We’ve been getting reports from our player base where all flying vehicles (planes and helicopters) are stuck in air and are unable to move at all. We’re unable to fix the issue on our end and believe something on Roblox’s end must’ve tripped something up.
Game: [Invictus] War Tycoon - Roblox
Video:
This may be related to this rollout relating to mover constraints: Improved Mover Constraints: Enhancing Stability and Network Ownership
Do your vehicles use LinearVelocity or AlignOrientation constraints? If so and you are using the default value for workspace.MoverConstraintRootBehavior, then you may be seeing different behavior relating to assembly creation. We moved into phase 2 today so the default behavior has been changed.
Yes the systems use LinearVelocity and the default MoverConstraintRootBehavior is being used.
However we are noticing that it is inconsistent across servers and are having a hard time doing any repro testing. What are some things we need to look into to fix with this change?
I read the post you shared and it seems like it can be one of two issues. 1) with parts being massless, or 2) our Root CFrame is being moved and another part has a LinearVelocity constrained to it.
If it’s an issue from the former, we have a Weight block that is not massless to provide mass for the vehicles. Wheels are given mass as well. I am noticing that even at Default for MoverConstraintRootBehavior, the AssemblyRootPart is still being set to a massless part. But there ARE parts that are not massless, should that be enough to prevent this from being the issue?
If from the latter, spawning in Vehicles/Planes/Helicopters and whatever else, we need to be able to move the model to the spawned location. How do we get around this?
I am noticing that even at Default for MoverConstraintRootBehavior, the AssemblyRootPart is still being set to a massless part.
Is it selecting the part that has the LinearVelocity constraint? This was the old behavior that we were trying to fix with this rollout. If that is still happening with the new default, I would like to take a look at the model to see what is going wrong.
Also some players have no issues and some do
I have DMed you the RBXM file. The AssemblyRootPart is massless but has the LinearVelocity
Hi all, have noted this on my train games which use LinearVelocity too - they work fine when you’re in a server alone but they don’t move when other users are present. No errors in the server log when joining to investigate but this is the set up I have in place:
If you disable the workspace property MoverConstraintRootBehavior, then you should be able to recover the old behavior. We will need to determine why your mechanisms are having problems with the new setting but I can help you trouble shoot that. Setting the property for now should get your game up and running again.
Temporarily disabling the workspace property MoverConstraintRootBehavior should fix things in the short term. We will need to sort out why the model doesn’t seem to work with the new logic by the time we hit phase 3 of this rollout.
Had similar issue with ragdoll horse mounts in my game today with players reporting that the mounts get stuck in the air and wouldn’t move. Mounts are parts connected with ball socket constraints with their core part moved by an alignorientation and a linearvelocity, with manually setting the velocity of every part in the model for things like jumping. Disabling the MoverConstraintRootBehavior fixed this.
Thanks, this is much appreciated. I’ve applied this change to my games and it seems to be working again now, including with other players (in their own trains) in the vicinity.
Sorry about the inconvenience. These things were bound to pop up as we moved into phase 2 of this rollout. Please send me the model if you would like help fixing it up to be compatible with the new logic. As the announcement post shows, this property fixes up some long standing jank in the mover constraints so we do need to eventually move over to the new logic.
Please take a look at the model and feel free to send it to me if you’d like help diagnosing the problem. We will need to get it working before we head into phase 3 of this rollout.
I believe I have a similar problem. Shown in the video is my train game, I am approaching a switch track where when I come close to it, it sets the direction for me and makes the appropriate rails have collision; however the train does not act like the rails have collision and instead derail.
Later, oddly enough I found that typing in a new collision group (not an existing one) to the rail parts suddenly fixes their collisions. (The rails and train wheels were never in a collision group other than Default, in the video you can see the rails are now in their own groups. This was an attempt at fixing the issue, however clearly failed.)
I also have the setting for the new mover constraints disabled:
Video Link:
If you are seeing the problem with Workspace.MoverConstraintRootBehavior disabled, then it is probably a separate issue. When did you first start seeing the issue?
I’ll mark this as a solution for now as you work through troubleshooting things individually. I can confirm this solves the issue. Thank you!
Good thing I found this thread. I had similar issues in my game. Interestingly, it seems to have only been affecting PC users and not mobile.
The issue has only first been reported in the game a few hours ago today. It is possible that it might have started a little earlier, and I do know studio has updated multiple amounts of times today combined with yesterday.
I just can’t wrap my head around why changing the rail part collision groups suddenly restores collisions, both the client & server see the same thing so it is quite confusing. (Also, thanks for replying)
I’ve had the same problem, setting Workspace.MoverConstraintRootBehavior to disabled has fixed it.
We move players in a “vehicle” using LinearVelocity. Whenever the LinearVelocity was created and had the attachment set, the “AreOwnersShown” debug visualisation would show network ownership for the assembly as black (I believe that means not owned by anyone?). “AreAwakePartsHighlighted” would show that the assembly is asleep. The assembly wouldn’t move. Disabling (Enabled=false) the LinearVelocity would fix the networkownership.
For some devices the assembly would never move, for other devices it worked fine.
After the server had been online for 12-16h all vehicles stopped working no matter which player/device.
