OpenFUT

funman300/OpenFUT

Fork 0

Commit Graph

Author	SHA1	Message	Date
funman300	9a0a76c9f4	fifa17-recon: real positions, clubs and the six card attributes for all 17,563 players The pool now comes from the game's OWN resident database, not from a rating index plus guesses. tools/db_dump.py walked the client's self-describing table catalog read-only and wrote data/tables/ (149 tables, 55MB); tools/build_player_facts.py turned it into data/player_facts.json; data/pool.json is the compact form fut_cards loads. MEASURED, per player: position (players.preferredposition1), nationality, teamid, leagueid (via leagueteamlinks), and the six card attributes. The six attributes are NOT columns -- they are a weighted sum of the 29 base attributes, and the weights are read out of the game's own playerattributesmapping table rather than from published formulas. Checked against real FIFA 17 cards: Messi 89/90/86/96/26/61 and Ibrahimovic 72/90/81/85/31/86 are EXACT, Suarez is one off on physical, Ronaldo within two on pace and shooting. Keepers come out directly from the gk* columns. What this fixes on screen: Kaka was a CDM, Bale a CM, Suarez a GK, and every attribute was derived from the rating. Now Bale is RW, Boateng is a CB with 90 defending, De Gea is a GK, and a bronze pack deals real bronze players in real positions. REVERSAL, deliberate: nation/team/league were being sent as ZERO so the client would fill its own values (the merge fills those three only when they arrive zero). Now that we hold the game's own numbers there is nothing to gain from zeros, and they actively hurt -- club-stats drill-downs bucket by the item's own nation and leagueId, so a club full of zeros would have quietly emptied the per-nation and per-league panels fixed the day before. Send the real values. The old rating-index path is kept as a fallback so the pool still builds without data/pool.json, and it now says out loud which of the two it used, because one is a measurement and the other is a guess. 439 + 61 checks green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW	2026-08-05 09:08:29 -07:00
funman300	e9e6f203c2	fifa17-recon: the card pool is now the REAL FIFA 17 roster, 17547 players The old pool was 79 hand-written rows whose asset ids were mostly invented, on the premise that the client's card map is empty offline so no id could render. That premise was refuted by a live screenshot, and this replaces its consequence. Source: tools/dbdata_extract.py reads FIFA's own rating-sorted index out of a running process (0x40 stride, self-validating {begin,end,end+1} name-pointer triple, anchored on 20801 = Ronaldo 94) -> data/roster.json. dbdata.dll was a dead end and is documented as such: its single export getTableData is an anti-tamper attestation routine, not a data accessor. Cross-validated against a completely independent method. tools/sweep_collect.py serves candidate ids as a synthetic club and reads back the identity the CLIENT resolved through its own merge. 573 of 573 overlapping names agreed exactly, and the single id present in one and not the other is 26501, the target of the documented 22800..22879 Legends remap -- which is also what produced 'Alex Hunter x80' in a sweep and had looked like a bug. Field honesty, because half of these are real and half are not: playerid/rating/name REAL the roster club/nation/league REAL we send zeros and the CLIENT fills them (the merge only fills those fields when they arrive as zero) position PARTLY 59 from the game's own per-card cache, 17 curated by hand, the rest synthetic but deterministic attributes SYNTH derived from rating and position 169193 is dropped from the curated set: it was in VERIFIED_ASSET_IDS and is not a real player. The client resolves it to the database's empty placeholder row, which renders as 'Jamal Blackman'. Two independent methods agreed. NOTE BEFORE PUSHING ANYWHERE PUBLIC: data/roster.json is EA's player data, extracted from your own installation. Fine locally; think twice about publishing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW	2026-08-04 21:08:52 -07:00
funman300	ffb0e6033c	fifa17-recon: real card pool -- 79 players, three tiers, and packs that differ The pool was 18 players rated 85 to 94. open_pack() split it with `(rating >= 75) == gold`, so the bronze pack's filter matched NOTHING and fell back to the whole pool: all three packs dealt gold rares and the bronze pack was a lie. The file's own TODO asked for "a full dbdata.dll extract (~18k players)". NEW fut_cards.py: 79 players, 39 gold / 20 silver / 20 bronze, 7 leagues, 20 nations, 18 teams, every outfield position plus GK, no duplicate asset ids. PACK_CATALOG now carries a weighted `tiers` draw per pack. Simulated 40 opens of each: Bronze Pack {'bronze': 159, 'silver': 41} 39 distinct cards, 12 positions Gold Pack {'silver': 110, 'gold': 170} 59 distinct cards, 12 positions Premium Gold {'gold': 392, 'silver': 48} 57 distinct cards, 12 positions WHY THIS IS NOT THE dbdata EXTRACT, and why that does not matter yet. dbdata.dll is a real PE with one export, getTableData, whose 2.5MB payload sits in a section named .xdata that disassembles as obfuscated code rather than a table directory, so the base DB is not statically extractable without running that export under Wine or defeating the obfuscation. More to the point it would change nothing on screen today. Per docs/CARD_SYSTEM.md the card view-model 0x1800d7920 reads EVERY rendered field (rating +0xb4, position +0x146, nation +0x148, teamid +0x94, six attrs +0x98..0xac, name +0xdd) from a definition record resolved at item+0x10 out of the client's own CardsDb map, and NEVER from our item JSON. Offline that map is EMPTY, so every lookup misses and a blank record is emitted. No assetId we send, real or invented, can produce a named card until that map is populated. That is a separate job (CARD_SYSTEM options A/B/C) about the CLIENT's map, not about our pool. What the pool DOES control is everything the server is source of truth for: the gold/silver/bronze split, leagueId/nation/teamid which are exactly what the club-stats drill-downs read (those now work, S20, and were being fed 5 leagues from 13 nations), preferredPosition which decides whether a squad can be filled at all, and the six attributes behind the market filters. Asset ids: 18 are genuine FIFA 17 ids and are listed in VERIFIED_ASSET_IDS. The rest are structural, and the docstring says so plainly rather than passing them off as real players. Because the CardsDb map is empty offline an id being wrong has no visible effect today; if the identity work lands, that set is the diff target. Backwards compatible: open_pack() still honours the legacy `gold` boolean when no tiers are given, and the old list survives as _LEGACY_POOL for the starter squad. 392 + 61 checks green. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW	2026-08-04 15:23:23 -07:00

