@genex-ai/multiplayer 0.17.8 → 0.17.9

package/PROTOCOL.md

@@ -1318,7 +1318,7 @@ Then `actions` held inputs, ascending seq, each `seq` uint32, `tick` uint16, `re
 **Downlink snapshot** (`kind` 2). Each seat gets its own snapshots: the room's *motion records* (below), delta-coded against the newest snapshot that seat acknowledged. A fragment has 29 bytes of header: `sid` uint32 · `snap` uint32 (the snapshot id, from 1, rising by at least one per snapshot) · `base` uint32 (the snapshot the delta is against; 0 for a keyframe) · `tick` uint32 (the server tick it was written at) · `inputAck` uint32 (the seat's last accepted input seq) · `flags` uint8 (bit 0 *keyframe*, set exactly when `base` is 0) · `frag` uint8 · `frags` uint8 (`frag < frags ≤ FAST_MAX_FRAGMENTS`, 32) · `sent` uint32 (the room clock, ms since room start, when the server wrote the snapshot: the `sNow` a WebSocket patch's TIMED prefix carries, §16.1), then that fragment's slice of the body. The body, split into slices of at most `FAST_MAX_DATAGRAM_BYTES − 29` bytes, is `removed` uint16 and that many record keys uint16, ascending, then `records` uint16 and that many records, ascending by key, each `key` uint16, `len` uint16 (at most `FAST_MAX_RECORD_BYTES`, 1024) and `len` bytes. A delta lists the records new or changed since `base` and the keys gone since it; a keyframe lists every record and removes nothing. The server keeps its last `FAST_SNAPSHOT_HISTORY` (32) snapshots per seat and writes a delta against the seat's `ackSnap` while it holds that snapshot, else a keyframe.
 **Partial snapshots** (authority-host `fast-snapshots.ts`). Each seat has a byte budget, a token bucket at its share of the room's rate (§17.6 *The downlink budget*) with a burst of one snapshot of `FAST_MAX_FRAGMENTS` full fragments. A snapshot that fits both is written as above, byte for byte. One past either is never dropped: it goes as a partial snapshot, its body cut to what the budget holds (at least one fragment, so the seat's ack always flows and the channel never looks dead). It needs no wire change and every client applies it. The records it carries are chosen by weight times age: the seat's own record and its own entity always go, then the other seats, then each entity by how near yours it is (`motionWeights`), and each record passed over ages, so none starves. A record that changed and is passed over is listed under `removed` when the base holds it: the client's newest snapshot no longer carries it, its state keeps the last value and a predicting client keeps the body out of the keyframe it adopts (`motionKnown`, *Client* below), never adopting old motion as current. The next delta is written against what the client will hold, so what was passed over goes out later. The endpoint counts each snapshot by shape (`stats().snapshots`: `whole`, `partial`, `refused`, and `deferred` records), under `fast` on the metrics endpoint. Measured on loopback UDP (`test/fast-many.test.ts`): a seat joining a physics room of 1,016 moving entities, whose keyframe is about 90 KB, used to get nothing and fell back at the handshake deadline; it now stays on the channel with every entity moving and no gap between snapshots over 500 ms, and so does one held to 48 KiB/s for a whole take.
 
-**Motion records** (`src/authority/fast-records.ts`, `encodeRecord`/`decodeRecord`). Each record is one entity's or one seat's: `kind` uint8 (`MotionRecordKind`: 1 entity, 2 seat), `idLen` uint8 and that many UTF-8 bytes of the entity id or seat session id (1 to 64 characters), a `mask` uint32 whose bit *i* says field *i* is present, then each present field in table order. An entity's fields, bit 0 up: `x` `y` `z` `vx` `vy` `vz` `yaw` `pitch` `duck` `spin` `fuel` float32; `epoch` `mstate` uint32; `qx` `qy` `qz` `qw` (orientation, [−1, 1]) and `lvx` `lvy` `lvz` `avx` `avy` `avz` (velocity, [−64, 64]) as uint16 codes of the schema's own quantize (clamp, span 2^16 − 2, half-up, so 0 is code 32767 and a fast seat decodes bit for bit what a WebSocket seat decodes); `sleep` (the bit alone); `rest` uint16. A seat's: `inMoveX` `inMoveY` `inMoveZ` `inYaw` `inPitch` float32; `inButtons` `inRep` `inStarve` `inBuf` `inAck` uint32, `inAck` being, in the receiving seat's own record only, its last input the server consumed (stepped or skipped) as of the snapshot, which its reconciler replays from (the header's `inputAck` is the last *accepted*, which trims actions). A field at its default (0, −0, false, never written) is left out and a field present at its default is a fault, so the bytes are canonical and a delta carries a record only when one of its fields changed; a field left out reads as its default. The entity's other fields (`kind`, `owner`, `hp`, `flags`, `data`, projectile and `cap` fields) and everything else in the state stay on the reliable channel. The server gives each live id a record key (uint16) of its own for the room; a client reads the id from the record, never from the key. A decoder drops, with its `FastFault`, a record of another kind, one that is truncated or has bytes left over, an empty, over-long or malformed id, an unknown mask bit, or a present field at its default, non-finite or past its span; a client leaves that id as it was.
+**Motion records** (`src/authority/fast-records.ts`, `encodeRecord`/`decodeRecord`). Each record is one entity's or one seat's: `kind` uint8 (`MotionRecordKind`: 1 entity, 2 seat), `idLen` uint8 and that many UTF-8 bytes of the entity id or seat session id (1 to 64 characters), a `mask` uint32 whose bit *i* says field *i* is present, then each present field in table order. An entity's fields, bit 0 up: `x` `y` `z` `vx` `vy` `vz` `yaw` `pitch` `duck` `spin` `fuel` float32; `epoch` `mstate` uint32; `qx` `qy` `qz` `qw` (orientation, [−1, 1]) and `lvx` `lvy` `lvz` `avx` `avy` `avz` (velocity, [−64, 64]) as uint16 codes of the schema's own quantize (clamp, span 2^16 − 2, half-up, so 0 is code 32767 and a fast seat decodes bit for bit what a WebSocket seat decodes); `sleep` (the bit alone); `rest` uint16. A seat's: `inMoveX` `inMoveY` `inMoveZ` `inYaw` `inPitch` float32; `inButtons` `inRep` `inStarve` `inBuf` `inAck` uint32, `inAck` being, in the receiving seat's own record only, its last input the server consumed (stepped or skipped) as of the snapshot, which its reconciler replays from (the header's `inputAck` is the last *accepted*, which trims actions). A field at its default (0, −0, false, never written) is left out and a field present at its default is a fault, so the bytes are canonical and a delta carries a record only when one of its fields changed; a field left out reads as its default. The entity's other fields (`kind`, `owner`, `hp`, `flags`, `data`, projectile and `cap` fields) and everything else in the state stay on the reliable channel. A projectile (an entity with `t0` > 0) has no record at all: its `x`..`vz` are its launch, read with `t0`, `g` and `src`, so the whole launch stays on the reliable channel and is never muted there (*Downlink*). Split across the two channels, a bounce's re-launch was drawn as the new flight from the old `t0` (or the old flight from the new one) until the other half landed: 7 to 38 units off on Unreal's projectile smoke over UDP. The server gives each live id a record key (uint16) of its own for the room; a client reads the id from the record, never from the key. A decoder drops, with its `FastFault`, a record of another kind, one that is truncated or has bytes left over, an empty, over-long or malformed id, an unknown mask bit, or a present field at its default, non-finite or past its span; a client leaves that id as it was.
 
 **Applying a snapshot** (`receiveFragment`, the client). A fragment whose `sid` is not the seat's is dropped. Fragments are gathered by `snap`; one whose header differs from its set's first (`base`, `tick`, `inputAck`, `flags`, `frags`, `sent`), or a duplicate, is dropped; at most `FAST_REASSEMBLY_SLOTS` (4) sets are gathered at once, the oldest giving way. A complete set is applied when its `snap` is newer than the newest applied and its base is a snapshot the client still holds (its last `FAST_SNAPSHOT_HISTORY` applied) or it is a keyframe; otherwise it is dropped, and so is a body that does not parse to the byte. Applying it copies the base's records, removes the removed keys, writes the records, and makes it the newest: its id is the next `ackSnap`, and its `inputAck` the ack `uplinkFor` trims actions by. Applying drops every incomplete set at or below the new snapshot: a lost fragment loses its snapshot, never the next one.
 
@@ -1329,7 +1329,7 @@ Then `actions` held inputs, ascending seq, each `seq` uint32, `tick` uint16, `re
 **Return to the channel** (`fast-session.ts`, authority-host `room.ts`). A fallback is not for the rest of the socket: a client that sends `fast-return@1` beside `fast@1`, in a room whose binding says `rev` ≥ 2, comes back by itself. It never moves until the path is proven, at the start too, so a network that blocks UDP costs it nothing. (1) The server offers such a seat `__fast` with `probe: true`, at join and at each reconnect, and answers its `__fast:again` `{}` the same way: a fresh `sid` and `key`, at most one per `FAST_AGAIN_MIN_MS` (500 ms) a seat, none while the seat is live or the switch is off; once the switch is on it offers one, unasked, to a seat that has none. An older client's first binding is as it always was. (2) The WebSocket carries everything while the seat proves the path: it sends empty uplinks, its address is challenged (*Return path*) and it applies snapshots, writing none of them anywhere, until it holds `FAST_RETURN_PROOF` (3). Anything it sends by datagram before step 3 waits on the server. (3) At the third it swaps, at one instant: `__fast:on` `{ last }` (the last seq it sent by WebSocket) goes on the socket after its last input frame, its next input goes by datagram as `last + 1`, and that snapshot is written whole, as a first one is. (4) The server reads `__fast:on` after every WebSocket input it follows, because TCP keeps their order: what its buffer still holds goes first, numbered as it would have been, then the parked datagrams from `max(last, received)` (at most 512 parked, a longer stall being the gap rule's), so no input is lost or stepped twice, however long TCP held the message. A WebSocket input stepped this way is judged at the seat's newest stamp. A physics room sends motion by WebSocket until the seat is live on the new binding and has acknowledged a snapshot that carries motion. A `__fast:on` that is malformed, past `FAST_SEQ_AHEAD_MS` of what was received or with no binding being proven changes nothing. (5) A socket that has to open (WebTransport) gets the same deadline on a fresh binding as on any: `FAST_HANDSHAKE_MS` or `FAST_OPEN_ROUND_TRIPS` of the seat's round trips, whichever is longer, to open, then `FAST_HANDSHAKE_MS` to the first snapshot; none of it costs an input, as the WebSocket has them. Measured on a session taking 1.5 s to open at 500 ms round trip: 86 and 87 of about 508 inputs lost with the seat's inputs on the datagrams while it opened (only the newest 32 survive the wait), 0 of 511 and 512 here. A proof that misses a deadline (*Fallback*) goes back: `__fast:off` `{ last }` closes that binding, the numbering unchanged, and `fallback` says why the seat is on the WebSocket. The retries: `fastRetryDelayMs(attempt, unit)`, doubling from `FAST_RETRY_BASE_MS` (1 s) to `FAST_RETRY_MAX_MS` (60 s), half of it random, forever; an ask that is answered does not climb, and a channel held for `FAST_RETURN_STABLE_MS` (30 s) starts over from 0, so a flapping path backs off; after the server's own `__fast:off` the first is 4 to 8 s on. An older host's binding has no `rev`: its seat sends no empty uplink and no `__fast:again` (Colyseus closes a socket over a message with no handler), and falls back as it always did. `status.fallbacks` and `status.returns` count. Measured on loopback UDP through the NAT rig (`test/fast-return.test.ts`): snapshots cut for 3 s, back on UDP within 3 s, every input once in order, 3 cuts in a row the same; on UDP 135 to 151 ms after the seat appears at 80 ms round trip; UDP blocked from the first datagram, 0 of 139 inputs lost, against 56 of 138 before (the first ones to reach the module were seq 57). Both ways cut, the inputs sent by datagram into the cut are still skipped by the gap rule (119 of 391): they are 2 s old, and a late step is worse.
 **Downlink.** In a physics room (§17.10: every client has a view) the state's entities are `AuthorityPhysicsEntity`, `AuthorityEntity`'s fields in its order under its name (decoders and the handshake's type description are unchanged), whose motion fields (an entity record's, *Motion records* below) carry the Colyseus view tag `MOTION_VIEW_TAG`; every entity enters a view with it. Once a fast seat has acknowledged a snapshot (`ackSnap` past 0) while its binding is open, each entity its view introduced in an earlier patch leaves its view's tag, silently (no delete reaches the client): its WebSocket carries that entity's other fields, the seat echoes and the root's `tick` and `keyframe`, never its motion. When the channel closes (the seat's `__fast:off` or the server's), or the socket reconnects, every such entity's motion is sent again in full in the next patch (or the reconnect's first state). A room without physics writes motion to every seat's WebSocket as before. **Liveness.** A datagram that passed a seat's binding proves its client alive: it answers the WebSocket transport's heartbeat for the seat's socket (uWebSockets.js, the production transport, closes a socket only after `idleTimeout`, 60 s, without a frame; every server on Colyseus's ws transport, the dev server, the bench's rooms and parks, runs its heartbeat at that deadline, 4 unanswered 15 s pings, `WS_TRANSPORT_HEARTBEAT`, where its default of 2 unanswered 3 s pings closed seats production keeps through a long route's TCP stall), so a TCP stall the datagrams outlive never closes a playing seat. A fast seat whose socket did drop keeps its snapshots, of the view it dropped with, through the reconnection grace, while its datagrams still feed the module.
 
