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

Compare commits

base: funman300/OpenFUT:python-fifa17-baseline-2026-08-10
Branches Tags
funman300/OpenFUT:main funman300/OpenFUT:fifa17-fut-squad-and-userinfo funman300/OpenFUT:retained/20260819-staging/e8d1c1d-seasons-draft-wip funman300/OpenFUT:rust-migration/protocol-blaze-foundation
funman300/OpenFUT:python-fifa17-baseline-2026-08-10
...
compare: funman300/OpenFUT:a3fd51692f880deae8827de324c46253e937fdbe
Branches Tags
funman300/OpenFUT:main funman300/OpenFUT:fifa17-fut-squad-and-userinfo funman300/OpenFUT:retained/20260819-staging/e8d1c1d-seasons-draft-wip funman300/OpenFUT:rust-migration/protocol-blaze-foundation
funman300/OpenFUT:python-fifa17-baseline-2026-08-10

88 Commits
python-fifa17-baseline-2026-08-10 ... a3fd51692f

Author SHA1 Message Date
funman300 a3fd51692f fifa17-recon: the trading gate is still shut, and two of yesterday's conclusions were wrong 
Ships the club-item subtype correction and the tradeable plumbing, and records two
refutations of claims made earlier in the same session. Nothing here is a working fix
for trading; the honest state is that the gate is still closed and we now know more
about why.

REFUTED 1: "the Blaze client-config store opens the trading gate". It does not, and the
flag is inert. IS_TRADING_ENABLED is an OUTPUT NAME. FUN_18006cc60 is a publisher: at
0x18006ccc6 it calls [rax+0x270] to READ gate byte 0x1fd2e, then lea rdx,[
IS_TRADING_ENABLED] and hands the value out under that name. The only rip-relative
reference to the literal 0x1801fc118 in all of .text is that lea; there is no comparison
against it anywhere, so no client-config key of that name can be read as an input. That
also undermines the IS_* store keys shipped beside it: their apparent success was never
actually attributed to them.

REFUTED 2: "the gate byte flipped to 1". It reads 0. It was measured as 1 shortly after
CardsDLL mapped and that was over-claimed as a success; a thorough re-measurement read 0
on the SAME pid and model pointer, and a fresh session reads 0 with an unambiguous raw
dump (model+0x1fd18.. = 01000000 00000000 00000000 00000000 3c000000 01 01 00 01, the 00
being 0x1fd2e). Either the first read was transient or something clears it after login.
The only writer is FUN_18011dc50 at 0x18011dc91, so a 0 means something RAN and wrote it.

AND THE "/settings IS DEAD" CLAIM FALLS TOO. FUN_18011dc50 is not unreachable: it is a
VIRTUAL method at model vtable slot +0x988 (absolute pointer 0x18021cc28). A direct-call
search found no callers because Ghidra does not resolve virtual calls, which is the same
dispatch-form trap that has now produced seven wrong verdicts here. The real chain is
    settings response -> FUN_180174630 -> FUN_18013c6d0 (deser)
      -> completion callback FUN_180173e00 -> vt+0x988 and vt+0x998 -> gate bytes
and FUN_180173e00 bails before applying anything unless the int at response+0x1c is
zero. Which atom writes +0x1c is unknown and is the thing worth chasing.

The measurement behind that claim also had a gap: it checked +0x1fd14, +0x1fd4c and
+0x1fd54 for the maximumTradePileSize=77 probe but NOT +0x1fd1c, which is the actual
TRADE_PILE_SIZE (read via vt+0xa58 = FUN_18011bf30). So the probe never tested the field
it needed to. Serving 77 and reading +0x1fd1c is the clean falsifier and is still open.

Recovered and worth keeping: an authoritative slot-to-name table from the publisher.
  vt+0x270 IS_TRADING_ENABLED -> +0x1fd2e        vt+0x2b0 IS_FRIENDLY_SEASON_ENABLED -> +0x1fd3a
  vt+0x2b8 IS_TOURNAMENT_QUIT_ENABLED -> +0x1fd3b vt+0x2c0 IS_PROCESSING_STATE_ENABLED -> +0x1fd3c
  vt+0x2c8 IS_DRAFT_MODE_ENABLED -> +0x1fd3d      vt+0x2d8 IS_STORY_MODE_REWARD_ENABLED -> +0x1fd3f
  vt+0x2f0 IS_RETURNING_USER_REWARDS_SCREEN -> +0x1fd40  vt+0xa58 TRADE_PILE_SIZE -> +0x1fd1c
That also locates the red TRANSFER LIST 0/0: it is +0x1fd1c, currently 0.

WHAT IS ACTUALLY SHIPPED HERE, all default off:
  * FUT_TRADEABLE sends untradeable=false. Verified landing at item+0x49 (stored
    INVERTED by case 0x361) on a live club record. Applied on every READ path, not only
    in _item(), because the save holds 246 items minted before the flag existed and the
    club route serves them straight from the save. That gap was caught by reading the
    served JSON, not by unit-testing the factory.
  * FUT_TRADING adds tradingEnabled and IS_TRADING_ENABLED to the Blaze config. Kept
    only as a record of the refutation, with the reasoning inline so nobody retries it.
  * fut_clubitems FAMILIES subtypes corrected: kit 9, stadium 10, badge 11 (cardtype 7,
    not 9), ball 30, league logo 31. Every previous value sat in the 0x91..0x96 TROPHY
    block. probe_shelf's candidate set lacked 9, 10 and 11, so the probe route the docs
    preferred could never have answered this for three of five families.
  * Club kits and badges now carry teamid, reintroduced ALONE after the 2026-08-05 crash
    (which was never bisected; value is the established suspect and that response also
    carried 30 items across five wrong subtypes). itemType dropped: it was unobserved and
    never copied into the record.

Live: 439 contract checks, 414 card-family checks, market suite, all pass. The transfer
market still refuses with zero requests and the menu entries are still greyed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-06 12:47:02 -07:00
funman300 e578443d73 fifa17-recon: tradingEnabled is 0, and that is why the transfer options are greyed out 
Card-subsystem pass, 11 agents plus three adversarial verifiers. Full writeup in
docs/plan-2026-08-06-card-subsystem.md. Two of the results below correct things I
committed earlier today.

THE GREYED-OUT TRANSFER OPTIONS ARE EXPLAINED. "Place on Transfer List" and "List on
Transfer Market" have been disabled in the reveal screen and nobody knew why.
TO_TRADE_PILE (FUN_1801a7260) requires BOTH item+0x49 tradeable AND a service gate at
vtable slot +0x270. That slot is `movzx eax, byte [rcx+0x1fd2e]; ret`, and 0x1fd2e is
the tradingEnabled gate byte. Read live and reproduced independently:

  slot +0x2b0 friendlySeasons  disp 0x1fd3a  VALUE=1
  slot +0x2c8 draftMode        disp 0x1fd3d  VALUE=1
  slot +0x2e0 packOpeningAnim  disp 0x1fd45  VALUE=1
  slot +0x270 tradingEnabled   disp 0x1fd2e  VALUE=0

tradingEnabled is the FIRST gate byte found that is not 1. This partly rehabilitates
the settings work from this morning: that plan died because every gate it targeted
already read 1, and the conclusion drawn was that the settings array does not matter.
It does. It matters for a flag nobody was looking at, and tradingEnabled is ALREADY in
_SETTINGS_KEEP, plumbed and never sent because _SETTINGS_MODE defaults to off.

So the fix is two things, not one: FUT_SETTINGS=keep AND untradeable false. Shipping
only the boolean would look like the finding failed.

THE DISCARD "MISS" NEVER EXISTED, which corrects e3092ca. fcc_discardcoins is resident
and complete, the client lookup runs and is correct, and it lands at item+0x3c. The
tile simply binds +0x38, which is OUR value, and nothing falls back to +0x3c. So the
client was not failing a lookup; it was faithfully displaying the 0 we sent. Same
observable, completely different mechanism, and the version in e3092ca is wrong.
FUT_DISCARD_SEND remains exactly the right fix, now for the right reason.

WHAT FUT PAYS FOR STAFF IS NO LONGER UNKNOWN. Same formula, but the rating input is the
table `value` column: gkcoachcards 9000081 value 66 gives 36, and the client's own
+0x3c reads 36. That closes the gap I flagged in e3092ca as not-guessed.

CLUB ITEM SUBTYPES, the standing unknown in CARD_SYSTEM.md, are settled: kit 9,
stadium 10, badge 11 are cardtype 7 (not 9), ball 30, league logo 31 by elimination.
All five constants in fut_clubitems.FAMILIES are wrong and all five currently sit in
the TROPHY block 0x91..0x96. Note the probe route the doc preferred could never have
answered this: probe_shelf()'s candidate set lacks 9, 10 and 11, so it would have spent
a launch and returned nothing for three of five families.

THE CARD MODEL FIELD MAP now exists, 28 rows, every field we send with the byte it
lands on and whether the client keeps it. Built by diffing what we serve against the
parsed records in the live heap (stride 0x180, anchored by a satellite back-pointer
rather than by assuming the +0x38 offset). Corrections that change what we serve:
+0x54 is the discard LEVEL not itemType, +0x49 is untradeable INVERTED, +0x5c is
itemState, definitionId is not an atom at all.

A HIGH-CONFIDENCE ABSENCE CLAIM WAS REFUTED IN VERIFICATION: playStyle IS stored, at
+0x88. Its controls were raw scalars while playStyle is a DECODED scalar, so the
control was the wrong FORM. That is a new variant of the absence trap, which has now
cost six wrong verdicts, and it is recorded in the doc.

FIX TO MY OWN PATCH from e3092ca: purchased() and last_pack() lacked the _with_discard
wrapper that items() had, so the pending pile, which is the one place a quick-sell
value is actually read, served unstamped cards. Found by verification, not testing.
All three read paths now stamp.

Correcting an overstatement in e3092ca: "turning the flag off is a true revert" holds
for the read paths, which copy, but NOT for cards minted while armed, because _item()
stamps at creation and those persist (9 items currently). Kept deliberately: the pack
reveal serves itemList straight from open_pack(), not through purchased(), so removing
creation-stamping would leave the screen that matters unstamped. Persisted values are
correct and self-heal, since every read recomputes and overwrites.

Nothing here has been on screen. Six patches are proposed in the doc as pasteable text,
env-flagged, defaulting off, none applied.

Live: 439 contract checks, 414 card-family checks, market suite, all pass.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-06 10:07:01 -07:00
funman300 e3092ca0f9 fifa17-recon: the client now shows the quick-sell value it is actually paid 
Follow-on to 21a81ad, both halves confirmed live.

FUT_DISCARD_TABLE IS PROVEN. Quick selling a 75-rated rare gold paid 600 and the
balance moved 9,844,900 -> 9,845,500, exact. The invented tier would have paid 150.
75 * 800 / 100 = 600, straight off the recovered fcc_discardcoins row.

BUT THE SCREEN SAID 0, which is why this commit exists. The value was right and
invisible: "Quick Sell 0" on the card and "Quick Sell all remaining Items 0" too, so
the wallet contradicted the display on every card. Cause is the guard the table work
had already reversed. FUN_18013fe00 stores our discardValue (atom 0xd7) at item +0x38
and 0x180141025 skips the client's own fcc_discardcoins lookup only when that value is
NON-ZERO. We seeded 0, so the client ran its own lookup, that lookup returns no row for
our cards, and it rendered 0.

FUT_DISCARD_SEND puts the value on the wire and the client uses ours verbatim. Live
result, one launch:
    a 77-rated rare gold shows "Quick Sell 616"   (77 * 800 / 100 = 616, exact)
    "Quick Sell all remaining Items" shows 5,640
and 5,640 is exactly the sum of the ten rated PLAYER cards in the pending pile. The
eleventh, a consumable, is excluded by the client from the bulk figure; the twelfth is
a staff card we deliberately send no value for. Both halves of the display now agree
with what the server credits.

WHY THE CLIENT'S OWN LOOKUP MISSES for our cards is still UNKNOWN. This routes around
that question rather than answering it, and it is worth answering.

TWO CORRECTNESS FIXES THE REPORT DID NOT COVER, both found by running the whole save
through the formula rather than trusting the 22/22 sample:
  * The recovered formula scales by rating, so a rating-less STAFF card collapses to 0.
    The old tier paid 50, so shipping it as-is was a regression. discard_value() now
    returns None when the formula does not apply and callers fall back. What FUT really
    pays for staff and consumables is UNKNOWN; the likely answer is the unscaled table
    price, but that is a guess and is not shipped as one.
  * A missing table row also returns None rather than 0, for the same reason.
  Verified across all 246 club items plus the pending pile: not one pays 0 coins.

discardValue is stamped inside the single item factory so every path gets it (pack
contents, starter grant, club, market), and additionally on the club READ path, because
_item() only covers cards minted from now on while the save already holds 246 built
before the flag existed. Stamped on the way out and NOT persisted, so the save stays
clean and turning the flag off is a true revert. Confirmed: 0 items on disk carry the
key.

FUT_DISCARD_SEND requires FUT_DISCARD_TABLE and silently stays off without it, so the
invented tier can never reach the screen and become authoritative-looking.

Freeze risk: low and in the safe direction. discardValue is a plain INT read by the
scalar getter 0x1801c79d0; every freeze on this project has come from an object or
array where a scalar was expected, never the reverse.

Both flags still default OFF. Live: 439 contract checks pass, market suite passes.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-06 07:55:05 -07:00
funman300 21a81ad63c fifa17-recon: the real quick-sell table, and the grouping bug is not in our layer 
Multi-agent pass over the store subsystem, 11 agents, findings run through three
adversarial verifiers. Full writeup in docs/plan-2026-08-05-store-subsystem.md.

THE REAL DISCARD TABLE IS RECOVERED. quick_sell() paid an invented rating tier
(600/300/150/50) that was wrong for every single card. The real table is
fcc_discardcoins in the client's own game DB, 141 rows keyed (cardtype, level, rare),
read out of the running client and verified 22/22 against live items:

    value = round_half_up(rating * price / 100)
    level    = 3 if rating >= 75, 2 if 65..74, else 1   (0x180141e8a..0x180141ea3,
               derived from rating, NOT a wire field)
    cardtype = FUN_1800d8330(cardsubtypeid), decoded from its jump table and checked
               across every subtype 0..599 with zero disagreements

A 94-rated gold rare is 752, not 600. A 76 rare is 608, not 150. A 55 bronze is 17,
not 50.

This also closes a disagreement nobody had noticed: the CLIENT already computes and
displays the correct value locally whenever our discardValue (atom 0xd7) is 0 or
absent. FUN_18013fe00 stores our value at item +0x38 and the guard at 0x180141025
skips the local computation when it is non-zero. So the screen has been showing the
real number while the server paid a made-up one, on every quick sell ever made.

Verified beyond what the report claimed, because a missing table row pays ZERO and
that would be a regression the old flat tier could not produce: across all 236 items
in the live profile, 230 map to cardtype 1 and 6 to cardtype 6, and NOT ONE would pay
0 coins. Table reproduces at 141 rows and the worked example lands exactly.

ZERO WIRE CHANGE, FUT_DISCARD_TABLE default off. Nothing new is sent; only the coin
figure the server credits moves. This is the patch worth defaulting on after one
in-game check, which is simply quick-selling a card and seeing the coins paid match
the value the card was already displaying.

THE GROUPING BUG IS NOT IN CARDSDLL, and the fix ranked first would have wasted a
launch. Live in the running client all three display groups own exactly the right
pack, there is exactly one copy of each pack record in 4 GiB, and nothing we send is
mis-parsed. The parsed model is correct and the Scaleform layer picks the wrong pack
when turning a tile click into a category id. displayGroupAssetId is served as 1/5/6
while the screen's category field reads 3, and group tiles carry a hardcoded
CATEGORY_ID of 0. Confirmed by direct read: ordinal 3, assetId 6, i.e. Premium, while
the last click was Gold.

The heap map that made this possible, all scoped to one pid: display-group vector
control block, 3 elements of 0x108; group record fields at +0x00 sortPriority,
+0x04 displayGroupAssetId, +0x40 a one-element pack vector; inner pack record 0x1a8
with packType at +0x38, ids at +0x70/+0xac, price at +0xa0, quantities at +0xc0..+0xd0.

extPrice SHOULD BE DELETED, not corrected. Both sub-parsers read only
externalPriceId; amount and currency are discarded. Sending the key at all creates an
"mtx" currency row that switches on a real-money price line the client can never fill
offline, which is the literal "or %1s" on every tile.

A WORRY NOBODY HAD RAISED, and I confirmed it from our own logs: the client has sent
packId 6 on every purchase it has ever made, four for four tonight and six for six
across history. We have never observed a successful buy of anything but Premium Gold.

Also settled: FUT_STORE_DISPLAYGROUP=0 is the right resting state, argued from
mechanism rather than from history; FUT_USERINFO=packs stays off because the
unopened-pack counter is client-mutable and the flag ladder silently drops squadList;
POST /user is a latent hard freeze that has never fired because the client never
issues that POST.

Honest coverage: the ActionScript layer is unread by everyone and every remaining
store mystery lives there.

Live: 439 contract checks pass, market suite passes, both flags off.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-06 07:43:51 -07:00
funman300 3f3d5704a7 fifa17-recon: quick sell has never been reachable, and finalFunds is the rendered price 
Live run, 2026-08-05 evening. Three results, one of them a route that has been dead for
the whole life of the project.

QUICK SELL WAS NEVER SERVED. Captured on the wire:
    DELETE /ut/game/fifa17/item/100000240      (single card, id in the URL, no body)
ENDPOINT_MAP documented the path as `ut/delete/game/%s/item`, ROUTES was built from the
doc, and the regex therefore never matched a real quick sell. Every quick sell fell
through to the catch-all, so quick_sell_route() and STORE.quick_sell() behind it had
never once been called.

The empty response was not a harmless no-op. This body is BALANCE-BEARING: the client
takes its coin total from it, so with totalCredits absent it rendered an uninitialised
value. A real session showed 1,133,686,384 coins against a true balance of 9,889,600.
Display artifact only, corrected by the next GET /user/credits, and the save was never
touched, but it is the reason a stub is not acceptable here.

quick_sell_url_route() serves the real form and returns the corrected shape,
{"items":[{"id":N}],"totalCredits":N}. DEFAULT ON, which the house rule now permits:
two quick sells fired through it in one session, each credited 150 and removed the
card, and the coin arithmetic reconciled exactly against the 15,000 pack purchases
either side of them. An unknown id returns {"items": []} rather than claiming a sale we
cannot account for.

Still UNKNOWN and deliberately not chased: whether the client ASSIGNS totalCredits as
the new balance or ADDS it as a delta. We send the new balance. The discriminating
window is about five seconds wide, because the client refetches GET /user/credits
straight afterwards, so either reading self-corrects and the practical impact is a brief
wrong number. It mattered only while we answered {}, because that garbage persisted.
The credit amount is STORE.quick_sell()'s invented rating tier, not FUT's real discard
table, which remains unknown.

finalFunds IS THE RENDERED COIN PRICE. Served funds=15000 / finalFunds=4321 on one pack
and the tile read 4,321. funds is not displayed. ENDPOINT_MAP updated to CONFIRMED LIVE
with the method recorded. FUT_PRICE_PROBE, the flag that produced it, stays default off
and is disarmed: it puts a price on a tile that the buy path does not charge.

TWO UNPLANNED FINDINGS, both recorded for the next round rather than fixed here:
  * The store grouping is broken and it is NOT cosmetic. All three packs collapse into
    one display group, and the Bronze, Gold and Premium group tiles all drill into the
    same single Premium Gold pack, so TWO OF THREE PACKS CANNOT BE BOUGHT. We send
    displayGroup {"value": name} but never displayGroupAssetId (0xda), so everything
    lands in group 0. The docs had this parked as a cosmetic "tiles read unknown"
    issue; it is an availability bug.
  * The FIFA Points price renders as the literal "or %1s", an unsubstituted printf
    placeholder. extPrice.finalPrice is served as {"amount":N,"currency":"mtx"} and
    "mtx" is evidently not a currency token the client resolves. Cosmetic.

Corrected in passing: packContentInfo DOES reach the tile (11 ITEMS / 11 GOLD /
11 RARES against exactly what we serve). An earlier screen showing zeros was the
display-GROUP level, which carries no content info. D3 was right.

Live: 439 contract checks pass, both probe flags off, store prices back to honest.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-05 20:03:41 -07:00
funman300 89da7b7609 fifa17-recon: /hub refutes yesterday's envelope conclusion, and two ENDPOINT_MAP freezes 
Three things: the envelope rule was wrong and is corrected, /hub is settled, and two
documented response shapes that would freeze the client are fixed.

THE CORRECTION. The previous commit concluded that a three-token root consumes `{`, the
first field name and that field's value without dispatching them, so the first key of a
flat body was silently eaten, and that `login` had therefore never been delivered on
POST /user. That is WRONG and is withdrawn, along with the claim that the key order of
the auth dict is load-bearing.

The first call to FUN_1801c7f10 returns token 7 and consumes NO input. It is a
once-only start-of-document token, guarded by the flag at parser+0xda together with the
zero character counter at parser+0x30. So the three tokens are BOF, `{`, and the FIRST
FIELD NAME, and the key loop dispatches from that first key onward. The `== 10` test on
the third token is not an envelope check, it is the empty-object early-out: for `{}` the
third token is END_OBJECT and the root exits with its constructor defaults intact, which
is why answering `{}` has always been safe.

Corrected enum: 7=BOF 9=START_OBJECT 10=END_OBJECT 11=FIELD_NAME 12=START_ARRAY
13=END_ARRAY. The enum itself was right before; the inference from it was not.

HOW IT WAS CAUGHT, which is the part worth keeping. Not by more decompiling. /hub is
served flat and the wrong model predicted its first key would be discarded, so the
prediction was checked against the client's own memory: clubPlayers read back as 205,
the value the server sent, at model+0x1fd70+0x3c with the slide proven against the FNV
prologue first. One live read refuted a chain of otherwise sound static reasoning in
about a minute. tools/hub_counter_probe.py keeps it repeatable.

Consequence worth flagging: a wrapper is not just unnecessary for these roots, it would
be harmful, since a wrapper key hashes to an atom with no arm and the whole object is
skipped. That makes the createPackResponse envelope DOUBTFUL rather than confirmed.
Atom 0xbe has no arm in FUN_180162880. There is no live evidence either way because
nothing has ever parsed that body, so the buy path is left exactly as it is.

TWO ERRORS OF MINE ON THE WAY, both recorded in the doc because both are cheap to
repeat. I searched for RS4:FutGetHubServerResponse, found nothing and reported that no
hub class existed; the class is FutGetHubDataServerResponse (literal 0x18022ce40,
vtable 0x18022cd48, deser 0x1801738b0, control FutSquadSave -> 0x180171a60 matched in
the same run). Then I scanned 152 deserializers for clubPlayers, got zero hits and a
passing control, because the guard is `!= 0x90` and my pattern only matched `== 0x`.
The control passed only because auctionCount happens to use `==`. A control that does
not exercise the same code shape as the target is not a control. The comment already at
utas_server.py:1076 had the hub chain right the whole time.

ENDPOINT_MAP corrections, both freeze-risky as written, neither affecting what we serve
today:
  * duplicateItemIdList is an ARRAY OF OBJECTS (element deser 0x180138e10), not the int
    list at :1095. Bare ints where the element parser expects objects is a tokenizer
    desync, i.e. a hard freeze at 0x1801c7f1a. Control that this is not a misread:
    dreamSquads 0xe9 in FutMoveCard genuinely is a bare int array.
  * FutDiscardCardServerResponse is {"items":[{"id":N}],"totalCredits":N}. There is no
    top-level id.

No behaviour change. utas_server.py is comment-only. 439 contract checks pass.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-05 19:35:27 -07:00
funman300 1605e6effd fifa17-recon: the envelope rule, and the one key of the auth body that is silently eaten 
The open question was whether a response deserializer DESCENDS a wrapper or PROBES for
one. Three roots spend an identical three tokenizer calls before dispatch, yet we serve
some bodies wrapped and some flat, and not all of those could be right.

TOKEN ENUM, decoded from the class table at DAT_18023dd40 and the switch in the
classifier FUN_1801c67a0 (the push/pop arms key off container state 2 = object,
3 = array):

  9  START_OBJECT      case 0x64, pushes state 2
  10 END_OBJECT        case 0x65, pops state 2
  11 FIELD_NAME        confirmed independently: FUN_18013bd40 tests +0xd0 == 0xb then
                       atom-hashes the string at +0xf8
  12 START_ARRAY       case 0x66, pushes state 3
  13 END_ARRAY         case 0x67, pops state 3
  1  error             the caseD_78 sink

So the three tokens are `{`, the first FIELD_NAME, and the token opening that field's
value. The envelope is structurally required and its name is NEVER hashed, which is why
FutCreatePack's ladder has no arm for createPackResponse (0xbe) and does not need one.
Coverage for that absence: the ladder has exactly four arms (0xec, 0x16e, 0x1dd, 0x264)
and 0xbe does not occur anywhere in the full 4702-char decompile, printed in full.

The competing reading rested on a factual error. It claimed the /purchased root spends
the same three tokens. FUN_180124ee0 spends TWO and hands off to FUN_18013bd40, which
spends the third. Same total, split across two functions. /purchased never was a
counterexample.

THE BUG THIS FOUND IS NOT THE ONE THAT WAS PREDICTED. The doc expected starterPack,
squad and userData to be swallowed on POST /user. They are not. FutCreateUser
(0x18014cc60) has ladder arms for exactly the five keys we send, and four of them
dispatch correctly at the outer level. The one that does not is `login`: its name is
eaten as the anonymous envelope and its value as the third token. It has an arm, so the
client wants it, and it has never once been delivered.

The second-order consequence matters more than the first. The key order of that dict is
load-bearing and nothing said so. Put userData first and the client loses the entire
user record, silently, with no error and no log line. That warning now sits in the code
next to the dict, which is the only place someone about to reorder it would look.

No behaviour change here. The utas_server.py edit is a comment. 439 contract checks
still pass. The probable proper fix, wrapping all five keys one level down inside a
single envelope key, is a hypothesis with a mechanism rather than a proven fix, and it
touches the login path, so it is not made here and would go behind a flag defaulting
off.

Writeup is section 2 of docs/plan-2026-08-05-pack-opening.md, added by the previous
commit. Opened by this and still UNKNOWN: GET /hub is answered with a flat two-key
body, which under this rule a three-token root would silently truncate, but there is no
FutGetHubServerResponse class and neither atom has a code xref, so /hub may not go
through a generated root at all.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-05 19:25:01 -07:00
funman300 afdbb364ca fifa17-recon: pack opening reversed end to end, and there is no pack-inventory endpoint 
A twelve-agent pass over the parts of pack opening we did not understand, run against
the live client (CardsDLL slide proven, not assumed) plus static CardsDLL. Findings
below survived an adversarial verification round that corrected several of them; where
a verifier and a finder disagreed, the verifier won.

THE HEADLINE IS A NEGATIVE, and it deletes work rather than creating it. There is no
pack-inventory endpoint in FIFA 17 and there never was. Proven three independent ways:
the 48-entry UTAS route template array at 0x18021df80, a regex for "ut/" over the whole
PE, and the 125-row client action table at 0x1802caa20, which is the complete set of
requests the client can originate. "Serve the pack inventory" comes off the backlog.
The unclaimed-pack tile and My Packs are two fields on responses we already build.

Corrections to ENDPOINT_MAP.md, both freeze-risky as written:
  * duplicateItemIdList is an array of OBJECTS (element parser 0x180138e10: itemId
    0x16d, duplicateItemId 0xeb, itemLoans 0x16f, duplicateItemLoans 0xed), not the
    int list documented at :1095 and :218. Control that this is not a misread:
    dreamSquads 0xe9 in FutMoveCard genuinely is a bare int array and parses with no
    inner object loop. We serve [], so this is a docs bug today and a live freeze the
    moment somebody implements it from the map as written.
  * FutDiscardCardServerResponse is {"items":[{"id":N}],"totalCredits":N}. There is no
    top-level id. :968-971 is wrong twice over.

packContentInfo is DECORATIVE. It is read only into a store-tile view model, and
nothing compares the declared counts against the delivered itemList, so open_pack()
does not have to honour the distribution.

The reveal is entirely CLIENT-SIDE. Walkout, tiering, colours and ordering are
arithmetic over fields we already send. Genuine outstanding server work reduces to
three items: duplicates, quick-sell credit, unopenedPacks.

Perishable intel captured: the real FIFA 17 retail pack catalogue, 41 SKUs with Origin
offer ids, recovered from the client heap as a parsed copy of data/store/storecfg.xml.
It is in no file on disk, only in a running process.

futmem/ is a standalone read-only Rust crate for this kind of work (maps, find,
strings, read). Read-only by construction: it opens /proc/<pid>/mem with File::open
and there is no code path in it that can write to another process, because a live game
session depends on that. Its own [workspace] table keeps it out of the parent
workspace. Chunked scanning overlaps by pattern_len-1 so a match spanning a chunk
boundary is still found.

utas_server.py gains FUT_PORT/FUT_LOG so a throwaway instance can be started without
bouncing the one the live client is using. Defaults unchanged (8099, /tmp/utas_server.log).
Noted for the record: this edit came from a research agent that had been told not to
touch server code. It is benign and useful, but it was out of scope.

Not committed: the doc proposes ENDPOINT_MAP.md changes as pasteable text rather than
applying them, and every proposed server change defaults off per the house rule.
Nothing in this commit changes a response the client sees.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-05 19:24:37 -07:00
funman300 d0dbfa99c0 fifa17-recon: the /settings gate bytes were never zero, and the plan built on that is dead 
Yesterday's settings-gate plan asserted that IS_FRIENDLY_SEASON_ENABLED and
IS_DRAFT_MODE_ENABLED "have never been set to true by anything, on any run", and
proposed spending a launch on that premise. Measured against the running client,
both read 1, and so does packOpeningAnimationEnabled, while /settings has only ever
been answered {"configs": []}.

  disp 0x1fd3a (friendlySeasonsEnabled)      value = 1
  disp 0x1fd3d (enableDraftMode)             value = 1
  disp 0x1fd45 (packOpeningAnimationEnabled) value = 1

Reproduced on two separate launches and two different pids.

Where the reasoning went wrong: the finding that FUN_18011dc50 is the only writer of
those bytes, and that the FutDataManagerImpl constructor never touches them, was
correct. The inference was not. The applier runs whether or not the configs array has
content, and the struct it is handed defaults these fields to 1, so the bytes were
being written all along. "Nothing populates the array" was treated as "nothing writes
the byte". Only the first of those was ever established.

Seasons therefore does not refuse because its gate byte is false. Its gate byte is
true. That diagnosis restarts, and the live test in section 3 should not be run as
written. The doc keeps the wrong turn on the record rather than quietly deleting it.

tools/gate_byte_probe.py makes this repeatable instead of a one-off. It is read-only
(O_RDONLY + pread), resolves the pid by comm, re-derives the CardsDLL slide from
/proc/<pid>/maps rather than caching it across launches, proves the slide against the
FNV prologue at 0x180180d00 read from the on-disk PE before trusting any address, and
decodes each gate displacement out of its accessor stub (0f b6 81 <disp32>) rather
than reading it from a table. Needs the client at the FUT hub, since CardsDLL loads
only then.

Also carries the two /settings changes that were pending from before: the mode
defaults to `off` (the live-proven baseline, since nothing here has faced the game)
and the transfer-pile probe is 77 rather than 100, because 100 is a stock-looking
number that would prove nothing if it showed up in game.

Live: 439 contract checks pass. check_settings_flags.py passes in all four modes.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-05 19:24:02 -07:00
funman300 897259c8fb fifa17-recon: the /settings 42-flag gate, and why Seasons never asks 
ENDPOINT_MAP said this class reads one key, `configs`, and that was true and
useless. What it missed is what happens after each element closes: the client
feeds the STRING VALUE of `type` back through the atom hasher and switches on
the result, 42 arms wide. A flag is a row, not a key, and the client hashes our
string itself.

Followed it to the end. FUN_18011dc50 is the only writer of the IS_* UI gate
bytes inside FutDataManagerImpl, every line is `byte = (field == 1)`, and the
constructor never touches those bytes. So a flag nobody sends is a gate nobody
opens. friendlySeasonsEnabled and enableDraftMode have never been sent by
anything, which is a mechanism for Seasons refusing while making zero requests
to any of the four servers.

