LinearVelocity completely breaking new Humanoids

Just recently, Roblox released a new update that was meant to overhaul Humanoid physics. Unfortunately, this broke our nextbot system, which uses LinearVelocity’s to move our AI around. We tried to find other temporary solutions, such as using the deprecated BodyForce, but to no avail. As a consequence, we were forced to temporarily shutdown our game, Evade, until a guaranteed fix was set in place.

The LinearVelocity object class is linked to HumanoidRootParts being deleted in humanoids. This has caused a collapse of the nextbot system in Evade, which required a bypass by changing the LinearVelocity attachment to a part welded to the humanoidrootpart, instead of an attachment directly to the humanoidrootpart itself.

Another issue related is that the humanoid’s health would be randomly set to 0 in game. No game functions set the health of Nextbots in game. In order to bypass this, a ForceField was given to these humanoids, which stopped the issue but also prevented damage from occuring to them. It was notable that this issue never happened to humanoids with slower speeds, like “Rebel” units, which resemble players and are much slower than the typical Nextbot.

This issue typically only happens with higher amounts of humanoids with LinearVelocitys in them, or when they are at high speeds, and surrounding humanoids often get deleted when the bug occurs.

Temporary Fix
As a temporary workaround these issues, we instead applied the LinearVelocity to a part, then welded it to the humanoid. It took multiple iterations and debating between other developers on a potential solution, but after a few hours, this was the only thing that appeared to reliably work.

Repro Files
linearvelocity_humanoid_bug.rbxl (61.6 KB)

7 Likes

I see in your test place you have EvaluateStateMachine set to false. The behaivor behind this property was only enabled on Friday. Do you intend to have it set to false?
This will result in a different behavior than you would have had earlier last week, the default value is True

The issue still appears whether EvaluateStateMachine is true or false. Setting it to false only delays the crashing by a moment, but the result is still the same.

Are you still encountering this issue?

No, it has been resolved within our game