magicprefix

magicprefix.txt defines every prefix that can roll on a magic, rare, or crafted item — the Sharp or Glimmering half of an affix pair. Identical 39-column schema to magicsuffix (same gating rules, same Properties.txt → itemstatcost chain), but a separate pool: a magic item rolls one prefix and one suffix from the two tables independently.

722 rows total: 689 named affixes plus 32 blank-Name placeholder rows and one Expansion section marker (an engine row dividing Classic v1.x affixes from LoD additions in the source file).

Of the 689 named rows: 603 roll naturally (spawnable=1), 66 are explicitly disabled (spawnable=0), and 20 have a blank spawnable column (also effectively non-spawning — see Historical accumulation). 573 of the spawnable rows are also rare-eligible. 132 rows are class-restricted via classspecific, spread across all 8 classes (16–18 entries each). 37 distinct exclusion groups partition the pool.

What's in a row

The 39 columns split into seven groups.

Identity

Spawn gating

Class restriction

The 132 class-restricted prefixes are distributed across all 8 classes:

Pool weighting

Group exclusion

Mod block (×3)

Item-type filter

Cosmetic / value

Group exclusion — the tier-ladder mechanism

group is what makes affix tiers feel like tiers. The canonical example is group 101 — the armor-defense family — which contains the familiar ac% ladder on body armor (alongside flat-ac rows on charms/jewels and ac/lvl per-level rows). The ac% subset on armo only:

When the engine rolls a prefix on a qlvl-30 piece of body armor:

1. Filters group 101 to rows where level ≤ 30 ≤ maxlevel (Sturdy, Strong, Glorious, Blessed, Saintly all eligible)
2. Computes each row's effective weight using the formula in Magic-level frequency multiplier below — for body armor (no magic lvl) this is just frequency; for circlets/orbs/staves/wands it's frequency × this-affix's-level
3. Picks one weighted by the resulting weights
4. Rolls the value within the chosen row's Min/Max

Group 101 also contains parallel rows for charms (Stout/Burly/Stalwart with flat ac) and per-level scaling (Miocene/Oligocene/Eocene/Paleocene with ac/lvl) — same group, different itypes. They don't compete with the armor ac% rows because the itype filter rules them out on body armor.

A magic item only gets one prefix total, so all groups compete for that single slot via their combined frequencies — group 101 is one of ~37 prefix groups vying for it.

Magic-level frequency multiplier

When the item being rolled has a non-zero magic lvl (set in weapons, armor, or misc.txt), the engine flips into a fundamentally different pool-weighting mode that dramatically shifts the pool toward high-level affixes. Disassembly of the v1.13c game binary confirms two paths:

if (item.magic_lvl > 0) {
  effective_weight = affix.frequency × affix.level
} else {
  effective_weight = affix.frequency
}

The presence of any non-zero magic lvl triggers the multiplication — its actual value (1 for orbs/staves/wands, 3/8/13/18 for the four circlet tiers) doesn't multiply directly. The triggered mode multiplies each eligible affix's frequency by that affix's own level field before summing the pool denominator.

This is what makes circlets/coronets/tiaras/diadems and caster-class weapons so coveted for high-tier rolls. A Diadem (magic_lvl 18) doesn't roll Berserker's "more often" because of an 18× multiplier on Berserker's; it rolls Berserker's more often because the entire pool gets re-weighted by per-affix level, and Berserker's level=90 puts it near the top of that re-weighting. Filler affixes at level=1–10 are essentially unchanged; mid-tier affixes get moderate boosts; high-tier affixes (level 60+) become competitive in groups they'd otherwise lose.

Items with magic lvl > 0

Only 42 items in the entire game carry a non-zero magic lvl:

The frequency-multiplier trigger is binary — any non-zero magic lvl flips the engine into level-weighted mode at the same intensity. The per-tier scaling on circlets only matters for the additive ilvl boost below.

Worked example — Berserker's vs Slayer's on a Diadem

Group 125 (class skills) contains a +1 tier and a +2 tier per class. Within the Barbarian sub-pool:

On a regular helm of equivalent qlvl, Slayer's is 2× more common than Berserker's (4 vs 2). On a Diadem, Berserker's is 1.25× more common than Slayer's (180 vs 144) — the within-group +1/+2 ratio fully flips.

