GaCy-GO/docs/aa-round-sync.md

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.SendModuleInitRequest() and observes CurrentPeakGroupID. It resolves the exact zero-argument method through reflection because the xLua bridge does not consistently expose native methods as Lua functions. 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()

The earlier metadata evidence established method names only. Runtime pointers in the log are process-local and are not shipped or reused.

Runtime correction and deployment — 2026-10-30

Bounded disassembly of the live module's method pointers proved that the misleadingly named SendGetChallengePeakDataRequest sends GetCurChallengePeakCsReq (8945), which only refreshes the current run. SendModuleInitRequest sends GetChallengePeakDataCsReq (8942), the full round catalog. Names and IDs are verified against protocol/proto/cmdid.go; no aliases were added. Evidence is in .runtime/aa-send-request.asm, aa-agent-send.asm, aa-init-request.asm, and aa-agent-init.asm. Examined GameAssembly SHA256: 4aa08a0706f27d2cf9951b61920c179140ece9ea94f7e34422c18e46922939b6.

After selecting group 3 through the existing SDK endpoint, real Client/server logs showed:

[GAC_AA_ROUND_SYNC] requested group=3 previous=1
PEAK_DATA current_group=3 groups=11 active_run=false
[GAC_AA_ROUND_SYNC] applied group=3

This confirms the native module accepted the selected group. After deployment the user confirmed that the AA round changed from Srtool and a room could be entered.

Separately, one malformed reference scene key (6 in group 5) caused strict override validation to reject all AA scenes, including other rounds. It is corrected to stage 501 using the unique missing PreLevelIDList entry and matching NpcMonsterIDList actor from Client resources; coordinates, actor, entrance and maze group are unchanged. Provenance is stored in ChallengePeakSceneOverrides.json. The imported peak.stages section is now decoded correctly rather than interpreting the names stages/groups as fake stage IDs.

TestPeakSceneCatalogMatchesClientGroups, Peak config/limit tests and the Game server build passed. All 44 resource stage placements validate. The new executable was installed and the Game server restarted; temporary probes were removed from scripts/. These checks do not prove battle/scene success in the Client.

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.