funman300/OpenFUT-Bridge
1
0
Fork 0
Code Issues 4 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

docs: run 4 — EASFC connect subsystem is created-but-dormant

Browse Source 
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 <noreply@anthropic.com>
This commit is contained in:
funman300
2026-07-02 18:03:50 -07:00
parent ba7bb4f4be
commit 6bd1241bdf
1 changed files with 35 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/connection-gate-findings.md
+35
View File
@@ -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 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 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]]. 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).