But, I believe the API should allow plugins to modify the selection box thickness as well. The most useful case I see with this is a small plugin to toggle selection box (setting thickness to 0 for hiding it) for objects just for lining up corners or other precise manipulations. Of course, the plugin can regard that as a plugin action, meaning the user can set a keyboard shortcut for it as well, thus allowing for instant selection box toggling. Also, even if malicious plugins do abuse this, it’s a relatively minor damage compared to the sheer flexibility it provides. Besides, there should be a thickness limit anyways, so plugins can’t set absurd values.
Glad this is natively supported now. This was an utterly annoying issue to deal with. Seeing my entire workspace hierarchy open up because of an accidental deletion caused me unnecessary headaches in trying to collapse everything again and only pick out what I actively needed to see.
I am planning to make the fields on DraggerService / Selection support temporary overrides from a plugin via writing to them (in addition to making Selection available in live games to support good interop between in game content creation tools). Though some additional infrastructure that hasn’t been built yet is needed to make that happen and I wanted to get the setting out to developers as soon as possible rather than waiting for everything DraggerService / Selection related to come together.
Small correction, the Release Note description here is out of date. This was changed to a method Player:GetNetworkPing() which returns a float number of seconds instead and updating the Release Note info seems to have been missed.
At the most basic level, you could implement a ping display in your game. Beyond that, if you’re writing non-trivial networking code for your game then the value is very useful for calculating interpolation / extrapolation of movement / other timing sensitive things.
You could previously infer the ping value yourself, but doing so correctly was quite difficult: The obvious approach (simply timing how long an empty Remote invocation round trip takes) gives a significantly wrong value due to the way RemoteFunction / RemoteEvent batching works.
Exactly, it’s the official API for precise client / server synchronization.
Big fan of temporary overrides for plugins to take advantage of. It would be cool if that could be extended to the majority of Studio’s settings, I am currently changing the edit quality for StudioTweaks to take advantage of special rendering behavior, but I can also see benefit from being able to override many other settings.
I’m super happy to finally be able to delete this feature from StudioTweaks. Does this behave the same for redo as well? I forgot to handle this case in my plugin.
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.
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.
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.
