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.
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.
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.
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.
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.
And no, it cant access LoadStringEnabled, it’s not even a key of the userdata by the looks of it (or there’s some metatable blocking code idk?)
But yes, Roblox can easily just either add an interface method to those properties that aren’t seen by Lua, or just add them to Lua with RobloxScriptSecurity or LocalUserSecurity permission, so a Lua window could still happen
That is a very good point. I would bet this is likely a focus of the new properties widget as well, probably to make editing properties easier even with a lot of them. I am starting to become less concerned with property bloat personally as I prefer function over cleanness in that case, and I think perhaps that may be where Roblox is trying to head.
The biggest problem with that I think is that the solution to property bloat has always been inconsistent, and probably will remain that way unless a much more general solution is created, and I think if it is Roblox’s goal to allow for more properties on things without causing issues, they’ll probably start with that on the property widget.
Not sure what you mean by “doesn’t exist according to Lua” (Lua is a programming language), but TweenService generates error messages for properties not accessible from scripts.
