Oreons spinning after reaching target

[skaldarnar]

So this happened:

I suspect this to be related to pathfinding or Behaviors in some way. @casals any idea what might cause this behavior?

[Naman-sopho]

This is the Oreons' "at work" animation. If you look into the Oreon BTs(and the associated behavior node) they are supposed to roam around in the entire area assigned for a task until it is completed. But for some reason poor Oreona are just stuck on one block :)

[casals]

@skaldarnar This looks very similar to the glitching observed in deer a while ago. IIRC that was related to "never reaching the target": the calculations related to deciding if the deer had reached the target (and thus stopping the animation were bugged. Have you seen this bug before, or is this something new? There was a commit to Behaviors related to this exact part of the code: Terasology/Behaviors@067b1c6 . Also - in the case the movement actions/associated animation changes are implemented only within MOO - it's worth comparing this code with what we have in Behaviors. As a final note: I quickly went through the behavior files but I couldn't find the animation changes (i.e. whihc animation the oreon should perform when it reaches the target). If you take a look at the stray behavior (https://github.com/Terasology/Behaviors/blob/develop/assets/behaviors/common/stray.behavior), you'll see that there's a clear change right after the random movement.

[skaldarnar]

Just saw Terasology/Behaviors#38 - maybe related? Not reaching target sounds reasonable, and maybe the recent behaviors change is related (it effectively reduced the distance the entity needs to have to the target...).
Assuming that the target position is in the center of a block (in the ground) a distance of 0.2 to the target might be to few....

[casals]

Yep - about "reducing the distance" - I remember tweaking with the parameters on Behaviors back at the time (the same LoC changed in the commit yesterday), and the reason why I kept the verification linear (and not squared) was because when it got too small (< 1, so the squared value is even smaller) the "glitching" was even more pronunciated. It may or may no be the problem at hand, but is does happen.

[skaldarnar]

Did some quick testing:

• ❌ increasing the distance to 0.6 does not help
• ❌ increasing the distance to 1.2 does not help

That doesn't seem to be the main problem.... 🙄

[casals]

Hm. Which is the associated behavior for this particular situation? Does changing it to a default behavior (i.e. critter) eliminates the bug?

[skaldarnar]

Feel free to investigate it - I won't have the time to look into this in detail 🙈