GLM

test/client-send-cadence.test.ts

@@ -1,8 +1,4 @@
-// The client's outbound cadence, which is what the server's inbound allowance
-// has to be sized against. Sending once per rendered frame put every display
-// above the allowance permanently over it; once the burst was spent the server
-// silently discarded whole batches, and movement commands are edge-triggered
-// and never re-sent, so a lost batch meant the direction change never happened.
+// Client outbound send cadence vs. server inbound allowance.
 import { describe, it, expect } from 'vitest';
 import { createRequire } from 'node:module';
 
@@ -16,7 +12,6 @@ const { applyArrayPlugins, settings, MoveActionCommand, ClientHeartbeatCommand }
 
 applyArrayPlugins();
 
-// Collects what would go on the wire.
 const drive = (frameRate: number, seconds: number, onFrame?: (socket: any) => void) => {
   const batches: Array<string> = [];
   const socket = { emit: (_event: string, payload: string) => batches.push(payload) };
@@ -38,9 +33,6 @@ describe('client send cadence', () => {
 
     for (const frameRate of [60, 144, 240]) {
       const batches = drive(frameRate, seconds);
-      // One heartbeat per interval, give or take where the frames fall. The
-      // point is that the count barely moves across a 4x range of frame rates —
-      // sending once per frame gave 180, 432 and 720 here.
       expect(batches.length).toBeLessThanOrEqual(expected * 1.1);
       expect(batches.length).toBeGreaterThanOrEqual(expected * 0.85);
     }
@@ -54,8 +46,6 @@ describe('client send cadence', () => {
   });
 
   it('still flushes real input on the frame it happens', () => {
-    // Input on frame 1 of a 144 Hz client: far inside the heartbeat interval, so
-    // pacing must not hold it back. Latency the player feels is one frame.
     let sentOn = -1;
     const batches = drive(144, 0.1, (commandSocket) => {
       if (sentOn === -1) {