Locking or unlocking parts inside packages should not count as modifying them

[PeZsmistic]

As a Roblox developer, it is currently totally impossible to work with packages in a game where locking parts is used for gameplay behavior.

Currently, locking or unlocking the map (which all lives under a folder in workspace) to do environment work will mark every single package as edited, which is completely absurd and makes working with packages a nightmare.

I just attempted to switch some of the foliage in my game to using packages and I will very likely be killing all of these packagelinks again tomorrow since I now have to waste a very large amount of time reverting the changes to every single package in the game which simply had all of its parts unlocked, and then re-locked.

CC @tnavarts since you replied to me last time I brought this up.

Improved Workflows for Packages

I unlock the whole map when doing map work. The map is in a folder and the lock tool affects the whole hierarchy at once. I need to be able to grab and drag package models around + duplicate them to build the world, so they need to be unlocked for me to do that, but I need them locked in gameplay. Packages in my case would be used for reusable map props like trees and plants.

[tnavarts]

I still don’t really follow.

If Locked has gameplay implications for you then wouldn’t you even more strongly want it to be modified because its gameplay behavior has changed? (Much like you would expect the package to be modified if you turned off CanCollide).

What behavior do you actually expect if you modify the locked status? That it would remain unmodified and the locked status would be silently clobbered when you get an update? Or that the locked status would be reapplied (possibly leaving the package in an inconsistent state if new parts were added which now don’t have the same locked status as the rest).

@PeZsmistic

I now have to waste a very large amount of time reverting the changes to every single package in the game

I would expect you to be able to Undo out of this. Did that not work here?

[PeZsmistic]

Undoing does not work since I’m going to be making changes to the game after the unlock. I have to hunt down every package and manually discard the changes to them so that studio will let me publish.

These are good questions though, and my only conclusion is: this sucks. Locked should not be a gameplay accessible property; it should exclusively be used for Studio tooling. Its purpose in gameplay would be better served as a developer defined “Editable” attribute, but to change this for my situation would be a multi-week ordeal trawling through third party code.

Maybe a better solution for my problem is to simply stop unlocking the map. Can we get this as native functionality instead? Allow selecting locked parts by holding a key combination Or alternatively (but less desirably) a toggle to respect the locked setting with the dragger tools.

[tnavarts]

@PeZsmistic

but to change this for my situation would be a multi-week ordeal trawling through third party code.

The reality is you’ll have to either do that or not use packages because there’s no fix without significant future implications for how draggers or packages work which would fix your situation, and the changes such a fix would be part of probably wouldn’t end up prioritizing this uncommon workflow over other things.

The most likely is a hotkey to allow selecting locked parts. Can’t promise that will happen but bring that up when I release the Dragger Improvements beta soon (watch for an announcement sometime this month).