Automatic class loot

Build availability

This page describes the current EliteMobs implementation. Older builds may lack these settings. Check the generated ClassLootSettings.yml and command completion before configuring it.

Class loot uses ordinary custom-item files and boss loot tables. A profile supplies the baseline enchantment roll for the encounter's difficulty and rank; the custom item supplies its material, name, lore, model, ownership, and deliberate overrides.

How drops work

Set itemType: CLASS_LOOT in a custom item, then reference that file in the boss's uniqueLootList. An empty table produces no class loot: the system does not invent missing items or families.

# customitems/winter_sword.yml
isEnabled: true
itemType: CLASS_LOOT
material: DIAMOND_SWORD
name: "&bWinter's Edge"
lore: ["&7Taken from $boss on $difficulty."]

# customitems/winter_helmet.yml
isEnabled: true
itemType: CLASS_LOOT
material: DIAMOND_HELMET
classLootFamily: TANK_HELMETS
name: "&bDeepwinter Helm"
lore: []

# custombosses/winter_keeper.yml
isEnabled: true
entityType: STRAY
name: "&bWinter Keeper"
level: 50
healthMultiplier: 7.0
damageMultiplier: 1.4
classLoot: true
classLootRank: BOSS
classLootDifficulty: AUTO
uniqueLootList:
  - filename: winter_sword.yml
    chance: 1.0
    amount: 1
  - filename: winter_helmet.yml
    chance: 1.0
    amount: 1

Author material, a nonblank name, and a string-list lore; lore: [] is valid. Missing or invalid required fields disable the item. Weapon families follow the material, except magic weapons use weaponType: WANDS or STAVES. Shields infer SHIELDS. Armor requires an explicit matching DPS_<slot> or TANK_<slot> family; a helmet cannot declare a boots family.

Supported families are SWORDS, AXES, BOWS, CROSSBOWS, TRIDENTS, HOES, MACES, SPEARS, STAVES, WANDS, DPS_HELMETS, DPS_CHESTPLATES, DPS_LEGGINGS, DPS_BOOTS, TANK_HELMETS, TANK_CHESTPLATES, TANK_LEGGINGS, TANK_BOOTS, and SHIELDS.

Boss field	Meaning
classLoot	Enables coverage for this boss; defaults on except reinforcement definitions
classLootDifficulty	AUTO, NORMAL, HARD, or MYTHIC; AUTO resolves the instance difficulty, otherwise the configured default
classLootRank	AUTO, TRASH, MINIBOSS, or BOSS; AUTO uses boss type, then legacy level tokens in the name
uniqueLootList	Ordinary item references; eligible CLASS_LOOT entries form the candidate pool

The global enabled switch in ClassLootSettings.yml also applies. Reinforcements, mounts, anti-exploit kills, invalid levels, locked-out players, and contributors below 10% of the boss's maximum health do not receive these rolls.

The default first-stage chances are 5% for trash, 25% for minibosses, and 100% for bosses, per eligible contributor. After that succeeds, selection considers only available class-item entries that match difficulty and permissions, with positive amount and chance. The selected entry's own chance is then rolled; on success, its configured amount is generated. No reroll is promised when that chance fails.

Class entries are handled by this coverage path, not duplicated as ordinary boss drops. Non-class rewards can coexist in the same table. Instanced equipment enters the dungeon vote pool; qualifying party equipment enters the party pool; other equipment is personal loot.

Reusing presentation across mobs

Reference the same custom-item filenames from several bosses. Each drop uses that encounter's rank, difficulty, and reward level. $boss, $weapon, $item, and $difficulty expand in the class item's name and lore.

Explicit item enchantments override matching results from the profile roll; item potion effects are appended to profile effects. Model fields, permission, and Soulbind remain ordinary custom-item settings. This lets one named item reuse a baseline while keeping a deliberate special property.

There is no boss-side classLootItems, classLootNames, or classLootLore authoring path in this implementation. Move presentation into ordinary custom-item definitions and add their loot references; do not rely on the earlier automatic migration described by testing-build documentation.

Class preferences

Personal rolls use the recipient's active specialization. Each shared dungeon roll chooses one qualifying contributor uniformly, independently of damage beyond the existing 10% threshold, and uses that contributor's class for selection. Party rolls do the same within the contributing nearby members of that party. Items still enter the existing shared vote and are not reserved for the selected player. The number of rolls, threshold, lockouts and voting eligibility are unchanged.

