funman300/OpenFUT
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fifa17-recon: S19 -- the MY CLUB counter is NOT server-fixable, with the mechanism

Browse Source 
Two experiments, both negative, and the negative has a mechanism behind it rather than
being another failed guess.

  FUT_CLUB_PAGE   served 114 items to /club?...count=11   tile still 0 TOTAL PLAYERS
  FUT_CLUBSTATS   full stat set, players=114, all modes   panel still Players 0

The bodies went out: four "CLUBSTATS: 11 stat rows (players=114)" responses in the log,
panel re-entered afterwards.

  FUN_18012fbe0   store+0x78 = request+0xc4      the mode tag is copied from the
                                                 REQUEST that just completed
  FUN_180043b90   switch (store+0x78)
    case 1  +0x800(1)->PLAYERS_EMPLOYED, (0x1e)->BALLS_EARNED, (0x28)->KITS_AVAILABLE,
            (0x14)->STADIA_OWNED, (10)->STAFF_EMPLOYED, (0x32)->TROPHIES_WON
    case 6  CARDS_NO_TRAINING_*, CARDS_NO_CONTRACT_*, CARDS_NO_FITNESS_*

The MY CLUB summary is case 1, which needs mode 1 (club). The client requests staff,
year and consumables and NEVER club, so the tag settles at 6 and case 1 is never
selected. Our values are stored correctly (contextId 1 forces contextValue 0, the
global bucket the +0x800 getter reads) and case 1 reads exactly the six ids we set.
Nothing ever asks for them.

THE MODE IS CHOSEN CLIENT-SIDE FROM THE REQUEST URL. No response body can change it,
so there is no body that fixes this and generating more of them is wasted work.

Two independent corroborations rather than one story that merely fits:
- case 6 reads 0x3d CONTRACTS, 0x3e TRAINING, 0x40 FITNESS, exactly the three ids
  FUN_18012fd40 cannot produce from any type string. The consumables view is
  unsettable from this endpoint by construction.
- FUT_CLUB_PAGE eliminated the only other candidate: the tile is not a count of the
  list we return.

Both flags stay implemented and default OFF. FUT_CLUBSTATS is correct against the
verified schema and would populate the moment a club-mode request occurred; deleting it
would throw away the schema work for no gain.

Recorded against myself: I argued from the matching labels (tile "TOTAL PLAYERS", panel
"Players", both zero while we served {}) that the two read the same store and one body
would fix both. The store IS shared. The SELECTION is not, and that is what decides it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
This commit is contained in:
funman300
2026-08-04 14:25:56 -07:00
parent 1e2b073e04
commit d2bbb4d378
1 changed files with 71 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
fifa17-recon/docs/REBUILD_RESEARCH.md
+71
View File
@@ -822,3 +822,74 @@ options body is exactly what would make the client proceed and ask for `/season`
first time. So success on the first step arms the second risk. Expect it, watch for the
busy-loop freeze rather than an error dialog, and be ready to answer `/season`
minimally rather than fully.
---
## 19. The MY CLUB counter: why it is not server-fixable (2026-08-04, measured)
Three experiments in one session, and the answer is a negative with a mechanism behind
it rather than another candidate body.
### What was tried
| flag | what it changed | result |
|---|---|---|
| `FUT_CLUB_PAGE` | served 114 items to `GET /club?...count=11` | tile still `0 TOTAL PLAYERS` |
| `FUT_CLUBSTATS` | full stat set on every Stats2 mode, `players=114` | panel still `Players 0` |
The bodies demonstrably went out. The log shows four `CLUBSTATS: ... 11 stat rows
(players=114)` responses at 14:20:19 and 14:20:23, and the panel was re-entered after.
### The mechanism
```
FUN_18012fbe0 store+0x78 = request+0xc4 the mode tag is copied out of the
store+0x7c = request+0xc8 REQUEST that just completed
store+0x80 = request+0xcc
FUN_180043b90 switch (store+0x78)
case 1 +0x800(1)->PLAYERS_EMPLOYED +0x800(0x1e)->BALLS_EARNED
+0x800(0x28)->KITS_AVAILABLE +0x800(0x14)->STADIA_OWNED
+0x800(10)->STAFF_EMPLOYED +0x800(0x32)->TROPHIES_WON
case 3 per-nation: BRONZE/SILVER/GOLD/RARE_PLAYERS_EMPLOYED, KITS, BADGES
case 6 CARDS_NO_TRAINING_*, CARDS_NO_CONTRACT_*, CARDS_NO_FITNESS_*
```
The MY CLUB summary is **case 1**, which requires mode 1 (`club`). The real client
requests `/club/stats/staff`, `/club/stats/year` and `/club/stats/consumables`, and
**never** `/club/stats/club`, so the mode tag settles at 6 and case 1 is never
selected. Our values are stored correctly (contextId 1 forces contextValue 0, the
global bucket the `+0x800` getter reads) and case 1 reads exactly the six ids we set.
Nothing ever asks for them.
**The mode is chosen client-side from the request URL.** No response body can change
it. That is why this is not a shape problem: there is no body that fixes it.
### Two independent corroborations
- Case 6 reads ids `0x3d` CONTRACTS, `0x3e` TRAINING and `0x40` FITNESS, which are
exactly the three ids the type-string map (`FUN_18012fd40`) **cannot produce**. The
consumables view is unsettable from this endpoint by construction, which is a
strange property unless the mode split is real.
- `FUT_CLUB_PAGE` eliminated the only other candidate: the tile is not a count of the
list we return.
### Status
`FUT_CLUBSTATS` stays implemented and **default off**. The body is correct against the
verified schema and would populate the moment a `club`-mode request occurred. Keeping
it costs nothing and throwing it away would lose the schema work.
`FUT_CLUB_PAGE` stays default off; it answered its question.
### What would still change this
One thing, and it is not another body: find what makes the client issue
`/club/stats/club`. It is a request the client knows how to build (the URL builder
`FUN_18012f4f0` has a `club`(0x87) mode), so something reaches it. That decision is in
the front-end layer, same as Seasons. Until then, treat the MY CLUB counter as **not
server-fixable** and stop generating candidate bodies for it.
An earlier note in this file argued the counter was server-supplied by
`/club/stats/<mode>`, and the live-evidence argument that the hub tile and the panel
read the same store (both said "players", both zero) was mine and was wrong in its
conclusion. The store is shared; the *selection* is not.