Damage-model grouping: 40 misplaced modifiers, plus burn and two wrong numerators

[shaumik]

Closes item 5 in docs/royale-followups.md.

Showdown applies damage modifiers in three groups, and the group decides where the number truncates: base power before the formula, the stat the formula reads, and the finished figure. This engine exposed every ability and item damage influence as a single lumped multiplier per side, so all of them landed in the final group. Forty of the forty-eight modelled modifiers were in the wrong one.

Two things followed, and they are why this was a wrong number rather than a wrong shape. The final group multiplies a figure that already contains the +2 from base + 2, which canon never scales; and base power stopped being truncated to a whole number before entering the formula, so the error compounded with type effectiveness instead of staying flat. Everything misplaced this way was systematically a little high.

Commits

		fixtures
416b111	base-power group — 29 handlers	0 of 147
b57a7ed	stat group — 11 handlers, and burn with them	110 of 147
1e2cc8c	Life Orb and Metronome numerators (item 9)	17 of 147
8f7b246	both benchmark tables re-derived	—

Split so the risky commit is eleven changes with the mechanism already proven by the first one, rather than forty landing together with a fixture re-record.

The audit was re-derived first, and confirmed

The doc says not to trust its own table. Re-derived against a fresh upstream checkout before any code moved: 48 modelled modifiers — 29 base-power, 11 stat, 8 already correct. Unchanged from what was filed.

Two notes for whoever reads it next. The engine models 66 damage-influencing registry entries, not 48; the other 18 are the resist berries, which are onSourceModifyDamage and correctly final — "58 of 66" is the same finding with the berries counted in. And several canon modifiers are not the decimal they look like: Muscle Band is [4505, 4096] where toMod(1.1) gives 4506, Reckless and Iron Fist are the type boosters' 4915 rather than a clean 1.2. The moved handlers spell the numerator.

Three things the handoff had wrong or missing

Technician needed no fix, and none was made. The doc claimed canon reads the base power after earlier modifiers, so the engine's raw m.Power <= 60 was half a bug. It isn't: Battle.comparePriority sorts handlers priority high to low, and Technician's onBasePowerPriority: 30 is the highest in the entire gen-9 dataset — nothing runs before it, so this.event.modifier is 1 and modify(bp, 1) is bp. Upstream's own test/sim/abilities/technician.js pins both sides: the boost is refused after a gen-7 Battery (22) and granted after a gen-9 Steely Spirit (22), because data/mods/gen7/abilities.ts overrides Technician down to 19. Withdrawn in the doc, with the reasoning recorded at the registry entry so it does not get "fixed" later.

Burn belonged to this bug and was not on the list. It is a condition rather than an ability or item, so the audit never looked at it — but canon applies it in modifyDamage after type effectiveness, as a modifier on the damage, and skips it outright for a Guts holder. This engine halved the Attack stat. Guts could not move into the stat group without settling that: its old implementation was Atk ×1.5 plus ×2 on the finished damage to cancel a halving applied to a different number — three multipliers standing in for canon's one, landing on neither of canon's figures.

The stat half moved 99 fixtures, not a handful. The doc said "five of these are on corpus teams", which is exactly right — Choice Band, Choice Specs, Guts, Solar Power, Thick Fat. It is easy to read that as five fixtures. Four of six archetypes carry one, so 18 of 21 pairings do, which is 126 of the 147 games before a single roll is considered. Attributed by measurement rather than assumed: with burn left where it was, the stat modifiers alone move 99; relocating burn adds the other 11.

Two further defects, fixed with their group

Both are the same dispatch and were found by reading upstream rather than reasoning from the mechanism's name.

• The weather stat boosts were keyed on the move's category. Sandstorm's Rock Sp. Def boost is onModifySpD and snow's Ice Defense boost is onModifyDef, and canon keys the defensive stat event on the move's override — unlike the offensive one, which it re-keys to the category. A Psyshock therefore runs ModifyDef, and a Rock-type in sand gets nothing from it, where reading the category handed the boost out anyway. Pinned by two cases differing only in which stat the move reads.
• The offensive event is re-keyed to the category while the raw read is not. attackStat = (category === 'Physical' ? 'atk' : 'spa') runs after calculateStat(attackStat…) has already read the override, so a Body Press reads Defense and still runs ModifyAtk — a Choice Band and a Thick Club boost it. Reading the override slug for the item lookup silently dropped that.

Tests, written first and watched failing

internal/engine/damage_grouping_test.go transcribes Showdown's chain from the reference rather than factoring it out of computeDamage, and asserts the exact sixteen-roll spread per modifier. A relative assertion ("with the item it should be bigger") passes in every group, which is how forty of these sat here unnoticed.

It opens with a control that must pass unchanged, so a mistranscribed reference cannot masquerade as a forty-instance bug. All 25 cases failed before their commit, each in the predicted direction, and pass after. Each group also gets a whole-battle test through ResolveTurn — the number proves the formula, a played turn proves the wiring reaches it.

Four ratio assertions went red and none was loosened. "×1.5 within a point" and "≈ half" describe a final-group modifier; once the modifier is on the stat the finished damage is not in that ratio at all, because the boosted stat still has to survive the division by the defense and by 50. A Mystic Water Surf correctly goes 24 → 30, a 25% jump from a 19.995% modifier. Each now compares against the same matchup with the raw stat or base power pre-modified, which is exact and states the group. One of them — Thick Fat in TestAbilityBattleIntegration — was passing only on its seed and went red under Part II's perturbation audit.

Verification

go test ./... -count=1, make test-showdown and make lint are green.

• Showdown port unchanged at 401 pass / 465 gaps. These are rounding corrections, not missing mechanics, and gapBug stays 0.
• Perturbation audit adds no new failures beyond the six that predate this work — filed as item 11, confirmed pre-existing by running it against main.
• Both benchmark tables re-derived, as Section 8 of docs/benchmark.md requires. The expectimax sweep's finding survived a third time: the d1→d2 drop measured 11.7 points against 11.4 and 11.5 on the two previous engines, and every new point estimate landed inside the previous engine's interval. The spread-impact table came from go run ./cmd/spread-impact.

Also filed, not fixed

• Item 10 — Reckless ignores crash-damage moves (move.recoil || move.hasCrashDamage). High Jump Kick and Jump Kick are both in the dataset carrying the flag; it needs a field through cmd/data-sync, which is the same omission that cost Sonic Boom its damage field.
• Item 11 — four tests drifted back into pinning the RNG in Widen move coverage: 24 moves off the denylist, 40 ledger rows closed #154.

docs/engine-findings.md is a closed record of the rounding pass; where it quotes figures this work supersedes, it now says so and points at the current ones rather than being rewritten.

---

Generated by Claude Code