We updated the Collision Groups Editor with a new UI, a fresh coat of paint, and also added a new property, CollisionGroup[string], to BasePart for the collision group name.
You can view collision states in the traditional table view or as a list per group.
The UI no longer has duplicate edit and buttons on each row.
Adding multiple collision groups at a time now require no extra clicks. All you need to do is type a name, press enter, and repeat.
Double-click group names on the left to rename them, or select a group and press the rename icon at the top.
Delete groups by selecting a group and pressing the delete button at the top.
New Property for Collision Group Name:
The new property CollisionGroup[string] replaces the CollisionGroupId[int].
No change is needed for the existing CollisionGroupId. The default value for the new property is “Default“. Internally, the engine respects the CollisionGroupId if the new property has a “Default“ value. We encourage you to use the CollisionGroup[string] in the future.
The CollisionGroup property allows the collision group to be more portable between places. With the new CollisionGroup, as long as the collision group name is the same in two places, copying a model from one place will preserve the same collision rule in another place after pasting the model into it.
We introduce a few new APIs in PhysicsService along with the CollisionGroup[string] property.
We will deprecate the CollisionGroupId[int] along with some old APIs in PhysicsService.
Please note the behavior of PhysicsService:RenameCollisionGroup will be different if you start using the CollisionGroup[string]. The API will only rename the registered CollisionGroup[string]. It will not rename the BasePart CollisionGroup[string] in the Workspace.
To open the Collision Group Editor, navigate to the Model tab, find the Advanced section, then click the icon for Collision Group Editor.
In the Explorer window, the new property is under BasePart.
Next Steps
The Editor will roll out around the same time as this announcement.
The Collision Group Name will roll out a few days later.
Are there plans to remove or deprecate anything?
GetCollisionGroupId: To be deprecated GetCollisionGroupName: To be deprecated CreateCollisionGroup: To be deprecated. Replaced by RegisterCollisionGroup
RemoveCollisionGroup: To be deprecated. Replaced by UnregisterCollisionGroup
GetCollisionGroups: To be deprecated. Replaced by GetRegisteredCollisionGroups
SetPartCollisionGroup: To be deprecated. Replaced by calling BasePart.CollisionGroup
CollisionGroupContainsPart: To be deprecated. Replaced by calling BasePart.CollisionGroup
We’d like to invite everyone to see if their development experience is improved by these changes and provide their feedback.
I’m really glad collision groups are being revisited & polished further for better UX! Out of curiosity though, is there a better way to detect whether a collision group exists as of now? :GetCollisionGroupId errors if none is found, so I’m forced to do as such at the moment:
if not pcall(function()
PhysicsService:GetCollisionGroupId("PlayerLimbs")
end) then
PhysicsService:CreateCollisionGroup("PlayerLimbs")
end
For one of my projects I’m forced to do such a hacky workaround because of this function erroring and such. Really hoping there’s a solution to this, I’d not I hope roblox will reconsider.
Because of how the game works, it allows any other maps to load in and create this collision group or mess with my check to see if it’s already created. I am forced to do this because of how these functions behave if none are found or trying to create a collision group that already exists, causing the game to break.
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!
Finally collision groups are getting some attention, although I prefer creating them via script, the new property will be useful and will allow programmers to quickly assign collision groups without calling PhysicsService
@PotionSeller33 Will the deprecated APIs spit a warning to the console (but still work)? Mainly asking since my game likely makes use of some of these deprecated APIs & properties, but I cannot update to using the new ones right away.
If the deprecated ones are still functional, what’s the timeframe until they lose their functionality?
This is an AMAZING QoL update. Basically addresses all of my concerns with Collision Groups. Better portability, and much more intuitive methods of setting/getting Collision Groups.
Generally deprecated on a Lua API does not mean that it will “lose it’s functionality”. The purpose of depreciating a Lua API is:
Letting you know that the API may not work properly alongside other new features added after it was deprecated.
Letting you know that there’s a newer better API available.
We value backwards compatibility, and that doesn’t end when an API becomes deprecated. Deprecated APIs MAY be removed or stop functioning at some point, but generally only after quite a long time and only if they actually become hard to maintain thanks to other newer engine changes. If we eventually do need to break a deprecated API it’s not a decision we take lightly.
