Enable Mouse Behavior Through Locked BaseParts

[https_KingPie]

As a Roblox developer, it is currently too hard to interact with instances contained within/overlapping BaseParts with Locked enabled.

In my current project, nearly all of the map will be contained within invisible non-interactable BaseParts which define regions within the game. Visibly, this looks like:

Image

Demo rig of place, these regions are normally invisible - all map credit to @Ahlvie

These regions have Locked enabled, because they require zero interaction by members of our development team on a regular basis. They are important for the game, because they tailor the client’s audio and lighting settings based on specific configurations. They are locked, because map changes to instances within these regions would constantly require either moving the region every time a change is required or operating solely within the Explorer menu, which is infeasible in an experience with lots of instances and objectively slower than clicking.

Locked blocks mouse input when a developer mouses over the BasePart in Studio, which is intended behavior.

Example of this:

The blue part is locked, and mouse behavior is not registered when hovering over it or clicking it

However, this is problematic when working with regions, because the current behavior of Locked also blocks mouse input on instances within a Locked BasePart.

Example of this:

https://i.vgy.me/A62CD7.gif(image larger than 10 MB)

Mouse behavior works when the tip of one of the instances within it barely pokes out of the region, e.g., that tree at the end

I would like to request a change to Locked behavior, such that mouse input is not blocked for instances within a Locked BasePart, and instead only blocks mouse behavior for the instance that is actually Locked

If this issue is addressed, it would improve my development experience because it would greatly expand the utility of the Locked property.

As it stands, it does not make sense for Locked behavior to essentially extend to all instances within a Locked instance. This essentially locks these other instances as well. This would also improve development flows, because it would enable better application of the Locked property to more effectively designate parts of a development workflow that are ‘complete’ and do not require further interaction or edits, without having unintended effects on other instances.

[PeZsmistic]

Nesting parts inside other parts isn’t really a good organization scheme, and until recently wasn’t even supported by streaming. A better design is to use models or folders and pack the contents alongside the volume rather than inside of it in the hierarchy.

You can use a collision group that does not collide with default to prevent Studio tools from interacting with these objects instead of locking them. This is technically a temporary workaround because I know Studio wants to fix this and add an explicit way to have tools ignore certain parts, but this has been working for me in the meantime for multiple years, and many plugins rely on it.

[https_KingPie]

Totally agree. To be clear, the parts aren’t actually nested within each other (via explorer, if I understand what you’re saying). It looks like this:

These regions (the ones that are locked) just happen to overlap existing models and instances, although they aren’t descendants of the region parts themselves.

I’ll probably be forced into using the collision group workaround, but I thought a feature request was probably due, since Locked behavior could be a lot more useful it tweaked slightly. The status quo behavior of, essentially, locking overlapping parts seems unintentional and I don’t think it’s been explicitly brought up until now.