This isn’t what I remembered last time it rained grenades…
3 Likes
Use Case: I make trains on ROBLOX. When the trains are supposed to be at the station, it could be really useful for me to have a sleeping part instead of having to anchor a part.
1 Like
Anchoring a part makes it accept no physics input (thus it sleeps). I fail to see any real gains from having a specific ‘sleep’ option in this use case.
2 Likes
When I anchor a part that still has a velocity (you know, a 0.1 velocity), players slide. Wouldn’t no physics solve this?
1 Like
From my understanding that is not related to the parts physical properties, but rather the physical properties of the players.
Sleeping a part (which i’m certain occurs when a part gets anchored) wouldn’t change this.
That is from the part. Try to anchor a part and set its velocity to (10, 0, 0) and walk on it/place a brick on it
1 Like
Maybe you could try scripting the velocity to be (0, 0, 0)? I think you could do something like that since velocity is a scriptable property, and you could just loop through the parts in the train and kill their velocity whenever the train is supposed to be at a station. I know this may not be the most desirable solution, but it could be something to use if you don’t want to anchor parts 
1 Like
The idea here is to use Anchored to keep the part “asleep”.
I know now that the part is definitely sleeping, after enabling “Are Awake Parts Highlighted” in the studio settings. The issue is that with slow angular velocity parts, they appear to sleep after moving a short distance.
Here’s a video of the issue:
This is regardless of friction as you can see by this second video of a part suspended in the air:
I have made sure the beta feature is enabled. This also happens with legacy body movers, so I am almost certain it’s an issue with the part being put to sleep.
Here’s a repro file if you’d like to try it out for yourself: AngularVelocitySleepingRepro.rbxl (18.9 KB)
7 Likes
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.)
15 Likes
Great update! My game has a rock dropping script and sometimes the rocks fell asleep and stayed in the air while they had to fall and i had to add a delay, now with the new update i think i should not worry about it!
Unfortunately I am still noticing that slow translating constraints still sleep only a second or two after moving. I am eagerly waiting for a fix to this.
@cc567 @UsernameMissingOrNil @plasma_node
We still do have a limit on the force applied and current velocity to decide if something should sleep, so very slow parts may still experience issues. It’s difficult to provide the specific criteria since it depends on several factors. For example, in your case with the rotating part @UsernameMissingOrNil, making the part larger should actually keep it awake under the same angular velocity (larger parts would have larger changes in position), or if a linear velocity component was added to the part. This is also why it’s helpful to see specific use cases, to better understand where the current system doesn’t handle well (do you need a part that size physically spinning in place at that speed for your game?).
We do however have a threshold value that I can change and hopefully improve these cases. We will also start discussing API options, probably along the lines of keeping parts awake.
@cc567 can you explain the case or send a repro file? You can DM if you want. Thanks.
@MrGreystone
Thanks for the thorough report, a lot of different things we would like to look into here. Do you also have a repro file you could send? Maybe just the boat model and sinking system? You can also DM, thanks.
4 Likes
Might be worth mentioning I was testing my game in Studio with this feature turned on and I got sleeper physics again…
It’s my bowling game. The ball bounced off the pins as if they were anchored.
I want an API to call physics sleep on objects. I want a more broad control over physics.
1 Like
Surely you can just Anchor the part? Anchoring functions identically to sleeping.
There’s two primary reasons why I want to manually trigger sleep, and use other calls.
-
Physics animations are dynamic, triggering a part to unanchor has latency between the client and server. If a car crashes into a giant brick wall, unanchoring the wall when the car gets near the wall is currently the best option, while using sleep would be an even better option, as with unanchoring nearby, I have to predict before the action. In normal game engines, even older ones such as the Source Engine, I can call Sleep.
-
Forcefully calling sleep has benefits on client-sided physics in situations where the client is interacting with an unanchored object (such as a rope or weld) and needs realtime awakening. The Roblox engine is not as fast, or controllable, as if I could specify when to call sleep.
1 Like
Maybe it’s something to do with the Mass? , did you try using bigger increments too? And did you try the same with a Massless Part? I know that this makes no sense, but that’s my only possible explanation for thios.
@C_Sharper This issue is only occurring when you have the sleep improvements beta enabled? Could you please provide a repro file (you can dm) if so?
@BuilderMfriend1
I explained the reasoning in my last post: to constantly rotate at that speed, that part would just need to be larger. That’s because the larger the part is the more “stuff” is visually moving around. Mass/density does not effect this. We may try lowering the threshold here though.
@RaterixRGL
For 1, a stationary brick wall would already be asleep, and wake up when touched. I’m not sure what you would gain by telling it to sleep. If it’s to insure that nothing else wakes it up except for a car, then anchoring the wall and unanchoring when a car comes within a certain distance would be a valid solution.
For 2, I don’t fully understand what you are describing. Are you running into an issue where something is not waking up via player interaction?
1 Like
Most of the time when we tie something to a player and want to control its physics, when we’re done with it the client usually has a few additional updates and causes instability.
About the unanchoring function, most game engines don’t require you to worry about instability. In many cases, most, if not all situations, relying on anchoring a part is the only solution to save on resources.
However, in other game engines, such as Unreal, they allow me to call sleep on an entire wall of blocks, and I don’t have to worry about them whatsoever. In Roblox however, I have to consistently worry about it updating incorrectly, and not processing physics as best as it could.
You see, in Roblox, a floating part will almost always never be told to sleep (except for those bug cases, due to such a badly made physics engine, I’ve even seen parts clip through other unanchored parts), because that’s not how we can control the engine. Stacked parts again are untrustworthy, the actual force of gravity alone is too unstable to rely upon. Roblox is doing physics calculations even when the part is sleeping, it’s unoptimized and poorly made.
My point is, if I had more control, and not be treated like a child as if apparently, actual programming functionality is too much for me to handle, then I would be happy.
I’ve been a developer on this platform for many years. To this day, I’m still upset that Brick Colors were the only way to change a parts color, and that Roblox for so long, thought that using an RGB Color Wheel was too complex for us to use.
1 Like