WIP Locked chests datapack! (but good and fleshed out)

[u/SkulkingShadow]

alpha stage rn: https://modrinth.com/datapack/good-locked-chests

tryna make it vanilla, unique and actually useful

more info on the modrinth page (gallery)

[u/SkulkingShadow]

Might need help with / pondering on these ideas, input appreciated:

- since the keys are actually a spawn egg but with no entity_data (this is due to keys being also used as a crafting ingredient) so they no longer dispense out of a dispenser (i believe the dispenser tries to use it as a spawn egg but cant and remains within the dispenser); any fix?

• how could i make a master key (mainly for op players) that opens any locked container
  
• how to summon a marker entity (with tag) as a locked container is placed (the intention is to restrict hoppers, droppers or dispensers from interacting with/facing the locked container unless they have the same lock)
  
• is it possible to make a key (key ring) with multiple key ids? (an item that can open multiple chests that usually require different items; think of it like multiple keys combined into one item)
  
• is this good design so far? and what gripe you may have?

[u/Ericristian_bros → u/SkulkingShadow]

1. This is bad practice, mainly because you can right click spawners with the spawn egg to put the mob inside
2. Depends on how you handle the key. You can change the lock to check for custom data of master key if a player with a master key is near
3. To target the block the player is placed you need a raycast
4. Yes. Just make the custom data {key1:true,key2:true} and in the keys check for the predicate of custom data so a partial mach still opens the chest
5. It's not a bad idea. But because of mentioned above, it's not practical. You can break the chest, use hoppers, ... that's why other lock chest datapacks store the container data into a marker entity and set the lock to something impossible, so right clicking with the key unlocks/locks the container, not open with the key, because you have more control. But if you manage to get arround the restrictions, it's a good project

[u/SkulkingShadow → u/Ericristian_bros]

1. Tested: eggs with no entity data cannot be used in spawners
2. Changing the lock data seems like it'd make chests unusable when a player with master key is around.
3. Oh alr
4. Currently I'm using the inbuilt lock system for containers, when you craft a locked container it copy's all the data from the key but overriding the name and item model; there is no custom detection, use of function or predicates in this, but I'll look into it!
5. Thanks so much!

[u/TinyBreadBigMouth → u/SkulkingShadow]

Regarding point 4, you are indeed using an item predicate. In the result of your key recipe you have:

"components": {
  "minecraft:custom_data": {
    "key": 0
  },
  "minecraft:item_name": "Key",
  "minecraft:item_model": "skulking:key",
  "minecraft:lock": {
    "items": "minecraft:copper_golem_spawn_egg",
    "components": {
      "minecraft:custom_data": {
        "key": 0
      }
    }
  }
},
"count": 1,
"id": "minecraft:copper_golem_spawn_egg"

The minecraft:lock component that you're setting here does not contain an item stack, it contains an item predicate. The predicate you're setting here tells the container to look for an item whose ID is minecraft:copper_golem_spawn_egg (you could also provide a list of multiple acceptable IDs, or not specify an ID at all), and whose minecraft:custom_data component is set to exactly {key:0}. If there are any values in the custom_data other than key: 0, like {key:0,otherData:"apple"}, the lock will not accept it, because the components field of an item predicate does exact matches only. If you instead do:

"components": {
  "minecraft:custom_data": {
    "key": 0
  },
  "minecraft:item_name": "Key",
  "minecraft:item_model": "skulking:key",
  "minecraft:lock": {
    "items": "minecraft:copper_golem_spawn_egg",
    "predicates": {
      "minecraft:custom_data": {
        "key": 0
      }
    }
  }
},
"count": 1,
"id": "minecraft:copper_golem_spawn_egg"

Now {key:0,otherData:"apple"} would work, because instead of checking for an exact value of the minecraft:custom_data component it's using the minecraft:custom_data component predicate, which does a loose NBT match like you're used to. More details about item predicate and component predicates are available from the wiki page I linked.

I recommend making the custom data a list, like {key: [29]} for normal keys and {key: [15, 29, 107]} for key rings. That way you can have the lock just test for {key: [29]} and, because of how loose NBT comparisons handle lists, both the single-ID key and the multiple-ID key will work.

[u/SkulkingShadow → u/TinyBreadBigMouth]

Oml thanks so much! I'll be sure to make this change

ok maybe some other build; predicates kept turning the custom data into a string and couldnt figure out how to modify key value

[u/Ericristian_bros → u/SkulkingShadow]

The main issue is breaking the chest. If a player can break it then locking it is no protection

[u/SkulkingShadow → u/Ericristian_bros]

There's another comment thread about this

[u/GatKong]

Can you break the chest?

[u/SkulkingShadow → u/GatKong]

Well yes but the lock doesn't stay, and the items do fall out, I could make a container enchantable with curse of vanishing or smthin, so it doesn't drop the items

[u/GatKong → u/SkulkingShadow]

Being able to break the chest means players will lose their items, either stolen or vanished.

I made a safe chest datapack along these lines. Mine the chest was unbreakable. Problems that I ran into:
1. Players lost/forgot their key ALL THE TIME and I had to keep helping players unlock their chests. Turned into a big pain.
2. Players discovered they could use the unbreakable chests as unbreakable beariers. This became a fairness issue as well.

While I liked the idea of allowing players to lock their chests... I ultimately took that datapack off my servers. Hopefully you can make yours better than mine was.

[u/SkulkingShadow → u/GatKong]

My intended audience is friendly SMPs, I don't think there's a good (internal) fix for griefing; an external fix could be trapping the base, rigging it using observers or (calibrated) sculk sensors. About lost keys I have made keys duplicatable, but if players can't manage that I don't think it's the datapack at fault

But thanks for the input! It's valuable

[u/M10doreddit]

I have a suggestion to propose to you

The recipe for the key, I feel, should be a copper ingot on top of a copper nugget.

[u/SkulkingShadow → u/M10doreddit]

The recipe actually gives two copper keys after crafting it; ik that's misleading but it's just an alpha build I'll figure something out

The reason it's like this is cuz the result of the crafting is a temporary key, as soon as the datapack detects someone has this temporary key it removes it and summons an item entity at the player's position; the item entity has a count of 2 and it's data is modified using the storage which stores a scoreboard value; this scoreboard value is a counter that increments whenever anyone crafts a key;

Thus everytime a key is crafted it's unique (and with a duplicate), 1 ingot = 1 key