The store is the control that makes this readable: IS_STORE_ENABLED is the same
kind of byte and its screen works, because storeEnabled and friends already
ship through the Blaze config store. That list has no seasons or draft flag.

Ship the gates behind FUT_SETTINGS (off/keep/gates, default gates), and
re-assert the working store flags in the same array on purpose: once a
populated array makes the applier run, it writes EVERY gate byte, so omitting
them could switch off a screen that works today.

maximumTradePileSize=100 rides along as a positive control, because a boolean
that changes nothing cannot distinguish "the flag did not help" from "the array
never reached the consumer".

check_settings_flags.py asserts each shipped name against the atom table AND
the recovered switch, since a misnamed flag is silently inert and looks exactly
like a failed fix. enableSquadBuildingSetsFeature is the reason both checks are
needed: a real atom with no arm here.

Live: 439 contract checks pass, market unit suite passes.
Not yet tested in game.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-05 12:11:20 -07:00
funman300 9348b83374 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 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-05 12:06:31 -07:00
funman300 ccf912c157 fifa17-recon: club items crashed the client -- unestablished fields, and too wide a blast radius 
The game hung and then crashed on the first equippables fetch. My fault twice over.

CAUSE, primary. I copied teamid, leagueid and value straight out of the fcc row as
extras. `value` appears elsewhere as an OBJECT member (displayGroup {"value": ...}),
and a scalar where an object is expected is the type-desync busy loop at 0x1801c7f1a
-- which presents exactly as "the game is taking its time" and then dies. Omission is
safe; an unestablished field is not. That is this project's own rule and I broke it
for three fields that were not needed to draw a card. All three are gone.

CAUSE, contributing. The last request before the crash was type=equippables&count=11
and we answered with 30 items spanning FIVE unverified cardsubtypeids at once: the
widest possible blast radius for a wrong shape, and it tells you nothing about which
subtype was wrong. equippables now answers [] until the subtypes are confirmed one
family at a time, and shelf() takes a families= filter so a test can serve exactly one.

Adds FUT_CLUBITEMS=probe:<family>, which serves one item per candidate subtype for a
single family, so the screen names the correct subtype instead of me guessing a third
time. Eight items, one family, one question.

The flag already defaulted off, so a plain restart cannot serve any of this.

439 + 414 checks green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-05 11:59:38 -07:00
funman300 f5002a0d4d fifa17-recon: serve club items -- the type names are SINGULAR and they were on the wire 
Arming the counters made the client name the route within seconds, exactly as it did
for consumables:

    club?type=equippables&count=11
    club?type=stadium&count=200
    club?type=ball&count=200

So it IS club?type= for this family, with SINGULAR names -- stadium and ball, not
stadia and balls -- and equippables as the combined club-customisation view. Those
requests were being answered from STORE.items(), which holds no club items because
the shelf is synthetic, so they correctly returned empty and looked like nothing was
happening.

Now serves the shelf: stadium 4, ball 6, badge 8, kit 8, equippables 30 (all four
combined), with player untouched at 205.

The cardsubtypeid values remain UNVERIFIED. cardtype 9 has no arm in the merge, so a
wrong subtype cannot announce itself; whether these render is now a live question and
the next screenshot answers it.

439 + 414 checks green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-05 11:55:07 -07:00
funman300 3b58b29094 fifa17-recon: club-item counts, and packs that contain more than footballers 
Correcting an overstatement first: I said every card family works. Balls, stadia,
badges and kits do not, and this is the start of that, not the finish.

CLUB ITEMS (FUT_CLUBITEMS=1, default off). tools/fut_clubitems.py builds shelves from
the game's own tables: fcc_balls 42, fcc_stadium 78, fcc_badgecards 656,
fcc_kitcards 1482, fcc_leaguelogos 44, each with its real carddbid AND its real
cardassetid. Counts are wired into the club stat set, replacing the honest zeros
rather than appending a second row per id (the deserializer does
store[ctx][statId] = value, so two rows for one id is a coin toss).

Counts FIRST and on purpose. The consumables round proved the count gates the fetch:
the client does not ask for an item list until club/stats reports a non-zero count,
and the CLUB tab reads 0x1e balls, 0x28 kits, 0x14 stadia. Arming the counters is what
makes the client name the item route, which is the one thing static reading has never
produced for this family -- cardtype 9 has NO arm in the merge, so nothing about it is
discoverable from the card DB.

What is deliberately NOT guessed: which cardsubtypeid means ball versus stadium. The
eight values that reach cardtype 9 are {30,31,145..150} and the assignment appears in
none of the 149 dumped tables. probe_shelf() serves one item per candidate so the
screen can say which is which, rather than shipping a guess into someone's club.

PACKS (FUT_PACK_MIX=1, default on). A pack is no longer eleven footballers: roughly a
quarter of each pack is now consumables and occasionally staff, as a ratio so it
scales from a 5-card bronze to an 11-card premium. Club items are excluded until their
subtypes are verified -- a pack is the worst place to discover a wrong subtype,
because the card lands in the save and has to be cleaned out by hand.

Also fixes the art id AT THE SOURCE. fut_consumables now sets cardassetid from the
fcc_ tables, so a pack-granted consumable renders correctly too. The earlier fix only
corrected the copy served by the club route, which meant packs would have dealt cards
with the green NOT FOUND box again.

Pack tests run against a COPY of the profile, after an earlier test persisted 15 cards
into the live save and had to be undone by hand.

439 + 414 checks green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-05 11:51:49 -07:00
funman300 cef1e8d1f4 fifa17-recon: consumable artwork CONFIRMED FIXED, and the two wrong guesses recorded 
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
 2026-08-05 11:47:05 -07:00
funman300 214be11202 fifa17-recon: the green NOT FOUND box was a wrong art id, cardassetid != carddbid 
A player photographed a green tag under every consumable card. It is not a status
label at all: external/ion_fut/artAssets/.../notfound.swf is the client's placeholder
for an art asset it could not resolve, so the card was drawing 'no such artwork'.

The cause is two id columns that look interchangeable and are not. In the game's own
fcc_ tables a consumable row carries BOTH carddbid (5003001) and cardassetid (3), and
the art is keyed on the small one. fut_store._item copies resourceId into cardassetid,
which is correct for players and wrong for every other family, so the client looked up
art id 5003001, found nothing, and fell back.

Now mapped from data/tables/fcc_*.json, dumped read-only from the client's own
database, so these are the game's ids rather than a guess: training 3, contract 7,
healing 10, misc 45. The same table also gives balls 37, kits 35, stadium 36,
badges 39, league logos 40, which is what the club-item family will need.

Two earlier guesses at this badge were wrong and are recorded as such: it is not the
untradeable flag (changing it left the tag untouched, and the record showed the flag
had flipped) and not a loc-string failure.

439 + 414 checks green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-05 11:45:08 -07:00
funman300 c41b1514d3 fifa17-recon: consumables are served tradeable, so the untradeable badge clears 
A player pointed at a green tag under every consumable card. It is ours, not the
client's: the deserializer sets a flag from (untradeableCount < count), we set
untradeableCount == count, so every stack read as fully untradeable and drew the
badge. UNTRADEABLE_COUNT and UNTRADABLE_COUNT are UI state keys in .rdata.

In FIFA 17 a pack-opened consumable is normally tradeable, so this was our own data
showing through rather than a rendering fault. Now untradeableCount is 0 and the
served copy carries untradeable false. FUT_CONSUM_UNTRADEABLE=1 restores the old
behaviour.

TODO/CONFIRM: the exact badge text was not read, only its source. If the tag survives
this change it is a different label and the untradeable theory is wrong.

439 + 414 checks green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-05 11:38:47 -07:00
funman300 550313362c fifa17-recon: consumables CONFIRMED LIVE -- artwork, stacks and correct amounts 
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
 2026-08-05 11:36:47 -07:00
funman300 122b7b94d2 fifa17-recon: consumables are STACK records, not bare items 
The route was right and the body was wrong. We served bare items, the client took the
response and inserted NOTHING (the live card map held only the 11 squad players), and
the screen stayed empty with no error logged anywhere. A 200 with a well-formed body
that the consumer silently discards is the worst failure shape there is, and it is the
third time this project has hit it.

FutConsumablesSearchServerResponse resolved from the RS4 literal 0x1802222f8:
factory 0x180130a10, vtable 0x180222200, deserializer +0x08 = 0x180130d10 (6873
chars). It takes itemData(0x16b) at the root like the club list, but its ELEMENT is
not an item. It is a five-atom wrapper and exactly one of the five carries the item:

    0xbc  count             int
    0xd7  discardValue      int
    0x16a item              -> FUN_18013fe00, the item parser itself
    0x287 resourceId        int
    0x362 untradeableCount  int

Everything else goes to the value-skip handler, which is precisely why a bare item was
accepted and did nothing. It also explains the UI: FUT draws consumables as one stack
with a quantity, not as N cards, and the wrapper is that quantity.

Identical consumables are now collapsed by resourceId and counted.

439 + 414 checks green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-05 11:34:01 -07:00
funman300 ccb736fa71 fifa17-recon: the consumables item route, found live -- GET club/consumables/<category> 
The counter WAS the gate, and fixing it produced the request within seconds:

    11:23:36  GET /ut/game/fifa17/club/consumables/training
    11:23:40  GET /ut/game/fifa17/club/consumables/contracts

Neither is club?type=, and neither is the /consumables/%s template we had been
hunting in the binary. The client asks here, and it asks ONLY once
club/stats/consumables reports a non-zero count. Two rounds of item-shape work went
unrequested for want of a counter.

Worse, the path is a /club prefix, so it fell through to the generic route: the
consumables screen was answered with the 194-card PLAYER list. It asked for training
cards and got Cristiano Ronaldo.

Now routed above the generic /club, serving the shelf filtered by category. The
segment names come from the UI group table at 0x180203260; training and contracts are
CONFIRMED on the wire, the other five are from that table and matched case
insensitively, with singular "contract" accepted because the client has used both.
An unknown segment serves the whole shelf and logs loudly rather than showing an empty
screen, since a new spelling is a wire fact worth catching.

Per-category counts match the on-screen panel exactly: training 42, contracts 13,
fitness 6, healing 21, position 20, playStyle 24, managerLeague 0. That correspondence
is what makes an empty list distinguishable from a wrong mapping.

439 + 414 checks green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-05 11:26:53 -07:00
funman300 2f8a6512db fifa17-recon: answer the CONSUMABLES panel with consumable counts, not player counts 
The tab was empty because we answered the wrong question. The client asks
GET club/stats/consumables 41 times a session; we replied with the PLAYER stat set
(players 205, playersGold 189 ...), which that panel does not read. Confirmed on
screen: seven categories present and selectable, every one reading 0.

Now appends 14 consumables* rows counted from the SHELF. The shelf, not STORE.items():
the consumables we serve are a synthetic overlay never granted into the save, so
counting the store gives fourteen zeros, which on screen is byte-identical to failure
and would have made the experiment unreadable. Counts match the independently derived
expectation exactly: 126 total, 21 healing, 7 player contracts, 21 player training,
3 player fitness, 20 position, 21 GK training, 6 manager contracts, 19 playstyle.

Safe by construction: the vocabulary is an ATOM switch (FUN_18012fd40, 40 arms,
default return 0), so an unrecognised name is inert rather than fatal, and the rows
are APPENDED -- the player, nation and league rows that drive the working screens are
untouched. Zero rows unless FUT_CONSUMABLES is armed.

Default ON because answering the consumables panel with player counts is wrong by
inspection rather than a judgement call. FUT_CONSUM_STATS=0 reverts.

439 + 414 checks green.

The open question this sets up: whether a non-zero count makes the client request an
item list at all. If it does, the log names the route and /consumables/%s is settled
for free. If the numbers move and no request follows, the panel renders from counts
alone and the 126-item shelf was never needed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-05 11:19:29 -07:00
funman300 0f83d73364 fifa17-recon: the consumables panel asks 41 times a session and we answer with players 
Round 3, 10 agents. The headline is measured, not inferred: GET club/stats/consumables
is requested 41 times per session by the real client (ProtoHttp), and _club_stat_set()
answers it with the PLAYER stat set. The panel reads 14 consumables* names that we
have never sent, so it is told '205 players' when it asked how many contracts the club
owns, and it has nothing to show.

That also explains why last round's 126-item consumable shelf was never requested. It
serves type=contract|training|healing|development and an UNTYPED /club with no
team=/league=, and all 9 of the client's untyped requests this session carry team=. The
only +126 item(s) line in the whole log came from one of our own probes.

Vocabulary recovered: the 14 consumables* rows plus badgeDBid 0x2e, kitsHome 0x29,
kitsAway 0x2a, leagueLogos 0x2f, trophiesSeasonOnline 0x38.

Other measured surfaces the client asks for and we fob off: GET /settings 11x answered
with an empty config array (a 40-flag feature gate, the biggest untouched lever in the
project), leaderboards/options 5x with {}, user/accountinfo 4x with {}.
club/stats/staff is a DIFFERENT class (FutStaffBonus); the staff counts come from the
Stats2 store, which is why the staff screen worked while we answered {}.

Refuted: ENDPOINT_MAP's claim that objectives have no route. FUN_180151610 builds
<base>/objective/%d/reward and FUN_180147780 builds .../complete.

New modules only. utas_server.py is deliberately untouched: whether to wire the counts
depends on a free observation the human can make on the client that is already running,
and spending a restart before that is what this round exists to avoid.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-05 11:13:54 -07:00
funman300 456ec24360 fifa17-recon: managers and coaches CONFIRMED LIVE, and the manager template paints our fields 
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
 2026-08-05 10:22:34 -07:00
funman300 22ba361578 fifa17-recon: repair_club keeps dead cards unless asked, plus the 2026-08-05 plan 
Deleting cards from someone's club is their call, not the tool's. The nine
unrepairable blanks are now KEPT unless --delete-dead is passed. A blank card is ugly,
not harmful, and the 175 stale cards were never the deletion candidates anyway: they
are real players wearing old invented numbers and they get repaired in place.

Also records the build round's synthesis as docs/plan-2026-08-05-families.md.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-05 10:16:13 -07:00
funman300 21b2263e30 fifa17-recon: family flags -- FUT_CONSUMABLES=0 meant ON 
os.environ.get returns the STRING "0", which is truthy, so anyone typing
FUT_CONSUMABLES=0 to turn the family off would have turned it on. "", "0", "off",
"no" and "false" now all mean off; any other value is the mode string ("1", "all").

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-05 10:05:57 -07:00
funman300 0e4bc13db4 fifa17-recon: serve consumables, coaches and managers behind flags, default OFF 
Wires the three families into club_route as a synthetic OVERLAY. Nothing changes by
default: with all three flags unset every route returns byte-identical bodies, checked
against the live 194-item save (club 194, type=player 194, league=53 drill-down 67,
hub clubPlayers 194, every staff stat 0).

  FUT_CONSUMABLES=1     serve on type=contract|training|healing|development
  FUT_CONSUMABLES=all   ... and on an untyped club fetch with no team=/league=
  FUT_COACHES=1         serve on type=headcoach|gkcoach|physio|fitnesscoach|staff
  FUT_COACHES=all       ... and on type=manager, the one staff request ever observed
  FUT_MANAGERS=1        serve on type=manager|staff

WHY AN OVERLAY AND NOT A GRANT. Clearing the flag restores the real club exactly on
the next fetch, with no un-granting and no edit to a save a live client is holding
open. And Store.add_items() uses setdefault("id", ...), so items arriving with an id
already set do NOT advance nextItemId -- granting these would eventually collide two
id spaces. The four overlay bases (9.4e8 consumables, 9.5e8 coaches, 9.6e8 managers,
9.1e8 probe) are asserted disjoint from each other, from the save's 1e8 and from the
sweep's 9e8. The cost is that overlay cards cannot be quick-sold or moved.

WHY EACH FLAG IS TWO-VALUED. The tab-to-?type= binding is UNOBSERVED -- only
type=player, type=manager and type=custom have ever come from this client, and none of
the nine other arm names in FUN_18012ec50 has. So every club fetch now LOGS the arm it
was asked for while any flag is set. That is what makes an empty tab actionable: it
says whether the request reached us and under which name, instead of nothing.

THE MIRROR FILTER, and it is not optional. club_route applied its cardsubtypeid filter
only when `kind and kind not in ("player","custom")`. For type=player, for type=custom
(the by-league / by-team drill-downs) and for an untyped fetch it filtered NOTHING, so
the moment the club held a non-player item it would be served straight into the
players tab and the drill-downs -- and a manager carries nation, leagueId and teamid,
so he would have appeared as a footballer in exactly the MY CLUB rows that were only
just made non-zero. The player branch now filters cardsubtypeid in (0,1,2,3). Provable
no-op today: all 194 items in the save are cardsubtypeid 0.

Same hardening for the three counters that keyed on itemType == "player" (hub
clubPlayers, _club_stat_context, _club_stat_set) -> _is_player(), i.e. the CLIENT's own
definition from FUN_1800d8330. itemType is INERT on the wire (atom 0x173 is parsed into
a stack std::string in FUN_18013fe00 and freed; it never reaches the record), so keying
our own screens on it made their correctness depend on a field the client ignores.

FREE SECOND ORACLE: the five staff sub-type counters (0xb..0xf) are now computed from
the overlay. FUN_180094ce0's STAFF_EMPLOYED row is the +0x800 SUM over those five, so
the parent id 0xa alone could never move it. That number moves without the merge being
involved at all, which keeps "our club reports N staff" separable from "the client
resolved the card".

item_def() also learns consumables (gated): answering a consumable resourceId with
cardsubtypeid 0 makes it cardtype 0 -- no merge arm, no miss-fill, i.e. plausible
garbage -- and it carried the same hardcoded rareflag 1 as fut_store._item().

tools/test_card_families.py: 414 offline checks over the item BUILDERS. Deliberately a
separate suite -- test_fut_contract.py talks to a live server over HTTP and imports
nothing from the server's own code, which is what lets it certify a future non-Python
implementation; these must run against the working tree without restarting anything.
Each guard was mutation-checked: reverting the 219 fix, or letting coach_item accept a
miss-fill assetid, or letting consumable_item accept a dead zone, each fails the suite.

Suites after: test_fut_contract 439/0, test_match_rewards 61/0, test_card_families
414/0. utas_server was NOT restarted; this lands on disk only.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-05 10:05:32 -07:00
funman300 9b22435421 fifa17-recon: manager cards -- 417 ids, real names, and a nation/league slot that is ours alone 
managercards: 417 rows, carddbid 1000001..1001552, assetid == carddbid on all 417,
value 57..88 (120 rows at exactly 57), rare 282/135 and NOT a rating threshold.
talkrating and formationid are 0 on ALL 417 rows -- both columns are dead in FIFA 17.
MEASURED from data/tables/, rowcount == rows_emitted.

Names come out after all, and by the CLIENT's own rule rather than an inference:
FUN_1801bb060 (879 bytes, read in full) does SELECT firstname,surname,... FROM manager
WHERE managerid == (*(u32*)(rec+0x18) & 0xffffff) - 1000000. Joining data/tables/
manager.json on that rule gives 1000509 Luis Enrique 88, 1000089 Wenger 86, 1000417
Guardiola 87, 1000414 Klopp 84 -- the ratings match the men, which a shifted column
could not produce. This supersedes the note that we get ids and not names: true of
managercards, false once you join `manager`.

Fixed here: `manager` has 747 rows but 746 distinct managerids -- managerid 107 is
duplicated with an empty-name row, and a plain dict comprehension kept the wrong one,
silently giving carddbid 1000107 a blank name and teamid 1357 instead of Slutskiy and
315. 296 -> 297 usable names.

THE KEY FACT, verified at instruction level: the parser routes the JSON `nation` to a
DIFFERENT record offset for a manager. At 0x180140e0b FUN_1800d8330's result is DEC'd
twice -- cardtype 1 stores nation to rec+0x148, cardtype 2 to rec+0xde, everything
else DISCARDS it. leagueId (atom 0x18a) lands unconditionally at rec+0xe0. The manager
merge FUN_1801356c0 (452 bytes, 1,587 chars, read in full) writes only firstname,
lastname, assetid, rating, talkrating, negotiation and rare -- it never touches
rec+0xde/+0xe0. So for a manager, WE are the only source of nation and league, and
they are read: FUN_1801a8580/FUN_1801a8540 feed FUN_1800e5940 ("ManagerCardBio"),
which publishes NATIONALITY, NATIONALITY_ASSET_ID and LEAGUE_ID.

That merge has NO else-branch, so unlike a coach a wrong manager id is COMPLETELY
SILENT. resourceId must equal carddbid exactly -- the manager arm reads the key raw,
with no & 0xffffff.

Also corrected against the design round's own draft: talkrating and negotiation are
NOT unread. FUN_1800e5940 publishes them as ATTRIB_TEAM_TALKS (rec+0xe2) and
ATTRIB_CONTRACT_NEGOTIATION (rec+0xe3). They come from the DB, not from us, and since
talkrating is 0 on all 417 rows TEAM TALKS reads 0 on every manager card in the game.

Not wired into the server in this commit.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-05 10:05:05 -07:00
funman300 9feb577c1c fifa17-recon: the four coach families -- 411 real ids, and a miss that labels itself 
headcoachcards 124 rows 2000004..2000328, gkcoachcards 121 rows 9000001..9000324,
physiocards 51 rows 4000002..4000259, fitnesscoachcards 115 rows 3000019..3000328.
All MEASURED from data/tables/, dumped read-only from the running client; rowcount ==
rows_emitted == len(rows) on all four, which is what makes "this id is absent" a claim
about a complete dump rather than about a truncated one. assetid == carddbid on every
row; every id fits in 24 bits.

WHY COACHES ARE THE CHEAPEST FAMILY TO TEST. Their four arms of FUN_180141660 (2,129
bytes, 214-line decompile read to its closing `return`) are the only merges in the
game that label their own failure: on rowcount < 1 each writes firstname = lastname =
"DB Error", rec+0xb4 = 0x32, rec+0x58 = 1 and a TABLE-UNIQUE assetid -- head 2000148,
fitness 3000259, physio 4000146, gkcoach 9000258. Two independent facts make that a
one-glance oracle, both verified by exhaustive scan of all 411 rows: no row in any of
the four tables has value == 50, and no fitnesscoach row is (fieldpos 1, posbonus 7,
amount 1).

CORRECTION to docs/plan-2026-08-04-card-families.md: the miss-fill is NOT uniform.
Only head coach and GK coach write 0xf into the attribute array at rec+0x98. Physio
writes 0xf into a BYTE at rec+0xdd; fitness coach writes no 0xf at all -- rec+0xde =
0x107 and rec+0xdd = 1. So card_identity_probe's attrs column means something
different per family, and its F_NAME_KNOWN=0xdd string read sits directly on top of
physio's, fitness coach's and the manager's raw stat bytes. Use coach_probe.py.

The key is RAW: all four staff branches pass *(u32*)(rec+0x18) unmasked into
`WHERE carddbid == ?`. Players are the only family that masks with & 0xffffff, so a
version byte in the top octet breaks every staff lookup -- silently on a manager,
loudly on a coach.

WHAT WE SEND: id, resourceId, cardsubtypeid, itemType, contract, itemState, owners,
untradeable. Nothing else. rating/rareflag/assetId are overwritten by the merge;
nation/leagueId/teamid would be INVENTED, because none of the four tables has such a
column; preferredPosition (rec+0x146) and attributeList (rec+0x98..) SURVIVE the merge
and are read by the generic view-model FUN_1800d7920, so sending them would hang a
position label and six attribute numbers on a coach. Omission is safe; a scalar where
an object is expected is not.

The starter shelf is one card per (tier, rare) combination per family -- 24 cards --
with two exclusions: the four miss-fill assetids (three of which are REAL rows, so a
hit and a miss would look identical on those cards), and any row whose own stat write
is byte-identical to its family's miss-fill (head/GK attribute 0 amount 15).

tier() is the binary's own tail, not our convention: the shared exit of FUN_180141660
writes rec+0x54 = 3 if rating >= 0x4b else 2 - (rating < 0x41), for every arm
including the miss arms.

Also lands the design round's read-only probe tooling: coach_probe.py (grades a live
record HIT/MISS/WRONG-BRANCH/NO-MERGE against the on-disk rows) and coach_window.py
(builds a mixed-control window; fires nothing).

Not wired into the server in this commit.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-05 10:04:44 -07:00
funman300 340c31f34e fifa17-recon: consumables -- the whole family, and it needs no id space at all 
144 live cardtype-6 subtypes and 28 dead zones, all derived from the binary rather
than guessed, plus EA's own authored variants out of the dumped fcc_* tables.

MEASURED (decompiles read to their closing brace, lengths stated):
  FUN_1800d8330  (714 chars)   cardsubtypeid -> cardtype. The cardtype-6 space is
                               {51..136} u {201..220} u {250..273} u {300..341} = 172.
  FUN_18013f4d0  (8,354 chars) subtype -> category(rec+0xb8), sub-sel(rec+0xbc i16),
                               amount(rec+0xbf i8), single(rec+0xc0). Two callees, a
                               range clamp and an enum map; no DB handle is touched,
                               which is why a consumable has no identity to look up.
  FUN_1801bfac0  (42,813 chars) category -> FUT_CONSUMABLE_* string + a HARDCODED
                               5000xxx artwork constant. resourceId never reaches the
                               screen for a consumable.
  fcc_trainingcards 143 rows / fcc_healingcards 27 / fcc_contractcards 13, each with
  rowcount == rows_emitted == len(rows), so absences below are from a COMPLETE dump.

Two things the family will not forgive, both enforced in the builder rather than
documented and hoped for:
  * `amount` (atom 0x1b) is MANDATORY for categories 0, 4, 5, 9, 10. The parser
    initialises its temp to 0xffffffffffffffff, so omitting it stamps (byte)-1, and
    the accessors FUN_1801a8040/FUN_1801a8060 are `(int)*(char *)` -- SIGNED. The
    card reads "-1", not 0. consumable_item() raises instead.
  * A DEAD-ZONE subtype does not self-label. It falls to the bottom default of
    FUN_18013f4d0 and renders as an ordinary Squad Training (Pace) card with amount
    0. There is no "DB Error" analogue here, so every subtype we ship comes from
    data/consumables.json and the builder refuses the other 28.

Two corrections to the generated data, both from re-reading FUN_1801bfac0 case 5 and
case 0 rather than from the category table:
  * subtype 220 is named FUT_CONSUMABLE_NAME_SQUADTRAINING, not ..._PLAYERFITNESS.
    0xdc == 220 is the FIRST half of the squad-fitness test, so 220 always takes that
    branch, and there is no ..._SQUADFITNESS string in the binary at all.
  * all 28 dead zones are SQUADTRAINING, not PLAYERTRAINING: case 0 tests
    `subtype - 0x33 < 7` then `subtype - 0x3d < 7` and no dead zone satisfies either.
  Exactly 29 of 172 rows changed; nothing else moved.

INFERRED, and flagged as such in the module: the ?type= grouping. The vocabulary is
certain (FUN_18012ec50 arms healing=23, contract=24, training=25, development=6), but
the tab-to-arm binding has NEVER been observed -- only type=player, type=manager and
type=custom have ever come from this client.

Three families deliberately NOT shipped: manager_formation_mod (71-86) has zero rows
in the 143-row table AND FUN_1801bfac0 case 6 calls FUN_1801a0100 on the formations
result without the rowcount guard its twin case 7 has -- a crash candidate;
formation_mod (121-136) has artwork -1; manager_league (300-341) renders literally
"ML: %d" from a raw number and one shipped amount (2118) is in no league table.

Not wired into the server in this commit.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-05 10:04:21 -07:00
funman300 d8ef9d4c4f fifa17-recon: the rareflag trap -- a rare Player Fitness card is a SQUAD Fitness card 
fut_store._item() hardcoded "rareflag": 1 on every item it builds. That is inert
for players and for staff, and CORRUPTING for exactly one consumable subtype.

MEASURED, in the binary: FUN_1801bfac0 case 5 (consumable category 5, fitness)
takes the squad-fitness branch when

    (cardsubtypeid == 0xdc) || FUN_1801a88c0(rec)

and FUN_1801a88c0 is exactly `*(int *)(rec + 0x58) == 1`. rec+0x58 is the rareflag
atom 0x271 (FUN_18013fe00 case 0x271 -> uStack_130; the frame arithmetic is
independently pinned by local_138 -> rec+0x50 and local_13c -> rec+0x4c, the two
offsets card_identity_probe has been reading live for days). FUN_180141660 does not
overwrite rec+0x58 for cardtype 6 -- cases 6/7/8/9 fall to the shared tail, which
writes only rec+0x54 -- so a rareflag we send survives all the way to the render.

Result: subtype 219 with rareflag 1 draws FUT_CONSUMABLE_NAME_SQUADTRAINING with
artwork 5000011 instead of Player Fitness with 5000010, and forces the
single-target count at param_5+0x1bc to 0. Silent. It would have corrupted the
first fitness card we ever served.

The guard is `0 if cardsubtypeid == 219 else rareflag`, added with two new KEYWORD
params. Every existing call site (fut_store.py:74/:357, utas_server.py:1404/:2136)
passes 8 positional args, so both take their defaults and the player dict is
byte-identical -- key order included, asserted in tools/test_card_families.py.

Scope correction to the round's own notes: rec+0x58 is read TWICE in that
42,813-char render function, not once. FUN_1801a88c0 is the category-5 read, but
line 108 reads it directly into param_5+0x1f0 (the rare/backing art) for EVERY
cardtype, before the `if (param_4 == 6)`. So the guard also stops a 219 being drawn
as rare -- intended, since rare IS the squad-fitness selector.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-05 10:03:54 -07:00
funman300 9876a6c870 fifa17-recon: repair_club -- fix stale cards in place, remove only the dead ones 
Audit of the live club: 194 items, 10 already correct, 175 stale, 9 dead.

STALE means a real FIFA 17 player carrying the old invented fields: attributes
computed from the rating, and in some cases a wrong club or nation (Kroos was stored
at Bayern and is at Real Madrid; Alaba was nation 40 and is Austria 4). Those are
REPAIRED in place from data/pool.json rather than deleted. Deleting them would throw
away 90 percent of the club for no reason: name, face and badge are already right and
only the numbers are wrong, and the item id does not change so squad slots survive.

DEAD means the playerid is not in the roster at all, so the client misses and stamps
its generic blank. Nothing to repair, so those are removed. A dead card referenced by
a saved squad is kept rather than breaking the slot.

The nation and team mappings were spot-checked against the game's own nations and
teams tables before trusting them across 175 cards: 4 Austria, 21 Germany, 38
Portugal, 60 Uruguay, 243 Real Madrid, 5 Chelsea.

MUST RUN WITH utas_server STOPPED. The server keeps the profile in memory and
rewrites it on its own schedule, so an edit underneath a running server is clobbered
by the next save. That is why the nine dead cards removed on 2026-08-04 were back a
few hours later: the removal was correct and the running server undid it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-05 10:03:10 -07:00
funman300 7b9a4fde15 fifa17-recon: /club honours ?team= and ?league= -- drill-downs showed the whole club 
Reported live: a Cristiano Ronaldo card appearing under Chelsea and under Arsenal.

The data was right and so was the client. teamid 243 really is Real Madrid in the
game's own teams table, and all eight Ronaldo cards in the live CardsDb map read
teamid 243. The fault was ours: club_route parsed only ?type= and ignored ?team= and
?league=, so clicking a club or a league in the club panel was answered with the
ENTIRE 194-item club. Every drill-down therefore contained every player.

Note which half was already correct: the club/stats COUNTS were fixed yesterday and
were right (England 11, Premier League 17). It was only the item list behind them that
was unfiltered, which is why this looked like a data bug and was not one.

Now: team=5 gives 26 items, team=243 gives 20, league=13 gives 22, and the unfiltered
club list is untouched at 194. 439 checks green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-05 09:44:56 -07:00
funman300 d17cf684ea fifa17-recon: keep raw memory captures out of git 
data/memdump reached 2.3GB of raw /proc/PID/mem captures. Only its index.json is
worth tracking; the captures regenerate from tools/db_dump.py against a running game.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-05 09:09:25 -07:00
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 49733f79d1 fifa17-recon: card-family enumeration round -- managers cracked, consumables need no ids 
11-agent round, every investigation adversarially reviewed. The headline is that this
was never five id hunts: the client's database is resident in ordinary heap as a
self-describing catalog of bit-packed fixed-stride row arrays, walkable READ-ONLY, so
the id sets fall out at zero cost in human club visits.

