Glad I’m not the only one encountering this. Though I have to wonder why this issue isn’t more active… what are we doing wrong? Haha.
For what it’s worth, it’s only an issue if your MoveTo speed is lower than the average tickrate (i.e. 0.333333), at least in my experience. Yes, even if you have a queue of MoveTo commands in it’s own spawned task; it just goes whacko if you try to move anything at a rate quicker than the game tick rate.
I’ve since given up on trying to make my own NPC’s / Bots and such. Until they fix these timing/sync issues, UEFN is severely limited in what kinds of games can be made IMO.
This wouldn’t be an issue if we could cancel/interrupt a running task, though (along with the MoveTo command that’s running inside the Task, I mean) - then we could just “steer” our props when their direction is updated, for example. REALLY hope they give us more than the basically-useless “Await” function on Tasks. Also the ability to assign the Task to a class field, so we can cancel it from a different place.
That would make the “I want to update MoveTo faster than the tickrate” issue redundant, and it’s probably easier to do than making MoveTo “more optimized”. Plus it benefits all async stuff.