Physics Sleep API is an all around must have! Allow me to elaborate.
In 2013 I made a game called Sinking Ships. It used bodyMovers, but by 2015 the article “LIVE - Upcoming Physical Properties and PartMaterial Changes” made me opt for a superior sink mechanism which used density accumulation in large buoyant hull parts to mimic flood-weight.
This was all well and fine, until I took an unexpected two year hiatus. In this period “Characters on Moving Platforms - Now Live” took centerstage. For me, and anyone else who hasn’t changed their methodology, it hasn’t been pretty:
Note: The below gif was sped up 50% (jittering is subdued, the oscillations are worse in-game)
Description of what you’re looking at (in sequence) above:
- Characters jittering in the bridge. (The ship is settled, there should be no movement.)
- Characters in the water flung off from jittering. (That doesn’t look fun, does it?)
- Two players at the stern sliding around. (One presumably jumps off in agony.)
The above’s display description:
- All around constant instability. (Expressed particularly well at the borders of the screen)
- An unfortunately common physics ‘explosion’ where my character as well as half a dozen more are flung out in various directions of questionably lethal velocity. (Just imagine what would happen if I added a impact damage script! In this condition it would be game breaking.)
The platforms update lends the great opportunity to make pilotable craft such as lifeboats for players to ride on with little inconvenience. I’ll just redesign my core mechanic first, I thought.
So I got to work, talked to some developers and did what everyone else who needed to move large models in the 21st century did: I CFramed an anchored basePart attached to it to give the illusion of a sinking.
Great! Now everything is deterministic, under my control, and players won’t be flinging everywhere! (It’s replaced by players now sliding in place, more on that later).
With this, I could actually consider physically simulated debris and free bodies in, on or around the vessel as well. Standing on buoyant cargo in the hold, finding relief from the cold water in the debris field after the ship’s descent, maybe even constructing a makeshift raft or something. It was certainly the source of necessary, creative, unique-to-Roblox-experiences I was seeking. But until now I’ve discussed it only in principle.
Pictured here below is an example of such free bodied items on a deck. In practice, with the conventional physics sleep, the cargo will go into paralysis and ‘ghost’ through the ship as it rises, literally staying place as the ship CFrames itself upwards, downwards, wherever regardless. This can only be ameliorated with a very hacky script which I can provide upon request.
With the beta improved physics sleep, this still occurs, though the behavior is more sleep and less complete shutdown of all functions for static eternity (as previous):
(This gif is sped up after the initial settling occurs x16. I can provide recordings of the conventional sleep as well as this in unedited full upon request.)
I narrowly presume this would be solved with some API like the current BasePart:SetNetworkOwner(), being instead called BasePart:SetPhysicsSleepState(int)
where int is a integer quantity specifying state. (1: default, 2: override to be active always, 0: override to be perma-sleep (for @Suggyiem’s intent)?
Because the ship is being CFramed about, it is micro-teleporting constantly, so I correct all freeBody positions via a mathematical calculation that determines the equivalent relative offset for a given a CFrame relative to the sinker’s.
This is great and all, but because characterReplication and its interpolation of those pesky not-every-frame player-position-update events is blackboxed, hardcoded, humanoid stuff, I can’t move everybody and everything a uniform displacement (i.e. on a cruise moving at 3studs/second in the X-positive direction) holistically. I wind up spamming updates as quick as possible and at best and still get this jittering in optimal conditions.
The only project I can speculate to have even ventured this far in integrating Roblox default character behavior with such serious Lua augmentation would be Phantom Forces under the guide of @AxisAngle. You shouldn’t have to be AxisAngle to do this, but it’s that hard.
For that I would propose a “displacementInheritance” function, though I still have no idea what I’m talking about.
(Pictured here: Two players and a cube all being simultaneously offset a uniform predeterminant amount every renderStep. I understand the Humanoid is opening up to Lua down the line though I still worry this will be beyond the breadth.)