Pausing Physics in Studio [Beta]

This truly would be ace for mega special moves, pause all screen action and rotate the camera around Matrix-stylee. A bit like when your mag fired back in those heady Dreamcast days playing Phantasy Star Online.

1 Like

AWESOME, now i can pause physics during the run without struggling

2 Likes

Oh, so really this is just re-enabling a feature from 2013 studio. Okay.

For the ones that don’t know this was a feature prior to 2014 studio but they long disabled it awhile ago, so this is nothing new.

But at least it’s nice to see that it’s back again which should’ve never gotten disabled in the first place.

3 Likes

I think if you weld 2 parts together simulated at different time speeds that all welded parts will simply follow the time scale of the dominant basepart until the welds are broken.

Another way I could imagine this is being able to set time scale for models instead of parts.
Setting it for every part would be awesome but I can only see it being useful for a few things.

Setting time scale per model would be useful for large-scale games where slow-motion or time-stopping is localized to only an area in the game.

I do think animations and particles should be synced with the time scale though because otherwise some people might have to go through and edit 100s of scripts to add in extra lines of code that slow down animation tracks.

And I for instance, I already manipulate the playback speed of animations in my projects, having to add extra code to take into account time-scale of physics would be a lot of tedious work.

4 Likes

It always annoyed my while doing physics-based projects that pausing the game for debugging stopped rendering. Finally it’s SO MUCH EASIER!

3 Likes

I think a cool way we could implement this is like when you die in a fighting game, your client simulation will be in slow motion for a more dramatic effect. Or, in a story game you are falling down a hole, and want to also make it dramatic! Plenty of ways we could implement this and I think I’d use it myself!

1 Like

Absolutely, the engine would have to decide the time scale for an assembly somehow. This sounds like a good way to do it.

I suggested the property existing on BaseParts because other assembly-specific properties, such as AssemblyLinearVelocity, are accessible on BaseParts too. It’d also be nice to set this on a single part instead of having to create another Model instance for time-scaling functionality (which I believe would be somewhat indirect and would require creating more instances for use cases such as projectiles, which could get pretty expensive)

Considering codebases that don’t account for this feature, it would be amazing if there was an easy way to make this work with animations. There also exist other instances that could benefit from runtime-writeable time scale, imagine Beam.TextureSpeed and Trail.Lifetime being affected by this property!
However, as much as I’d like a solution that “just works”, I don’t know how this could be implemented or how to structure the API in a useful way, which is why I limited my suggestion to physics-related functionality.
Perhaps in addition to the BasePart properties/methods I suggested, there could be a more general Instance.TimeScale property controlling how much “time affects them”, as well as an Instance:Step(deltaTime: number) method similar to the others suggested. That definitely sounds way easier said than implemented, of course :sweat_smile:

3 Likes

Having absolute control over time and stepping would be super useful I think.
Physics can sometimes be quite expensive, especially with many objects.

Would be cool if I could literally just pause physics simulation manually when I’m 100% certain that something will not be moving any time soon.
I know objects sleep when not moving but it’s not perfect detection and sometimes also results in objects not moving when hit by something else.

I know the anchored property exists for this but anchoring stuff also causes them to lose all momentum and energy information.

Something I’d also love to see is being able to call physics stepping methods from a different thread in Parallel Luau to have multi-threaded physics in physics-intensive games.

And… being able to turn off physics replication would also be a nice-to-have so I can implement my own replication methods which are a lot more optimized and use way less data because I know exactly what data I need and what to discard.

3 Likes

now let us pause time in real life :fire: :fire: :fire:

4 Likes

For the record, physics doesn’t simulate on anchored parts, but they do keep their velocity and angular velocity. These are stored in AssemblyLinearVelocity and AssemblyAngularVelocity. Anchoring a part affected by physics, and then un-anchoring it later will cause it to continue moving as it had been before it was anchored.

I definitely agree. Having complete control over the way instances are simulated would allow for huge optimizations!

4 Likes

No, deltaTime is a read only parameter, if I’m correct. It only shows you how long ago the previous frame was, it isn’t able to manipulate anything.

1 Like

I meant the internal delta time the physics engine uses, of course not the one you can read through run service silly!

Ohh, my bad

Character limit sucks.

2 Likes

Hello,

Curious if anything was pushed to live servers? As of very recently, our popular game Super League Soccer with over 10K CCU has been experiencing issues regarding ball physics. More specifically balls losing, gaining, or maintaining velocity when they shouldn’t. No new versions of the game have been published since the 18th of March. This means nothing on our end has changed. This is a very new occurrence- within the past day or so.

Please feel free shoot me a DM or reply and I can provide more details if needed.

1 Like

Incredible work! This was a much-needed update!

Wondering when we’re gonna get something like timescale in Unity

i cant wait to see paused planes

1 Like

This reminds me of Create and Valkryien Skies Clockwork with the ability to infuse physics… by the way… how did Roblox make those two fans one on the client and one on the server?

yay im so glad to see this happen, this helps alott :slight_smile:

1 Like

One of them is network ownership on the client, the second one is network ownership on the server

3 Likes