This is a minor problem in PGS, but in the spring solver, sleeping is a very large problem. The spring solver continues to be relevant in games because of several unwanted behaviors that PGS has. This thread is not for a discussion about that, though; it is about the problems sleeping creates.
Take a very simple vehicle. It’s a vehicle seat (for input), a script that controls a BodyVelocity and a BodyAngularVelocity, and a frictionless part with zero elasticity hinged to the bottom. The vehicle seat changes between gray, white, and black to indicate the Throttle property. As you can see in the video, if the simple vehicle comes to a momentary rest, no amount of forward or backwards input can get it to move again. Only rotating the vehicle can.
Please do not be confused: there are other issues that sleeping parts presents, not just with this simple example.
This roller coaster has an invisible, CanCollide part that stops the roller coaster from moving, which is un-CanCollided to allow the roller coaster to dispatch.
This is what happens 90% of the time:
This behavior is rather annoying and makes things barely function. You have to jump out and get back in any time you want the roller coaster to go, and likewise for the train. There are more cases than this that I haven’t mentioned, these are simply the two easiest to explain.
The specific issue in this case seems to be that BodyMovers don’t wake up parts when they apply a force. There’s other issues with sleeping though and it should be more dynamic for development.
That’s only the first case in the post. The second case has to do with a block being removed, but I understand why that would never awaken. There are two others I wrote up then deleted for succinctness.
I really think this comes back to the whole argument of allowing developers to manually engage physics for a part.
Generally roblox does not want to implement things that can cause a lot of strain on the servers (imagine a script that sets network ownership of every part in the game to the server then wakes them all up at once. That’d be hell on the server).
But that said I do think a simple, straightforward and reliable method of telling parts to engage physics would be an awesome feature to have and I feel that this would help a lot of physics-reliant games, even if that method would be to fix issues with BodyMovers like those depicted here.
Imagine a script that duplicates 10,000 parts a second for the duration of the server’s lifetime. It’s not ROBLOX’s job to prevent people from being stupid.
We shouldn’t rush to implement manual control just because someone thought it would solve their problems though. If there’s a way to resolve this automagically behind the scenes (e.g. keeping parts awake if they have a bodymover on them and fixing the issues of waking constraints) then it should be done automagically without requiring any work on our part, and there’d be no reason to implement manual control. If it’s not possible to automagically solve all use cases, only then should we look into manual control.
I’m not sold on this idea. I’d like manual control for reasons similar to the ones Sharksie is asking for the ability to shutdown Team Create servers. It takes weeks or months to fix a bug or add one case, and during that time you’re stuck in the suck. Not to mention that some of the use cases would never add because they’re too game-specific, like awakening parts when a vehicle gets close enough. How would ROBLOX know what vehicles are meant to awaken parts?
That would be a use case that isn’t solved where manual control is appropriate.
What the engineers have to find out though is whether the plethora of bugs are perceived or real. If there are only a handful of underlying issues that cause all of these problems, then there’s no need for manual control once those are resolved. You can guess that some bugs are unfixable, but you’re not a ROBLOX engineer and don’t know how sleeping parts work internally. If they magically address all bugs then there’s no need for manual control. If they can’t fix issues that are game-specificy, then manual control it is. We don’t need to guess which bugs are fixable or not. Feature requests are tailored to problems instead of solutions because of this.
Keyword here being magic? If there were magically no bugs would we need a bug reports forum?
There are more issues with sleeping than the two examples I gave. Also, please stop assuming what I think. It happened yesterday and I was none too pleased, and again just now. I think sleeping bugs are unfixable in the same way Sharksie thinks TC bugs are unfixable, which is to say I don’t. What I did say was that I did not believe ROBLOX would add some behavior that control would add, namely that parts would awaken in the presence of a vehicle. What’s a vehicle? What range works best? These are questions I think are better-suited to the game’s developer.
Do these issues happen with the PGS solver as well? On the physics team we’re working on fixing issues in PGS with the goal of removing the spring solver in the future. If something doesn’t work well with PGS after tuning let us know.
Do you have any un-coplylocked place for reproducing this? If it’s something simple like BodyMover property setters not waking bodies when PGS is disabled (it looks like this is the case) we can fix that.
So as a general statement for issues that happen in spring solver but don’t happen in PGS, our response is increasingly going to be “use PGS”.
We have to standardize on one physics solver - we just can’t maintain two solvers forever and fix bugs and make performance improvements and add features to both. Increasingly for us this means that we care a lot about PGS and don’t really care as much about spring solver.
In internal conversations, the term “spring solver” has long been replaced by “legacy solver”, which is an indication of that.
There has been a lot of ongoing work in terms of improving physics simulation - the feature work is probably more or less obvious (new constraints, new body movers, and some upcoming really exciting projects). In addition to that, we have two areas of focus:
Performance and memory improvements. There were quite a few changes shipped in the last 6 months or so that improve solver performance, particularly in cases where we have a lot of joints or a lot of contacts, and this work will continue. Additionally, we started a series of memory optimizations that focus on making sure physics components in the world take as little memory as they can - this applies to physical representation of parts, contact data, terrain and other things - and some of these require redesigns of internal data structures that does not apply to legacy solver.
Stability. We like how PGS solves solveable systems, but we don’t like how it behaves when there’s no solution. There’s been some changes that we have shipped recently that improve constraint resolution when you have collisions preventing solution for some systems with joints, and we are continuing investigation in these areas, focusing both on stability of local mechanisms and, increasingly, on instabilities resulting from distributed physics simulation.
Fundamentally, the end goal is to make sure that all games can transition to PGS. Currently we have ~70% of player-minutes over all of Roblox using PGS (that is, 70% of total play time in Roblox is in PGS-enabled games), and we intend to drive it closer to 100% and eventually officially deprecate (this should happen next year) and remove (no specific ETA, have to get better stability first) legacy solver.
Having said that, if there’s a trivial fix for this problem we won’t refuse to fix it just because the solver is legacy - but we will not spend large amounts of time looking for soluitions to problems in the legacy solver.
Now, separately - for sleeping bugs that do happen in PGS, please report them as separate threads. Sleeping system is designed to optimize performance without developer intervention; there are cases where it’s overly aggressive; there are cases where modifications of some properties don’t trigger wakeups; all of these are fixable and should be fixed if you report them as bugs.
