In the demo place I have, which should show the issue at hand - there is an NPC called Bob who uses Humanoid::Move(direction) to walk in the direction of the green cube, which changes it’s position when he reaches it. (Basically Bob randomly walks around using Move)
DEMO PLACE: HERE, Uncopylocked.
Calling Move(direction) from the server to a Humanoid will work 100% fine... until you introduce a client into the picture.
When you bring a client into the picture, and the client goes near the NPC Humanoid, Move() starts to bug out and eventually the Humanoid will stop moving to the direction it originally was meant to go to.
I believe the issue may be related to the physics distribution. This behaviour happens regardless of FilteringEnabled.
I’ve tried enforcing the Move() command by repeating it, but even that doesn’t fix it. I assume there’s a bug that’s happening relating to the client taking control of the Humanoid’s physics.
This issue is currently holding back my project, as MoveTo() is unreliable currently with tight spaces due to short distances being ignored by it (probably due to legacy support for that green circle).
REPRO STEPS:
[ol]
[li]Walk towards Bob[/li]
[li]Bob will stop randomly, this isn’t intended.[/li]
[li]Walk away from bob - He will start again after a certain distance[/li]
[li]Repeat a few times - each time he’ll resume his movements after a certain distance to a point where he completely freezes no matter how far away you get from him. [/li]
[/ol]
After doing this a few times, you’ll notice Bob stops moving completely, even if you move away from him. If you look at the source code in the place above, he’s not meant to stop completely like that.
Bob’s coded to move to the direction of his goal, yet for some reason introducing a client player near him makes his Move() command break a little more until eventually it stops working.
This bug also occurs in Studio local servers as well.