Pausing Physics in Studio [Beta]

Updates Announcements
,
#47

Thank you for making pausing like how it used to be a long time ago. It can be super useful, so it is very much appreciated!

9 Likes
#48

i think the closest thing to this you could do is anchor the entire world, and then reset it back to how it was, although not sure how fast it would be as you need to loop through the entire workspace and anchor it, maybe you could use tag service to tag physical objects so you don’t waste time looping through static objects like the map and stuff.

8 Likes
#49

couldn’t this be done by just dividing the deltaTime used to step physics in the engine by a number we provide?, or is it more complicated than that.

7 Likes
#50

By “stepping physics”, I mean being able to control when physics updates occur on physically-simulated instances, and a way to specify how much time these updates should simulate.

What I have in mind is:

  • A property like ParticleEmitter.TimeScale for BasePart (perhaps BasePart.AssemblyPhysicsTimeScale), a runtime-writeable positive number that acts as a “multiplier” for that assembly’s physics updates.
    • With this, you would be able to specify any assembly to simulate twice as fast with a value of 2, or half as fast with a value of 0.5, or completely turn off its physics with a value of 0.
    • This property replicates to clients when set on the server
  • A method for BasePart (perhaps BasePart:StepAssemblyPhysics(deltaTime: number)) that simulates a physics update, and allows the user to specify over how much time that update should represent.
    • The deltaTime passed in is multiplied by BasePart.AssemblyPhysicsTimeScale inside the method. If the user wants to simulate an exact time, they can divide deltaTime by the property.
    • Using this along with AssemblyPhysicsTimeScale = 0, you can completely control how physics is simulated for this assembly.
    • This method essentially sets the positions and velocities of each part. Replication would be handled in the same way physics replications are usually handled.
    • Note: I’m not particularly sure if this method should affect parts that are anchored. I can see use cases for it, but they would be solved by un-anchoring the part before calling this method.
  • A Workspace property similar to BasePart.AssemblyPhysicsTimeScale (perhaps Workspace.PhysicsTimeScale), which provides control over the entire world’s physics.
    • BaseParts are simulated at the speed of their assembly’s AssemblyPhysicsTimeScale property, multiplied by Workspace.PhysicsTimeScale.
  • A Workspace method similar to BasePart:StepAssemblyPhysics (perhaps Workspace:StepPhysics(deltaTime: number)) that simulates a physics update for the entire world.
    • Does not step physics for anchored assemblies (if those exist).

I don’t want to overstep this suggestion, but if possible, it would unlock even more use cases if the Workspace methods suggested above could be extended to WorldModels.

I believe some large use cases would be:

  • Setting workspace.PhysicsTimeScale (e.g. to 0.5) to slow down the entire world, like it’s done in this gem: Glass - Roblox
    • Setting the AssemblyPhysicsTimeScale of the player’s character (e.g. to 2) to make the character move normally in a slowed-down world
  • Setting AssemblyPhysicsTimeScale to slow down or stop player characters within a set distance, for a time-stop ability
    • Bonus points if we can tween the property to slow down time smoothly, instead of stopping it immediately
  • Setting AssemblyPhysicsTimeScale to 0 to “turn off” physics, while keeping collision detection (Touched events)
    • Simplifies the implementation of custom character controllers. We wouldn’t have to fight Roblox when making our own platformer character physics (or resort to anchoring the character and running collision detection ourselves)
    • Simulating particles that explode when touched with custom physics
  • Using the potential WorldModel:StepPhysics method on a WorldModel inside a ViewportFrame to simulate 3D confetti in a victory screen UI
    • Could also be done with BasePart:StepAssemblyPhysics if the WorldModel contains some parts that should not be physically simulated
  • An ability in a PvP combat game that creates “impact frames” which pause the world around the attacker and victim briefly, to intensify the power of the attack.

Notes:

  • I don’t believe being able to set a PhysicsTimeScale for individual parts (as opposed to entire assemblies) would be very useful (what would happen to a welded part simulated at half the time scale of its welded parts?). If anyone has ideas where that could be useful, please don’t hesitate to reply!
  • Since we can already control animation time stepping, I don’t believe it’s necessary to make this feature control animations. Users can account for properly scaling animation speeds in their animation handling code. However, I’d definitely love to see if anyone has ideas on how this could be automated alongside the physics APIs suggested above!
18 Likes
#51

Absolutely astonishing update by Roblox here.
However it would be nice if you could change time scale in real time.:confused:

It would honestly benefit the community in such a positive way and I personally see no problem/reason not to integrate it in the future.
https://devforum.roblox.com/t/pausing-physics-in-studio-beta/2925013/30?u=basedmannn

5 Likes
#52

I think this update, or something related to it is causing issues with Humanoids. I don’t know for sure, but I used to never get any reports about humanoids being flung in my game, but suddenly today I’ve been getting tons of reports about it despite not changing anything in my game for a month or so.

6 Likes
Pausing Physics update causing Characters to Fling in game(s)
#53

Pretty sure this update will not affect anything in a real game, even if it did beta features only work in studio so it wouldn’t affect your game until it comes out of beta.

8 Likes
#54

It seems that breakpoints still pause rendering. Is this intentional, and is there anything I can do about it?

7 Likes
#55

yes please add a timescale property to workspace. unity has had a feature like that for years. Unity - Scripting API: Time.timeScale
just make a workspace.TimeScale where 0 is stop time, 1 is full speed and 0.5 is half speed.
i needed something like this working on a superhot style game in the past.

8 Likes
#56

Nice! That seems like a promising update, I wonder when you guys are gonna release it to real games…

Is that update finally good?

  • Yes
  • No

0 voters

4 Likes
#57

Can i pause the physics using script in future?

1 Like
#58

pausing physics in realtime games when?

actually no, scrap that, can we have a whole physics slowmotion :fire::fire:

5 Likes
#59

if Roblox is planning to add new features for in-game physics, I would like you to consider the need for rollbacks.

a major concern for many developers wanting to make competitive games is implementing server authoritative characters, and current solutions rely on custom physics because we have no way of doing this with our current api (e.g. Chickynoid).

2 Likes
#60

great update the pause simulation will be fast by fixing physics in the object property and also scripts.

3 Likes
#61

Awesome! Now we can pause physics :-o
This will be helpful!

2 Likes
#62

I should use it for my game paralleized engineers it’s a sci-fi game so it’s cool if I can implement this to freeze the time including break NPC animations with the aerodynamic and wind if it’s fully frozen the time should be frozen but not all script and NPCs it’s a cool thing to implement but where ??? I’m not telling

2 Likes
#63

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
#64

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

2 Likes
#65

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
#66

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