Release Notes for 488

Client Difference Log

API Changes

Added Class ScriptRefId : ScriptRef [NotCreatable] [NotReplicated]
Added Class ScriptRefPath : ScriptRef [NotCreatable] [NotReplicated]

Added Property bool Bone.IsCFrameDriven {RobloxScriptSecurity} [Hidden] [ReadOnly]
Added Property float Selection.SelectionThickness [ReadOnly]
Added Property bool Studio.Enable Script Analysis {RobloxScriptSecurity}
Added Property Color3 Studio.ScriptEditorMenuBorderColor {RobloxScriptSecurity} [Hidden] [NotReplicated]
Added Property float Studio.Selection Highlight Thickness {RobloxSecurity}

Added Function Dictionary AssetImportService:GetInstanceMap(string fileName) {RobloxScriptSecurity}
Added Function Instance AvatarImportService:ImportFBXAnimationUserMayChooseModel(Instance selectedRig, Function userChooseModelThenImportCB) {RobloxScriptSecurity} [Yields]
Added Function Instance AvatarImportService:ImportLoadedFBXAnimation(bool useFBXModel) {RobloxScriptSecurity} [Yields]
Added Function int DebuggerConnection:GetSource(Instance scriptRef, Function status) {RobloxScriptSecurity}
Added Function double Workspace:GetServerTimeNow()

Added EnumItem DebuggerStatus.InvalidArgument : 7
Added EnumItem StudioScriptEditorColorCategories.MenuBorder : 37
Added EnumItem WrapLayerDebugMode.OuterCage : 6

Changed the return-type of Function Player:GetNetworkPing from int to float

Removed Property Studio.Enable Linting

Removed Function AssetImportSettings:Import
Removed Function ScriptRef:Find
Removed Function ScriptRef:FindAll

(Click here for a syntax highlighted version!)


I’m really liking this addition:

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.



ps can someone dm me the docs for


Can’t wait for Brightness in more objects and a Squash property! Always enjoy having more features for visual enhancement.


What will Player/NetworkPing be used for in practice?

So this is basically the new version of tick()?
I guess it’s supposed to make *DO NOT USE* High precision clock syncing tech between clients and server with accuracy of <1ms obsolete


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.


I’m working on something right now that so needed this. My wishes have been answered! Can’t wait to see it live.


@tnavarts - in the Release Notes does link to “Do you want to purchase the domain” :slight_smile:



Something is off here but i can’t quite put my finger on it :thinking:

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?