107 lines
7.0 KiB
Markdown
107 lines
7.0 KiB
Markdown
# Currency Wars route continuation audit
|
|
|
|
**2026-10-31 update:** An initial xaodev-based generated EliteBranch factory
|
|
has now been connected to the route fallback. The older unsupported-factory
|
|
statements below describe the preceding implementation. The new code passes
|
|
CW automated tests but has no Client gameplay confirmation; see
|
|
`CW-XAODEV-CLAUDE-HANDOFF.md` for provenance, limits and pending integration checks.
|
|
|
|
The captured route 2801 contains these node types after the first boss:
|
|
|
|
| Chapter | Sections in order |
|
|
| --- | --- |
|
|
| 2 | CampMonster, Supply, EliteBranch, Monster, Boss |
|
|
| 3 | CampMonster, Supply, EliteBranch, Monster, Boss |
|
|
|
|
These names are joined from `CurrencyWarsCatalog.json` stage routes and
|
|
`CurrencyWarsReferenceNodes.json` templates. They describe the template, not
|
|
necessarily a run's dynamically substituted node display.
|
|
|
|
`cwAdvanceRouteNode` now creates a captured empty Supply container and uses
|
|
`cwGenerateReferenceEnemyLayer` for other destinations. The enemy factory
|
|
accepts Boss, CampMonster and Monster; it still rejects EliteBranch. The
|
|
Monster factory uses the explicit replacement-camp policy documented in
|
|
`currency-wars-route-factory.md` because the old run's neutral camp is not
|
|
present in its saved protocol data.
|
|
Consequently a successful 2-1 battle does not establish that 2-2 or later
|
|
rooms can be played. Constructing the remaining node layers, pending
|
|
actions and rewards needs their corresponding native/reference rules and a
|
|
current-Client check; copying the first Supply's randomized inventory would not
|
|
prove the later rooms correct.
|
|
|
|
`cwCapturedSupplyLayer` derives the empty Supply node container from the
|
|
revision-bound transition capture and validates that it has no camp or enemy
|
|
branches. It neither copies the captured option list nor modifies a run. It is
|
|
now connected to route advancement. The generated RoundBegin path creates a
|
|
Supply offer from captured role variants and equipment. SupplyBox is not
|
|
implemented. Automated offer
|
|
generation checks pass; the new route is not yet verified in the Client.
|
|
|
|
## Updated FFGO Supply evidence
|
|
|
|
The user-supplied reference binary has SHA-256
|
|
`00a75ef82614977d951250705250c6ad478ef7cdde717c761f0c70244a84ed10`.
|
|
Its `gfPendingSupplyOf` reads the run rules `SupplyRarity`, `SupplyStar`,
|
|
`SupplyEmblems`, and `SupplyBox`. `gfPendingFillSupplyOptions` reads
|
|
`GridFight_BaseSupplyRoleNum`, draws roles and selects equipment from `Basic`,
|
|
`Craftable`, or `Emblem`, depending on the chapter and rules. These names were
|
|
resolved from the reference binary, not inferred from the earlier dump.
|
|
`gfFxHProjectRunState` also projects `ExtraSupplyOption` into the additional
|
|
option count consumed by `gfPendingFillSupplyOptions`; the generated offer
|
|
uses the saved run rule and checks the combined count before drawing.
|
|
|
|
The updated reference also calls `gfPendingApplySupplyEquipChance`, which
|
|
reads `SupplyEquipChance`, `SupplyEquip`, and `SupplyEquipChapter`. When the
|
|
conditions match, it can replace equipment in one randomly selected option.
|
|
The generated offer uses saved run rules and validates replacement items
|
|
against captured equipment. Pool accounting and all run modifiers need more
|
|
comparison; later node families still need implementation and Client checks.
|
|
|
|
When a Supply selection has no captured next-node transition,
|
|
`cwSelectSupply` now delegates to the generated route factory on the same
|
|
detached transaction and preserves finish/unlock/level/pending notification
|
|
order. The existing captured path remains unchanged. This removes the separate
|
|
capture-only restriction after a generated Supply choice, but the factory
|
|
still rejects unsupported destination families, including the EliteBranch
|
|
following 2-2; the selection remains uncommitted until that family is
|
|
implemented. No Client run has exercised this fallback.
|
|
|
|
For a selected Encounter branch, the battle settlement now grants supported
|
|
gold, EXP, or item rewards when the reported progress reaches the branch's
|
|
threshold, using the selected server-side drop list on the detached snapshot.
|
|
Unmapped reward types fail without committing. Perfect-clear monster Orb
|
|
generation is not implemented; Client verification is still outstanding.
|
|
|
|
The native captured Encounter at route 2801 chapter 1 section 4 contains two
|
|
branch displays, each with its own penalty, monster wave and `BOAMLLHPNEC`
|
|
drop. A read-only check of the saved run at chapter 2 section 1 generated its
|
|
next Supply node and four choices on a detached copy; the saved run was not
|
|
written and no Client interaction was performed. The latest FFGO's
|
|
`gfRouteFillEliteBranch` constructs branch IDs from the node template's first
|
|
parameter and option kind, resolves difficulty through
|
|
`gfRouteEliteBranchDifficulty`, and builds the reward in
|
|
`gfRouteEliteOptionReward`. These are useful evidence, but matching the later
|
|
branches to this Client's option, penalty and difficulty data remains open.
|
|
|
|
After the final node, `cwAdvanceRouteNode` returns `CW route has no next node`.
|
|
At zero HP, `finishCurrencyWarsBattle` returns `CW defeat settlement requires
|
|
terminal-run handler`. Neither path currently settles the run. FFGO's extracted
|
|
descriptor names settlement reasons Quit=1, HpZero=2, and Finish=3; the current
|
|
Client's obfuscated enum has matching numeric slots, but only Quit=1 has been
|
|
confirmed for the current implementation. The reference `gfSettleSend` builds
|
|
and archives a settlement record before sending the settlement notification.
|
|
The names and fields of its rank/reward/archive components must be mapped to
|
|
## Pipeline Integration Test Verification
|
|
|
|
An automated end-to-end integration test (`TestCurrencyWarsSupplyToEncounterBattleSettlementPipeline`) in `internal/gameserver/currency_wars_xaodev_test.go` has verified the full generated route progression on an isolated temporary environment:
|
|
1. **Supply Selection (Route 2801, Ch 2, Sec 2)**: Completes supply selection and advances to Ch 2, Sec 3 (`EliteBranch`).
|
|
2. **Xaodev Encounter Generation**: Generates the two-branch encounter layer via `cwGenerateXaodevEncounter`, setting the server-side runtime marker `XaodevEncounter/2801/2/3:1` in `runtime.Rules`.
|
|
3. **Round Preparation**: Transitions the round state to `SelectingEncounter` via `cwGeneratedRoundPreparation`.
|
|
4. **Branch Selection & Difficulty Bonus**: Selecting Branch 2 correctly applies the branch difficulty bonus (`baseStage.EnemyHardLevel + branchAdd`) to `stage.ANJBLBEOJND.PIJBPDPEODG` and transitions to `ReturnPreparation`.
|
|
5. **ReturnPreparation**: Safely clears the pending queue.
|
|
6. **Battle Building**: `buildCurrencyWarsBattle` produces the scene battle info with matching hard level and verified battle avatars.
|
|
7. **Settlement & Clean Difficulty Reset**: `finishCurrencyWarsBattle` credits rewards (gold and level/exp), advances the route to Ch 2, Sec 4 (`Monster`), and resets branch difficulty back to 0.
|
|
8. **CAS Roundtrip Persistence**: Reloading from storage verifies that state updates, monotonic revisions, and difficulty resets persist accurately.
|
|
|
|
*Note: All automated tests pass; actual in-game battle flow and client rendering await user verification.*
|