Release Notes for 466

Notes for Release 466


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 :eyes:, here is a preview of it (cc @CloneTrooper1019):

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:


Thank you. This was driving me mad.


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. :stuck_out_tongue: 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.