Studio Selection doesn't work if CollisionGroup doesn't collide with Default group

Expected behavior: Studio tools should be able to select any part regardless of the collision group (assuming the part isn’t locked).

Observed behavior: Studio tools only allow selection of parts that can collide with the Default collision group.


Clicking on an object in the 3D studio viewport doesn’t work if the CollisionGroup for that object is set to not collide with the Default collision group. This includes the Default group too (i.e. if the Default group is set to not collide with anything).

Very easy to reproduce:

  1. Create a part in Studio
  2. Create a new Collision Group
  3. Assign the part to that group
  4. Set the group to not collide with the Default group
  5. Try clicking on it in the 3D viewport

You can drag and select. You can also select within Explorer window. But you cannot just click on it in the 3D viewport.

15 Likes

Hey, just want to let you know I looked into it and was able to reproduce the bug.

Know we are tracking it and will get it addressed. thanks for the report!

4 Likes

I believe this is very expected behavior! You should not be creating collision groups that do not collide with default for normal game purposes, this does not make any sense to do. In normal circumstances you’d have parts in a custom collision group that specifically do not collide with another collision group.

Please do not change this, this opens up the avenue for a huge range of plugins that use invisible parts for displaying adornments, such as my plugin, which uses a part that does not collide with Default to add extra adornments/surfacegui to the selection box around models, or to hide the default selection box. If Studio tools could raycast and hit this part, it would break the whole thing.

AFAIK, this is also very nontrivial to fix because this is deeply rooted into the way raycasting works, and many games already rely on this behavior to have parts that do not interact with their own systems and other external systems that use raycasting (i.e. developers cannot inject these parts into the raycast blacklist themselves).

The benefits from changing this behavior are completely unclear and arguably negligible in comparison to the benefits of keeping it this way. If this was to be changed, an alternative method for accomplishing all of the above must be provided first, because the ability to do this is critical for many games and plugins, including some of my own projects, and for some of my plugins.


Actually through some testing just now it looks like parts in CoreGui will still render adornments and surfacegui, which means I may not need this trick for my plugins, but it still is very important to certain systems in my other projects.

3 Likes

The only reason I found this bug is because of my use-case of needing to do this. I needed to create a part that only collides with specific collision groups and ignores everything else, including Default. But then I couldn’t select the part.

Also, this is just in regards to the selection tools in Studio. It has nothing to do with changing overall collision group behavior, nor raycasting behavior. Just the tools themselves.

It is critical that Studio tools be completely unaware of certain parts I create for plugin purposes, and the same is true for some gameplay mechanics in one of my projects since I prefer to keep game systems independent of each other, so I do not want to maintain a global raycast blacklist for parts that are purely meant to be collision volumes.

Your problem can probably be solved with the addition of another non-Default collision group to contain everything you don’t want the part to collide with.

1 Like

I’m not too sure about that, since the new raycasting API allows rays to hit parts that don’t collide with Default. This was only a problem with the old API.

Besides, this suggestion doesn’t have anything to do with raycasting, just studio tools. Games shouldn’t be affected if this bug is addressed.

I guess, but something to keep in mind is that this won’t work if you plan on sharing your work (as a free model w/e etc.) Moreover, this would mean that you’d have to set every part in the game to a separate collision group that behaves exactly like default incl. players, and that’s just really tedious.

1 Like

I would argue this would fall under using an unsupported feature. Plus you can create your own selection tools by activating the plugin mouse and using the Selection service.

I would have to add every other part in the game to it then. It’s a weird use-case for sure, but that’s besides the point in regards to the bug.

I get that fixing this would break your plugin. That’s not fun. I get that. But perhaps there’s another way to go about what your plugin is doing.

1 Like

It was my understanding that the Studio tools used the same raycasting API. If there is an easy way to make them hit no matter what without affecting ingame behavior as you say, then I guess there isn’t a problem anymore because as an addendum to my earlier reply:

Actually through some testing just now it looks like parts in CoreGui will still render adornments and surfacegui, which means I may not need this trick for my plugins.

It’s important to note though that I don’t want certain parts in my games to be affected by Studio tools at all, e.g. collision volumes. If I lock them then they block raycasts IIRC, and if I leave them be, then I accidentally drag them around when I’m trying to work. Changing this would impact my ability to efficiently work on this project.

1 Like

I think it should be a setting, it’d mess up a couple of things. For example I use collision groups to make spawn areas that cannot be collided with, and if this were changed it’d be annoying to handle in studio

This isn’t regarding the behavior of collision groups

Really interesting discussion, we will need to have internal chats about how to address this; regardless of how we implement it however, the box-select and click-select (raycast) should not diverge in their behavior.

It seems like preventing in-window selects is something that IS useful so we will have to consider this as we move forward

6 Likes

I had a situation with this last year which brought to the staff’s attention that this could be problematic for newer developers.

*sniffles*

They set up a feature request with some solutions they’d discussed, which was never addressed. I was unaware that plugin creators had to use this hacky method, which adds more to the pile.

I encountered this bug yesterday because multiple game elements need to not collide with default, as it was either have parts that don’t collide with default, or move almost every single part in the entire map to a new group along with every new part the modelers add.

Shouldn’t this be a separate feature?

3 Likes