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>

fifa17-recon/tools/utas_server.py

@@ -460,8 +460,79 @@ def club_rename_route(h):
     return 200, {}
 
 
-# GET ut/game/<sku>/settings (0x18013C6D0) recognises ONE key: configs (0xa2).
-SETTINGS = {"configs": []}
+# GET ut/game/<sku>/settings (0x18013C6D0) recognises ONE key: configs (0xa2),
+# an array of {type(0x354), value(0x377)}. The flag is not the JSON key: the
+# client hashes the STRING VALUE of `type` through the atom hasher FUN_180180d00
+# and switches on it, 42 arms wide. See ENDPOINT_MAP "FutGetSettingsServerResponse".
+#
+# WHY THIS IS NOT `{"configs": []}` ANY MORE. The applier FUN_18011dc50 is the only
+# writer of the IS_* UI gate bytes and every line is `byte = (field == 1)`. The
+# FutDataManagerImpl ctor never touches those bytes. So a flag we do not send is a
+# gate that is never opened, and IS_FRIENDLY_SEASON_ENABLED / IS_DRAFT_MODE_ENABLED
+# have never been sent by anything. That is a mechanism for the standing bug where
+# Seasons refuses while making ZERO requests to any of the four servers.
+#
+# FREEZE SAFETY. `value`'s getter 0x1801c79d0 takes int/float/bool/string and
+# coerces to int64, so a scalar cannot desync the token reader here. Ints are used
+# below. Never put an object or an array in `value`.
+#
+# THE STORE FLAGS ARE RE-ASSERTED DELIBERATELY. storeEnabled/coinEnabled/... reach
+# the client today through the BLAZE config store, not through here, and the store
+# screen is live-proven working. Once a populated configs array makes the applier
+# run, it writes EVERY gate byte from this struct, so omitting them could turn the
+# working store off. Sending them as 1 pins them to the state they are already in.
+_SETTINGS_MODE = os.environ.get("FUT_SETTINGS", "gates")
+
+# Flags that are already live-proven ON via the Blaze store. Re-asserted so the
+# applier cannot regress a working screen. Keep in sync with FUT_RS4_CONFIG.
+_SETTINGS_KEEP = (
+    "storeEnabled", "storeEnabled_JP", "coinEnabled", "coinEnabled_JP",
+    "cardPackStoreEnabled", "cardPackStoreEnabled_JP", "pointsPackStoreEnabled",
+    "tradingEnabled",
+)
+
+# The gates nothing has ever populated. These are the point of the exercise.
+_SETTINGS_GATES = (
+    "friendlySeasonsEnabled",        # [0x16] -> 0x1fd3a -> IS_FRIENDLY_SEASON_ENABLED
+    "enableDraftMode",               # [0x17] -> 0x1fd3d -> IS_DRAFT_MODE_ENABLED
+    "enableSinglePlayerDraftMode",   # [0x18] -> 0x1fd3e (shares its arm with
+    "enableOfflineDraftMode",        #           enableOfflineDraftMode)
+    "tournamentQuitEnabled",         # [0x20] -> 0x1fd3b -> IS_TOURNAMENT_QUIT_ENABLED
+)
+
+# NOT sent, and each for a reason:
+#   enableObjectives / enableObjectivesAsManagerTasks -- their shared arm can only
+#     CLEAR the field (`if (value == 0) field = 0`), so 1 is a no-op and 0 would
+#     switch objectives OFF. Nothing to gain, something to lose.
+#   clientKeepAliveResetTimeoutSec / getOperationTimeoutSec -- these do not set a
+#     field, they reprogram client timers with value*1000.
+#   itemDbVersion / checkServerDbVersion -- checkServerDbVersion makes the client
+#     go read a server_db_version config; leave the DB-version path alone.
+#   enableSquadBuildingSetsFeature -- a real atom with NO arm in this switch, so
+#     it does nothing here whatever we send.
+
+# The positive control. maximumTradePileSize lands in field [0] and feeds
+# FUN_18011f380, and transfer-list capacity is READABLE IN GAME. Without it a null
+# result is ambiguous between "the flags did not help" and "the configs array never
+# reached the consumer". With it, those two look different.
+_SETTINGS_PROBE = (("maximumTradePileSize", 100),)
+
+
+def _settings_body():
+    """off  -> the historical {"configs": []} baseline.
+       keep -> re-assert only the already-working flags, plus the control. Isolates
+               "does populating configs at all change anything" from the new gates.
+       gates-> keep, plus the gates nothing has ever sent. The actual experiment."""
+    if _SETTINGS_MODE == "off":
+        return {"configs": []}
+    rows = [{"type": k, "value": 1} for k in _SETTINGS_KEEP]
+    if _SETTINGS_MODE == "gates":
+        rows += [{"type": k, "value": 1} for k in _SETTINGS_GATES]
+    rows += [{"type": k, "value": v} for k, v in _SETTINGS_PROBE]
+    return {"configs": rows}
+
+
+SETTINGS = _settings_body()
 
 # GET ut/game/<sku>/userMassInfo (GetUserMassInfo, deser FUN_180174630).
 #