From 6bd1241bdfd362347fd338fd8ec4d2b19de9bc39 Mon Sep 17 00:00:00 2001 From: funman300 Date: Thu, 2 Jul 2026 18:03:50 -0700 Subject: [PATCH] =?UTF-8?q?docs:=20run=204=20=E2=80=94=20EASFC=20connect?= =?UTF-8?q?=20subsystem=20is=20created-but-dormant?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Probe shows connect states are constructed at boot (ctor x4) but never touched (GetConnState=0, no vtable method fires). The online-connect subsystem is dormant; nothing activates it. FIFA parks in the earlier EbisuSDK-login layer and never hands off to EASFC. Confirms we're at the M2/Blaze boundary with pre-Blaze infra present. Co-Authored-By: Claude Fable 5 --- docs/connection-gate-findings.md | 35 ++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/docs/connection-gate-findings.md b/docs/connection-gate-findings.md index 01bc5d9..0f79bfd 100644 --- a/docs/connection-gate-findings.md +++ b/docs/connection-gate-findings.md @@ -932,3 +932,38 @@ transition starts the EASFC connect** (idle connect-state → nucleusConnectREST probe next: the connect-state's earlier vtable steps (+0xa8/+0xb0 = +0x507cd60/+0x507cf90) to see if the state is entered-but-stalls vs never-entered, and the online-controller update that would advance it. Still a cost/priority call vs [[project_direction_pivot]]. + +--- + +## RUN 4 — the EASFC connect subsystem is created-but-dormant (2026-07-02) + +Probed the connect-state lifecycle to settle entered-but-stalled vs never-entered. + +| probe | enter | reading | +|---|---|---| +| `connectState.ctor` (+0x5078d20) | **4** | connect states ARE created (4 slots) at boot init | +| `ctrl.GetConnState` (+0x4f46570) | **0** | nothing ever reads/iterates the connect-state array | +| `connState.m_a8/m_b0/tick_b8/m_c0` | **0** | no vtable method ever invoked on any connect state | +| `nucleusConnectREST` (+0x2861910) | 0 | never reached | +| `OnlineStatus.deser` (+0x278a4d0) | 33 | control: our pushed events keep arriving/parsing | +| sampler `ctx[M+0x778]` | non-null, stable | control: session context exists throughout | + +**Definitive picture.** The EASFC/Nucleus online-connect subsystem is **constructed at boot +(as part of OriginSDK/`X` init — chain: connect-state ctor ← array-init +0x4f47920 ← ctor ++0x4f47b70 ← … ← OriginSDK ctor +0x279d5c0) and then left completely dormant**: its +connect-state array is built and never touched again — no iteration, no vtable call, no +connect attempt. So the block is not inside the connect flow at all; **nothing ever activates +the subsystem.** FIFA parks at "connecting to EA Servers" in the earlier EbisuSDK-login layer +and never hands off to EASFC. Our OnlineStatus/Login events parse and set FIFA's stored online +bool, but the game-side listener is a no-op (see run 2), so no active handler reacts to "online" +by starting EASFC. + +**What this means strategically.** Every object we can see (session context, connect states) +exists; the missing piece is the runtime *activation* of the online subsystem — the game's +top-level "go online" transition, which anadius (offline DRM) never drives and which our LSX +bridge does not reach. Pinning the exact dormancy guard (the EASFC controller's per-frame Update +early-returns before reading the array) is the identified next lever, BUT: forcing it only moves +FIFA to the *next* wall — dialing the Blaze redirector (gosredirector) and speaking Fire2 — which +is the full multi-month M2→M6 Blaze-emulation frontier. This run empirically confirms we are +standing exactly at the M2 boundary the status review priced, with the pre-Blaze infrastructure +proven present. Decision point vs [[project_direction_pivot]] (FLE career = stated primary plan).