0.2.6-dev: DESIGN §31.8 says how PR #416 by Cromemadnd sounded twice — its wheel-confirm hook restarted a Start that had run 0.3 s (a purchase then a move) and its round-start sequence forced every piece; the state that follows a wheel drop never landed there
This commit is contained in:
1 parent
461a7747e1
commit
a3da5c2775
1 file changed
+6
-5
@@ -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
|
||||
|
||||
Reference in new issue
Block a user