33 lines
3.2 KiB
Markdown
33 lines
3.2 KiB
Markdown
# AA round selection sync — 2026-10-25
|
|
|
|
## Confirmed path and defect
|
|
|
|
The Srtool AA dropdown posts `peak_group_id` to `/api/monster-settings/aa-round`; the SDK writes `persistent.aa_round_selection`. A read-only check returned group 2 with the configured Client version. The running Game executable contains the selection reader.
|
|
|
|
Before this change, the selected group affected only `GetChallengePeakDataScRsp.CurrentPeakGroupId` when the Client happened to request AA data. Saving from Srtool did not invalidate cached Client module state. `StartChallengePeak` continues to consume the actual requested PeakID; it does not consult the UI selector and must not silently substitute a different room.
|
|
|
|
The protocol's `ChallengePeakGroupDataUpdateScNotify` contains one `ChallengePeakGroup`, with no current-group field. Sending that notification is not proof that the selected current group changed. No numeric command alias or unsolicited response was added.
|
|
|
|
## Source changes
|
|
|
|
- `internal/gameserver/aa_round_sync.go` builds a resource-validated desired group and selected-group/version digest. The default comes from the same loaded Peak groups as the data handler. It reads selection without writing saves.
|
|
- `aa_round_sync.lua` uses the actual current Client's `ChallengePeakModule.SendGetChallengePeakDataRequest()` and observes `CurrentPeakGroupID`. It sends one outstanding request and waits for the native value to match. It does not fabricate a response, alter private state, close a page, change scene, start a Battle, or remap a PeakID.
|
|
- Server gating defers while `CURRENT_BATTLE`, `ChallengeRun`, or CW is active; the Client also checks `BattleGamePhase`. Existing native login initialization (`CurrentPeakGroupID == 0`) is allowed to finish without issuing a duplicate request.
|
|
- `GetChallengePeakData` retains the existing Peak run's group until that run is left. It logs the actual selected group, number of groups and active-run state. Missing Peak resources now produce a typed error rather than a fabricated group/room list.
|
|
- Server README and Thai/English Srtool copy describe deferred native refresh rather than claiming that reopening the page necessarily causes a data request.
|
|
|
|
## Evidence and validation boundaries
|
|
|
|
The current process metadata in Player.log, `[GAC_AA_ROUND_META]`, reports:
|
|
|
|
```
|
|
UInt32 get_CurrentPeakGroupID()
|
|
Void SendGetChallengePeakDataRequest()
|
|
```
|
|
|
|
This evidence establishes the named native API, not its successful execution or UI refresh. Runtime pointers in the log are process-local and are not shipped or reused.
|
|
|
|
`go build ./internal/gameserver` and `node --check ../GaC-srtool/js/i18n.js` passed. No tests, save mutations, executable replacement, restart or Lua staging were performed for this source change. Root must wire `loadAARoundRefreshLua(s)` into heartbeat, build/deploy, and confirm the real request/reply plus `[GAC_AA_ROUND_SYNC] applied` and the displayed round before reporting Client success.
|
|
|
|
There is intentionally no timeout retry while an in-flight request cannot be distinguished from an unchanged result. A changed native group proves completion; new desired choices can then be requested. Reconnect/module replacement resets local request tracking. All activity schedules and resource room/boss definitions remain intact.
|