From 9348b83374e211fd3308d723fd7f2cb62f24335e Mon Sep 17 00:00:00 2001 From: funman300 Date: Wed, 5 Aug 2026 12:06:31 -0700 Subject: [PATCH] fifa17-recon: club-item research -- cardtype map exact, itemState carries equipped state 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 Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW --- fifa17-recon/docs/CARD_SYSTEM.md | 50 ++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) diff --git a/fifa17-recon/docs/CARD_SYSTEM.md b/fifa17-recon/docs/CARD_SYSTEM.md index 3bbdaa5..4b7f307 100644 --- a/fifa17-recon/docs/CARD_SYSTEM.md +++ b/fifa17-recon/docs/CARD_SYSTEM.md @@ -397,3 +397,53 @@ THE TRAP GENERALISES. An fcc_ row carries BOTH carddbid and cardassetid and they not interchangeable. fut_store._item copies resourceId into cardassetid, which is correct for players and wrong for every other family. The club-item family will need the same mapping: balls 37, kits 35, stadium 36, badges 39, league logos 40. + +--- + +# Club items: what the research established, 2026-08-05 + +Researched after a guessed field crashed the client. Facts first, and the one thing +still unknown is named as unknown. + +## VERIFIED IN BINARY + +1. THE CARDTYPE MAP IS EXACT. FUN_1800d8330 (714 chars, read in full) returns cardtype + 9 for cardsubtypeid 0x1e, 0x1f, 0x91..0x96, 0xe7..0xe9 and 0xec, and nothing else. + fcc_misccards carries cardsubtype 231 = 0xe7, which anchors the 0xe7..0xe9 block to + misc cards. That leaves 0x1e, 0x1f and 0x91..0x96 for badges, kits, stadia, balls + and league logos. +2. ITEMSTATE CARRIES THE EQUIPPED STATE. The enum table at 0x180229d20 (stride 0x10) + is: WAITING_FOR_GAME, inGame, forSale, offered, activeBadge, activeHomeKit, + activeAwayKit, activeBall, activeStadium, active. So an EQUIPPED club item is not a + different subtype, it is the same item with itemState set to one of those five. + "free" is correct for owned-but-not-equipped, which is what we send. +3. CLUB ITEMS HAVE NO CATEGORY GROUP TABLE. Consumables have one at 0x180203260 (seven + codes: training, contracts, fitness, healing, playStyle, managerLeagueModifier, + position) and staff have one at 0x180203310 (five codes). There is no equivalent + for club items; the only club-item strings are the COUNT labels + FUT_MYCLUB_KITS_AVAILABLE / BADGES_AVAILABLE / STADIA_OWNED / BALLS_EARNED, which + we already serve correctly. +4. THE ROUTE IS club?type= WITH SINGULAR NAMES. Observed live: type=stadium, + type=ball, type=equippables (the combined customisation view). Not the plural stat + names, and not a club/ path. + +## STILL UNKNOWN, AND NOT GUESSED + +Which of 0x1e, 0x1f, 0x91..0x96 means ball versus stadium versus badge versus kit. +It is in none of the 149 dumped tables, there is no group table, and cardtype 9 has NO +arm in the merge, so a wrong subtype cannot announce itself the way a coach's "DB +Error" does. Two ways to settle it, in order of preference: + a. more RE: find the consumer that switches on subtype for a club item, most likely + in the equip path that writes itemState = activeBadge and friends; + b. FUT_CLUBITEMS=probe:, which serves ONE family as eight items, one per + candidate subtype, so the screen names the right one. + +## WHY THE CRASH HAPPENED, recorded so it is not repeated + +teamid, leagueid and value were copied out of the fcc row as "extras". `value` appears +elsewhere as an OBJECT member (displayGroup {"value": ...}); a scalar where an object +is expected is the type-desync busy loop at 0x1801c7f1a, which presents as the game +taking its time and then dies. None of the three was needed to draw a card. Compounding +it, the response that crashed was type=equippables carrying 30 items across FIVE +unverified subtypes at once, so even the crash taught us nothing about which subtype +was wrong. Both are fixed: no extras, equippables withheld, one family per test.