From a3da5c2775fe795aeb6a9fa81b933096c69e8910 Mon Sep 17 00:00:00 2001 From: sganggs Date: Tue, 13 Oct 2026 04:47:58 +0800 Subject: [PATCH] =?UTF-8?q?0.2.6-dev:=20DESIGN=20=C2=A731.8=20says=20how?= =?UTF-8?q?=20PR=20#416=20by=20Cromemadnd=20sounded=20twice=20=E2=80=94=20?= =?UTF-8?q?its=20wheel-confirm=20hook=20restarted=20a=20Start=20that=20had?= =?UTF-8?q?=20run=200.3=20s=20(a=20purchase=20then=20a=20move)=20and=20its?= =?UTF-8?q?=20round-start=20sequence=20forced=20every=20piece;=20the=20sta?= =?UTF-8?q?te=20that=20follows=20a=20wheel=20drop=20never=20landed=20there?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/history/0.2.6.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/docs/history/0.2.6.md b/docs/history/0.2.6.md index dbf168a6..2c4d4070 100644 --- a/docs/history/0.2.6.md +++ b/docs/history/0.2.6.md @@ -142,8 +142,8 @@ has loaded) was fixed in 0.2.3 (§28.22: the late model continues Start at the e whose Start still plays keeps it and sounds nothing more, whether the clip runs on its model, is owed to a model still loading, or was cued less than a clip length ago. That covers a purchase followed by a move, and the round start's replay reaching a piece just put down. Only an idle prep piece lands. A battle unit never does: the sim's `deploy` events keep - the silent `onDeploy`, and audio.handleBattleEvents makes their sound (the PR's view-side sound would have doubled every - battle deployment). Nor does a piece that is attacking, dying, lifted by a drag or in another clip, or any piece while the + the silent `onDeploy`, and audio.handleBattleEvents makes their sound (the PR's view-side sound would have sounded most + battle deployments a second time). Nor does a piece that is attacking, dying, lifted by a drag or in another clip, or any piece while the tab is hidden (the clip and the suspended audio would play it stale on return). - Round start (`ui/gameLogic roundStartReplay`, `screens/game.js`, `render/app.js replayDeploys`). During 回合开始 the own board's pieces land one after another in deployment order, each turn chained 50 ms after the one before. The order is the @@ -160,10 +160,11 @@ has loaded) was fixed in 0.2.3 (§28.22: the late model continues Start at the e - Purchase and board triggers (`render/app.js setPrep`). An operator that has just arrived on the bench lands: a purchase, a reward or a grant, and a merge's elite on its bench slot or on the copy's tile. A summon that arrives with its owner's placement does not, nor does an item. A piece that a new state puts on a board tile it was not on lands when that state - arrives, whether it came from the bench, from another tile or as the partner of a swap. The PR also landed a piece at - the wheel's confirm, which sounded twice whenever the server answered after 0.3 s, and on every move on the bench and + arrives, whether it came from the bench, from another tile or as the partner of a swap. The PR landed a piece at the + wheel's confirm instead, restarting any Start that had run 0.3 s (a purchase followed by a move sounded twice); its + round-start sequence forced every piece, one that had just landed included, and it landed every move on the bench and every retreat. Here turning in place, a retreat and bench moves do not land. That is narrower than the PR's wheel hook, - which fired on every confirm. The deploy flash (`fx.deploy`) is unchanged. + which fired on every confirm, a turn in place included. The deploy flash (`fx.deploy`) is unchanged. **[ASSUMED]** The purchase and board triggers (the PR author's account). The 50 ms gap (`DEPLOY_REPLAY_MS`, the PR's value; no source gives the official one). Summon pieces taking part in the replay after the operators, as in the battle's