sganggs
c236273cf2
- The S2 ward ("期间持续使自身与该目标周围的敌人陷入沉睡") re-applies a 0.5 s sleep every 0.25 s, so an enemy held asleep
was one entry for garrison_125 (「每当范围内有敌人或干员进入沉睡或晕眩时」 萨尔贡 / 精准 +1, elite +2, at most 24 / 48 per
battle). The reporter's first-hand memory of the official mode: 「攻击范围内有陷入沉睡就开始迅速增加直至上限」.
- The pulse now passes applyStatus `reenter` (a new opt-in: statusApplied reports `entered`; the buff refreshes as
before) — once per enemy and pulse, not while a longer sleep from elsewhere holds it. With one enemy in her range the
trait reaches its cap 5.63 s into S2; an enemy outside her range still adds nothing; a refresh elsewhere is still no
entry (the garrison rule is unchanged). No enemy wakes between pulses. The pulse timing is [ASSUMED] (not in the data).
- Tests: garrisons_battle — new 缇缇 125 + S2 test (normal and elite: an enemy at her back adds nothing over 8 s of
pulses; an enemy in range beside both wards, one entry per pulse, takes the trait to 24 / 48 within 6.5 s).
- Docs: DESIGN §24.8 (and the §24 intro), the Battle.applyStatus / garrison / kit comments.
- Golden: roster-042 (缇缇 S2): her trait's 24 layers come within her first S2 (26–37 s) instead of over four casts up
to 177 s; same totals (capped), and the earlier layers end the fight at 166.97 s instead of 182.03 s, 5 knock-outs
instead of 7.
Golden results
The simulation is deterministic: the same seed and inputs give the same battle and the same match, bit for bit. These files record the exact outcome of a fixed corpus of seeded scenarios, so a change that alters gameplay — even one meant to be a pure refactor that only reorders random draws, hook order or iteration order — fails loudly instead of slipping through.
tools/golden.mjsbuilds the corpus fromdata/*.json(fixed order, fixed seeds) and reduces every scenario to a digest. Its header documents the families and the digest fields.test/golden/<family>.jsonhold the digests (roster,bonds,fields,matches).test/golden.test.jsrecomputes them and compares. On a mismatch it prints the scenario, the field and old → new.
The corpus
| family | what runs |
|---|---|
roster |
49 battles: every visible chess record (normal and elite) with every selectable skill and module (DESIGN §16), 12 operators per battle on a real stage (all 11 in turn) against the round's real wave three times over, every non-leader enemy kind of data/enemies.json as extra spawns (half of them bounties), placeable summons on the board, every equipment item, band, battle-side 机变 card and stage map card in turn, bonds from the board |
bonds |
46 battles: every bond at its activation threshold (1 layer) and at its top tier (999 layers) |
fields |
22 battles: every Final Assault / Hidden Core leader on a pair and a solo template (shared pool, 200 s cap) and the 联防 field with 1 and 2 helpers (carried HP / SP, a knocked-out operator, two leakers' enemies) |
matches |
16 bot-only matches to the end in virtual time: solo 标准 / 险境 / 绝境 / 终极 × 2 seeds, co-op 2 / 3 / 4, one server-run combat match, two runs boosted to the Hidden Core |
Battles go through the production BattleSpec path (server/sim/spec.js, as browsers and the server's headless fields
run them); matches construct Match directly with a VirtualScheduler. Every option is explicit, so a change to a
test-harness default never moves a digest.
What a digest ignores on purpose (it does not affect gameplay): object key order, engine unit ids (snapshot ids are renumbered by first appearance, units are named by board uid or def id), board piece uids, the order of client events within a tick (they are counted, not hashed) and wall-clock time. Damage / healing sums are rounded to integers and HP to 2 decimals.
npm test runs the fast subset (the scenarios marked "fast": true: every chess record with its default loadout,
every stage and every non-leader enemy kind, every bond at its top tier, six fields, five matches — 53 of the 133). GOLDEN_FULL=1 checks everything.
Workflow
GOLDEN_FULL=1 node --test test/golden.test.js # the whole corpus (≈ 20 s with 4 worker threads)
node --test test/golden.test.js # the fast subset
npm run golden # the same comparison from the tool (all families, a short report)
npm run golden:update # recompute and rewrite test/golden/*.json
node tools/golden.mjs --twice # determinism: the corpus twice in one process, the second pass reversed
- A refactor commit must never change these files. Run
GOLDEN_FULL=1 node --test test/golden.test.jsbefore committing it. If a digest moves, the refactor changed behaviour: find out why (the first differing value ofsnapssays when two runs parted, in 10-game-second steps) instead of updating the files. - An intended gameplay change (a fix, new content, a data rebuild): run
npm run golden:updateand commit the changed files together with the change, saying in the commit message which scenarios moved and why. - Reviewing the diff: every scenario is a block of its own and every unit / enemy / round is one line, so a diff
shows which scenarios moved and which values changed. A change confined to the scenarios that contain the touched
operator, enemy or rule is expected; a change everywhere (every
rngDraws, everysnaps) means something global moved — the RNG draw order, the tick order, a shared rule. - Adding to the corpus (a new family, more scenarios, a new digest field) changes the files by design: do it in a commit of its own, never together with a refactor.
- A new engine hook, event or chess record does not change the digests of the existing scenarios by itself — the
hook list is frozen in the tool and the corpus is regenerated only on
golden:update— but new data records do join the corpus there (the roster family enumeratesdata/chess.json).