Weapon relevance comes from the active class form's configured weapon affinities, including specialization-specific bonuses. It does not use the weapon currently held. Armor and shield preferences appear for every class in the generated settings:

selection:
  classBiasEnabled: true
  relevantChance: 0.8
  categoryWeights:
    WEAPONS: 50
    ARMOR: 45
    SHIELDS: 5
  classes:
    paladin:
      armor: TANK
      shields: true
    champion:
      armor: DPS
      shields: false
    ranger:
      armor: DPS
      shields: false
    battlemage:
      armor: BOTH
      shields: false

The explicit tank defaults are Paladin, Guardian, Aegis, Bulwark, Shieldbearer, Templar, Bannerlord, Deathless, Dreadnought, Colossus and Arcane Knight. Justicar, Marshal, Juggernaut, Warmonger, Battlemage and Cryomancer accept both armor roles. Other forms prefer DPS armor, including Cleric forms. Shield preferences default to Paladin, Guardian, Aegis, Bulwark, Shieldbearer, Justicar, Templar, Marshal and Bannerlord. These are editable equipment preferences, not combat role restrictions.

Missing class selection or disabled bias uses the category weights without the 80/20 split. An empty bucket transfers its probability to the available bucket. Unavailable magic/material families are removed before calculating probabilities. A zero category weight excludes it from real rolls; all zero weights disable automatic rolls and warn. The weights are relative inside each relevance bucket, so they are not promises of an overall 50/45/5 distribution for every class.

Administrator review

Permission: elitemobs.loot.admin. Commands require a player and support tab completion.

/em loot preview <mob.yml> <level> <NORMAL|HARD|MYTHIC>
/em loot preview <mob.yml> <level> <NORMAL|HARD|MYTHIC> <AUTO|TRASH|MINIBOSS|BOSS> <family|ALL>
/em loot giveall <mob.yml> <level> <NORMAL|HARD|MYTHIC>
/em loot giveall <mob.yml> <level> <NORMAL|HARD|MYTHIC> <AUTO|TRASH|MINIBOSS|BOSS>

For example:

/em loot preview GK_boss_snickersnap.yml 100 MYTHIC
/em loot preview GK_boss_snickersnap.yml 100 MYTHIC BOSS WANDS
/em loot giveall GK_boss_snickersnap.yml 100 MYTHIC

preview reports available item families, family probabilities for the administrator's active class, authored enchantment ceilings/chances, rare rules, potion effects and authored table entries. A named family also gives one generated sample. Short forms use the boss's resolved rank. Explicit rank/difficulty arguments override it for inspection without modifying its configuration. Family probabilities are conditional on a successful automatic roll; configured drop chance is reported separately. Enchantment rules are authored ceilings before budget and global enchantment availability/caps, not guaranteed values on every sample.

giveall gives one independently rolled sample of every available automatic family and one sample per non-class authored item entry. Automatic candidates still require matching difficulty and entry permissions, positive chance and amount, and an available item. Samples bypass the actual drop rolls, relevance weights and configured quantities. The separate non-class item pass also bypasses entry permissions. Item-level restrictions still use the normal custom-item constructor. Authored entries include all difficulty variants, with raw difficulty conditions reported: selected difficulty controls the automatic profiles, and the command makes no assumptions about which dungeon owns a reusable mob. Fixed and limited custom items retain their existing level rules; scalable samples use the requested level without the administrator's progression cap. Unavailable/invalid items are reported; missing generations also warn in console. Overflow drops at the administrator's feet.

The commands do not spawn a mob, run death events, execute command rewards, pay currency or create loot votes. Non-item rewards are reported only. A disabled automatic-loot switch is reported but does not prevent deliberate preview samples. This is an inspection tool, not a drop-frequency simulation or dungeon loot audit.

Enchantment formula

The generated ClassLootSettings.yml contains all 171 difficulty/rank/family profiles. This excerpt shows the shape of an editable profile; edit the generated file rather than replacing all profiles with this excerpt:

enabled: true
defaultDifficulty: NORMAL
difficultyIds:
  '0': NORMAL
  '1': HARD
  '2': MYTHIC
