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.
AWESOME, now i can pause physics during the run without struggling
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.
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.
It always annoyed my while doing physics-based projects that pausing the game for debugging stopped rendering. Finally itâs SO MUCH EASIER!
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!
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 BasePart
s because other assembly-specific properties, such as AssemblyLinearVelocity
, are accessible on BasePart
s 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
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.
now let us pause time in real life
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!
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.
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.
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.
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
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
One of them is network ownership on the client, the second one is network ownership on the server