From a3fd9e870fecab2e3e5826e895a39d4a3e466059 Mon Sep 17 00:00:00 2001 From: funman300 Date: Tue, 4 Aug 2026 15:38:41 -0700 Subject: [PATCH] fifa17-recon: REFUTED -- the CardsDb map is not empty offline 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) Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW --- fifa17-recon/docs/CARD_SYSTEM.md | 55 ++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) diff --git a/fifa17-recon/docs/CARD_SYSTEM.md b/fifa17-recon/docs/CARD_SYSTEM.md index 49c4cd8..57b39af 100644 --- a/fifa17-recon/docs/CARD_SYSTEM.md +++ b/fifa17-recon/docs/CARD_SYSTEM.md @@ -139,3 +139,58 @@ and validates A. No such tool exists yet. - `fifadrive.sh` (screen capture) + `vgamepad.py` (virtual pad) for headless drive/observe — note keyboard XTEST does NOT reach FIFA; the gamepad is unverified in-game. + +--- + +## REFUTED 2026-08-04: the CardsDb map is NOT empty offline + +This document has claimed since it was written that "**Offline that map is EMPTY**, so +every lookup misses and a default blank record is emitted -> generic card", and that +the view-model reads every rendered field from the resolved record and "NEVER from our +item JSON". A live pack open falsifies both halves. + +### The observation + +One bronze pack, five cards. Two rendered as real players with names, club badges and +national flags. Three rendered as blanks: rating 50, position RWB, every attribute 1, +no name. Nothing in our pool has rating 50, position RWB or all-ones attributes, so the +blank is the client's default record, exactly as this document describes. + +The two that resolved match OUR ITEM JSON field for field: + +| we sent | screen showed | +|---|---| +| `(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 / 61 PHY | +| `(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. They cannot have come from a database. + +### What this means + +- The map HAS entries offline. Some asset ids resolve. +- Rating, position, nation, league, team and the six attributes come from **our item + JSON** for a card that resolves. +- Name, club badge and national flag come from the **client's own data**, keyed by + assetId. +- When the assetId is NOT in the client's data, the whole card collapses to the blank + default, which is why a bad id looks like a rendering failure rather than a lookup + failure. + +### The consequence, which is much cheaper than what this document proposed + +The recommended plan here was to populate the client's map by driving its insert, hand +building a red-black tree node, or patching the resolve miss-path, all of which write +to a live process. **None of that is needed to get real cards.** The rule is simply: + +> Use asset ids that exist in the client's database. Valid id gives a real card. +> Invalid id gives the blank. + +`fut_cards.py` currently carries 18 verified ids and 61 structural placeholders, and +the placeholders are what produce the blanks. Two of them (232517, 235066) happen to be +real, which is why the pack was a mix. The remaining work is therefore a DATA problem, +getting the real id list out of `dbdata.dll`, and not a code-injection problem. + +`TODO/CONFIRM`: whether a resolved card's rating truly comes from our JSON or whether +the client's record happens to agree. The attributes settle it (they were invented) but +rating specifically has not been isolated. Send a deliberately wrong rating for a known +good id and look.