Author

SHA1

Message

Date

funman300

9a0a76c9f4

fifa17-recon: real positions, clubs and the six card attributes for all 17,563 players

The pool now comes from the game's OWN resident database, not from a rating index
plus guesses. tools/db_dump.py walked the client's self-describing table catalog
read-only and wrote data/tables/ (149 tables, 55MB); tools/build_player_facts.py
turned it into data/player_facts.json; data/pool.json is the compact form fut_cards
loads.

MEASURED, per player: position (players.preferredposition1), nationality, teamid,
leagueid (via leagueteamlinks), and the six card attributes.

The six attributes are NOT columns -- they are a weighted sum of the 29 base
attributes, and the weights are read out of the game's own playerattributesmapping
table rather than from published formulas. Checked against real FIFA 17 cards:
Messi 89/90/86/96/26/61 and Ibrahimovic 72/90/81/85/31/86 are EXACT, Suarez is one
off on physical, Ronaldo within two on pace and shooting. Keepers come out directly
from the gk* columns.

What this fixes on screen: Kaka was a CDM, Bale a CM, Suarez a GK, and every
attribute was derived from the rating. Now Bale is RW, Boateng is a CB with 90
defending, De Gea is a GK, and a bronze pack deals real bronze players in real
positions.

REVERSAL, deliberate: nation/team/league were being sent as ZERO so the client would
fill its own values (the merge fills those three only when they arrive zero). Now
that we hold the game's own numbers there is nothing to gain from zeros, and they
actively hurt -- club-stats drill-downs bucket by the item's own nation and leagueId,
so a club full of zeros would have quietly emptied the per-nation and per-league
panels fixed the day before. Send the real values.

The old rating-index path is kept as a fallback so the pool still builds without
data/pool.json, and it now says out loud which of the two it used, because one is a
measurement and the other is a guess.

439 + 61 checks green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW

2026-08-05 09:08:29 -07:00

funman300

e9e6f203c2

fifa17-recon: the card pool is now the REAL FIFA 17 roster, 17547 players

The old pool was 79 hand-written rows whose asset ids were mostly invented, on
the premise that the client's card map is empty offline so no id could render.
That premise was refuted by a live screenshot, and this replaces its consequence.