MEASURED:
  managercards carddbid 1000001..1001455, assetid == carddbid; two agents using two
    different block locators agreed 417/417 (docs/managercards_ids.txt). This is why
    the earlier sweeps of 1..5000 and 6000..8000 were silent.
  staff bands: headcoach 2000004+, fitnesscoach 3000019+, physio 4000002+,
    gkcoach 9000001+, corroborated by the four miss-fallback assetids hard-coded in
    FUN_180141660 each landing inside its own table's decoded range.
  all four coach branches write a LOUD miss-fill: firstname/lastname "DB Error",
    rating 0x32, rare 1, attrs[0] 0xf, plus a table-unique assetid. Managers write
    none, so a wrong manager id is silent and a wrong coach id labels itself.
  consumables have NO table and NO id space: cardtype 6 has no arm in the merge,
    FUN_18013f4d0's only callees are a range clamp and an enum map, and every string
    is a hardcoded FUT_CONSUMABLE_* literal. A contract is three JSON keys.
  the ?type= taxonomy is 29 explicit arms plus a default: badge 11, kit 12, stadium
    13, ball 14, equippables 15, leaguelogos 16, misc 26. club/stats kits and
    badgeDBid are PLAIN COUNTS, not ids.
  fancards is a boolean column of the fixtures table; newcards is FUT atom 0x1d7.
    NEITHER is a card family, so two of the five hunts never existed.

REFUTED, and worth keeping: the live table-directory walk was off by one entry
(descriptor for table T is at entry-0x20, not entry+0x08), which had mislabelled
managercards as factory_teams and shifted every column count. managercards names are
32-bit string-pool offsets and the pool was never located -- we get ids, not names,
and we do not need names because the client supplies them.

TRAPS RECORDED: rareflag=1 silently converts a Player Fitness card (219) into Squad
Fitness, and fut_store._item() hardcodes rareflag 1 on every item.

Four proposed club-item sweep windows were killed by review as invariant by
construction: with no merge arm there is no miss-fill, so every id yields a
byte-identical record and the probe cannot discriminate. That is a wasted human action
correctly caught before it cost one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 22:40:24 -07:00
funman300 c76cf706ef fifa17-recon: CARD_SYSTEM -- record the solved identity mechanism and the oracle 
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
 2026-08-04 22:00:18 -07:00
funman300 b996c0673d fifa17-recon: sweep every staff table at once (t*@) 
The manager sweep (subtype 4, ids 1-5000) came back with 5000 records at
cardtype 2 -- confirming FUN_1800d8330(4)=2 live -- and NOTHING written: no name,
no nation, no teamid, and no miss-fill either. Our sentinel rating 7, position 25
and attributes all survived. So either manager ids are not in 1-5000 or that
branch keys off something the player branch does not.

Guessing the id space costs a club visit per guess, so 't*@lo-hi' now fans all
five non-player tables across one range in a single response: 4 managercards,
5 headcoachcards, 6 gkcoachcards, 7 physiocards, 8 fitnesscoachcards. One staff
tab load tests 1000 ids against all five.

The full table set, from the DLL's own strings: players, managercards,
headcoachcards, fitnesscoachcards, gkcoachcards, physiocards, fancards, newcards
-- plus a consumables family (contract, fitness, healing, position, training and
playstyle modifiers, formation and league mods) and club items (badges, balls,
kits) which are almost certainly NOT DB-resolved the way cards are.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 21:25:43 -07:00
funman300 1b1c178c09 fifa17-recon: /club honours ?type= -- the STAFF tab was showing footballers 
Observed live: the staff tab issues GET /club?year=2017&type=manager&count=200.
club_route ignored the parameter entirely and answered every type with the full
player list, so FUT displayed players as coaching staff.

The filter is deliberately narrow. 'player' and 'manager' are the only values the
client has ever been seen to send; 'custom' (the by-league and by-team drill-downs)
and a missing type keep exactly the behaviour that is already proven on screen,
because those drill-down counts were only just fixed and must not be disturbed. An
unrecognised type is filtered rather than answered with everything, since
answering an unknown question with the whole player list is the bug being fixed.

We own no staff cards, so type=manager is [] today -- an empty item list, the same
shape the itemData parser already accepts everywhere else.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 21:20:06 -07:00
funman300 c28cad281b fifa17-recon: sweep can target the non-player card tables 
The merge FUN_180141660 dispatches on record+0x4c, which FUN_1800d8330 derives
from cardsubtypeid alone, and each branch queries a different table by
carddbid = record+0x18 -- the same field players use for playerid:

    0..3 -> 1  players (live-proven)   5 -> 3  headcoachcards
    4    -> 2  manager                 8 -> 4  fitnesscoachcards
    6    -> 10 gkcoachcards            7 -> 5  physiocards
    9..b -> 7  unidentified            absent -> 0x156 -> 0, no merge at all

So a 't<subtype>@' prefix on the sweep window probes any of them the same way
players were probed: 't5@auto:1-20000:5000'.

Only cardsubtypeid changes. itemType stays 'player' because the merge dispatches
on the subtype alone and the wire shape of a real staff item has NEVER been
observed -- across every logged session the client has only ever asked for
type=player and type=custom. Inventing a shape for an unobserved request is the
change class behind every freeze this project has had.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 21:18:01 -07:00
funman300 0a1c9dc2ce fifa17-recon: strip_dead_cards -- remove club cards whose playerid is not real 
Leftovers from the invented-id pool that data/roster.json replaced. The client
misses on them and stamps its generic card (rating 50, teamid 1933, nation 14,
position 2, attributes 1, blank name), which is what a blank card on screen IS.

Removed 9 from the live club (5 distinct bad ids, 169193 four times over). 188 of
194 cards were already resolving; these were the whole remainder.

Refuses to remove anything a saved squad references, backs up first, and is a dry
run unless --fire. It touches only the club pile: a card present in both club and
purchased is the known fatal desync, and deleting from one pile cannot create that.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 21:15:55 -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 b0bbc2a07f fifa17-recon: sweep auto-advance + the three-state oracle, live-proven 
The oracle is three-valued, and all three fingerprints are now confirmed live
against a running client rather than read out of Ghidra:

  NAMED        our sentinel rating 7 survives and a real name appears. The id is
               real, and teamid/nation/leagueId come back FILLED by the game
               because we send them as zero.
  placeholder  rating 7 survives but the name is 'Jamal Blackman', team 0. The
               players-table row exists and is an empty slot. This is the trap:
               169193 does this and it was in VERIFIED_ASSET_IDS.
  MISS         rating 0x32, teamid 0x78d, nation 0xe, position 2, name ' '. That
               is the binary's miss-fill, byte for byte, and it is exactly the
               blank card photographed in a pack today.

Scale: 5000 candidates per response ingests cleanly; 20000 was served and then
silently not ingested (the map did not change at all), so the ceiling is between
them and auto chunks default to 5000.

Auto-advance: the client PAGES the club, so one visit yields several fetches.
'auto:lo-hi:step' hands out the next chunk per fetch. Item ids derive from the
candidate's offset in the WHOLE range, not its index in the chunk, so chunks never
collide and results accumulate across fetches for a single probe at the end.

sweep_collect.py accumulates into data/players.json and rejects the placeholder
name as a matter of course. Yield in 20000-24999 was 19 real ids per 5000, which
is why auto-advance matters: the real roster clusters in 150000-240000.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 20:44:02 -07:00
funman300 87e5cd2e53 fifa17-recon: FUT_ID_SWEEP -- use the running game as the player-DB oracle 
dbdata.dll is an anti-tamper decoy (getTableData returns a self-integrity blob),
so the players table only exists inside the running client. But we do not need to
unpack it: the client merges its own DB into every item we serve, keyed on
resourceId & 0xffffff, and leaves the result in a map we can already read.

So serve a RANGE of candidate playerids as a synthetic club, then read the map
back with card_identity_probe.py. One club fetch classifies the whole window.

Sends teamid/nation/leagueId as ZERO so the client fills the REAL values (the
merge only fills zeros -- confirmed live: one playerid appears twice with two
different nations, both ours). Sentinel rating 7, deliberately not 50, so the
miss-fill (rating 0x32) can never be mistaken for a surviving sentinel.

The window comes from a control FILE read per request, not just the env: a full
sweep is many windows and restarting mid-session is what produced 'error
connecting to FIFA 17 Ultimate Team' once already. Nothing is written to the save,
so clearing the file restores the real club on the next fetch.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 20:35:51 -07:00
funman300 132a013b39 fifa17-recon: card identity is a DATA problem -- live probe proves the record model 
Adds tools/card_identity_probe.py, a read-only /proc/PID/mem walk of the CardsDb
card map that reports the identity the CLIENT resolved for every card it holds.

Why it matters: identity never comes from us. The item-parser tail registers every
parsed item into the map, and immediately before that FUN_180141660 -> FUN_180135890
queries the client's own local players table by resourceId & 0xffffff. On a hit it
fills name/face and leaves our rating/position/attributes alone; on a miss it writes
a fixed generic card (rating 0x32, teamid 0x78d, nation 0xe, position 2, attrs 1,
name ' '). That miss fingerprint is exactly the blank card photographed in a pack
today, so the chain is confirmed by live evidence and not only in Ghidra.

First live run, 11 nodes, 0 failed reads, size counter agrees with the walk:
Ronaldo/Messi/Suarez/Kroos/Hazard all resolve with real names, so every record
offset derived statically (+0x18 resourceId, +0xb4 rating, +0x94 teamid, +0x148
nation, +0x146 position, names inline at +0xb8/+0xc8/+0xdd) is correct live.

This makes card identity a pure DATA problem: serve real playerids. The probe is
the bulk oracle for finding them -- N candidate ids served, one read classifies all N.

Also flips FUT_STORE_DISPLAYGROUP to default on; it shipped off pending proof that
the key does not switch FIFA17.exe to another tile render path, and it was then run
live and the store tiles showed their real names.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 20:29:27 -07:00
funman300 a3fd9e870f 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) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 15:38:41 -07:00
funman300 7ad7aa0afa fifa17-recon: club stats -- per-NATION buckets, and the sub-type sums 
LIVE 2026-08-04: the ENGLAND tile read 0 while drilling into it showed Premier League
17. Same bug as before, one level up: the LEAGUE buckets were keyed and the NATION
buckets were not.

The eight-row MY CLUB panel is FUN_180094ce0 (not FUN_180043b90, which is a different
provider using a different string family), and it computes:

  PLAYERS_EMPLOYED = +0x7f8(nationId, 4) + (nationId, 3) + (nationId, 2)
  STAFF_EMPLOYED   = +0x800 over 0xb, 0xc, 0xd, 0xe, 0xf
  TROPHIES_WON     = +0x800 over 0x33 .. 0x38
  STADIA_OWNED     = +0x800(0x14)      BALLS_EARNED = +0x800(0x1e)

Two consequences:

1. The no-id modes (year / consumables / club / newcards), which is what the client
   fires on entering MY CLUB, now carry PER-NATION buckets keyed by nation id. The
   three screens are consistent at last:
     no id        -> nation buckets   (the tab strip and the eight-row panel)
     country/<id> -> league buckets   (the leagues in that nation)
     league/<id>  -> team buckets     (the teams in that league)
2. STAFF_EMPLOYED and TROPHIES_WON are SUMS OF SUB-TYPES. Sending staff(0xa) or
   trophies(0x32) alone can never move those rows, whatever their value. The eleven
   sub-type rows are now emitted: staffManager/HeadCoach/GKCoach/Physio/FitnessCoach
   and trophiesOffline/Online/FeaturedOffline/FeaturedOnline/SeasonOffline. All zero
   today because the club owns no staff and has won nothing, but the mapping is what
   matters when it does.

All eleven new type strings verified against docs/fut_atoms.tsv, 0 mismatches.

Live: /club/stats/year now returns 117 rows across 16 nation buckets, England
(nation 14) summing to 11 players. 439 + 61 checks green, zero tracebacks.

This is the third correction to this one endpoint today. The pattern in all three is
identical and worth stating once more: the parser accepts anything, and only the
CONSUMER tells you which bucket and which type ids it reads. Every time I reasoned
about the body instead of reading the reader, I shipped a wrong one.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 15:35:17 -07:00
funman300 4c5cc3ab4b fifa17-recon: THE MY CLUB COUNTER -- it was clubPlayers in GET /hub all along 
The tile's big number is `clubPlayers` (atom 0x90) in the body of GET ut/%s/hub, a
route we have answered with {} for the life of the project.

The chain, re-derived independently by two agents (one via Ghidra, one via raw PE plus
capstone with no decompiler) and checked by two reviewers:

  clubPlayers(0x90) --INT getter 0x1801c79d0--> clamp FUN_1800d7b30 (<=0 becomes 0)
    -> R+0x3c, where R = FUT data-manager slot +0x1f8 (FUN_18011a810 is literally
       `lea rax,[rcx+0x1fd70]; ret`)
    -> read by FUN_1800b0250, published as TEXT0 of TILE_ID 0x210
    -> captions FUT_GH_TOTAL_PLAYERS_0/_1 at 0x18020a0f8 / 0x18020a110
  auctionCount(0x33) -> R+0x38 -> TEXT0 of TILE_ID 0x1b0, the TRANSFERS tile

FUN_180139610 (the hub body parser, 14855 chars, censused in full: 18 atoms, none
missed) is the ONLY writer of +0x3c anywhere in the image, one write, guarded by
`if (iVar6 != 0x90)`. This is not a candidate, it is the field.

I SPENT A DAY ON THE WRONG SURFACE AND WROTE THE WRONG CONCLUSION. REBUILD_RESEARCH
S19 declared the counter "not server-fixable" with a mechanism that was internally
correct and completely beside the point: the tile never read the club-stat store.
Two things reinforced the error and both are now fixed in the docs:

  * ENDPOINT_MAP said this response "uses C++ reflection / vtable dispatch, NOT an
    inline atom ladder -- no static field ladder to read" and marked it a GAP. False.
    There is an inline ladder, one indirection away.
  * The eight-row MY CLUB panel was assumed to be FUN_180043b90 case 1, which
    publishes six keys, and I treated the six-versus-eight mismatch as a puzzle rather
    than as evidence. It is a DIFFERENT provider, FUN_180094ce0, using a different
    string family (FUT_MYCLUB_*), reading neither the mode tag nor any type id we were
    sending. Two providers; we were reading the wrong one.

That is the third negative claim of this shape to fail today, after "this deserializer
has no skip handler" and "the factory does not wipe the stat map".

auctionCount is included as a FREE CONTROL: different field, different tile, so if MY
CLUB moves and TRANSFERS does not, delivery is fine and something is specific to +0x3c.

Default ON. Freeze risk is low by construction rather than by belief: a flat object of
two integers, both read with the INT getter, so there is no array, no nested object and
no type-desync surface. FUT_HUBDATA=0 restores {}.

Contract guard added, and verified to bite rather than merely pass:
  default        439 checks, 0 failed
  FUT_HUBDATA=0  435 checks, 3 FAILED  (clubPlayers missing / not a number)
A regression here would otherwise be silent: still 200, still valid JSON, tile quietly
back to 0.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 15:29:59 -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
funman300 a7ac5a09fd fifa17-recon: club stats LIVE-PROVEN, default ON; S19's verdict was over-scoped 
MY CLUB -> ENGLAND -> Premier League now reads 17. First non-zero number ever rendered
on that screen. Nothing froze, no other screen changed, 392 + 61 checks green with the
flag defaulted on and no env override.

S19 concluded "the MY CLUB counter is not server-fixable". That was too broadly scoped.
The nation and league drill-downs ARE server-fixable and are now fixed. S20 records the
corrected scope.

What made it work, from FUN_180043b90 case 3:

  uVar7  = (**(param_2 + 0x18))(param_2, row, "LEAGUE_ID")   THE UI ROW'S OWN ID
  bronze/silver/gold = (+0x7f8)(store, uVar7, 2 / 3 / 4)
  publish("PLAYERS_EMPLOYED", gold + silver + bronze)         COMPUTED, never read
  rare/kits/badges   = (+0x7f8)(store, uVar7, 5 / 0x28 / 0x2d)

Still open and now correctly scoped: the hub tile's "0 TOTAL PLAYERS" and the MY CLUB
summary rows read the GLOBAL bucket via +0x800 in cases 1 and 5. We serve those rows.
The unchanged question is what SELECTS those cases, since the mode tag is copied from
the completed request and the client requests year, consumables, staff, country/<id>
and league/<id> but never club.

The method note, which is the durable part: two rounds of reasoning about this endpoint
produced two wrong bodies; twenty lines of the consumer produced the right one. Reading
the PARSER tells you what is accepted. Only reading the CONSUMER tells you what is used.
That question was answerable from the start and went unasked until live screenshots
forced it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 14:50:06 -07:00
funman300 f65c197942 fifa17-recon: club stats -- key the buckets the way the READER looks them up 
Second correction in an hour, and this one comes from reading the provider instead of
reasoning about it. The per-context getter is (+0x7f8)(store, contextValue, typeId),
and contextValue comes from THE UI ROW, not from the URL:

  case 3:  uVar7  = (**(param_2 + 0x18))(param_2, row, "LEAGUE_ID")
           bronze = (+0x7f8)(store, uVar7, 2)
           silver = (+0x7f8)(store, uVar7, 3)
           gold   = (+0x7f8)(store, uVar7, 4)
           publish "PLAYERS_EMPLOYED", gold + silver + bronze
           rare/kits/badges = (+0x7f8)(store, uVar7, 5 / 0x28 / 0x2d)
  case 4:  keyed by "TEAM_ID"; reads 1 (players), 0x28 (kits), 0x2e (badgeDBid)

Three things my previous commit got wrong:

1. It keyed every row to the id in the URL. The reader iterates the SCREEN'S ROWS and
   looks up each row's own id, so one response must carry a bucket per row. Keying to
   the URL id fills exactly one bucket the screen never asks for, which is why the
   ENGLAND tab still showed zeros after the "fix".
2. PLAYERS_EMPLOYED is COMPUTED as gold + silver + bronze in the per-context cases and
   is never read from the store, so sending `players` (type id 1) does nothing there.
   The tier counts are mandatory.
3. The screens NEST: country/<id> lists the LEAGUES in that nation (case 3, LEAGUE_ID)
   and league/<id> lists the TEAMS (case 4, TEAM_ID). That matches the live navigation
   exactly: selecting ENGLAND produced Premier League / Championship / League One /
   League Two.

Because every response wipes the whole map, each response only needs its own screen's
buckets, which also avoids a real collision: the storage key is contextValue alone, so
nation 14 and league 14 would otherwise share a bucket.

Live output now:

  country/14 -> 41 rows, 5 league buckets
                league 13 gold=17 -> PLAYERS_EMPLOYED=17   (Premier League)
                league 19 gold=26, league 53 gold=55, ...
  league/13  -> 6 team buckets {5:20, 21:15, 22:11, 240:21, 241:30, 243:17}

Recorded as a method note: two rounds of reasoning about this endpoint produced two
wrong bodies, and reading twenty lines of the provider produced the right one. The
question "what does the reader look up" is answerable and was not asked.

392 + 61 checks green, zero tracebacks. Still behind FUT_CLUBSTATS, default off.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 14:45:40 -07:00
funman300 9ee21afb56 fifa17-recon: club stats -- populate the PER-CONTEXT buckets, not just the global one 
LIVE 2026-08-04, and this corrects the body I shipped an hour ago. Selecting the
ENGLAND tab on the MY CLUB screen issues exactly one request:

  14:30:32  GET /ut/game/fifa17/club/stats/country/14      (14 = England)

and NO item-list request. So that tab is driven entirely by per-nation stats, and it
showed nothing while the club holds 8 England players.

THE GUARD WAS THE BUG. In deser 0x180130150, contextId == 1 or 5 <= contextId <= 9
FORCES contextValue to 0, which is the global bucket that the +0x800 getter reads. The
per-nation view reads the +0x7f8 getter keyed by the NATION ID instead. Every row I
sent carried contextId 1, so no matter what contextValue said, everything landed in
the global bucket and the per-context tabs could never see it. I had the guard written
down in my own comment and still sent a body that tripped it on every row.

Now, for country/<id>, league/<id> and team/<id>, the response carries the global rows
AND per-context rows keyed by that id, computed from the club's real nation/leagueId/
teamid fields:

  country/14 -> players 8, playersGold 8, rarePlayers 8, silver/bronze/kits/badges 0

Both sets ride in the SAME response because every response wipes the whole map first,
so anything left out is erased rather than merged.

contextId 3 is used purely because it is OUTSIDE the guard and therefore preserves
contextValue. TODO/CONFIRM what contextId means semantically; nothing read so far
gives it a meaning beyond that guard.

Also verified rather than assumed this round: all 11 type strings we emit resolve
correctly against docs/fut_atoms.tsv (players 0x238, rarePlayers 0x272, stadia 0x2d7,
balls 0x4f, kits 0x17c, badges 0x4b, trophies 0x340 ...), 0 mismatches. So the strings
were never the failure.

Does NOT claim to fix the MY CLUB hub counter, which remains the open question in S19.
This fixes the nation/league tabs, which is a different and now-understood symptom.

392 checks green. Still behind FUT_CLUBSTATS, default off.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 14:33:01 -07:00
funman300 d2bbb4d378 fifa17-recon: S19 -- the MY CLUB counter is NOT server-fixable, with the mechanism 
Two experiments, both negative, and the negative has a mechanism behind it rather than
being another failed guess.

  FUT_CLUB_PAGE   served 114 items to /club?...count=11   tile still 0 TOTAL PLAYERS
  FUT_CLUBSTATS   full stat set, players=114, all modes   panel still Players 0

The bodies went out: four "CLUBSTATS: 11 stat rows (players=114)" responses in the log,
panel re-entered afterwards.

  FUN_18012fbe0   store+0x78 = request+0xc4      the mode tag is copied from the
                                                 REQUEST that just completed
  FUN_180043b90   switch (store+0x78)
    case 1  +0x800(1)->PLAYERS_EMPLOYED, (0x1e)->BALLS_EARNED, (0x28)->KITS_AVAILABLE,
            (0x14)->STADIA_OWNED, (10)->STAFF_EMPLOYED, (0x32)->TROPHIES_WON
    case 6  CARDS_NO_TRAINING_*, CARDS_NO_CONTRACT_*, CARDS_NO_FITNESS_*

The MY CLUB summary is case 1, which needs mode 1 (club). The client requests staff,
year and consumables and NEVER club, so the tag settles at 6 and case 1 is never
selected. Our values are stored correctly (contextId 1 forces contextValue 0, the
global bucket the +0x800 getter reads) and case 1 reads exactly the six ids we set.
Nothing ever asks for them.

THE MODE IS CHOSEN CLIENT-SIDE FROM THE REQUEST URL. No response body can change it,
so there is no body that fixes this and generating more of them is wasted work.

Two independent corroborations rather than one story that merely fits:
- case 6 reads 0x3d CONTRACTS, 0x3e TRAINING, 0x40 FITNESS, exactly the three ids
  FUN_18012fd40 cannot produce from any type string. The consumables view is
  unsettable from this endpoint by construction.
- FUT_CLUB_PAGE eliminated the only other candidate: the tile is not a count of the
  list we return.

Both flags stay implemented and default OFF. FUT_CLUBSTATS is correct against the
verified schema and would populate the moment a club-mode request occurred; deleting it
would throw away the schema work for no gain.

Recorded against myself: I argued from the matching labels (tile "TOTAL PLAYERS", panel
"Players", both zero while we served {}) that the two read the same store and one body
would fix both. The store IS shared. The SELECTION is not, and that is what decides it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 14:25:56 -07:00
funman300 1e2b073e04 fifa17-recon: route the draft entry purchase, and resolve the envelope ambiguity 
LIVE 2026-08-04: the draft-state array fix WORKED. The screen rendered instead of
hanging and the client advanced to the entry-fee screen, then crashed on the next
call, which we had never implemented:

  GET  /squad/mode/draft/state?mode=ONLINE  -> our array body    screen RENDERED
  GET  /user/credits                        -> 7200
  GET  /store/purchasegroup/all             -> the entry-fee screen
  POST /purchase/mode/0/draft   {"currency":"COINS","usePreOrder":0}
                                            -> {}  UNMAPPED, then the crash

Advancing the failure to the next unimplemented call is what a correct fix looks like.

ENVELOPE AMBIGUITY RESOLVED, and ENDPOINT_MAP's note about it is wrong. Two structures
reference RS4:FutPurchaseDraftModeServerResponse:

  0x18014c260  vtable 0x180224ef8, factory 0x18014c090.  3188 chars, OBJECT root
               (prologue tests != 10 = END_OBJECT), 1 skip handler, exactly the seven
               scalar ints. THIS IS THE RESPONSE PARSER.
  0x180150310  vtable 0x1802262f0, factory 0x180150260.  1836 chars, ARRAY root
               (loops until 0xd), ZERO skip handlers -- and NOT a response root at
               all. It parses ENTRANCE CRITERIA: each element's name is strcmp'd
               against the literals "COINS", "POINTS", "DRAFT_TOKEN" and stored at
               +0x28/+0x2c/+0x30. It shares the class-name string because it is the
               fee sub-object, not an "alternate/summary envelope" as documented.

THE CRASH ITSELF DISCRIMINATED, which is worth keeping as a technique. An object-root
parser handed {} parses benignly and leaves defaults; an array-root parser handed {}
desyncs and HANGS, which is exactly what draft/state did before the fix. We observed a
CRASH, not a hang, so the object-root parser is what ran and the failure is downstream
of an empty-but-valid parse. Consistent with 0x18014c260, inconsistent with the other.

Coins are NOT deducted. The client posts the price in the URL and it sent 0, because we
omit entranceCriteria from draft/state so there is no fee to charge. Charging a guessed
amount would be inventing an economy rule.

ALSO FIXED, before it reached the game: the route table hands handlers the compiled
PATTERN, not a match object (the dispatcher calls fn(rx, self)), so calling .group() on
the first argument raised AttributeError and killed the connection outright. That is
strictly worse than the {} it was replacing. Caught by verifying the response actually
changed after the restart rather than assuming the route worked.

Default ON: the behaviour it replaces is a confirmed crash, so no working state is at
risk. FUT_DRAFT_PURCHASE=0 reverts.

392 + 61 checks green, zero tracebacks on a clean boot.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 14:17:45 -07:00
funman300 b434a3efdc fifa17-recon: FUT_CLUBSTATS -- serve the club-stat set (CLUB STATS panel, maybe the tile) 
Live 2026-08-04: the CLUB STATS panel shows eight zeros (Rare Players, Players, Staff
Employed, Stadia Owned, Trophies Won, Kits, Badges, Balls Earned) while the client
fetches /club/stats/{staff,year,consumables} and we answer {} to all three. Those
zeros are ours. Every row name maps to a type string in the recovered map.

Wire schema, fully verified from deser 0x180130150 (7,870 chars, read end to end):
  {"stat":[{contextId:int, contextValue:int, type:string, typeValue:int}]}
Unknown keys route to FUN_180135ff0 at BOTH levels, so extras are inert.

FIVE THINGS THAT DECIDE WHETHER IT WORKS:

1. EVERY RESPONSE WIPES THE WHOLE MAP FIRST. Nothing accumulates, so a good body on
   one mode followed by a thin one on another ERASES the first and request ordering
   decides what survives. Handled by serving the SAME COMPLETE SET on every Stats2
   mode: whichever lands last leaves the map correct. (One investigator reported this
   factory does not wipe; a reviewer re-read it and refuted that. The wipe is real,
   and this is the second negative claim from that batch to fail.)
2. /club/stats/staff IS A DIFFERENT CLASS: FutStaffBonus, {"bonus":[{type,value}]},
   not Stats2. Its type strings are undecoded so it keeps {}, which is safe and also
   means it does not disturb the Stats2 map.
3. ELEMENT-LOCAL VARIABLES ARE NOT RESET BETWEEN ELEMENTS -- the clears sit before
   the array loop, not inside it -- so omitting a key in element N inherits element
   N-1's value. All four keys are emitted in every element.
4. The storage key is contextValue ALONE; contextId is only a guard (1, or 5..9,
   forces contextValue to 0, the global bucket the +0x800 getter reads). contextId 1
   throughout.
5. 0x3d CONTRACTS, 0x3e TRAINING and 0x40 FITNESS are READ by the panel but cannot
   be SET from here. No type string produces them.

THIS IS ALSO NOW THE HUB-TILE CANDIDATE. The investigation concluded the MY CLUB tile
does not read this store, but flagged that negative as BOUNDED: the interface comes
through a QueryInterface adapter, so the vtable is assembled at runtime and cannot be
read statically. Live evidence points the other way. The tile reads "0 TOTAL PLAYERS"
and the panel reads "Players 0" -- same quantity, both zero, both while we answer {}.
And FUT_CLUB_PAGE ruled out the alternative: 114 items served to /club, tile still 0,
so it is not a count of the list. Strong inference, not proof; this flag is the test.

The test is unusually clean: the club holds 114 items and all of them are players, so
every other row is an honest zero. If it works, exactly two numbers move (Players and
Rare Players, 0 -> 114) and nothing else changes.

Gold/silver/bronze thresholds are FIFA's rating convention (75+/65-74/under), not
something read out of the binary, and the code says so.

Default OFF. 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 14:12:48 -07:00
funman300 285d4f6cb7 fifa17-recon: the blockers plan from the multi-agent pass 
Five parallel Ghidra investigations, one adversarial reviewer each, one synthesis.
Kept in the repo because the reviewer corrections are load-bearing: they refuted claims
in four of the five reports, two of which would have shipped wrong behaviour (a
speculative /season body justified by our own curl traffic in the log, and a store
field block that was a freeze rather than a regression).

Carries the next live session (one launch, three flags, four menu actions, one
read-only memory probe), the implementation queue, what is genuinely blocked and why,
and a what-could-make-this-plan-wrong section that names the store change as the
concrete regression risk.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 14:04:00 -07:00
funman300 1e9cfb6da9 fifa17-recon: ENDPOINT_MAP -- remove two documented hang recipes, fix five entries 
This file has been handing out bodies that freeze the client, under the heading
"MINIMAL known-good".

1. FutGetDraftCurrentState. The root container is a JSON ARRAY. The documented body was
   object-root, used the spelling DRAFTSQUAD_ON which is NOT an accepted squadState
   value, and embedded a full squad object. Anyone serving it would have reproduced the
   exact hang the entry existed to prevent, which is what happened live on 2026-08-03
   when our generic /squad route answered this endpoint with a squad object.
   Path corrected too: it is ut/%s/squad/mode + /draft/state, not ut/%s/draft/state.
   The `squad/mode` segment was missing, which is why the URL is invisible to the
   request-template table. Established by live capture, not statically: FUN_180146ac0
   appends the suffix to a caller-supplied buffer and has no resolvable callers.

2. FutGetDraftAward (0x1801510c0) has the same array-root prologue, and its documented
   object-root body would hang identically. Corrected, and marked TODO/CONFIRM on the
   member list, which was not re-verified this pass.

   Both of these survived because a census claimed only three array-root readers
   existed in the DLL. It missed one. The census run to check it was wrong in the other
   direction. ~23 of 86 top-level readers are still unclassified, so the file now says:
   do not serve any endpoint here until its root container is classified by reading the
   actual prologue, not by regex.

3. roundsInfo element: `score` and `penaltyScore` offsets were swapped (+0x10 / +0x18).

4. FutSeasonList: deserializer is 0x1801683f0, not 0x180167740 (that is the ELEMENT
   parser), and the root is an OBJECT with one key `seasons`(0x2ad), not an array.
   Someone documented the element parser's key set at the document level, and
   utas_server.py served that shape for months on the strength of this row. Three of
   the listed element keys are inner members of elgReq and inert at element level.
   Added: element ordering (type before divisionId), stride 0x318, the (0xb-divisionId)
   short, and the three array-loop members that must stay omitted.

5. Recorded on the season entry that the client has NEVER requested /season across 486
   real requests, so no body there is observable yet.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 14:03:33 -07:00
funman300 9cf21202dc fifa17-recon: delete two loaded guns, fix the season root, add the tile-name fix 
ZERO-LAUNCH FIXES from the multi-agent pass over 0x18013af30 and 0x1801683f0.

