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>
This commit is contained in:
funman300
@@ -1243,12 +1243,83 @@ reader → infinite spin at `0x1801c7f1a` (the hub freeze).
|
||||
- **Handled:** `utas_server.massinfo()` → `{userInfo, squad, settings, userData}`;
|
||||
`FUT_MASSINFO=full|squad|userinfo|settings|empty` bisects it one member per relaunch.
|
||||
|
||||
### FutGetSettingsServerResponse — CONFIDENCE: HIGH ✅ HANDLED
|
||||
- **Deser:** `0x18013c6d0`
|
||||
- **HTTP:** `GET ut/%s/settings`
|
||||
### FutGetSettingsServerResponse — CONFIDENCE: HIGH ✅ HANDLED (schema) / the 42 flags are RECOVERED, UNTESTED
|
||||
- **Deser:** `0x18013c6d0` (1982 bytes, 12061-char decompile, read end to end)
|
||||
- **HTTP:** `GET ut/%s/settings`, and the `settings` (0x2bf) member of `userMassInfo`
|
||||
(both callers of the deser: `0x18014e590` and `0x180174630`)
|
||||
- **Fields:** single wrapper key `configs` (0xa2) → array of config entries
|
||||
`{ type (0x354), value (0x377) }`.
|
||||
- **Handled:** `utas_server.SETTINGS = {"configs": []}`. Min JSON: `{"configs":[]}`.
|
||||
`{ type (0x354), value (0x377) }`. The key ladder really does hold nothing else.
|
||||
|
||||
**The mechanism the key ladder hides.** A flag is not a JSON key. When an element
|
||||
closes, the client feeds the STRING VALUE of `type` back through the atom hasher
|
||||
(`FUN_180180d00`) and switches on the result, 42 arms wide:
|
||||
|
||||
```json
|
||||
{"configs": [{"type": "friendlySeasonsEnabled", "value": 1}]}
|
||||
```
|
||||
|
||||
So the flag vocabulary is the same atom table everything else uses, and the client
|
||||
hashes our string itself — a flag cannot be misnamed silently, it simply falls
|
||||
through to the default arm and is ignored.
|
||||
|
||||
- **`value` is type-forgiving.** Its getter `0x1801c79d0` accepts int (token 2),
|
||||
float (3), bool (4) and string (5, via `sscanf "%I64d"`), coercing all four to
|
||||
int64. `1`, `"1"` and `true` are equivalent. This is one of the few scalar
|
||||
getters in the API with NO desync risk on scalars. An object or array is still
|
||||
a freeze.
|
||||
- **The applier demands exactly 1.** `FUN_18011dc50` is the only writer of the
|
||||
gate bytes and every line is `gate_byte = (field == 1)`. Not truthiness. `2`,
|
||||
`-1` and `"yes"` all read as OFF.
|
||||
|
||||
**Flags that publish a UI gate key.** `FUN_18006cc60` publishes IS_* state keys by
|
||||
reading single bytes inside `FutDataManagerImpl` (service id `0xed84b11`, ctor
|
||||
`0x18010cdc0`). Those bytes are written ONLY by the applier, and the ctor never
|
||||
touches them (whole 16620-char ctor scanned):
|
||||
|
||||
| flag `type` | field | gate byte | UI key |
|
||||
|---|---|---|---|
|
||||
| `tradingEnabled` | `[10]` | `0x1fd2e` | `IS_TRADING_ENABLED` |
|
||||
| `storeEnabled` / `_JP` | `[0xb]` / `[0xc]` | `0x1fd2f` / `0x1fd30` | `IS_STORE_ENABLED` (accessor `0x18011c600` picks `_JP` when region == 4) |
|
||||
| `friendlySeasonsEnabled` | `[0x16]` | `0x1fd3a` | `IS_FRIENDLY_SEASON_ENABLED` |
|
||||
| `tournamentQuitEnabled` | `[0x20]` | `0x1fd3b` | `IS_TOURNAMENT_QUIT_ENABLED` |
|
||||
| `processingStateEnabled` | `[0x21]` | `0x1fd3c` | `IS_PROCESSING_STATE_ENABLED` |
|
||||
| `enableDraftMode` | `[0x17]` | `0x1fd3d` | `IS_DRAFT_MODE_ENABLED` |
|
||||
| `enableOfflineDraftMode` = `enableSinglePlayerDraftMode` | `[0x18]` | `0x1fd3e` | (shared arm, one field) |
|
||||
| `storyModeRewardEnabled` | `[0x1f]` | `0x1fd3f` | `IS_STORY_MODE_REWARD_ENABLED` |
|
||||
| `returningUserRewardsScreenEnabled` | `[0x19]` | `0x1fd40` | `IS_RETURNING_USER_REWARDS_SCREEN_ENABLED` |
|
||||
|
||||
**Why this is the standing suspect for Seasons and Draft.** Both refuse while
|
||||
making zero requests to any of the four servers, which no response shape can
|
||||
explain. A UI key evaluated from a byte that nothing ever wrote does explain it.
|
||||
The store is the control: `IS_STORE_ENABLED` reads the same kind of byte and its
|
||||
screen works, because `storeEnabled` and friends are already shipped through the
|
||||
**Blaze** client-config store (`FUT_RS4_CONFIG` in `blaze_responder_v3b.py`) —
|
||||
and that list contains no seasons, draft or tournament flag. Same mechanism, one
|
||||
population, one blank.
|
||||
|
||||
This is a hypothesis with a mechanism, not a confirmed cause. It predicts that
|
||||
sending the flags opens the screens; if they still refuse, the gate is upstream
|
||||
of the UI key and the whole settings line is dead.
|
||||
|
||||
**Two arms that are not simple assignments:**
|
||||
- `enableObjectives` (0xfd) and `enableObjectivesAsManagerTasks` (0xfe) share an
|
||||
arm that can only ever CLEAR `[0x1c]`: `if (value == 0) field = 0`. Sending 1
|
||||
is a no-op. Objectives cannot be turned ON here, only off.
|
||||
- `clientKeepAliveResetTimeoutSec` (0x86, vtable +0x68) and `getOperationTimeoutSec`
|
||||
(0x13d, +0x58) do not store a field; they call a timer object with `value * 1000`.
|
||||
Sending a small number shortens client timeouts. Leave them alone.
|
||||
|
||||
**`maximumTradePileSize` (0x1c0) is the positive control.** It lands in `[0]` and
|
||||
is passed to `FUN_18011f380`, and transfer-list capacity is visible in game. It
|
||||
distinguishes "the flag did not help" from "the configs array never reached the
|
||||
consumer at all", which no boolean flag can do on its own.
|
||||
|
||||
**Not in the switch:** `enableSquadBuildingSetsFeature` (0x100) is a real atom but
|
||||
has NO arm here, so SBC is gated somewhere else. Scanned the full decompile;
|
||||
this absence is asserted over the whole function, not a slice.
|
||||
|
||||
- **Handled:** `utas_server.SETTINGS`, `FUT_SETTINGS` (default `gates`).
|
||||
`off` restores the historical `{"configs": []}`.
|
||||
|
||||
### FutGetHubDataServerResponse — CONFIDENCE: LOW (full schema) / HIGH (served {} works) — GAP
|
||||
- **Wrapper:** `0x1801736ad` → inner `0x180173a50` / `0x180173b10` / `0x180173c00`.
|
||||
|
||||
Reference in New Issue
Block a user