funman300
772f8a615a
Corrects the record against the CLIENT BINARY rather than library hearsay, using
the project's own reverse-engineering record
(fifa17-recon/docs/plan-2026-08-06-transfer-market.md, read out of the on-disk PE).
REVERTED (refuted): `tradeOwner`, `sellerId`, `offers`. FIFA 17's auctionInfo
deserializer (0x18013e410) reads exactly TWELVE atoms -- bidState, buyNowPrice,
currentBid, expires, itemData, sellerEstablished, sellerName, startingBid,
coinsProcessed, tradeId, tradeState, watched -- and value-SKIPs everything else at
0x180135ff0. Those three fields were added last commit on the strength of
contemporaneous FIFA 17 libraries; the PE says the client never reads them, so they
were inert and could not have been the Actions-panel gate. A preservation emulator
must not emit fields the client does not consume. New test pins the exact set.
ADDED: the auction clock. `expires` is SECONDS REMAINING (never an epoch) and the
client renders a LIVE COUNTDOWN it expects to reach 0. We hardcoded 3600, so no
auction ever aged or ran out. Now `duration` is taken from the ISStart body
(additive `duration_secs` column, defaulting to 3600) and `expires` is derived from
created_at + duration - now, clamped at 0. An active listing whose clock has run
out projects as `expired`/`none`/`expires: 0` -- FIFA 17's relistable state, per the
lifecycle table (active=1 inactive=2 expired=3 closed=4; none=0 outbid=1 highest=2
buyNow=3, both closed vocabularies). Pure projection: no row is mutated, so no
sweeper and no race with the economy.
ADDED: `duplicateItemIdList: []` on GetTradePile, which shares one deserializer
(0x18013e7f0) with ISSearch/ISWatchList over four members and we were omitting one.
CONFIRMED by the same source, so kept: `GET ut/{ns}/trade/status?tradeIds=a,b,c` is
real (ISVIEWTRADE) and my handler matches it exactly, including the comma list.
`ISREMOVETRADE` is `DELETE ut/delete/{ns}/trade/{tradeId}` -- our ORIGINAL spelling
was right. The plain-DELETE arm stays because the same source advises dispatching
on path and being method-agnostic (HTTP verbs are not statically recoverable).
Differential returns to strict key-set parity, with a comment recording WHY parity
is not sufficient: a field absent from both sides is invisible to it.
333 tests pass, 0 failed, clippy clean. Verified live: the twelve-atom record, the
four-member envelope, and the listing correctly reading expires=0 / expired after
aging past its hour.
openfut-utas-host
The first live FIFA 17 UTAS migration host. It fronts the client-visible UTAS port and migrates one route at a time to OpenFUT Core, proxying everything else to the Python UTAS oracle so the rest of FUT keeps working unchanged.
FIFA 17 ──HTTP──▶ openfut-utas-host
├── GET …/club ──▶ FIFA17 adapter ──▶ OpenFUT Core (/collection)
└── everything else ──▶ Python UTAS oracle (verbatim reverse proxy)
What it owns / does not own
Owns: socket + HTTP/1.1 keep-alive transport, route classification, the Core
access client, the Python passthrough, and diagnostics. It owns no game
domain state — filtering/pagination is Core's; wire parsing/shaping is the
adapter's. The adapter never learns how Core is reached (the architecture rule):
the host holds the [CoreAccess] boundary (GET {core_url}/collection?… today).
Safety model
- Classification happens once, before execution. Exact
GET /ut/game/<title>/club→ Rust; everything else → Python. No shared path, no "try Rust then Python". - A Core failure on
/clubdegrades to a valid empty{"itemData":[]}and logs an error — it never falls back to Python (which could double-apply a mutation on other routes)./clubis read-only, but the rule is absolute. - Mutating routes (PUT/POST,
/squad,/purchased, quick-sell, market, auth, SBC,/club/stats/*,/clubUser) all classify to passthrough and are untouched.
Configuration (env)
| Var | Required | Default | Meaning |
|---|---|---|---|
OPENFUT_UTAS_HOST_ADDR |
yes | — | where this host listens (client-visible UTAS addr) |
OPENFUT_UTAS_PYTHON_URL |
yes | — | Python UTAS oracle base URL for fallback (must differ from this host) |
OPENFUT_FIFA17_CATALOG |
yes | — | FIFA 17 card-definition identity catalog (Fifa17CardCatalog JSON: card id → asset id) |
OPENFUT_IDENTITY_STORE |
yes | — | persistent external-identity store file (owned instance → stable wire id) |
OPENFUT_PERSONA_ID |
yes | — | FIFA persona id stamped on GET /squad/active (must match the persona LSX/Blaze/POW/UTAS agree on) |
OPENFUT_CORE_URL |
no | http://127.0.0.1:8080 |
OpenFUT Core base |
OPENFUT_FIFA17_TABLES_DIR |
no | fifa17-recon/data/tables |
leagues/nations/teams.json for id⇄name |
Startup fails clearly if the catalog or identity store cannot be loaded — there is no placeholder fallback (exactly one production identity path).
Identity model (resolved)
FIFA renders an owned card by resolving resourceId & 0xffffff against the
client's own local players table; an invented id renders a blank generic
card (proven live — fut_cards.py:11-21). Two distinct identities, never
conflated, are resolved by [Fifa17IdentityResolver] (the single production path):
- Definition identity (
resourceId/assetId) — the card's real FIFA asset id, from the versionedOPENFUT_FIFA17_CATALOG. An unmapped definition is dropped and counted, never faked. - Instance identity (
id) — a stable, persistent, reversible wire integer from the genericopenfut-identitystore under the FIFA 17 wire-id policy (monotonic from100_000_001). The same owned instance keeps its id across restart and reverses exactly; two copies of one definition share aresourceIdbut get distinctids. The namespace is globally monotonic within(fifa17, owned-item)— no per-account column is needed because Core owned-instance ids are globally-unique UUIDs.
Remaining prerequisite for a rendering retail /club: Core inventory must
reference cards that exist in the catalog. The catalog + store + resolver are
built and tested; wiring a controlled real FIFA 17 dev-content inventory (the
curated per-game dev pack) is the next slice. rare=SP ("Special") stays
UNSUPPORTED (semantics unproven; parsed, reported, never guessed).
Retail A/B runbook (first /club gate)
Change only the UTAS routing layer; keep the validated Rust Redirector/Roster and the current Blaze path. Python remains the rollback oracle — do not modify it.
Preconditions (mirror the proven blaze/roster switch discipline):
cargo test -p openfut-utas-host -p openfut-adapter-fifa17green;clippy -D warningsclean;fmt --checkclean.- Built binary identity == HEAD (
scripts/verify-build-identity.sh); no dirty tree. - Python UTAS directly reachable; the Rust host directly probeable; no stale NAT/switch rules; FIFA fully closed.
Bring-up:
- Move Python UTAS to an alternate port (
FUT_PORT=8199in the container/openfut-fut.sh); it keeps serving there. - Start this host on the client-visible UTAS addr:
OPENFUT_UTAS_HOST_ADDR=<lan>:8099 OPENFUT_UTAS_PYTHON_URL=http://127.0.0.1:8199 OPENFUT_CORE_URL=http://127.0.0.1:8080 OPENFUT_FIFA17_CATALOG=<catalog.json> OPENFUT_IDENTITY_STORE=<store.json> OPENFUT_PERSONA_ID=33068179 openfut-utas-host - Launch FIFA → FUT → My Squad player picker and exercise: no-filter, position, nation, league, league+team, Gold+position, then scroll beyond page one.
Evidence to capture (all six):
- Switch: client traffic hits the Rust host.
- Rust positive: host log
owner=RUST route=club …for the client IP. - Python negative for /club: Python logs no
/clubrequest in the window. - Python positive for other UTAS: unimplemented routes still reach Python.
- Core positive: Core logs the
/collectionquery and returns the expected set. - Application + pagination: the UI shows filtered results; later pages differ from page one (no repeated-first-page amplification).
Rollback: point the UTAS addr back at Python directly; confirm FUT still usable;
then re-enable the host and confirm /club again (proves reversibility).
Logs are safe by construction: no auth/session/device/token material — only owner, route, filter summary, counts, status.