Skip to main content

Set up a CrazyCrates test and troubleshoot crate keys

CloudExaCrazyCrates offers configurable crates with physical or virtual keys. Begin with a small test prize and a controlled account. Key balances and delivered rewards are player data, so troubleshooting should preserve them rather than reset everyone to make a crate appear usable.

Match the release before installation

Read the project's current requirements for your chosen build. The current documentation describes a Paper 26-family and Java 25 requirement; an older Minecraft server needs a release explicitly documented for it. This does not mean you should upgrade the entire production server merely to install the newest plugin.

Download through official links and follow the installation guide. Stop first and back up worlds, crate definitions, keys and existing player data. Keep the previous plugin and configuration together. If an update introduces a migration, test it against a copied installation with disposable accounts before allowing production writes.

Build a crate with a harmless reward

  1. Start and check Console for CrazyCrates errors. Confirm that the expected crate definitions loaded.
  2. Use the installed command help guide.to identify the crate editor and its valid crate identifiers. Current documentation includes an editor command with a named-crate option; examples from older releases may differ.
  3. Copy a bundled example into a distinctly named test crate using the supported editor or configuration workflow. Keep it away from public interaction.
  4. Configure one ordinary item prize with a clearly recorded amount. Review its chance or weight and any additional commands before saving.
  5. Set up a key of the type the crate expects. Check its identifier rather than relying only on its displayed item name.

A physical key is an inventory item; a virtual key is tracked as a balance. Giving one type does not establish that the other type can open the same configured crate. Avoid using a copied item's appearance as proof of authenticity.

Test the complete transaction

The current command reference documents /crates give <virtual/physical> <crate> <amount> <player>. Fill each argument with the intended type, exact crate ID, a small amount and your test player. Check installed help before running this on another release. In Console, omit the leading slash.

Count the player's keys, open once and confirm the expected deduction and reward. Test with no key, the wrong crate's key and a full inventory. Record the result after reconnecting. If a crate animation succeeds without a reward, inspect prize requirements and the first command error rather than issuing repeated replacement keys immediately.

Keep editor and reward permissions restricted

Crate editors and key-giving commands belong to trusted staff. Do not grant a wildcard permission to let visitors use one crate. Review any reward executed as console, use the plugin's documented player placeholder and test an inexpensive result first. Monetary rewards also require a working economy integration; see Vault and balances.

If an update breaks keys, keep the original key data and inspect the documented migration path for that exact release. Send support the crate ID, key type, versions, time and redacted logs. Further reading: requirements, commands and key troubleshooting.

Looking for another plugin? Browse the Minecraft plugin guide directory.