Resolved FeatureCatalog; telemetry now reads the taper count from the
inventory feature. The logoff inventory is sent from the feature's own
OnLogoff instead of a second host-logoff subscription whose correctness
depended on subscription order: the root logs features off in reverse, the
socket last, so the frame still leaves.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The original's appraisal time was the wall clock at the moment the
appraisal came in. The reader stamped it when it first built the record,
which for a coalesced update can be minutes later; the appraisal event now
stamps it.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
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>
record listens where the plugin is pointed (/mm ws url) and writes every
frame to a JSON-lines file; compare reports, per frame type, whether two
recordings have the same fields in the same order with the same JSON types.
A live headless run against the local server recorded register, telemetry,
vitals, chat, combat_stats, character_stats and the share_* frames, and the
unsubscribe at logout. The same tool records the DECAL plugin (point its
endpoint here) so the two can be compared.
Also ships Newtonsoft.Json beside the plugin (a class library does not copy
its package dependencies by default; the plugin failed to load without it).
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>
Fields, order and types as the original sent them. Values follow the
original's client library where it matters: race and gender are the player's
string properties, birth the creation time as a US date (explicit pattern, so
no newer-culture space quirk), burden the units over 150 times effective
strength truncated to a percent, capacity with the carrying augmentation, and
properties the player's integer properties minus the original's blacklist.
Attributes, vitals and skills carry unbuffed values, creation being the value
before experience was spent. Titles, the allegiance tree and luminance total
come through seams that the plugin API additions fill; until then they are
null, as the original sent them before the matching server message arrived.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Resolved FeatureCatalog (both blocks kept; the main window's Tools buttons now
open the Mossy Tracker and Metas panels). Tests from both sides adjusted to
the combined plugin: quest tests look at quest frames only (chat is streamed
too), and the stream tests ignore the /myquests request sent at login.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
start_radar/stop_radar from the backend drive it, as before. nearby_objects
keeps the original's shape: map coordinates on the surface, landblock-local
raw positions with zero map coordinates in a dungeon, ids as signed ints, the
same eight object classes, no wielded items or self. dungeon_map is built the
original's way from the landblock's cells (x a multiple of 10, whole metres,
6-metre floors, rotation = the orientation's stored W) and sent once per
landblock per session; the cells come through a small reader that the
plugin API's dungeon-cell data will fill (until then the map is not sent).
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The original kept VTank's profile folder in step with the club's metas
repository; the port does the same against host.VtankProfiles, dropping
.met files under mosstank/metas and .nav files under mosstank/navs where
MossTank reads dropped profiles, flattened to their bare names as the
original flattened them. The Gitea tree and raw endpoints are the
original's; the repository address is the metas_repository_url setting,
defaulting to the original repository. An overwritten file keeps its old
copy as .bak (MossTank's pickers skip .bak side files).
Storage is text-only, so the SHA-256 compare hashes the text a stored read
gives back (UTF-8, BOM dropped); for the plain-text files in the repo that
equals the original's byte compare. Network work runs on the thread pool,
one operation after another; chat lines and window updates are applied on
the tick. The four /mm verbs keep their chat lines, and the Metas tab is
its own markup window with IsVisible for the main window to open.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The original's DxHud overlay: the player's row, then one per character heard
from, each a health bar over split stamina and mana bars with percentages,
and for the others an arrow toward them relative to where the player faces
plus the distance, fading from white to red as they get further. Ctrl shows
a frame and a close box; Ctrl+drag moves it and the spot is saved per
character. /mm vitalsharing overlay toggles it.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Outgoing, the original's share_* frames byte for byte: subscribe with the
player id on start and without it after every reconnect, vitals on change or
every 3 s, position on change or every 10 s, the item heartbeat every 5 s,
unsubscribe on stop. Debuff casts come from the host's peer network: the
attempts and landings the bot announces, plus the player's own completed
casts, so a hand-cast debuff is shared once it lands (a plugin cannot see
outgoing packets, so hand-cast attempts are not). Ids stay signed ints, skill
a double, duration_ms the spell's duration.
Incoming, another computer's characters and casts go into the host's peer
network (the new relay imports), where the bot reads them exactly as it reads
characters on this computer: vitals and position for heals, landed debuffs
for target choice. Peers not heard from for 15 s drop out; the original kept
them forever. Logoff now runs features in reverse so the unsubscribe leaves
before the socket closes, and stopping the socket flushes what was queued.
Builds against a preview of the plugin API with the peer relay
(0.1.19-mmpreview.1, packed from the relay commit); switch to the released
package when it exists.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The owner calls the flag tracker important, so the original's pages come
across with their tables unchanged: augmentations and luminance auras from
the player's own int properties (the object table carries them), recalls
from the spellbook with composited spell icons, cantrips matched from the
active enchantments to trained skills, attributes and wards, the tracked
weapons the original kept data for but never showed, and the quest timers.
Read on the tick thread at login and on each page's Refresh; the quest
page redraws every five seconds instead of from a thread-pool timer.
The root panel's visibility is the settable IsVisible so the main window
can open it; the three sections the original left as stubs stay out, and a
headless host registers nothing. The fake spell catalog learns IsKnown.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The original's notebook without the parts OpenAC or another plugin now owns
(updater, VTank path, route visualisation, chest looter). Labels read live
from the trackers each frame. Settings gains the backend URL and shared-secret
fields, since the secret is no longer compiled in. Tools opens the Mossy
Tracker and Metas windows through openers their features set. The WebSocket
label now shows the real connection state rather than the setting.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The backend's quest panel shows the stipend, blank aug gem and insatiable
jaw timers from the `quest` frame, so the port reads /myquests the way the
original did (a three-second window of chat lines matched by its regex)
and streams the three priority stamps every 30 s with the same five-field
frame and the same countdown strings. The name table is copied as it was,
so the duplicate insatiableeaterjaw entry still resolves to the later name.
Timers run on the tick scheduler instead of thread-pool timers.
The session tests clear the login-time /myquests before counting the
commands the backend ran.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The frames the backend reads most, each pinned by a golden test written from
the original's source (field order, JSON types, string-formatted numbers,
mem_mb in bytes, the PascalCase aggregates Newtonsoft emits for combat_stats).
Coordinates repeat the original's float arithmetic from the landblock-local
float, so ew/ns carry the same float-widened values as before. Telemetry goes
out on connect and every 5 s, vitals every 5 s, combat stats every 10 s when
dirty. The rare meta-state switch is not carried over (owner decision); the
allegiance rare announcement and the !report reply are. Kill patterns and
combat patterns are the original's, unchanged.
Also fixes the tick scheduler re-arming repeating jobs from now instead of
from their due time, which made every cadence drift a frame late per period.
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>
