GaCySR/GaCy-GO
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

Update GaCy-GO

Browse Source
This commit is contained in:
CAtlas0784 committed 2026-10-28 18:54:43 +07:00
1 parent da8a32f60d
commit 0cbe460e49
345 files changed
+98202 -77559
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

docs/prydwen-endgame-recommendations.md
+6 -4
View File
@@ -1,9 +1,11 @@
# Endgame team recommendations
`GetFriendRecommendLineup` (CmdID 2985 from the checked-in 4.6.53 command table) now returns three recommended teams for the current MoC floor-12 snapshot. The response uses the `OJJJDPNOKHG.lineup_list` shape because its repeated `ChallengeLineupList` entries match the three stage rows in the referenced Client page. Each external character slug is resolved through the current `resources/AvatarConfig.json`; the server does not embed AvatarIDs in its handler.
`GetFriendRecommendLineup` (CmdID 2985 in the checked-in Client 4.6.53 command table) serves current Prydwen team snapshots for Memory of Chaos, Pure Fiction, Apocalyptic Shadow, and Anomaly Arbitration. Each source slug is resolved through this Client's `resources/AvatarConfig.json`, with source-name aliases kept beside the snapshot. The AA response uses the Peak-lineup protocol variant and obtains Peak IDs from `ChallengePeakGroupConfig.json`; it does not embed the current game's IDs in the handler.
The bundled snapshot is dataset revision 4.6.2, collected 2026-10-14, for MoC cycle 4.6.1 “Crossing the Afterlife”. The files identify the first-ranked Prydwen team for stages 12-1, 12-2, and 12-3. The dataset repository declares MIT and asks users to credit LvlUrArti; its README says it contains processed data shown on Prydwen. Attribution and source metadata are kept in `resources/PrydwenEndgameTeams.json`.
The bundled data is revision 4.6.2, collected 2026-10-14. Each mode retains its own challenge version/name because their cycles do not necessarily advance together. Data is processed from the MIT-licensed [LvlUrArti/MocDataProcessed dataset](https://huggingface.co/datasets/LvlUrArti/MocDataProcessed), which describes its contents as processed Prydwen data and requests credit to LvlUrArti.
To refresh for another floor and the newest published snapshot, run `python tools/update_prydwen_endgame_teams.py --floor 12 --stage-count 3`. The updater validates every slug against this Client's AvatarConfig before replacing the snapshot; add a source-slug-to-AvatarVOTag alias in the resource if a name differs.
Refresh all modes from the latest dataset snapshot with `python tools/update_prydwen_endgame_teams.py`. To refresh only one mode, use `--mode moc`, `--mode pf`, `--mode as`, or `--mode aa`. The updater selects the highest-ranked team whose four character slugs resolve against this Client's `AvatarConfig`; this avoids emitting avatar IDs that the running Client does not define.
Protocol limitation: the current proto retains an obfuscated `JFNJKAPPNOF` enum and obfuscated response oneof names. The handler echoes the request `type` and `key`, and uses the lineup-list variant based on the visible three-row MoC UI and the message's repeated lineup schema. The exact numeric type-to-mode relationship and the meaning of response field `ALDBIIIGLOM` are not established. This first implementation does not discriminate modes using `type` or `key`, so it is limited to the illustrated MoC page and needs in-Client verification before claiming support for other Endgame modes or the friend-cleared tab.
Protocol limitation: `GetFriendRecommendLineupCsReq.type` is the obfuscated `JFNJKAPPNOF` enum in this Client's protobuf. The mapping 2=MoC, 3=PF, 4=AS, and 5=AA is an explicit implementation assumption; the checked-in schema does not reveal the enum names, and we do not have packet captures from each Client page to confirm those values. The mapping is centralized in `resources/PrydwenEndgameTeams.json`, and unknown values receive an empty response with the request context preserved instead of MoC data. The handler logs the received type/key to support Client-side verification. AA `key` matching also remains an assumption: known Peak resource IDs are matched directly, and otherwise the latest configured group is paired with the bundled current AA snapshot.
The response shapes follow the checked-in protobuf: the current three-stage MoC/PF/AS pages use `OJJJDPNOKHG.lineup_list`; AA uses `MJMGDLJAJCM` entries with `peak_id` and avatar lists. These server tests verify resource conversion and protobuf round trips; a successful build does not confirm the live Client accepted every mode's obfuscated route or UI response.