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:
Create a part in Studio
Create a new Collision Group
Assign the part to that group
Set the group to not collide with the Default group
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.
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.
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.
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.
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.
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.
Note that at the time of editing any workaround involving CoreGui was insufficient. I needed the part in workspace because I am taking advantage of issues with glass rendering.
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
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
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.
There is no technical reason why you shouldn’t do that (except for this particular case),
The Default collision group is… the default, so it’s faster to build stuff that uses it as it doesn’t require tweaking with collision groups.
Example situation: if I wanted Part A to collide with and only with Part B but not everything else, on a big map with a lot of parts in the Default group, it just seems pointless to setup a group that doesn’t collide with the aforementioned part AND spend time putting all these parts into the newly created group just so that they don’t collide with the Part A.
Not to mention this will add extra steps when adding new stuff to the map in the future.
Disabling collisions for the Default group is the most sensible choice here IMO.
True, I agree with this.
I have a suggestion how this whole issue could be solved: what if we had the option to choose which Collision Group the Studio Selection uses?
I actually rely on this bug/feature for setting up “zones” (groups of massive parts that cover different areas) across my map. I would use the Locked property, but it currently blocks all selection.
I make platformer games, and some obstacles need to collide with the player, but not anything else.
It’s a very tedious task, because instead of selecting the part I want to select, I select an entirely different part. This can increase the time I spend editing the part (the one, which I want to edit) tenfold.
Looking at this topic, I think, that the devs should make an option in Studio’s advanced settings, so you can toggle on or off this option if needed. It’s a compromise for people who need it, and for people who despise it.
Hi, just wanted to add that this is really annoying to build/test with. I understand the use case for plugins but that should be a separate feature altogether. Selection tools should only respect Locked/Unlocked, outside of CollisionGroups. I really think CollisionGroups should (intuitively) just be used for physics interactions and raycasts at runtime, NOT for the default selection tools. At the very least, an option to toggle this behavior would be appreciated as suggested already.