Skip to content

vault_randomizing_processor

finnsetchell edited this page Aug 15, 2026 · 2 revisions

vault_randomizing_processor

Sets the loot table and key item on a placed vault, and clears the runtime state so the vault generates unopened. Use it to give vaults in your structures their own rewards without baking loot table ids into every NBT, and to keep one processor list shared across a set of rooms.

Requires MC 1.21 or later. The processor is not registered on the 1.20 branches.

Minimal example

{
  "processor_type": "moogs_structures:vault_randomizing_processor",
  "loot_table": "mmr:desert_mineshaft/vault",
  "ominous_loot_table": "mmr:desert_mineshaft/vault_ominous"
}

Fields

Field Type Required Default Notes
loot_table resource location yes Loot table for normal vaults.
ominous_loot_table resource location no (falls back to loot_table) Loot table for ominous vaults.
key_item item id no minecraft:trial_key Key that opens normal vaults.
ominous_key_item item id no minecraft:ominous_trial_key Key that opens ominous vaults.

Normal versus ominous is decided by the vault's ominous blockstate as saved in your NBT. The processor reads it and never changes it, so it cannot turn a normal vault ominous.

Gotchas

  • The two ominous fields fall back differently. Omit ominous_loot_table and ominous vaults reuse your loot_table. Omit ominous_key_item and they fall back to vanilla minecraft:ominous_trial_key, not to your key_item. If you set a custom key_item, set ominous_key_item too or your ominous vaults will want a vanilla key.
  • The key item is rewritten as a plain item. Any components you baked onto the key in the NBT (custom name, enchantments, custom data) are replaced by a bare id and a count of 1. Other config values you set in the build world, like the display loot table or activation ranges, are kept.
  • Set the ominous blockstate in the build world when you save the piece. Supplying ominous_loot_table alone does nothing if no vault in the piece is ominous.

See also

Clone this wiki locally