feedback5: DESIGN §25.22 — the header and intro of round 19's four fixes (#232, #236, #173, #235), its subsections in order, the §25 intro list
This commit is contained in:
1 parent
8b780c1b5b
commit
0255afd12b
1 file changed
+46
-38
+46
-38
@@ -45,7 +45,9 @@ battle-history request postponed by the owner, the hotkey request built in §25.
|
||||
type of content packs (a
|
||||
language is a file in the language folder) → §25.20; the last stream of that batch, CB1, bonds, strategies and items (the
|
||||
谢拉格 wind's endless freeze, 埃芒加德's and M3茧甲's 复活 as a knock-out and a free redeploy, 佩佩's paid refresh, the 炎佑 on
|
||||
the medic's slot, 凯瑟琳's offer, the hidden layers on the result card; the official behaviours pinned) → §25.21.
|
||||
the medic's slot, 凯瑟琳's offer, the hidden layers on the result card; the official behaviours pinned) → §25.21; and, before the release, four GitHub reports of round 19 (a stunned or frozen enemy blocked by contact, #232; the
|
||||
round-start banner of an eliminated player or a spectator seat, #236; 干员调配 without its game data, #173; the official
|
||||
result box and battle-over sounds of the approved PR #112, #235) → §25.22.
|
||||
|
||||
Decisions of the owner: 2026-10-04 — the server stays on plain `node:http` + `ws`, no web framework (§25.1);
|
||||
2026-10-05 — the 补位 plan (§25.3); the 自选编队 rules, the collab operators out of the pool, ISW-A refused (§25.4);
|
||||
@@ -1857,6 +1859,49 @@ are.
|
||||
and an 进阶 set; and the pair counts once toward the 3 members.
|
||||
- Pinned: `test/content/feedback5-cb1-pins.test.js`.
|
||||
|
||||
### 25.22 GitHub round 19, fixed before the release (the owner's decision of 2026-10-07) — `sim/ai.js updateEnemy`, `ui/gameLogic/phases.js`, `screens/game.js`, `screens/loadout.js`, `match/settle.js`, `match/views.js`, `ui/components.js ResultDialog`
|
||||
|
||||
The owner held 0.2.0 for the new GitHub reports of 2026-10-06 (#214–#251, triaged in round 19): the four real ones are fixed
|
||||
here, each reproduced first; the rest were answered (not a bug, already fixed in 0.2.0, or left for 0.2.1).
|
||||
|
||||
#### 25.22.1 GitHub #232 「再部署之后的干员无法阻挡破隐被冰冻的隐身怪」 (@ccyl; the repro and the cause by @kukiC): a stunned or frozen enemy is blocked by contact — `sim/ai.js updateEnemy`
|
||||
|
||||
- **Seen**: a 隐匿 enemy kept frozen beside an operator who falls hides again 3 s after the block ends; the operator
|
||||
redeploys on its tile — the enemy inside its block radius, a slot free — and neither blocks nor reveals it until the
|
||||
freeze ends. Measured on 0b306ba with kukiC's steps (a block-2 operator, the enemy 0.2 tile from its centre): a tick after
|
||||
the redeploy, not blocked and still 隐匿; the freeze removed, blocked and revealed on the next tick. 晕眩 the same, and
|
||||
without 隐匿 the same (nothing to reveal). 0.1.4 had it: v0.1.4 gives the same output (the same early return).
|
||||
- **Official**: PRTS 异常效果 — STUNNED and FROZEN switch the state machine (no attack, no skill; an enemy cannot move);
|
||||
neither holds 不可阻挡 (BLOCK_FREE 「无法阻挡/被阻挡,自动解除阻挡」), which SLEEPING and LEVITATE do. 术语释义 冻结
|
||||
「无法移动、攻击及使用技能」 names no block, unlike 沉睡 「无法阻挡/被阻挡」. 作战机制 §碰撞体积与位置识别: an operator deployed
|
||||
onto an enemy blocks it, one standing still included — a block needs contact, not movement. [ASSUMED] no page names the
|
||||
frozen / stunned case in words; it follows from those definitions.
|
||||
- **Cause**: updateEnemy returned on `stunned && !e.hidden` before the contact check (`Battle._checkBlock`), and 冻结 /
|
||||
沉睡 / 浮空 set `stun` too (units.js): a held enemy was never checked, so an operator redeployed or deployed beside it, a
|
||||
slot freeing up or a push / pull into contact with a stun all waited for the status to end (`e.hidden` there is off the
|
||||
field, not 隐匿).
|
||||
- **Now**: the held branch runs the same check before it returns (no move, no attack, as before): a stunned or frozen enemy
|
||||
in an operator's block radius with a free slot is blocked where it stands, and the block lifts its 隐匿; the 3 s window
|
||||
after a block's end is unchanged. `_checkBlock` still refuses 沉睡 / 浮空 / 恐惧 / 不可阻挡, and an enemy held short of
|
||||
contact is blocked only once it walks in after the status, at the same point as without it — the rule of a moving or
|
||||
standing enemy (a 束缚 one, which is not stunned, was already blocked there).
|
||||
- Open, not changed (not #232): the held branch still does not re-check a block the enemy already holds, so a held enemy
|
||||
that gains 不可阻挡 through a plain buff keeps its blocker until the stun ends — a `reborn()` 重生 (主角阵营角色 …: the buff
|
||||
carries `stun` + `unblockable`) stays blocked through it, as in 0.1.4, though PRTS 特殊机制 重生 gives 无敌 + 无法阻挡 and
|
||||
`reborn()`'s comment says its blocker lets go. Re-checking it would move two more golden scenarios (roster-012,
|
||||
standin-04).
|
||||
- Golden: 52 scenarios — roster-003, -014 … -019, -031, -036, -038, -040, -041, -045 … -047; bond-indomShip-high,
|
||||
-kazimierzShip-high, -raidShip-low, -siracusaShip-low, -suntShip-low; boss-boss_3-solo, boss-boss_4-pair,
|
||||
boss-boss_7-solo, hidden-boss_8-pair, hidden-boss_9-pair, hidden-boss_10-pair, unite-2; solo-FUNNY-1, solo-NORMAL-2,
|
||||
solo-HARD-2, solo-ABYSS-1, coop2-NORMAL-3, coop2-HARD-4, coop3-ABYSS-5, coop2-NORMAL-8-serverrun, coop2-NORMAL-70-diy;
|
||||
diy-003, -004, -026, -034, -035, -056, -057, -065, -066, -070, -071, -094, -095, -101, -102, -103. Traced one by one with
|
||||
an instrumented copy: in each the first divergence is a stunned or frozen enemy blocked during its status by an operator
|
||||
or summon it touched with a free slot, before or inside the first differing snapshot window of the battle scenarios;
|
||||
every scenario that moved has one.
|
||||
- Tests: `test/sim/feedback5-frozen-reblock.test.js` (9: the four #232 cases and the 晕眩 / 冻结 capacity cases fail on
|
||||
0b306ba; the contact-only, 束缚 and refusal guards pass on both). Docs: docs/SIM.md (§1.2 Blocking, `stun`, `freeze`),
|
||||
DESIGN §5 (design/engine.md), docs/PLAYING.md.
|
||||
|
||||
#### 25.22.2 GitHub #236 「被淘汰后每回合开始横幅仍显示「资金已到账」(观战席同理)」 (@2321Robin, with PR #237): the round-start banner reads 观战中 to an eliminated player and a spectator seat — `ui/gameLogic/phases.js phaseBanner`, `screens/game.js`
|
||||
|
||||
- **Seen** (a real Match with fake battles: three humans and a spectator seat, p_0 out of LP at round 1's settlement):
|
||||
@@ -1935,40 +1980,3 @@ are.
|
||||
the parent), `test/match/playtest6-matchflow.test.js` #235 (2; the 联防 one fails on the parent: losses = the LP
|
||||
settled, no result ticker, gone in the next phase), SP_E2E `test/ui/resultbox.e2e.test.js` (3, mock variants
|
||||
`unite[,through][,helper|,dead]`). Docs: PLAYING.md §1 / §5, design/network.md, design/client.md, design/match.md.
|
||||
#### 25.22.1 GitHub #232 「再部署之后的干员无法阻挡破隐被冰冻的隐身怪」 (@ccyl; the repro and the cause by @kukiC): a stunned or frozen enemy is blocked by contact — `sim/ai.js updateEnemy`
|
||||
|
||||
- **Seen**: a 隐匿 enemy kept frozen beside an operator who falls hides again 3 s after the block ends; the operator
|
||||
redeploys on its tile — the enemy inside its block radius, a slot free — and neither blocks nor reveals it until the
|
||||
freeze ends. Measured on 0b306ba with kukiC's steps (a block-2 operator, the enemy 0.2 tile from its centre): a tick after
|
||||
the redeploy, not blocked and still 隐匿; the freeze removed, blocked and revealed on the next tick. 晕眩 the same, and
|
||||
without 隐匿 the same (nothing to reveal). 0.1.4 had it: v0.1.4 gives the same output (the same early return).
|
||||
- **Official**: PRTS 异常效果 — STUNNED and FROZEN switch the state machine (no attack, no skill; an enemy cannot move);
|
||||
neither holds 不可阻挡 (BLOCK_FREE 「无法阻挡/被阻挡,自动解除阻挡」), which SLEEPING and LEVITATE do. 术语释义 冻结
|
||||
「无法移动、攻击及使用技能」 names no block, unlike 沉睡 「无法阻挡/被阻挡」. 作战机制 §碰撞体积与位置识别: an operator deployed
|
||||
onto an enemy blocks it, one standing still included — a block needs contact, not movement. [ASSUMED] no page names the
|
||||
frozen / stunned case in words; it follows from those definitions.
|
||||
- **Cause**: updateEnemy returned on `stunned && !e.hidden` before the contact check (`Battle._checkBlock`), and 冻结 /
|
||||
沉睡 / 浮空 set `stun` too (units.js): a held enemy was never checked, so an operator redeployed or deployed beside it, a
|
||||
slot freeing up or a push / pull into contact with a stun all waited for the status to end (`e.hidden` there is off the
|
||||
field, not 隐匿).
|
||||
- **Now**: the held branch runs the same check before it returns (no move, no attack, as before): a stunned or frozen enemy
|
||||
in an operator's block radius with a free slot is blocked where it stands, and the block lifts its 隐匿; the 3 s window
|
||||
after a block's end is unchanged. `_checkBlock` still refuses 沉睡 / 浮空 / 恐惧 / 不可阻挡, and an enemy held short of
|
||||
contact is blocked only once it walks in after the status, at the same point as without it — the rule of a moving or
|
||||
standing enemy (a 束缚 one, which is not stunned, was already blocked there).
|
||||
- Open, not changed (not #232): the held branch still does not re-check a block the enemy already holds, so a held enemy
|
||||
that gains 不可阻挡 through a plain buff keeps its blocker until the stun ends — a `reborn()` 重生 (主角阵营角色 …: the buff
|
||||
carries `stun` + `unblockable`) stays blocked through it, as in 0.1.4, though PRTS 特殊机制 重生 gives 无敌 + 无法阻挡 and
|
||||
`reborn()`'s comment says its blocker lets go. Re-checking it would move two more golden scenarios (roster-012,
|
||||
standin-04).
|
||||
- Golden: 52 scenarios — roster-003, -014 … -019, -031, -036, -038, -040, -041, -045 … -047; bond-indomShip-high,
|
||||
-kazimierzShip-high, -raidShip-low, -siracusaShip-low, -suntShip-low; boss-boss_3-solo, boss-boss_4-pair,
|
||||
boss-boss_7-solo, hidden-boss_8-pair, hidden-boss_9-pair, hidden-boss_10-pair, unite-2; solo-FUNNY-1, solo-NORMAL-2,
|
||||
solo-HARD-2, solo-ABYSS-1, coop2-NORMAL-3, coop2-HARD-4, coop3-ABYSS-5, coop2-NORMAL-8-serverrun, coop2-NORMAL-70-diy;
|
||||
diy-003, -004, -026, -034, -035, -056, -057, -065, -066, -070, -071, -094, -095, -101, -102, -103. Traced one by one with
|
||||
an instrumented copy: in each the first divergence is a stunned or frozen enemy blocked during its status by an operator
|
||||
or summon it touched with a free slot, before or inside the first differing snapshot window of the battle scenarios;
|
||||
every scenario that moved has one.
|
||||
- Tests: `test/sim/feedback5-frozen-reblock.test.js` (9: the four #232 cases and the 晕眩 / 冻结 capacity cases fail on
|
||||
0b306ba; the contact-only, 束缚 and refusal guards pass on both). Docs: docs/SIM.md (§1.2 Blocking, `stun`, `freeze`),
|
||||
DESIGN §5 (design/engine.md), docs/PLAYING.md.
|
||||
Reference in new issue
Block a user