Allow using blocks locked indirectly by a protection

[JosTheDude]

Issue

Items that are attached to another 'locked' block or item become unusable

Reproduction

1. Install Bolt on a server
2. Setup a sign, item frame, etc. connected to a chest or barrel
3. Lock the sign, item frame, etc.
4. Block it is attached too (i.e. chest) becomes unusable

Video

2025-01-11.00-10-33.mov

Video depicting issue.

Additional Info

Thanks for the awesome plugin<3

[pop4959]

Looks to be working as intended since you do not have permission to interact with that sign, and the connected block to the sign falls under the sign's protection.

Keep in mind that without admin transfer you would not have been able to get into that position (since "interact" permission would be denied on placing the sign against the chest).

[JosTheDude]

Looks to be working as intended since you do not have permission to interact with that sign, and the connected block to the sign falls under the sign's protection.

Keep in mind that without admin transfer you would not have been able to get into that position (since "interact" permission would be denied on placing the sign against the chest).

Thanks for the reply.

Would it be possible for a configuration option to make it such that blocks attached to protected blocks don't subsequently become protected? A few players in my community want to lock item frames attached to chests but not the chests themselves.

[pop4959]

Generally that doesn't really make much sense, because the reason these blocks are locked by association is so that you can't break the block by breaking it's supporting block.

I'll leave this open until I can take a closer look though, maybe there is an alternative here that would work since it sounds like you want the interaction to be different.

[JosTheDude]

This is the statement my players made regarding this issue:

"You seem to be encountering what I encountered, an auto-locked container attached to a manually locked block (in my case it was a locked item frame and a barrel). Pop's reply is indeed reasonable for its default mechanics, to prevent the block behind the locked item from being destroyed and dropping the locked item. Though I'd think that would be griefing, so I'm not sure we'd run into that very often.

My issue with it is that it prevents use cases for certain things, where a change in the setting would be much more convenient. For example, if I wanted four barrels stacked on top of each other and labeled with an item frame at the top, my entire structure would have to be built one block higher to accommodate this design if I wanted all four barrels to be used (item frame above the barrels instead of on the top barrel). This also causes some issues with design, such as attaching a trapdoor to something like a lectern to make it look nicer, and then the lectern becomes unusable. I haven't tested all of the use cases, but I imagine any combination of lockable block/usable block could cause this issue. It's not a huge deal to work around it, it just makes things much easier if it's possible to have a setting to unlock lockable blocks and usable blocks separately. Thank you for looking into this! "

[rymiel]

an auto-locked container attached to a manually locked block (in my case it was a locked item frame and a barrel)

I'm unsure what you're referring to here, is the "auto-locked container" an item frame and the "manually locked block" a barrel? This issue only exists if a locked block or entity that needs support is being supported by an unlocked block. If you want that unlocked block to be able to be used, you could just lock it as "public" instead, which removes this issue.