enchantmentBudgetFraction: 0.5
minimumPrimaryLevel: 1
dropChance:
  TRASH: 0.05
  MINIBOSS: 0.25
  BOSS: 1.0
profiles:
  MYTHIC:
    BOSS:
      WANDS:
        primaryEnchantment: POWER
        enchantments:
          POWER:
            level: 7
            chance: 1.0
          UNBREAKING:
            level: 5
            chance: 0.9
          MENDING:
            level: 1
            chance: 0.15
          MULTICAST:
            level: 2
            chance: 0.4
        rareEnchantments:
          MULTICAST:
            level: 3
            chance: 0.01

For each rule, roll its chance independently. Rare rules are additional rolls and replace a successful ordinary rule only when their level is higher. Enabled native levels become a bag of enchantment units. Draw ceil(N * fraction) units without replacement. Reserve up to minimumPrimaryLevel of those units for the primary enchantment, bounded by its selected ceiling and the total budget. A zero budget stays zero. Custom enchantments keep their selected levels and do not consume native units, matching existing scalable custom loot. Global enchantment availability and procedural eligibility still apply. Custom provider settings use the current enchantment definition format. Native maxLevelV2 is a procedural/value reference, not the authored-content ceiling. Unsupported weapon/enchantment combinations are skipped with a configuration diagnostic; wands and staves cannot acquire Punch from profiles.

DPS armor uses Sharpness as its primary enchantment with lighter protection. EliteMobs already counts damage enchantments from equipped armor. Tank armor uses Protection as its primary, with defensive secondary enchantments. Shields use Protection through the existing offhand defense calculation. Helmet and boot profiles can include their supported slot enchantments. These are separate items, not a new full-set bonus or new skill types. Armor uses diamond materials; shields use SHIELD. Each reward has its own ordinary custom-item name and lore.

Profiles optionally accept potionEffects using the existing item syntax, for example potionEffects: ["STRENGTH,0,SELF,ONHIT"]. Amplifiers are zero-based. These effects use the existing item effect rules and durations, independently of the enchantment budget. Invalid entries warn and are skipped. The bundled equipment profiles have no potion effects: the reviewed samples do not justify making a particular proc a baseline benefit. Existing weapon profiles remain unchanged; missing armor and shield profiles are supplied from the bundled defaults.

Example: Power 7 plus Unbreaking 5 creates 12 native units. At 0.5, six are selected; one is reserved as Power, and five are drawn from the remaining bag. The resulting item might have Power 4 / Unbreaking 2. Multicast II, when selected, remains II. Its separate 1% rare roll can produce III on a Mythic boss wand. That is 1% of generated Mythic boss wands, not 1% of all boss kills. Profiles can be tuned without duplicating Winter's Edge into three custom item files.

Where the defaults come from

The September 2026 source audit covered 58 available DLC packages, 2,566 custom-item definitions and 4,417 boss loot references. It retained 68 unresolved references rather than inventing missing items. Classification and sparse groups require judgment, so these profiles are a starting point for manual balance review.

For sampled weapon groups, positive enchantment-level medians are rounded to the nearest integer, with halves rounded up. Secondary chances use observed prevalence rounded to 5% increments. A group needs at least five positive samples for its own median; sparse groups use a better-sampled counterpart. Level ceilings do not decrease from Normal to Hard to Mythic. Binary or mechanically capped effects use explicit caps.

Armor profiles use a focused audit of 920 tiered armor and shield items. Each rule prefers the same armor role and slot, then other slots of the same role, then the same slot across roles. Shields use shield evidence. Missing evidence uses an explicit fallback. Potion-effect evidence did not meet the minimum sample and prevalence requirements for a default proc, so baseline profiles contain none.

Magic weapons have no classified samples in that audit. Their Power and Unbreaking profiles derive from bows. Multicast, Blast Radius and Ignition rules are new balance choices. The 5%/25%/100% drop rates and 80% class preference are also design choices, not measured DLC frequencies.

Primary enchantment targets

These are configured ceilings before the random native-enchantment budget. Each cell lists Normal / Hard / Mythic. They are not guaranteed final item levels, and secondary enchantments also consume budget.

