Items
The OOP module keeps item usage concise by letting you build an item stack once and then reuse it for giving, spawning, or embedding it in wider entity workflows.
Nothing of its own: eachsummon() creates one minecraft:item entity. No objective, storage, forceloaded chunk, tick or load function.
Basic usage
In game: hovering the sword given by player.giveItem(sword)
summon() spawns the stack as a minecraft:item entity at the given position (defaulting to ~ ~ ~). The overload taking a ChatComponents or a String + Color sets the entity's visible custom name.
Writing a stack into NBT
toNbt() returns the {id, count?, components?} compound Minecraft expects wherever an item stack lives in NBT: the Item tag of an item entity, a container's Items entries, or a data modify ... set value target. Empty components are omitted, matching how vanilla serializes a stack with no component patch.
Pass explicit components to serialize a variant of the same stack without rebuilding it: sword.toNbt(otherComponents).
Configuring the spawned entity
summon takes a trailing ItemEntitySummonData block that controls the spawned entity's root NBT:
Generated output:
showcase = true is a shortcut for a static display item: it sets PickupDelay and Age so the entity never despawns and cannot be picked up, plus Invulnerable and NoGravity. Any of those set explicitly win over the shortcut, and the item's custom_name component is mirrored onto the entity so the name renders in the world. An item entity with a customName shows it in the world unless customNameVisible = false.
Shared entity fields
These come from EntitySummonData, the base shared by item entities, mannequins, display entities and interactions. They are written first, before the fields of the entity itself:
| Field | Builder | NBT tag | Type |
|---|---|---|---|
air |
Air |
Short |
|
customName |
customName(text, color) |
CustomName |
ChatComponents |
customNameVisible |
CustomNameVisible |
Boolean |
|
data |
customData { } |
data |
NbtCompound |
fallDistance |
fall_distance |
Double |
|
fire |
onFire(duration) |
Fire |
Short |
glowing |
Glowing |
Boolean |
|
hasVisualFire |
HasVisualFire |
Boolean |
|
invulnerable |
Invulnerable |
Boolean |
|
invulnerableTime |
invulnerableFor(duration) |
invulnerable_time |
Int |
motion |
motion(dx, dy, dz) |
Motion |
List<Double> |
noGravity |
NoGravity |
Boolean |
|
onGround |
OnGround |
Boolean |
|
passengers |
passenger(entity) |
Passengers |
List<NbtCompound> |
portalCooldown |
PortalCooldown |
Int |
|
rotation |
rotation(yaw, pitch) |
Rotation |
List<Float> |
silent |
Silent |
Boolean |
|
tags |
tag(vararg names) |
Tags |
List<String> |
team |
team(team) |
Team |
String |
ticksFrozen |
frozen(duration) |
TicksFrozen |
Int |
invulnerableTime is a number of ticks during which the entity ignores damage, while invulnerable makes it immune for good. The duration builders take a TimeNumber and write ticks: invulnerableFor(3.seconds) writes invulnerable_time:60, onFire(5.seconds) writes Fire:100s (at most 32767 ticks) and frozen(1.seconds) writes TicksFrozen:20. team is the name of the team the entity joins when it spawns, and data is free NBT any entity stores, matched with nbt={data:{...}} in selectors. The pos of an entity isn't a field because summon already takes its position.
passenger(entity) adds a model with its id, as the model is when it is added. Mannequins, display entities and interactions take it, an item entity isn't possible as a passenger because its Item compound only comes with ItemStack.summon:
Item-only fields
ItemEntitySummonData adds the fields that only exist on minecraft:item:
| Field | NBT tag | Description |
|---|---|---|
age |
Age |
Ticks lived - negative values delay despawning |
health |
Health |
Item entity health |
owner |
Owner |
UUID allowed to pick the item up |
pickupDelay |
PickupDelay |
Ticks before pickup is allowed |
showcase |
- | Shortcut described above |
thrower |
Thrower |
UUID that threw the item |
For anything not covered, summon also accepts an extraEntityNbt builder applied last, so you can write arbitrary root tags (a fixed UUID, modded data, and so on).
Practical example
This pattern is useful when the same item should be given directly in one context and spawned as a visible reward in another.
See also
- Entities & Players - Give, replace, or spawn item stacks from entity-scoped helpers.
- Events - React to item use or consumption with event-driven logic.
- Components - Define richer custom names, lore, and metadata for the items you build.