Group 125 also gets dramatically more weight in cross-group competition. Its constituent affixes have level=36 and level=90 — both well above the level=1–10 filler that dominates the prefix pool by raw count. Under the multiplier, group 125 punches far above its raw-frequency weight class.

Pool-level eligibility (additive)

Separately from the frequency multiplier, magic lvl also extends the affix-eligibility ceiling. The effective alvl for affix selection is:

if (item.magic_lvl > 0) {
  alvl = MAX(ilvl, qlvl) + item.magic_lvl   // capped at 99
}

A Diadem (qlvl=85, magic_lvl=18) effectively rolls at alvl=99 regardless of where it dropped, unlocking the highest-level affixes (e.g. Berserker's at level=90) even on a Diadem dropped at low ilvl. The two effects compound: items with magic_lvl get more affixes in their eligible pool AND those high-level affixes get amplified weighting within the pool.

Same affix, multiple rows

Many affixes appear in multiple rows because the engine needs different per-itype or per-tier mod ranges for the same display name:

• Sturdy appears twice for armo (qlvl 1 with ac% 10–20, qlvl 4 with ac% 21–30) — same Name, separate tier entries.
• Stout appears five times: lcha / scha / mcha / jewl (different itypes) and at different qlvl thresholds within charms.

The implication: filtering by Name won't give you "the row" — there isn't one. To know what an affix can do, query all rows with that Name and scan their itype*/level constraints.

frequency=0 vs spawnable=0 vs blank

These columns mean different things and overlap imperfectly. Three failure modes for "this row won't roll on a magic item":

• spawnable=0 — affix is engine-defined but never appears on naturally-rolled items. Used by uniques, sets, and crafted-recipe outputs.
• spawnable=blank — legacy entry with no explicit flag. Treated as not naturally spawning.
• frequency=0 (or blank) — this specific row isn't picked from the magic-affix pool. The same Name might still appear in other rows with non-zero frequency, so the affix as a whole can still roll.

In magicprefix, of 689 named rows: 603 roll, 66 are spawnable=0, 20 are spawnable=blank, and an additional handful are spawnable=1 but frequency=0 (rows that exist for engine reference but don't compete in the magic-affix pool — usually duplicates of spawnable rows).

If you're asking "can this affix appear on a magic item I'm rolling?", check all three.

Historical accumulation across versions

The version column reveals that this file is a historical accumulation, not a current snapshot. Affixes from every era of the game live in the same file:

• version = 0 — original Classic Diablo II (June 2000 release)
• version = 1 — Classic patches (v1.01–v1.06)
• version = 100 — Lord of Destruction expansion (June 2001) and everything after, including D2R additions

Old affixes are never removed. They stay in the file for save-game compatibility (legacy items on old characters still need their mod definitions resolvable), for unique-item references, and for version-context spawning (Classic-only realms draw from the version=0/1 pool; LoD/D2R can draw from all three). The Expansion row is the visual divider in the source file between Classic and LoD entries — an engine artifact, not an affix.

This accumulation is why the file is so much larger than what actually rolls in current play. The version × spawnable distribution in magicprefix:

The blank-spawnable cluster lives almost entirely in version=100: those are LoD-era entries the dev team chose to define but never wire into the active pool — present for engine reference, future-proofing, or planned content that didn't ship. The version=0/version=1 rows are the original Classic affixes; they're still spawnable on Classic realms but largely shadowed by their LoD equivalents on LoD/D2R.

Cross-references

• automagic — separate auto-attached-prefix system for class-specific bases (Sorc orbs, Amazon weapons, etc.). Doesn't interact with the magic-affix pool — auto-mods attach in addition, not instead.
• itemtypes — itype*/etype* reference the item-type taxonomy.
• itemstatcost — mod*Code resolves through Properties.txt to stats defined here.
• weapons / armor — magic lvl from these files multiplies frequency during affix-pool weighting.
• magicsuffix — identical schema, parallel pool. A magic item rolls one prefix and one suffix.
• PlayerClass.txt — the classspecific column references class codes defined here.
• Properties.txt — defines what each mod*Code resolves to.
• Colors.txt — the transformcolor column references color codes defined here.