Vehicle Seat :Sit() teleports vehicle to character

[slitherylemur]

I woke up to my newly launched game 🚀Rocket Cars 2 - Roblox being completely broken when it was working fine yesterday.

I have had to private the game to stop my advertisements ruining my like ratio.

Calling :Sit() on the vehicle seat appears to teleport the seat and the entire vehicle to the players position instead of the other way round.

The vehicle suspension and physics and/or controls also seems to be different to how they should be.

This does not seem to be an issue on my end as the game had 2 servers on the same version, the one opened 14 hours ago was fine and all the ones opened from now are broken.

No changes were made during the time of it becoming broken.

This is reproduced by all players so system information is not necessary.

To try combat this we teleported the character to the location of the vehicle spawn before siting the player but our controls and/or physics constraints still appear to not interact the way they used to.

I have no idea why this is happening and I’m very confused. Perhaps the seat weld is happing the opposite way round or something.
I hope that I am wrong and this is not a bug on Roblox’s end but I haven’t changed anything.
Thanks for the help!

Expected behavior

The vehicle should stay at its location and have the character be sat into the vehicle.
The vehicles movement should work as in our video for the game recorded yesterday.

[slitherylemur]

Edit:
This old version of our game not updated in months now also deosnt work.
feel free to test:

DEMOLITION DERBY🚗💥🚗 [NEW!!]

Perhaps something was recently deprecated/removed?

[kni0002]

I have been experiencing a similar issue, I believe that its related to server/client ownership that Roblox may of messed up.

My game Shipping Lanes was working fine a few days ago, then suddenly today people started encountering issues related to ship movement. I investigated and it seems that physics and objects owned by the player does not replicate to the server for some reason?

Shipping Lanes

May raise another issue, since this bug is somewhat major

[Im_Magni]

This happens when the character its anchored and the seat unanchored

[slitherylemur]

neither is the case though and it broke over night.

[vespa_rbx]

we are looking into the problem and get back as soon as we get any update

[DrCherenkov]

I’ve disabled a recent bug fix for this place. Can you try your game again? Also, to help with further debugging, would it be possible to provide a simplified model or place that reproduces the problem? Thanks.

[slitherylemur]

Game works now. Thanks for the help. Sorry for the late response. I will send you a copy of the game in a private messages

[RamboBelac (Rambo)]

Same issue has occurred in my game with my starfighter system. Without any changes, the starfighters began not taking off or crashing into the ground.

[ContextLost]

The change Brian enabled effected wether LinearVelocity constraints participated in the spanning tree logic, which is also responsible for choosing assembly roots.

This could indirectly effect the choice of assembly roots, because simulated joints to another assembly with stronger root priority can force the current system to pick a different assembly root than it would have otherwise because the “mechanism” tree is a superset of the tree of parts that form Assemblies. (A “mechanism” is an internal tree of parts/assemblies connected by simulated joints; it’s the basis of network ownership units. A Mechanism forms one or more network ownership units.)

If a part has a simulated joint linking it to an anchored part, in the mechanism tree it is probably the node connecting its assembly to the root of the whole “mechanism,” If so, it must be the root of it’s own assembly as well because the tree of parts in an assembly is a subset of the larger “mechanism” tree for no good reason.

We wish it wasn’t like this. It’s hard to explain, we don’t really document this, and we’re actively working on changing it to make it more simple and reasonable. In the future Mechanisms will be trees of Assemblies connected to other Assemblies (not parts), and Mechanisms and Network Ownership Units will be the same thing.

Hypothesis

What probably happened is some delicate balance was upset. The seat only puts a multiplier on the largest surface area of the part extents root priority sorting criteria. This one is really finicky and hard to reason about.

If the car had a tiny seat that would otherwise loose a root comparison with your character, but also had a LinearVelocity connected to an anchored part, that LinearVelocity was probably “accidentally” inflating the car’s chance of being the combined assembly root until Brian fixed it.

Workaround / Definitive Fix

You might consider setting a BasePart.RootPrioty on the seat > 0 (or otherwise greater than your HumanoidRootPart) to guarantee the car seat will always be root when a character gets in the car.

If the character has stronger assembly root priority than the car, the car snaps onto your butt instead of the other way around.

If anything is relying on that part size based comparison to function it’s on shaky ground. Prone to being broken by large avatars, etc.