Constraints blocking animation replication?

I’m currently working on a train simulator and I’ve ran across an issue with animation replication (?)

Imagine the first green box is a truck, and the second green box being a trailer,
I connect the trailer to the truck via a rodconstraint, but as soon as it’s enabled, it breaks all animation replication for the truck…

If the trailer is welded to the truck, the animations run fine, it’s just that any constraint between the two boxes stop the animations.
Network ownership of the entire thing is set to the local player, which sees all animations run fine at all times.

What the server sees:
https://cdn.discordapp.com/attachments/364496113203675147/546354405394612225/gif.gif

I have no idea how to fix this other than having a heartbeat loop enabling/disabling the constraint which is a very inefficient and hacky way around this

2 Likes

Here is perhaps a clearer gif to illustrate the problem.

https://giant.gfycat.com/HugeWaryIcelandgull.webm

Through further experimentation, I’ve found that this happens when the assembly root changes to the new part. Anyone having issues with this should try to increase the RootPriority so the assembly root doesn’t change accidentally.

https://giant.gfycat.com/BetterDistinctDegus.webm

5 Likes

Cheers, this saved me hours!

Happy it helped.
I wouldn’t mark this thread as solved. I do believe this is a bug, and marking it as solved may lead to it being overlooked.

I think it certainly is a bug, raising the root priority sometimes fixes replication, but sometimes still doesn’t solve it at all (just noticed it after doing several tests) :frowning:

Looks like you’re enabling the constraint only on the client side here, right?

That would cause the client and the server to have an inconsistent mechanism structure. A lot of parts of replication rely on mechanisms having a consistent structure. Every “mechanism” (set of assemblies linked with constraints) has a single “root moving assembly” and the replicator may reject updates if that root is inconsistent.That’s probably what’s happening. Try enabling the constraint on the server first so the structure stays consistent. That might fix it.

Unfortunately these details on network replication are poorly documented right now and we don’t have great tools to visualize when and if these kind of desyncronized situations are happening. We’ll try to improve this in the future.

2 Likes

In both the OP and in the videos I provided, the constraints are enabled on the server (green viewport outline).


It would definitely be helpful to have documentation and tools for debugging these kinds of replication and sync issues.

1 Like

I see, I have been able to solve this entirely in a very hacky way… RootPriority on the server is 0, Clients sets RootPriority to 1 and disables constrains locally… This seems to have fixed animation replication entirely for some reason. :sweat_smile:

2 Likes

According to the topic, I’m having the same issue. Below’s a screen capture of me sitting on a seat connected to another part through a hingeconstraint. All of parts in the constellation are owned by the server. The sit animation is played both on the server and on the client, nothing to see though.
The animation is however visible on the server, but not to other players. Cloning each part of the character in place on the server results in a sitting character.

Setting the seat’s owner to the sitting player and delaying the sitting animation by two seconds results in the animation to work more or less. However, a second player taking another seat in the same constellation (other seat’s owner will be set to other player, animation also delayed by two seconds) only shows the animation on the client of the second player.

Screenshots

Client of player who sat first:


Client of player who sat afterwards:

Edit: This does not require anchored parts in the constellation, even happens here aswell.

1 Like