FUT_STORE_FIELDS IS DELETED, AND IT WAS A FREEZE, NOT A REGRESSION. It sent
"actionType": 0 and "firstPartyStoreId": 0 as JSON INTEGERS. Both atoms (0x8, 0x127)
are read with the STRING getter 0x1801c7aa0. That is the exact type-desync class this
project exists to avoid. So "the corrections stopped packs opening" was never bad luck
or an unrelated field: two of them were the documented freeze mechanism, shipped by a
change whose own comment claimed it was correct about what the parser reads. Knowing
WHICH atoms a parser reads tells you nothing about which TYPES it demands. Read the
getter, every time. (Two other fields in that block were no-ops anyway: useDefaultImage
0x36a stores inverted, and visible 0x37d never reads its value at all.)

FUT_STORE_GROUPS IS DELETED and its freeze is now traced end to end. It sent
displayGroup as an ARRAY of pack-shaped objects on the belief that the key was parsed
recursively by the same element parser. It is not recursive at all: case 0xd9 never
re-enters 0x18013af30. It is a FLAT OBJECT with exactly two members. An array desyncs
the reader, the parser runs off the end of the document, and the tokenizer returns the
same token forever with nothing consumed, spinning inside FUN_1801c7f10 whose body
contains the observed PC 0x1801c7f1a.

Both were being kept as togglable "maybe nearly right" experiments. Each is a loaded
gun; neither survives contact with the decompile. Deleted rather than left switched off.

NEW FUT_STORE_DISPLAYGROUP (default 0): send the one key that actually names a tile,
displayGroup = {"value": "<pack name>"}. `value` (0x377, STRING) writes record offset
+0x00, the same slot whose constructor default is the literal "unknown" (the only such
literal in the DLL, 0x180223108). The tiles say "unknown" because nobody ever sent the
field. Distinct values per pack so grouping stays 1:1. priority/displayGroupAssetId/
displayGroupUseDefaultImage all omitted as second variables.
Default OFF for a reason the token-balance proof does not cover: this may be the first
field we have sent that selects a RENDER PATH rather than a value, and that code is
packed.

SEASON ROOT SHAPE CORRECTED. season_list() and its docstring were both wrong in the
same way: the deserializer is 0x1801683f0 (object root, one key seasons=0x2ad, array
inside), not 0x180167740, which is the per-ELEMENT parser. Someone read the element
parser and served its key set at the document root, so a bare array populated nothing.
Three of the keys served (eligibilityKey/Slot/Value) are inner members of elgReq and
inert even at element level. Also recorded: `type` must precede `divisionId` because
the divisionId branch reads the parsed type at elem+0x1b4.
Still behind FUT_MODES and still pointless to serve: across 486 real client requests
the game has NEVER asked for /season. Every /season line in our log is our own curl.

NEW FUT_CLUB_PAGE (default 0): an experiment, not a fix. The MY CLUB counter's
renderer is not in cardsdll (no two-number formatter of any spelling exists) and
FutStickerBookSearch has no count atom, so there is no field we can send that IS the
number. What is still testable is whether the counter is a Flash-side count over the
returned list, which a pure length change discriminates. A NULL RESULT IS THE VALUABLE
ONE: if the counter does not move, there is no server-side lever for this symptom and
the right outcome is to prove that and stop.

392 + 61 checks green, defaults byte-identical.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 14:02:09 -07:00
funman300 397d46f174 fifa17-recon: the -4 rule is literally the ASCII prefix "RS4:" 
The "4-byte header" that precedes every response class name in .rdata, which cost six
failed class-to-deserializer resolutions before anyone noticed the offset, is not a
length prefix or a refcount. It is the string RS4:. The full literal is
RS4:FutXServerResponse, and searching for the bare class name lands four bytes in.

Verified directly on three classes:
  FutDestroyMatchServerResponse           name@0x18021d694  header = b'RS4:'
  FutGetDraftCurrentStateServerResponse   name@0x180224204  header = b'RS4:'
  FutStickerBookStats2ServerResponse      name@0x1802220cc  header = b'RS4:'

Found by a verification agent that had been instructed to distrust the rule. It did,
and came back with the reason rather than the offset. A magic constant you have to
remember is a rule you will eventually get wrong; a prefix you can read is not.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 13:48:14 -07:00
funman300 24bbc32da5 fifa17-recon: fix the match tail -- real URLs, endReason, and coins in the right place 
The whole match family is one RPC descriptor block (rows 49-54, every row using URL
template index 16 = `ut/%s/match`) with a fixed suffix appended per call:

  CREATEMATCH  ut/game/fifa17/match          PLAYGAME    ut/game/fifa17/match
  MATCHREADY   ut/game/fifa17/match/ready    DESTROYMATCH ut/game/fifa17/match/end
  RESETMATCH   ut/game/fifa17/match/reset    KEEPALIVE   ut/game/fifa17/match/keepalive

THERE IS NO /match/{id} URL. The id travels in the body. Our reward path was gated on
`h.command == "DELETE" or "/ut/delete/" in h.path` and extracted the id with
re.search(r"/match/(\d+)"), so it was waiting for a request the client does not make.
The gate is now widened to include a /match/end path with ANY verb, because the verb
genuinely cannot be determined statically: the strings "PUT" and "DELETE" do not exist
anywhere in cardsdll.dll (0 hits each), so verb selection happens outside this DLL. A
reviewer flagged "the reward path can never fire" as overreach on exactly that point;
widening rather than replacing the gate is the response.

THE RESULT SIGNAL IS `endReason` (atom 260), a STRING enum with nine values: WIN DRAW
LOSS DNF QUIT NO_CONTEST DNF_WIN DNF_DRAW DNF_LOSS. Not a score comparison. The score
lives in `myMatchStats.goals` / `opponentMatchStats.goals`, two literal-keyed objects
of 15 int fields each, and the client OMITS both when endReason is DNF or QUIT, so
nothing may require them. _match_result() now reads endReason first and keeps the old
spelling probe only as a fallback, because request-side static findings are a floor:
PUT /item's swap/tradeId appeared in no static listing either.

THREE CORRECTIONS TO THE RESPONSE, all of which were shipping wrong:

1. `coins` (atom 149) is NOT a top-level key. It is read only inside `gameModeAward`.
   The one field most obviously named "the reward" was being silently skipped.
2. `qualifiedChampionEventId` (0x269) has a SIDE EFFECT: its branch calls through a
   manager vtable after storing. Sending a habitual zero poked champion-event
   machinery for no benefit. Removed.
3. `bidTokens` (atom 89) inside gameModeAward is MATCHED and then handled by nothing,
   so its value token is left unconsumed. That is the precondition for the desync
   spin. A freeze trap dressed as an ordinary field; now guarded by a unit check.

test_match_rewards.py rewrote its expectations. The old version asserted a top-level
`coins` and passed happily while the server shipped a body whose reward field the
client never read. A test that encodes the wrong schema converts a bug into a
guarantee. New test_end_reason_is_authoritative covers all nine enum values, the
stats-less DNF case, and that endReason beats a contradictory score probe.

DEFAULT ON (FUT_MATCH_END=0 reverts), a reasoned exception to the flag convention:
nothing here is live-proven because no match has ever been played, and the old
behaviour is not a working screen but a path that provably could not fire.

61 unit checks (58 with the flag off), 392 contract checks green.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 13:47:05 -07:00
funman300 0968cd351b fifa17-recon: route squad/mode/draft/state -- the root container is an ARRAY 
Deser 0x180147070 (FutGetDraftCurrentStateServerResponse) discards tokens until it
sees START_ARRAY. Handed a top-level OBJECT it never reaches its exit condition and
spins in the inner `while (tok != END_OBJECT)` loop while the tokenizer returns EOF
forever. Process alive, no crash dump, no dialog: exactly the signature observed live
on 2026-08-03, when our generic /squad route answered this endpoint with a full
active-squad object.

The suffix composition `ut/%s/squad/mode` + `/draft/state?mode=...` makes the URL
invisible to the request-template table, which is why /squad swallowed it. Fourth time
a suffix endpoint has been invisible to that table, second time the generic /squad
route has eaten one (/squad/list was the first).

Verified at instruction level rather than by regex: 7 top-level atoms (4 int-getter
calls, 3 string-getter, 0 bool, 2 skip) across the whole body [0x180147070,
0x1801475a3]. FUN_180135ff0 IS present, twice, so unknown keys are inert. NO ATOM
COLLIDES with the squad object we were serving, which means the hang was purely the
container level and not a per-field type desync.

entranceCriteria(0x108) is now known to be an object of three int keys
COINS/DRAFT_TOKEN/POINTS. It is OMITTED anyway: knowing a shape is not a reason to
send it.

A second agent independently simulated this exact body through the deserializer line
by line and got a clean exit in 16 token reads, and separately refuted four claims in
the first agent's report (a census undercount, a wrong .rdata address where
0x18021e7f4 is 'TFA' not the squad template, an incorrect stateParam2 typing argument,
and a dangerous aside about a second array-root envelope). The body survived all of it.

DEFAULT ON, a deliberate exception to "default to the live-proven value": the
live-proven value here HANGS THE GAME, and there is no working screen to protect
because Draft cannot be entered at all today. FUT_DRAFT_STATE=0 restores the old
routing.

392 + 51 checks green; /squad/0 and /squad/list verified unchanged.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 13:43:34 -07:00
funman300 224874d1d3 fifa17-recon: close both standing items in the priority doc 
User-Agent filter: implemented as the default in futlog.py.

The two wrong .rdata addresses: verified they never reached any document. They existed
only in an agent recon report, so there was nothing to correct. Kept the reviewer's
corrected values because they are verified and useful:
  RS4:FutGetClubInfoServerResponse         0x180221a38  (not 0x180220e38)
  RS4:FutStickerBookSearchServerResponse   0x180221e48  (not 0x180221248)

Closing an item by checking it was never a problem counts as closing it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 11:35:23 -07:00
funman300 38b10e5ec5 fifa17-recon: S18d -- a testable hypothesis for the Seasons blocker 
/leaderboards/options is the ONLY mode-related endpoint the real client has ever
requested, and we answer {} because FUT_MODES is off. Three of its seven occurrences
are followed within ~2 minutes by /user/accountinfo and a fresh /ut/auth, which is the
signature of hitting an error, returning to the main menu, and re-entering FUT.

Hypothesis: the client fetches mode options on entering the play area, caches them, and
later refuses Seasons from that cached EMPTY body without issuing another request. That
would explain the zero-requests-at-failure observation, which no response-shape theory
has been able to account for: the deciding fetch happened minutes earlier.

Stated as a hypothesis, not a finding. The correlation is real; the causation is not
established. Cheap to test: leaderboard_route already implements an options body behind
FUT_MODES=1.

Risk noted in advance: FUT_MODES=1 also enables /season, whose array-root shape is a
flagged freeze candidate. That risk cannot fire while the client never asks. If this
hypothesis is right, a populated options body is precisely what would make it ask for
the first time, so succeeding at step one arms step two.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 11:33:56 -07:00
funman300 b7943aead3 fifa17-recon: contract test guarding the move-verdict shape (392 checks) 
The bug we just closed was invisible to every existing check: PUT /item answered 200
with a well-formed JSON body, and the body told the client the move had FAILED. Seven
attempts, weeks of investigation, and nothing in the suite would have noticed a
regression back to {}.

test_move_verdict_shape asserts the record vector exists, has ONE RECORD PER REQUESTED
ITEM (an empty vector fails the client exactly as hard as a wrong field), and that
id/pile/success carry the number/string/bool types their getters require.

Non-mutating: it asks to move ids that cannot exist, so nothing changes pile. The
verdicts come back success=false, which is honest and is not what is asserted.

Verified it actually catches the regression rather than just passing:
  default (ack)        392 checks passed, 0 failed
  FUT_MOVE_BODY=empty  382 passed, 1 FAILED -- "returns itemData array"

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 11:32:04 -07:00
funman300 dd8dddd7af fifa17-recon: log archaeology -- /club is only ever the SEARCH form 
REBUILD_RESEARCH S18, from running futlog.py over the full 3044-request history.

The client has requested /club six times and EVERY ONE carried a query string
(year/type/count/position/level/nation/league/team/sort). The bare path has never
been requested. ENDPOINT_MAP says GET ut/%s/club is FutGetClubInfo, whose only
recognised member is user(0x36c), and concludes our itemData body is skipped and the
club list must therefore be empty. The club list is NOT empty; every card renders. So
either the query form dispatches elsewhere or the row is wrong. TODO/CONFIRM.

Relevant to the MY CLUB counter: we ignore the query string completely and return all
109 items to a request asking for count=11 with position and sort filters, and our
response carries no result total. A paged search response is exactly where a tab
counter would read its number from.

Also recorded: the unmapped view is a standing detector for suffix endpoints the URL
template table cannot show. It has caught four so far.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 11:30:33 -07:00
funman300 e5bfe58fc8 fifa17-recon: futlog.py -- client-filtered log reader, and a correction it caught 
Implements the standing requirement recorded in priority-2026-08 S5: the User-Agent
filter is now the DEFAULT in the log tooling, not an option. The real client sends
ProtoHttp; our own probes send curl/* or Python-urllib/*. Reading the log unfiltered
gave this project a materially wrong picture of itself (/clubUser and /user/list had 93
and 180 hits, none from the game).

The old futlog.py was a one-off with a hardcoded path and no notion of who made the
request. Replaced with a real tool: timeline or summary, body/response display, path
regex, time window, status filter, and an --unmapped view that lists the endpoints the
client wants and we catch-all. --all and --probes exist for when you deliberately want
our own traffic.

Over the full 3044-request history: 486 requests came from the game.

IT IMMEDIATELY CAUGHT ME OVERSTATING SOMETHING. Yesterday's commit called the PUT /item
request shape "captured for the first time (the client had never successfully reached
this path)". False. There are NINE client PUT /item requests in the log, eight of them
during the failed attempts, every one carrying swap and tradeId:

  08:45:11 08:51:13 08:55:21 08:58:19 09:10:52 09:15:26 09:22:31 09:37:12 | 11:15:48

The request was on the wire and in the log the whole time. What was new was reading it.
Same class of error as the truncated decompile in S16: evidence already collected and
not looked at. REBUILD_RESEARCH S17 corrected.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 11:28:42 -07:00
funman300 5b139864ee fifa17-recon: SOLVED "Send to Club" -- it was the response body all along 
Live 2026-08-04 with FUT_MOVE_BODY=ack and FUT_PACK_AUTOCLUB=0. Bought a bronze pack,
opened it, chose Send to Club. The session SURVIVED, the five cards persisted into the
club pile, and there was no ut/delete/auth logout -- the logout that accompanied all
seven previous attempts.

  11:15:48 PUT /item
    req {"itemData":[{"id":100000125,"pile":"club","swap":0,"tradeId":0}, ... x5]}
    res {"itemData":[{"id":100000125,"pile":"club","success":true}, ... x5]}
  11:15:49 GET /user/credits      session alive
  11:15:51 GET /hub               no error dialog
  11:16:06 GET /club?year=2017... MY CLUB opened

PUT ut/%s/item never was an ack endpoint. It builds per-item VERDICT records, and the
completion handler raises EVENT_CARDS_MOVE_CARD_FAILURE when the vector is empty or
success != 1. Every body this project ever returned, {} included, told the client the
move had FAILED, and the client ended the FUT session because that is what that event
does. We were failing our own move.

Defaults flipped: FUT_MOVE_BODY empty -> ack, FUT_PACK_AUTOCLUB 1 -> 0. The autoclub
workaround is retired.

New intel, captured for the first time because the client had never got this far: the
request carries `swap` and `tradeId` beside id/pile. We ignore both and the move
succeeded, so neither is load-bearing for a pending-to-club move.

PROCESS, and this is the part worth keeping. The FIRST attempt at this test produced
no PUT /item at all: FUT_PACK_AUTOCLUB=1 had already emptied the pending pile at
purchase time, so the reveal screen had nothing to assign and the client never issued
the request. The workaround for the bug was hiding the bug. Before testing a fix,
check the configuration still lets the client make the call the fix is for.

Two self-inflicted incidents, both recorded in REBUILD_RESEARCH S17:
- Restarting the server to inject a flag WHILE FIFA was running produced the exact
  "error connecting to FIFA 17 Ultimate Team" dialog this project spent weeks chasing,
  from a plain connection refusal during the ~30s window. Restart only at the main
  menu, and check the log for ProtoHttp requests before blaming a response.
- pgrep -f matched the invoking shell twice, killing it before the restart, because
  the same command contained the literal script name in a later clause.

Docs updated: REBUILD_RESEARCH S17 (the solve), priority-2026-08 S2/S3.1/S6 (next task
is now the MY CLUB counter), PROJECT_REPORT 6a, HANDOFF 5a plus the stale "FutMoveCard
has no skip handler" claim in S3 and a new 5d for Seasons/Draft.

380 + 51 checks green.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 11:20:03 -07:00
funman300 18d864908e fifa17-recon: priority doc for August 2026 
The deliverable owed from the assessment brief. Ordered by cost of the measurement
that would settle each item, not by how important the outcome feels.

Headline reordering: the observation session ran and did NOT produce the match
shape. Seasons refuses with zero requests to any layer and Draft hangs, so both
routes into a match are blocked and /match is now behind a fix rather than in front
of one. The next task is instead one launch with FUT_MOVE_BODY=ack, which is the
only open problem where the decompiler has produced a verified necessary condition
that has never been satisfied.

Also recorded:
- The User-Agent split. Real client (ProtoHttp) vs our own probes. /clubUser and
  /user/list have 93 and 180 recorded hits and not one came from the game. Every
  "the client asks for X" claim predating the split is unsupported until rechecked.
- The narrowed-core measurement. The proposed boundary ("ownership and economy keyed
  by opaque integer item ids") is correct and every per-item prediction held, but
  narrowing is not what guts core: FIFA 17 relevance is. Six services totalling 869
  lines model features with no FIFA 17 endpoint at all, survive narrowing perfectly,
  and are worth nothing here. Suite: 61 of 101, not the 81 previously claimed.
  Recommendation is to reuse the scaffolding and the 61 tests, not the service layer.
- Port timing stays "after", led by the match-result-shape argument: three of the
  four queued items will change a response schema, and porting a placeholder schema
  means porting the correction too.
- test_fut_contract.py is now implementation-independent (380 checks over HTTP), so
  it can certify a Rust port. That is the port's main de-risking asset and it exists.
- A "What could make this plan wrong" section, including that a negative ack result
  is not a refutation, and that every negative claim in ENDPOINT_MAP.md is weaker
  than the corresponding positive one after the FutMoveCard retraction.

Standing requirements recorded, including the User-Agent filter default (required,
not yet implemented) and two wrong .rdata addresses still to correct.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 11:09:14 -07:00
funman300 f488793b34 fifa17-recon: RETRACT the FutMoveCard "no skip handler" claim; stage the ack shape 
RETRACTION. This repo claimed, in REBUILD_RESEARCH S14c and in utas_server's
item_route comment, that FutMoveCard 0x180128600 "HAS NO SKIP HANDLER
(FUN_180135ff0 appears zero times, unique among FUT deserializers)" and "parses
only itemData -> dreamSquads". Every part of that is false. Full decompile:

  FUN_180135ff0 call sites : 2   (offsets 5006, 6080)
  atoms parsed             : 7   active dreamSquads id itemData pile reason success

Cause: the decompile was written out as src[:4000] and then searched. The function
is 6193 chars, so BOTH skip-handler call sites and four of the seven atoms lay past
the cut. An absence was reported from a truncated listing -- the same failure mode
as the Memory.getBytes bytearray scan that silently returned zero hits. Never
conclude an absence without asserting the searched region covers the function.

Cost: the false claim implied "any extra key desyncs this parser", which sent the
investigation after client-side state for seven attempts, and the derived premise
"the deciding factor is client-side state, not the wire" was wrong too.

VERIFIED SHAPE. PUT ut/%s/item is not an ack endpoint; it returns per-item VERDICT
records:
  id(0x15c)      INT     0x1801c79d0  -> record+0x00
  pile(0x226)    STRING  0x1801c7aa0  -> enum 0x180142650 (club=7 purchased=6 trade=5)
  success(0x2fa) BOOL    0x1801c7620  -> record+0x0c
  reason(0x279)  STRING               -> "Destination Full" = 0xf
  dreamSquads(0xe9) INT array;  else  -> FUN_180135ff0 (skip)

The completion handler raises EVENT_CARDS_MOVE_CARD_FAILURE when the record vector
is EMPTY or record+0x0c != 1, and success is initialised to '\0' per element. So
every body ever returned reported the move as FAILED, {} included. Quick sell
survives an identical {} because its callbacks read only the transport code and
ignore the body -- that is the whole asymmetry, and it was on the wire after all.

STAGED, NOT DEFAULTED. FUT_MOVE_BODY=ack emits the correct shape; the default stays
`empty` because sufficiency is untested. One launch settles it.

The ack is answered BEFORE the `if moved:` gate: under FUT_PACK_AUTOCLUB=1 the
cards are already in the club when the reveal asks to move them, so move_items()
returns nothing and a moved-derived body would be zero-record -- failing in exactly
the configuration ack exists to fix. Caught in review before it ran. success is
asserted only for ids that were moved now or are already in the club; anything else
gets an honest success:false rather than an invented verdict.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 11:05:38 -07:00
funman300 a93a8bcdd7 fifa17-recon: decouple contract suite from the Python implementation 
test_fut_contract.py no longer imports ACCOUNT from fut_account. The expected
persona comes from FUT_TEST_PERSONA_ID and the target from FUT_TEST_BASE, so the
suite now imports nothing but stdlib and talks to a server at a URL.

That is what lets these 380 checks certify ANY implementation of the reversed
spec, a future Rust openfut-core included, without replaying the reverse
engineering. The original reason for reading ACCOUNT still holds and is preserved
in the comment: suite and server must not each hold a private copy of the
constant, or the identity-consistency checks would only prove two copies matched.

Also adds pileSizeClientData(0x227) behind FUT_PILESIZES (default off). A probe
run with 16 uniquely-valued entries did NOT move the MY CLUB counter, so that
member is eliminated as its source; the code is kept for the record and flagged
off.

Docs: OPENFUT_PROJECT_REPORT.md and OPENFUT_HANDOFF.md. The report now separates
"built but untested" from "never requested by the client" -- the server log records
User-Agent, and splitting real client traffic (ProtoHttp) from this project's own
probes shows /season, /tournament, /champion, /match, /clubUser and /user/list are
at ZERO client requests. /clubUser (0 client, 93 probe) and /user/list (0 client,
180 probe) are the starkest: work was done on both assuming the client wanted them.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 10:31:37 -07:00
funman300 5d5198f5d1 fifa17-recon: match rewards, POW online layer, account backend, quick sell 
Second session. FUT core loop, the EASFC/POW online layer, a central account
backend, and a lot of corrections. Everything risky is behind an env flag with
the default set to whatever was live-proven.

WORKING END TO END (live-verified this session):
  * match loop -- POST/PUT/POST/DELETE ut/%s/match, rewards via FutDestroyMatch
    (0x180121b60). Play a match, get coins, W/D/L updates.
  * packs -- buy, cards land in the club, session survives (FUT_PACK_AUTOCLUB=1)
  * quick sell -- POST ut/delete/%s/item was UNMAPPED and paid NOTHING; six cards
    were destroyed for 0 coins. Now credits discardValue.
  * POW/EASFC online -- the "EA FC servers unreachable" banner is powdll's layer,
    a THIRD http api on :8094 nobody had served. Redirect needs no root: powdll
    FUN_18005a460 reads FIFA_POW_URL from the same client-config store as
    ROSTERUPDATE_URL. FUT_POW=1.
  * account backend -- fut_account.py replaces 7 hardcoded copies of the persona
    across 5 files; club/persona/online-profile editable via CLI.

CORRECTIONS TO ENDPOINT_MAP (all re-extracted from the deserializers):
  * FutStoreGetPackTypes: id/packType/isPremium/quantity/saleType/purchaseLimit/
    purchaseCount are NOT skipped no-ops -- all are parsed. extPrice inner objects
    take externalPriceId(0x11a), not amount/currency.
  * FutMoveCard 0x180128600 has NO skip handler (FUN_180135ff0 appears zero times,
    unique among FUT deserializers) and parses only itemData -> dreamSquads.
  * class -> deserializer resolution: the name literal is preceded by a 4-BYTE
    HEADER and the factory LEA points at the header, so look up name_addr - 4.
    Six attempts failed on this; now ghidra_env.class_deser(). Unlocked 11 SBC/
    Draft schemas.
  * live-only endpoints the request table never lists: ut/%s/squad/list,
    ut/%s/user/club, ut/%s/club/stats/*, ut/%s/clientdata/<key>. The template
    table is a floor, not a ceiling -- the log is the only ground truth.
  * 163 RS4 call names exist; we served 17. All now served.

FIXED: club/stats/* was answering with the entire 28-item club inventory on every
poll (it fell through to the generic /club route).

UNSOLVED: the pack reveal's "Send to Club" (PUT ut/%s/item) kills the FUT session
whatever we answer -- {} included -- while its sibling quick-sell endpoint accepts
a bare {}. Seven hypotheses eliminated by live test, documented in
REBUILD_RESEARCH.md S14c so none get re-walked. FUT_PACK_AUTOCLUB routes around it.
Also unfixed: store tiles render "unknown" (displayGroup is parsed RECURSIVELY by
the same element parser; sending it FROZE the store, so FUT_STORE_GROUPS=1 is
default off).

Tests: test_fut_contract.py 380 (live, read-only) + test_match_rewards.py 51 (pure).

Note: fut_store.py carries some pre-existing uncommitted changes from before this
session (pack catalogue ids, pending-pile behaviour) that could not be separated
from this session's additions in the same file.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
 2026-08-04 09:42:59 -07:00
funman300 59934b4ef0 fifa17-recon: FUT squad blocker solved + userInfo delivered 
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
 2026-08-03 20:47:16 -07:00
funman300 6270c37208 fifa17-recon: store-enable live poke (online-readiness gate) 
The FUT store 'not available' is FIFA's online-mode readiness gate
(FUT::CompetitionManager), not a config flag. tools/store_enable_poke.py finds
CardsDLL's live base and patches the 3 gate methods (0x1800f7fb0
IS_EASTORE_SERVICE_READY, 0x1800fb850 IS_STORE_ENABLED, 0x180100500
IS_COIN_PURCHASABLE) to 'mov eax,1; ret'. Reversible (saves originals; 'restore'
subcommand; FIFA restart clears it). Needs ptrace_scope=0 + FIFA running.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
 2026-08-02 21:43:52 -07:00
funman300 f9ffcfdf20 fifa17-recon: map /transfermarket (live: FIFA's market search endpoint) 
Live log ground-truth: FIFA's transfer-market SEARCH hits
GET /ut/game/fifa17/transfermarket?type=player&start=0&num=12 (was UNMAPPED ->
catch-all {} => empty market), NOT /auctionhouse as the struct name suggested.
Route it to the same listings handler. Market now serves 18 listings on the
endpoint FIFA actually calls.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
 2026-08-02 21:26:41 -07:00
funman300 69ef101efb fifa17-recon: env-gated SBC experiment flags (FUT_SBC=1) 
Add enableSquadBuildingSetsFeature + FUT/SBC_USE_STUBS to the Blaze FUT config,
gated on env FUT_SBC (default OFF -> baseline unchanged, no restart needed). The
SBC set-list deser (0x180154990) checks FUT/SBC_USE_STUBS -- FIFA may render
built-in stub SBCs with zero server content. A concrete, safe lever to try SBCs
in the next live session without shipping complex (freeze-risky) SBC JSON blind.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
 2026-08-02 20:23:12 -07:00
funman300 0081dfc8d4 fifa17-recon: transfer market sell/list flow (stateful, tested) 
Complete the market loop (browse + buy + sell). POST auctionhouse (FutISStart)
lists an owned club item -> profile.listings + returns {id:tradeId}. tradePile
builds a validated auction record per listing from the owned item + prices
(freeze-safe, same 0x18013e410 shape). DELETE trade/{id} removes the listing.
fut_store gains list_for_sale/listings/remove_listing (tradeId space 900500000+).

test_market_buy.py extended with sell/delist checks (temp profile, no real-save
mutation): list -> tradePile shows it with prices -> delist empties it. All pass.
Read-only contract suite still 311/311. Functional (FIFA's exact sell params)
pending live test; freeze-safe by construction.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
 2026-08-02 20:21:10 -07:00
funman300 f38231d89d fifa17-recon: transfer market buy/bid flow (stateful, tested) 
trade_route now resolves the auction from its tradeId and, on buy-now
(bid >= buyNowPrice), spends coins + grants the won card to the club + echoes
the CLOSED auction (FutISOfferTrade shape). Reuses the validated auction record
(0x18013e410) so it stays freeze-safe; whether FIFA surfaces the won item
post-buy is functional (needs live test). Insufficient funds -> 461.

tools/test_market_buy.py: offline unit test on a TEMP profile (never touches the
real save) -- verifies coin deduction, card grant, closed-auction shape, and the
461 path. PASS. Read-only contract suite still 311/311.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
 2026-08-02 20:17:52 -07:00
funman300 b05ccd7ce5 fifa17-recon: record market-implemented status + SBC config-flag leads 
enableSquadBuildingSetsFeature / FUT/SBC_USE_STUBS (client-side stub SBCs) /
SBC_ELG_KEY_ found in CardsDLL -- the next lead for SBCs, to validate live.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
 2026-08-02 20:03:46 -07:00
funman300 f7f19aeed3 fifa17-recon: populate transfer market with real listings (freeze-safe) 
Serve 18 real-player auctions on GET auctionhouse (search) built to the reversed
auction record schema (deser 0x18013e410) field-for-field: itemData reuses
fut_store._item (the proven club/squad card parser 0x18013fe00), scalar fields
all HIGH-confidence reversed. Rating-based buy-now pricing; tradeId space
900000000+. tradePile/watchList stay empty (no live sell/watch flow yet). Toggle
off with FUT_MARKET=empty.

Extend test_fut_contract.py to validate EVERY populated record field type
(numbers/strings/bool/object) so the listings are proven freeze-safe OFFLINE
before the game parses them. 311 checks, all passing.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
 2026-08-02 19:59:41 -07:00
funman300 7a243aa795 fifa17-recon: contract/freeze-safety regression tests 
Add tools/test_fut_contract.py -- stdlib-only, read-only tests that hit the live
utas_server and assert each response matches the shape reversed from CardsDLL
(docs/ENDPOINT_MAP.md). Encodes freeze-safety invariants (auctionInfo/players/
itemData/currencies/purchase must be array/object per the SAX deserializers;
scalar-where-container = busy-loop freeze at 0x1801c7f1a) plus the specific
contracts: v2/store gate == SUCCESS, coin counter binds currencies[coins].funds,
userMassInfo stays {}, empty squad slots carry itemData=null (proven-safe).
Catches the regression class that previously bit us (phantom packs, coins-0,
squad reset). 58 checks, all passing.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
 2026-08-02 18:59:09 -07:00
funman300 629813b580 fifa17-recon: transfer market read routes (empty-but-valid) 
Add auctionhouse/trade/tradePile/watchList/marketdata routes per ENDPOINT_MAP
market §. All share the reversed IS-list body {auctionInfo:[], credits, total,
duplicateItemIdList} (shared deser 0x18013e7f0). Served EMPTY (no live listings
yet) -- empty arrays never desync the SAX reader, so freeze-safe; unlocks the
market screens vs the prior catch-all {}. GET auctionhouse merges the
FutGetAuctionCount ints (extra keys skip). POST auctionhouse = FutISStart new
tradeId; PUT relist / watch add-remove / delete = acks. tradePile precedes
/trade (prefix collision). Populating real auctions deferred to in-game test.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
 2026-08-02 17:15:41 -07:00
funman300 4e89cce37d fifa17-recon: store fix (v2/store gate + flags) + full FUT endpoint map 
Store "not available" root cause reversed from CardsDLL:
- ut/v2/game/fifa17/store is an ELIGIBILITY gate (FutStorePackQuantities
  deser 0x1801758c0), not a quantity list. It reads one key "result"
  (atom 0x288); the store screen refuses to open unless SUCCESS. Was
  unhandled -> catch-all {} -> "not available". Now returns {"result":"SUCCESS"}.
- Store-screen entitlement checks (0x18001749d/0x1800175a2) read IS_*/
  *_PURCHASE_ENABLED Blaze flags, separate from storeEnabled. Added the full
  confirmed set (14 flags) to FUT_RS4_CONFIG.
- Catalog: assetId (0x23) is the real pack identity; extPrice inner keys are
  amount/currency (not mtx). (Also gated client-side by GetSystemMetrics>1024x768.)

