I want to move players and their physically simulated trucks and wood up and down on a big elevator. I can do this in one of two ways:
- Anchor the elevator and update its CFrame to move it
- Use a prismatic constraint
Both of these solutions have problems that the other solution solves. Neither is currently acceptable on its own.
CFraming
CFraming is good because it is absolute. I can tell the elevator to be somewhere, and it will be there. It is bad because it doesn’t interact with physically simulated objects well.
Here, the elevator is lowering, carrying players and vehicles. Starting around 4:35, you can see that the players who aren’t actively rocking their cars forwards and backwards will start to float up relative to the elevator. The elevator is lowering underneath of them, and the vehicle isn’t following because it’s gone to sleep. These players have figured out that they can keep their cars awake by rocking their cars back and forth, but I’ve seen more videos of players who haven’t figured this out, and their cars will just phase straight up through the top of the elevator until they get some sort of input from an unanchored object.
Same problem applies when the elevator is going up. Here’s another video.
At 2:29, you see this user struggling with sleeping parts phasing down through the elevator as it moves up through it.
I could see CFraming working for this use case if there was a way of searching through the elevator region and forcing all the parts in the region to stay awake while the elevator is in motion.
.
.
Constraints
Constraints are definitely the correct way of moving things in a physically simulated way. Because the elevator is actually moving (not just changing position as with CFraming), the engine recognizes that it is interacting with parts around it, and should automatically keep these parts awake. This is nice. However, it is bad because constraints could be doing anything out of your control, and there’s no way to make them absolutely do what you want.
Here, the elevator is using a prismatic constraint, with max force set to inf. It is not supposed to be moving at this point; it should be in the neutral high position. However, these players, using only the weight of a few vehicles, are able to overpower the elevator and force it down below the desired position as much as they want.
I think one of the issues here may be that the players have network ownership of their vehicles, but the elevator is simulated on the server, and these simulations don’t interact with each other well. The players simulations are doing what they will, and the server is trying its best to keep up.
I’d propose that with max force set to inf, this be handled as special case. Not just interpreting the max force as a very large number. It should make things actually move as if with infinite max force.
.
.
.
I know that constraints would be the proper way to do this. But honestly, fixing this maxforce issue with constraints seems much, much harder than just providing API to force parts awake. I know the goal is to build a physics engine that is smart enough to know when to sleep parts and keep them awake, but it’s never going to be perfect. It’s best to give developers control. The same reasoning applied when we finally got the ability to set network ownership.
Ultimately, I hope both of these problems get addressed.