Section 7 of plan-2026-08-06-card-subsystem.md listed these and they were never
applied, so the stale text kept misleading readers — it already cost this project
a ten-row itemState table.
CARD_SYSTEM.md:
- "STILL UNKNOWN, AND NOT GUESSED" is ANSWERED. Its candidate set was wrong:
it asked which of 0x1e/0x1f/0x91..0x96 meant kit/badge/stadium, but three of
the five families are cardtype 7 (kit 9, stadium 10, badge 11) and are not in
that set at all, and 0x91..0x96 are trophies. Replaced with the settled map
and how each family's caption resolves.
- itemState table starts at 0x180229cc0, not 0x180229d20 — the recorded address
points MID-table, which is why six rows were missing. Added that
WAITING_FOR_GAME/inGame are aliases, that omitting the key yields invalid and
not free, and that the match is case-sensitive (measured).
- the consumables route claim "the /consumables/%s template ... the client has
still never used" is false; it IS that template, with base index 3 = ut/%s/club.
- added the dated field-map correction block, extended with the +0x60 and
definitionId findings measured on 2026-08-21.
tools/fut_store.py: the discard_value premise "that lookup returns no row for our
cards" / "WHY its lookup misses is still UNKNOWN" is false — it does not miss, the
tile reads a different property. That story sent one round of work chasing a table
defect that never existed.
Researched rather than guessed, after a guessed field crashed the client.
VERIFIED: FUN_1800d8330 returns cardtype 9 for exactly 0x1e, 0x1f, 0x91..0x96,
0xe7..0xe9, 0xec; fcc_misccards' cardsubtype 231 anchors the 0xe7 block to misc, so
badges/kits/stadia/balls/logos live in 0x1e, 0x1f and 0x91..0x96.
VERIFIED, and it answers a question nobody had asked: the itemState enum at
0x180229d20 is WAITING_FOR_GAME, inGame, forSale, offered, activeBadge, activeHomeKit,
activeAwayKit, activeBall, activeStadium, active. An EQUIPPED club item is the same
item with itemState set, not a different subtype. 'free' is right for owned-but-not-
equipped, which is what we already send.
VERIFIED: club items have no category group table (consumables and staff both do), and
the route is club?type= with SINGULAR names, observed live.
STILL UNKNOWN and labelled so: which subtype means which family. Not in any of the 149
dumped tables, no group table, and cardtype 9 has no merge arm so a wrong value cannot
announce itself.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
Real card art, tier colours and the GK glove icon all draw once cardassetid carries
the art id. Records both refuted hypotheses with the evidence that killed them, since
each was plausible and someone will reach for them again.
The generalisable trap: an fcc_ row has BOTH carddbid and cardassetid, they are not
interchangeable, and _item copies resourceId into cardassetid -- right for players,
wrong for every other family. Club items will hit it next: balls 37, kits 35,
stadium 36, badges 39, league logos 40.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
Rendering with real artwork, quantity badges and +5/+10/+15 amounts, so atom 0x1b
reaches record+0xbf. The client's own dialog names the class we resolved: 'Search
Type: Consumables Search'.
Records the three things that each had to be right and each failed silently with a
200: the count gates the fetch, the route is club/consumables/<category> (a /club
PREFIX, so it was being answered with the player list), and the element is a five-atom
stack wrapper whose 0x16a member is the only thing that carries the item.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
34 staff cards, zero DB Error. Every coach id hit its table first time, which is the
payoff from enumerating the game's own database instead of sweeping for ids: the loud
miss-fill exists and never fired.
10 of 10 managers resolved with historically correct nations and leagues.
RESOLVED, previously TODO/CONFIRM: the manager card template paints record+0xde
(nation) and record+0xe0 (league). Luis Enrique draws the Spain flag and 'LaLiga
Santander'; the Premier League managers draw their flag and 'ENG 1'. The merge never
writes either field, so nothing but our own JSON could have supplied them.
Corrected: negotiation at +0xe3 is NOT on the card front, which shows CONTRACT 7
there. I had told the user to look for it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
Supersedes the parts of this document that were wrong: the CardsDb map is not empty
offline, and dbdata.dll is not the player database.
Records the merge dispatch table, the field-fill asymmetry that the pool design
depends on (send zero for what the client knows, send our own only where it knows
nothing), the three-state oracle with all three fingerprints, the 5000-item ingest
ceiling, the fact that the map is WIPED on every club fetch, and where the 17,547
player roster came from plus its independent cross-validation.
Also records the state of the other card families so the next session starts from
the manager branch writing no miss-fill, rather than rediscovering it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
CARD_SYSTEM.md has claimed since it was written that offline the CardsDb map is EMPTY,
every lookup misses, and the view-model reads every rendered field from the resolved
record and NEVER from our item JSON. A live pack open falsifies both halves.
One bronze pack, five cards. Two rendered as real players with names, club badges and
national flags. Three rendered blank: rating 50, position RWB, every attribute 1. Our
pool contains no rating 50, no RWB and no all-ones attributes, so the blank is the
client default.
The two that resolved match our item JSON field for field:
(232517, 62, RB, nation 36, league 19, team 175, [72,44,58,60,62,61])
-> SILVA, 62 RB, Wolfsburg badge, Norway flag, 72 PAC 44 SHO 58 PAS 60 DRI 62 DEF
(235066, 60, GK, nation 34, league 31, team 48, [62,63,33,61,17,62])
-> NOWAK, 60 GK, 62/61 63/17 33/62
Those attribute numbers were invented by hand this afternoon. They cannot have come
from a database.
So: stats come from our JSON, name/badge/flag come from the client keyed by assetId,
and an assetId the client does not know collapses the WHOLE card to the blank, which
is why a bad id looks like a rendering failure rather than a lookup failure.
THE CONSEQUENCE IS THAT THE PLANNED WORK IS UNNECESSARY. This document recommended
populating the map by driving the insert, hand-building a red-black tree node, or
patching the resolve miss path, all of which write to a live process. None of it is
needed. The rule is: use asset ids that exist in the client database. fut_cards.py has
18 verified ids and 61 structural placeholders, and the placeholders are the blanks.
The remaining work is a DATA problem, not a code-injection problem.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
The client now issues PUT /squad and the hub renders coins, record and the
squad roster. Three separate root causes, all verified live.
Squad blocker (the long-standing "client never sends PUT /squad"):
AddPlayerToSquad, GetSquads and SelectSquadById issue ZERO network requests
(pure local model reads/mutations, FutSquadServiceImpl vtable 0x180233ff0);
only SaveCurrentSquad writes, and it is unguarded. The client simply needed a
populated ACTIVE squad model, which arrives via the massinfo `squad` member.
No response of ours was ever being rejected.
userMassInfo is NOT required to be {}:
0x180174630 is a FLAT {userInfo, squad, settings, userData} body -- the old
"wrapper key is user" note was wrong, and the historical freeze was the
malformed squad member, not the envelope.
clubNameChangeAllowed must be false:
sending true advertises a club-rename flow whose UI model is never populated;
the client shows a naming prompt and dies confirming it (ACCESS_VIOLATION
reading 0x0 at FIFA17.exe+0x71b8651, 4/4 runs, no CardsDLL frame and no request
in flight). Isolated by a single-variable run; guarded by a contract check.
Endpoint/schema corrections found in live traffic, invisible to static analysis:
* GET ut/%s/squad/list is a real endpoint and must return {"squad":[...]},
not the active-squad object (the /list suffix is appended by the caller, so
it never appeared in the request table)
* PUT lands on ut/%s/squad/<id>, not a bare ut/%s/squad
* userInfo currencies are read as name/funds/finalFunds/active -- there is no
"value" key, so coins always rendered 0
* squad-list elements take STRING formation/squadType, not ints
* the CardsDLL script-API thunk<->name table was off by one (AddPlayerToSquad
is 0x18004aa70; 0x18004aff0 is GetPotentialChemistry_Club)
FUT_MASSINFO / FUT_USERINFO ladders keep every step of the bisect reproducible.
Contract suite 311 -> 358 checks. Tooling added: PyGhidra harness (Ghidra's
Java/OSGi script path is broken on this box), minidump reader, live code grabber.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
A full 88-rated real FUT squad (Ronaldo/Messi/Suárez/Ramos/Kroos/Alba/
Hazard/Oblak/Alaba/Boateng) renders 100% offline, no EA servers.
Mechanism: the definition fetch was unnecessary — FIFA has all player
identity locally in dbdata.dll. The CLUB-SEARCH / Add-Player flow
(GET /club?type=player&count=N, served by our /club route) makes FIFA
resolve each item's assetId against its own local DB (real name/photo/
club/nation) and merge the rating/attributes our /club item carries,
caching a real record in the CardsDb store. No idList fetch, no leaked
data.
Recipe: utas FUT_SQUAD_STEP=s3v0 -> /club serves the full XI; in FUT,
Squads -> Add Player/search -> results render real -> add to slots.
docs/CARD_SYSTEM.md updated with the SOLVED mechanism + recipe.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
Milestone: FIFA 17 Ultimate Team boots end-to-end on our offline backend
past every EA gate into the hub and a live Squads editor (correct 4-4-2,
5-star squad, no freezes).
Key findings this session:
- userMassInfo MUST stay {} (any content desyncs the massinfo parser
0x180174630 -> tokenizer busy-loop freeze). Deliver the squad via
GET /squad/0 (fetched on Squads-tab entry) instead.
- Player cards render generic because the card view-model (0x1800d7920)
reads identity/rating/face from a resolved record at item+0x10, filled
by a lookup (0x18011cca0) in the FUT item-definition std::map at
CardsDb+0x160c0 -- which is EMPTY offline -> default blank record.
- Version advertising (itemDbVersion/checkServerDbVersion) is proven inert
(JSON fields routed to the skip handler). Owned items don't auto-trigger
a definition fetch. In-place map overwrite is dead (map stays empty).
- Definition-serving endpoints (item/resource, defid, item?idList) built +
ready; the fetch trigger lives in the packed FIFA17.exe.
New: docs/CARD_SYSTEM.md (findings + ordered next-steps plan for real
player cards: patch-POC, dbdata extractor, drive FIFA17.exe fetch, or
live-memory store injection). Plus tools: fut_seed.py (squad ladder +
definition serving), fifadrive.sh, vgamepad.py, and the login-RE toolset.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
funman300