lokiplay 0.4.2 → 0.4.4

package/dist/AGENTS.template.md

@@ -92,7 +92,10 @@
   what the update path does, then ask them to confirm server. Write
   `"authority": "server"` and `step`. Do not elect a player host. Server
   rooms are browser-only, run in Singapore, and end if the step fails; they
-  do not fall back to a player. That is fairness, not lower latency.
+  do not fall back to a player. That is fairness, not lower latency. The
+  viewer clock follows `tickRate`. Leave `simulationHz` as the local
+  prediction step. Do not set `simulationHz` equal to `tickRate` to unstick
+  presentation.
 - Before compiling `step`, change the state update so the next state depends
   only on the previous state and this tick's inputs. Drawing, sound, and
   asset loads stay in the browser. If the update reads the DOM, the clock,
@@ -108,10 +111,6 @@
   the worker never mounts anything else.
 - A later switch is another deploy after the creator confirms again. Rooms
   already open keep the authority they started with.
-- Do not ask the creator to choose server, and do not write
-  `"authority": "server"`, until Loki has enabled server authority in
-  production. Until then, continuous games use host realtime. The server
-  question above applies once that switch is on.
 - After inspecting and confirming each game mode's profile, choose
   `createSynchronizedRoom()` for turn-based or event-driven state, or
   `createRealtimeRoom()` for continuous realtime. Do not choose by genre or

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "lokiplay",
-  "version": "0.4.2",
+  "version": "0.4.4",
   "description": "Command-line tools for Loki game projects and deployments.",
   "license": "MIT",
   "repository": {
@@ -39,7 +39,7 @@
     "access": "public"
   },
   "dependencies": {
-    "@lokiplay/protocol": "0.4.2",
+    "@lokiplay/protocol": "0.4.4",
     "fflate": "^0.8.3"
   }
 }