Client Difference Log
API Changes
Added Property bool BasePart.CanTouch
Added Property bool Workspace.TouchesUseCollisionGroups [NotScriptable]
Added Function Array AvatarEditorService:GetBatchItemDetails(Array itemIds, Enum<AvatarItemType> itemType) [Yields]
Added Function Tuple HeightmapImporterService:GetHeightmapPreviewAsync(Content heightmapAssetId) {RobloxScriptSecurity} [Yields]
Changed the parameters of Function GlobalDataStore:IncrementAsync
from: (string key, int delta = 1)
to: (string key, int delta = 1, Array userids = {}, Instance options = nil)
Changed the parameters of Function GlobalDataStore:SetAsync
from: (string key, Variant value, Variant userids, Instance options = nil)
to: (string key, Variant value, Array userids = {}, Instance options = nil)
Changed the parameters of Function Plugin:PauseSound
from: (Instance soundChannel)
to: (Instance sound)
Changed the parameters of Function Plugin:PlaySound
from: (Instance soundChannel, double normalizedTimePosition = 0)
to: (Instance sound, double normalizedTimePosition = 0)
Changed the parameters of Function Plugin:ResumeSound
from: (Instance soundChannel)
to: (Instance sound)
Changed the security of Function AvatarEditorService:CheckApplyDefaultClothing
from: {RobloxScriptSecurity}
to: {None}
Removed Function HeightmapImporterService:GetGreyscale
(Click here for a syntax highlighted version!)
Wow, I’m certainly excited about this:
It’s great being able to filter which parts can excite the Touched event of colliding parts, but a bigger issue is the Touched event firing repeatedly even when the part moves while keeping contact with the listener part. This spams the function and forces developers to almost always include a debounce, which is inconvenient to do each and every time. Ideally, it’d be great if the event only fires upon the start of the contact.
Also, here’s a question: what if you enable CanTouch while it’s touching a listener part? Will it fire the event immediately or until it moves/retouches?
You shouldn’t rely on the engine to do the debounce for you, that behavior can change over time. It may not account network if it is involved, such as object owned by players and the latency involved.
I assume these events happen during a physics step, so the next time it moves. You can create a microprofiler tag and see exactly at which part it was fired.
Alright, speculation time.
This release mentions a new properties widget, which likely indicates to an upcoming beta. Roughly two years ago, a Roblox staff member commented that attributes were delayed because they did not want to add them without making sure they could be edited in-studio, which they mentioned would require a significant re-write of the properties widget.
I deduce, my dear watson, that attributes are coming.
I believe the issue addressed by this property is more geared towards reducing the amount of times the .Touched event can fire, as developers often shied away from using it due to the inherent lag caused by a high amount of moving parts coming in contact with the listener.
Should CanTouch instead be a feature of collision groups? It seems redundant to have CanTouch, CanCollide, and CollisionGroup when they could all be represented meaningfully via just CollisionGroup. Alternatively there could be a BindToTouched method of some kind, that allows for fast filtering.
I also wish for my non-collide parts to automatically be ignored from raycasting, and it seems like bloat to have a property for that too. I’m currently putting CanCollide=true and CanCollide=false in separate folders so I can ignore them. Looks like I misunderstood RaycastParams.CollisionGroup.
I fear it may be slightly late for that kind of feedback, but I definitely agree with you there. It would be cumbersome at best to manage this property for all parts, and CollisionGroups would provide an existing, useful way to aggregate them.
Certainly this is the purpose of having a mutable RaycastParams object. I’d love to see this as an option, but I am vehemently against changing default behavior, especially when there is a better way.
That’s unfortunate. Parts are the most common instance type in almost every game, so it’s very important that they are lightweight. It would also be more efficient for our scripts to only need to set a single property. Collision groups are already a feature used by the physics system and seems like it would be an intuitive alternative.
To be honest RaycastParams is pretty much useless to me because you can only specify a single collision group. A single collision group filter isn’t useful once you start to have complex collision group interactions.
This update broke my game.
Basically you are setting my tools enabled to false when they are equipped.
This happens sporadically but only started happening hours ago, we havn’t updated the game since last year.
Game Link: Empty Baseplate - Roblox
Update: Now i’ve made so guns wont disappear even if they are disabled. But guns are never disabled ingame by any of my scripts.
You should file a bug report with repro file – this is in Release Notes and won’t be seen by the right engineers here.
I am curious… Does disabling CanTouch for moving objects improve performance at all? What about static ones? Or non collidable ones? And what about when the game has a lot of parts?
My game has hundreds of thousands of parts in it made by my terrain generator and I am wondering if I were to disable CanTouch for these objects (which I never need to use .Touched for) if I would see any server-side or client-side performance benefit.
Also… New properties widget?
I think I missed something…
When i saw the flag I thought they were making a Lua properties window, which was instantly debunked by the fact that Roblox has a few properties that can’t be interfaced by Lua, such as
- HttpService.HttpEnabled (but there is a RobloxScriptSecurity method for accessing this?)
- LoadStringEnabled
- MeshID
(and also the fact there’s no builtins related to properties)
I’m with you on that I think it’s just something that would allow them to include the Attributes editor.
HttpService.HttpEnabled works for me in command bar
print(game:GetService"HttpService".HttpEnabled)
Roblox can likely add some sort of studio-only interface to update these properties if they wanted to.
HttpEnabled as well as some other stuff is updated from the Game Settings Widget which is lua iirc.
Or, they can create a new script context like plugin that’s studio only which allows those properties to be updated.
There are probably other ways that are better that I’m just not thinking of…
So, I wouldn’t say that idea is completely debunked. It depends on what Roblox thinks is best and ultimately decides to do.
GameSettings uses these two functions to read and change the state of HttpEnabled, so I see where you’re coming from.
And yes, I’ve never understood why BuiltIns don’t have the LocalUserSecurity permission.
EDIT: See this post
I think it’s a side effect of how the permission level bits are set for the ElevatedStudioPlugin identity level. Just a bunch of weird legacy gimmicks for the most part.
I would be surprised if Roblox does not have the ability to publish the built-in plugins at a RobloxScript permission level / using CoreScripts, which would make your conclusion defunct.
I’m mostly worried about property bloat on BaseParts. It may seem great to add more features, but it’s just important to stay minimal with this instance type whenever possible.