Really like this change.
I don’t quite understand the point of this change.
I think it’s because you can input the name of a nonexistent collision group into the CollisonGroup property, but it won’t do anything.
So, unregistered groups kinda exist, but don’t work.
2 Likes
We will add an API for the check and release it in the upcoming weeks.
10 Likes
Why do icons always look so out of touch? The UI isn’t bad. It’s just the icon. For some reason, Roblox cannot get icons right. The colors don’t fit so it distracts me.
2 Likes
Please make collision groups effect touch events! I was trying to have a touch event hitbox, but because the part count of other objects was high, the server load went through the roof
I bring you good news, Touched events already can be affected by collision groups, it’s just not the default behavior. Turn on the TouchesUseCollisionGroups setting if you want that behavior:
16 Likes
I was not a fan of the quite verbose and inconvenient to type API of PhysicsService, so I’m really happy the API for collision groups is being streamlined.
New collision group editor also looks great and way more functional, so kudos!
4 Likes
Wonderful. Could we also get an update so that we can use both collision group names and IDs to call PhysicsService functions? e.g
5 Likes
Why create new functions with the same functionality and deprecate the old ones when there is nothing wrong with them? Seems entirely unnecessary unless the new functions behave differently.
4 Likes
The technical difference is the return type, but it’s really about intent, of both us and the developer.
It makes it more clear to developers that they should no longer use Ids, and it makes it clearer to people reading Lua code whether code was written under the old approach of using Ids or the new approach of using names.
Technically since collision groups still have an id under the hood, we could continue to use the same API method, however in both regards mentioned above the intent would be much less clear that way.
4 Likes
Wait, why? Why can’t CollisionGroup[string] just be a convenient setter/getter by name for the CollisionGroupId? Why does it actually have to be stringly typed, and the two properties not linked at all?! This is bad!
4 Likes
I don’t mind these changes, they don’t seem something too big.
If GetCollisionGroupName will be deprecated, how else can we get the collision group’s name?
Will the CollisionGroupId still be a thing after these changes? I don’t think we need it, but just asking to be sure.
Also still prefer my plugin, although it needs a refreshment in the UI:
1 Like
WOW this is awesome, no more having to tediously write out commands in the console to get the right names and IDs.
1 Like
Nice work on the plugin.
No, we will eventually deprecate the property. It will be accessible in Lua for backward compatibility, but won’t show up in the auto-completion etc.
We don’t have a replacement for this since the input of the method is CollisionGroupId
5 Likes
I’m having a bug(?) with this change and I’m not sure if it’s on Roblox’s end or my end. The CollisionGroupId doesn’t change when assign collision groups via CollisionGroup[string].
Do I need to change both CollisionGroup[string] and CollisionGroupId[int] for now? I’m planning to only use CollisionGroup since CollisionGroupId is going to be deprecated.
The Collision Group Name will roll out a few days later.
4 Likes
Such system should be added to particle emitters.
1 Like
Oh alright. It explains that! Thanks for the clarification.
Great update! I don’t know what they were thinking when they made the original service. It was so convoluted before.
2 Likes
Come on! They never fixed collision groups to not affect ray casting!