funman300
897259c8fb
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>
41 lines
1.7 KiB
Python
41 lines
1.7 KiB
Python
"""Does a /settings flag gate the Seasons and Draft screens?
|
|
|
|
The hypothesis. Seasons refuses while making ZERO requests to any of the four
|
|
servers, so nothing on the wire can be wrong. A UI state key evaluated from a
|
|
client-side default explains that exactly. The settings deser writes
|
|
friendlySeasonsEnabled -> param_2[0x16] and enableDraftMode -> param_2[0x17], and
|
|
.rdata carries the UI keys IS_FRIENDLY_SEASON_ENABLED and IS_DRAFT_MODE_ENABLED.
|
|
|
|
This asks whether those two are the same value, and what it defaults to when the
|
|
configs array is empty (which is what the server has always sent).
|
|
|
|
A positive result is: the key's writer reads the settings field. A negative
|
|
result is: the writer reads something else, which kills the hypothesis cheaply.
|
|
CONTROL: IS_STORE_ENABLED, whose flag (storeEnabled -> param_2[0xb]) is attached
|
|
to a screen that is live-proven WORKING while we send an empty configs array, so
|
|
whatever it defaults to is a default that does NOT block.
|
|
"""
|
|
KEYS = ["IS_FRIENDLY_SEASON_ENABLED", "IS_DRAFT_MODE_ENABLED", "IS_STORE_ENABLED"]
|
|
|
|
for k in KEYS:
|
|
print("=" * 78)
|
|
print(k)
|
|
print("=" * 78)
|
|
hits = find_all(k.encode() + b"\x00")
|
|
if not hits:
|
|
print(" no string found -- check the literal")
|
|
continue
|
|
for h in hits:
|
|
print(" string @ %#x" % h)
|
|
xs = xrefs_to(h)
|
|
if not xs:
|
|
print(" NO XREFS (may be reached by table/pointer, not a direct lea)")
|
|
for frm, typ, fn, ent in xs:
|
|
print(" ref from %#x in %s (%#x)" % (frm, fn, ent))
|
|
|
|
print("\n\n" + "#" * 78)
|
|
print("# WHO CALLS THE SETTINGS DESER, and what object does it fill?")
|
|
print("#" * 78)
|
|
for a, n in callers(0x18013C6D0):
|
|
print(" %#x %s" % (a, n))
|