The backend's inventory views and mana panel are fed by three streams the
original sent: the whole inventory after login, at logoff and on
/mm sendinventory; an add, update or remove per item as it enters,
changes in or leaves the packs; and the per-item cantrip state of worn and
wielded gear. This ports all three onto the host's object events, with the
frames built exactly as the original built them.
Behaviour kept: adds and removes go out at once, changes are coalesced into
one update per item on a two-to-five-minute timer re-rolled per flush; the
first login appraises everything worth appraising and waits before
sending; later logins merge in the saved appraisal data (kept in the
character's storage, as the original kept a file per character); the
mana panel debounces a quarter second and projects mana down between
reports.
Adapted to the host: appraisals go through a tick-driven queue, one at a
time, retrying while the host's single slot is busy; the login upload waits
for the inventory to stop arriving and for the socket, so it is not
written into a closed socket; the logoff upload subscribes ahead of the
root so the socket is still open; enchantment changes are polled once a
second (the host has no event); an item-cast enchantment is the one that
never runs out. A request the server never answers no longer holds the
upload back for good.
The Prismatic Taper count telemetry reads is InventoryFeature.PrismaticTaperCount.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The backend reads items in the shape the original plugin serialized them:
its item record's fields and every public getter, with property tables
keyed the way the original's client framework keyed them (raw property ids
mixed with framework pseudo keys). The record is carried over member for
member, with the getters' lookup tables verbatim, so Newtonsoft writes the
same members in the same order with the same JSON types.
The builder rebuilds the framework keys from what the plugin contract
exposes. Which keys exist, and when, follows the original's own item
dumps (3058 items): a header field's key is present exactly when the
server sent the field, the value key always (-1 when unsent), the
underlay key with the second header word, spell counts with a non-empty
appraised spell book, weapon and armor keys with their profiles; the
slot key never appears. Header words the contract does not expose yet
(header flag words, physics words, hook type, parent) sit behind one
seam that reports them absent, and while the header flags are absent a
field's presence falls back to its value being non-zero.
Tables are written in ascending key order: the original's order was its
framework's hash-table order and cannot be reproduced; the backend reads
by key.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The socket connects with the shared-secret header, registers first, reassembles
incoming frames of any size (the original dropped anything over 4 KiB) and
reconnects two seconds after a failure. Incoming share_* frames go to the
vital-sharing handlers; any other frame is a chat-box command for this
character, run one per tick through the chat bar as if typed. Frames are
written with Newtonsoft.Json defaults, the original's serializer, so the
backend sees the same bytes. The secret lives in the character's settings.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