-**Client** (`src/authority/fast-client.ts`, `fast-session.ts`; `fast-udp.ts` the Node socket, `fast-default.ts` finding it at run time so no browser bundle links it, `fast-webtransport.ts` the browser's). A client with a socket opener sends `fast@1`: in Node that is every client that did not say `fast: false`; in a browser, WebTransport unless the game said `fast: false`. `session.fast` says `live`, `snapshots` and `fallback`, why the seat is on the WebSocket: `no-webtransport` (the page has none: it never asked), `no-relay` (a binding with no usable `wt`), `not-offered` (no binding within `FAST_HANDSHAKE_MS` of its first frame: a room or server with no channel; a binding that comes later still opens), `unreachable` (a malformed binding, a socket that cannot open, or a session that failed or cannot carry the seat), `handshake` (no snapshot in time: a blocked network), `stall` (snapshots stopped) or `server` (the server's `__fast:off`); null on the channel, while connecting, or when the game turned it off. It takes `__fast` once the socket's state is decoded (its `seqBase` is the player's), and an unusable one (not a uint32 sid, a 16-hex-digit key and a url, or a url it cannot open: in Node anything but `udp://host:port` with a port in 1..65535, an IPv6 host in brackets, and no credentials, path, query or fragment) is a fallback at once. Its wire seq is `seqBase` plus the input's count on the socket. The inputs it sent by WebSocket before the binding arrived were dropped by the server unstepped: its first datagrams carry them again, and whenever more new inputs are due than one window holds it sends one datagram per window's worth, oldest first, so none is stepped as a fill. While the channel is live the server drops its WebSocket inputs unstepped; its ack is its own seat record's `inAck`; and it writes each applied snapshot into its state as a patch would (each record's fields through the schema, a field the record leaves at its default unwritten where the state never wrote one, with the state's `tick` and, in a predicting room, which patches only on keyframes, `keyframe` set to the snapshot's `tick`), then runs the state's change listeners, so prediction, reconcile and interpolation never see which channel delivered a state. A WebSocket patch that would write one of those fields for an id the channel holds is put back before any listener runs: a patch held behind a lost TCP segment never moves an entity or the tick back. The client keeps the WebSocket's latest value of each field it holds, and decodes each patch against those values (Colyseus sends a field only when it changes and reports a decoded field only when it differs from the one held). Motion comes by snapshot and the entity list by WebSocket, so an entity can be listed while the newest snapshot does not carry its record: it left your view and the WebSocket's removal is still on its way, or it came back into view by WebSocket first. Its fields then hold another keyframe's motion, so a predicting client keeps its body out of the keyframe it adopts, as one out of view (§17.11 *The client world*), until a snapshot carries it again. Every fast client with body prediction does (TypeScript, Unreal, Rust, Unity), held to the `motionKnown` vectors. Adopted as part of the keyframe, a body a keyframe behind failed the canary's exact comparison: on Mechanism Hall at `near-wifi`, where every radio episode releases snapshots and patches in separate bursts, prediction turned `diverged` for 7 of 28 fast seats a batch and for none on WebSocket. At a fallback, every held field takes the WebSocket's latest value in one patch, so no field keeps a snapshot's value the server has since moved on from (a seat that stopped while the snapshots were cut is drawn where it stopped); in a physics room an entity's motion instead keeps the channel's values until the server's full resend lands (*Downlink*: its WebSocket values date from when the channel went live), so nothing is drawn back where it was then. Each snapshot is a clock sample at its `sent`, with the round trip of the input its `inAck` newly acknowledges (timed from that input's send, which the client keeps for its newest `FAST_SEQ_AHEAD_MS` of inputs: the server consumes an input well after it received it), so a fast seat's clock reads what a WebSocket seat's does; the tick's nominal instant would read up to a step early, by however late the server ran that step. After a fallback the WebSocket ack counts that socket's WebSocket inputs (the dropped ones too), so the client's ack is its count at the fallback plus the WebSocket ack past the inputs it sent by WebSocket before it. A client may keep sending its input frames while live (Unreal and Rust, whose core's input handle exposes neither baseline below) or keep them off the socket (TypeScript and Unity, so a TCP stall holds no inputs); either way an input frame is a delta against the last frame the client *encoded* (the fields that changed since) and its lag-compensation stamp a delta against the last stamp it wrote, so a frame kept off the socket moves both baselines past what the server decoded. A client that keeps frames off must therefore, at the fallback, send its next frame whole (every field) and its next stamp as a delta against the last stamp the server got (the one before the binding); otherwise each input it sends after the fallback is stepped with the fields the server last decoded (a held axis read as 0) and judged seconds in the past. The server may end the channel with `__fast:off` `{}`; the client answers with its own `__fast:off { last }` and falls back as above (no server sends it yet). A client without `fast-return@1` that falls back before its first datagram loses the inputs it sent by WebSocket before the binding; one with it never does (*Return to the channel*).
+**Client** (`src/authority/fast-client.ts`, `fast-session.ts`; `fast-udp.ts` the Node socket, `fast-default.ts` finding it at run time so no browser bundle links it, `fast-webtransport.ts` the browser's). A client with a socket opener sends `fast@1`: in Node that is every client that did not say `fast: false`; in a browser, WebTransport unless the game said `fast: false`. `session.fast` says `live`, `snapshots` and `fallback`, why the seat is on the WebSocket: `no-webtransport` (the page has none: it never asked), `no-relay` (a binding with no usable `wt`), `not-offered` (no binding within `FAST_HANDSHAKE_MS` of its first frame: a room or server with no channel; a binding that comes later still opens), `unreachable` (a malformed binding, a socket that cannot open, or a session that failed or cannot carry the seat), `handshake` (no snapshot in time: a blocked network), `stall` (snapshots stopped) or `server` (the server's `__fast:off`); null on the channel, while connecting, or when the game turned it off. It takes `__fast` once the socket's state is decoded (its `seqBase` is the player's), and an unusable one (not a uint32 sid, a 16-hex-digit key and a url, or a url it cannot open: in Node anything but `udp://host:port` with a port in 1..65535, an IPv6 host in brackets, and no credentials, path, query or fragment) is a fallback at once. Its wire seq is `seqBase` plus the input's count on the socket. The inputs it sent by WebSocket before the binding arrived were dropped by the server unstepped: its first datagrams carry them again, and whenever more new inputs are due than one window holds it sends one datagram per window's worth, oldest first, so none is stepped as a fill. While the channel is live the server drops its WebSocket inputs unstepped; its ack is its own seat record's `inAck`, except where a projectile prediction is settled (§17.9: its input acknowledged and its id not in the state), which reads the ack of the newest applied snapshot at or before the WebSocket's latest `tick` (the launch comes by WebSocket and can land after the snapshot of its tick; settled against the newest snapshot, a shot was dropped as refused before its launch arrived; held to the `settleAck` vectors); and it writes each applied snapshot into its state as a patch would (each record's fields through the schema, a field the record leaves at its default unwritten where the state never wrote one, with the state's `tick` and, in a predicting room, which patches only on keyframes, `keyframe` set to the snapshot's `tick`), then runs the state's change listeners, so prediction, reconcile and interpolation never see which channel delivered a state. A WebSocket patch that would write one of those fields for an id the channel holds is put back before any listener runs: a patch held behind a lost TCP segment never moves an entity or the tick back. The client keeps the WebSocket's latest value of each field it holds, and decodes each patch against those values (Colyseus sends a field only when it changes and reports a decoded field only when it differs from the one held). Motion comes by snapshot and the entity list by WebSocket, so an entity can be listed while the newest snapshot does not carry its record: it left your view and the WebSocket's removal is still on its way, or it came back into view by WebSocket first. Its fields then hold another keyframe's motion, so a predicting client keeps its body out of the keyframe it adopts, as one out of view (§17.11 *The client world*), until a snapshot carries it again. Every fast client with body prediction does (TypeScript, Unreal, Rust, Unity), held to the `motionKnown` vectors. Adopted as part of the keyframe, a body a keyframe behind failed the canary's exact comparison: on Mechanism Hall at `near-wifi`, where every radio episode releases snapshots and patches in separate bursts, prediction turned `diverged` for 7 of 28 fast seats a batch and for none on WebSocket. At a fallback, every held field takes the WebSocket's latest value in one patch, so no field keeps a snapshot's value the server has since moved on from (a seat that stopped while the snapshots were cut is drawn where it stopped); in a physics room an entity's motion instead keeps the channel's values until the server's full resend lands (*Downlink*: its WebSocket values date from when the channel went live), so nothing is drawn back where it was then. Each snapshot is a clock sample at its `sent`, with the round trip of the input its `inAck` newly acknowledges (timed from that input's send, which the client keeps for its newest `FAST_SEQ_AHEAD_MS` of inputs: the server consumes an input well after it received it), so a fast seat's clock reads what a WebSocket seat's does; the tick's nominal instant would read up to a step early, by however late the server ran that step. After a fallback the WebSocket ack counts that socket's WebSocket inputs (the dropped ones too), so the client's ack is its count at the fallback plus the WebSocket ack past the inputs it sent by WebSocket before it. A client may keep sending its input frames while live (Unreal and Rust, whose core's input handle exposes neither baseline below) or keep them off the socket (TypeScript and Unity, so a TCP stall holds no inputs); either way an input frame is a delta against the last frame the client *encoded* (the fields that changed since) and its lag-compensation stamp a delta against the last stamp it wrote, so a frame kept off the socket moves both baselines past what the server decoded. A client that keeps frames off must therefore, at the fallback, send its next frame whole (every field) and its next stamp as a delta against the last stamp the server got (the one before the binding); otherwise each input it sends after the fallback is stepped with the fields the server last decoded (a held axis read as 0) and judged seconds in the past. The server may end the channel with `__fast:off` `{}`; the client answers with its own `__fast:off { last }` and falls back as above (no server sends it yet). A client without `fast-return@1` that falls back before its first datagram loses the inputs it sent by WebSocket before the binding; one with it never does (*Return to the channel*).
 
 **Pacing** (§17.11 *Input pacing*, unchanged in P1). A recovered input usually arrives one datagram late, so recovery after a short loss is no burst; what stays bursty is a radio queue's delay (70–170 ms episodes on `real-mac-wifi`), which is the same on either transport. Fills and recovered inputs enter the seat's buffer like any other and the pacer is the same: `MAX_INPUTS_PER_TICK_PER_PLAYER` (4, `limits.ts`) and `PACE_MAX_DEPTH_S` (50 ms, `input-pacing.ts`) apply. Proposal, to be measured in P4 before it is adopted: a starve that ends with recovered inputs was loss, not jitter, so it should not hold the cushion for `PACE_KEEP_S` (the excess drains at the next `PACE_WINDOW_S`), and with `repeat@1` recovered inputs and fills pay owed repeats back first (absorbed, `feedWithPayback`), so a recovered burst is not stepped twice. P4 measures starved ticks, own popP99 and remote lurches on fast seats with the cap at 4 and at 2 and `PACE_MAX_DEPTH_S` at 0.05 and 0.1, against the WebSocket base.
 

