Item Modifiers
Item modifiers (also called loot functions) let you transform item stacks: change counts, add components, set names/lore, copy data, and more. Kore exposes a concise DSL over the vanilla format so you can define modifiers in code and use them in commands and loot tables.
For the vanilla reference, see the Minecraft Wiki – Item modifier.
Quick start
Create a modifier and apply it with the /item modify
command:
This produces the exact JSON the game expects, while keeping everything type-safe and composable in Kotlin.
Where modifiers live in Kore
- Builder entry-point:
dataPack.itemModifier(..)
returns anItemModifierArgument
you can reference elsewhere. - Internal data:
ItemModifier
stores an inlinable list ofItemFunction
objects and serialises directly to a JSON array when saved. - Each
ItemFunction
accepts optionalconditions { .. }
, which are regular Predicates.
See kore/features/itemmodifiers/ItemModifier.kt
for the container type and kore/features/itemmodifiers/functions/*
for all functions.
Working with components
Many transformations map 1:1 to item components. A few common examples:
For a general overview of item components and their builders, see Components.
Conditions on functions (Predicates)
Every item function can define conditions { .. }
. These are standard Kore Predicates and support all the same helpers (random chance, weather, scores, entity checks, etc.). This mirrors the vanilla “conditions” array on loot functions.
Learn more in Predicates.
Composition and nesting
filtered { itemFilter { .. } modifiers { .. } }
– Run nested modifier list if the item matches anItemStack
filter.modifyContents(..) { modifiers { .. } }
– Apply nested modifiers to items inside a component (e.g., bundle contents).sequence { .. }
– Inline a sequence of functions as a single step.reference(myModifier)
– Reuse another item modifier by name.
Selected function examples
Alphabetical sampling of common functions. All names match vanilla functions and are available in the functions
package.
applyBonus(enchantment, formula)
copyComponents(include/exclude, source)
copyCustomData(source, ops)
copyName(source)
copyState(block, properties)
enchantRandomly(options, onlyCompatible)
enchantWithLevels(options, levels)
enchantedCountIncrease(enchantment, count, limit)
explorationMap(destination, decoration, zoom, searchRadius, skipExistingChunks)
explosionDecay()
fillPlayerHead(entity)
filtered { .. }
furnaceSmelt()
limitCount(limit)
modifyContents(component) { modifiers { .. } }
reference(name | ItemModifierArgument)
sequence { .. }
setAttributes { attribute(..) }
setBannerPattern(patterns, append)
setBookCover(title, author, generation)
setComponents { .. }
setContents(component) { entries { .. } }
setCount(count, add)
setCustomData(nbt)
setCustomModelData(colors | flags | floats | strings)
setDamage(damage, add)
setEnchantments { map }
setFireworkExplosion(shape) { .. }
setFireworks(flightDuration) { explosions { explosion(..) } }
setInstrument(tag)
setItem(item)
setLore(..)
setLootTable(type, name | LootTableArgument, seed)
setOminousBottleAmplifier(amplifier)
setPotion(potion)
setStewEffect { potionEffect(..) }
setWritableBookPages(pages, generation)
setWrittenBookPages(pages)
toggleTooltips(toggles)
See the test suite ItemModifierTests.kt
for end-to-end JSON expectations that mirror vanilla.
Using modifiers in commands
Use inside a function (e.g., in your load/setup) and call /item modify
via the DSL:
Tips and best practices
- Keep modifiers focused and reusable; prefer composing small helpers with
reference(..)
. - Use
conditions { .. }
to guard expensive or situational changes. - Prefer component-based edits (
setComponents
,setContents
,setFireworks
, etc.) for clarity and future-proofing. - When editing lists, pick the right mode:
REPLACE_ALL
,APPEND
, orINSERT
with offsets.
See also
- Predicates – conditions for item functions
- Components – building and understanding item components
- Inventory Manager – maintain item states in GUIs/slots
- Vanilla reference: Minecraft Wiki – Item modifier