Laggy/jerky rotation when target is reached

Beginner Questions
#1

Hi Aron!
I just wanted to ask you what could be the reason why sometimes when a RichAI object have reached its target, instead of stop its movement it continues to rotate in a jerky and laggy way, for an undefines time.
Don’t think it is something related to the rotation speed because a tried a very large range of values. I also tried to set a larger end of reached distance and a slowdown time to 0 but I still get the same result.

Maybe it’s something stupid but I can’t find a reason!
Thank you

#2

Hi

Is “precise slowdown” enabled?
That usually helps.
Also, slowdown time should be greater than 0 for best effect.

#3

tried, but no success. my current configuration:
repath rate: 0.5
max speed: 5
acceleration: 2
slowdown time: 1
rotation speed: 10000
end reached: 2
wall force: 3
wall dist: 1
raycast for ground placement: true
center offset: 1
funnel: iterative
precise slowdown: true
slowdown when not facing: true

My rotation speed is so high because my AI is actually an invisible group entity and I am using the vector from each member of the flock to this entity as an additional goal seeking weight for my flocking behaviour. So I don’t need realism in rotation, the faster this entity rotates to the target, the less time is wasted for my boid to reach the target.
(so another question would be: do you think this is a good choice to implement a goal seeking flocking behaviour?)

#4

Hi

Do you think you could capture a video and upload it somewhere?

Yeah, I guess that could work.

#5

I will, as soon as I can.
Whatever, I thought that the simplest quick-and-dirty solution is to disable the RichAI component once it reaches its target (I’m working with opsive’s behavior designer so it is reasonable to switch on and off the component when the behavior is chosen)

#6

I had the same thing, a sudden jerk just when the target is reached. In my case the cause turned out to be my own interpolation of the facing angle. I computed the direction vector by subtracting subsequent positions and dividing by the speed to normalise its length. But this goes wrong of course when speed becomes zero. You also get rounding errors as it approaches zero, which are magnified by the normalisation.