From 022634704a04bc57026c11280ec97e201b8db8e4 Mon Sep 17 00:00:00 2001 From: funman300 Date: Tue, 18 Aug 2026 03:49:39 +0000 Subject: [PATCH] fix(scripts): staging squad now matches production's known-good shape exactly Adds the manager reference, the last remaining difference from the squad the same client demonstrably accepts. Staging's squad shape is now identical to production's: zero missing keys, zero type differences, zero empty-vs-populated mismatches. The manager looked unfixable. Production points at instance 100000427 while the staging club holds 11 players and zero staff, so there was apparently nothing to reference, and inventing an id would have pointed at a non-existent item. Checking production properly dissolved the problem: 100000427 is absent from production's OWN club listing too. /club/staff returns 1975 items spanning ids 100000001..100004826 and 100000427 is not among them, and the type=staff/type=manager filters are ignored (200 players either way). Production's manager reference is dangling and the client accepts that squad anyway, which proves the client does not validate the manager id against the club -- only a populated array matters. So the reference is mirrored verbatim, dangling id included. That replicates the known-good state exactly and is better than pointing the manager slot at a player, which would have been a guess dressed up as a fix. Method note: every step here came from diffing against production rather than reading the client. The host reported squad-active 200 outcome=ok throughout, and 200 with the right players was never evidence the client accepted the body. --- scripts/sold-staging-seed-squad.py | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-) diff --git a/scripts/sold-staging-seed-squad.py b/scripts/sold-staging-seed-squad.py index 0e4cae4..f9b060b 100755 --- a/scripts/sold-staging-seed-squad.py +++ b/scripts/sold-staging-seed-squad.py @@ -37,6 +37,10 @@ LINEUP = ["GK", "RB", "CB", "CB", "LB", "CM", "CM", "CM", "RW", "ST", "LW"] FORMATION = "f433" SQUAD_TYPE = "REGULAR_SQUAD" CHEMISTRY = 50 +# Production's squad-manager reference, mirrored verbatim; it resolves to nothing in +# production either (absent from its own /club/staff listing), which is exactly why +# copying it is safe. +PRODUCTION_MANAGER_REF = 100000427 # Production's opaque 33-int tactics array. Never parsed server-side; reused because # only the shape (a JSON-encoded int array, not null) matters to the client. CUSTOM = ("[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0," @@ -120,11 +124,20 @@ def build_put(chosen): # Production carries five, all pointing at one player. Mirrored so the # array is populated rather than empty. "kicktakers": [{"index": i, "id": captain, "dream": False} for i in range(5)], - # Left empty deliberately: production references an owned staff instance - # (100000427) and the staging club holds 11 players and zero staff, so - # there is no manager to point at. Inventing an id would reference a - # non-existent item. This is the one remaining shape difference. - "manager": [], + # Mirrors production's manager reference verbatim, including the fact that + # the id resolves to nothing. + # + # This looked unfixable at first: production points at instance 100000427 + # while the staging club holds 11 players and zero staff, so there was + # apparently no manager to reference. Then checking production properly + # showed 100000427 is absent from its OWN club listing too -- + # /club/staff returns 1975 items spanning ids 100000001..100004826 and + # 100000427 is not one of them. Production's manager reference is dangling + # and the client accepts that squad regardless, which proves the client does + # not validate the manager id against the club. Only a populated array + # matters, so replicating the known-good state exactly is both faithful and + # sufficient -- and it beats pointing the manager slot at a player. + "manager": [{"id": PRODUCTION_MANAGER_REF, "dream": False}], }