package/dist/authority/fast-webtransport.js

@@ -6,10 +6,10 @@ import {
   openWebTransportFastSocket,
   webTransportFastOpener,
   webTransportOptions
-} from "../chunk-NFMGIKFZ.js";
+} from "../chunk-ZDGSUR6E.js";
 import "../chunk-OD6NRSX2.js";
 import "../chunk-2NGXXQDS.js";
-import "../chunk-CSQEEANB.js";
+import "../chunk-WEMRRIHH.js";
 export {
   FAST_WT_HASHES_MAX,
   FAST_WT_HASH_HEX_DIGITS,

package/dist/authority/index.js

@@ -217,8 +217,8 @@ import {
   wireRowOfState,
   writeWireRow,
   yieldShares
-} from "../chunk-QZOCUQJT.js";
-import "../chunk-FPWP22Y7.js";
+} from "../chunk-MQYARUGU.js";
+import "../chunk-TEHGMFAG.js";
 import "../chunk-YWQ3ALYY.js";
 import {
   AcceptKind,
@@ -400,7 +400,7 @@ import {
   validRoomCode,
   validateInitOut,
   validateTickOut
-} from "../chunk-NFMGIKFZ.js";
+} from "../chunk-ZDGSUR6E.js";
 import {
   LeaveReason,
   MODULE_CONTRACT,
@@ -446,7 +446,7 @@ import {
   AUTHORITY_ROOM_ENDED_TEXT,
   AuthorityCloseCode,
   authorityCloseCodeOf
-} from "../chunk-CSQEEANB.js";
+} from "../chunk-WEMRRIHH.js";
 
 // src/authority/world-cost.ts
 var WorldCost = {