I have a crane model that I was trying to make when I came across this issue, and you can see my initial post on the Scripting Support section here.
Here’s a video showing the problem:
When I begin tweening the anchored part’s CFrame, the attached part freezes and does not unfreeze until the tween has finished. If the network ownership of the unanchored part is manually assigned to a user (or the user approaches the part and network ownership is automatically handed over), only that user sees the part moving. The server, as well as all other clients, view it as being stuck until network ownership is changed again or the part’s tween finishes.
Here’s the place file from the video: Baseplate.rbxl (22.4 KB)
Hey! I’ve encountered the same issue which I PMed to some of the DevRel team to move into this section since I didn’t have permissions to create a new thread (not a Regular), but I seem to be able to reply here.
I’ve made a repro for this:
Reproduction steps:
Open the rbxl reproduction file
Press play (not Run)
Under Workspace.Model.Script, there is a EnableBugBoolValue - toggle it on to showcase the issue.
Whenever EnableBug is on, the client should be unable to see any replication changes from AlignPosition - if you switch the mode from client to server, you will notice that the model is being moved on server, but not on client.
@The_Sink the only workaround for this I found was to manually update the Attachment’s WorldPosition or Position properties (pretty much what @kleptonaut kleptonaut said) rather than the BasePart it is parented under
Sorry for bumping up this topic but yes, this bug is still present today.
A quick repro demo, Instead of ropes, I am using HingeConstraint.
It appears that it only replicates for the network ownership of the unanchored parts, which means if a player owns the network ownership of the parts, they will only perform in the expected behavior on the client’s screen but not on the server.
I am trying to create a working bell (animated with tweens) as shown in the video below, but the sphere that strikes the bell on the inside appears anchored from the perspective of anybody who does not have network ownership of it, making the entire assembly appear wonky when activated.
I would attempt the workaround, except that I’m not sure how I would go about applying it to attachments along a rotating cylinder.
Hi sorry for the bumb but this is also an issue with Hinge constraints unless I got wrong how they work, if they are connected to an achored part (in this case the base of a turret) It won’t replicate either.
I currently have a similar issue but with HingeConstraints. I am tweening my door’s hinge part which has other door parts welded to it and a HingeConstraint based handle attached to one of the welded parts. Setting network ownership did not help. I even used a custom RunService based tween module to move the door on the server but still did not work as expected.
Sorry for yet another bump but it seems to be getting worse for me, a baseplate with 2 constraints and 3 parts seems to be something the engine can’t manage. I have linked the file below if anyone would like! bugged.rbxl (82.2 KB)
I noticed that this bug says that setting ownership to a specific player causes everyone else including the server to not see updates.
I experienced an issue with my trains where if a player sat on a coach that did not have a body mover, that coach would lag behind the rod constraint connecting it to other coaches, including the coach with a body mover, resulting in the trains being violently derailed or even the constraint outright breaking.
Can anyone else confirm if they have this issue when using body movers as opposed to tweens?
I definitely feel like this bug’s priority should be bumped massively, considering that I had to remove seats from my trains entirely because of this bug (as it is not performant, buggy, and unnecessary to have body movers in every vehicle of the train)