Full FUT API reversed (clean-room, CardsDLL only) into docs/ENDPOINT_MAP.md:
~100 FutXServerResponse types across 7 feature groups (market, SBC, draft,
seasons/match, club, store, user/hub), each with deserializer VA, atom-mapped
field schema + types, freeze-risk flags, and minimal known-good JSON.
Tooling kept: tools/atomdump.py (dumps the 907-atom key table at 0x1802d2760)
-> docs/fut_atoms.tsv. Research prompt: docs/OPENCODE_ENDPOINT_PROMPT.md.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
 2026-08-02 17:13:11 -07:00
funman300 c7759a52c4 fifa17-recon: working FUT store + pack opening + coins format 
Reverse-engineered the exact FIFA17 store/purchase/credits response
shapes (wf a245577b + wf_76fcf89b) and applied them:

- Store catalog: root key MUST be "purchase" (atom 608) not
  "purchaseGroups"; packs keyed by "id" (int16) not packId; price is a
  "currencies":[{name,funds,finalFunds}] array; name is "description".
  Our old {purchaseGroups:...} hashed to unknown atoms -> empty -> "store
  not available". Now the store displays.
- Pack buy: gate open_pack on a transaction with "packId" and state !=
  TRANSACTIONCANCEL (the TRANSACTIONCREATED create step) -- fixes the
  phantom-buy. Reveal response = {"createPackResponse":{itemList,
  numberItems,purchasedPackId,duplicateItemIdList}}
  (FutCreatePackServerResponse).
- Coins: /user/credits must return currencies[name=="coins"].funds, not
  {"credits":N} (the hub/store read currencies). squad_route also
  reconstructs the active squad from club item-id references.

Verified via curl: store shows 3 packs; cancel spends nothing; Bronze
buy awards 5 real players and deducts 400 coins. NOTE: the FUT HUB coin
counter reads from userMassInfo (not /user/credits) -- still blocked on
the userMassInfo-freeze wall (separate reverse in progress).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
 2026-08-02 10:22:24 -07:00
funman300 89dc9baa61 fifa17-recon: fix active squad resetting on reload 
FIFA's updateActiveSquad PUT stores each slot as itemData={id:<clubItemId>}
(a reference), not the full player. We saved the bare references, so the
squad reloaded empty ("active squad resets"). Add Store.reconstruct_squad()
to re-embed the full club item by id on GET /squad/0, so the saved squad
reloads with its real players.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
 2026-08-02 09:56:18 -07:00
funman300 1b2319635d fifa17-recon: fix store transaction wrongly auto-opening packs 
store/transaction receives {"state":"TRANSACTIONCANCEL"} (cancel/close)
and {"packId":N} (pack-details fetch on store load) -- neither is a
confirmed purchase. The handler treated packId as a buy and even
defaulted to opening a Gold Pack on cancels, silently spending coins.

Make store_buy a safe no-op that logs every body, so the real
purchase-CONFIRM signal can be identified from a deliberate in-game buy
and open_pack() gated on exactly that. Save restored on next fresh run.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
 2026-08-01 21:05:25 -07:00
funman300 5c43dbe39e fifa17-recon: pack opening (store catalog + buy + award) 
Add a first-cut FUT store on top of the persistent profile:
- fut_store: PACK_CATALOG (Bronze/Gold/Premium), a curated real-player
  PACK_POOL, and open_pack() (deduct coins -> generate items -> add to
  club -> persist).
- utas_server routes: GET store/purchasegroup/all (catalog), PUT
  (v2) store/transaction (buy + open, returns awarded itemData +
  updated coins), GET purchased (last pack). Matches both /ut/game and
  /ut/v2/game prefixes.

Verified via curl: buy Gold Pack -> 7 real players awarded, coins
15000->10000, club 10->17, persisted. Wire format is a best-guess
grounded in the CardsDLL store keys (packId/price/itemData/coins);
iterate against the in-game store next. Pool is curated for now --
replace with a full dbdata.dll extract later.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
 2026-08-01 20:56:07 -07:00
funman300 bebe573d05 fifa17-recon: persistent FUT profile + starter pack 
Add fut_store.py: a JSON-backed profile store (coins, owned club items,
saved squads, record). First run grants a starter pack -- 15000 coins +
a 10-player starter club (real assetIds; identity resolves locally
in-game per docs/CARD_SYSTEM.md).

Wire utas_server to the store: /user/credits -> persisted coins,
/club -> persisted owned items, PUT /squad -> persists the squad the
user builds so it survives relaunches. Profile save file is gitignored.

Foundation for pack-opening (store/purchasegroup + transaction) next.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
 2026-08-01 20:52:48 -07:00
funman300 2083a8821e fifa17-recon: SOLVED — real player cards render offline 
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
 2026-08-01 20:48:03 -07:00
funman300 6ddd5e9d47 fifa17-recon: offline FUT squad-shell working + full card-system RE 
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
 2026-08-01 20:24:30 -07:00
