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>
