Hello! First of all, Aron, this is fantastic software that has proven to be both more fully featured and less complicated to integrate than Simple Path. Can’t beat the price, either, especially when compared to products like xaitment.
I’ve got the A* Project working well, except for one issue that I can’t for the life of me figure out. I’m using a Recast graph with RVO simulation. Enemies pursue the player just fine, but they have a habit of zig zagging back and forth, even with a Funnel Modifier. You can see the quirky behavior in this video:
http://www.youtube.com/watch?v=RR_vAD5Q1Ok&feature=youtu.be
The enemies toward the back do this most often, making me think it’s the RVO. Once or twice I’ve seen it happen with isolated enemies out in the open, which doesn’t make sense since the RVO shouldn’t really be coming into effect with no other agents nearby. And yet, before I upgraded to the Pro version and started using RVO, enemies pathed just fine. No matter what settings I change, it makes no difference. No offense, but there are few details about the RVOController’s exposed variables in the documentation, so I have no idea if adjusting settings is actually doing anything. You can see my current settings here:
RVOController: http://i1343.photobucket.com/albums/o800/BrianCrandell/PathfindingProblem1_zpsbdf94327.png
Seeker and Modifiers: http://i1343.photobucket.com/albums/o800/BrianCrandell/PathfindingProblem2_zps33bccb31.png
Recast Graph: http://i1343.photobucket.com/albums/o800/BrianCrandell/PathfindingProblem3_zpsdf4145d3.png
Even though switching to the A* Project has solved a lot of problems, pathfinding has been by far the biggest headache on this game, and it’d be such a relief if you can help me solve this.
Hi
Yeah, the spammers are a real pain. I have changed the registration captcha and removed all I could find for the moment. Hopefully they will decrease in number.
It definitely looks like steering code at least. I think the paths generated are fine.
I don’t think the RVOController is causing the problem, it looks more like the input to the RVOController, that is, whatever movement script you are using (AIPath?).
More specifically, I think you should increase the Pick Next Waypoint Distance (or corresponding variable) on the movement script.
I see we have some spammers on lately. >_> This fell off the front page pretty quickly because of them.
I never understood how important security measures like CAPTCHA are…they were always just that annoying step required during sign-up. That definitely illustrated why we need them. Nice job cleaning up the forum.
Thanks for your response. It wasn’t Pick Next Waypoint Distance, but you pushed me in the right direction. Turns out that I was still using AstarAI as my movement script, which wasn’t meant for RVO, so I had all these funky inputs going into the local avoidance. Now I’m using RVOExampleAgent, and that solved the initial problem. However, I’ve got a follow up if you don’t mind.
I’m using a Finite State Machine to switch between normal movement (pathing) and attacking states. I’m trying to turn off pathing for the attacking state because I want my enemies to stand in place for most attacks. At the beginning of my movement state, I always call RVOExampleAgent.RecalculatePath(). At the end of the state, I call Seeker.GetCurrentPath().Error() and set RVOExampleAgent.path to null, according to your advice in someone else’s thread about canceling unit move orders. In addition, in RVOController I return at the start of Update() if my enemy is not in the movement state.
The problem is that when enemies are finished attacking and return to the movement state, they teleport a large distance in the direction they were headed before they stopped moving. It’s as if they’re still following the path vector, just without updating their position. I recorded another video below:
Something is still updating, but I can’t track down what. Do you have any idea what it may be?
Hi
That is because the local avoidance system uses an internal agent with its own position. The RVOController does its best to keep that position updated even if the transform is moved by something else than local avoidance. By not giving the RVOController move commands in combination with returning from the update function will have the effect that the desired velocity is still set to the last movement call, so the internal agent keeps moving (not the visible one because you return at the start of the update function). When you stop returning, it will “teleport” to the actual position of the internal agent.
What is a better approach is to set the Locked property on the RVOController to true. This will stop it from moving.
Hey, there we go! I understand RVO better now. Awesome, thanks again!
