From bea3b49070f2b341fbc7174f91913444e6df54b3 Mon Sep 17 00:00:00 2001 From: funman300 Date: Fri, 21 Aug 2026 21:17:43 +0000 Subject: [PATCH] =?UTF-8?q?docs(fifa17):=20a=20LeagueName=5FAbbr=5F15=20pa?= =?UTF-8?q?th=20exists=20=E2=80=94=20recorded=20as=20a=20lead,=20not=20a?= =?UTF-8?q?=20fix?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit FUN_180098f20, previously described as the league-logo function with a hedged "localizedName, probably", read in full: it queries fcc_leaguelogos WHERE leagueid == %d, reads carddbid/value/cardassetid, and captions with 'LeagueName_Abbr_15_%d' in the 'FUT String' domain. A database-backed league name therefore exists, in exactly the shape kits use for teamid — so "cardtype 9 has no DB name resolver" is too strong for league logos. Deliberately NOT concluded: its only caller passes [rbx+0x20] as the league id, and rbx there is a loop cursor over small list elements (int/double/int), not the 0x158-byte card record. Reading that as the record's assetId and shipping "send leagueid as assetId" would be the exact inference this document exists to prevent. Recorded as a lead with the next question named: does the OWNED render path reach this resolver, and which field feeds it? --- .../docs/plan-2026-08-06-card-subsystem.md | 33 +++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/fifa17-recon/docs/plan-2026-08-06-card-subsystem.md b/fifa17-recon/docs/plan-2026-08-06-card-subsystem.md index 3e14abd..deef77d 100644 --- a/fifa17-recon/docs/plan-2026-08-06-card-subsystem.md +++ b/fifa17-recon/docs/plan-2026-08-06-card-subsystem.md @@ -431,6 +431,39 @@ nothing else. Ownership, `content_kind`, club/stats counting and restart durability are already in place for all three, so the probe is the only remaining work: the projection arm is a two-line change once the name is proven. +#### A lead on league logos: a `LeagueName_Abbr_15_%d` path DOES exist + +`FUN_180098f20` (named above as the league-logo function, hedged "localizedName, +probably") was read in full on 2026-08-21. It builds a real database query, and +the literals settle what it does: + +``` +table 'fcc_leaguelogos' +where 'leagueid' '==' %d ; the id arrives in r9d +columns 'carddbid' 'value' 'cardassetid' +caption 'LeagueName_Abbr_15_%d' ; a localisation key built from the league id +domain 'FUT String' +``` + +So a database-backed league NAME demonstrably exists in the client, keyed on +`leagueid`, in exactly the shape kits use (`TeamName_Abbr15_`). That +makes the blanket claim "cardtype 9 has no DB name resolver" too strong for +league logos specifically. + +WHAT THIS DOES NOT YET SHOW, stated plainly because the obvious next step is a +trap. Its ONLY caller is `0x180098da3`, and the `[rbx+0x20]` it passes as the +league id is NOT the item record: `rbx` is reloaded from `[rsp+0x48]` and +compared against an end pointer, i.e. it is a cursor over a list of small +elements (int at `+0x20`, double at `+0x24`, int at `+0x2c`), not the 0x158-byte +card record. So this is a CATALOG/BROWSE builder, and it is not established that +the owned-item render path reaches it at all. Reading `+0x20` as the record's +`assetId` and concluding "send the leagueid as assetId" would be exactly the +kind of inference this document exists to prevent. + +The lead worth following: find whether the owned cardtype-9 render path reaches +this resolver, and if so which field feeds the league id. If it does, league +logos need no `localizedName` at all and separate from the ball/misc gap. + --- ## 4. The card lifecycle