funman300
e578443d73
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 correctse3092ca. 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 ine3092cais 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 ine3092caas 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 frome3092ca: 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 ine3092ca: "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>
78 lines
3.6 KiB
Python
78 lines
3.6 KiB
Python
"""Q5: resourceId decomposition, the value mappers, and who reads assetId (+0x20).
|
|
|
|
Established so far, and the reason for each question here:
|
|
* FUN_180141660's TAIL, reached on EVERY family including the no-merge default,
|
|
does record+0x54 = 3 if record+0xb4 >= 0x4b else 2 if >= 0x41 else 1. So +0x54
|
|
is the bronze/silver/gold CARD LEVEL derived from rating, not itemType.
|
|
* The players merge queries `players` by record+0x18 & 0xffffff and, on 0 rows,
|
|
OVERWRITES rating=0x32, attrs=1, teamid=0x78d, nation=0xe, position=2, name=" ".
|
|
* The item deser routes atom 0x1d1 nation to +0x148 for family 1 and +0xde for
|
|
family 2 and NOWHERE otherwise, and atom 0x18a leagueId always to +0xe0.
|
|
|
|
Remaining:
|
|
(a) FUN_180166ca0(resourceId, &out_byte, buf, &out_dword) -- the resourceId
|
|
decomposition. out_dword lands at record+0x18 and out_byte at record+0x24,
|
|
and +0x24 gates the "p%d.dds" FUTPlayerHeads photo registration. This decides
|
|
Q3: what resourceId actually has to look like.
|
|
CONTROL: DAT_7364642e642570 must read as "p%d.dds"; if it does not, my read of
|
|
the photo path is wrong.
|
|
(b) FUN_180136480 playStyle mapper, FUN_180166810 preferredPosition mapper,
|
|
FUN_180166660 itemState mapper, FUN_1801666f0 injuryType mapper.
|
|
(c) WHO READS record+0x20 (assetId)? Accessors FUN_1801a8020 and FUN_1801a8990
|
|
read it. Enumerate their callers. HYPOTHESIS: only the staff/manager card
|
|
art path, which the merge itself fills from the local DB, so a wire assetId
|
|
is dead for every family.
|
|
CONTROL: the same enumeration run on FUN_1801a87f0 (+0xb4 rating) must return
|
|
the publishers we already found. An enumeration that returns nothing for
|
|
rating is broken.
|
|
(d) FUN_1800d84e0 -- the value written to record+0x30.
|
|
(e) FUN_1801356c0 manager merge, for the family table.
|
|
"""
|
|
import traceback
|
|
|
|
try:
|
|
print("=== CONTROL: the format string at 0x1801eaf90..0x1801eafa8 region ===")
|
|
for a in (0x1801EAF98,):
|
|
print(" %#x -> %r" % (a, rd_str(a, 32)))
|
|
hits = find_all(b"p%d.dds")
|
|
print(" 'p%%d.dds' occurrences: %s" % " ".join("%#x" % h for h in hits))
|
|
for h in find_all(b"FUTPlayerHeads"):
|
|
print(" FUTPlayerHeads @%#x" % h)
|
|
|
|
print()
|
|
print("=== (a) FUN_180166ca0 resourceId decomposition ===")
|
|
print(dec(0x180166CA0))
|
|
|
|
print("=== (b) mappers ===")
|
|
for lbl, a in (("playStyle FUN_180136480", 0x180136480),
|
|
("preferredPosition FUN_180166810", 0x180166810),
|
|
("itemState FUN_180166660", 0x180166660),
|
|
("injuryType FUN_1801666f0", 0x1801666F0)):
|
|
s = dec(a)
|
|
print("--- %s len=%d" % (lbl, len(s)))
|
|
print(s)
|
|
|
|
print("=== (c) callers of the accessors ===")
|
|
for lbl, a in (("+0x20 assetId FUN_1801a8020", 0x1801A8020),
|
|
("+0x20/+0x4c FUN_1801a8990", 0x1801A8990),
|
|
("+0x1c cardassetid FUN_1801a8010", 0x1801A8010),
|
|
("+0x18 resourceId FUN_1801a80a0", 0x1801A80A0),
|
|
("CONTROL +0xb4 rating FUN_1801a87f0", 0x1801A87F0),
|
|
("+0x54 level FUN_1801a80c0", 0x1801A80C0),
|
|
("+0x54 FUN_1801a8870", 0x1801A8870),
|
|
("+0x54 FUN_1801a88f0", 0x1801A88F0)):
|
|
print("--- %s" % lbl)
|
|
for frm, typ, fn, ent in xrefs_to(a):
|
|
print(" %#x %-10s %s(%#x)" % (frm, typ, fn, ent))
|
|
|
|
print()
|
|
print("=== (d) FUN_1800d84e0 (record+0x30) ===")
|
|
print(dec(0x1800D84E0))
|
|
|
|
print("=== (e) FUN_1801356c0 manager merge ===")
|
|
s = dec(0x1801356C0)
|
|
print("len=%d" % len(s))
|
|
print(s)
|
|
except Exception:
|
|
traceback.print_exc()
|