Source: tools/dbdata_extract.py reads FIFA's own rating-sorted index out of a
running process (0x40 stride, self-validating {begin,end,end+1} name-pointer
triple, anchored on 20801 = Ronaldo 94) -> data/roster.json. dbdata.dll was a
dead end and is documented as such: its single export getTableData is an
anti-tamper attestation routine, not a data accessor.

Cross-validated against a completely independent method. tools/sweep_collect.py
serves candidate ids as a synthetic club and reads back the identity the CLIENT
resolved through its own merge. 573 of 573 overlapping names agreed exactly, and
the single id present in one and not the other is 26501, the target of the
documented 22800..22879 Legends remap -- which is also what produced 'Alex Hunter
x80' in a sweep and had looked like a bug.

Field honesty, because half of these are real and half are not:
  playerid/rating/name  REAL   the roster
  club/nation/league    REAL   we send zeros and the CLIENT fills them (the merge
                               only fills those fields when they arrive as zero)
  position              PARTLY 59 from the game's own per-card cache, 17 curated
                               by hand, the rest synthetic but deterministic
  attributes            SYNTH  derived from rating and position

169193 is dropped from the curated set: it was in VERIFIED_ASSET_IDS and is not a
real player. The client resolves it to the database's empty placeholder row, which
renders as 'Jamal Blackman'. Two independent methods agreed.

NOTE BEFORE PUSHING ANYWHERE PUBLIC: data/roster.json is EA's player data,
extracted from your own installation. Fine locally; think twice about publishing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW

2026-08-04 21:08:52 -07:00

funman300

ffb0e6033c

fifa17-recon: real card pool -- 79 players, three tiers, and packs that differ

The pool was 18 players rated 85 to 94. open_pack() split it with `(rating >= 75) ==
gold`, so the bronze pack's filter matched NOTHING and fell back to the whole pool:
all three packs dealt gold rares and the bronze pack was a lie. The file's own TODO
asked for "a full dbdata.dll extract (~18k players)".

NEW fut_cards.py: 79 players, 39 gold / 20 silver / 20 bronze, 7 leagues, 20 nations,
18 teams, every outfield position plus GK, no duplicate asset ids. PACK_CATALOG now
carries a weighted `tiers` draw per pack. Simulated 40 opens of each:

  Bronze Pack   {'bronze': 159, 'silver': 41}    39 distinct cards, 12 positions
  Gold Pack     {'silver': 110, 'gold': 170}     59 distinct cards, 12 positions
  Premium Gold  {'gold': 392,  'silver': 48}     57 distinct cards, 12 positions

WHY THIS IS NOT THE dbdata EXTRACT, and why that does not matter yet. dbdata.dll is a
real PE with one export, getTableData, whose 2.5MB payload sits in a section named
.xdata that disassembles as obfuscated code rather than a table directory, so the base
DB is not statically extractable without running that export under Wine or defeating
the obfuscation.

More to the point it would change nothing on screen today. Per docs/CARD_SYSTEM.md the
card view-model 0x1800d7920 reads EVERY rendered field (rating +0xb4, position +0x146,
nation +0x148, teamid +0x94, six attrs +0x98..0xac, name +0xdd) from a definition
record resolved at item+0x10 out of the client's own CardsDb map, and NEVER from our
item JSON. Offline that map is EMPTY, so every lookup misses and a blank record is
emitted. No assetId we send, real or invented, can produce a named card until that map
is populated. That is a separate job (CARD_SYSTEM options A/B/C) about the CLIENT's
map, not about our pool.

What the pool DOES control is everything the server is source of truth for: the
gold/silver/bronze split, leagueId/nation/teamid which are exactly what the club-stats
drill-downs read (those now work, S20, and were being fed 5 leagues from 13 nations),
preferredPosition which decides whether a squad can be filled at all, and the six
attributes behind the market filters.

Asset ids: 18 are genuine FIFA 17 ids and are listed in VERIFIED_ASSET_IDS. The rest
are structural, and the docstring says so plainly rather than passing them off as real
players. Because the CardsDb map is empty offline an id being wrong has no visible
effect today; if the identity work lands, that set is the diff target.

Backwards compatible: open_pack() still honours the legacy `gold` boolean when no
tiers are given, and the old list survives as _LEGACY_POOL for the starter squad.

392 + 61 checks green.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW

2026-08-04 15:23:23 -07:00

3 Commits