Release Notes for 460

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.

14 Likes

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.

4 Likes

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.

5 Likes

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.

9 Likes

You should file a bug report with repro file – this is in Release Notes and won’t be seen by the right engineers here.

7 Likes


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? :eyes:
I think I missed something…

13 Likes

@devSparkle
I think this suggests Roblox was ahead of you on that one (I missed this too):
image

5 Likes

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.

2 Likes

HttpService.HttpEnabled works for me in command bar

print(game:GetService"HttpService".HttpEnabled)
2 Likes

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.

2 Likes

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

1 Like

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.

3 Likes

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.

2 Likes

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.

3 Likes

I actually recently discovered it does have LocalUserSecurity which really confused me because I swear I did this before and it gave me an error


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?)
image

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

2 Likes

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.

That’s speculation though haha.

2 Likes

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.

game:GetService"TweenService":Create(game:GetService"ServerScriptService",TweenInfo.new(),{LoadStringEnabled=""})


This also exposes other properties not accessible from scripts like BasePart.siz, Part.shap, and HopperBin.Command.

5 Likes

An easier way to check this is to pass the property name into GetPropertyChangedSignal.

10 Likes

I made one: Update 460 broke several key features in my game - #2 by PeZsmistic
Hope the right people see it!

4 Likes

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.