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>
20 lines
837 B
Python
20 lines
837 B
Python
"""The settings defaults, from the handler's own constructor.
|
|
|
|
FUN_18014e590 (the /settings body parser) writes the flag struct at object+0x28.
|
|
FUN_18014e2d0 sits in the same code region and is the sub-object constructor the
|
|
FutDataManagerImpl ctor invokes for that slot, so it should initialise those
|
|
fields. Byte offset of flag-table field N is 0x28 + N*4:
|
|
|
|
0x50 tradingEnabled[10] 0x54 storeEnabled[0xb] <- CONTROL, works today
|
|
0x80 friendlySeasonsEnabled[0x16] 0x84 enableDraftMode[0x17]
|
|
0x88 offline/singleplayer draft[0x18] 0x98 enableObjectives[0x1c]
|
|
"""
|
|
for va in (0x18014E2D0, 0x18014E590):
|
|
f = func(va)
|
|
src = dec(va)
|
|
print("=" * 78)
|
|
print("%#x body %d bytes / decompile %d chars (printed in full)"
|
|
% (va, f.getBody().getNumAddresses(), len(src)))
|
|
print("=" * 78)
|
|
print(src)
|