feedback5 R19A: a stunned or frozen enemy is blocked by contact where it stands — an operator redeployed beside a frozen 隐匿 enemy blocks it and so reveals it (GitHub #232, @ccyl; the repro and the cause by @kukiC); golden: 52 scenarios move
ai.js updateEnemy returned on `stunned && !e.hidden` before the contact check (Battle._checkBlock), and 冻结 / 沉睡 / 浮空 set `stun` too, so a held enemy was never checked: 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 (0.1.4 had it too). PRTS 异常效果: STUNNED / FROZEN stop the enemy's moves and attacks and hold no 不可阻挡 (BLOCK_FREE), which SLEEPING / LEVITATE do; 术语释义 冻结 names no block; 作战机制 §碰撞体积与位置识别: an operator deployed onto an enemy blocks it, a standing one included. The held branch now runs the same check before it returns (no move, no attack, as before): _checkBlock still refuses 沉睡 / 浮空 / 恐惧 / 不可阻挡, an enemy held short of contact is blocked only once it walks in (the same point as without the status), and the 3 s 隐匿 window after a block's end is unchanged. A block the held enemy already holds is still not re-checked (a reborn() 重生 keeps its blocker, as in 0.1.4: noted as open in §25.22.1). Golden — in each scenario the first divergence is a stunned or frozen enemy blocked during its status by an operator or summon it touched with a free slot (traced one by one with an instrumented copy): roster-003, -014, -015, -016, -017, -018, -019, -031, -036, -038, -040, -041, -045, -046, -047; bond-indomShip-high, bond-kazimierzShip-high, bond-raidShip-low, bond-siracusaShip-low, bond-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; matches 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. standins unchanged. Tests: test/sim/feedback5-frozen-reblock.test.js (9; the four #232 cases and the 晕眩 / 冻结 capacity cases fail on the parent). Docs: CHANGELOG 0.2.0 规则(按官方), docs/history/0.2.0.md §25.22.1, docs/SIM.md (§1.2 Blocking, stun, freeze), docs/design/engine.md, docs/PLAYING.md.
This commit is contained in:
1 parent
0b306baa49
commit
9123e76509
13 files changed
+959
-750
No files matched your search
+7
-4
@@ -246,8 +246,11 @@ the `unblockable` flag (恐惧, 诱导 and many enemy abilities carry it), 浮
|
||||
enemy falling asleep is released at once, its slot freeing for the next enemy, and stays where it is; once awake it is
|
||||
blocked again only by a blocker with room, else it walks on — DESIGN §24.9). It is checked every tick for every
|
||||
unblocked enemy, moving or not: an enemy that overlaps an operator when its blocker dies / is withdrawn / is stunned, or when the operator's
|
||||
blocked enemy dies, is taken over at once; an enemy that finds no room walks on (pass-through). Several blockers in
|
||||
contact → the nearest [ASSUMED]. A head-on enemy therefore stops at contact, ~0.71 tile from the blocker's centre, on the
|
||||
blocked enemy dies, is taken over at once; an enemy that finds no room walks on (pass-through). A stunned or frozen
|
||||
enemy is checked too — 晕眩 / 冻结 hold no 不可阻挡 (PRTS 异常效果: the STUN / FROZEN state machines stop its moves and
|
||||
attacks) —, so an operator redeployed beside a held enemy blocks it where it stands and lifts its 隐匿; one held short of
|
||||
contact is blocked once it walks in after the status (GitHub #232; until 0.2.0 the check waited for the status to end).
|
||||
Several blockers in contact → the nearest [ASSUMED]. A head-on enemy therefore stops at contact, ~0.71 tile from the blocker's centre, on the
|
||||
tile in front of it (PRTS 作战机制: a blocked enemy's collider does not enter the blocker's tile; the official few
|
||||
hundredths of a tile of deceleration are not modelled), and **every blocker** — melee units (要塞 / 领主 / 哨戒铁卫
|
||||
included), summons (流形's melee copy) and a ranged operator standing on a melee tile alike — may always target the
|
||||
@@ -605,8 +608,8 @@ of coverage per 3 s), kept because the current wording no longer says so (feedba
|
||||
|
||||
| key | effect | value |
|
||||
|---|---|---|
|
||||
| `stun` | cannot act / move; **a stunned operator blocks nothing** (its blocked enemies are released: taken over by another operator in contact with room, else they walk on — §1.2 Blocking) | – |
|
||||
| `freeze` | stun; **enemies** also RES −15 | – |
|
||||
| `stun` | cannot act / move; **a stunned operator blocks nothing** (its blocked enemies are released: taken over by another operator in contact with room, else they walk on — §1.2 Blocking); a stunned enemy is still blocked by contact (晕眩 holds no 不可阻挡 — GitHub #232) | – |
|
||||
| `freeze` | stun (a frozen enemy is still blocked by contact, as a stunned one); **enemies** also RES −15 | – |
|
||||
| `cold` | ASPD −30; a 2nd cold while cold ⇒ `freeze` for max(remaining cold, the incoming cold after 抵抗) — PRTS 术语释义 寒冷 「持续时间取双方之中最高」 (`COLD_FREEZE_DURATION` 3 s only when neither side has a duration; unless frozen-immune). On an enemy (友方寒冷) the pair becomes that freeze and no cold is left — 「两两一对产生友方冻结」, so a lone cold on a frozen enemy waits for a partner (0.2.0; the 谢拉格 wind no longer freezes for good); on an operator (敌方寒冷) the longer cold stays on with the freeze. [ASSUMED] the one catalogue cold uses the 友方 max for an enemy-applied cold too | – |
|
||||
| `sleep` | 无敌且无法行动: inactive, untargetable, **takes no damage** (unless the attacker profile has `hitSleep` or the damage `ignoreSleep`), blocks nothing; PRTS 异常效果 SLEEPING = 无法行动+无敌+**不可阻挡**: an enemy asleep **cannot be blocked and takes no block slot** — its blocker lets go at once (the slot frees for the next enemy), it stays where it is, and when it wakes it is blocked again only by a blocker with room, else it walks on (DESIGN §24.9) | – |
|
||||
| `slow` | moveMul 1 − value (*strongest*) | default 0.5 |
|
||||
|
||||
Reference in new issue
Block a user