517 changed files with 462323 additions and 98 deletions
Expand all files Collapse all files
OPENFUT_HANDOFF.md
+265
View File
@@ -0,0 +1,265 @@
# OpenFUT — project handoff
Self-contained briefing for an assistant with **no access to this repo or machine**.
Everything needed to understand the project and reason about its open problems is here.
---
## 1. What this is
**OpenFUT** is a clean-room, fully offline re-implementation of the server backend for
**FIFA 17 Ultimate Team (FUT)**. EA's servers for FIFA 17 are long dead. The goal is to
make the retail game's FUT mode fully playable again — open packs, build squads, use the
transfer market, play matches and earn rewards — by emulating every server the client
talks to, on localhost.
Nothing is decompiled *into* the project. The game's binaries are read to learn the
**wire format** (which JSON keys, of which types, each response must contain), and the
servers are written from scratch in Python against that spec.
The client is unmodified retail FIFA 17 running under Wine/Proton on Linux.
---
## 2. Architecture — four independent servers
FIFA 17 does not talk to one backend. It talks to four, on different protocols, and all
four must be satisfied in sequence before FUT loads.
```
FIFA 17 (Wine/Proton)
│
├─ LSX / Origin :4216 XML over TCP. Local Origin client emulation.
│ Login, entitlements, persona.
├─ Blaze :42127 redirector (TLS) → :42130 game server, :42131 nucleus
│ EA's binary "Fire2/TDF" RPC protocol. Session, auth,
│ and — critically — the CLIENT-CONFIG STORE.
├─ UTAS / RS4 :8099 The FUT REST API. JSON over HTTP. ~45 endpoints.
│ Club, squads, packs, market, matches. The bulk of it.
└─ POW / EASFC :8094 (+ :8080 content) A third HTTP API, discovered late.
Online status bar, level, EASFC credits, catalogue.
```
Plus two helpers: a **roster** server (:8081) serving a roster-update XML the FUT
loading screen blocks on, and **autopatch**, which patches the running process's
ProtoSSL certificate verification so the client accepts our self-signed TLS.
### How the client is redirected
Three mechanisms, in decreasing order of preference:
1. **Blaze client-config keys** — the cleanest. Blaze serves a key/value config store
and the client reads its own service URLs from it. `FUT_RS4_APIURL_<MODULE>` and
`FUT_RS4_URL_<CALL>` point the FUT API at `127.0.0.1:8099`; `FIFA_POW_URL` points
the EASFC layer at `127.0.0.1:8094`. **No root, no DNS games.**
2. **`/etc/hosts`** — for hosts baked into the binary (`easw.easports.com`,
`gosredirector.ea.com`).
3. **iptables DNAT** — for a hardcoded IP (`159.153.51.20` → the Blaze redirector).
---
## 3. The wire format, and why it is unforgiving
FUT responses are JSON, but the client does **not** use a general JSON object model. Each
response class has a hand-written SAX-style deserializer that walks tokens and dispatches
on a **hashed key id** (an "atom"). This has three consequences that dominate the project:
**Atoms.** Every JSON key name maps to a 16-bit atom id via FNV-1a. There is a recovered
table of ~900 (id → name). A response is really "which atoms does deserializer X read,
and of what type".
**Type fidelity is fatal.** Feeding a scalar where the parser expects an object or array
does not error — it **desyncs the token reader and the game hard-freezes** in a busy loop
at `0x1801c7f1a`. This is the single most common way to break the game, and it has bitten
this project repeatedly. Arrays must be arrays; nested objects must be objects.
**Unknown keys are usually skipped safely** — most deserializers route an unrecognised
atom to a value-skip handler (`FUN_180135ff0`), so extra fields are inert. This document
previously named `FutMoveCard` (`0x180128600`) as an exception with no skip handler at
all. **That was wrong**, and the retraction is in §5a: it has two skip-handler call sites
and parses seven atoms. No deserializer in this project is currently known to lack one.
Treat any future "this class has no skip handler" claim as unproven until the search is
shown to have covered the whole function.
### Working method
For any endpoint: find the response class's deserializer, extract the atom ids it
compares against, map them to names, note the getter used for each (int / string / bool /
nested), and build the minimal body. Omit nested members unless their shape is known —
omission is skip-safe, a wrong shape freezes the game.
---
## 4. What works today (live-verified)
| Area | Status |
|---|---|
| Boot to the FUT hub | ✅ |
| Club identity, coins, W/D/L record | ✅ |
| Active squad — renders 11 real players, chemistry links | ✅ |
| Squad building — `PUT /squad/<id>` fires, persists across relaunch | ✅ |
| Squad roster ("MY SQUADS") | ✅ |
| Transfer market — browse, bid, buy-now, sell, watchlist | ✅ |
| Packs — buy, reveal, Send to Club | ✅ (the workaround is retired, see §5a) |
| Quick sell — destroys cards, credits coins | ✅ |
| Match loop — create/ready/play/destroy + coin rewards | ✅ implemented, **never played in-game** |
| Online/EASFC status bar (no "servers unreachable") | ✅ when enabled |
| Seasons / tournaments / leaderboards / champions | ⚠️ routed with reversed schemas, never live-tested |
Current save state: 99 club items, 8,400 coins, 0-0-0 record.
**Design convention:** every risky change ships behind an environment flag, default set
to whatever is live-proven (`FUT_MASSINFO`, `FUT_USERINFO`, `FUT_MODES`,
`FUT_PACK_AUTOCLUB`, `FUT_POW`, `FUT_STORE_GROUPS`, …). This exists because two working
screens were broken by shipping "corrections" on by default.
---
## 5. Open problems
### 5a. "Send to Club" kills the FUT session — SOLVED 2026-08-04
Opening a pack shows the cards correctly; choosing **Send to Club** used to produce
*"there has been an error connecting to FIFA 17 Ultimate Team"* and a logout, seven
attempts running. The cards always moved server-side; only the acknowledgement was
rejected.
The cause was the response body. `PUT ut/%s/item` returns per-item **verdict** records,
not an acknowledgement, and the completion handler raises
`EVENT_CARDS_MOVE_CARD_FAILURE` when the record vector is empty or when `success != 1`.
Every body the project returned, `{}` included, reported the move as failed. The fix is
the real shape:
```json
{"itemData":[{"id":100000125,"pile":"club","success":true}, ...]}
```
Live: five cards to the club, session survived, cards persisted, no `ut/delete/auth`.
The autoclub workaround is retired.
Two corrections this closed, both worth carrying forward:
- The repo's claim that this deserializer had **no skip handler** and parsed only two
keys was false. It came from searching a truncated decompile. It implied the body
could not be at fault, which is what sent seven attempts after client-side state.
Never conclude an absence from a truncated or unverified-length extraction.
- The quick-sell asymmetry was not evidence of client state. Quick sell's callbacks
read only the transport status code and never touch the body.
### 5b. "MY CLUB" counter always reads 0 — UNSOLVED
The hub tab bar shows `MY CLUB 0` despite the club holding 99 items.
**Eliminated by live test:**
- **Not the item list** — the user opened MY CLUB, the client fetched the club and
**displayed all 99 players correctly**, and the counter still read 0.
- **Not `pileSizeClientData`** — the massinfo member that carries pile sizes as
`{"entries":[{"key":int,"value":int}]}`. A probe sent 16 entries with uniquely
identifiable values; the counter stayed 0.
- **Not lazy loading** — the club endpoint was fetched 6 times that session.
**Unexplored contrast:** the `ACTIVE SQUAD` tab in the same bar correctly shows `11/23`.
So some counters work. Whatever differs between that one and the club one is likely the
answer.
### 5c. Store tiles render "unknown" — DIAGNOSED, NOT FIXED
Pack tiles show `unknown` with zero item counts. The `"unknown"` string is an
unconditional **default** in a string constructor — the field simply never gets written.
The store renders *display groups*, and `displayGroup` is parsed **recursively by the same
element parser**. Sending it populated **froze the store** (the type-desync busy loop), so
it is behind a flag, default off. Doing it properly needs the group's own field set worked
out rather than a self-referential copy of the pack.
### 5d. Seasons and Draft refuse — UNSOLVED, and not obviously server-side
Selecting **single-player Seasons** raises *"There was a problem communicating with the
FIFA Ultimate Team servers"* while making **zero requests to any layer**. UTAS, Blaze and
POW logs show only pings and one census subscription across the whole failure window. No
response can be wrong because no request was made. POW is eliminated (same failure with it
enabled and disabled).
**Online Draft** hangs the client rather than crashing it (process alive, no dump). The
one suspicious thing on the wire is `GET ut/%s/squad/mode/draft/state`, which our generic
`/squad` route answers with a full active-squad object: 23 slots, nested `itemData`, a
33-integer formation string. The real class wants `roundsInfo` plus a state enum, so this
is a textbook type-desync candidate and the timing matches. **Nothing has isolated it**;
it is a suspect, not a cause.
Both matter beyond themselves, because they are the only two routes into a match, and the
`/match` request shape has therefore never been captured.
---
## 6. Notable reverse-engineering findings
- **Class → deserializer resolution.** A response class's name literal is preceded by a
**4-byte header**, and the constructing factory's `lea` points at *the header*, not the
text. Lookups must use `name_address - 4`. Six attempts failed on this off-by-four;
four of them returned zero results and nearly got recorded as "this class has no
deserializer".
- **The request-template table is a floor, not a ceiling.** Several real endpoints are
built by the caller appending a suffix and therefore never appear in the binary's URL
table: `squad/list`, `user/club`, `club/stats/*`, `clientdata/<key>`. Only live traffic
reveals them. This has caught the project three separate times.
- **The documentation lies.** The project's own `ENDPOINT_MAP.md` (~1,360 lines, ~100
reversed structs) has been wrong repeatedly: it claimed `FutMoveCard` parses
`chemistry` (it does not); it called seven store pack fields "skipped no-ops" (all are
parsed); it gave price-object keys as `amount`/`currency` (the parsers read
`externalPriceId`). **Verify against the decompiler before relying on any row.**
- **The online layer was hiding in an unpacked DLL.** "EA FC servers are unreachable"
comes from a third HTTP API implemented in a *loose, unpacked, string-rich* library —
not the packed executable, and not any layer previously emulated. It is redirectable
purely through the Blaze config store.
- **The main executable is Denuvo-packed.** Its code exists only in a live process. Live
memory is readable via `/proc/PID/mem` (the PE is mapped flat), which is how a crash
site was disassembled. Any logic living there cannot be reversed statically.
---
## 7. Tooling built
- A **PyGhidra harness** with helpers for decompiling, xrefs, vtables, byte scanning and
class→deserializer resolution. (Ghidra's Java/OSGi scripting is broken on this machine;
PyGhidra bypasses it entirely.)
- A **minidump reader** — exception record, fault-time registers, module map, and a stack
walk that recovers a usable backtrace.
- A **live code grabber** that reads and disassembles unpacked code out of a running
process.
- A **read-only live probe** pattern for polling client model state while playing.
- **Two test suites**: 380 live contract checks (freeze-safety: asserts every response
field's type against the reversed schema) and 51 pure unit checks for match rewards.
- A **traffic-replay audit** that diffs current responses against a known-good session —
this is what proves a change did not alter what the client sees.
---
## 8. Documentation in-repo
| File | Contents |
|---|---|
| `ENDPOINT_MAP.md` | ~100 reversed response structs, atoms, types, freeze risks |
| `FUT_RESPONSE_REBUILD_PLAN.md` | Squad family, massinfo, the service-layer call graph |
| `REBUILD_RESEARCH.md` | Complete API surface, gap analysis, POW layer, and every eliminated hypothesis with its evidence |
| `CARD_SYSTEM.md` | How card identity resolves locally from the game's own database |
| `REPACK_INTEL.md` | Origin/LSX emulation notes |
---
## 9. Where help would be most valuable
1. **The MY CLUB counter (§5b).** Given the client demonstrably *has* the items and
*renders* them, what else could a tab counter read from? Note that a sibling counter in
the same bar works correctly.
2. **Seasons refusing with zero requests to any server (§5d).** The client raises a
"problem communicating with the FIFA Ultimate Team servers" without contacting
anything. Nothing on the wire can be wrong because nothing went on the wire.
3. **Whether the remaining problems are fixable server-side at all**, or whether the
deciding logic lives in the Denuvo-packed executable and only live instrumentation can
settle it. Note that this question was asked about `Send to Club` too, and there the
answer turned out to be a plain wire fix, so treat "it must be client-side" as a
hypothesis needing evidence rather than a fallback explanation.
Useful framing: this project's failures have almost always come from proposing a fix
before testing the assumption under it. Hypotheses that come with a cheap way to
disconfirm them are worth far more than plausible ones.
OPENFUT_PROJECT_REPORT.md
+313
View File
@@ -0,0 +1,313 @@
# OpenFUT — Project Report
**Goal:** make FIFA 17 Ultimate Team fully playable offline, forever, by re-implementing
every server the game talks to.
**Status:** FUT boots, loads, and is playable. Packs, squads, the transfer market, coins
and progression all work. Two cosmetic/flow problems remain open.
**Timeline:** 2026-06-25 → 2026-08-04 · 44 commits · ~12,900 lines of Python across 39
tools · ~3,600 lines of reverse-engineering documentation.
---
## 1. What the project is
EA shut down FIFA 17's servers years ago, which kills Ultimate Team — the mode is entirely
server-driven. Your club, squads, packs, market and progression all live server-side, so
without a backend the mode is dead even though the game still installs and runs.
OpenFUT replaces that backend with local servers. The game is **unmodified retail
FIFA 17** running under Wine/Proton on Linux; nothing is patched into the game except a
single runtime tweak so it accepts our TLS certificate.
This is **clean-room work**. No EA code is copied or redistributed. The game's own
binaries are read to learn the *wire format* — which JSON keys, of which types, each
response must carry — and the servers are written from scratch against that specification.
---
## 2. Project history
The project changed target twice before finding its footing. That arc matters, because
each pivot was driven by hitting a hard wall.
**Phase 1 — FIFA 23 (June 2026).** Began as an offline FUT backend for FIFA 23: a Rust
core (`openfut-core`, Axum + SQLite), a protocol bridge (`openfut-bridge`), and a GUI
launcher. All three built and passed tests. The architecture was sound but the client
never got far enough to exercise it.
**Phase 2 — the FIFA 23 wall.** FIFA 23 refused to go online at all. Extensive reverse
engineering of the connection state machine, live-memory probing, and forcing the
"go online" gate directly all failed — the client's internal coherence checks were the
wall, not any single flag. Documented as a dead end rather than fought.
**Phase 3 — the FIFA 17 pivot (late July).** FIFA 17 turned out to be a far better target:
its network library is **unprotected and fully symboled**, exposing 979 RPC names. The
insight was to crack FIFA 17 first and port the understanding back.
That worked, quickly:
- **TLS pinning defeated** — the client's certificate verification is patched at runtime
in memory, so a self-signed cert is accepted.
- **Origin/LSX emulation** — the local Origin client protocol was reverse engineered,
including the repack's own crypto layer, beating "log in to Origin" and
"title version outdated".
- **Blaze cracked end to end** — EA's binary RPC protocol: redirector, second-hop
handshake, and the encoded pre-auth exchange. This was the big one.
- **Full FUT API mapped** — ~100 response structures reverse engineered to field level.
**Phase 4 — building the FUT backend (August).** With the protocol understood, the work
became making FUT actually *play*: card rendering, packs, the store, the transfer market,
squads, and match rewards. This is where the project stands.
---
## 3. Architecture
FIFA 17 does not talk to one backend. It talks to **four**, on different protocols, and
all four must be satisfied in sequence before FUT loads.
```
FIFA 17 (Wine/Proton)
│
├─ LSX / Origin :4216 XML/TCP — local Origin client emulation
│ login, entitlements, persona
├─ Blaze :42127 redirector (TLS) → :42130 game, :42131 nucleus
│ EA's binary Fire2/TDF RPC
│ session, auth, and the CLIENT-CONFIG STORE
├─ UTAS / RS4 :8099 the FUT REST API — JSON/HTTP, ~45 endpoints
│ club, squads, packs, market, matches
└─ POW / EASFC :8094 a third HTTP API (+ :8080 content)
online status, level, credits, catalogue
```
Plus **roster** (:8081), serving an XML file the FUT loading screen blocks on, and
**autopatch**, which patches certificate verification in the running process.
### Redirection, in order of preference
1. **Blaze client-config keys** — the client reads its own service URLs from a key/value
store that Blaze serves. Pointing FUT and EASFC at localhost needs **no root and no
DNS manipulation**. This is the clean mechanism and most redirection uses it.
2. **`/etc/hosts`** — for hostnames baked into the binary.
3. **iptables DNAT** — for one hardcoded IP address.
---
## 4. The wire format — and why it is unforgiving
FUT responses are JSON, but the client does not use a general JSON object model. Each
response class has a hand-written SAX-style deserializer that walks tokens and dispatches
on a **hashed key id** ("atom"). Three consequences dominate the project:
**Atoms.** Every JSON key maps to a 16-bit id via FNV-1a. A recovered table of ~900
id→name pairs is the Rosetta stone. A response spec is really "which atoms does this
deserializer read, of what type".
**Type fidelity is fatal.** A scalar where an object or array is expected does not error —
it **desyncs the reader and hard-freezes the game** in a busy loop. This is the primary
failure mode of the entire project.
**Unknown keys are usually skipped — but not always.** Most deserializers route
unrecognised atoms to a skip handler, making extra fields inert. At least one does not,
so any unexpected key desyncs it.
**Working method:** locate the deserializer, extract its atom set and per-atom getter
types, build the minimal body, and omit nested members whose shape isn't known — omission
is safe, a wrong shape freezes the game.
---
## 5. What works
| Capability | State |
|---|---|
| Boot: Origin → Blaze → FUT hub | ✅ |
| Club identity, coins, W/D/L record | ✅ |
| Active squad — 11 real players, ratings, chemistry | ✅ |
| Squad building — saves and survives relaunch | ✅ |
| Squad roster ("MY SQUADS") | ✅ |
| Transfer market — browse, bid, buy-now, list, watchlist | ✅ |
| Store — buy packs | ✅ |
| Packs — cards land in the club | ✅ via workaround (§6a) |
| Quick sell — credits coins | ✅ |
| Match loop — create/ready/play/destroy + rewards | ⚠️ built, **never requested by the client** (see below) |
| Online/EASFC status bar | ✅ when enabled |
| Seasons, tournaments, leaderboards, champions | ⚠️ routed, **never requested by the client** (see below) |
| Card identity (names, faces, ratings) | ✅ resolves from the game's own local database |
### "Untested" is two different things, and the difference matters
The server log records the User-Agent of every request. The real client identifies as
`ProtoHttp`; this project's own curl and Python probes do not. Separating them shows that
several endpoints previously filed as "built but untested" have in fact **never been
requested by the game at all**, and everything recorded against them was self-inflicted
traffic:
| endpoint | client requests | project probes |
|---|---|---|
| `/leaderboards/options` | 5 | 1 |
| `/clientdata/userHubData` | 13 | 2 |
| `/user/accountinfo` | 23 | 49 |
| `/season`, `/season/user` | **0** | 2 |
| `/tournament`, `/tournament/user` | **0** | 3 |
| `/leaderboards` (bare) | **0** | 2 |
| `/champion` | **0** | 2 |
| `/match` | **0** | 2 |
| `/clubUser` | **0** | 93 |
| `/user/list` | **0** | 180 |
| `/sbs` (SBC), `/draft/mode` | **0** | 0 |
`/clubUser` and `/user/list` are the starkest: 273 requests between them, none from the
game. Work was done on both on the assumption the client wanted them.
A zero in the client column does **not** mean the client never wants that endpoint. In
most cases it means **nobody has navigated to that part of the game yet**. It does mean no
claim about those endpoints has been tested against the client, and any analysis that does
not apply this filter is misleading by default.
**Requirement:** every capture and analysis tool in this project should apply the
User-Agent split by default rather than as an afterthought.
**Design convention.** Every risky change ships behind an environment flag whose default
is whatever is live-proven. This exists because shipping "corrections" on by default broke
two working screens — once freezing the store outright.
---
## 6. Open problems
### 6a. "Send to Club" ends the FUT session — SOLVED 2026-08-04
Opening a pack displayed the cards correctly, but choosing **Send to Club** produced
*"there has been an error connecting to FIFA 17 Ultimate Team"* and a logout, seven
attempts running. The cards always moved correctly server-side; only the
acknowledgement was rejected.
**It was the response body all along.** `PUT ut/%s/item` does not parse an
acknowledgement, it builds per-item **verdict** records, and the completion handler
raises `EVENT_CARDS_MOVE_CARD_FAILURE` when the record vector is empty or when
`success != 1`. Every body this project returned, `{}` included, therefore told the
client the move had failed, and the client ended the FUT session because that is what
that event does. Serving the real shape fixed it in one launch:
```json
{"itemData":[{"id":100000125,"pile":"club","success":true}, ...]}
```
Live result: five cards sent to the club, session survived, cards persisted, no
`ut/delete/auth` logout. Both flags are now defaults and the autoclub workaround is
retired.
**Why it took seven attempts,** which is the part worth keeping: the project had
recorded that this deserializer had *no skip handler* and parsed only two keys. That
was false, produced by searching a **truncated** decompile (the first 4,000 characters
of a 6,193-character function). It implied "the body cannot be the problem", which is
what redirected the investigation to client-side state. The quick-sell asymmetry that
seemed to confirm it has a mundane explanation: quick sell's callbacks read only the
transport status code and never touch the body, so its tolerance of `{}` said nothing
about this endpoint.
The general lesson, now a standing rule: **never conclude an absence from a truncated
or unverified-length extraction**, and treat every negative claim in the endpoint docs
as weaker than the corresponding positive one.
### 6b. "MY CLUB" counter reads 0
The hub shows `MY CLUB 0` despite 99 items. Not the item list (the client *displays* all
99), not the pile-size data (a 16-entry probe changed nothing), not lazy loading (fetched
6 times). Unexplored: the neighbouring `ACTIVE SQUAD` counter works correctly — the
difference between them is likely the answer.
### 6c. Store tiles read "unknown"
`"unknown"` is an unconditional default in a string constructor — the field is never
written. The store renders *display groups*, and that member is parsed recursively by the
same parser; sending it populated **froze the store**, so it is flagged off pending a
correct group schema.
### 6d. Large parts of the game have never been opened
Distinct from 6a to 6c, which are things that misbehave. Per the User-Agent table in
section 5, entire modes have never issued a single client request: Seasons, Tournaments,
FUT Champions, Draft, SBC, and the match loop itself. Their endpoints are routed and their
schemas are reversed, but no claim about any of them has been tested against the game.
This is not a bug list. It is unmeasured surface, and it is the cheapest information
available to the project because most of it costs nothing but navigating menus. It is
recorded here because "routed from a reversed schema" reads like a stronger claim than it
is, and section 7 warns that this project's notes have described things differently from
what is true.
*A multi-agent investigation into 6a and 6b is currently running.*
---
## 7. Notable findings
- **Class → deserializer resolution.** A response class's name literal is preceded by a
4-byte header and the factory points at *the header*. Six attempts failed on that
off-by-four; four returned nothing and were nearly recorded as "no deserializer exists".
- **The URL table is a floor, not a ceiling.** Several real endpoints are built by
appending a suffix at the call site and never appear in the binary's template table.
Only live traffic reveals them — this caught the project three separate times.
- **The project's own documentation has been wrong repeatedly** — fields described as
inert turned out to be parsed, and documented key names didn't match the parsers.
Verify against the decompiler, not the notes.
- **The online layer was hiding in plain sight.** "EA FC servers unreachable" comes from a
third HTTP API in a *loose, unpacked, string-rich* library — not the protected
executable, and not any previously emulated layer. Redirectable purely by config.
- **The main executable is Denuvo-packed**, so its code exists only in a live process.
Live memory is readable, which is how a crash site was disassembled — but logic living
there cannot be reverse engineered statically.
---
## 8. Tooling and quality
- **PyGhidra harness** with decompile / xref / vtable / byte-scan / class-resolution
helpers (Ghidra's own Java scripting is broken on this machine).
- **Minidump reader** — exception record, fault-time registers, module map, stack walk.
- **Live code grabber** — reads and disassembles unpacked code from a running process.
- **Read-only live model probes** for watching client state while playing.
- **Test suites:** 380 live contract checks (type/freeze safety per reversed schema) plus
51 pure unit checks. Both green.
- **Traffic-replay audit** — diffs current responses against a known-good session to prove
a change didn't alter what the client sees.
- **~3,600 lines of RE documentation** across six files, including every eliminated
hypothesis with its supporting evidence.
---
## 9. Roadmap
**Immediate (free, no code):** play a match — the reward loop is built and unit-tested but
has never run in-game. Enable the game-mode endpoints and see whether four more modes
light up.
**Near term:** close the two open problems, most likely via live instrumentation rather
than more static analysis. Implement SBC and Draft (schemas already recovered). Fix the
store display groups properly.
**Longer term:** the stated destination is porting this into the Rust `openfut-core`
behind a FIFA-17 bridge. Everything currently lives in Python prototypes; the
documentation is now good enough to write the port against.
---
## 10. Honest assessment
**What went well.** The FIFA 17 pivot was the decisive call — recognising that an
unprotected binary was worth more than persisting against a hardened one. Blaze, Origin
and the FUT API were all cracked end to end. The freeze-safety test suite has repeatedly
caught regressions before they reached the game.
**What went badly.** Progress has been slowest where fixes were proposed before the
assumption under them was tested. Both open problems absorbed many attempts built on
plausible but unverified theories; several were disproved in a single measurement that
could have been taken first. Two working screens were broken by shipping unverified
"corrections" on by default — which is precisely why the flag convention exists now.
**The most reliable technique** has been comparing a working case against a failing one:
diffing live traffic against a known-good session, and contrasting a succeeding endpoint
with its failing sibling. That has produced more answers than any amount of decompilation.
fifa17-recon/.gitignore
+1
View File
@@ -9,3 +9,4 @@
*.log *.log
__pycache__/ __pycache__/
captures/ captures/
tools/fifa17_profile.json
fifa17-recon/data/club_items.json
+17398
View File
File diff suppressed because it is too large Load Diff
fifa17-recon/data/coach_seeds.json
+416
View File
@@ -0,0 +1,416 @@
{
"_source": "data/tables/*.json dumped read-only from the running client by tools/db_dump.py",
"_key": "resourceId == carddbid, RAW u32 (the staff branches of FUN_180141660 do NOT mask, unlike players)",
"families": {
"headcoach": {
"cardsubtypeid": 5,
"table": "headcoachcards",
"record_4c": 3,
"rowcount": 124,
"carddbid_band": [
2000004,
2000328
],
"absent_ids_in_band": 201,
"miss_fill_assetid": 2000148,
"seeds": [
{
"carddbid": 2000004,
"assetid": 2000004,
"attribute": 0,
"value": 55,
"amount": 5,
"rare": 0
},
{
"carddbid": 2000008,
"assetid": 2000008,
"attribute": 2,
"value": 55,
"amount": 5,
"rare": 0
},
{
"carddbid": 2000016,
"assetid": 2000016,
"attribute": 5,
"value": 55,
"amount": 5,
"rare": 0
},
{
"carddbid": 2000024,
"assetid": 2000024,
"attribute": 4,
"value": 55,
"amount": 5,
"rare": 0
},
{
"carddbid": 2000032,
"assetid": 2000032,
"attribute": 5,
"value": 55,
"amount": 5,
"rare": 0
},
{
"carddbid": 2000044,
"assetid": 2000044,
"attribute": 1,
"value": 64,
"amount": 5,
"rare": 1
},
{
"carddbid": 2000064,
"assetid": 2000064,
"attribute": 1,
"value": 80,
"amount": 15,
"rare": 1
},
{
"carddbid": 2000084,
"assetid": 2000084,
"attribute": 3,
"value": 66,
"amount": 5,
"rare": 0
},
{
"carddbid": 2000124,
"assetid": 2000124,
"attribute": 0,
"value": 70,
"amount": 10,
"rare": 1
},
{
"carddbid": 2000164,
"assetid": 2000164,
"attribute": 1,
"value": 77,
"amount": 10,
"rare": 0
}
],
"bad_controls": [
2000005,
2000089,
2000177,
2000259
]
},
"gkcoach": {
"cardsubtypeid": 6,
"table": "gkcoachcards",
"record_4c": 10,
"rowcount": 121,
"carddbid_band": [
9000001,
9000324
],
"absent_ids_in_band": 203,
"miss_fill_assetid": 9000258,
"seeds": [
{
"carddbid": 9000001,
"assetid": 9000001,
"attribute": 0,
"value": 55,
"amount": 5,
"rare": 0
},
{
"carddbid": 9000017,
"assetid": 9000017,
"attribute": 4,
"value": 55,
"amount": 5,
"rare": 0
},
{
"carddbid": 9000021,
"assetid": 9000021,
"attribute": 5,
"value": 55,
"amount": 5,
"rare": 0
},
{
"carddbid": 9000025,
"assetid": 9000025,
"attribute": 0,
"value": 80,
"amount": 15,
"rare": 1
},
{
"carddbid": 9000037,
"assetid": 9000037,
"attribute": 3,
"value": 64,
"amount": 5,
"rare": 1
},
{
"carddbid": 9000081,
"assetid": 9000081,
"attribute": 2,
"value": 66,
"amount": 5,
"rare": 0
},
{
"carddbid": 9000117,
"assetid": 9000117,
"attribute": 5,
"value": 80,
"amount": 15,
"rare": 1
},
{
"carddbid": 9000121,
"assetid": 9000121,
"attribute": 0,
"value": 75,
"amount": 10,
"rare": 0
},
{
"carddbid": 9000125,
"assetid": 9000125,
"attribute": 1,
"value": 74,
"amount": 10,
"rare": 1
},
{
"carddbid": 9000308,
"assetid": 9000308,
"attribute": 5,
"value": 80,
"amount": 15,
"rare": 1
}
],
"bad_controls": [
9000002,
9000086,
9000174,
9000280
]
},
"physio": {
"cardsubtypeid": 7,
"table": "physiocards",
"record_4c": 5,
"rowcount": 51,
"carddbid_band": [
4000002,
4000259
],
"absent_ids_in_band": 207,
"miss_fill_assetid": 4000146,
"seeds": [
{
"carddbid": 4000002,
"assetid": 4000002,
"attribute": 5,
"value": 55,
"amount": 5,
"rare": 0
},
{
"carddbid": 4000018,
"assetid": 4000018,
"attribute": 6,
"value": 55,
"amount": 5,
"rare": 0
},
{
"carddbid": 4000022,
"assetid": 4000022,
"attribute": 0,
"value": 80,
"amount": 15,
"rare": 1
},
{
"carddbid": 4000026,
"assetid": 4000026,
"attribute": 2,
"value": 55,
"amount": 5,
"rare": 0
},
{
"carddbid": 4000046,
"assetid": 4000046,
"attribute": 3,
"value": 64,
"amount": 5,
"rare": 1
},
{
"carddbid": 4000078,
"assetid": 4000078,
"attribute": 4,
"value": 66,
"amount": 5,
"rare": 0
},
{
"carddbid": 4000122,
"assetid": 4000122,
"attribute": 3,
"value": 74,
"amount": 10,
"rare": 1
},
{
"carddbid": 4000170,
"assetid": 4000170,
"attribute": 1,
"value": 75,
"amount": 10,
"rare": 0
},
{
"carddbid": 4000194,
"assetid": 4000194,
"attribute": 6,
"value": 75,
"amount": 10,
"rare": 0
},
{
"carddbid": 4000254,
"assetid": 4000254,
"attribute": 6,
"value": 80,
"amount": 15,
"rare": 1
}
],
"bad_controls": [
4000003,
4000089,
4000175,
4000257
]
},
"fitnesscoach": {
"cardsubtypeid": 8,
"table": "fitnesscoachcards",
"record_4c": 4,
"rowcount": 115,
"carddbid_band": [
3000019,
3000328
],
"absent_ids_in_band": 195,
"miss_fill_assetid": 3000259,
"seeds": [
{
"carddbid": 3000019,
"assetid": 3000019,
"value": 55,
"amount": 1,
"posbonus": 3,
"fieldpos": 1,
"rare": 0
},
{
"carddbid": 3000023,
"assetid": 3000023,
"value": 55,
"amount": 1,
"posbonus": 5,
"fieldpos": 1,
"rare": 0
},
{
"carddbid": 3000035,
"assetid": 3000035,
"value": 55,
"amount": 1,
"posbonus": 5,
"fieldpos": 0,
"rare": 0
},
{
"carddbid": 3000043,
"assetid": 3000043,
"value": 64,
"amount": 2,
"posbonus": 6,
"fieldpos": 2,
"rare": 1
},
{
"carddbid": 3000047,
"assetid": 3000047,
"value": 64,
"amount": 2,
"posbonus": 2,
"fieldpos": 1,
"rare": 1
},
{
"carddbid": 3000059,
"assetid": 3000059,
"value": 64,
"amount": 2,
"posbonus": 1,
"fieldpos": 0,
"rare": 1
},
{
"carddbid": 3000083,
"assetid": 3000083,
"value": 66,
"amount": 2,
"posbonus": 5,
"fieldpos": 0,
"rare": 0
},
{
"carddbid": 3000091,
"assetid": 3000091,
"value": 80,
"amount": 5,
"posbonus": 5,
"fieldpos": 2,
"rare": 1
},
{
"carddbid": 3000127,
"assetid": 3000127,
"value": 70,
"amount": 3,
"posbonus": 5,
"fieldpos": 1,
"rare": 1
},
{
"carddbid": 3000171,
"assetid": 3000171,
"value": 77,
"amount": 3,
"posbonus": 5,
"fieldpos": 3,
"rare": 0
}
],
"bad_controls": [
3000020,
3000100,
3000178,
3000307
]
}
}
}
fifa17-recon/data/consumables.json
+4438
View File
File diff suppressed because it is too large Load Diff
fifa17-recon/data/memdump/.gitignore
+4
View File
@@ -0,0 +1,4 @@
# Raw /proc/PID/mem captures: regenerate with tools/db_dump.py, never commit.
# One of these directories reached 2.3GB.
data/memdump/*.bin
data/memdump/*.raw
fifa17-recon/data/memdump/index.json
+1400
View File
File diff suppressed because it is too large Load Diff
fifa17-recon/data/player_facts.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/players.json
+5168
View File
File diff suppressed because it is too large Load Diff
fifa17-recon/data/pool.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/positions.json
+61
View File
@@ -0,0 +1,61 @@
{
"20801": 27,
"41236": 25,
"48717": 0,
"48940": 0,
"52091": 7,
"53612": 5,
"53914": 5,
"106231": 25,
"108080": 3,
"112253": 10,
"120533": 5,
"121944": 14,
"137186": 5,
"138956": 5,
"139668": 0,
"139720": 5,
"139968": 0,
"142780": 5,
"142784": 3,
"143745": 14,
"146530": 3,
"146562": 18,
"146954": 14,
"150724": 0,
"152729": 5,
"153244": 25,
"156616": 16,
"157481": 5,
"158121": 0,
"159147": 5,
"161648": 18,
"162240": 14,
"162895": 14,
"163711": 10,
"165153": 25,
"167431": 14,
"168354": 0,
"168651": 14,
"171877": 14,
"172879": 5,
"175943": 27,
"176769": 25,
"177413": 14,
"177610": 5,
"178509": 25,
"179783": 0,
"179944": 5,
"181458": 16,
"182494": 0,
"183497": 0,
"184144": 16,
"184432": 7,
"185239": 5,
"188152": 18,
"189125": 16,
"189461": 14,
"189560": 10,
"190547": 5,
"191740": 14
}
fifa17-recon/data/positions_curated.json
+19
View File
@@ -0,0 +1,19 @@
{
"155862": "CB",
"158023": "RW",
"167495": "GK",
"176580": "ST",
"177003": "CM",
"182521": "CM",
"183277": "LM",
"183907": "CB",
"184941": "CB",
"188545": "ST",
"189332": "LB",
"190871": "LW",
"192985": "RM",
"197445": "LB",
"200389": "GK",
"202126": "ST",
"20801": "LW"
}
fifa17-recon/data/roster.json
+122831
View File
File diff suppressed because it is too large Load Diff
fifa17-recon/data/tables/BigAttendance.json
+1
View File
@@ -0,0 +1 @@
{"table":"BigAttendance","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":7,"rowsize_bytes":4,"rows_emitted":7,"rowblock":"0x7be0210","rowblock_bytes":104,"descriptor":"0x7bf0848","schema":[{"name":"max","bit":0,"width":4,"kind":"int","min":0,"max":10,"storage":"int"},{"name":"emotion","bit":4,"width":3,"kind":"int","min":0,"max":6,"storage":"int"},{"name":"min","bit":7,"width":4,"kind":"int","min":0,"max":10,"storage":"int"}],"rows":[{"max":6,"emotion":0,"min":0},{"max":6,"emotion":1,"min":0},{"max":7,"emotion":2,"min":0},{"max":7,"emotion":3,"min":0},{"max":10,"emotion":4,"min":1},{"max":9,"emotion":5,"min":1},{"max":9,"emotion":6,"min":1}]}
fifa17-recon/data/tables/MatchIntensity.json
+1
View File
@@ -0,0 +1 @@
{"table":"MatchIntensity","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":9,"rowsize_bytes":4,"rows_emitted":9,"rowblock":"0x7c31058","rowblock_bytes":0,"descriptor":"0x42e9a3a8","schema":[{"name":"scorediff","bit":0,"width":4,"kind":"int","min":-4,"max":4,"storage":"int"},{"name":"time60","bit":4,"width":2,"kind":"int","min":-1,"max":2,"storage":"int"},{"name":"time90","bit":6,"width":2,"kind":"int","min":-1,"max":2,"storage":"int"},{"name":"time120","bit":8,"width":3,"kind":"int","min":-1,"max":3,"storage":"int"},{"name":"time75","bit":11,"width":3,"kind":"int","min":-1,"max":3,"storage":"int"},{"name":"time45","bit":14,"width":2,"kind":"int","min":-1,"max":2,"storage":"int"},{"name":"time30","bit":16,"width":2,"kind":"int","min":-1,"max":2,"storage":"int"},{"name":"time15","bit":18,"width":2,"kind":"int","min":-1,"max":2,"storage":"int"}],"rows":[{"scorediff":-4,"time60":-1,"time90":-1,"time120":-1,"time75":-1,"time45":-1,"time30":-1,"time15":-1},{"scorediff":-3,"time60":0,"time90":-1,"time120":-1,"time75":0,"time45":0,"time30":-1,"time15":-1},{"scorediff":-2,"time60":1,"time90":-1,"time120":0,"time75":0,"time45":0,"time30":0,"time15":-1},{"scorediff":-1,"time60":-1,"time90":2,"time120":3,"time75":3,"time45":1,"time30":0,"time15":1},{"scorediff":0,"time60":-1,"time90":2,"time120":3,"time75":3,"time45":0,"time30":-1,"time15":0},{"scorediff":1,"time60":0,"time90":1,"time120":2,"time75":2,"time45":1,"time30":0,"time15":1},{"scorediff":2,"time60":0,"time90":0,"time120":0,"time75":1,"time45":1,"time30":1,"time15":2},{"scorediff":3,"time60":-1,"time90":0,"time120":0,"time75":0,"time45":-1,"time30":-1,"time15":0},{"scorediff":4,"time60":0,"time90":0,"time120":-1,"time75":-1,"time45":0,"time30":-1,"time15":-1}]}
fifa17-recon/data/tables/NoAttendance.json
+1
View File
@@ -0,0 +1 @@
{"table":"NoAttendance","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":7,"rowsize_bytes":4,"rows_emitted":7,"rowblock":"0x7be01e8","rowblock_bytes":114,"descriptor":"0x7bf0f08","schema":[{"name":"max","bit":0,"width":4,"kind":"int","min":0,"max":10,"storage":"int"},{"name":"emotion","bit":4,"width":3,"kind":"int","min":0,"max":6,"storage":"int"},{"name":"min","bit":7,"width":4,"kind":"int","min":0,"max":10,"storage":"int"}],"rows":[{"max":7,"emotion":0,"min":0},{"max":8,"emotion":1,"min":0},{"max":9,"emotion":2,"min":0},{"max":9,"emotion":3,"min":0},{"max":10,"emotion":4,"min":1},{"max":9,"emotion":5,"min":1},{"max":8,"emotion":6,"min":0}]}
fifa17-recon/data/tables/assetcryptokeys.json
+1
View File
@@ -0,0 +1 @@
{"table":"assetcryptokeys","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":0,"rowsize_bytes":44,"rows_emitted":0,"rowblock":"0x42750c68","rowblock_bytes":3553,"descriptor":"0x7bf0e48","schema":[{"name":"key","bit":0,"width":256,"kind":"string","min":0,"max":0,"storage":"inline-string"},{"name":"keyid","bit":256,"width":64,"kind":"string","min":0,"max":0,"storage":"inline-string"},{"name":"artificialkey","bit":320,"width":7,"kind":"int","min":0,"max":127,"storage":"int"}],"rows":[]}
fifa17-recon/data/tables/attributeprefpositionformula.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/audionation.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/audiostadium.json
+1
View File
@@ -0,0 +1 @@
{"table":"audiostadium","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":86,"rowsize_bytes":4,"rows_emitted":86,"rowblock":"0x42e9a4c8","rowblock_bytes":369,"descriptor":"0x7b57908","schema":[{"name":"stadiumpalanguageindex","bit":0,"width":6,"kind":"int","min":-1,"max":31,"storage":"int"},{"name":"stadiumid","bit":6,"width":9,"kind":"int","min":0,"max":511,"storage":"int"}],"rows":[{"stadiumpalanguageindex":0,"stadiumid":1},{"stadiumpalanguageindex":4,"stadiumid":2},{"stadiumpalanguageindex":3,"stadiumid":5},{"stadiumpalanguageindex":2,"stadiumid":9},{"stadiumpalanguageindex":4,"stadiumid":10},{"stadiumpalanguageindex":0,"stadiumid":13},{"stadiumpalanguageindex":1,"stadiumid":14},{"stadiumpalanguageindex":7,"stadiumid":15},{"stadiumpalanguageindex":-1,"stadiumid":26},{"stadiumpalanguageindex":0,"stadiumid":28},{"stadiumpalanguageindex":1,"stadiumid":29},{"stadiumpalanguageindex":2,"stadiumid":30},{"stadiumpalanguageindex":-1,"stadiumid":32},{"stadiumpalanguageindex":-1,"stadiumid":33},{"stadiumpalanguageindex":-1,"stadiumid":34},{"stadiumpalanguageindex":-1,"stadiumid":35},{"stadiumpalanguageindex":2,"stadiumid":41},{"stadiumpalanguageindex":4,"stadiumid":42},{"stadiumpalanguageindex":0,"stadiumid":100},{"stadiumpalanguageindex":13,"stadiumid":104},{"stadiumpalanguageindex":0,"stadiumid":112},{"stadiumpalanguageindex":0,"stadiumid":113},{"stadiumpalanguageindex":0,"stadiumid":115},{"stadiumpalanguageindex":0,"stadiumid":116},{"stadiumpalanguageindex":2,"stadiumid":135},{"stadiumpalanguageindex":2,"stadiumid":137},{"stadiumpalanguageindex":-1,"stadiumid":147},{"stadiumpalanguageindex":-1,"stadiumid":149},{"stadiumpalanguageindex":-1,"stadiumid":153},{"stadiumpalanguageindex":0,"stadiumid":155},{"stadiumpalanguageindex":0,"stadiumid":156},{"stadiumpalanguageindex":3,"stadiumid":157},{"stadiumpalanguageindex":-1,"stadiumid":158},{"stadiumpalanguageindex":-1,"stadiumid":172},{"stadiumpalanguageindex":-1,"stadiumid":175},{"stadiumpalanguageindex":-1,"stadiumid":176},{"stadiumpalanguageindex":-1,"stadiumid":178},{"stadiumpalanguageindex":-1,"stadiumid":179},{"stadiumpalanguageindex":-1,"stadiumid":180},{"stadiumpalanguageindex":-1,"stadiumid":181},{"stadiumpalanguageindex":-1,"stadiumid":182},{"stadiumpalanguageindex":-1,"stadiumid":183},{"stadiumpalanguageindex":-1,"stadiumid":192},{"stadiumpalanguageindex":-1,"stadiumid":193},{"stadiumpalanguageindex":-1,"stadiumid":194},{"stadiumpalanguageindex":-1,"stadiumid":195},{"stadiumpalanguageindex":-1,"stadiumid":196},{"stadiumpalanguageindex":-1,"stadiumid":197},{"stadiumpalanguageindex":-1,"stadiumid":212},{"stadiumpalanguageindex":-1,"stadiumid":228},{"stadiumpalanguageindex":-1,"stadiumid":229},{"stadiumpalanguageindex":0,"stadiumid":246},{"stadiumpalanguageindex":3,"stadiumid":247},{"stadiumpalanguageindex":0,"stadiumid":248},{"stadiumpalanguageindex":-1,"stadiumid":249},{"stadiumpalanguageindex":0,"stadiumid":260},{"stadiumpalanguageindex":-1,"stadiumid":261},{"stadiumpalanguageindex":-1,"stadiumid":262},{"stadiumpalanguageindex":14,"stadiumid":264},{"stadiumpalanguageindex":0,"stadiumid":265},{"stadiumpalanguageindex":-1,"stadiumid":316},{"stadiumpalanguageindex":0,"stadiumid":326},{"stadiumpalanguageindex":0,"stadiumid":327},{"stadiumpalanguageindex":0,"stadiumid":329},{"stadiumpalanguageindex":0,"stadiumid":330},{"stadiumpalanguageindex":0,"stadiumid":331},{"stadiumpalanguageindex":0,"stadiumid":332},{"stadiumpalanguageindex":0,"stadiumid":333},{"stadiumpalanguageindex":0,"stadiumid":335},{"stadiumpalanguageindex":0,"stadiumid":336},{"stadiumpalanguageindex":0,"stadiumid":337},{"stadiumpalanguageindex":0,"stadiumid":341},{"stadiumpalanguageindex":2,"stadiumid":343},{"stadiumpalanguageindex":14,"stadiumid":344},{"stadiumpalanguageindex":-1,"stadiumid":345},{"stadiumpalanguageindex":0,"stadiumid":347},{"stadiumpalanguageindex":0,"stadiumid":348},{"stadiumpalanguageindex":0,"stadiumid":349},{"stadiumpalanguageindex":-1,"stadiumid":352},{"stadiumpalanguageindex":-1,"stadiumid":353},{"stadiumpalanguageindex":17,"stadiumid":354},{"stadiumpalanguageindex":0,"stadiumid":355},{"stadiumpalanguageindex":-1,"stadiumid":357},{"stadiumpalanguageindex":-1,"stadiumid":358},{"stadiumpalanguageindex":-1,"stadiumid":359},{"stadiumpalanguageindex":-1,"stadiumid":360}]}
fifa17-recon/data/tables/career_calendar.json
+1
View File
@@ -0,0 +1 @@
{"table":"career_calendar","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":1,"rowsize_bytes":20,"rows_emitted":1,"rowblock":"0x7c20708","rowblock_bytes":0,"descriptor":"0x4254fc28","schema":[{"name":"transferwindowend1","bit":0,"width":11,"kind":"int","min":101,"max":1231,"storage":"int"},{"name":"transferwindowstart1","bit":11,"width":11,"kind":"int","min":101,"max":1231,"storage":"int"},{"name":"transferwindowend2","bit":22,"width":11,"kind":"int","min":101,"max":1231,"storage":"int"},{"name":"setupdate","bit":33,"width":19,"kind":"int","min":20080101,"max":20601231,"storage":"int"},{"name":"dateid","bit":52,"width":1,"kind":"int","min":0,"max":1,"storage":"int"},{"name":"enddate","bit":53,"width":19,"kind":"int","min":20080101,"max":20601231,"storage":"int"},{"name":"currdate","bit":72,"width":19,"kind":"int","min":20080101,"max":20601231,"storage":"int"},{"name":"startdate","bit":91,"width":19,"kind":"int","min":20080101,"max":20601231,"storage":"int"},{"name":"transferwindowstart2","bit":110,"width":11,"kind":"int","min":101,"max":1231,"storage":"int"},{"name":"objectivecheckdate","bit":121,"width":19,"kind":"int","min":20080101,"max":20601231,"storage":"int"}],"rows":[{"transferwindowend1":831,"transferwindowstart1":701,"transferwindowend2":131,"setupdate":20080101,"dateid":0,"enddate":20080101,"currdate":20080101,"startdate":20080101,"transferwindowstart2":101,"objectivecheckdate":20080101}]}
fifa17-recon/data/tables/career_clinchedobjectives.json
+1
View File
@@ -0,0 +1 @@
{"table":"career_clinchedobjectives","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":0,"rowsize_bytes":20,"rows_emitted":0,"rowblock":"0x42e982a8","rowblock_bytes":513,"descriptor":"0x7b102a8","schema":[{"name":"predictedclinchfordrawflags","bit":0,"width":31,"kind":"int","min":0,"max":2147483520,"storage":"int"},{"name":"clinchedobjectivesflags","bit":31,"width":31,"kind":"int","min":0,"max":2147483520,"storage":"int"},{"name":"predictedclinchforwinflags","bit":62,"width":31,"kind":"int","min":0,"max":2147483520,"storage":"int"},{"name":"teamid","bit":93,"width":18,"kind":"int","min":-1,"max":200000,"storage":"int"},{"name":"predictedclinchforlossflags","bit":111,"width":31,"kind":"int","min":0,"max":2147483520,"storage":"int"}],"rows":[]}
fifa17-recon/data/tables/career_commonnames.json
+1
View File
@@ -0,0 +1 @@
{"table":"career_commonnames","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":0,"rowsize_bytes":8,"rows_emitted":0,"rowblock":"0x0","rowblock_bytes":null,"descriptor":"0x7b408f8","schema":[{"name":"firstname","bit":0,"width":15,"kind":"int","min":0,"max":29999,"storage":"int"},{"name":"lastname","bit":15,"width":15,"kind":"int","min":0,"max":29999,"storage":"int"},{"name":"groupid","bit":30,"width":7,"kind":"int","min":0,"max":127,"storage":"int"},{"name":"commonnameid","bit":37,"width":10,"kind":"int","min":1,"max":1024,"storage":"int"}],"rows":[]}
fifa17-recon/data/tables/career_firstnames.json
+1
View File
@@ -0,0 +1 @@
{"table":"career_firstnames","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":0,"rowsize_bytes":8,"rows_emitted":0,"rowblock":"0x0","rowblock_bytes":null,"descriptor":"0x7bf0c08","schema":[{"name":"firstnameid","bit":0,"width":12,"kind":"int","min":1,"max":4096,"storage":"int"},{"name":"firstname","bit":12,"width":15,"kind":"int","min":0,"max":29999,"storage":"int"},{"name":"groupid","bit":27,"width":7,"kind":"int","min":0,"max":127,"storage":"int"}],"rows":[]}
fifa17-recon/data/tables/career_lastnames.json
+1
View File
@@ -0,0 +1 @@
{"table":"career_lastnames","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":0,"rowsize_bytes":8,"rows_emitted":0,"rowblock":"0x0","rowblock_bytes":null,"descriptor":"0x7bf12c8","schema":[{"name":"lastname","bit":0,"width":15,"kind":"int","min":0,"max":29999,"storage":"int"},{"name":"lastnameid","bit":15,"width":12,"kind":"int","min":1,"max":4096,"storage":"int"},{"name":"groupid","bit":27,"width":7,"kind":"int","min":0,"max":127,"storage":"int"}],"rows":[]}
fifa17-recon/data/tables/career_playerlastmatchhistory.json
+1
View File
@@ -0,0 +1 @@
{"table":"career_playerlastmatchhistory","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":0,"rowsize_bytes":12,"rows_emitted":0,"rowblock":"0x42521898","rowblock_bytes":120033,"descriptor":"0x7ba3408","schema":[{"name":"minsplayed","bit":0,"width":8,"kind":"int","min":0,"max":150,"storage":"int"},{"name":"position","bit":8,"width":6,"kind":"int","min":-1,"max":50,"storage":"int"},{"name":"artificialkey","bit":14,"width":19,"kind":"int","min":0,"max":300000,"storage":"int"},{"name":"playerfact","bit":33,"width":5,"kind":"int","min":-1,"max":15,"storage":"int"},{"name":"teamid","bit":38,"width":18,"kind":"int","min":-1,"max":200000,"storage":"int"},{"name":"playeroverall","bit":56,"width":7,"kind":"int","min":-1,"max":100,"storage":"int"},{"name":"playerid","bit":63,"width":19,"kind":"int","min":-1,"max":300000,"storage":"int"}],"rows":[]}
fifa17-recon/data/tables/career_playermatchratinghistory.json
+1
View File
@@ -0,0 +1 @@
{"table":"career_playermatchratinghistory","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":0,"rowsize_bytes":12,"rows_emitted":0,"rowblock":"0x42493f28","rowblock_bytes":7585,"descriptor":"0x7b205a8","schema":[{"name":"minsplayed","bit":0,"width":8,"kind":"int","min":-1,"max":140,"storage":"int"},{"name":"position","bit":8,"width":5,"kind":"int","min":0,"max":31,"storage":"int"},{"name":"date","bit":13,"width":19,"kind":"int","min":20080101,"max":20601231,"storage":"int"},{"name":"artificialkey","bit":32,"width":19,"kind":"int","min":0,"max":300000,"storage":"int"},{"name":"rating","bit":51,"width":7,"kind":"int","min":-1,"max":100,"storage":"int"},{"name":"playerid","bit":58,"width":19,"kind":"int","min":0,"max":300000,"storage":"int"}],"rows":[]}
fifa17-recon/data/tables/career_squadranking.json
+1
View File
@@ -0,0 +1 @@
{"table":"career_squadranking","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":0,"rowsize_bytes":8,"rows_emitted":0,"rowblock":"0x42e97c18","rowblock_bytes":449,"descriptor":"0x7bf0488","schema":[{"name":"curroverall","bit":0,"width":10,"kind":"int","min":0,"max":1000,"storage":"int"},{"name":"playerid","bit":10,"width":19,"kind":"int","min":-1,"max":300000,"storage":"int"},{"name":"lastoverall","bit":29,"width":10,"kind":"int","min":0,"max":1000,"storage":"int"}],"rows":[]}
fifa17-recon/data/tables/celebrations.json
+1
View File
@@ -0,0 +1 @@
{"table":"celebrations","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":13,"rowsize_bytes":4,"rows_emitted":13,"rowblock":"0x7bc3088","rowblock_bytes":5,"descriptor":"0x7b701e8","schema":[{"name":"celebrationid","bit":0,"width":4,"kind":"int","min":0,"max":13,"storage":"int"}],"rows":[{"celebrationid":0},{"celebrationid":1},{"celebrationid":2},{"celebrationid":3},{"celebrationid":4},{"celebrationid":5},{"celebrationid":6},{"celebrationid":7},{"celebrationid":8},{"celebrationid":9},{"celebrationid":10},{"celebrationid":11},{"celebrationid":12}]}
fifa17-recon/data/tables/clubcommentarynames.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/commentarynames.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/competition.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/competitionsponsorlinks.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/createclubnames.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/createplayer.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/createplayerpositiontemplates.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/createplayerviews.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/customformations.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/customteamstyles.json
+1
View File
@@ -0,0 +1 @@
{"table":"customteamstyles","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":0,"rowsize_bytes":12,"rows_emitted":0,"rowblock":"0x4254bdf8","rowblock_bytes":369,"descriptor":"0x42816ee8","schema":[{"name":"defmentality","bit":0,"width":7,"kind":"int","min":1,"max":100,"storage":"int"},{"name":"teamstyleid","bit":7,"width":7,"kind":"int","min":900,"max":1000,"storage":"int"},{"name":"basestyle","bit":14,"width":18,"kind":"int","min":-2,"max":200000,"storage":"int"},{"name":"buspassing","bit":32,"width":7,"kind":"int","min":1,"max":100,"storage":"int"},{"name":"defteamwidth","bit":39,"width":7,"kind":"int","min":1,"max":100,"storage":"int"},{"name":"busdribbling","bit":46,"width":7,"kind":"int","min":1,"max":100,"storage":"int"},{"name":"defaggression","bit":53,"width":7,"kind":"int","min":1,"max":100,"storage":"int"},{"name":"buspositioning","bit":60,"width":1,"kind":"int","min":1,"max":2,"storage":"int"},{"name":"ccpositioning","bit":61,"width":1,"kind":"int","min":1,"max":2,"storage":"int"},{"name":"busbuildupspeed","bit":62,"width":7,"kind":"int","min":1,"max":100,"storage":"int"},{"name":"ccshooting","bit":69,"width":7,"kind":"int","min":1,"max":100,"storage":"int"},{"name":"ccpassing","bit":76,"width":7,"kind":"int","min":1,"max":100,"storage":"int"},{"name":"defdefenderline","bit":83,"width":1,"kind":"int","min":1,"max":2,"storage":"int"},{"name":"cccrossing","bit":84,"width":7,"kind":"int","min":1,"max":100,"storage":"int"}],"rows":[]}
fifa17-recon/data/tables/cz_assets.json
+1
View File
@@ -0,0 +1 @@
{"table":"cz_assets","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":0,"rowsize_bytes":248,"rows_emitted":0,"rowblock":"0x427ce458","rowblock_bytes":26817,"descriptor":"0x4254ffa8","schema":[{"name":"crestid","bit":0,"width":32,"kind":"int","min":-2147483648,"max":2147483647,"storage":"int"},{"name":"dbid","bit":32,"width":32,"kind":"int","min":-2147483648,"max":2147483647,"storage":"int"},{"name":"publishdate","bit":64,"width":32,"kind":"int","min":-2147483648,"max":2147483647,"storage":"int"},{"name":"rating","bit":96,"width":32,"kind":"unknown","min":0,"max":0,"storage":"int"},{"name":"kitid","bit":128,"width":32,"kind":"int","min":-2147483648,"max":2147483647,"storage":"int"},{"name":"xms_media_id","bit":160,"width":32,"kind":"int","min":-2147483648,"max":2147483647,"storage":"int"},{"name":"type","bit":192,"width":32,"kind":"int","min":-2147483648,"max":2147483647,"storage":"int"},{"name":"author","bit":224,"width":720,"kind":"string","min":0,"max":0,"storage":"inline-string"},{"name":"assetname","bit":944,"width":1008,"kind":"string","min":0,"max":0,"storage":"inline-string"},{"name":"assetyear","bit":1952,"width":4,"kind":"int","min":0,"max":15,"storage":"int"},{"name":"playerposition","bit":1956,"width":6,"kind":"int","min":0,"max":50,"storage":"int"},{"name":"version","bit":1962,"width":15,"kind":"int","min":0,"max":30000,"storage":"int"}],"rows":[]}
fifa17-recon/data/tables/cz_leagues.json
+1
View File
@@ -0,0 +1 @@
{"table":"cz_leagues","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":0,"rowsize_bytes":164,"rows_emitted":0,"rowblock":"0x424a1908","rowblock_bytes":849,"descriptor":"0x424af898","schema":[{"name":"overlaybgcolour3r","bit":0,"width":8,"kind":"int","min":0,"max":255,"storage":"int"},{"name":"tournamentballid","bit":8,"width":8,"kind":"int","min":0,"max":255,"storage":"int"},{"name":"overlaytextcolour3r","bit":16,"width":8,"kind":"int","min":0,"max":255,"storage":"int"},{"name":"overlaytextcolour1g","bit":24,"width":8,"kind":"int","min":0,"max":255,"storage":"int"},{"name":"overlaytextcolour3b","bit":32,"width":8,"kind":"int","min":0,"max":255,"storage":"int"},{"name":"overlaybgcolour1g","bit":40,"width":8,"kind":"int","min":0,"max":255,"storage":"int"},{"name":"championcupslotallotment","bit":48,"width":8,"kind":"int","min":0,"max":255,"storage":"int"},{"name":"overlaybgcolour3b","bit":56,"width":8,"kind":"int","min":0,"max":255,"storage":"int"},{"name":"finalstadiumid","bit":64,"width":8,"kind":"int","min":0,"max":255,"storage":"int"},{"name":"overlaytextcolour2b","bit":72,"width":8,"kind":"int","min":0,"max":255,"storage":"int"},{"name":"overlaybgcolour1r","bit":80,"width":8,"kind":"int","min":0,"max":255,"storage":"int"},{"name":"overlaybgcolour2b","bit":88,"width":8,"kind":"int","min":0,"max":255,"storage":"int"},{"name":"overlaytextcolour1r","bit":96,"width":8,"kind":"int","min":0,"max":255,"storage":"int"},{"name":"overlaytextcolour3g","bit":104,"width":8,"kind":"int","min":0,"max":255,"storage":"int"},{"name":"overlaytextcolour1b","bit":112,"width":8,"kind":"int","min":0,"max":255,"storage":"int"},{"name":"overlaybgcolour3g","bit":120,"width":8,"kind":"int","min":0,"max":255,"storage":"int"},{"name":"overlaybgcolour1b","bit":128,"width":8,"kind":"int","min":0,"max":255,"storage":"int"},{"name":"overlaybgcolour2r","bit":136,"width":8,"kind":"int","min":0,"max":255,"storage":"int"},{"name":"overlaytextcolour2g","bit":144,"width":8,"kind":"int","min":0,"max":255,"storage":"int"},{"name":"eurocupslotallotment","bit":152,"width":8,"kind":"int","min":0,"max":255,"storage":"int"},{"name":"overlaytextcolour2r","bit":160,"width":8,"kind":"int","min":0,"max":255,"storage":"int"},{"name":"overlaybgcolour2g","bit":168,"width":8,"kind":"int","min":0,"max":255,"storage":"int"},{"name":"leaguedescription","bit":176,"width":1080,"kind":"string","min":0,"max":0,"storage":"inline-string"},{"name":"leaguetype","bit":1256,"width":2,"kind":"int","min":0,"max":2,"storage":"int"},{"name":"numteams","bit":1258,"width":6,"kind":"int","min":0,"max":32,"storage":"int"},{"name":"trophyid","bit":1264,"width":9,"kind":"int","min":-1,"max":255,"storage":"int"},{"name":"teamadvancingpergroup","bit":1273,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"leagueid","bit":1276,"width":12,"kind":"int","min":1,"max":3000,"storage":"int"},{"name":"fixturevsgroup","bit":1288,"width":2,"kind":"int","min":0,"max":2,"storage":"int"},{"name":"teampergroup","bit":1290,"width":5,"kind":"int","min":0,"max":16,"storage":"int"},{"name":"finalmatchlegs","bit":1295,"width":2,"kind":"int","min":0,"max":2,"storage":"int"},{"name":"fixturevseachteam","bit":1297,"width":2,"kind":"int","min":0,"max":2,"storage":"int"},{"name":"subonbench","bit":1299,"width":3,"kind":"int","min":0,"max":7,"storage":"int"}],"rows":[]}
fifa17-recon/data/tables/cz_players.json
+1
View File
@@ -0,0 +1 @@
{"table":"cz_players","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":0,"rowsize_bytes":8,"rows_emitted":0,"rowblock":"0x42614398","rowblock_bytes":12033,"descriptor":"0x7bf0608","schema":[{"name":"assetid","bit":0,"width":19,"kind":"int","min":0,"max":300000,"storage":"int"},{"name":"commentaryid","bit":19,"width":20,"kind":"int","min":-1,"max":1000000,"storage":"int"},{"name":"playerid","bit":39,"width":19,"kind":"int","min":0,"max":300000,"storage":"int"}],"rows":[]}
fifa17-recon/data/tables/cz_teamkits.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/cz_teams.json
+1
View File
@@ -0,0 +1 @@
{"table":"cz_teams","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":0,"rowsize_bytes":24,"rows_emitted":0,"rowblock":"0x4254c208","rowblock_bytes":1473,"descriptor":"0x7b110a8","schema":[{"name":"hascrestimage","bit":0,"width":32,"kind":"int","min":-2147483648,"max":2147483647,"storage":"int"},{"name":"hassponsorimage","bit":32,"width":32,"kind":"int","min":-2147483648,"max":2147483647,"storage":"int"},{"name":"teamabbrev3","bit":64,"width":72,"kind":"string","min":0,"max":0,"storage":"inline-string"},{"name":"teamid","bit":136,"width":18,"kind":"int","min":0,"max":200000,"storage":"int"},{"name":"commentaryid","bit":154,"width":20,"kind":"int","min":-1,"max":1000000,"storage":"int"}],"rows":[]}
fifa17-recon/data/tables/dcplayernames.json
+1
View File
@@ -0,0 +1 @@
{"table":"dcplayernames","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":0,"rowsize_bytes":40,"rows_emitted":0,"rowblock":"0x426df378","rowblock_bytes":200032,"descriptor":"0x7b579b8","schema":[{"name":"name","bit":0,"width":304,"kind":"string","min":0,"max":0,"storage":"inline-string"},{"name":"nameid","bit":304,"width":13,"kind":"int","min":30000,"max":35000,"storage":"int"}],"rows":[]}
fifa17-recon/data/tables/default_teamsheets.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/defaultteamdata.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/defformation.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/dlcballs.json
+1
View File
@@ -0,0 +1 @@
{"table":"dlcballs","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":0,"rowsize_bytes":52,"rows_emitted":0,"rowblock":"0x424a0528","rowblock_bytes":2625,"descriptor":"0x7b576f8","schema":[{"name":"name","bit":0,"width":400,"kind":"string","min":0,"max":0,"storage":"inline-string"},{"name":"assetid","bit":400,"width":11,"kind":"int","min":0,"max":2000,"storage":"int"}],"rows":[]}
fifa17-recon/data/tables/dlcboots.json
+1
View File
@@ -0,0 +1 @@
{"table":"dlcboots","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":0,"rowsize_bytes":52,"rows_emitted":0,"rowblock":"0x424980e8","rowblock_bytes":2624,"descriptor":"0x7b57dd8","schema":[{"name":"name","bit":0,"width":400,"kind":"string","min":0,"max":0,"storage":"inline-string"},{"name":"assetid","bit":400,"width":11,"kind":"int","min":0,"max":2000,"storage":"int"}],"rows":[]}
fifa17-recon/data/tables/dna.json
+1
View File
@@ -0,0 +1 @@
{"table":"dna","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":0,"rowsize_bytes":260,"rows_emitted":0,"rowblock":"0x0","rowblock_bytes":null,"descriptor":"0x7b57b18","schema":[{"name":"dna","bit":0,"width":2040,"kind":"string","min":0,"max":0,"storage":"inline-string"},{"name":"playerid","bit":2040,"width":19,"kind":"int","min":0,"max":300000,"storage":"int"}],"rows":[]}
fifa17-recon/data/tables/dynamicimages.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/eatrax.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/editedplayernames.json
+1
View File
@@ -0,0 +1 @@
{"table":"editedplayernames","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":0,"rowsize_bytes":184,"rows_emitted":0,"rowblock":"0x42a7f108","rowblock_bytes":281553,"descriptor":"0x7b10b68","schema":[{"name":"firstname","bit":0,"width":360,"kind":"string","min":0,"max":0,"storage":"inline-string"},{"name":"commonname","bit":360,"width":360,"kind":"string","min":0,"max":0,"storage":"inline-string"},{"name":"playerjerseyname","bit":720,"width":360,"kind":"string","min":0,"max":0,"storage":"inline-string"},{"name":"surname","bit":1080,"width":360,"kind":"string","min":0,"max":0,"storage":"inline-string"},{"name":"playerid","bit":1440,"width":19,"kind":"int","min":0,"max":300000,"storage":"int"}],"rows":[]}
fifa17-recon/data/tables/factory_teams.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/fcc_GrandStandPlayers.json
+1
View File
@@ -0,0 +1 @@
{"table":"fcc_GrandStandPlayers","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":113,"rowsize_bytes":4,"rows_emitted":113,"rowblock":"0x424b4358","rowblock_bytes":481,"descriptor":"0x7988528","schema":[{"name":"playerid","bit":0,"width":19,"kind":"int","min":0,"max":300000,"storage":"int"}],"rows":[{"playerid":1},{"playerid":41},{"playerid":51},{"playerid":195},{"playerid":240},{"playerid":241},{"playerid":244},{"playerid":246},{"playerid":388},{"playerid":393},{"playerid":570},{"playerid":805},{"playerid":942},{"playerid":1025},{"playerid":1040},{"playerid":1041},{"playerid":1075},{"playerid":1088},{"playerid":1109},{"playerid":1116},{"playerid":1183},{"playerid":1198},{"playerid":1201},{"playerid":1419},{"playerid":1605},{"playerid":1620},{"playerid":1845},{"playerid":4000},{"playerid":4202},{"playerid":4833},{"playerid":5419},{"playerid":5467},{"playerid":5589},{"playerid":5673},{"playerid":5680},{"playerid":5681},{"playerid":6235},{"playerid":6975},{"playerid":7289},{"playerid":7512},{"playerid":7518},{"playerid":7743},{"playerid":9014},{"playerid":10264},{"playerid":13038},{"playerid":13128},{"playerid":20170},{"playerid":20801},{"playerid":41236},{"playerid":46747},{"playerid":51539},{"playerid":52241},{"playerid":53769},{"playerid":117106},{"playerid":121939},{"playerid":146530},{"playerid":153079},{"playerid":155862},{"playerid":156353},{"playerid":156616},{"playerid":158023},{"playerid":161840},{"playerid":162895},{"playerid":164000},{"playerid":164240},{"playerid":166120},{"playerid":166124},{"playerid":166906},{"playerid":167495},{"playerid":168473},{"playerid":168542},{"playerid":173731},{"playerid":176580},{"playerid":176635},{"playerid":176676},{"playerid":177003},{"playerid":177845},{"playerid":181872},{"playerid":182521},{"playerid":183277},{"playerid":183898},{"playerid":183907},{"playerid":184941},{"playerid":188350},{"playerid":188545},{"playerid":189332},{"playerid":189511},{"playerid":190043},{"playerid":190044},{"playerid":190053},{"playerid":190871},{"playerid":191189},{"playerid":191695},{"playerid":192119},{"playerid":192181},{"playerid":192883},{"playerid":192985},{"playerid":193080},{"playerid":195864},{"playerid":197445},{"playerid":198710},{"playerid":214098},{"playerid":214100},{"playerid":214101},{"playerid":214267},{"playerid":214649},{"playerid":215558},{"playerid":215732},{"playerid":222000},{"playerid":222257},{"playerid":222481},{"playerid":222680},{"playerid":226764}]}
fifa17-recon/data/tables/fcc_badgecards.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/fcc_balls.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/fcc_bonusvalues.json
+1
View File
@@ -0,0 +1 @@
{"table":"fcc_bonusvalues","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":12,"rowsize_bytes":8,"rows_emitted":12,"rowblock":"0x77e13b8","rowblock_bytes":1919903238,"descriptor":"0x7b401a8","schema":[{"name":"bonusvalue","bit":0,"width":32,"kind":"unknown","min":0,"max":0,"storage":"int"},{"name":"bonuslevel","bit":32,"width":8,"kind":"int","min":0,"max":255,"storage":"int"},{"name":"bonustype","bit":40,"width":8,"kind":"int","min":0,"max":255,"storage":"int"},{"name":"bonusid","bit":48,"width":8,"kind":"int","min":0,"max":255,"storage":"int"}],"rows":[{"bonusvalue":0,"bonuslevel":0,"bonustype":0,"bonusid":0},{"bonusvalue":1065353216,"bonuslevel":1,"bonustype":0,"bonusid":1},{"bonusvalue":1073741824,"bonuslevel":2,"bonustype":0,"bonusid":2},{"bonusvalue":1077936128,"bonuslevel":3,"bonustype":0,"bonusid":3},{"bonusvalue":1065353216,"bonuslevel":0,"bonustype":1,"bonusid":4},{"bonusvalue":1067450368,"bonuslevel":1,"bonustype":1,"bonusid":5},{"bonusvalue":1069547520,"bonuslevel":2,"bonustype":1,"bonusid":6},{"bonusvalue":1073741824,"bonuslevel":3,"bonustype":1,"bonusid":7},{"bonusvalue":0,"bonuslevel":0,"bonustype":3,"bonusid":8},{"bonusvalue":1065353216,"bonuslevel":1,"bonustype":3,"bonusid":9},{"bonusvalue":1077936128,"bonuslevel":2,"bonustype":3,"bonusid":10},{"bonusvalue":1084227584,"bonuslevel":3,"bonustype":3,"bonusid":11}]}
fifa17-recon/data/tables/fcc_chemlinkcalc.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/fcc_coinrewards.json
+1
View File
@@ -0,0 +1 @@
{"table":"fcc_coinrewards","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":17,"rowsize_bytes":8,"rows_emitted":17,"rowblock":"0x79883e8","rowblock_bytes":0,"descriptor":"0x7b40758","schema":[{"name":"leaderboard","bit":0,"width":12,"kind":"int","min":-1024,"max":1024,"storage":"int"},{"name":"coin","bit":12,"width":12,"kind":"int","min":-1024,"max":1024,"storage":"int"},{"name":"cap","bit":24,"width":7,"kind":"int","min":0,"max":100,"storage":"int"},{"name":"objectiveid","bit":31,"width":7,"kind":"int","min":1,"max":100,"storage":"int"}],"rows":[{"leaderboard":500,"coin":40,"cap":5,"objectiveid":1},{"leaderboard":500,"coin":5,"cap":10,"objectiveid":2},{"leaderboard":500,"coin":1,"cap":25,"objectiveid":3},{"leaderboard":500,"coin":5,"cap":10,"objectiveid":4},{"leaderboard":500,"coin":75,"cap":1,"objectiveid":5},{"leaderboard":500,"coin":1,"cap":80,"objectiveid":6},{"leaderboard":500,"coin":1,"cap":60,"objectiveid":7},{"leaderboard":500,"coin":15,"cap":1,"objectiveid":8},{"leaderboard":-500,"coin":-20,"cap":3,"objectiveid":9},{"leaderboard":-500,"coin":-5,"cap":5,"objectiveid":10},{"leaderboard":-500,"coin":-10,"cap":5,"objectiveid":11},{"leaderboard":-500,"coin":-40,"cap":5,"objectiveid":12},{"leaderboard":-500,"coin":-1,"cap":10,"objectiveid":13},{"leaderboard":500,"coin":0,"cap":0,"objectiveid":15},{"leaderboard":500,"coin":325,"cap":1,"objectiveid":16},{"leaderboard":-500,"coin":0,"cap":0,"objectiveid":17},{"leaderboard":500,"coin":0,"cap":0,"objectiveid":18}]}
fifa17-recon/data/tables/fcc_contractcards.json
+1
View File
@@ -0,0 +1 @@
{"table":"fcc_contractcards","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":13,"rowsize_bytes":16,"rows_emitted":13,"rowblock":"0x7b10ee8","rowblock_bytes":13,"descriptor":"0x42814a68","schema":[{"name":"carddbid","bit":0,"width":31,"kind":"int","min":0,"max":2001001001,"storage":"int"},{"name":"cardsubtype","bit":31,"width":14,"kind":"int","min":0,"max":10000,"storage":"int"},{"name":"weightrare","bit":45,"width":14,"kind":"int","min":0,"max":10000,"storage":"int"},{"name":"cardassetid","bit":59,"width":14,"kind":"int","min":0,"max":10000,"storage":"int"},{"name":"gold","bit":73,"width":7,"kind":"int","min":0,"max":100,"storage":"int"},{"name":"rating","bit":80,"width":7,"kind":"int","min":0,"max":100,"storage":"int"},{"name":"bronze","bit":87,"width":7,"kind":"int","min":0,"max":100,"storage":"int"},{"name":"silver","bit":94,"width":7,"kind":"int","min":0,"max":100,"storage":"int"}],"rows":[{"carddbid":5001001,"cardsubtype":201,"weightrare":0,"cardassetid":7,"gold":1,"rating":50,"bronze":8,"silver":2},{"carddbid":5001002,"cardsubtype":201,"weightrare":0,"cardassetid":7,"gold":8,"rating":65,"bronze":10,"silver":10},{"carddbid":5001003,"cardsubtype":201,"weightrare":0,"cardassetid":7,"gold":13,"rating":80,"bronze":15,"silver":11},{"carddbid":5001004,"cardsubtype":201,"weightrare":100,"cardassetid":7,"gold":3,"rating":60,"bronze":15,"silver":6},{"carddbid":5001005,"cardsubtype":201,"weightrare":100,"cardassetid":7,"gold":18,"rating":70,"bronze":20,"silver":24},{"carddbid":5001006,"cardsubtype":201,"weightrare":100,"cardassetid":7,"gold":28,"rating":90,"bronze":28,"silver":24},{"carddbid":5001007,"cardsubtype":202,"weightrare":0,"cardassetid":8,"gold":1,"rating":50,"bronze":8,"silver":2},{"carddbid":5001008,"cardsubtype":202,"weightrare":0,"cardassetid":8,"gold":8,"rating":65,"bronze":8,"silver":10},{"carddbid":5001009,"cardsubtype":202,"weightrare":0,"cardassetid":8,"gold":13,"rating":80,"bronze":11,"silver":11},{"carddbid":5001010,"cardsubtype":202,"weightrare":10,"cardassetid":8,"gold":3,"rating":60,"bronze":15,"silver":6},{"carddbid":5001011,"cardsubtype":202,"weightrare":10,"cardassetid":8,"gold":18,"rating":70,"bronze":18,"silver":24},{"carddbid":5001012,"cardsubtype":202,"weightrare":10,"cardassetid":8,"gold":28,"rating":90,"bronze":24,"silver":24},{"carddbid":5001013,"cardsubtype":201,"weightrare":0,"cardassetid":7,"gold":99,"rating":90,"bronze":99,"silver":99}]}
fifa17-recon/data/tables/fcc_discardcoins.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/fcc_formationcardspositions_hd.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/fcc_formationcardspositions_kc.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/fcc_healingcards.json
+1
View File
@@ -0,0 +1 @@
{"table":"fcc_healingcards","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":27,"rowsize_bytes":12,"rows_emitted":27,"rowblock":"0x42814488","rowblock_bytes":353,"descriptor":"0x7b200f8","schema":[{"name":"carddbid","bit":0,"width":31,"kind":"int","min":0,"max":2001001001,"storage":"int"},{"name":"cardsubtype","bit":31,"width":14,"kind":"int","min":0,"max":10000,"storage":"int"},{"name":"weightrare","bit":45,"width":14,"kind":"int","min":0,"max":10000,"storage":"int"},{"name":"cardassetid","bit":59,"width":14,"kind":"int","min":0,"max":10000,"storage":"int"},{"name":"amount","bit":73,"width":7,"kind":"int","min":0,"max":100,"storage":"int"},{"name":"rating","bit":80,"width":7,"kind":"int","min":0,"max":100,"storage":"int"}],"rows":[{"carddbid":5002001,"cardsubtype":219,"weightrare":0,"cardassetid":10,"amount":20,"rating":55},{"carddbid":5002002,"cardsubtype":219,"weightrare":0,"cardassetid":10,"amount":40,"rating":70},{"carddbid":5002003,"cardsubtype":219,"weightrare":0,"cardassetid":10,"amount":60,"rating":80},{"carddbid":5002004,"cardsubtype":220,"weightrare":70,"cardassetid":10,"amount":10,"rating":55},{"carddbid":5002005,"cardsubtype":220,"weightrare":70,"cardassetid":10,"amount":20,"rating":70},{"carddbid":5002006,"cardsubtype":220,"weightrare":70,"cardassetid":10,"amount":30,"rating":80},{"carddbid":5002007,"cardsubtype":211,"weightrare":0,"cardassetid":9,"amount":1,"rating":55},{"carddbid":5002008,"cardsubtype":211,"weightrare":0,"cardassetid":9,"amount":2,"rating":70},{"carddbid":5002009,"cardsubtype":211,"weightrare":0,"cardassetid":9,"amount":5,"rating":80},{"carddbid":5002010,"cardsubtype":212,"weightrare":0,"cardassetid":9,"amount":1,"rating":55},{"carddbid":5002011,"cardsubtype":212,"weightrare":0,"cardassetid":9,"amount":2,"rating":70},{"carddbid":5002012,"cardsubtype":212,"weightrare":0,"cardassetid":9,"amount":5,"rating":80},{"carddbid":5002013,"cardsubtype":213,"weightrare":0,"cardassetid":9,"amount":1,"rating":55},{"carddbid":5002014,"cardsubtype":213,"weightrare":0,"cardassetid":9,"amount":2,"rating":70},{"carddbid":5002015,"cardsubtype":213,"weightrare":0,"cardassetid":9,"amount":5,"rating":80},{"carddbid":5002019,"cardsubtype":215,"weightrare":0,"cardassetid":9,"amount":1,"rating":55},{"carddbid":5002020,"cardsubtype":215,"weightrare":0,"cardassetid":9,"amount":2,"rating":70},{"carddbid":5002021,"cardsubtype":215,"weightrare":0,"cardassetid":9,"amount":5,"rating":80},{"carddbid":5002022,"cardsubtype":216,"weightrare":0,"cardassetid":9,"amount":1,"rating":55},{"carddbid":5002023,"cardsubtype":216,"weightrare":0,"cardassetid":9,"amount":2,"rating":70},{"carddbid":5002024,"cardsubtype":216,"weightrare":0,"cardassetid":9,"amount":5,"rating":80},{"carddbid":5002025,"cardsubtype":217,"weightrare":0,"cardassetid":9,"amount":1,"rating":55},{"carddbid":5002026,"cardsubtype":217,"weightrare":0,"cardassetid":9,"amount":2,"rating":70},{"carddbid":5002027,"cardsubtype":217,"weightrare":0,"cardassetid":9,"amount":5,"rating":80},{"carddbid":5002028,"cardsubtype":218,"weightrare":20,"cardassetid":9,"amount":1,"rating":60},{"carddbid":5002029,"cardsubtype":218,"weightrare":20,"cardassetid":9,"amount":2,"rating":74},{"carddbid":5002030,"cardsubtype":218,"weightrare":20,"cardassetid":9,"amount":4,"rating":85}]}
fifa17-recon/data/tables/fcc_kitcards.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/fcc_leaguelogos.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/fcc_leaguelogostickers.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/fcc_leagues.json
+1
View File
@@ -0,0 +1 @@
{"table":"fcc_leagues","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":43,"rowsize_bytes":12,"rows_emitted":43,"rowblock":"0x428136d8","rowblock_bytes":545,"descriptor":"0x7b405b8","schema":[{"name":"leaguename","bit":0,"width":32,"kind":"string","min":0,"max":0,"storage":"offset-unresolved"},{"name":"leagueid","bit":32,"width":13,"kind":"int","min":0,"max":5000,"storage":"int"},{"name":"fifacountryid","bit":45,"width":13,"kind":"int","min":0,"max":5000,"storage":"int"},{"name":"futcountryid","bit":58,"width":13,"kind":"int","min":0,"max":5000,"storage":"int"}],"rows":[{"leaguename":236,"leagueid":1,"fifacountryid":13,"futcountryid":212},{"leaguename":250,"leagueid":4,"fifacountryid":7,"futcountryid":212},{"leaguename":269,"leagueid":7,"fifacountryid":54,"futcountryid":211},{"leaguename":290,"leagueid":10,"fifacountryid":34,"futcountryid":212},{"leaguename":305,"leagueid":13,"fifacountryid":14,"futcountryid":14},{"leaguename":321,"leagueid":14,"fifacountryid":14,"futcountryid":14},{"leaguename":342,"leagueid":16,"fifacountryid":18,"futcountryid":18},{"leaguename":354,"leagueid":17,"fifacountryid":18,"futcountryid":18},{"leaguename":366,"leagueid":19,"fifacountryid":21,"futcountryid":21},{"leaguename":383,"leagueid":20,"fifacountryid":21,"futcountryid":21},{"leaguename":401,"leagueid":31,"fifacountryid":27,"futcountryid":27},{"leaguename":413,"leagueid":32,"fifacountryid":27,"futcountryid":27},{"leaguename":425,"leagueid":39,"fifacountryid":95,"futcountryid":211},{"leaguename":443,"leagueid":41,"fifacountryid":36,"futcountryid":212},{"leaguename":458,"leagueid":50,"fifacountryid":42,"futcountryid":212},{"leaguename":474,"leagueid":53,"fifacountryid":45,"futcountryid":45},{"leaguename":491,"leagueid":54,"fifacountryid":45,"futcountryid":45},{"leaguename":504,"leagueid":56,"fifacountryid":46,"futcountryid":212},{"leaguename":519,"leagueid":60,"fifacountryid":14,"futcountryid":14},{"leaguename":534,"leagueid":61,"fifacountryid":14,"futcountryid":14},{"leaguename":549,"leagueid":63,"fifacountryid":22,"futcountryid":212},{"leaguename":564,"leagueid":65,"fifacountryid":25,"futcountryid":212},{"leaguename":586,"leagueid":66,"fifacountryid":37,"futcountryid":212},{"leaguename":608,"leagueid":67,"fifacountryid":40,"futcountryid":211},{"leaguename":624,"leagueid":68,"fifacountryid":48,"futcountryid":212},{"leaguename":639,"leagueid":78,"fifacountryid":75,"futcountryid":211},{"leaguename":648,"leagueid":80,"fifacountryid":4,"futcountryid":212},{"leaguename":663,"leagueid":83,"fifacountryid":167,"futcountryid":211},{"leaguename":681,"leagueid":189,"fifacountryid":47,"futcountryid":212},{"leaguename":699,"leagueid":308,"fifacountryid":38,"futcountryid":212},{"leaguename":714,"leagueid":322,"fifacountryid":17,"futcountryid":212},{"leaguename":731,"leagueid":332,"fifacountryid":49,"futcountryid":212},{"leaguename":746,"leagueid":335,"fifacountryid":55,"futcountryid":211},{"leaguename":772,"leagueid":336,"fifacountryid":56,"futcountryid":211},{"leaguename":788,"leagueid":341,"fifacountryid":83,"futcountryid":211},{"leaguename":802,"leagueid":347,"fifacountryid":140,"futcountryid":211},{"leaguename":820,"leagueid":349,"fifacountryid":163,"futcountryid":211},{"leaguename":833,"leagueid":350,"fifacountryid":183,"futcountryid":211},{"leaguename":856,"leagueid":351,"fifacountryid":195,"futcountryid":211},{"leaguename":876,"leagueid":353,"fifacountryid":52,"futcountryid":211},{"leaguename":897,"leagueid":2025,"fifacountryid":54,"futcountryid":211},{"leaguename":914,"leagueid":2134,"fifacountryid":221,"futcountryid":211},{"leaguename":925,"leagueid":2150,"fifacountryid":221,"futcountryid":211}]}
fifa17-recon/data/tables/fcc_managerbonusvalues.json
+1
View File
@@ -0,0 +1 @@
{"table":"fcc_managerbonusvalues","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":9,"rowsize_bytes":4,"rows_emitted":9,"rowblock":"0x7c31088","rowblock_bytes":16472,"descriptor":"0x7b10388","schema":[{"name":"bonuslevel","bit":0,"width":8,"kind":"int","min":0,"max":255,"storage":"int"},{"name":"bonustype","bit":8,"width":8,"kind":"int","min":0,"max":255,"storage":"int"},{"name":"cardlevel","bit":16,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"bonusvalue","bit":19,"width":5,"kind":"int","min":0,"max":16,"storage":"int"},{"name":"bonusid","bit":24,"width":5,"kind":"int","min":0,"max":16,"storage":"int"}],"rows":[{"bonuslevel":3,"bonustype":1,"cardlevel":1,"bonusvalue":2,"bonusid":0},{"bonuslevel":3,"bonustype":1,"cardlevel":2,"bonusvalue":5,"bonusid":1},{"bonuslevel":3,"bonustype":1,"cardlevel":3,"bonusvalue":10,"bonusid":2},{"bonuslevel":2,"bonustype":2,"cardlevel":1,"bonusvalue":1,"bonusid":3},{"bonuslevel":2,"bonustype":2,"cardlevel":2,"bonusvalue":2,"bonusid":4},{"bonuslevel":2,"bonustype":2,"cardlevel":3,"bonusvalue":3,"bonusid":5},{"bonuslevel":3,"bonustype":2,"cardlevel":1,"bonusvalue":1,"bonusid":6},{"bonuslevel":3,"bonustype":2,"cardlevel":2,"bonusvalue":1,"bonusid":7},{"bonuslevel":3,"bonustype":2,"cardlevel":3,"bonusvalue":1,"bonusid":8}]}
fifa17-recon/data/tables/fcc_misccards.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/fcc_myclubs.json
+1
View File
@@ -0,0 +1 @@
{"table":"fcc_myclubs","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":2,"rowsize_bytes":8,"rows_emitted":2,"rowblock":"0x7c20748","rowblock_bytes":0,"descriptor":"0x7b57a68","schema":[{"name":"myclubname","bit":0,"width":32,"kind":"string","min":0,"max":0,"storage":"offset-unresolved"},{"name":"myclubid","bit":32,"width":8,"kind":"int","min":0,"max":128,"storage":"int"}],"rows":[{"myclubname":0,"myclubid":1},{"myclubname":16,"myclubid":2}]}
fifa17-recon/data/tables/fcc_myclubscategories.json
+1
View File
@@ -0,0 +1 @@
{"table":"fcc_myclubscategories","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":12,"rowsize_bytes":12,"rows_emitted":12,"rowblock":"0x7988488","rowblock_bytes":0,"descriptor":"0x7b20878","schema":[{"name":"categoryname","bit":0,"width":32,"kind":"string","min":0,"max":0,"storage":"offset-unresolved"},{"name":"futcountryid","bit":32,"width":16,"kind":"int","min":0,"max":50000,"storage":"int"},{"name":"myclubid","bit":48,"width":8,"kind":"int","min":0,"max":128,"storage":"int"},{"name":"id","bit":56,"width":8,"kind":"int","min":0,"max":128,"storage":"int"},{"name":"isteamcategory","bit":64,"width":8,"kind":"int","min":0,"max":128,"storage":"int"},{"name":"categoryid","bit":72,"width":8,"kind":"int","min":0,"max":128,"storage":"int"}],"rows":[{"categoryname":0,"futcountryid":0,"myclubid":0,"id":1,"isteamcategory":0,"categoryid":16},{"categoryname":13,"futcountryid":14,"myclubid":0,"id":2,"isteamcategory":1,"categoryid":1},{"categoryname":32,"futcountryid":18,"myclubid":0,"id":3,"isteamcategory":1,"categoryid":2},{"categoryname":50,"futcountryid":21,"myclubid":0,"id":4,"isteamcategory":1,"categoryid":3},{"categoryname":69,"futcountryid":27,"myclubid":0,"id":5,"isteamcategory":1,"categoryid":4},{"categoryname":86,"futcountryid":45,"myclubid":0,"id":6,"isteamcategory":1,"categoryid":5},{"categoryname":103,"futcountryid":212,"myclubid":0,"id":7,"isteamcategory":1,"categoryid":6},{"categoryname":121,"futcountryid":211,"myclubid":0,"id":8,"isteamcategory":1,"categoryid":7},{"categoryname":138,"futcountryid":0,"myclubid":2,"id":10,"isteamcategory":0,"categoryid":18},{"categoryname":155,"futcountryid":0,"myclubid":2,"id":11,"isteamcategory":0,"categoryid":8},{"categoryname":173,"futcountryid":0,"myclubid":2,"id":12,"isteamcategory":0,"categoryid":10},{"categoryname":190,"futcountryid":0,"myclubid":2,"id":13,"isteamcategory":0,"categoryid":11}]}
fifa17-recon/data/tables/fcc_nationcalc.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/fcc_navcoords_hd.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/fcc_navcoords_kc.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/fcc_preferredformationcalcback.json
+1
View File
@@ -0,0 +1 @@
{"table":"fcc_preferredformationcalcback","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":16,"rowsize_bytes":12,"rows_emitted":16,"rowblock":"0x7b40a98","rowblock_bytes":0,"descriptor":"0x42811bb8","schema":[{"name":"formations","bit":0,"width":32,"kind":"string","min":0,"max":0,"storage":"offset-unresolved"},{"name":"form10","bit":32,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form2","bit":35,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"id","bit":38,"width":6,"kind":"int","min":0,"max":34,"storage":"int"},{"name":"form3","bit":44,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form5","bit":47,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form4","bit":50,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form13","bit":53,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form7","bit":56,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form9","bit":59,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form14","bit":62,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form12","bit":65,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form15","bit":68,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form8","bit":71,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form6","bit":74,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form16","bit":77,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form11","bit":80,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form1","bit":83,"width":3,"kind":"int","min":0,"max":4,"storage":"int"}],"rows":[{"formations":0,"form10":1,"form2":0,"id":3,"form3":0,"form5":1,"form4":0,"form13":2,"form7":1,"form9":2,"form14":0,"form12":1,"form15":0,"form8":1,"form6":3,"form16":0,"form11":1,"form1":0},{"formations":6,"form10":2,"form2":0,"id":6,"form3":0,"form5":1,"form4":0,"form13":1,"form7":1,"form9":2,"form14":0,"form12":1,"form15":0,"form8":3,"form6":1,"form16":0,"form11":1,"form1":0},{"formations":12,"form10":2,"form2":0,"id":7,"form3":0,"form5":1,"form4":0,"form13":1,"form7":1,"form9":3,"form14":0,"form12":1,"form15":0,"form8":2,"form6":2,"form16":0,"form11":1,"form1":0},{"formations":18,"form10":3,"form2":0,"id":8,"form3":0,"form5":1,"form4":0,"form13":1,"form7":1,"form9":2,"form14":0,"form12":1,"form15":0,"form8":2,"form6":1,"form16":0,"form11":1,"form1":0},{"formations":25,"form10":1,"form2":0,"id":13,"form3":0,"form5":2,"form4":0,"form13":1,"form7":3,"form9":1,"form14":0,"form12":2,"form15":0,"form8":1,"form6":1,"form16":0,"form11":2,"form1":0},{"formations":31,"form10":1,"form2":0,"id":14,"form3":0,"form5":3,"form4":0,"form13":1,"form7":2,"form9":1,"form14":0,"form12":2,"form15":0,"form8":1,"form6":1,"form16":0,"form11":2,"form1":0},{"formations":37,"form10":1,"form2":0,"id":16,"form3":0,"form5":2,"form4":0,"form13":1,"form7":2,"form9":1,"form14":0,"form12":3,"form15":0,"form8":1,"form6":1,"form16":0,"form11":2,"form1":0},{"formations":44,"form10":1,"form2":0,"id":19,"form3":0,"form5":2,"form4":0,"form13":1,"form7":2,"form9":1,"form14":0,"form12":2,"form15":0,"form8":1,"form6":1,"form16":0,"form11":3,"form1":0},{"formations":51,"form10":1,"form2":0,"id":21,"form3":0,"form5":1,"form4":0,"form13":3,"form7":1,"form9":1,"form14":0,"form12":1,"form15":0,"form8":1,"form6":2,"form16":0,"form11":1,"form1":0},{"formations":58,"form10":0,"form2":2,"id":23,"form3":2,"form5":0,"form4":1,"form13":0,"form7":0,"form9":0,"form14":0,"form12":0,"form15":0,"form8":0,"form6":0,"form16":0,"form11":0,"form1":3},{"formations":64,"form10":0,"form2":3,"id":24,"form3":2,"form5":0,"form4":1,"form13":0,"form7":0,"form9":0,"form14":0,"form12":0,"form15":0,"form8":0,"form6":0,"form16":0,"form11":0,"form1":2},{"formations":70,"form10":0,"form2":2,"id":25,"form3":3,"form5":0,"form4":1,"form13":0,"form7":0,"form9":0,"form14":0,"form12":0,"form15":0,"form8":0,"form6":0,"form16":0,"form11":0,"form1":2},{"formations":76,"form10":0,"form2":1,"id":27,"form3":1,"form5":0,"form4":3,"form13":0,"form7":0,"form9":0,"form14":0,"form12":0,"form15":0,"form8":0,"form6":0,"form16":0,"form11":0,"form1":1},{"formations":82,"form10":0,"form2":0,"id":29,"form3":0,"form5":0,"form4":0,"form13":0,"form7":0,"form9":0,"form14":3,"form12":0,"form15":2,"form8":0,"form6":0,"form16":1,"form11":0,"form1":0},{"formations":89,"form10":0,"form2":0,"id":30,"form3":0,"form5":0,"form4":0,"form13":0,"form7":0,"form9":0,"form14":2,"form12":0,"form15":3,"form8":0,"form6":0,"form16":1,"form11":0,"form1":0},{"formations":96,"form10":0,"form2":0,"id":31,"form3":0,"form5":0,"form4":0,"form13":0,"form7":0,"form9":0,"form14":1,"form12":0,"form15":1,"form8":0,"form6":0,"form16":3,"form11":0,"form1":0}]}
fifa17-recon/data/tables/fcc_preferredformationcalcgk.json
+1
View File
@@ -0,0 +1 @@
{"table":"fcc_preferredformationcalcgk","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":16,"rowsize_bytes":12,"rows_emitted":16,"rowblock":"0x7b40828","rowblock_bytes":7,"descriptor":"0x428119f8","schema":[{"name":"formations","bit":0,"width":32,"kind":"string","min":0,"max":0,"storage":"offset-unresolved"},{"name":"form10","bit":32,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form2","bit":35,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"id","bit":38,"width":6,"kind":"int","min":0,"max":34,"storage":"int"},{"name":"form3","bit":44,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form5","bit":47,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form4","bit":50,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form13","bit":53,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form7","bit":56,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form9","bit":59,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form14","bit":62,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form12","bit":65,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form15","bit":68,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form8","bit":71,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form6","bit":74,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form16","bit":77,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form11","bit":80,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form1","bit":83,"width":3,"kind":"int","min":0,"max":4,"storage":"int"}],"rows":[{"formations":0,"form10":2,"form2":0,"id":3,"form3":0,"form5":2,"form4":0,"form13":2,"form7":2,"form9":2,"form14":0,"form12":2,"form15":0,"form8":2,"form6":3,"form16":0,"form11":2,"form1":0},{"formations":6,"form10":2,"form2":0,"id":6,"form3":0,"form5":2,"form4":0,"form13":2,"form7":2,"form9":2,"form14":0,"form12":2,"form15":0,"form8":3,"form6":2,"form16":0,"form11":2,"form1":0},{"formations":12,"form10":2,"form2":0,"id":7,"form3":0,"form5":2,"form4":0,"form13":2,"form7":2,"form9":3,"form14":0,"form12":2,"form15":0,"form8":2,"form6":2,"form16":0,"form11":2,"form1":0},{"formations":18,"form10":3,"form2":0,"id":8,"form3":0,"form5":2,"form4":0,"form13":2,"form7":2,"form9":2,"form14":0,"form12":2,"form15":0,"form8":2,"form6":2,"form16":0,"form11":2,"form1":0},{"formations":25,"form10":2,"form2":0,"id":13,"form3":0,"form5":2,"form4":0,"form13":2,"form7":3,"form9":2,"form14":0,"form12":2,"form15":0,"form8":2,"form6":2,"form16":0,"form11":2,"form1":0},{"formations":31,"form10":2,"form2":0,"id":14,"form3":0,"form5":3,"form4":0,"form13":2,"form7":2,"form9":2,"form14":0,"form12":2,"form15":0,"form8":2,"form6":2,"form16":0,"form11":2,"form1":0},{"formations":37,"form10":2,"form2":0,"id":16,"form3":0,"form5":2,"form4":0,"form13":2,"form7":2,"form9":2,"form14":0,"form12":3,"form15":0,"form8":2,"form6":2,"form16":0,"form11":2,"form1":0},{"formations":44,"form10":2,"form2":0,"id":19,"form3":0,"form5":2,"form4":0,"form13":2,"form7":2,"form9":2,"form14":0,"form12":2,"form15":0,"form8":2,"form6":2,"form16":0,"form11":3,"form1":0},{"formations":51,"form10":2,"form2":0,"id":21,"form3":0,"form5":2,"form4":0,"form13":3,"form7":2,"form9":2,"form14":0,"form12":2,"form15":0,"form8":2,"form6":2,"form16":0,"form11":2,"form1":0},{"formations":58,"form10":0,"form2":2,"id":23,"form3":2,"form5":0,"form4":2,"form13":0,"form7":0,"form9":0,"form14":0,"form12":0,"form15":0,"form8":0,"form6":0,"form16":0,"form11":0,"form1":3},{"formations":64,"form10":0,"form2":3,"id":24,"form3":2,"form5":0,"form4":2,"form13":0,"form7":0,"form9":0,"form14":0,"form12":0,"form15":0,"form8":0,"form6":0,"form16":0,"form11":0,"form1":2},{"formations":70,"form10":0,"form2":2,"id":25,"form3":3,"form5":0,"form4":2,"form13":0,"form7":0,"form9":0,"form14":0,"form12":0,"form15":0,"form8":0,"form6":0,"form16":0,"form11":0,"form1":2},{"formations":76,"form10":0,"form2":2,"id":27,"form3":2,"form5":0,"form4":3,"form13":0,"form7":0,"form9":0,"form14":0,"form12":0,"form15":0,"form8":0,"form6":0,"form16":0,"form11":0,"form1":2},{"formations":82,"form10":0,"form2":0,"id":29,"form3":0,"form5":0,"form4":0,"form13":0,"form7":0,"form9":0,"form14":3,"form12":0,"form15":2,"form8":0,"form6":0,"form16":2,"form11":0,"form1":0},{"formations":89,"form10":0,"form2":0,"id":30,"form3":0,"form5":0,"form4":0,"form13":0,"form7":0,"form9":0,"form14":2,"form12":0,"form15":3,"form8":0,"form6":0,"form16":2,"form11":0,"form1":0},{"formations":96,"form10":0,"form2":0,"id":31,"form3":0,"form5":0,"form4":0,"form13":0,"form7":0,"form9":0,"form14":2,"form12":0,"form15":2,"form8":0,"form6":0,"form16":3,"form11":0,"form1":0}]}
fifa17-recon/data/tables/fcc_preferredformationcalcmid.json
+1
View File
@@ -0,0 +1 @@
{"table":"fcc_preferredformationcalcmid","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":16,"rowsize_bytes":12,"rows_emitted":16,"rowblock":"0x7b409c8","rowblock_bytes":10,"descriptor":"0x42811838","schema":[{"name":"formations","bit":0,"width":32,"kind":"string","min":0,"max":0,"storage":"offset-unresolved"},{"name":"form10","bit":32,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form2","bit":35,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"id","bit":38,"width":6,"kind":"int","min":0,"max":34,"storage":"int"},{"name":"form3","bit":44,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form5","bit":47,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form4","bit":50,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form13","bit":53,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form7","bit":56,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form9","bit":59,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form14","bit":62,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form12","bit":65,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form15","bit":68,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form8","bit":71,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form6","bit":74,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form16","bit":77,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form11","bit":80,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form1","bit":83,"width":3,"kind":"int","min":0,"max":4,"storage":"int"}],"rows":[{"formations":0,"form10":0,"form2":0,"id":3,"form3":0,"form5":0,"form4":1,"form13":2,"form7":0,"form9":2,"form14":0,"form12":0,"form15":0,"form8":0,"form6":3,"form16":0,"form11":0,"form1":0},{"formations":6,"form10":2,"form2":0,"id":6,"form3":0,"form5":1,"form4":0,"form13":0,"form7":0,"form9":2,"form14":0,"form12":0,"form15":0,"form8":3,"form6":0,"form16":0,"form11":0,"form1":0},{"formations":12,"form10":2,"form2":0,"id":7,"form3":0,"form5":0,"form4":0,"form13":0,"form7":0,"form9":3,"form14":0,"form12":0,"form15":0,"form8":2,"form6":2,"form16":0,"form11":0,"form1":0},{"formations":18,"form10":3,"form2":0,"id":8,"form3":0,"form5":0,"form4":0,"form13":0,"form7":0,"form9":2,"form14":0,"form12":0,"form15":0,"form8":2,"form6":0,"form16":0,"form11":0,"form1":0},{"formations":25,"form10":0,"form2":1,"id":13,"form3":1,"form5":1,"form4":0,"form13":0,"form7":3,"form9":0,"form14":0,"form12":2,"form15":0,"form8":0,"form6":0,"form16":0,"form11":2,"form1":1},{"formations":31,"form10":0,"form2":1,"id":14,"form3":1,"form5":3,"form4":0,"form13":0,"form7":1,"form9":0,"form14":0,"form12":2,"form15":0,"form8":1,"form6":0,"form16":0,"form11":2,"form1":1},{"formations":37,"form10":0,"form2":1,"id":16,"form3":1,"form5":2,"form4":0,"form13":0,"form7":2,"form9":0,"form14":0,"form12":3,"form15":0,"form8":0,"form6":0,"form16":0,"form11":2,"form1":1},{"formations":44,"form10":0,"form2":1,"id":19,"form3":1,"form5":2,"form4":0,"form13":0,"form7":2,"form9":0,"form14":0,"form12":2,"form15":0,"form8":0,"form6":0,"form16":0,"form11":3,"form1":1},{"formations":51,"form10":0,"form2":0,"id":21,"form3":0,"form5":0,"form4":0,"form13":3,"form7":0,"form9":0,"form14":0,"form12":0,"form15":0,"form8":0,"form6":2,"form16":0,"form11":0,"form1":0},{"formations":58,"form10":0,"form2":2,"id":23,"form3":2,"form5":1,"form4":0,"form13":0,"form7":1,"form9":0,"form14":0,"form12":1,"form15":0,"form8":0,"form6":0,"form16":0,"form11":1,"form1":3},{"formations":64,"form10":0,"form2":3,"id":24,"form3":2,"form5":1,"form4":0,"form13":0,"form7":1,"form9":0,"form14":0,"form12":1,"form15":0,"form8":0,"form6":0,"form16":0,"form11":1,"form1":2},{"formations":70,"form10":0,"form2":2,"id":25,"form3":3,"form5":1,"form4":0,"form13":0,"form7":1,"form9":0,"form14":0,"form12":1,"form15":0,"form8":0,"form6":0,"form16":0,"form11":1,"form1":2},{"formations":76,"form10":0,"form2":0,"id":27,"form3":0,"form5":0,"form4":3,"form13":0,"form7":0,"form9":0,"form14":0,"form12":0,"form15":0,"form8":0,"form6":1,"form16":0,"form11":0,"form1":0},{"formations":82,"form10":0,"form2":0,"id":29,"form3":0,"form5":0,"form4":0,"form13":0,"form7":0,"form9":0,"form14":3,"form12":0,"form15":2,"form8":0,"form6":0,"form16":1,"form11":0,"form1":0},{"formations":89,"form10":0,"form2":0,"id":30,"form3":0,"form5":0,"form4":0,"form13":0,"form7":0,"form9":0,"form14":2,"form12":0,"form15":3,"form8":0,"form6":0,"form16":1,"form11":0,"form1":0},{"formations":96,"form10":0,"form2":0,"id":31,"form3":0,"form5":0,"form4":0,"form13":0,"form7":0,"form9":0,"form14":1,"form12":0,"form15":1,"form8":0,"form6":0,"form16":3,"form11":0,"form1":0}]}
fifa17-recon/data/tables/fcc_preferredformationcalcst.json
+1
View File
@@ -0,0 +1 @@
{"table":"fcc_preferredformationcalcst","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":16,"rowsize_bytes":12,"rows_emitted":16,"rowblock":"0x7b404e8","rowblock_bytes":15,"descriptor":"0x42811678","schema":[{"name":"formations","bit":0,"width":32,"kind":"string","min":0,"max":0,"storage":"offset-unresolved"},{"name":"form10","bit":32,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form2","bit":35,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"id","bit":38,"width":6,"kind":"int","min":0,"max":34,"storage":"int"},{"name":"form3","bit":44,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form5","bit":47,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form4","bit":50,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form13","bit":53,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form7","bit":56,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form9","bit":59,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form14","bit":62,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form12","bit":65,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form15","bit":68,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form8","bit":71,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form6","bit":74,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form16","bit":77,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form11","bit":80,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"form1","bit":83,"width":3,"kind":"int","min":0,"max":4,"storage":"int"}],"rows":[{"formations":0,"form10":0,"form2":0,"id":3,"form3":0,"form5":0,"form4":0,"form13":2,"form7":0,"form9":0,"form14":0,"form12":0,"form15":1,"form8":0,"form6":3,"form16":0,"form11":1,"form1":0},{"formations":6,"form10":2,"form2":1,"id":6,"form3":1,"form5":1,"form4":0,"form13":0,"form7":0,"form9":2,"form14":1,"form12":0,"form15":0,"form8":3,"form6":0,"form16":0,"form11":0,"form1":1},{"formations":12,"form10":2,"form2":1,"id":7,"form3":1,"form5":0,"form4":0,"form13":0,"form7":0,"form9":3,"form14":0,"form12":0,"form15":1,"form8":2,"form6":0,"form16":0,"form11":0,"form1":1},{"formations":18,"form10":3,"form2":1,"id":8,"form3":1,"form5":0,"form4":0,"form13":0,"form7":0,"form9":2,"form14":1,"form12":0,"form15":1,"form8":2,"form6":0,"form16":0,"form11":0,"form1":1},{"formations":25,"form10":0,"form2":0,"id":13,"form3":0,"form5":2,"form4":1,"form13":0,"form7":3,"form9":0,"form14":0,"form12":2,"form15":0,"form8":0,"form6":0,"form16":0,"form11":2,"form1":0},{"formations":31,"form10":0,"form2":0,"id":14,"form3":0,"form5":3,"form4":1,"form13":0,"form7":2,"form9":0,"form14":1,"form12":2,"form15":0,"form8":1,"form6":0,"form16":1,"form11":2,"form1":0},{"formations":37,"form10":0,"form2":0,"id":16,"form3":0,"form5":2,"form4":1,"form13":0,"form7":2,"form9":0,"form14":0,"form12":3,"form15":0,"form8":0,"form6":0,"form16":0,"form11":2,"form1":0},{"formations":44,"form10":0,"form2":0,"id":19,"form3":0,"form5":2,"form4":0,"form13":0,"form7":2,"form9":0,"form14":0,"form12":2,"form15":0,"form8":0,"form6":1,"form16":0,"form11":3,"form1":0},{"formations":51,"form10":0,"form2":1,"id":21,"form3":0,"form5":0,"form4":0,"form13":3,"form7":0,"form9":0,"form14":0,"form12":0,"form15":0,"form8":0,"form6":2,"form16":0,"form11":0,"form1":0},{"formations":58,"form10":1,"form2":2,"id":23,"form3":2,"form5":0,"form4":0,"form13":0,"form7":0,"form9":1,"form14":1,"form12":0,"form15":1,"form8":1,"form6":0,"form16":0,"form11":0,"form1":3},{"formations":64,"form10":1,"form2":3,"id":24,"form3":2,"form5":0,"form4":0,"form13":1,"form7":0,"form9":1,"form14":1,"form12":0,"form15":1,"form8":1,"form6":0,"form16":0,"form11":0,"form1":2},{"formations":70,"form10":1,"form2":2,"id":25,"form3":3,"form5":0,"form4":0,"form13":0,"form7":0,"form9":1,"form14":1,"form12":0,"form15":1,"form8":1,"form6":0,"form16":0,"form11":0,"form1":2},{"formations":76,"form10":0,"form2":0,"id":27,"form3":0,"form5":1,"form4":3,"form13":0,"form7":1,"form9":0,"form14":0,"form12":1,"form15":0,"form8":0,"form6":0,"form16":1,"form11":0,"form1":0},{"formations":82,"form10":1,"form2":1,"id":29,"form3":1,"form5":1,"form4":0,"form13":0,"form7":0,"form9":0,"form14":3,"form12":0,"form15":2,"form8":1,"form6":0,"form16":1,"form11":0,"form1":1},{"formations":89,"form10":1,"form2":1,"id":30,"form3":1,"form5":0,"form4":0,"form13":0,"form7":0,"form9":1,"form14":2,"form12":0,"form15":3,"form8":0,"form6":1,"form16":1,"form11":0,"form1":1},{"formations":96,"form10":0,"form2":0,"id":31,"form3":0,"form5":1,"form4":1,"form13":0,"form7":0,"form9":0,"form14":1,"form12":0,"form15":1,"form8":0,"form6":0,"form16":3,"form11":0,"form1":0}]}
fifa17-recon/data/tables/fcc_preferredpositioncalc.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/fcc_stadium.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/fcc_textposvalues_hd.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/fcc_textposvalues_kc.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/fcc_trainingcards.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/fieldpositionboundingboxes.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/fifaGameDefaults.json
+1
View File
@@ -0,0 +1 @@
{"table":"fifaGameDefaults","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":5,"rowsize_bytes":36,"rows_emitted":5,"rowblock":"0x42e99fb8","rowblock_bytes":353,"descriptor":"0x42816d38","schema":[{"name":"defaultgkteam","bit":0,"width":18,"kind":"int","min":-1,"max":200000,"storage":"int"},{"name":"defaultgkid","bit":18,"width":19,"kind":"int","min":-1,"max":300000,"storage":"int"},{"name":"defaultfourthofficial","bit":37,"width":9,"kind":"int","min":1,"max":512,"storage":"int"},{"name":"defaultlinesman1","bit":46,"width":9,"kind":"int","min":1,"max":512,"storage":"int"},{"name":"gamesettingscontext","bit":55,"width":3,"kind":"int","min":0,"max":5,"storage":"int"},{"name":"defaultplayerid","bit":58,"width":19,"kind":"int","min":-1,"max":300000,"storage":"int"},{"name":"defaultfemalegkteam","bit":77,"width":18,"kind":"int","min":-1,"max":200000,"storage":"int"},{"name":"defaultleagueid","bit":95,"width":12,"kind":"int","min":-1,"max":3000,"storage":"int"},{"name":"gamesettingspk","bit":107,"width":31,"kind":"int","min":0,"max":2147483520,"storage":"int"},{"name":"defaultfemaleplayerid","bit":138,"width":19,"kind":"int","min":-1,"max":300000,"storage":"int"},{"name":"defaultreferee","bit":157,"width":9,"kind":"int","min":1,"max":512,"storage":"int"},{"name":"defaultlinesman2","bit":166,"width":9,"kind":"int","min":1,"max":512,"storage":"int"},{"name":"defaultteamid","bit":175,"width":18,"kind":"int","min":-1,"max":200000,"storage":"int"},{"name":"defaultballid","bit":193,"width":10,"kind":"int","min":-2,"max":1000,"storage":"int"},{"name":"defaultfemalegkid","bit":203,"width":19,"kind":"int","min":-1,"max":300000,"storage":"int"},{"name":"defaultfemaleplayerteam","bit":222,"width":18,"kind":"int","min":-1,"max":200000,"storage":"int"},{"name":"defaultplayerteam","bit":240,"width":18,"kind":"int","min":-1,"max":200000,"storage":"int"}],"rows":[{"defaultgkteam":10,"defaultgkid":150724,"defaultfourthofficial":52,"defaultlinesman1":359,"gamesettingscontext":1,"defaultplayerid":198710,"defaultfemalegkteam":113000,"defaultleagueid":13,"gamesettingspk":1,"defaultfemaleplayerid":226328,"defaultreferee":301,"defaultlinesman2":360,"defaultteamid":1,"defaultballid":100,"defaultfemalegkid":227400,"defaultfemaleplayerteam":113009,"defaultplayerteam":243},{"defaultgkteam":10,"defaultgkid":150724,"defaultfourthofficial":52,"defaultlinesman1":359,"gamesettingscontext":2,"defaultplayerid":198710,"defaultfemalegkteam":113000,"defaultleagueid":13,"gamesettingspk":2,"defaultfemaleplayerid":226328,"defaultreferee":301,"defaultlinesman2":360,"defaultteamid":1,"defaultballid":100,"defaultfemalegkid":227400,"defaultfemaleplayerteam":113009,"defaultplayerteam":243},{"defaultgkteam":10,"defaultgkid":150724,"defaultfourthofficial":52,"defaultlinesman1":359,"gamesettingscontext":3,"defaultplayerid":198710,"defaultfemalegkteam":-1,"defaultleagueid":13,"gamesettingspk":3,"defaultfemaleplayerid":-1,"defaultreferee":301,"defaultlinesman2":360,"defaultteamid":10,"defaultballid":100,"defaultfemalegkid":-1,"defaultfemaleplayerteam":-1,"defaultplayerteam":243},{"defaultgkteam":10,"defaultgkid":150724,"defaultfourthofficial":52,"defaultlinesman1":359,"gamesettingscontext":4,"defaultplayerid":198710,"defaultfemalegkteam":-1,"defaultleagueid":13,"gamesettingspk":4,"defaultfemaleplayerid":-1,"defaultreferee":301,"defaultlinesman2":360,"defaultteamid":10,"defaultballid":158,"defaultfemalegkid":-1,"defaultfemaleplayerteam":-1,"defaultplayerteam":243},{"defaultgkteam":10,"defaultgkid":150724,"defaultfourthofficial":52,"defaultlinesman1":359,"gamesettingscontext":5,"defaultplayerid":198710,"defaultfemalegkteam":-1,"defaultleagueid":13,"gamesettingspk":5,"defaultfemaleplayerid":-1,"defaultreferee":301,"defaultlinesman2":360,"defaultteamid":10,"defaultballid":23,"defaultfemalegkid":-1,"defaultfemaleplayerteam":-1,"defaultplayerteam":243}]}
fifa17-recon/data/tables/fifaGameSettings.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/fitnesscoachcards.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/fixtures.json
+1
View File
@@ -0,0 +1 @@
{"table":"fixtures","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":0,"rowsize_bytes":24,"rows_emitted":0,"rowblock":"0x42740ef8","rowblock_bytes":28833,"descriptor":"0x427568e8","schema":[{"name":"textid_gameotw","bit":0,"width":8,"kind":"int","min":0,"max":255,"storage":"int"},{"name":"predictedwinner","bit":8,"width":2,"kind":"int","min":0,"max":3,"storage":"int"},{"name":"hometeamid","bit":10,"width":18,"kind":"int","min":0,"max":200000,"storage":"int"},{"name":"fancards","bit":28,"width":1,"kind":"int","min":0,"max":1,"storage":"int"},{"name":"hometeamskill","bit":29,"width":3,"kind":"int","min":0,"max":7,"storage":"int"},{"name":"legno","bit":32,"width":1,"kind":"int","min":0,"max":1,"storage":"int"},{"name":"awayteamskill","bit":33,"width":3,"kind":"int","min":0,"max":7,"storage":"int"},{"name":"stageofcompetition","bit":36,"width":6,"kind":"int","min":0,"max":63,"storage":"int"},{"name":"competitionid","bit":42,"width":10,"kind":"int","min":0,"max":1023,"storage":"int"},{"name":"stadiumid","bit":52,"width":9,"kind":"int","min":0,"max":511,"storage":"int"},{"name":"fixturedate","bit":61,"width":20,"kind":"date","min":0,"max":1048575,"storage":"int"},{"name":"currawayprevscore","bit":81,"width":5,"kind":"int","min":0,"max":31,"storage":"int"},{"name":"drawmode","bit":86,"width":5,"kind":"int","min":0,"max":16,"storage":"int"},{"name":"competitiontype","bit":91,"width":3,"kind":"int","min":0,"max":4,"storage":"int"},{"name":"matchimportance","bit":94,"width":3,"kind":"int","min":0,"max":7,"storage":"int"},{"name":"fixtureid","bit":97,"width":18,"kind":"int","min":0,"max":200000,"storage":"int"},{"name":"multipleleg","bit":115,"width":1,"kind":"int","min":0,"max":1,"storage":"int"},{"name":"livegametype","bit":116,"width":3,"kind":"int","min":0,"max":7,"storage":"int"},{"name":"currhomeprevscore","bit":119,"width":5,"kind":"int","min":0,"max":31,"storage":"int"},{"name":"fixturetime","bit":124,"width":17,"kind":"int","min":0,"max":86400,"storage":"int"},{"name":"fanflags","bit":141,"width":1,"kind":"int","min":0,"max":1,"storage":"int"},{"name":"awayteamid","bit":142,"width":18,"kind":"int","min":0,"max":200000,"storage":"int"},{"name":"refereeid","bit":160,"width":10,"kind":"int","min":-1,"max":512,"storage":"int"}],"rows":[]}
fifa17-recon/data/tables/formationlayout.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/formations.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/fut_storymodehero.json
+1
View File
@@ -0,0 +1 @@
{"table":"fut_storymodehero","source":"FIFA17.exe resident database (tools/db_dump.py)","rowcount":80,"rowsize_bytes":8,"rows_emitted":80,"rowblock":"0x4280fa38","rowblock_bytes":673,"descriptor":"0x7b57648","schema":[{"name":"carddbid","bit":0,"width":31,"kind":"int","min":0,"max":2147483647,"storage":"int"},{"name":"teamid","bit":31,"width":31,"kind":"int","min":0,"max":2147483647,"storage":"int"}],"rows":[{"carddbid":22800,"teamid":1943},{"carddbid":22801,"teamid":1},{"carddbid":22802,"teamid":1952},{"carddbid":22803,"teamid":5},{"carddbid":22804,"teamid":1799},{"carddbid":22805,"teamid":7},{"carddbid":22806,"teamid":95},{"carddbid":22807,"teamid":9},{"carddbid":22808,"teamid":10},{"carddbid":22809,"teamid":11},{"carddbid":22810,"teamid":1796},{"carddbid":22811,"teamid":12},{"carddbid":22812,"teamid":17},{"carddbid":22813,"teamid":1806},{"carddbid":22814,"teamid":106},{"carddbid":22815,"teamid":1960},{"carddbid":22816,"teamid":18},{"carddbid":22817,"teamid":1795},{"carddbid":22818,"teamid":109},{"carddbid":22819,"teamid":19},{"carddbid":22820,"teamid":1943},{"carddbid":22821,"teamid":1},{"carddbid":22822,"teamid":1952},{"carddbid":22823,"teamid":5},{"carddbid":22824,"teamid":1799},{"carddbid":22825,"teamid":7},{"carddbid":22826,"teamid":95},{"carddbid":22827,"teamid":9},{"carddbid":22828,"teamid":10},{"carddbid":22829,"teamid":11},{"carddbid":22830,"teamid":1796},{"carddbid":22831,"teamid":12},{"carddbid":22832,"teamid":17},{"carddbid":22833,"teamid":1806},{"carddbid":22834,"teamid":106},{"carddbid":22835,"teamid":1960},{"carddbid":22836,"teamid":18},{"carddbid":22837,"teamid":1795},{"carddbid":22838,"teamid":109},{"carddbid":22839,"teamid":19},{"carddbid":22840,"teamid":1943},{"carddbid":22841,"teamid":1},{"carddbid":22842,"teamid":1952},{"carddbid":22843,"teamid":5},{"carddbid":22844,"teamid":1799},{"carddbid":22845,"teamid":7},{"carddbid":22846,"teamid":95},{"carddbid":22847,"teamid":9},{"carddbid":22848,"teamid":10},{"carddbid":22849,"teamid":11},{"carddbid":22850,"teamid":1796},{"carddbid":22851,"teamid":12},{"carddbid":22852,"teamid":17},{"carddbid":22853,"teamid":1806},{"carddbid":22854,"teamid":106},{"carddbid":22855,"teamid":1960},{"carddbid":22856,"teamid":18},{"carddbid":22857,"teamid":1795},{"carddbid":22858,"teamid":109},{"carddbid":22859,"teamid":19},{"carddbid":22860,"teamid":1943},{"carddbid":22861,"teamid":1},{"carddbid":22862,"teamid":1952},{"carddbid":22863,"teamid":5},{"carddbid":22864,"teamid":1799},{"carddbid":22865,"teamid":7},{"carddbid":22866,"teamid":95},{"carddbid":22867,"teamid":9},{"carddbid":22868,"teamid":10},{"carddbid":22869,"teamid":11},{"carddbid":22870,"teamid":1796},{"carddbid":22871,"teamid":12},{"carddbid":22872,"teamid":17},{"carddbid":22873,"teamid":1806},{"carddbid":22874,"teamid":106},{"carddbid":22875,"teamid":1960},{"carddbid":22876,"teamid":18},{"carddbid":22877,"teamid":1795},{"carddbid":22878,"teamid":109},{"carddbid":22879,"teamid":19}]}
fifa17-recon/data/tables/gkcoachcards.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/headcoachcards.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/leaguerefereelinks.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/leagues.json
+1
View File
File diff suppressed because one or more lines are too long
fifa17-recon/data/tables/leagueteamlinks.json
+1
View File
File diff suppressed because one or more lines are too long

Some files were not shown because too many files have changed in this diff Show More