Automatic class loot

Build availability

This page describes the new class-loot implementation in current testing builds. Older public builds may not contain these settings or review commands. Check the generated ClassLootSettings.yml and command completion before configuring it.

Use automatic class loot to give a dungeon consistent equipment coverage. Write each item's name and lore once in a custom boss configuration. EliteMobs generates the item for the encounter's rank and difficulty when it drops. You do not need one custom-item file per family or per difficulty.

Keep exceptional rewards in custom item files and add them through loot tables. Automatic equipment can coexist with a boss's named relic, scripted weapon, quest item or other deliberately custom reward.

How drops work

classLoot: true adds a separate baseline equipment roll to a custom mob's death. It works even when dropsEliteMobsLoot: false or the authored loot table is empty. Existing custom items and unique loot remain available alongside it. New loaded custom-mob configurations default to coverage enabled; explicit classLoot: false settings are preserved. Summoned reinforcements, mounts and anti-exploit kills are excluded. A recipient must contribute at least 10% of the mob's maximum HP, be a real tracked player, and not be locked out of the dungeon reward.

Per-boss setup

These fields belong at the root of a file in plugins/EliteMobs/custombosses/:

Field	Meaning
classLoot	Enable or disable the separate automatic equipment roll.
classLootRank	AUTO, TRASH, MINIBOSS or BOSS.
classLootDifficulty	AUTO, NORMAL, HARD or MYTHIC.
classLootItems	Per-family names and lore. Omission does not exclude that family.

The following is a presentation excerpt, not a complete boss or complete set of 19 family entries. Configure each item's name and lore once:

classLoot: true
classLootRank: BOSS
classLootDifficulty: AUTO
classLootItems:
  SWORDS:
    name: "&bWinter's Edge"
    lore:
      - "&7Its edge has never known a whetstone."
      - "&7Each winter leaves it sharper."
  AXES:
    name: "&bGlacier Splitter"
    lore:
      - "&7The haft bears the names of seven miners."
      - "&7None returned for it."
  WANDS:
    name: "&bFrostwhisper"
    lore:
      - "&7Hold it to your ear."
      - "&7The blizzard is still inside."
  DPS_CHESTPLATES:
    name: "&bIcebreaker's Hauberk"
    lore:
      - "&7The smith sharpened every link."
      - "&7Putting it on requires practice."
  TANK_CHESTPLATES:
    name: "&bGlacier Guard"
    lore:
      - "&7The last avalanche left a dent."
      - "&7The next will have to try harder."
  SHIELDS:
    name: "&bWinter's Door"
    lore:
      - "&7Taken from a cabin buried in snow."
      - "&7It still keeps the cold outside."

The active instanced dungeon supplies the difficulty ID. Numeric IDs 0/1/2, Normal/Hard/Mythic and Easy/Medium/Hard are supported, ignoring case, surrounding whitespace and color formatting. The package's authored mode declarations determine whether Hard is the middle or top tier: Easy or Medium selects the latter scheme, unless the IDs explicitly declare Normal or Mythic. Detection happens before translation. Numeric IDs always retain their 0/1/2 meaning. A recognized name can supply the tier for a custom ID, or supply the ID when it is missing.

ClassLootSettings.yml maps resolved IDs 0/1/2 to NORMAL/HARD/MYTHIC by default; an explicit mapping for the original ID takes precedence. Unrecognized definitions produce a console warning with the package filename. Unknown custom IDs retain exact matching for authored filters and use an explicit loot mapping or the configured default tier. Power and loot difficultyID filters both accept a scalar or a YAML list, and accept either numeric or named IDs. Unknown filter values warn once per package/source/value; empty or malformed filters match nothing.

Outside an instance, the configured defaultDifficulty applies. Set classLootDifficulty to a named difficulty for non-instanced content with a known difficulty. classLootRank: AUTO uses BOSS/EVENT or MINIBOSS boss types, then legacy $bossLevel / $minibossLevel name tokens, otherwise TRASH. An explicit TRASH/MINIBOSS/BOSS override avoids ambiguity in older content. Name/filename classifications in the corpus are evidence inferences; runtime rank does not guess from filenames.

Supported item keys are SWORDS, AXES, BOWS, CROSSBOWS, TRIDENTS, HOES (scythes), MACES, SPEARS, STAVES, WANDS, DPS_HELMETS, DPS_CHESTPLATES, DPS_LEGGINGS, DPS_BOOTS, TANK_HELMETS, TANK_CHESTPLATES, TANK_LEGGINGS, TANK_BOOTS and SHIELDS. The default selection favors the active class: 80% relevant equipment and 20% off-class equipment. Within the chosen bucket, categories have configurable weights (WEAPONS 50, ARMOR 45, SHIELDS 5), then available families in that category are equally likely. Adding a family does not change its category's share of that bucket. This is one item per successful roll, not a full set. An omitted item still participates with &6$boss's $weapon and empty lore. $boss, $weapon, $item and $difficulty work in each item's name and lore. lore: [] explicitly means no authored lore and does not warn. Missing, blank or invalid names, missing/invalid lore and unknown family keys produce a dedicated [ClassLoot presentation] console warning with the boss filename and field paths when that enabled boss configuration loads. Inherited presentation counts as authored. Warnings do not disable drops or insert placeholder text into authored YAML.

