HingeConstraint lagging behind moving object

I’m experiencing an issue where a welded model hinge constrained to a moving arm lags behind the arm movement.

I’m creating a theme park ride where a big arm rotates vertically with two carriages attached at the bottom, these carriages should be able to rotate freely.

This video shows the problem:


As you can see, the carriages float around the area where the arm is rotating, while they should be solidly attached in position but still be free to rotate.

Any help is appreciated!

Hey did you eventually find a fix for this? Having the same issue of HingeConstraints lagging behind. Tried mulitple things from NetworkOwnership to Massless and custom physics. But it seams like it just doesn’t behave like a WeldConstraint by matching the position instantly

Bump, I’m still looking for a solution to this same issue, however on a smaller scale.


The handle seen in the image is lagging behind, when at rest the handle meets it and is normal, no issues, but when the drawer opens is when it lags behind.

How is the handle attached to the drawer? If it’s welded it should update immediately.
How are you moving the drawer?

CFrames, Welds, Motors, and Motor6Ds aren’t physics based, so when you use physics based Constraints there is going to be some lag.

One thing I did in a case where I wanted to use both (I had hydraulic pistons made of PrismaticConstraints attached to a ramp pivoted with a Motor (not a HingeConstraint) so it was more stable.
The pistons would lag and jerk when the ramp tilted up and down.

I ended up putting a loop while the ramp was moving, and changing one of the Properties (like the force or speed related ones) very slightly. It kind of forces the Constraint to update. It’s not code, but the basis is something like this:

Is the Motor (or whatever the non-physics joint is) moving?
If it is then
change constraint Force (or Speed etc.) from x to .1 higher than x
task.wait()
change constraint Force back to x
task.wait()
end

It was being moved using just a HingeConstraint set to Servo, no attachment errors, however the mesh that actually holds the handle was attached via weld.


After a bunch of testing, I did find out that it was fully NetworkOwnership based, since Roblox sets network owners to the nearest player (using the growing network circle thing that roblox internal uses), the hinge constraint and the handle was working perfectly and had no delay for the player closest to it (network owner), however for everyone else including the server, the handle lagged behind.

I tried to set the network owner to server only while the drawer was in the process of moving and then some, however that just caused the lag behind for ALL players including the closest one.

I tried to manually set the network owner to the player who interacted with the drawer for it to open, and while this looked good for the player actually opening the drawer, everyone else saw the same lagging issue.

I was at a loss so I just removed the hinge constraint and had to cut my losses and accept that the handle wouldn’t swing when the drawer opened.


It may be good to let you know the drawer was being opened with the tween service through a remote event on the client. Since server tweens are laggy, my game uses a remote event and :FireAllClients to make tweens happen for each client, and while this COULD be the issue and related to ping, after testing with another player who had the exact same ping as me and vice versa, only one player had the proper look of the handle.

That’s the issue. You are tweening the drawer and using a HIngeConstraint.
Use a Prismatic for the drawer and a Hinge for the handle, or tween the rotation of the handle weld to the drawer and then tween the movement of the drawer.

Check out my Steampunk place. You’ll see all sorts of doors with handles. The ones you should look at are on the island with the paddlewheel ship at the dock. Go to the elevator (Prismatic constraints for it and the doors) and go to the big double doors covered with the awning. Open the doors and close them looking at the internal mechanisms with the gears and rack and pinion style locks. All of those are done with Constraints using Hinges and PrismaticConstraints.
There’s also many other interactable light switches, and moving parts. On the ramps for both airships the pistons were the ones I mentioned in my post above, since I am using Motors for the ramps since Hinges weren’t moving slowly enough.
On the center island is my small shack. The door is constraints, but the window and bed/desk are both moved with DragDetectors.
The Island with the observatory house has DragDetectors for the light and fan levers, the dartboard doors, the globe, the upstairs workbench drawer, and the chairs. The doors are Constraints. The observatory controls are Constraints, but the sliding doors for the dome are Tweened welds to the dome.

Yeah that makes sense, I’ll message back here if the issue still happens after switching to prismatic, if I don’t message back then assume it worked! Thanks

1 Like