Asset Lifecycle
V1 separates physical file caching from server trust and activation.
Offer and consent
Section titled “Offer and consent”After authentication, the server offers one canonical item catalog and one PNG/OGG manifest. The player approves or declines a tuple containing the authenticated server fingerprint, catalog SHA-256, and manifest SHA-256.
A decline produces zero file requests and no activation. An unchanged approved tuple is reused on reconnect or native round restart; any changed tuple requires a new decision. An undecided or declined offer may prompt again for the new player instance.
Shared blobs, scoped provenance
Section titled “Shared blobs, scoped provenance”Verified file bytes live once in the shared SHA-256 FileCache. Consent remains in a separate server/catalog record, so possession of a blob never grants a different server permission to activate it.
The completed approved manifest is also the runtime authorization boundary: both server sends and client resource decoding require exact SHA-256 membership with the expected PNG or OGG kind. The authorization snapshot is cleared on decline, failure, replacement, and disconnect.
The index is replaced atomically. Startup reconciliation quarantines temporary, corrupt, orphaned, and invalid files, then enforces the cache budget.
Staging and commit
Section titled “Staging and commit”For a custom-item catalog, the client stages:
- Stock InventoryItemLoader template clones.
- Assigned ID and collision checks.
- PNG header/decode and decoded-allocation limits.
- Icon assignment.
- Display-name and description translation entries.
All definitions publish together or none publish. Only the exact activated digest is acknowledged to the server. CustomItems.TryGiveItem remains blocked until that acknowledgement matches server registration.
Player lifecycle
Section titled “Player lifecycle”Each player instance keeps its offered snapshot. Server file changes build offers for future player instances, reached by reconnecting or native round restart. V1 does not send destructive hot reload or generic spawn state to active players.
Before the next facility scene starts, the client revokes the old offer and asset authorization, removes materialized custom items, and clears texture overrides and added announcer vocabulary. The new player receives a fresh offer and must finish activation again. A native restart can preserve the authenticated connection; its encryption counters, disk cache, and persisted consent remain intact. Matching approved consent avoids another prompt, while cached bytes still require fresh authorization and activation.
Round, enrollment, and other non-asset state are independent of transfer. Asset-dependent state waits for approved successful activation; other authenticated late-join state does not.
Texture overrides
Section titled “Texture overrides”Anomaly.Server.Api.Assets.AssetOverrides applies manifest-backed PNG textures to existing network objects. SetTexture addresses a network ID, relative renderer path, and material index; SetPlayerTexture, SetRoomTexture, and SetDoorTexture accept native LabAPI wrappers. The server permits up to 32 override addresses per object and 1,024 in total. ClearTexture removes one address and ClearAll removes every override on an object. Room and door helpers require a network identity.
An override replaces the base-color texture on the selected renderer material. The client uses the shader’s declared main texture, then _BaseColorMap, _BaseMap, or _MainTex when available. Clearing restores the original texture on the same material property. A shader without a supported texture slot is left unchanged.
Supported formats and limits
Section titled “Supported formats and limits”- Remote PNG and OGG only.
- Custom items consume PNG only.
- 64 MiB per transfer-manifest file.
- 256 MiB per manifest.
- Encoded PNG: 16 MiB, 4096 pixels per dimension, and 16 Mi pixels.
- Encoded OGG: 32 MiB, two channels, 8-96 kHz, and 30 seconds.
- A retained decoded asset must fit 64 MiB; peak and process-wide decode budgets apply separately.
The remote content contract supports stock-template custom items, existing-object texture overrides, and announcer vocabulary. It does not transfer AssetBundles, meshes, arbitrary prefabs, or custom item models and weights. Local CASSIE OGG/WAV replacements use the separate audio catalog.
See Custom Items for the author workflow and Runtime Paths for cache and consent locations.
Continue to API and Namespace Index.