Client Difference Log
API Changes
Added Class CalloutService : Instance [NotCreatable] [Service] [NotReplicated]
Added Function void CalloutService:AttachCallout(string definitionId, string locationId, Instance target) {RobloxScriptSecurity}
Added Function void CalloutService:DefineCallout(string definitionId, string title, string description, string learnMoreURL) {RobloxScriptSecurity}
Added Function void CalloutService:DetachCalloutsByDefinitionId(string definitionId) {RobloxScriptSecurity}
Added Class UIStroke : UIComponent
Added Property Enum<ApplyStrokeMode> UIStroke.ApplyStrokeMode
Added Property Color3 UIStroke.Color
Added Property Enum<LineJoinMode> UIStroke.LineJoinMode
Added Property float UIStroke.Thickness
Added Property float UIStroke.Transparency
Added Property bool UIStroke.Enabled
Added Property bool Studio.Physical Draggers Select Scope By Default {RobloxScriptSecurity}
Added Property Enum<TerrainAcquisitionMethod> Terrain.LastUsedModificationMethod {RobloxScriptSecurity} [Hidden] [NotReplicated]
Added Property Enum<MeshPartHeadsAndAccessories> Workspace.MeshPartHeadsAndAccessories [NotScriptable]
Added Function void AppUpdateService:DisableDUAR() {RobloxScriptSecurity}
Added Function void Workspace:SetMeshPartHeadsAndAccessories(Enum<MeshPartHeadsAndAccessories> value) {RobloxScriptSecurity}
Added Event RunService.PostSimulation(double deltaTime)
Added Event RunService.PreAnimation(double deltaTime)
Added Event RunService.PreRender(double deltaTime)
Added Event RunService.PreSimulation(double deltaTime)
Added Enum ApplyStrokeMode
Added EnumItem ApplyStrokeMode.Contextual : 0
Added EnumItem ApplyStrokeMode.Border : 1
Added Enum LineJoinMode
Added EnumItem LineJoinMode.Round : 0
Added EnumItem LineJoinMode.Bevel : 1
Added EnumItem LineJoinMode.Miter : 2
Added Enum MeshPartHeadsAndAccessories
Added EnumItem MeshPartHeadsAndAccessories.Default : 0
Added EnumItem MeshPartHeadsAndAccessories.Disabled : 1
Added EnumItem MeshPartHeadsAndAccessories.Enabled : 2
Added Enum TerrainAcquisitionMethod
Added EnumItem TerrainAcquisitionMethod.None : 0
Added EnumItem TerrainAcquisitionMethod.Legacy : 1
Added EnumItem TerrainAcquisitionMethod.Template : 2
Added EnumItem TerrainAcquisitionMethod.Generate : 3
Added EnumItem TerrainAcquisitionMethod.Import : 4
Added EnumItem TerrainAcquisitionMethod.Convert : 5
Added EnumItem TerrainAcquisitionMethod.EditAddTool : 6
Added EnumItem TerrainAcquisitionMethod.EditSeaLevelTool : 7
Added EnumItem TerrainAcquisitionMethod.EditReplaceTool : 8
Added EnumItem TerrainAcquisitionMethod.RegionFillTool : 9
Added EnumItem TerrainAcquisitionMethod.RegionPasteTool : 10
Added EnumItem TerrainAcquisitionMethod.Other : 11
Added Tag [Deprecated] to Event RunService.Heartbeat
Added Tag [Deprecated] to Event RunService.RenderStepped
Added Tag [Deprecated] to Event RunService.Stepped
Changed the parameters of Event RunService.Heartbeat
from: (double step)
to: (double deltaTime)
Changed the parameters of Event RunService.RenderStepped
from: (double step)
to: (double deltaTime)
Changed the parameters of Event RunService.Stepped
from: (double time, double step)
to: (double time, double deltaTime)
Removed Property TextBox.Content
Removed Property TextButton.Content
Removed Property TextLabel.Content
Removed Property Workspace.MeshPartHeads
Removed Function Workspace:SetMeshPartHeads
Removed Enum MeshPartHeads
Removed EnumItem MeshPartHeads.Default
Removed EnumItem MeshPartHeads.Disabled
Removed EnumItem MeshPartHeads.Enabled
(Click here for a syntax highlighted version!)
Loving that the RunService events got name upgrades to be more representative of when they’re running. RenderStepped, Stepped and Heartbeat were not really telling of this and you don’t really know until you read the documentation (which not a lot of developers do).
That reminds me: staff shared a diagram on Twitter showing the execution order of these events, including the new one PreAnimation, which helps show what happens when. With a diagram update already on hand, it’ll be very easy to switch to the new names and make use of the new event as well.
I thought this was reviewed and changed after developer complaints on the announcement thread. Is “Content” only how it appears on the Release Notes because of the way they’re generated and is the actual property different, or has there been no real change to the property name?
Regarding UIStroke, if anyone wants a sneak-peek 
, here is a preview of it (cc @Maximum_ADHD):
However, what is the function of ApplyStrokeMode (as I was unable to see a difference between Contextual and Border in the video above)?
Also, will UIStroke work for text and have the TextStrokeTransparency/Color3 deprecated? It seems in the video that that that border is definitely more than 1 px thick!
An amazing addition to UIStroke would be the support to wrap around the alpha of transparent images, which would allow a game’s group logo to be decoratively bordered, for example. Another one includes support for gradient colors, although I don’t see a streamlined way of doing this (adding a UIGradient object under UIStroke–that’d be too much).
It looks like it did end up being removed:
I’m so confused by this. Virus scripts may not work but, we can re-enable them? Why would we want to re-enable something persistently annoying to deal with in the first place?
My guess is they block scripts from running when their bytecode/hash matches certain values which allows them to block popular virus scripts in the Library, and in case this ends up being a problem for any developer you can just modify it a bit to get around it. I’m guessing they’ll announce more once it goes live.
To add, if they can detect these scripts and prevent them from running, it’s also likely possible to point them out in Studio for developers to remove. Really happy to finally see something done about this.
The fact that it showed up in the release notes again is a procedure bug with how the release notes are handled. TL;DR: The revert just ended up with the same release notes as the original change.
If you can get around it, that doesn’t stop people from updating virus scripts which brings you back to square one. Hoping there’s a more grandeur focus around this that hasn’t been disclosed yet.
It’s likely mostly an attempt to prevent spreadable malicious code in toolbox assets from crushing new developers, especially in old toolbox assets that haven’t been updated in half a decade but still hold strong positions in search results. It’s a bandage for a problem that has existed for too long with no easy solution. We should be appreciating this attempt to mitigate this, it’s obviously not desirable for Roblox to just keep doing nothing about the issue for another five years waiting on a Perfect Solution.
Removing the said items also work. If it’s malicious, I don’t see the point of having it remain in view on a public toolbox used in production. Especially when visibility to said items seems to be high (?).
Majority of these issues arise / stem from the lack of care after years of being postponed or essentially forgotten about. As a developer or as a long time user, most decisions on this platform seem to stem from “bandage-like” solutions.
While I’d hope that most of us appreciate this/Roblox/people who worked on said thing(s), I feel like we forget about the years of perpetually asking for this to be fixed. And as the years went by, the library got more saturated with malicious code w/o any tangible safeguards in place.
The only real way that I personally see for this to be corrected is to do a deep clean of malicious code: i.e search every item in the toolbox (wherever it’s stored/pulled from), remove it from view or even delete it (spooky word on this platform lol) and put actual safeguards in-place that will prevent this from happening again. This is a pretty radical move (even in terms of theory) but, like you said, this a complex issue that needs to be handled. However, perhaps, a radical one may work.
This doesn’t just pertain for toolbox. Nearly everything that is accessible by users, published by users and can be search show similar symptoms which as a user or a person trying to “make it” on the platform can be incredibly challenging. i.e The saturation of stolen clothing items from clothing designers, etc.
But yeah, I do agree.
I don’t really feel that deleting or removing content from the toolbox is necessary or a good idea, there is room for that to go wrong. I am, however, a huge fan of this change because it means that old games using malicious code like this won’t be nearly as laggy (I hope).
I think that a good solution is to have a prompt, similar to what you get when you insert a tool. Roblox can pull from a list of “blacklisted” script sources (or hashes of bytecode/source, which, would be easy to store in fast flags), and prompt the user when they insert something, asking them to remove it.
The prompt could simply say, for example, something like “This model has malicious or misleading code in it. Remove the content from the model?”
Additionally, perhaps the prompt could have a third option to insert the model without removing content but select and disable the scripts which would show them in the explorer without allowing them to run by default.
This would be an excellent solution to this issue in my opinion as it would be cheap in terms of development cost, would inform the user about the code being removed, but would not inhibit any use or viewing of the content and would be non intrusive. On top of that, malicious scripts aren’t able to as easily say, for example, ask the user to insert something into the script to stop it from getting blocked.
In the future, this could be extended to rely on all kinds of methods to filter out malicious code, and is extendable, meaning if changes need to be made, they can be made without any unexpected impact to games. (Which would be incredibly rare, but accidents happen)
Not sure if you read the release note or not but it clearly says “really old” scripts, so e.g. ancient “fire antivirus” scripts. I assume they’re meant to make any old models in the library safer again to insert, not to counter new models with virus scripts.
Just because they’re pushing out 1 change doesn’t mean that’s all they’re doing to solve a particular problem, don’t be that guy. 
It’s just 1 release note.
I just appreciate that anything is being done at all so why complain.
Does anyone have an idea of when the new RunService events will work? I see them in studio’s autocomplete today but they don’t seem to fire.
what is the function of
ApplyStrokeMode(as I was unable to see a difference between Contextual and Border in the video above)?
ApplyStrokeMode would switch whether it is adding stroke for text or adding border to the frame if it gets parented under a text object, as we consider there are needs for each of them.
Also, will UIStroke work for text and have the TextStrokeTransparency/Color3 deprecated? It seems in the video that that that border is definitely more than 1 px thick!
Those properties will not get deprecated. It will get overriden if you parent a UIStroke to apply textstrokes, which will allow thickness greater than 1px.
Another one includes support for gradient colors
We support adding gradient to strokes by parenting gradient under a stroke object. We will give more detailed explanation when announcing the beta.
What is the status of these events? After three months these new events still don’t work, and the old events had their Deprecated tag removed.
Iirc the deprecated status was removed because the new events weren’t actually enabled when they got deprecated.
Not sure why they haven’t been enabled yet but it probably has to do with the release process, probably around testing. I’ve noticed some features seem to sit around in the engine for quite a while before they release (without any changes seemingly though I’m sure there are occasionally internal changes).
The same thing happened with Attributes, which, interestingly upon release “don’t support” certain value types like CFrame, Region3, arrays, dictionaries, etc despite previously supporting these prior to release, which, I would assume is probably where the hold up was. Perhaps there is a stability or security concern around some of those complex value types as they do seem to be pretty close to their format in memory. (I hope these get readded because it makes most of my use cases for attributes useless)
There might be some concern around these new events for some reason, or maybe they’re just low priority and nobody has had a chance to test and approve them.