Family	Primary	Trash	Miniboss	Boss
SWORDS	SHARPNESS	2 / 3 / 4	3 / 3 / 4	5 / 7 / 9
AXES	SHARPNESS	2 / 3 / 4	3 / 4 / 4	3 / 5 / 6
BOWS	POWER	2 / 3 / 4	3 / 3 / 4	4 / 5 / 7
CROSSBOWS	POWER	2 / 3 / 4	3 / 3 / 4	4 / 5 / 7
TRIDENTS	SHARPNESS	2 / 3 / 4	3 / 3 / 4	5 / 7 / 9
HOES	SHARPNESS	2 / 3 / 4	3 / 3 / 4	5 / 6 / 8
MACES	SHARPNESS	2 / 3 / 4	3 / 3 / 4	5 / 6 / 8
SPEARS	SHARPNESS	2 / 3 / 4	3 / 3 / 4	4 / 6 / 8
STAVES	POWER	2 / 3 / 4	3 / 3 / 4	4 / 5 / 7
WANDS	POWER	2 / 3 / 4	3 / 3 / 4	4 / 5 / 7
DPS_HELMETS	SHARPNESS	2 / 3 / 5	3 / 5 / 7	5 / 7 / 10
DPS_CHESTPLATES	SHARPNESS	2 / 3 / 4	3 / 5 / 7	5 / 7 / 10
DPS_LEGGINGS	SHARPNESS	2 / 3 / 4	4 / 5 / 7	5 / 7 / 10
DPS_BOOTS	SHARPNESS	2 / 3 / 5	3 / 4 / 6	5 / 7 / 10
TANK_HELMETS	PROTECTION	2 / 3 / 4	2 / 3 / 5	5 / 7 / 9
TANK_CHESTPLATES	PROTECTION	2 / 3 / 4	3 / 4 / 6	5 / 7 / 10
TANK_LEGGINGS	PROTECTION	2 / 3 / 4	2 / 3 / 4	5 / 6 / 8
TANK_BOOTS	PROTECTION	2 / 3 / 4	3 / 4 / 6	5 / 7 / 10
SHIELDS	PROTECTION	2 / 3 / 4	3 / 4 / 7	5 / 7 / 10

Balancing a dungeon

1. Choose the dungeon's combat level and level sync using the difficulty guide. Keep the tier IDs explicit.
2. Assign TRASH, MINIBOSS and BOSS from each encounter's role. These select loot quality and frequency; they do not set boss HP or damage.
3. Begin with the generated profiles above. Tune ClassLootSettings.yml to change the baseline across content, rather than cloning each named item three times.
4. Evaluate the final rolled items, including secondary effects and rare procs. Increasing a ceiling increases the bag of available levels, not a guaranteed stat on every drop. Difficulty level sync preserves the importance of enchantment quality, so a large ceiling increase can matter well beyond one dungeon.
5. Account for eligible contributors and encounter count. A 100% boss roll is per eligible contributor, not one guaranteed item for the whole party. Repeated minibosses can supply more equipment than the final encounter.
6. Review exceptional authored rewards alongside the baseline. Keep their distinctive behavior intentional; do not make every special item an unconditional upgrade over every baseline item. Use the review commands on this page before a playtest.

Boss survivability still follows the separate recommended boss values. There is no formula that converts healthMultiplier into an enchantment level. Validate encounter duration and reward economy through playtesting after configuration review.

Magic availability and migration

validWeapons.STAVES and validWeapons.WANDS in ProceduralItemGenerationSettings.yml default to true. Compatible, operational FMM is also required. Missing or reloading magic services remove those families from selection; the Advanced Combat System's world settings do not determine item availability.

A magic CLASS_LOOT item declares weaponType. Omit fmmItemModel to use the bundled weapon for that family, or supply a valid authored FMM weapon ID. Staves use a supported spear material; wands use BLAZE_ROD. A display-only model does not substitute for a working magic weapon.

dropProcedurallyGeneratedItems controls ordinary procedural drops. Class coverage uses its own global and per-boss switches. Procedural names come from staffNames and wandNames in StaticItemNames.yml; class-item names come from their custom-item files.

For older testing content, replace boss-side presentation with CLASS_LOOT custom items and ordinary loot references. Native enchantment keys in profiles retain their existing format; custom-item references to magic enchantments require namespaced IDs such as freeminecraftmodels:multicast,2.