Allow selecting locked parts by holding a key combination

Locking parts currently serves as a way to prevent unintentional modifications to parts while working on unrelated things (among other use cases), but it is currently too hard to select a locked part if I really need to select it anyway.

It is very difficult to copy and paste, or get to the properties of a part that has been locked, especially if it is very deeply nested away in the explorer hierarchy. If I need to get e.g. the color of a nearby part, copy a meshpart so I can reuse it and save on memory in my game, or I need to reference something else about it, I must do the following:

  • Select the lock tool
  • Unlock the part
    • If the part is in a folder or a nested folder, this involves unlocking every other part in the entire folder tree as well - if there are a mixture of locked and unlocked parts in the folder, I lose that information, either everything is locked or everything is unlocked.
  • Deselect the lock tool
  • Select the part

And if I want to prevent myself from accidentally editing things again, or selecting the wrong things while working I must do this process again to lock everything, until I need to sample another meshpart or property.

This is awful and makes re-using meshparts and keeping colors consistent unnecessarily tedious and difficult.

When I hold down alt to drill into a model to select individual parts, I should be able to also do this for locked parts. For example, maybe I could hold down alt+ctrl to activate the alt-click select behavior, but also have it ignore if a part is locked and select it anyway.


For example, right now I’m making props and I wanted to reuse this spiked meshpart in my map:

image

I cannot copy this meshpart to use in my props because it is locked, and to unlock it I have to go through a tedious ritual that I must repeat every time I want to sample a meshpart, and I risk ripping the ground up by accident if I don’t re-lock everything since all of the parts in my map are in a nested folder hierarchy.

60 Likes

I’d like to raise this feature request back up again. As a Roblox developer, it is currently too hard to work with locked parts in Studio as they hold the same behaviour as a live session.

I desire to have my map locked in live gameplay to prevent any mistaken changes such as by third party building tools but currently I don’t have any way to select locked parts in Studio without unlocking them. This also damages workflows relying on packages if I ever unlock them or if a change in their position or orientation is registered as a change. Workarounds like having a script lock relevant parts at runtime is not ideal; I’d have to iterate through the Workspace on too many parts unnecessarily instead of having that property set right as the experience instance turns up.

If I could have my Studio tools ignore a part’s lock in any way, this would help me keep my properties consistent without needing to always track their original lock state. I could keep parts locked while not actually registering new changes. This is also a pain with nested packages that propagate the change upward now, so complex packaged assemblies with locks end up generating too many changes I should otherwise not have to be making.

My part locks are to prevent unintended changes, yes, but I don’t want to change the lock state of my parts when I’m trying to make an intended change on them. I use part locking with the intent of not making changes to them unless I deliberately need to and the extra clicks involved in flipping the property are not only bad for my development experience timewise but also because they actually trigger certain systems that I don’t want them triggering.

12 Likes

I want to re-open this. It can be useful to lock parts to avoid selecting the wrong ones when building, but occasionally I run into the scenario where I am unsure of where a locked part is in a folder of many other parts/models, and having a key combination to select locked parts would make this incredibly simple, and save me a lot of time.