Skip to content
Stacking

Stacking

Mob Stacker

Identical mobs within 6 blocks merge into a single entity with a count label. Death drops and XP scale with the stack count, so loot stays accurate.

  • Vanilla loot tables — Drops are generated by Minecraft's own loot tables, multiplied by the stack count
  • Cooked drops — Mobs killed by fire automatically drop the cooked variant
  • Slime split handling — Stacked slimes don't split on death, preventing exponential lag
  • Kill-one-by-one mode — Optional mode that respawns the rest of the stack on each kill
  • Configurable label — MiniMessage display format with %count% and %name% (e.g. <red>x%count% <white>%name%). The name is sent as a translatable component, so the same stack reads "x5 Zombie" or "x5 Zombi" depending on each player's client — and no language file lists a single mob
  • Count out of reach — The stacked count lives on the entity, not in its label: a name tag renamed x100 used to be read as a hundred mobs and multiplied the drops accordingly
  • Exclusions — Skip named mobs and any entity types you list (Villagers, Wither, Ender Dragon, ...). A mob a player named is never merged into either, so their name tag is never overwritten

Item Stacker

Dropped items nearby merge into a single entity with a count label. Hopper pickup and player pickup overflow are handled correctly — excess items stay on the ground instead of being silently destroyed.

  • Meta comparison — Only stacks items with identical metadata (enchants, leather color, custom name, ...)
  • Configurable display — MiniMessage display format (e.g. <aqua>x%count%)
  • Pickup delay — Tweak how soon stacked items can be picked up
  • Exclusions — Skip named items and configurable item type list
  • Duplication-safe — See below

How the count is stored

A stacked pile can hold far more than a vanilla stack, so the real count cannot live on the ItemStack. It is stored in the entity's PersistentDataContainer, together with the visible count it was written with. Every read reconciles the two:

real = stored + (visible - visibleAtWrite)

That subtraction is what makes the feature safe. Anything that changes the stack behind the plugin's back — a mob picking part of the pile up, a vanilla merge, another plugin — shows up as a difference between the two numbers and is absorbed. Reading the stored count on its own would hand that difference back out as free items.

The label above the pile is cosmetic. It is never used as the source of truth: a display name is writable by anyone, and reading it as a quantity was itself a duplication vector.

  • Non-stackable items (tools, armour) are never merged
  • Player and hopper pickups are handled by the plugin so the exact amount moves, never more
  • Mob pickups (piglin bartering, allays) are reconciled on the next tick
  • The entity's visible count never exceeds the item's own maximum stack size, so a consumer the plugin does not control can only ever take what is really there
  • A pile is handed to an inventory in item-sized stacks, one at a time. Inventory#addItem does split an oversized stack on its own, but it splits by the container's maximum (99) rather than the item's (64) — and the count is clamped as it is written, which quietly destroyed 35 items out of every 99 on any pile above a vanilla stack