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!
What specific issue are you having here? You can explicitly choose how you want raycasting to interact with collision groups by setting CollisionGroup on the RaycastParams.
Have you tried wrapping the function in a pcall? That way if it errors out, you will get that indication without it crashing your script.
(Also @tnavarts or @APandaPoet)
Is there a reason I can’t click on an item in Studio workspace that is in a Collision Group?
I noticed this a couple weeks ago. All items around that Part will be selected just fine with a mouse click but not an item in a Collision Group.
If there’s a setting I can’t find then that’s fine, but if it’s a bug I can file a bug report.
I tried uninstalling and reinstalling Studio to see if it was only my computer, but it still occurs…
The draggers raycast using the “Default” collision group, if your object does not collide with “Default” then the draggers won’t pick it up.
Seems to be a very strange functionally that you can’t select a Part while building because it’s in a Collision Group.
Is this always going to be a thing?
It makes it extremely difficult to build!
- you have to manually search through your Explorer to find and select that one part you are trying to Move, Rotate, or Resize.
- Perform whatever of the above you want to do.
- Now maybe I have to manouever another Part that is in a collision group, (crud, now I’m back in the dang Explorer window trying to find that 1 Part in a 50 Part Model!)
- Move that Part.
- Oh wait. Since I changed the second Part the first Part I moved now doesn’t look right so I have to Rotate it a smidge to get it facing right.
- Back to step 1.
It’s even more of a royal pain if you try to do it by moving the object back to the default group so you can temporarily interact with it:
- Select the Part. Again, manually from tens of thousands of Parts deep inside models in your Explorer window.
- Go into your Collision Group Editor to + it back to the “Default” Collision Group
- Move it, rotate it, resize it and do whatever tool changes you need to do.
- Find out that you have to move that second Part to realign it so you + it back into the Default group.
- Remember to go back to your Collision Group Editor and try to remember which 1 of the 32 possible groups each Part you interacted with used to be in.
Trying to follow these steps every time you want to use a tool on an item can really mess with what should be a 2 second operation. Imagine doing these processes a thousand times in a build session!
Scottifly happily Alt-Clicks an item, moves it, and is done!
I apologize for the rant, but this makes absolutely no sense to me.
Draggers should select whatever you click on unless that item is Locked.
4 Likes
This behavior is used in many plugins to create parts that cannot be selected. Requires alternative support for that before this can be changed likely.
Thanks for reporting! It’s on our radar. In collision group editor, make the un-selectable collision group to collide with “Default” collision group is a workaround. We will address the issue in a more user friendly way.
3 Likes
Out of touch? They’re completely appropriate.
- The symbol of a plus sign is self-explanatory across language barriers.
- The button color value is higher, making it stand out as an interactable element, but the color value isn’t so much higher as to make it steal attention away from the parent interface it belongs to.
- It’s simple design fits the rest of the parent interface and doesn’t stand out more than it should or get lost.
The point of UI isn’t to ‘wow’ people, but to be an intuitive point of interaction for your software.
This is all fundamental UI design. What would you do differently?
(Edit: Typo)
Probably to keep the API from becoming more cluttered and confusing, especially to people new to the Roblox platform.