Why
4 Likes
This is a cool feature, but misses the mark for me. Limiting pause to physics only isnât something I really care about, and at the same time has substantial downsides limiting its use in my projects which often involve interrelated state and pipelines of work that needs to happen at certain times during the frame for better performance, game polish (no jittering or teleporting or other weird behavior, plus bug fixes), and code simplicity. I am wary of using this feature because suddenly having one part of the gameâs pipeline disappear will start breaking things and putting them in conditions they were not designed or tested for.
I would find it a lot more useful to have a way to pause everything in the game (all code execution, signals, etc.), while still having basic engine-level rendering (and perhaps execution of plugins and command bar). And just some kind of free cam so we can move around and look at things from different perspectives (resetting when resumed). This would be more deterministic and would have less of a meaningful impact on the state of the gameâŚ
If allowed when paused, things like property changes would have to be buffered up and sent to the game when normal execution is resumed. This would as a side effect greatly enhance the utility of the pause feature, because we could easily manually recreate (by hand, using the command bar, or plugins) certain conditions which ordinarily would need to be performed by pre-written code. It would make debugging such things a lot easier because we could just reproduce the bugs from hand instead of having to do lots of weird gameplay stuff to trigger them. For example, deletion and/or replacement of instances in the hierarchy as if they were changes replicated from the server.
Either way, I find it really weird that you guys seem to consistently avoid making Studio features which are light-handed and more on the deterministic side, and instead go for approaches which are very likely to break things which are not designed in a super defensive way like âletâs do gymnastics to avoid using engine features naively except for these very specific things which we have observed behave consistently in all situationsâ.
A couple of other examples include:
- Script debugging has a problem where for some reason if you have paused on a breakpoint in a RenderStepped callback, the same callback will still be executed for future frames, interrupting the execution of the callback you are currently stepping, which is just completely different from the runtime behavior of the engine and mega confusing for the programmer trying to debug their code.
- Getting RenderStepped callbacks in plugins (because listening to the signal directly only works when the main viewport is being rendered, which is not the case when editing scripts or looking at diffs or whatever). At the moment the only way I know how to do this is by manually triggering layout updates on Heartbeat or another reliable signal, and connecting to property changes which are dependent on the layout, like AbsolutePosition, the callbacks of which will be executed in the rendering portion of the frame.
Anyway if you guys plan on having proper support for full pausing in the future w/ rendering, free cam, property changes, etc. then Iâm happy.
7 Likes
Not sure if this was recently added or if it has existed since some time ago, but i just discovered that theres a new âStepPhysicsâ event in the documentation
Could this possibly mean that we are going to be given time scaling control soon? 
5 Likes
Awesome feature, Iâve also noticed the new inclusion of the StepPhysics method in documentation.
Will this be a studio-only feature, or should we anticipate being able to use PausePhysics and StepPhysics in local or server context.
Thanks a ton!
Hi Aiden,
For now, this will only be available in Studio. We have heard the communityâs request to enable this on Client/Server, so we will continue to investigate whether this is feasible. Thanks for the question!
Best,
M0bsterlobster
1 Like
Thanks a ton for the quick response!
The reason why this feature is so desirable at the moment, is it gives us developers a way to have pseudo-determinism using Robloxâs default humanoids. At the moment, if you want to create server-authoritative movement methods on Roblox, youâll have to use your own form of movement (such as linear movement using vectors) or creating your own physics that you can snapshot (such as Chickynoid)
Being able to step physics and reliably track how far a player will move in a frame would be an incredibly powerful tool.
I wish you the best, hopefully we can see this be implemented in a full capacity.
2 Likes
This is very late reply, but these are very flawed methods of doing things. You just run with a smaller delta time than the real physics frame time.
âDecrease the distance objects are moved each step so that when ran at very low speed the simulation doesnât look choppy.â Is what you are saying here I just worded it differently.
Explanation.
The delta time here is essentially just a multiplier to the studs per second of the object: if the studs per second is 1 and delta time is 0.016 then the object moves 0.016 studs per step of the simulation so decreasing the distance moved each simulation step is the same as decreasing the delta time.
I said it that way because it accounts for acceleration as well. For example, with a spring, if you only scaled the velocity, it wouldnât be accurate nor the same as if there was no time scaling.
Ah I see thanks for pointing that out I will add a correction.