search

Loot Tables

Loot tables are JSON files that define what items should generate in many situations (container contents, mob/block drops, fishing, the loot command, and more). Kore provides a concise, type-safe DSL to build those tables programmatically.

For an introduction to the vanilla format, see the Minecraft Wiki entry Loot table.

Quick start

val lt = lootTable("my_loot_table") {
	// Optional top-level item-modifier functions applied to the final drops.
	functions {
		enchantRandomly {
			options += Enchantments.LOOTING
		}
	}

	// Add one or more pools
	pool {
		rolls = constant(2f)
		bonusRolls = constant(1f)

		// Predicates (aka conditions) – see the Predicates guide
		conditions {
			weatherCheck(raining = true)
		}

		entries {
			// Reference another loot table as an entry
			lootTable(LootTables.Gameplay.PIGLIN_BARTERING) {
				functions {
					setCount(1f)
				}
			}
		}

		// Pool-level item-modifier functions
		functions {
			setCount(1f)
		}
	}
}

// Use it via the loot command
load {
	loot(self(), lt)
}
Kotlin

Table structure

  • functions: Top-level list of item modifier functions (applied after pooling). Map to vanilla loot functions like set_count, enchant_randomly, etc. See also the Components page’s “Patch items” note for runtime patching helpers.
  • pools: One or more LootPools.
  • randomSequence: Optional RandomSequenceArgument for deterministic sequences.
  • type: Optional LootTableType (vanilla categories like blocks, entities, chests, fishing, etc.).

Pools

Each pool controls a roll and entry selection:

  • rolls: A number provider indicating how many rolls to perform. Use providers like constant(..) or more advanced ones from the predicates providers package.
  • bonusRolls: An optional number provider added to rolls (commonly used with luck or looting effects when using conditions/functions).
  • conditions: A list of predicate conditions guarding the pool. Refer to the Predicates guide for available conditions and composition (allOf, anyOf, etc.).
  • entries: The actual things that can be selected (items, tags, alternatives, other loot tables, etc.).
  • functions: Item modifier functions applied to items generated by this pool.

Minimal example:

pool(constant(1f)) {
	entries {
		lootTable(LootTables.Gameplay.PIGLIN_BARTERING)
	}
}
Kotlin

Entries and functions

  • Entries can be other loot tables, singleton items, or composites. Kore mirrors vanilla’s entry types in features.loottables.entries with idiomatic builders.
  • Functions are item modifiers. Common helpers include:
    • setCount(..)
    • enchantRandomly { options += Enchantments.* }
    • Many others under features.itemmodifiers.functions

Functions may also carry their own conditions { .. } blocks to finely control when they apply.

Predicates (conditions)

Loot-table conditions use the same system as Kore’s general Predicates. You can attach them at the pool level, entry level, or function level. See the Predicates guide for the full catalog and patterns like randomChance(..), weatherCheck(..), entityProperties { .. }, and more.

Refer to: Predicates (/docs/predicates).

Full example with expected JSON

val lt = lootTable("loot_table") {
	functions { enchantRandomly { options += Enchantments.LOOTING } }

	pool {
		rolls = constant(2f)
		bonusRolls = constant(1f)
		conditions { weatherCheck(true) }

		entries {
			lootTable(LootTables.Gameplay.PIGLIN_BARTERING) {
				functions {
					setCount(1f) { conditions { randomChance(0.5f) } }
				}
			}
		}

		functions { setCount(1f) }
	}
}
Kotlin

Produces JSON equivalent to:

{
  "functions": [
    { "function": "minecraft:enchant_randomly", "options": "minecraft:looting" }
  ],
  "pools": [
    {
      "rolls": 2.0,
      "bonus_rolls": 1.0,
      "conditions": [
        { "condition": "minecraft:weather_check", "raining": true }
      ],
      "entries": [
        {
          "type": "minecraft:loot_table",
          "name": "minecraft:gameplay/piglin_bartering",
          "functions": [
            {
              "function": "minecraft:set_count",
              "conditions": [
                { "condition": "minecraft:random_chance", "chance": 0.5 }
              ],
              "count": 1.0
            }
          ]
        }
      ],
      "functions": [
        { "function": "minecraft:set_count", "count": 1.0 }
      ]
    }
  ]
}
JSON

Using with commands

You can pipe a table into the /loot command via the DSL:

load {
	loot(self(), lootTable("example") { /* … */ })
}
Kotlin

Full list of Loot-table helpers

Below is an alphabetical list of DSL helpers related to loot tables. Names match the builder functions or properties you use in code.

  • Top-level (table)

    • functions { .. }
    • lootTable(fileName, init)
    • pool(..) { .. }
    • randomSequence(..)
    • type(..)
  • Pool helpers

    • bonusRolls(..)
    • conditions(..) / conditions { .. }
    • entries(..) / entries { .. }
    • functions { .. }
    • rolls(..)
  • Entry types (use inside entries { .. })

    • alternative(children, conditions) / alternate { .. }
    • dynamic(name) { .. }
    • empty(quality, weight)
    • group(children, conditions) / group { .. }
    • item(name) { .. }
    • lootTable(name) { .. }
    • sequence(children, conditions) / sequence { .. }
    • tag(name) { .. }
  • Entry helpers (per entry where applicable)

    • children { .. } (for alternative, group, sequence)
    • conditions { .. }
    • functions { .. } (for item, dynamic, entry lootTable, tag)
    • quality = ..
    • weight = ..
  • Providers and types

    • NumberProvider (e.g., constant(..))
    • Predicate / PredicateCondition
    • ItemModifier (loot functions list used in functions { .. })
  • Loot table types (type = LootTableType.*)

    • ADVANCEMENT_ENTITY
    • ADVANCEMENT_LOCATION
    • ADVANCEMENT_REWARD
    • ARCHEOLOGY
    • BARTER
    • BLOCK
    • BLOCK_USE
    • CHEST
    • COMMAND
    • EMPTY
    • ENTITY
    • EQUIPMENT
    • FISHING
    • GIFT
    • GENERIC
    • SELECTOR
    • SHEARING
    • VAULT

Tips and best practices

  • Keep pools narrowly focused and use multiple pools instead of complex single-pool logic.
  • Prefer explicit conditions over embedding probabilities solely in functions for clarity.
  • Reuse common entry/function fragments by extracting helpers into functions to keep files short and readable.
  • Predicates: /docs/predicates
  • Advancements (rewards can point to loot tables): /docs/advancements