Yes, though it’s relevant for Redo much more rarely so I didn’t bother mentioning it in the release note. Implementation wise the new code applies to any Undo/Redo which ends up creating Instances, which is a delete in the case of Undo or an object creation / insertion in the case of Redo.
When it comes to preventing a frantic tree expansion that can take 5 minutes or more to finish, covering all of the cases is very important lol. This was also difficult to implement from the plugin side because folders had different reselection behavior from models post-history-navigation. So that’s really good to hear.
I’m working on something right now that so needed this. My wishes have been answered! Can’t wait to see it live.
@tnavarts - debug.info in the Release Notes does link to “Do you want to purchase the domain debug.info?”
Something is off here but i can’t quite put my finger on it
Lol, in all seriousness I love that this exists now, thanks!
Does that mean that UDP-like-Remotes are finally on the horizon?
The current remote events kinda suck for doing this type of stuff as every time packetloss occurs you get a significant pingspike due to remotes forcibly being processed in the exact same order you fire them.
The fact that this took years is a bit sad, but at least it’s becoming a new change.
GetNetworkPing
, and GetServerTimeNow
are functions I am looking forward to game and studio production, precision is key.
Back from 477, FindFirstDescendant
was added, is there a specific timepoint this year where it’ll be enabled for production?
Generally one-off API additions like this that just a single engineer worked on on their own get turned on 2-3 weeks after they appear in the API dump, when the engineer has time after the relevant mobile force update has happened.
GetServerTimeNow
is network agnostic correct? My current implementation uses RemoteEvents, ratcheting if the new report is lower, to get the ServerTimeNow+LowestLatency configuration. I expect now I could just do GetServerTimeNow - LowestLatency; the Latency from GetNetworkPing.
At a given moment in time, GetServerTimeNow
will return exactly the same thing on the server and each client – it accounts for the network latency for you in making that happen. It’s also “smooth”: When it detects any amount of drift, it will slightly speed up or slow down the progression of the time returned to restore the synchronization so that you don’t see any sudden changes in the value returned.
So… if I were playing from the international space station, would it account for relativistic effects?
It’s likely to assume the clocks tick at the same rate, and as packets come in, it’ll try to catch up (late and smoothly). It can predict with some error, the latency involved for the packet to travel across the network assuming the time it takes to travel both ways are the same, but not really to predict relativistic effects, different network paths, slower paths or time drift due to the clock technology’s precision.
Unfortunately we’ll have to leave that for version 2
Is this going to be changed to use seconds like you mentioned Player:GetNetworkPing()
was changed to, or, is the precision actually high enough that using floats would end up having a negative impact on precision that people might not want?
Uhh… yikes. Might have to wait a bit longer on that API being turned on. It was indeed intended to return seconds.
Had a chance to look at the behavior of this and I’m noticing it always selects the workspace, even if I’m undoing something I deleted that was deeply nested, which is definitely not the top level restored instance. Wanted to mention since it seems unintentional.
Got repro steps? It works correctly for me. Also maybe one of your plugins is conflicting with the behavior, have you tried with plugins disabled?
It was happening with StudioTweaks, I dissected it and narrowed it down to this, which cause the issue to happen with all plugins disabled:
- Make this
- Run this in the command bar
game:GetService("PhysicsService"):CreateCollisionGroup("Test")
-
Delete the highlighted model
-
Ctrl Z to undo, the workspace will be selected.
This no longer happens if you add game:GetService("ChangeHistoryService"):SetWaypoint("Created collision group")
after creating the collision group (or modifying it with CollisionGroupSetCollidable). The issue happens because the collision group is removed as part of the undo operation.
Having undo remove the collision group is fine and my plugin accounts for that if it’s missing at any point, and I can patch this in my plugin by setting a waypoint, but it’s still strange that this somehow interferes with setting the Selection.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.