Custom Crates & Keys that Players Can Create

So, after pondering for the last year of not even existing on this server, I thought of crates that players may create crates and crate keys of their own, that is modified only by the creator of the crates and keys.

You can generate keys and crates with the command /crate generate <key | crate> , but you can only create 2 crates and keys max (more or less if /crate limit is used). Anyone can break the crate like normal, and if they right-click the crate without the key for the crate to view it's contents, and right-click with the key to unlock the crate, but if you want to modify the crate (if you are the owner of it), you hold shift, and right-click the crate to open up a modify menu, allowing you to rename the crate, change crate key requirement, and the crate's contents.

However, crates and keys that have been created by you after 12 hours will be removed (or once you, the creator of the crates logout, whatever is more viable), and their storage of items will be removed as well to save space, and the keys will be removed from everyone's inventory and echests (OR they are given new lore: "this crate key no longer works").

These crates will roll to grant the user a random item in the crate, and once you roll, the key you are using to unlock the crate with will be used up and gone from your inventory. Also; there is an option in crates that will only allow the first crate key to work, preventing any sort of distribution. There is a new rule for the crates: Do not sell crate keys for real life money, or with any currencies that can only be achieved through paying with real life money, as this results in gambling.

Admins have the ability to view ALL crates currently existing in the server, and are capable of deleting any crates or keys as needed. Players may only create their own crates and keys if they have played for 14 days, and then they must be granted permission from an admin via the command: /crate requestperm, which requests a random admin in the server for crate permission.

Commands:

• /crate requestperm (requests permission to an admin chosen by random)
• /crate generate <key | crate> (creates custom crate or key with provided name)
• /crate help (displays a list of commands in the crate category)
• /crate remove <key | crate> (removes crate/key from the server) (OPs can only remove their own, ADMINs can remove any crate or key in the server)
• /crate clear (clears all crates and keys created by you)
• /crate clearall (clears all crate and keys created by anyone) (ADMIN ONLY)
• /crate listall (lists all crates keys made by everyone, allowing you to view their contents on click) (ADMIN ONLY)
• /crate list (Lists all crates and keys made by you, allowing you to view their contents on click)
• /crate edit (edits a crate (must be your own crate))
• /crate toggle (disables/enables crate commands and crate functionality) (ADMIN ONLY)
• /crate limit (changes the limit of crates and keys OPs can create) (ADMIN ONLY)
• /crate perm (grants the player crate commands) (ADMIN ONLY)
• /crate unperm (revokes the player's crate commands, and removes all crates and keys made by them) (ADMIN ONLY)
• /crate pause <on | off> (pauses the use of commands that effect/create crates or keys for OPs) (ADMINS ONLY)

This feature would be excelling for when you want to distribute a random item to someone else, or a item of your choice if you add a single item to the crate's content, which skips rolling.

Alright, thats all I have to talk about this suggestion, so drop on in and see if this would be good or not.

@Shdwo#14111
There is one thing kits and shulkers, don't have, and that is the randomized capabilities of items (which I have explained in my suggestion). Crates do a great job at randomizing the outcome of which item you obtain, and the outcome is unbiased, whether or not the crate creator wants the outcome for the player using the crate. Reason why a randomized outcome would be added is that there would be a 1v1 match, and each player gets a random item to fight with, so that the fight is tilted with some RNG, OR; a player wins an event and the reward can range from something simple as a diamond sword with some enchantments, to something overpowered, like a heavily enchanted Pwnhammer from Terraria.

@Shdwo#14117
Crate keys can also be granted to a player to allow them to use the crate the key belongs to as well, and the keys don't have to follow by a name for a locked container (which is what the lock NBT you provided), instead, the crate requires a key with the correct NBT, so the name of the key can't do spit, thus allowing you to do more stylish key naming, and removes the issue of having keys being useless when they are renamed to something else. Also, players can /invsee the key holder, and get the key name that way with a quick screencap, so what is the point of a macro command that adds the Lock NBT when the key's name is exposed with a command as simple as /invsee?

@StevenNL2000#14201 If you define events as scenarios you host, sure, crates are usable for events, but when you see most of the other servers and how they use crates, you can see that crates are usually used as a way to see what item you can get, and use the item you get for your benefit. However, it fitting the freedom theme doesn't seem as so.

Crates in TotalFreedom are for rewarding, randomization without bias, and most importantly; they remove the issue of replicating key names by scouting the key holder when key names are not going to be what allows the key to open the crate.

However, considering @Shdwo#14117's post, a quick command to lock containers would be really good, and can be perfected if a /key command existed that would open a locked container with the same ID so that the name won't be the reason of unlocking the container, so it could run like this:

• /lock (Locks the container you are holding with the id argument being what the container is looking for before it is opened)
• /key (Adds a special tag to the item you are holding that is going to be scanned by whatever locked container you attempt to open)

So even if this thread's suggestion is denied, at least adding a secure lock and key system would be a great substitute (except for the randomization being gone).