docs(fifa17): a LeagueName_Abbr_15 path exists — recorded as a lead, not a fix

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?
This commit is contained in:
funman300
2026-08-21 21:17:43 +00:00
parent e44c88dd68
commit bea3b49070
@@ -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_<teamid>`). 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