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
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
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?
This bug is still being worked on. When there is an update i will pass it along.
Maybe, but:
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’m currently having this issue and it’s quite irritating. Any update on when/if it will be fixed?
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.
Won’t the .Locked property work?
Edit: I didn’t see how old this was, someone bumped this to the top of the bug reports, will probably delete this
Encountered this issue today. Very confusing as I was trying to figure out why my parts were “Locked” when in fact a collision group was the issue.
I am confused as to why this strange selection behaviour has not been fixed yet? Roblox replied that they are tracking the issue but it still exists. It is very annoying to have to select parts in the explorer when I expect to be able to just click the part in the viewport
@itsFrank17 this just started happening for me today as well. I haven’t had this issue in the past 2 years.
Specifically I have one Collision group not following the settings of the group. I added my post to this topic since I also can’t select the Parts in this group by Alt + clicking on them with my mouse.
It’s a simple train/cart tutorial place that I haven’t worked on in a couple years. It’s only 57 KB and I’ve included a copy below. It was working fine when I built it. Now I opened it up to check it out before I sent it to someone on the forums having train/cart ride issues and it’s acting funky.
I have used Collision Groups with no problems in the past. Since they’re so easy to work with once you understand them I know the things I’ve done trying to troubleshoot the issue today haven’t screwed it up.
I have 3 collision groups. Default, Wheels, and Rails.
Default can collide with Default and Rails so players can interact with them. Wheels can only collide with Rails since they are alignment parts underneath this Physics based train.
I can select all the parts in the Default and Rails groups with my mouse.
I cannot select the items in the Wheels group.
When I test the game the items in the Wheels group are colliding with the Default group.
I tried closing out of the place and reloading it, but that didn’t change anything.
I went back after closing completely out of Studio and it still isn’t working properly.
I also deleted both the Rails and Wheels groups and tried to add them again, selecting the Rail Parts and adding them to the Rails group, and the same with the Wheel parts in the Wheels Group.
It seems to be an issue with the Wheels group not recognizing that it’s not supposed to collide with the Default group.
The Wheels group isn’t set to collide with itself because some wheels overlap, and I can see during testing that those wheels are not colliding with each other.
If I select the group of rail ties (all Default collision group) and make them CanCollide false the train runs fine. This is basically taking all the Default and Wheels collisions out of the picture manually, which isn’t the way CollisionGroups are supposed to work.
You can try it out here:
Train Experiment.rbxl (56.5 KB)
Since it is only a test place you can run the train manually by selecting both VectorForces inside the ‘Frame with VectorForce’ Parts (1 in each Carriage). Change just the X values of both VectorForces.
I’ve set it in steps of 5000 up to a total of 40,000 and the train runs very fast even though the rail corners are fairly sharp (20° between each segment). Above that it’ll likely derail. The Y forces I have in there are there to help keep the train on the tracks.
I also haven’t installed any new plugins in the last couple years, and haven’t put any free models in this build.
Maybe this is only happening on my computer, but if someone could try it out to see if it works for them I’d appreciate the input and it may help with this bug report.
It is working the exact same buggy way for me as well. Goes fine when the ties’ CanCollide is set to false, doesn’t go if they are set to true. I tried setting it to true while one of the wheels is inside a tie and it really acts like as if they are supposed to collide with each other (even though they are not).
It’s weird because me and 2 of my friends have started experiencing a similar issue recently.
Probably embarrassing for me to say, but I only recently found out about Collision Groups, so I never actually used them before. On Tuesday, I was just casually working on my tram, then concluded the day, didn’t change anything else, just building and improving that one tram. On Wednesday when I opened the same place where I make all my buses and trams, I couldn’t select anything except for a backup tram model. I checked DevForums and then found out it’s something about Collision Groups. But I still don’t know what to do or what the exact problem is… everything in the place is set to the Default one.
Later, I got reports for my main game that the AI train that’s supposed to spawn every 15-30 minutes piled up and as they kept spawning, by time there were 6-7 of them just stuck behind each other. I’m guessing that the first hit something that it’s CanCollide was magically turned on (even though we haven’t updated the game for the past 2-3 weeks), then the others just got stuck behind.
I’ve disabled the train spawning as I didn’t really have much time to do proper bug fixing and it was a pretty game-breaking bug, but since then the main game is also now experiencing the same weird bug that occured in my bus/tram making place. In the main game, it’s about half of the map acting normal and the other half can’t be selected in Studio and that part acts like it’s not supposed to collide with anything. There is a bus garage on both sides. You can walk safely on both sides. Those buses that can be spawned in the buggy section just completely fall out of the map like 80% of the time. In the other 20%, they stay and act like the ones on the other section, which is that they fall out once you get out of them and only if you are on the bugged side of the map.
I actually tried checking the “border” of the 2 sides with an articulated bus. Sure enough, when I jumped out of the driver seat, the front was fine, but the part after the bendy part was just swinging in the baseplate itself. Both sides and the bus are all on the Default Collision Group, and all 3 had their CanCollide on.
To fix the bug, I first tried restarting Studio, didn’t work. I then tried reinstalling it, didn’t work. I tried restarting my whole computer, still didn’t work. I also tried making a script that sets everything in a new Collision Group that can collide with Default and itself, but it still didn’t work. The only thing that worked so far that can speed up my production is putting things in a completely new baseplate, but that’s really not ideal especially when it comes to big maps. And who knows when will that also bug out.
From what I have seen so far, it’s almost as if it put itself in a separate Collision Group that can’t be edited, doesn’t collide with anything, and shows itself as Default even though it’s not. And even a script couldn’t change the part’s CollisionGroup properly. I mean, it did change it, but it acted as if nothing happened.
As for plugins, I have “Team Create with Hats” installed that adds an extra CollisionGroup, but even in places where Team Create isn’t turned on and the plugin doesn’t do anything, the bug still occurs. The 2 friends that I mentioned at the start don’t even have the plugin and the same occurred for them.
It’s pretty frustrating as it’s a pretty game breaking bug and it also slows down production very heavily. We still have a Christmas update and a map update to make until February and I already think we are late.
Maybe “Team Create with Hats” is the issue!
I’ve had that installed for the last couple years but had no issues.
I did just check and saw there was an update for it. I’m not sure when the update came out since I haven’t checked for updates in a while. I did update it, but after that I shut down Studio and restarted it by loading the train place in and I’m getting the exact same issue.
One thing I didn’t mention is that I have AreContactPointsShown selected in the Studio settings. It shows red spheres wherever there are collision points when play testing.
When I switch the ties in Play mode from CanCollide false to true I’d expect red spheres everywhere the ties contact the UnderWheels. I don’t get any indication (red spheres) of the contacts, just the visual fact that the train is getting pushed up due to the collisions happening.
I then tried shutting the plugin off, closing Studio, and reopening this place. Same issue, I can’t select any items in the Wheels CollisionGroup.
I don’t think it is the one causing the issue. I did also try turning off all plugins, same issue happened. And that plugin doesn’t do anything if you are in a place where Team Create isn’t turned on. Also, as I said, the 2 of my friends don’t even have the plugin and the issue still occurs. It’s really weird.
Also, thank you for telling me about that setting. Didn’t really know that was a thing. I guess I just haven’t really experimented with collisions before. Thank you!