Default drop chances are 5% for trash, 25% for minibosses and 100% for bosses, per eligible contributor. These are editable v0 economy choices, not frequencies measured from DLC. Instanced drops enter the existing dungeon vote pool; eligible party drops use the existing party pool; other rewards use normal personal loot. Item level comes from the existing combat reward level and item-tier roll.

Reusing presentation across mobs

Use the existing extends mechanism in custombosses. A disabled parent stores the shared presentation; each active child opts in and supplies its own encounter settings. The parent is a boss configuration template, not a custom-item file.

# custombosses/winter_rewards.yml
isEnabled: false
classLoot: true
classLootDifficulty: AUTO
classLootItems:
  SWORDS:
    name: "&bWinter's Edge"
    lore: ["&7Each winter leaves it sharper."]
  AXES:
    name: "&bGlacier Splitter"
    lore: ["&7The haft still bears the miners' names."]
  BOWS:
    name: "&bWhiteout"
    lore: ["&7The string hums before the snow begins."]
  CROSSBOWS:
    name: "&bLast Light"
    lore: ["&7Keep one bolt for the journey home."]
  TRIDENTS:
    name: "&bThree Below"
    lore: ["&7Recovered from beneath the fishing pier."]
  HOES:
    name: "&bWinter Reaper"
    lore: ["&7Nothing grew where its last owner walked."]
  MACES:
    name: "&bAvalanche"
    lore: ["&7The mountain needed no second blow."]
  SPEARS:
    name: "&bIcicle"
    lore: ["&7Do not warm it by the fire."]
  STAVES:
    name: "&bSnowbound"
    lore: ["&7A storm was sealed inside the grain."]
  WANDS:
    name: "&bFrostwhisper"
    lore: ["&7Hold it close. The blizzard is still inside."]
  DPS_HELMETS:
    name: "&bRimecrest"
    lore: ["&7Its crown was sharpened for the charge."]
  DPS_CHESTPLATES:
    name: "&bIcebreaker's Hauberk"
    lore: ["&7The smith sharpened every link."]
  DPS_LEGGINGS:
    name: "&bSnowstalker's Stride"
    lore: ["&7Their owner never waited for spring."]
  DPS_BOOTS:
    name: "&bBlack Ice"
    lore: ["&7The first step was always the quickest."]
  TANK_HELMETS:
    name: "&bDeepwinter Helm"
    lore: ["&7Snow gathers where the dents used to be."]
  TANK_CHESTPLATES:
    name: "&bGlacier Guard"
    lore: ["&7The last avalanche left a dent."]
  TANK_LEGGINGS:
    name: "&bPermafrost Greaves"
    lore: ["&7The watch lasted longer than the winter."]
  TANK_BOOTS:
    name: "&bFrozen Footing"
    lore: ["&7The gate fell. Its keeper did not."]
  SHIELDS:
    name: "&bWinter's Door"
    lore: ["&7It still keeps the cold outside."]

# custombosses/winter_guard.yml
isEnabled: true
extends: winter_rewards.yml
entityType: STRAY
name: '&bWinter Guard'
level: 50
healthMultiplier: 3.0
damageMultiplier: 1.2
classLootRank: MINIBOSS

# custombosses/winter_keeper.yml
isEnabled: true
extends: winter_rewards.yml
entityType: STRAY
name: '&bWinter Keeper'
level: 50
healthMultiplier: 7.0
damageMultiplier: 1.4
classLootRank: BOSS
classLootItems:
  SHIELDS:
    name: "&bKeeper's Vigil"
    lore: ["&7Someone had to stay behind."]

These examples define spawnable bosses. Add your normal dungeon spawn settings and powers to the children. The names and lore are illustrative, not a supplied DLC pack.

extends takes a configuration filename, not a filesystem path. Keep filenames unique within the boss catalog. Child fields override parent fields; lists replace parent lists. isEnabled, spawn locations, leashRadius, powers and eliteScript are not inherited. Missing or cyclic parents are configuration errors.

Inherited classLootItems entries count as authored presentation. A child can replace one family's name or lore without copying all the others. Its rank and the active difficulty still select the generated statistics. Setting a single family's lore: [] deliberately removes its lore. Omitting its entry does not remove it from automatic drops.

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 presentation issues, 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 authored item entry. It bypasses drop chances, relevance weights, loot-entry permission conditions and configured quantities. 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.75
          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 enchant availability, procedural eligibility and maxEnchantmentLevel still apply. maxLevelV2 is the ordinary procedural/value reference; it does not truncate the authored ceilings. 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 slot has its own name and lore under classLootItems.

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 scripted item an unconditional upgrade over every generated 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

In ProceduralItemGenerationSettings.yml, these default to enabled:

validWeapons:
  STAVES: true
  WANDS: true

These switches control ordinary procedural drops, shops and class loot. Operational compatible FMM is also required. Selection excludes a missing, disabled or reloading magic service. Experimental Combat world settings do not gate item availability. dropProcedurallyGeneratedItems controls ordinary procedural drops; class coverage has its own global enabled switch and per-mob classLoot switch. Procedural names come from staffNames / wandNames in StaticItemNames.yml; class item names and lore remain per mob and per item.

Legacy classLootNames and shared classLootLore migrate into individual entries. Existing per-item fields, including empty lore, take precedence. The migration preserves source text, removes the obsolete fields and uses the normal translated configuration lifecycle. Translation keys follow paths such as classLootItems.SWORDS.lore. Existing explicit classLoot opt-outs are not overridden.