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

docs(fifa17): close the eight-flag chain link, and separate the two databases

Browse Source 
FUN_1801aa190 (the plan's "two minutes of work" item) is eleven instructions and
resolves TWO parallel arrays, not the one the earlier claim described:
f(self, idx, which) reads item+0x104+idx*4 when the flag is clear and
item+0x124+idx*4 when it is set — eight ints each, 0x20 apart. Live, BOTH read
all zeros on every resident record including a rating-94 player, so neither can
be the reason any action is greyed today.

The FUT roster database question is partly answered. Scanning FIFA17.exe in the
live process recovers the full API name set — StartFUTRosterDownload,
DL_FUT_LIVEDB, APPLY_FUT_LIVEDB, LoadFUTDatabase, UnLoadFUTDatabase,
SetFUTDatabaseUnloaded, UpdateFUTDBVersion, GetFUTDBCRC, RosterXMLDownloadedFail,
.dbFUTVer/.dbMajor/.dbMinor/CRCs — none of which exists in CardsDLL. That is a
downloaded, versioned, CRC-checked live database with its own lifecycle, which is
categorically not the shipped card tables. Whether it is loaded RIGHT NOW is
still open: the load flag was not located, and the absence of an open DB file
proves nothing since the process only holds Frostbite bundles.
This commit is contained in:
funman300
2026-08-21 21:15:02 +00:00
parent a842c5ffb0
commit e44c88dd68
1 changed files with 52 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
fifa17-recon/docs/plan-2026-08-06-card-subsystem.md
+52 -9
View File
@@ -575,10 +575,31 @@ kits from `FUN_1801a8800` (`+0xba`, u16) and `FUN_1801a8040` (`+0xbf`, signed
byte). Which wire atom sets it is unknown, so we cannot serve a specific kit byte). Which wire atom sets it is unknown, so we cannot serve a specific kit
deliberately. Note `+0xba` is the same slot as the unresolved ball subtitle. deliberately. Note `+0xba` is the same slot as the unresolved ball subtitle.
**`FUN_1801aa190`.** The one unopened link inside the eight-flag chain: it is **`FUN_1801aa190`. CLOSED 2026-08-21.** The one unopened link inside the
claimed to resolve `statsList[4]` and `[5]` at `+0x104 + idx*4`. It changes no eight-flag chain. It is eleven instructions, and it resolves TWO parallel arrays
action today because we send no `statsList`, but it is two minutes of work and it rather than the one the earlier claim described:
would close the chain.
```
mov rax, [rcx+0x10] ; the ITEM record (same +0x10 hop the kit gate uses)
test r8b, r8b
jz .low
mov eax, [rax + rdx*4 + 0x124] ; array B
ret
.low:
mov eax, [rax + rcx*4 + 0x104] ; array A <- the claimed statsList
ret
```
So the signature is `f(self, int idx, bool which)`: `+0x104 + idx*4` when the
flag is clear, `+0x124 + idx*4` when it is set. The two arrays are 0x20 apart,
i.e. eight ints each (`+0x104..+0x123`, `+0x124..+0x143`).
LIVE (pid 6580, production-served records): BOTH arrays read all zeros on every
resident record, players included — e.g. resourceId 20801 rating 94 has
`A = [0]*8`, `B = [0]*8`. That confirms "changes no action today because we send
no statsList", and extends it: the sibling array at `+0x124` is equally empty.
Any action flag derived from either is reading 0 in production, so neither can
be the reason an action is greyed.
**The `BOUGHT_FOR` consumer.** `+0x34` = atom `0x185 lastSalePrice` is resolved. **The `BOUGHT_FOR` consumer.** `+0x34` = atom `0x185 lastSalePrice` is resolved.
What remains is whether the field is visible anywhere worth populating. What remains is whether the field is visible anywhere worth populating.
@@ -628,11 +649,33 @@ the live save.
**Re-read `+0x30` after a refetch** to decide between "monotonic clock" and **Re-read `+0x30` after a refetch** to decide between "monotonic clock" and
"sequence counter". Low value; nothing we send reaches it. "sequence counter". Low value; nothing we send reaches it.
**Confirm the FUT roster database is loaded.** The `fcc_discardcoins` result **Confirm the FUT roster database is loaded. PARTLY ANSWERED 2026-08-21 — the
proves `g_db` is loaded and complete; it says nothing about the separate database two databases are now definitively distinct; the load FLAG is still unlocated.**
behind `LoadFUTDatabase` / `.dbFUTVer` / `DL_FUT_LIVEDB`, whose strings live in The `fcc_discardcoins` result proves `g_db` is loaded and complete; it says
FIFA17.exe and not in CardsDLL. These are different databases and they should stop nothing about the separate database behind `LoadFUTDatabase` / `.dbFUTVer` /
being conflated. `DL_FUT_LIVEDB`. Scanning FIFA17.exe's 79 MB of code+data in the live process
(pid 6580) recovers the whole API name set, and it settles the distinction:
```
SetFUTDatabaseUnloaded UpdateFUTDBVersion StartFUTRosterDownload
LoadFUTDatabase UnLoadFUTDatabase GetFUTDBCRC
CancelRosterDownload DL_FUT_LIVEDB APPLY_FUT_LIVEDB
RosterXMLDownloadedFail .dbFUTVer .dbMajor .dbMinor .dbMajorCRC .dbMinorCRC
```
Every one of those lives in FIFA17.exe; none is in CardsDLL. So the FUT roster
DB is a DOWNLOADED, versioned, CRC-checked live database with its own
download -> apply -> load/unload lifecycle (and its own failure state,
`RosterXMLDownloadedFail`), which is a different kind of thing from the shipped
card tables CardsDLL reads. They should stop being conflated, and this is the
evidence for saying so.
What is NOT answered: whether it is loaded right now. The process holds no
separate database file open — only Frostbite bundles (`.sb` / `.cas`) — which is
consistent with the roster DB living inside a bundle or in memory, so absence of
a file handle proves nothing either way. The `SetFUTDatabaseUnloaded` state
implies a boolean somewhere; that global was not located, so "is it loaded"
remains open and needs the flag found before it can be answered honestly.
### Needs a launch the user must drive -- ranked, and short ### Needs a launch the user must drive -- ranked, and short