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:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user