You Cannot Hide a Player and Show Them at the Same Time

This post is my attempt to understand, and then explain, my current conceptual model of how Medal of Honor: Allied Assault (MOHAA) netcode behaves when a server tries to hide players from clients that should not see them yet. I chose MOHAA because it is the first-person shooter and the codebase I know best, not because it is special: the open-source reimplementation OpenMoHAA inherits the Quake III / ioquake3 networking skeleton, and almost everything below applies, with different names and constants, to any authoritative client/server shooter. It is not official OpenMoHAA documentation, it does not speak for the project's developers, and it should never be read as such. Where I quote source code I quote a pinned revision and link to it, so that anyone can check whether I read it correctly.

I also want to be honest about the epistemic status of what follows. I have read the code, traced the paths by hand, and written down the math myself, but I have not yet instrumented a live server to measure the quantities this post is ultimately about. I am fully aware that my interpretation may be incomplete or mistaken in places, and some observations I flag are exactly the kind of thing that looks like a bug on paper and turns out to be intentional once you know the history. So, keep that in mind. In any case, corrections and suggestions are all welcome. Just reach out to me on Discord.

The question is old and most of the ingredients are all public. Cheating in online games has been described as a problem of misplaced trust since at least Yan and Randell's taxonomy [1] (but of course it is as old as games exist): a wallhack works because the client is handed state it is not entitled to use, and the client is not trustworthy. Studies of state exposure ask how far ahead of legitimate need that state is preloaded [2, 3]. Server-side visibility filtering, the family this post is about, answers by not sending the state at all until it is needed, in forms ranging from MOHAA's own 2.30 patch and OpenMoHAA's reimplementation [4] to community occlusion culling for Source [5] and Riot's Fog of War for VALORANT [6]. Snapshot interpolation and client prediction, the machinery that decides how early "needed" is, were laid out by Bernier [7], the Valve wiki [8], Gambetta [9], and van Waveren [10]. Probabilistic checking of clients [11], cryptographic hidden-state protocols [12, 13], and trusted client execution [3] attack the same trust problem from other sides. And Bayesian modelling under uncertain, imperfect measurements is a mature field with good textbooks [14, 15].

Existing work studies information exposure, state dissemination, interpolation delay, visibility filtering, probabilistic verification, and secure hidden-state handling. A unified probabilistic treatment of server disclosure, cheat accessibility, true visibility, and first legitimate rendering appears less developed in the public FPS literature. I do not claim novelty for any single ingredient. What I try to contribute is to the scientific knowledge of netcode itself through a (optional to this post) mathematical lens.

A server-side anti-wallhack system works by withholding an enemy's state while that enemy is safely hidden. The server must nevertheless release the state early enough for the real client to receive and render it before geometric visibility. Those two sentences are the whole post; everything else is about how large "early enough" is, why it is not a constant, and what a codebase that actually implements this does about it.

Withhold for longer and the cheat learns less. Withhold for longer and the legitimate client has less time to prepare.

Here is the example I will keep coming back to. Two players, a defender holding an angle and an attacker running towards the corner that separates them. While the attacker is behind the wall, the defender's game does not need to know where the attacker is. If the server sends the attacker's position anyway, a wallhack on the defender's machine can draw it through the wall. If the server refuses to send it, the wallhack has nothing to draw. But the moment the attacker steps around the corner, the defender's game must draw them at once, and it cannot draw what it has not received. Packets take time to travel, and the game does not draw a packet the instant it arrives; it waits until it can place the packet in time between its neighbours. So the server has to release the attacker's position a little before the attacker is actually visible. During that "little before", a cheat can see through the wall. After it, if the release was too late, the legitimate defender sees the attacker appear out of thin air, already aiming.

There is no setting that makes both problems vanish. Every state-withholding implementation has the same kind of timing tradeoff, whether it is a 2003 patch for a World War II shooter or a 2020 fog-of-war system in a competitive title. The tradeoff can be moved, measured, and optimized, but it cannot be switched off, and I think treating it as a switch ("just enable anti-wallhack") is why discussions about it tend to go badly. The rest of the post tries to replace the switch with a number, then to replace the number with a distribution, and finally to say how the distribution could be measured on a real server (that would be very cool).

Two things this post is not about. It is not about aimbots, triggerbots, or any cheat that acts on state the client legitimately has; withholding cannot help there. And it is not about the general anti-cheat question of detecting modified clients [16]. It is about one narrow, well-posed thing: the timing of disclosure. Finally, if you are reading this in the hope of learning how bypass an anti-cheat, I have bad news: anti-cheats do not share the same limitations as client-based cheats since they can rely on server-side information. Good luck with that.

3.1 What a snapshot is, and why everyone else lives in the past Level 1

In the Quake III family of engines, and therefore in MOHAA and OpenMoHAA, the server is the only authority on where anyone is. It advances the world in fixed steps: at the default sv_fps 20 that is one step every 50 ms. After each step it builds, for each connected player, a snapshot: a compact description of that player's own state plus the entities the server has decided that player should know about, and it sends the snapshot as a UDP packet [17, 18, 19]. Snapshots are delta-compressed against the last one the client acknowledged, so a lost packet costs a little bandwidth rather than a resend [20].

Your machine, meanwhile, draws far more than twenty frames per second, and it has to draw other players at moments for which no snapshot exists. The standard answer, which Bernier wrote up for Half-Life [7] and Valve later documented in detail [8], is interpolation: the client deliberately holds its notion of "now" a little behind the newest snapshot, so that for any rendered frame it has one snapshot just before and one just after, and it blends the two. Other players are therefore always drawn slightly in the past. Your own player is the exception: to keep controls responsive, the client runs your inputs through the same movement code the server uses and shows you the predicted result immediately, correcting itself if the server later disagrees [9, 21]. Gambetta's articles come with a small live demo of both mechanisms, and if you want the MOHAA-shaped version of the same picture, I built one here.

Now the wallhack. Which entities go into your snapshot is decided by the server, and the traditional criterion is coarse: the map is pre-divided into regions, and the compiler records which regions could possibly see which others, the potentially visible set [22]. An enemy in a region that could in principle be seen from yours is sent, even if right now a crate, a doorway, or a thin interior wall is between you. The enemy's position is then sitting in your machine's memory. A wallhack is nothing more than a program that reads that memory and draws what it finds. The server cannot stop your machine from reading its own memory; the only lever it has is to not send the data. That lever is what MOHAA 2.30 pulled, and what OpenMoHAA reimplements under the name sv_netoptimize [4, 23]. The trouble is that "not sending" collides with "interpolating", because interpolation needs the data before it is needed on screen. If you would like to see a modern production version of the idea before diving into MOHAA's, Riot's Fog of War write-up [6] demonstrates it with short animated clips of an enemy being withheld and then revealed.

3.2 The corner, step by step Level 1

Take the defender and the attacker from section 2, and watch one crossing from the defender's point of view. Four moments matter, and I will give each a letter.

1. S, the server releases. On some server step the server decides the attacker now belongs in the defender's snapshot. In OpenMoHAA that decision is a geometric test that runs a short distance into the future (section 5); in other systems it may be a fixed lead. Either way, S is the first snapshot that carries the attacker.
2. A, the packet arrives. Some tens of milliseconds later, the snapshot reaches the defender's machine and is parsed. From this instant the attacker's position is in memory. A cheat can use it now.
3. R, the game first draws the attacker. The legitimate client does not draw a snapshot the moment it arrives. It waits until its own clock reaches the snapshot's time, so that it can blend towards the next one; then it needs a frame to render and the display needs a moment to show it. R is the first frame in which a human could see the attacker.
4. V, the corner opens. The attacker's body actually crosses the line of sight. This moment is decided by the two players' movement, not by any software.

Everything interesting is in the order of these four moments. If V comes after R, the defender saw the attacker in time, and the cheat had from A to V to look through the wall. If V comes before R, the attacker popped into existence late by R minus V, and the cheat had less, possibly nothing. Figure 1 lets you move the three quantities that decide the order.

3.3 Four clocks, three delays, one margin Level 1 Level 3

I will use these symbols for the rest of the post. All times are on the server's clock; the client's clock enters only through the delays, which is the point of choosing this frame.

Three remarks. First, the bracket \([x]_+\) is shorthand for \(\max(x, 0)\), the positive part of \(x\): a window cannot be negative, and neither can a lateness, so both are clipped at zero. Second, \(H\) is the only quantity the server controls, and even that only indirectly: it chooses a rule, and the rule plus the geometry produces \(H\). Third, the two outcomes are driven by the same \(H\) in opposite directions, through delays the server does not choose and cannot observe exactly. That is the entire tension, and section 4 makes it precise.

4.1 Two margins that cannot both be large Level 1

Put the two outcomes side by side. The cheat's window is \(W = \max(H - D_A, 0)\): every millisecond of lead beyond the delivery delay is a millisecond of wall-vision. The legitimate lateness is \(L = \max(D_A + B - H, 0)\): every millisecond of lead short of the full delay to first render is a millisecond during which a visible enemy is not on screen. Making \(W\) zero requires \(H \le D_A\). Making \(L\) zero requires \(H \ge D_A + B\). Both at once require \(B \le 0\), and \(B\) is a waiting time, so it is never negative and in practice never zero. The title of the post is a theorem with a one-line proof: for any client whose render delay is positive, no disclosure lead makes both the cheat's window and the legitimate lateness vanish.

The corner in Figure 1 shows what the trade looks like at the level of a single crossing. In the interval \(D_A < H < D_A + B\), the cheat sees the attacker \(H - D_A\) early and the defender still sees them \(D_A + B - H\) late; both are true at once, and the sum \(W + L = B\) does not depend on \(H\) at all. All the server can do in that band is decide who pays for \(B\). Outside the band, one of the two costs is zero and the other grows linearly.

4.2 Why it is a trade, not a switch Level 1 Level 3

If every client had the same delays, the trade would still exist but it would be boring: pick \(H\) somewhere in the band and argue about it once. What makes it interesting is that \(D_A\) and \(B\) differ across clients, across time for one client, and across corners on the same map. A player on fibre in the same city as the server has \(D_A\) near 15 ms; a player on mobile data two countries away has 90 ms with spikes. The server sets one rule. For the near player the rule leaks; for the far player the same rule pops. Once the delays are random variables, the sensible question is not "which \(H\) is right" but "which \(H\) minimises the expected cost, given what I believe about the delays and how much I dislike each kind of failure". That is a decision problem, and it has a clean answer when the costs are linear.

Everything in this section is read from one revision of the OpenMoHAA repository, commit 667c50f9 of 2026-04-13, and every listing links to that commit rather than to a moving branch. I quote the smallest range that supports a claim, I never edit the quoted text, and under each listing I say what I think it shows and what it does not. If the project changes any of this, the listings will still be true of that commit and possibly false of the game you are running; check the date.

The feature has no "wallhack" in its name anywhere in the code or commit history. The project documentation calls it network optimization, files it under a heading that also says "Antichams", and traces it to the 2.30 patch of Allied Assault Breakthrough [4, 23]:

### Optimization / AntichamsA new variable, `sv_netoptimize`, enables a feature that optimizes network bandwidth by not sending players information about others they can't see. For each client, the server optimizes by only transmitting data about players within their view. Clients will not receive information about players they can't see. This feature also helps protect against cheaters:- `set sv_netoptimize 0`: Disable optimization - the default- `set sv_netoptimize 1`: Enable optimization for entities that are moving- `set sv_netoptimize 2`: Enable optimization, alwaysThis option exists since **Medal of Honor: Allied Assault Breakthrough** 2.30, however it was improved in OpenMoHAA: sounds like footsteps will be sent so players don't get confused.

From docs/markdown/03-configuration/01-configuration.md:59–67 at the pinned commit. The differences page says the same in fewer words: 04-differences.md:334–338.

I read that description as a bandwidth feature that happens to hide information, and the code below is consistent with that reading: the filter is careful about not making the game feel wrong (a grace timer, a look-ahead, sounds for the hidden) and only incidentally careful about what a cheat can learn. That is not a criticism. It is the reason the timing question of section 4 is the right question to ask of it.

5.1 The server tick and the two frame times

The server advances in whole frames of frameMsec milliseconds and stamps every snapshot with the integer time of the last completed frame. There is a second frame-time variable, sv.frameTime, which is the same quantity in seconds as a float; the visibility code multiplies it by three, so it pays to be clear about its units.

	if ( sv_fps->integer < 1 ) {		Cvar_Set( "sv_fps", "20" );	}    	frameMsec = 1000 / sv_fps->integer;	// don't let it scale below 1ms	if(frameMsec < 1)	{		Cvar_Set("timescale", va("%f", sv_fps->integer / 1000.0f));		frameMsec = 1;	}	sv.timeResidual += msec;

	while ( sv.timeResidual >= frameMsec ) {		sv.timeResidual -= frameMsec;		svs.time += frameMsec;		if( sv.state == SS_GAME )		{			const char *err;			// let everything in the world think and move			ge->RunFrame( svs.time, frameMsec );

	// send messages back to the clients	SV_SendClientMessages();

	// Added in OPM	//  Handle non-pvs sounds	SV_HandleNonPVSSound();	svs.lastTime = svs.time;

	Com_Memset (&sv, 0, sizeof(sv));	sv.frameTime = 1.0 / sv_fps->value;

For the timing model this fixes the resolution of \(S\): a player can only become disclosed on a frame boundary, so \(S\) is a multiple of 50 ms at the default rate. It also fixes the resolution of what the server can know about \(V\): the trace runs on positions the game logic produced for this frame, never in between.

5.2 Building one client's snapshot: the viewpoint

SV_BuildClientSnapshot is called once per client per send. It copies the client's own player state, picks a viewpoint, and calls the entity walk of section 5.3 from that viewpoint. Two details matter for us: which point is used, and the fact that the client's own entity is in the set.

	ps = SV_GameClientNum( client - svs.clients );	frame->ps = *ps;    frame->ps.net_pm_flags = CPT_DenormalizePlayerStateFlags(ps->pm_flags);    frame->ps.iNetViewModelAnim = CPT_DenormalizeViewModelAnim(ps->iViewModelAnim);	//SV_SvEntityForGentity	// never send client's own entity, because it can	// be regenerated from the playerstate	clientNum = frame->ps.clientNum;	if ( clientNum < 0 || clientNum >= MAX_GENTITIES ) {		Com_Error( ERR_DROP, "SV_SvEntityForGentity: bad gEnt" );	}	svEnt = &sv.svEntities[ clientNum ];		// su44: that's not done in MoHAA	//svEnt->snapshotCounter = sv.snapshotCounter;	// find the client's viewpoint	if (ps->pm_flags & PMF_CAMERA_VIEW)	{		VectorCopy(ps->camera_origin, org);		VectorCopy(ps->camera_angles, ang);	}	else	{		VectorCopy(ps->vEyePos, org);		VectorCopy(ps->viewangles, ang);	}	SV_AddEntToSnapshot(svEnt, SV_GentityNum(client - svs.clients), &entityNumbers, NULL, qfalse);

5.3 The gates, in order

SV_AddEntitiesVisibleFromPoint walks every entity and applies a sequence of cheap-to-expensive tests. The head of the loop is inherited almost verbatim from Quake III: skip entities not in use or already sent, honour SVF_NOCLIENT, SVF_SINGLECLIENT and SVF_NOTSINGLECLIENT (sv_snapshot.c:643–669), with the ioquake3 SVF_CLIENTMASK block commented out and marked "Removed in OPM" (sv_snapshot.c:670–680). Then come MOHAA additions: an entity attached to a parent is judged by its parent's visibility (sv_snapshot.c:682–689, sv_snapshot.c:716–729), sky-origin and always-draw entities are broadcast (sv_snapshot.c:698–714). The tail is where players are treated differently from everything else.

		// ignore if not touching a PV leaf		// check area		if ( !CM_AreasConnected( clientarea, svCheckEnt->areanum ) ) {			// doors can legally straddle two areas, so			// we may need to check another one			if ( !CM_AreasConnected( clientarea, svCheckEnt->areanum2 ) ) {				continue;		// blocked by a door			}		}		if (g_gametype->integer != GT_SINGLE_PLAYER && !(ent->r.svFlags & SVF_NOFARPLANE)) {			float farplane = sv.farplane;			if (farplane < 1) farplane = 12000;			if (farplane > 12000) farplane = 12000;			check = EntityDistCheck(origin, forward, parentEnt ? parentEnt : ent, farplane, ps->fov);			if (check == CULL_OUT) {				continue;			}		}		// check individual leafs		if( !svEnt->numClusters ) {			continue;		}/* … L769–L794 omitted: per-cluster PVS bit test, including the lastCluster overflow case … */		if (svEnt->snapshotCounter == sv.snapshotCounter) {			ent->s.renderfx &= ~(RF_WRAP_FRAMES | RF_SHADOW_PLANE);			ent->s.renderfx |= RF_WRAP_FRAMES;			continue;		}		if (g_gametype->integer != GT_SINGLE_PLAYER && ent->s.number < svs.iNumClients) {			if (!SV_ClientIsVisible(ent->s.number, client - svs.clients, check, forward, right)) {				SV_AddNonPVSSound(client, ent);				continue;			}		}		// add it		SV_AddEntToSnapshot( svEnt, ent, eNums, portalEnt, portalsky);		// if its a portal entity, add everything visible from its camera position		if ( ent->r.svFlags & SVF_PORTAL && svEnt != portalEnt ) {			SV_AddEntitiesVisibleFromPoint( ent->s.origin2, frame, eNums, svEnt, qfalse, client, angles  );		}	}	if (!portalsky && skyorigin && !portalEnt) {		SV_AddEntitiesVisibleFromPoint(skyorigin->s.origin, frame, eNums, NULL, qtrue, client, angles);	}}

5.4 Near, far, and in between: EntityDistCheck and the two modes

Before the potentially visible set is consulted, every entity is classified by distance from the viewpoint, scaled by the viewer's field of view and by whether a player is moving. The classification is not just a far-plane cut: its CULL_IN result is what mode 1 of the filter uses to skip the trace entirely.

int EntityDistCheck(const vec3_t origin, const vec3_t forward, const gentity_t* ent, float farplane, float fov) {	vec3_t dir;	float farplaneMax;	float length;	float fovCheck;	float dot;	VectorSubtract(origin, ent->r.centroid, dir);	length = VectorNormalize(dir) - ent->r.radius;	farplaneMax = farplane + 128;	if (length >= farplaneMax) {		return CULL_OUT;	}	fovCheck = fov / 80 * length;	if (ent->s.number < svs.iNumClients && VectorLength(ent->s.pos.trDelta) < 5) {		fovCheck *= 0.25f;	}	if (fovCheck <= 640) {		return CULL_IN;	}	dot = DotProduct(forward, dir) + 0.5f;	if (dot < 0) {		dot = 0;	}	if (fovCheck * (dot * 2.f + 1.f) >= farplaneMax) {		// outside the farplane		return CULL_OUT;	}	return CULL_CLIP;}

On the far plane itself: the clamp accepts anything in \([1, 12000]\) and maps zero to 12000, so a map that never sets a far plane is culled at 12128 units, which on most MOHAA maps is "never". The value it clamps is written by SV_SetFarPlane, and that function stores a square:

void SV_SetFarPlane( int farplane ){	if( farplane )	{		sv.farplane = ( farplane + 32 ) * ( farplane + 32 );	}	else	{		sv.farplane = 0;	}

sv_game.c:1469–1478. A far plane of 4000 is stored as \(4032^2 \approx 1.6 \times 10^7\), which the clamp reduces to 12000, and EntityDistCheck then compares against a linear length. Either the game module always passes a value the clamp is meant to swallow, or the two sides disagree about units. This is fixture F7; I do not know which it is, and a deterministic test would settle it in an afternoon.

5.5 SV_ClientIsVisible, line by line

This is the function the whole post is about. It is called with the target's slot first and the viewer's slot second, and with the viewer's forward vector as computed from the snapshot viewpoint of section 5.2. I quote it whole, because its control flow is the argument.

qboolean SV_ClientIsVisible(int toNum, int fromNum, int distCheck, const vec3_t forward, const vec3_t right) {	client_t* fromClient;	playerState_t *fromPs, *toPs;	vec3_t dir;	vec3_t fromOrigin, toOrigin;	vec3_t toRight;	float dot;	float speed;		if (!g_netoptimize->integer || !sv_netoptimize->integer) {		return qtrue;	}	if (toNum >= svs.iNumClients) {		return qtrue;	}	fromClient = &svs.clients[fromNum];	if (sv_netoptimize->integer == NETO_CULLED && distCheck == CULL_IN) {		fromClient->lastVisCheckTime[toNum] = svs.time + sv_netoptimize_vistime->integer;		return qtrue;	}	if (fromClient->lastVisCheckTime[toNum] > svs.time) {		return qtrue;	}    fromPs = SV_GameClientNum(fromNum);    toPs = SV_GameClientNum(toNum);	if (fromPs->fLeanAngle == 0) {		VectorCopy(fromPs->vEyePos, fromOrigin);	} else if (fromPs->fLeanAngle >= 0) {		VectorMA(fromPs->vEyePos, 30, right, fromOrigin);	} else {		VectorMA(fromPs->vEyePos, -30, right, fromOrigin);    }    VectorCopy(fromPs->vEyePos, fromOrigin);	if (toPs->fLeanAngle == 0) {		VectorCopy(toPs->vEyePos, toOrigin);	} else if (toPs->fLeanAngle >= 0) {		AngleVectors(toPs->viewangles, toRight, NULL, NULL);		VectorMA(toPs->vEyePos, 30, toRight, toOrigin);	} else {		AngleVectors(toPs->viewangles, toRight, NULL, NULL);		VectorMA(toPs->vEyePos, -30, toRight, toOrigin);    }    VectorCopy(toPs->vEyePos, toOrigin);	VectorSubtract(toOrigin, fromOrigin, dir);	VectorNormalize(dir);	dot = DotProduct(forward, dir);	if (SV_ClientIsVisibleTrace(fromOrigin, toOrigin, toPs->viewheight / 2, dot)) {		fromClient->lastVisCheckTime[toNum] = svs.time + sv_netoptimize_vistime->integer;		return qtrue;	}	speed = VectorLength(toPs->velocity);	if (speed <= 0) {		return qfalse;	}	//	// check with velocity prediction	//	VectorMA(fromOrigin, sv.frameTime * 3, fromPs->velocity, fromOrigin);	VectorMA(toOrigin, sv.frameTime * 3, toPs->velocity, toOrigin);	if (SV_ClientIsVisibleTrace(fromOrigin, toOrigin, toPs->viewheight / 2, dot)) {        fromClient->lastVisCheckTime[toNum] = svs.time + sv_netoptimize_vistime->integer;        return qtrue;	}	// not visible	return qfalse;}

Read as a timing rule, the function says: a hidden player is released at the first server frame in which either (a) a straight line exists between the two eye positions now, or (b) the target is moving and a straight line exists between where both players would be 150 ms from now if each kept its current velocity. Everything else is memory of a previous success (the grace timer) or a distance shortcut (mode 1). The consequences for \(H\) are worked out in section 5.9.

5.6 What "line of sight" means to the server

Both traces call the same helper, which is worth reading because "visible" here is a very specific and very cheap thing: a ray, then possibly a second ray, against the world and against brush entities, with a content mask that excludes players.

qboolean SV_ClientIsVisibleTrace(const vec3_t fromOrigin, const vec3_t toOrigin, float height, float dot) {	vec3_t dir;	vec3_t end;	VectorSubtract(toOrigin, fromOrigin, dir);    VectorNormalize(dir);    //VectorMA(toOrigin, -height, dir, end);	VectorCopy(toOrigin, end);	if (SV_WorldTrace(fromOrigin, end, (CONTENTS_SLIME | CONTENTS_LAVA | CONTENTS_SOLID))) {		return qtrue;	}	if (dot < 0) {		return qfalse;    }	end[2] -= height;	return SV_WorldTrace(fromOrigin, end, (CONTENTS_SLIME | CONTENTS_LAVA | CONTENTS_SOLID));}

qboolean SV_WorldTrace(const vec3_t start, const vec3_t end, int mask){	trace_t trace = { 0 };    CM_BoxTrace(&trace, start, end, vec3_origin, vec3_origin, 0, mask, qfalse);	if (trace.fraction != 1) {		return qfalse;	}	// Also test against brush models	return SV_ClipMoveToBSPEntities(start, end, mask);}

Two players standing in a doorway, one behind the other, do not occlude each other for this test; a closed door does, both through the areaportal gate of section 5.3 and, if it is a brush model, through the second clip. The test has no notion of the viewer's screen: a target that is behind the viewer passes the eye-to-eye trace as long as the ray is clear, because dot only decides whether the lowered second ray is attempted. The far-plane classifier of section 5.4 is the only place where looking away costs an entity anything, and there it only makes the far cut stricter.

5.7 The grace timer

Every success writes svs.time + sv_netoptimize_vistime into a per-viewer, per-target array (server.h:227), and the next sv_netoptimize_vistime milliseconds of checks for that pair return "visible" without tracing. With the 200 ms default this means the server keeps sending a player for four frames after they were last seen, which covers a peeker stepping back behind cover and re-emerging. In timing terms the grace timer changes nothing about the first reveal, which is what \(H\) measures; it changes how often a first reveal happens, because a target that ducks in and out within 200 ms never becomes hidden again. It also has a second-order effect on the cheat: a target that was seen once is disclosed for 200 ms after cover is regained, so the cheat window at the end of an encounter is at least 200 ms plus \(D_A\). The model of section 9 treats the grace period as an outcome to measure, not as a parameter to tune, because its value is a matter of feel.

5.8 Sounds for the unseen

The documentation's remark that "sounds like footsteps will be sent" is implemented as a small queue per entity and a forwarder in the snapshot builder. The interesting property is where the sound is placed.

static void SV_AddNonPVSSound(client_t* client, gentity_t* ent) {	int i;    for (i = 0; i < ent->r.num_nonpvs_sounds; i++) {		nonpvs_sound_t *npvs = &ent->r.nonpvs_sounds[i];        SV_ClientSound(            client,            &ent->s.origin,            ENTITYNUM_NONE,            1,            npvs->index,            npvs->volume,            npvs->minDist,            npvs->pitch,            npvs->maxDist,            qfalse        );	}}

void Entity::PlayNonPvsSound(const str& soundName, float volume){    AliasListNode_t* ret;    str name;    if (g_gametype->integer == GT_SINGLE_PLAYER) {        // Ignore in single-player        return;    }    if (!sv_netoptimize->integer) {        // don't use sound indexes for nothing        return;    }    if (edict->r.svFlags & SVF_BOT) {        // bots are not real clients        return;    }    if (edict->r.num_nonpvs_sounds >= MAX_NONPVS_SOUNDS) {        return;    }    name = GetRandomAlias(soundName, &ret);    if (name.length() && ret) {        nonpvs_sound_t* npvs = &edict->r.nonpvs_sounds[edict->r.num_nonpvs_sounds];        npvs->index = gi.pvssoundindex(name.c_str(), ret->streamed);        npvs->volume = G_Random() * ret->volumeMod + ret->volume * volume;        npvs->minDist = ret->dist;        npvs->maxDist = ret->maxDist;        npvs->pitch = G_Random() * ret->pitchMod + ret->pitch;        edict->r.num_nonpvs_sounds++;

So the filter is a partial-information channel rather than a wall. A hidden player who walks sends up to four positioned sounds per server frame at their true origin, tagged to no entity. A client that listens for footsteps hears them from the right direction, which is the intended effect; a program that reads the sound stream learns a sequence of exact positions at footstep rate, which is a side effect. Box D8 in section 9 tries to put a number on it. I want to be careful here: this is not a flaw in the implementation so much as a statement of what the feature is for. It is meant to stop the client from rendering hidden players, and it does that; it is not meant to be an information boundary, and it is not one.

5.9 What three server frames are, and are not

The projected trace is often described as "the server looks 150 ms ahead so the client has the data in time". The code supports a narrower statement. The server tests whether a straight line exists between two straight-line extrapolations of the players' positions 150 ms ahead; if the test passes at frame \(t_j\), the player is included in the snapshot built at \(t_j\). Whether that is 150 ms "ahead" of the true reveal depends on the path the players actually take, on the frame quantisation, and on whether the target is moving at all. The box below does the arithmetic; the paragraph after it gives the short version.

The short version: three frames is a prediction horizon in server time. It converts into a lead of between two and three frames when the prediction is right, into a lag of up to one frame when the prediction is structurally unavailable (the stationary target), and into something else when the path curves. It is never a promise about the client, because the client's delay \(D_A + B\) is not an input to the rule. Valorant's design note on the same problem states the rule the other way round: the look-ahead is chosen to exceed the viewer's expected ping [6]. That is a per-client horizon, and the next box says what it would take here.

5.10 To the wire, and the knobs

After the entity set is decided, the snapshot is serialised. The timing-relevant fields are the timestamp and, surprisingly, a residual byte that OpenMoHAA adds and that no client reads.

	MSG_WriteSVC(msg, svc_snapshot);	// NOTE, MRE: now sent at the start of every message from server to client	// let the client know which reliable clientCommands we have received	//MSG_WriteLong( msg, client->lastClientCommand );	// send over the current server time so the client can drift	// its view of time to try to match	if( client->oldServerTime ) {		// The server has not yet got an acknowledgement of the		// new gamestate from this client, so continue to send it		// a time as if the server has not restarted. Note from		// the client's perspective this time is strictly speaking		// incorrect, but since it'll be busy loading a map at		// the time it doesn't really matter.		MSG_WriteLong (msg, svs.time + client->oldServerTime);	} else {		// WOMBAT: note that MOHAA always goes into this else.		// therefore we are deviating from the MOHAA protocol but i don't think this is a problem		MSG_WriteLong (msg, svs.time);	}	if ( sv.timeResidual > 254 )		MSG_WriteByte( msg, 255 );	else MSG_WriteByte( msg, sv.timeResidual );

	}	// delta encode the playerstate	if ( oldframe ) {		MSG_WriteDeltaPlayerstate( msg, &oldframe->ps, &frame->ps, sv.frameTime);	} else {		MSG_WriteDeltaPlayerstate( msg, NULL, &frame->ps, sv.frameTime);	}	// delta encode the entities	SV_EmitPacketEntities (oldframe, frame, msg);	MSG_WriteSounds( msg, client->server_sounds, client->number_of_server_sounds );

The client parser reads the byte right after the time and stores it in a field nothing else touches:

	newSnap.serverTime = MSG_ReadLong( msg );	newSnap.serverTimeResidual = MSG_ReadByte( msg );

cl_parse.cpp:290–291 (fixture F14). It is one byte per snapshot; it would be a cheap sub-frame timestamp if the clock code of section 6.1 used it.

When a snapshot is sent is decided by SV_SendClientMessages (sv_snapshot.c:1277–1325): a client is skipped while less than its snapshotMsec has elapsed since its last snapshot, and non-LAN clients are further rate-limited by SV_RateMsec. snapshotMsec comes from the client's snaps userinfo value, clamped to the server's frame rate:

	{		i = atoi(val);				if(i < 1)			i = 1;		else if(i > sv_fps->integer)			i = sv_fps->integer;		i = 1000 / i;	}	else		i = 50;	if(i != cl->snapshotMsec)	{		// Reset last sent snapshot so we avoid desync between server frame time and snapshot send time		cl->lastSnapshotTime = 0;		cl->snapshotMsec = i;			}

sv_client.c:1590–1608. A client asking for more than sv_fps snapshots per second gets exactly sv_fps; one asking for fewer gets fewer. The snapshot period on the client side, and therefore \(B\), is bounded below by the server frame and can be lengthened by the client.

The one place where sv.frameTime reaches the wire is the animation-time delta suppression, an OpenMoHAA fix that skips sending a value the client can predict:

void MSG_WritePackedAnimTime_ver_15(msg_t* msg, float fromValue, float toValue, float frameTime, int bits){	int packed;	// Fixed in OPM	//  See the comment above the ANIMTIME_DELTA_SUPPRESSION_EPSILON variable	if (fabs(toValue - fromValue - frameTime) < ANIMTIME_DELTA_SUPPRESSION_EPSILON) {		// Suppress the delta as the next frame is predictable		MSG_WriteBits(msg, 0, 1);		return;

msg.cpp:2615–2624. Not about visibility; included so that the two uses of sv.frameTime are both on the page.

Finally, the settings, with their defaults at this revision:

	sv_fps = Cvar_Get ("sv_fps", "20", CVAR_SAVEGAME | CVAR_SERVERINFO | CVAR_NORESTART );

    sv_netoptimize = Cvar_Get("sv_netoptimize", "0", 0);	sv_netoptimize_vistime = Cvar_Get("sv_netoptimize_vistime", "200", 0);    g_netoptimize = Cvar_Get("g_netoptimize", "1", 0);

	// Added in 2.30	Cvar_Set("g_netoptimize", "1");

typedef enum {	NETO_NONE,	NETO_CULLED,	NETO_ALWAYS} netoptimize_e;

    g_smoothClients = gi.Cvar_Get("g_smoothClients", "1", 0);

    sv_netoptimize = gi.Cvar_Get("sv_netoptimize", "0", 0);

The server decides \(S\). The network decides \(D_A\). Everything from \(A\) to \(R\) is the client's doing, and the client's code is where most of the intuition about "the client has the data early, so it can smooth the reveal" turns out to be only partly true. This section follows a disclosing snapshot from the socket to the screen.

6.1 The client's clock has no fixed delay

Source engines have an explicit interpolation delay (cl_interp, by default two snapshot periods) [8]. Quake III and its descendants do not. The client keeps an offset between its wall clock and server time, and adjusts that offset by a millisecond or two on every snapshot, pushing forward when it did not run out of data and pulling back when it did. The render delay \(B\) is whatever that feedback loop settles on.

		// cl_timeNudge is a user adjustable cvar that allows more		// or less latency to be added in the interest of better		// smoothness or better responsiveness.		int tn;		tn = cl_timeNudge->integer;		if (tn<-30) {			tn = -30;		} else if (tn>30) {			tn = 30;		}		cl.serverTime = cls.realtime + cl.serverTimeDelta - tn;		// guarantee that time will never flow backwards, even if		// serverTimeDelta made an adjustment or cl_timeNudge was changed		if ( cl.serverTime < cl.oldServerTime ) {			cl.serverTime = cl.oldServerTime;		}		// note if we are almost past the latest frame (without timeNudge),		// so we will try and adjust back a bit when the next snapshot arrives		if ( cls.realtime + cl.serverTimeDelta >= cl.snap.serverTime - 5 ) {			cl.extrapolatedSnapshot = qtrue;		}	}

#define	RESET_TIME	500void CL_AdjustTimeDelta( void ) {	int		resetTime;	int		newDelta;	int		deltaDelta;	cl.newSnapshots = qfalse;	// the delta never drifts when replaying a demo	if ( clc.demoplaying ) {		return;	}	// if the current time is WAY off, just correct to the current value	if ( com_sv_running->integer ) {		resetTime = 100;	} else {		resetTime = RESET_TIME;	}	newDelta = cl.snap.serverTime - cls.realtime;	deltaDelta = abs( newDelta - cl.serverTimeDelta );	if ( deltaDelta > RESET_TIME ) {		cl.serverTimeDelta = newDelta;		cl.oldServerTime = cl.snap.serverTime;	// FIXME: is this a problem for cgame?		cl.serverTime = cl.snap.serverTime;		if ( cl_showTimeDelta->integer ) {			Com_Printf( "<RESET> " );		}	} else if ( deltaDelta > 100 ) {		// fast adjust, cut the difference in half		if ( cl_showTimeDelta->integer ) {			Com_Printf( "<FAST> " );		}		cl.serverTimeDelta = ( cl.serverTimeDelta + newDelta ) >> 1;	} else {		// slow drift adjust, only move 1 or 2 msec		// if any of the frames between this and the previous snapshot		// had to be extrapolated, nudge our sense of time back a little		// the granularity of +1 / -2 is too high for timescale modified frametimes		if ( !cls.timeScaled ) {			if ( cl.extrapolatedSnapshot ) {				cl.extrapolatedSnapshot = qfalse;				cl.serverTimeDelta -= 2;			} else {				// otherwise, move our sense of time forward to minimize total latency				cl.serverTimeDelta++;			}		}	}	if ( cl_showTimeDelta->integer ) {		Com_Printf( "%i ", cl.serverTimeDelta );	}}

The loop has a steady state, and it is worth deriving because it is the value of \(B\) for the default configuration. Call \(P\) the snapshot period (50 ms) and \(\ell\) the amount by which the displayed time trails the newest snapshot's time at the moment that snapshot arrives. Between arrivals the displayed time advances \(P\), so just before the next snapshot it trails by \(\ell - P\); the client flags an extrapolated frame when that trail is 5 ms or less. If it was flagged, the next adjustment is −2 ms (\(\ell\) grows by 2); if not, +1 ms (\(\ell\) shrinks by 1). So \(\ell\) shrinks one millisecond per snapshot until it reaches \(P + 5\), gets pushed back to \(P + 7\), and shrinks again: a three-snapshot cycle around \(\ell \approx P + 5\), tripping the flag one snapshot in three. In server-time terms the client renders about one snapshot period behind the newest snapshot it holds, plus 5 ms, plus the time to the next rendered frame. That is the nominal \(B\): roughly 55 to 70 ms at 20 snapshots per second, larger at lower snapshot rates, and it is emergent rather than configured. cl_timeNudge shifts it by up to ±30 ms; jitter shifts it by whatever the halving rule at L1078 leaves behind; and after a reset (a 500 ms jump, for example at connect) the client starts with no buffer at all and walks back to the steady state at 2 ms per snapshot, which takes about a second and a half at 20 Hz.

6.2 Snapshot transitions and who may interpolate

The client holds at most two snapshots for rendering: cg.snap, whose time is at or before the displayed time, and cg.nextSnap, whose time is after it. CG_ProcessSnapshots (cg_snapshot.c:410–491) reads new snapshots as needed and transitions when the displayed time passes the next one's time. When a snapshot becomes nextSnap, every entity in it is examined and marked eligible or ineligible for interpolation. This is the rule that decides what a first reveal looks like.

static void CG_SetNextSnap(snapshot_t *snap){    int            num;    entityState_t *es;    centity_t     *cent;    cg.nextSnap = snap;    cg_entities[cg.snap->ps.clientNum].interpolate = qtrue;    // check for extrapolation errors    for (num = 0; num < snap->numEntities; num++) {        es   = &snap->entities[num];        cent = &cg_entities[es->number];        cent->nextState = *es;        // if this frame is a teleport, or the entity wasn't in the        // previous frame, don't interpolate        if (!cent->currentValid || ((cent->currentState.eFlags ^ es->eFlags) & EF_TELEPORT_BIT)            || (cent->currentState.parent != es->parent) || (cent->currentState.modelindex != es->modelindex)) {            cent->interpolate = qfalse;            // if this isn't the first frame and we have valid data, set the            // teleport flag            if (cent->currentValid) {                cent->teleported = qtrue;            }        } else {            cent->interpolate = qtrue;        }    }    // if the next frame is a teleport for the playerstate, we    // can't interpolate during demos    if (cg.snap && (snap->ps.pm_flags & PMF_RESPAWNED)) {        cg.nextFrameTeleport = qtrue;    } else {        cg.nextFrameTeleport = qfalse;    }    // if changing follow mode, don't interpolate    if (cg.nextSnap->ps.clientNum != cg.snap->ps.clientNum) {        cg.nextFrameTeleport = qtrue;    }    // if the camera cut bit changed, than the next frame is a camera cut    if ((cg.nextSnap->ps.camera_flags & CF_CAMERA_CUT_BIT) != (cg.snap->ps.camera_flags & CF_CAMERA_CUT_BIT)) {        cg.nextFrameCameraCut = qtrue;    } else {        cg.nextFrameCameraCut = qfalse;    }    // if changing server restarts, don't interpolate    if (snap->serverTime < cgi.GetServerStartTime()) {        // reset the camera        cg.nextFrameTeleport = qtrue;    }    // sort out solid entities    CG_BuildSolidList();}

There is one more fact needed to read the timeline correctly. Entities are drawn from cg.snap, not from cg.nextSnap: CG_AddPacketEntities iterates cg.snap->entities (cg_ents.c:641–644). An entity present only in the next snapshot has its nextState filled in, which any process reading the client's memory can see, but no model on screen, until the transition. That transition is where the eligibility flag is consumed.

static void CG_TransitionEntity(centity_t *cent){    cent->currentState = cent->nextState;    cent->currentValid = qtrue;    // reset if the entity wasn't in the last frame or was teleported    if (!cent->interpolate) {        CG_ResetEntity(cent);    }    // clear the next state.  if will be set by the next CG_SetNextSnap    cent->interpolate = qfalse;    // reset the teleported state    cent->teleported = qfalse;    if (cent->currentState.eType == ET_EVENTS) {        CG_Event(cent);    }}

static void CG_ResetEntity(centity_t *cent){    dtiki_t *tiki;    int      i;    VectorCopy(cent->currentState.origin, cent->lerpOrigin);    VectorCopy(cent->currentState.angles, cent->lerpAngles);    // if we just teleported, all we care about is the position and orientation    // information    if (cent->teleported) {        cent->teleported = qfalse;        return;    }

6.3 Four rendering branches and a 100 ms cap

MOHAA stripped Quake III's typed trajectories down to a velocity and a timestamp, and the client's evaluator became a straight line with a cap. The server writes the velocity for players only when its own g_smoothClients is on.

void BG_EvaluateTrajectory(const trajectory_t *tr, int atTime, const vec3_t base, vec3_t result){    float deltaTime;    if (atTime > cg_smoothClientsTime->integer + tr->trTime) {        atTime = cg_smoothClientsTime->integer + tr->trTime;    }    deltaTime = (float)(atTime - tr->trTime) / 1000.0;    result[0] = tr->trDelta[0] * deltaTime + base[0];    result[1] = tr->trDelta[1] * deltaTime + base[1];    result[2] = tr->trDelta[2] * deltaTime + base[2];}

typedef struct {	int trTime;	vec3_t trDelta;} trajectory_t;

    if (g_gametype->integer != GT_SINGLE_PLAYER && g_smoothClients->integer) {        VectorCopy(client->ps.velocity, edict->s.pos.trDelta);        edict->s.pos.trTime = client->ps.commandTime;    } else {        VectorClear(edict->s.pos.trDelta);        edict->s.pos.trTime = 0;    }

With those pieces, the position of every entity for the frame is chosen by one function with four branches. Which branch a newly disclosed player takes depends on the eligibility flag from section 6.2 and on the viewer's cg_smoothClients.

void CG_CalcEntityLerpPositions(centity_t *cent){    int   i;    float f;    f = cg.frameInterpolation;    if (cent->currentState.eType == ET_PLAYER) {        if (cent->currentState.number == cg.snap->ps.clientNum) {            // if the player, take position from prediction            VectorCopy(cg.predicted_player_state.origin, cent->lerpOrigin);            for (i = 0; i < 3; i++) {                cent->lerpAngles[i] = LerpAngle(cent->currentState.angles[i], cent->nextState.angles[i], f);            }            return;        }    }    if (cent->currentState.eType != ET_PLAYER || !cg_smoothClients->integer) {        float quat[4];        float mat[3][3];        if (!cent->interpolate) {            VectorCopy(cent->currentState.angles, cent->lerpAngles);            VectorCopy(cent->currentState.origin, cent->lerpOrigin);            return;        }        for (i = 0; i < 3; i++) {            cent->lerpOrigin[i] =                cent->currentState.origin[i] + f * (cent->nextState.origin[i] - cent->currentState.origin[i]);        }        if (!memcmp(cent->currentState.angles, cent->nextState.angles, sizeof(vec3_t))) {            VectorCopy(cent->currentState.angles, cent->lerpAngles);        } else {            // use spherical interpolation using quaternions so that bound objects            // rotate properly without gimble lock.            SlerpQuaternion(cent->currentState.quat, cent->nextState.quat, f, quat);            QuatToMat(quat, mat);            MatrixToEulerAngles(mat, cent->lerpAngles);        }    } else if (cent->interpolate) {        float quat[4];        float mat[3][3];        // if the entity has a valid next state, interpolate a value between the frames        // unless it is a mover with a known start and stop        vec3_t current, next;        // this will linearize a sine or parabolic curve, but it is important        // to not extrapolate player positions if more recent data is available        BG_EvaluateTrajectory(&cent->currentState.pos, cg.snap->serverTime, cent->currentState.origin, current);        BG_EvaluateTrajectory(&cent->nextState.pos, cg.nextSnap->serverTime, cent->nextState.origin, next);        cent->lerpOrigin[0] = current[0] + f * (next[0] - current[0]);        cent->lerpOrigin[1] = current[1] + f * (next[1] - current[1]);        cent->lerpOrigin[2] = current[2] + f * (next[2] - current[2]);        if (!memcmp(cent->currentState.angles, cent->nextState.angles, sizeof(vec3_t))) {            VectorCopy(cent->currentState.angles, cent->lerpAngles);        } else {            // use spherical interpolation using quaternions so that bound objects            // rotate properly without gimble lock.            SlerpQuaternion(cent->currentState.quat, cent->nextState.quat, f, quat);            QuatToMat(quat, mat);            MatrixToEulerAngles(mat, cent->lerpAngles);        }    } else {        // just use the current frame and evaluate as best we can        BG_EvaluateTrajectory(&cent->currentState.pos, cg.time, cent->currentState.origin, cent->lerpOrigin);        VectorCopy(cent->currentState.angles, cent->lerpAngles);    }}

    // set cg.frameInterpolation    if (cg.nextSnap && r_lerpmodels->integer) {        int delta;        delta = (cg.nextSnap->serverTime - cg.snap->serverTime);        if (delta == 0) {            cg.frameInterpolation = 0;        } else {            cg.frameInterpolation = (float)(cg.time - cg.snap->serverTime) / delta;        }    } else {        cg.frameInterpolation = 0; // actually, it should never be used, because        // no entities should be marked as interpolating    }

The relevant client cvars and their defaults, for reference (cg_main.c:137–159):

    cg_errorDecay                 = cgi.Cvar_Get("cg_errordecay", "100", 0);    cg_nopredict                  = cgi.Cvar_Get("cg_nopredict", "0", 0);    cg_showmiss                   = cgi.Cvar_Get("cg_showmiss", "0", 0);    cg_stats                      = cgi.Cvar_Get("cg_stats", "0", 0);    cg_hidetempmodels             = cgi.Cvar_Get("cg_hidetempmodels", "0", 0);    cg_synchronousClients         = cgi.Cvar_Get("g_synchronousClients", "0", 0);    cg_stereoSeparation           = cgi.Cvar_Get("cg_stereosep", "0.4", CVAR_ARCHIVE);    cg_lagometer                  = cgi.Cvar_Get("cg_lagometer", "0", 0);    paused                        = cgi.Cvar_Get("paused", "0", 0);    r_lerpmodels                  = cgi.Cvar_Get("r_lerpmodels", "1", 0);    cg_3rd_person                 = cgi.Cvar_Get("cg_3rd_person", "0", CVAR_CHEAT);    cg_drawviewmodel              = cgi.Cvar_Get("cg_drawviewmodel", "2", CVAR_ARCHIVE);    cg_cameraheight               = cgi.Cvar_Get("cg_cameraheight", "18", CVAR_ARCHIVE);    cg_cameradist                 = cgi.Cvar_Get("cg_cameradist", "120", CVAR_ARCHIVE);    cg_cameraverticaldisplacement = cgi.Cvar_Get("cg_cameraverticaldisplacement", "-2", CVAR_ARCHIVE);    cg_camerascale                = cgi.Cvar_Get("cg_camerascale", "0.3", CVAR_ARCHIVE);    cg_traceinfo                  = cgi.Cvar_Get("cg_traceinfo", "0", CVAR_ARCHIVE);    cg_debugFootsteps             = cgi.Cvar_Get("cg_debugfootsteps", "0", CVAR_CHEAT);    cg_smoothClients              = cgi.Cvar_Get("cg_smoothClients", "1", CVAR_ARCHIVE);    cg_smoothClientsTime          = cgi.Cvar_Get("cg_smoothClientsTime", "100", CVAR_ARCHIVE);    pmove_fixed                   = cgi.Cvar_Get("pmove_fixed", "0", 0);    pmove_msec                    = cgi.Cvar_Get("pmove_msec", "8", 0);    cg_pmove_msec                 = cgi.Cvar_Get("cg_pmove_msec", "8", 0);

cg_smoothClients and cg_smoothClientsTime are CVAR_ARCHIVE, so they are per-player choices that survive restarts; the server has no say in them. In ioquake3 the equivalent cvar defaults to 0 and is CVAR_USERINFO (cg_main.c:309), so the server at least knows what each client chose.

6.4 A first reveal, frame by frame

Put sections 6.1 to 6.3 together for a player who was withheld and is disclosed in snapshot \(m\), whose server time is \(T_m\). All numbers assume the defaults and the steady state of section 6.1.

1. \(A\): snapshot \(m\) arrives. Its entity list, including the new player, is parsed into cl.parseEntities. The displayed time is about \(T_m - 55\) ms. cg.snap is snapshot \(m-2\) and cg.nextSnap is \(m-1\); the new player is in neither and is not drawn. The data is in memory.
2. \(A + 5\) ms: snapshot \(m\) becomes nextSnap. The displayed time crosses \(T_{m-1}\); CG_TransitionSnapshot makes \(m-1\) current and CG_SetNextSnap installs \(m\). For the new player currentValid is false, so interpolate = qfalse (Listing 11, L291–L293). The entity's nextState now holds the disclosed origin and velocity. Still not drawn: the renderer iterates snapshot \(m-1\).
3. \(A + 55\) ms: snapshot \(m\) becomes current. The displayed time crosses \(T_m\). CG_TransitionEntity copies the state and, because the entity is ineligible, CG_ResetEntity places lerpOrigin exactly at the disclosed origin (Listing 12). In the same call, because snapshot \(m+1\) arrived about 5 ms ago, CG_SetNextSnap(m+1) runs immediately: the player is now valid, no teleport bit flipped, same parent and model, so interpolate = qtrue.
4. \(R\): the first frame drawn after that. CG_CalcEntityLerpPositions takes the third branch (Listing 14, L492–L517): each endpoint is advanced from its commandTime to its snapshot time along the server-written velocity, then blended with \(f \approx 0\). The player appears at approximately the disclosed position, moving smoothly from the first frame. There is no visual snap, because there was nothing on screen to snap from; the cost was paid entirely as the 55 ms of latency in step 3, on top of \(D_A\).

That is the nominal path. The other path is the one Figure 4 shows when you delay the following snapshot: if \(m+1\) has not arrived when the displayed time crosses \(T_m\), cg.nextSnap is null, the interpolation fraction is zero (Listing 15, L853), the eligibility flag stays false, and the renderer takes the fourth branch: extrapolate the single known state to the displayed time along the velocity, but no further than 100 ms past the state's commandTime, after which the player stands still until data arrives (fixture F8). When \(m+1\) finally arrives, CG_SetNextSnap marks the player eligible and the third branch takes over from wherever the extrapolation had reached, with a discontinuity equal to the extrapolation error. Box D5 bounds that error.

Two things follow for the timing model. First, \(B\) is not "one frame": on the nominal path it is a full snapshot period plus a few milliseconds, because the client will not draw a snapshot until it also holds the one after it, and the disclosing snapshot is by construction the first one to carry the player. Second, the server's 150 ms horizon and the client's 55 ms hold are not coordinated: the horizon buys \(H\), the hold spends \(B\), and neither side reads the other's number.

6.5 Local prediction and command replay

The viewer's own body follows a different rule. The client does not wait for snapshots to move the local player; it runs the shared movement code on the inputs it has already sent and shows the result now, then reconciles when the server's version arrives. This is the technique Bernier described for Half-Life [7] and that the Gambetta articles walk through with a live demo [9]; OpenMoHAA's version starts from the newest snapshot it holds and replays every command the server has not yet acknowledged.

    // Added in OPM: prediction check    //  Don't use the next snapshot if the prediction is about to be disabled    //  this prevent "blinking" issues like when entering a vehicle turret gun    //  where arms would be seen shortly    if (cg.nextSnap && !cg.nextFrameTeleport && !cg.thisFrameTeleport && !(cg.nextSnap->ps.pm_flags & PMF_NO_PREDICTION)) {        cg.predicted_player_state = cg.nextSnap->ps;        cg.physicsTime            = cg.nextSnap->serverTime;    } else {        cg.predicted_player_state = cg.snap->ps;        cg.physicsTime            = cg.snap->serverTime;    }

    // run cmds    moved = qfalse;    for (cmdNum = current - CMD_BACKUP + 1; cmdNum <= current; cmdNum++) {        // get the command        cgi.GetUserCmd(cmdNum, &cg_pmove.cmd);        if (cg_pmove.pmove_fixed) {            PM_UpdateViewAngles(cg_pmove.ps, &cg_pmove.cmd);        }        // don't do anything if the time is before the snapshot player time        if (cg_pmove.cmd.serverTime <= cg.predicted_player_state.commandTime) {            continue;        }        // don't do anything if the command was from a previous map_restart        if (cg_pmove.cmd.serverTime > latestCmd.serverTime) {            continue;        }

        if (cg.predicted_player_state.commandTime == oldPlayerState.commandTime) {            if (cg.thisFrameTeleport) {                // a teleport will not cause an error decay                VectorClear(cg.predictedError);                cg.thisFrameTeleport = qfalse;                if (cg_showmiss->integer) {                    cgi.Printf("PredictionTeleport\n");                }            }        }

        Pmove(&cg_pmove);        moved = qtrue;        // add push trigger movement effects        // CG_TouchTriggerPrediction();

    if (!moved) {        if (cg_showmiss->integer) {            cgi.Printf("not moved\n");        }        return;    }    // fire events and other transition triggered things    CG_TransitionPlayerState(&cg.predicted_player_state, &oldPlayerState);}

There is one inherited mechanism whose input has quietly disappeared. ioquake3 measures the difference between its predicted position and the server's, stores it in cg.predictedError, and decays it over cg_errordecay milliseconds so that corrections are smoothed (cg_predict.c:522–571). OpenMoHAA's view code still applies the decay:

    // add error decay    if (cg_errorDecay->value > 0) {        int   t;        float f;        t = cg.time - cg.predictedErrorTime;        f = (cg_errorDecay->value - t) / cg_errorDecay->value;        if (f > 0 && f < 1) {            VectorMA(cg.refdef.vieworg, f, cg.predictedError, cg.refdef.vieworg);        } else {            cg.predictedErrorTime = 0;        }

cg_view.c:635–646. But nothing writes a non-zero cg.predictedError at this revision (the only assignment in the predictor is the VectorClear on teleport), so the smoothing adds zero and corrections are applied as hard snaps. Whether that is intended (MOHAA's original client may well have behaved this way) or a leftover is fixture F12; either way it does not affect remote players, which is the subject of this post, and I mention it because the empty CG_TransitionPlayerState at cg_playerstate.c:38 is the same shape of thing.

For the timing model, prediction means the viewer's own position is ahead of the newest snapshot rather than behind it. The peeker sees themself at the corner about \(D_A + B\) earlier than anyone else sees them there, which is the peeker's advantage in the sense of the FDG study [24] and Chen's follow-up [25], and which section 9 has to keep separate from the disclosure lead: the two add up from the holder's point of view.

Medal of Honor: Allied Assault was built on a licensed Quake III Arena engine, and OpenMoHAA is an open-source re-implementation that borrows heavily from ioquake3 for the parts id Software published. It is tempting to summarise the relationship in one of two wrong ways: "OpenMoHAA is ioquake3 with different weapons", or "OpenMoHAA is its own engine". Neither survives reading the networking code. The skeleton is Quake III's, function for function, and in many places comment for comment: server frames, per-client snapshots, delta compression against the last acknowledged frame, a 32-entry packet history, reliable commands on a UDP netchan, a client clock that drifts, local prediction by command replay, and remote interpolation between two held snapshots. Every one of those is described in the classic write-ups of the Quake III model [17, 18, 20, 19] and every one of them is still recognisable here. What changed is the state that flows through the skeleton and the policies applied at three or four junctions, and those changes are exactly the ones that matter for a first reveal. This section lists them, then shows three of them side by side, pinned to ioquake3 commit 58839361 (2026-07-19).

7.1 Inherited skeleton, changed policies

7.2 Side by side: interpolation eligibility

The clearest example of structural inheritance with a policy change. The comment is the same, the shape is the same, and OpenMoHAA adds two disqualifiers and a flag. Note also the assignment of nextState: ioquake3 uses memcpy with the struct copy left in a comment; OpenMoHAA uses the struct copy.

		memcpy(&cent->nextState, es, sizeof(entityState_t));		//cent->nextState = *es;		// if this frame is a teleport, or the entity wasn't in the		// previous frame, don't interpolate		if ( !cent->currentValid || ( ( cent->currentState.eFlags ^ es->eFlags ) & EF_TELEPORT_BIT )  ) {			cent->interpolate = qfalse;		} else {			cent->interpolate = qtrue;		}	}	// if the next frame is a teleport for the playerstate, we	// can't interpolate during demos	if ( cg.snap && ( ( snap->ps.eFlags ^ cg.snap->ps.eFlags ) & EF_TELEPORT_BIT ) ) {		cg.nextFrameTeleport = qtrue;	} else {		cg.nextFrameTeleport = qfalse;	}

        cent->nextState = *es;        // if this frame is a teleport, or the entity wasn't in the        // previous frame, don't interpolate        if (!cent->currentValid || ((cent->currentState.eFlags ^ es->eFlags) & EF_TELEPORT_BIT)            || (cent->currentState.parent != es->parent) || (cent->currentState.modelindex != es->modelindex)) {            cent->interpolate = qfalse;            // if this isn't the first frame and we have valid data, set the            // teleport flag            if (cent->currentValid) {                cent->teleported = qtrue;            }        } else {            cent->interpolate = qtrue;        }    }    // if the next frame is a teleport for the playerstate, we    // can't interpolate during demos    if (cg.snap && (snap->ps.pm_flags & PMF_RESPAWNED)) {        cg.nextFrameTeleport = qtrue;    } else {        cg.nextFrameTeleport = qfalse;    }

For a first reveal both engines agree: an entity absent from the previous snapshot is not interpolated. The MOHAA additions matter for a different discontinuity, a player whose attachment or model changes (picking up a weapon that changes the model index, mounting something), and for the teleported flag that lets CG_ResetEntity skip its animation reset.

7.3 Side by side: trajectories

The second example is a case where MOHAA-specific state makes the code path materially different. Quake III sends a typed trajectory with a base position and an optional duration, and its evaluator switches on the type; a client-side player uses TR_INTERPOLATE by default, which means "just use the base", or TR_LINEAR_STOP when smoothing is on. MOHAA sends a velocity and a command time, and its evaluator is one straight line, clamped.

void BG_EvaluateTrajectory( const trajectory_t *tr, int atTime, vec3_t result ) {	float		deltaTime;	float		phase;	switch( tr->trType ) {	case TR_STATIONARY:	case TR_INTERPOLATE:		VectorCopy( tr->trBase, result );		break;	case TR_LINEAR:		deltaTime = ( atTime - tr->trTime ) * 0.001;	// milliseconds to seconds		VectorMA( tr->trBase, deltaTime, tr->trDelta, result );		break;	case TR_SINE:		deltaTime = ( atTime - tr->trTime ) / (float) tr->trDuration;		phase = sin( deltaTime * M_PI * 2 );		VectorMA( tr->trBase, phase, tr->trDelta, result );		break;	case TR_LINEAR_STOP:		if ( atTime > tr->trTime + tr->trDuration ) {			atTime = tr->trTime + tr->trDuration;		}		deltaTime = ( atTime - tr->trTime ) * 0.001;	// milliseconds to seconds		if ( deltaTime < 0 ) {			deltaTime = 0;		}		VectorMA( tr->trBase, deltaTime, tr->trDelta, result );		break;	case TR_GRAVITY:		deltaTime = ( atTime - tr->trTime ) * 0.001;	// milliseconds to seconds		VectorMA( tr->trBase, deltaTime, tr->trDelta, result );		result[2] -= 0.5 * DEFAULT_GRAVITY * deltaTime * deltaTime;		// FIXME: local gravity...		break;	default:		Com_Error( ERR_DROP, "BG_EvaluateTrajectory: unknown trType: %i", tr->trType );		break;	}}

typedef struct {	trType_t	trType;	int		trTime;	int		trDuration;			// if non 0, trTime + trDuration = stop time	vec3_t	trBase;	vec3_t	trDelta;			// velocity, etc} trajectory_t;

void BG_EvaluateTrajectory(const trajectory_t *tr, int atTime, const vec3_t base, vec3_t result){    float deltaTime;    if (atTime > cg_smoothClientsTime->integer + tr->trTime) {        atTime = cg_smoothClientsTime->integer + tr->trTime;    }    deltaTime = (float)(atTime - tr->trTime) / 1000.0;    result[0] = tr->trDelta[0] * deltaTime + base[0];    result[1] = tr->trDelta[1] * deltaTime + base[1];    result[2] = tr->trDelta[2] * deltaTime + base[2];}

typedef struct {	int trTime;	vec3_t trDelta;} trajectory_t;

The consumer differs accordingly. ioquake3's position function has three exits and no cap: interpolate if eligible and typed TR_INTERPOLATE, interpolate a TR_LINEAR_STOP client, otherwise evaluate the current state at the display time, which for TR_LINEAR_STOP is bounded by the trajectory's own duration.

static void CG_CalcEntityLerpPositions( centity_t *cent ) {	// if this player does not want to see extrapolated players	if ( !cg_smoothClients.integer ) {		// make sure the clients use TR_INTERPOLATE		if ( cent->currentState.number < MAX_CLIENTS ) {			cent->currentState.pos.trType = TR_INTERPOLATE;			cent->nextState.pos.trType = TR_INTERPOLATE;		}	}	if ( cent->interpolate && cent->currentState.pos.trType == TR_INTERPOLATE ) {		CG_InterpolateEntityPosition( cent );		return;	}	// first see if we can interpolate between two snaps for	// linear extrapolated clients	if ( cent->interpolate && cent->currentState.pos.trType == TR_LINEAR_STOP &&											cent->currentState.number < MAX_CLIENTS) {		CG_InterpolateEntityPosition( cent );		return;	}	// just use the current frame and evaluate as best we can	BG_EvaluateTrajectory( &cent->currentState.pos, cg.time, cent->lerpOrigin );	BG_EvaluateTrajectory( &cent->currentState.apos, cg.time, cent->lerpAngles );

cg_ents.c:796–822. Compare the four branches of Listing 14: OpenMoHAA has no trType to switch on, so the choice is made by the cvar and the eligibility flag alone, and the bound on extrapolation is the client-side cg_smoothClientsTime rather than a server-written duration.

The practical difference for a first reveal: an ioquake3 client with default settings draws a newly appearing player at the snapshot's base position and never extrapolates them; an OpenMoHAA client with default settings extrapolates from the disclosed origin along the disclosed velocity for up to 100 ms whenever the next snapshot is late, and otherwise interpolates trajectory endpoints that were themselves advanced from the command time. The MOHAA path is smoother in the common case and wrong by a bounded amount (box D5) in the rare one.

7.4 The path that does not exist in ioquake3

The third comparison is the point of the post. ioquake3's entity walk has no per-player geometric test at all: after the flag checks, the double-add guard and the broadcast shortcut, it is area connectivity, then PVS, then add. Its snapshot builder also excludes the viewer's own entity and takes the viewpoint from the player origin plus view height.

		// entities can be flagged to explicitly not be sent to the client		if ( ent->r.svFlags & SVF_NOCLIENT ) {			continue;		}		// entities can be flagged to be sent to only one client		if ( ent->r.svFlags & SVF_SINGLECLIENT ) {			if ( ent->r.singleClient != frame->ps.clientNum ) {				continue;			}		}		// entities can be flagged to be sent to everyone but one client		if ( ent->r.svFlags & SVF_NOTSINGLECLIENT ) {			if ( ent->r.singleClient == frame->ps.clientNum ) {				continue;			}		}		// entities can be flagged to be sent to a given mask of clients		if ( ent->r.svFlags & SVF_CLIENTMASK ) {			if (frame->ps.clientNum >= 32)				Com_Error( ERR_DROP, "SVF_CLIENTMASK: clientNum >= 32" );			if (~ent->r.singleClient & (1 << frame->ps.clientNum))				continue;		}		svEnt = SV_SvEntityForGentity( ent );		// don't double add an entity through portals		if ( svEnt->snapshotCounter == sv.snapshotCounter ) {			continue;		}		// broadcast entities are always sent		if ( ent->r.svFlags & SVF_BROADCAST ) {			SV_AddEntToSnapshot( svEnt, ent, eNums );			continue;		}		// ignore if not touching a PV leaf		// check area		if ( !CM_AreasConnected( clientarea, svEnt->areanum ) ) {			// doors can legally straddle two areas, so			// we may need to check another one			if ( !CM_AreasConnected( clientarea, svEnt->areanum2 ) ) {				continue;		// blocked by a door			}		}		bitvector = clientpvs;

	// grab the current playerState_t	ps = SV_GameClientNum( client - svs.clients );	frame->ps = *ps;	// never send client's own entity, because it can	// be regenerated from the playerstate	clientNum = frame->ps.clientNum;	if ( clientNum < 0 || clientNum >= MAX_GENTITIES ) {		Com_Error( ERR_DROP, "SV_SvEntityForGentity: bad gEnt" );	}	svEnt = &sv.svEntities[ clientNum ];	svEnt->snapshotCounter = sv.snapshotCounter;	// find the client's viewpoint	VectorCopy( ps->origin, org );	org[2] += ps->viewheight;	// add all the entities directly visible to the eye, which	// may include portal entities that merge other viewpoints	SV_AddEntitiesVisibleFromPoint( org, frame, &entityNumbers, qfalse );

		// entities can be flagged to be sent to a given mask of clients		// Removed in OPM		//  This doesn't make sense it it only supports half of the client		/*		if ( ent->r.svFlags & SVF_CLIENTMASK ) {			if (frame->ps.clientNum >= 32)				Com_Error( ERR_DROP, "SVF_CLIENTMASK: clientNum > 32\n" );			if (~ent->r.singleClient & (1 << frame->ps.clientNum))				continue;		}		*/

		// ignore if not touching a PV leaf		// check area		if ( !CM_AreasConnected( clientarea, svCheckEnt->areanum ) ) {			// doors can legally straddle two areas, so			// we may need to check another one			if ( !CM_AreasConnected( clientarea, svCheckEnt->areanum2 ) ) {				continue;		// blocked by a door			}		}		if (g_gametype->integer != GT_SINGLE_PLAYER && !(ent->r.svFlags & SVF_NOFARPLANE)) {			float farplane = sv.farplane;			if (farplane < 1) farplane = 12000;			if (farplane > 12000) farplane = 12000;			check = EntityDistCheck(origin, forward, parentEnt ? parentEnt : ent, farplane, ps->fov);			if (check == CULL_OUT) {				continue;			}

		if (g_gametype->integer != GT_SINGLE_PLAYER && ent->s.number < svs.iNumClients) {			if (!SV_ClientIsVisible(ent->s.number, client - svs.clients, check, forward, right)) {				SV_AddNonPVSSound(client, ent);				continue;			}		}		// add it		SV_AddEntToSnapshot( svEnt, ent, eNums, portalEnt, portalsky);

	// find the client's viewpoint	if (ps->pm_flags & PMF_CAMERA_VIEW)	{		VectorCopy(ps->camera_origin, org);		VectorCopy(ps->camera_angles, ang);	}	else	{		VectorCopy(ps->vEyePos, org);		VectorCopy(ps->viewangles, ang);	}	SV_AddEntToSnapshot(svEnt, SV_GentityNum(client - svs.clients), &entityNumbers, NULL, qfalse);

The left column is the whole of what a stock ioquake3 server does to decide whether you learn where another player is: is the entity in an area connected to yours, and is one of its clusters in your potentially visible set. That is the model in which wallhacks are cheap, and in which the peeker's-advantage literature was mostly written [24]. The right column adds a distance and direction classifier for every entity, a per-player line-of-sight test with memory and look-ahead, and an audio side channel for the players it withholds, all evaluated from the eye position rather than the origin. Nothing in the right column has a counterpart on the left, and the client code that has to cope with its consequences (sections 6.2 to 6.4) is the inherited Quake III client code, unchanged in the parts that decide what a first reveal looks like. That asymmetry, a server that withholds for reasons the client was never designed around, is why the timing model of sections 3 and 4 is the right lens for this engine in particular.

Two more references belong here for readers who want to go beyond what I cover. The Unlagged project's networking primer [20] and the sh-unlagged mod are the classic treatment of the other half of the fairness problem, lag compensation for hits, which this post deliberately leaves alone; van Waveren's DOOM III paper [10] describes id's next architecture, which kept per-client PVS filtering and dropped snapshot interpolation in favour of a different client model; and the netcodesimulator project is a small sandbox for the same four-clocks reasoning that does not depend on any engine.

Reading code closely turns up places where the source and the intent visible in the comments do not obviously agree. I want to be careful about what I do with those. A person reading a reimplementation of a twenty-year-old engine, without the original source, without the original developers, and without measurements, is not in a position to call any of them a bug: several are almost certainly faithful reproductions of the original binary's behaviour, some are deliberate simplifications, and at least one may be my misreading. What each of them deserves is a deterministic fixture: a scripted scene with known positions and velocities, run through the function in isolation, with the expected output written down in advance. If the fixture passes, the observation was noise. If it fails, the project has a test to decide what it wants. The table lists fourteen, in the order they appear in the post; all of them are filed here as fixture candidates and none as defects.

Three smaller ones, for completeness: the loop head computes a num that nothing reads, so sv_drawentities has no effect on the walk (sv_snapshot.c:621–624); the local player's eligibility flag set at cg_snapshot.c:280 is recomputed by the loop below it; and the per-viewer sound queue is capped at four, so a player who makes five sounds in a frame discloses four. None of these changes the timing model.

Sections 3 to 6 gave the corner a vocabulary and OpenMoHAA a mechanism. Neither gives a number. The horizon multiplier is three frames because someone chose three; the grace timer is 200 ms because someone chose 200. I do not think those choices are wrong. I think nobody, including me, knows whether they are right, because "right" depends on quantities that vary from corner to corner and link to link, and the only way to know their distribution is to measure it. This section is my attempt to say what a measurement-driven answer would look like. It is a model, not a result: I have no telemetry from a populated OpenMoHAA server, and every number in the figures below is simulated from assumptions that are stated where they are made.

9.1 Why one number is not enough

Take the three delays of section 3.3 one at a time. The delivery delay \(D_A\) is half a round trip plus queueing, and it jitters; a lost snapshot costs a whole period, and the next one arrives as a delta against an older base. The render delay \(B\) sits near one snapshot period in steady state (section 6.1) but walks off by tens of milliseconds after every clock reset and takes a second and a half to return, and it grows by up to the extrapolation cap when the next snapshot is late (section 6.4). The disclosure lead \(H\) is anywhere in \((-f, kf]\) depending on whether the approach is straight, curved, or made by a player who is standing still (box D4, fixture F4). None of these is a constant, and the interesting events live in the tails: the corner where a low-ping cheat gets a 120 ms lead, the corner where a high-ping player sees the attacker 150 ms late.

Worse, the population is heterogeneous in exactly the direction that makes a single setting bad. The cheat window is \(W = [H - D_A]_+\): it is largest for the cheater with the best link. The lateness is \(L = [D_A + B - H]_+\): it is largest for the honest player with the worst link. One \(H\) for everyone is therefore at once too generous to the low-ping cheat and too stingy to the high-ping player, which is the observation behind the per-client horizon of box D10. Any evaluation that reports an average over players hides this.

There is measurement work to build on. Tokey, Chen, Claypool and colleagues ran a controlled study of how much the peeker's advantage grows with latency [24]; Chen models who wins a peek under asymmetric latency [25]; Liu, Xu and Claypool's survey lays out the space of compensation techniques whose effects one would be measuring [26]; Riot describe sizing a client buffer from the measured jitter of their population rather than from a rule of thumb [27]; and two of Tariq10x's videos make, in a different register, the same case that FPS timing arguments should be settled by simulation and measurement rather than folklore [28, 29]. What I want from a model is narrower than any of those: for a setting \(k\) and a population of links and corners, the predicted distribution of \(W\) and \(L\), and how sure we are about it.

Bayesian modelling is the natural tool because the question is about unobserved future corners and the data are noisy, sparse in the tails, and measured through instruments that are themselves imperfect. The discipline matters more than the label:

1. Separate the latent quantities (the real \(S\), \(A\), \(R\), \(V\)) from the measurement process (logged timestamps on two unsynchronised clocks, a crossing time reconstructed offline from positions).
2. Choose likelihoods that match the data: positive, heavy-tailed delays; a lead that is quantised to frames; events that are censored when the player is never drawn.
3. Write priors in physical units and inspect what they imply before looking at data.
4. Carry every uncertainty through to the decision, so that the answer is a distribution over settings, not a point.

In one line: logged timestamps are not physical timing, and a model that treats them as such will be confidently wrong in the tails, which is where the corner is decided.

9.2 A generative model of the corner

I find it easier to trust a model that says how one event could have been generated than one that fits a curve to a histogram. For a single corner crossing \(i\), observed by one viewer, this is the story. The server discloses the target with lead \(H_i\), which section 5.9 showed is the horizon \(k f_i\) scaled by how much of it the geometry realised, \(\varphi_i \in [0,1]\), minus a frame-quantisation residual \(\rho_i \in (-f_i, 0]\). A straight approach gives \(\varphi_i = 1\); a curved one, or a stationary target under the speed gate, gives \(\varphi_i = 0\); intermediate values happen when the projected point clears the corner only some frames after it could have. The snapshot takes \(D_{A,i}\) to arrive, which is positive and heavy-tailed and depends on the link. The client then takes \(B_i\), which depends on its clock state and on whether the next snapshot is late. Some crossings end without the target ever being drawn, and those must be kept as censored observations rather than dropped. And every one of these is measured with error: the client's clock is offset from the server's, and \(V\) is reconstructed after the fact from logged positions.

Box D6 writes this down as a hierarchical model with partial pooling across clients, sessions, maps and corners, and gives illustrative priors in milliseconds. Box D8 looks at the same corner through information theory and explains why a cheat wants time rather than bits, and what the non-PVS sounds of section 5.8 leak.

with pm.Model(coords=coords) as corner_model:
    # partial pooling over clients, sessions, maps and corners (non-centred)
    u_client = pm.Normal("u_client_raw", 0, 1, dims="client") * pm.HalfNormal("tau_client", 0.5)
    u_corner = pm.Normal("u_corner_raw", 0, 1, dims="corner") * pm.HalfNormal("tau_corner", 0.5)

    # delivery delay D_A: log Student-t, location from the link
    alpha_A = pm.Normal("alpha_A", np.log(60.0), 0.6)
    beta_A  = pm.Normal("beta_A", 0, 0.5, dims="net_feature")
    sigma_A = pm.HalfNormal("sigma_A", 0.5)
    nu_A    = pm.Exponential("nu_A_minus_2", 0.1) + 2
    mu_A    = alpha_A + X_net @ beta_A + u_client[client_id]
    log_DA  = pm.StudentT("log_D_A", nu=nu_A, mu=mu_A, sigma=sigma_A,
                          observed=np.log(D_A_obs_ms), dims="event")

    # render delay B: same shape, centred on one snapshot period
    alpha_B = pm.Normal("alpha_B", np.log(55.0), 0.5)
    ...

    # realised fraction of the horizon: Beta regression on what the server logged
    theta   = pm.Normal("theta", 0, 1, dims="geom_feature")
    kappa   = pm.Gamma("kappa", 2, 0.1)
    pi      = pm.math.invlogit(Z_geom @ theta + u_corner[corner_id])
    phi     = pm.Beta("phi", pi * kappa, (1 - pi) * kappa, observed=phi_obs, dims="event")

    # derived quantities for a candidate k (frames) and frame length f (ms)
    rho = pm.Uniform("rho", -f_ms, 0, dims="event")
    H   = pm.Deterministic("H", k * f_ms * phi + rho)
    W   = pm.Deterministic("W", pt.maximum(H - pm.math.exp(log_DA), 0))
    L   = pm.Deterministic("L", pt.maximum(pm.math.exp(log_DA) + B - H, 0))

parameter                   truth  post mean        94% interval  r_hat
alpha_A                      4.01       4.08  [   3.94,    4.22]   1.00
beta_A[log_rtt_half]         0.90       0.91  [   0.85,    0.97]   1.00
beta_A[log1p_jitter]         0.30       0.31  [   0.27,    0.36]   1.00
sigma_A                      0.30       0.30  [   0.27,    0.32]   1.00
nu_A_minus_2                 4.00       3.03  [   1.88,    4.58]   1.00
tau_client                   0.20       0.26  [   0.17,    0.40]   1.00
alpha_B                      4.06       4.06  [   4.04,    4.08]   1.00
sigma_B                      0.22       0.22  [   0.21,    0.24]   1.00
theta[closing_speed]         1.10       1.04  [   0.97,    1.10]   1.00
theta[approach_angle]       -0.70      -0.68  [  -0.74,   -0.62]   1.00
kappa                        8.00       7.92  [   7.14,    8.76]   1.00
tau_corner                   0.35       0.28  [   0.16,    0.49]   1.00

derived, at k = 3 and f = 50 ms, over the same 600 synthetic crossings:
posterior mean E[W] = 14.1 ms    P(W > 0) = 0.54
posterior mean E[L] = 91.4 ms    P(L > 0) = 0.98

9.3 From posterior draws to a server setting

Inference says what the system does. A decision asks what the server should do. Suppose the model of box D6 has been fitted to telemetry and we hold \(S\) posterior draws \(\theta^{(1)}, \ldots, \theta^{(S)}\). For each draw and each candidate horizon \(h = k f\), simulate future corners and record

Then score each setting with a loss that says how much a millisecond of cheat window costs relative to a millisecond of lateness, and, because a rare 250 ms invisible attacker matters more than many harmless 2 ms misses, adds terms for the tails:

The setting to choose minimises the loss averaged over the posterior. The spread of the per-draw minimisers says how much the choice depends on what is still unknown. Figure 5 shows the frontier for one simulated population, and Figure 6 the spread; box D7 states precisely what the histogram is and is not. Everything in both figures is simulated from the assumptions printed in their captions, not measured from OpenMoHAA.

The model of section 9 is only as good as its event trace, and the trace has to be collected at the places in the code where the four clocks are actually stamped. The useful unit is one visibility candidate: one viewer, one target, one server frame in which the target was considered for inclusion. Not a per-packet average and not a per-match summary, because both erase the tails, and not only the inclusions, because the filter under study is the thing doing the selecting. Every point below is a place I would add a log line, pinned to the revision this post reads.

10.1 Instrumentation points

Two rules about clocks. Use the server's snapshot time and sequence number as the shared key between server-side and client-side records; never join on wall clocks. And treat the client's offset from the server as a quantity to estimate, with the engine's own round-trip estimate as its prior, rather than as a known constant; box D6 shows where it enters the likelihood.

10.2 One event per corner crossing

Joined across the points above, one candidate becomes one record. The field names are mine; the point of showing the record is to make clear that the server half and the client half are stamped on different clocks and joined by sequence numbers.

{
  "event_id": "match42:viewer7:target3:frame9181",
  "server": {
    "svs_time_ms": 182930,
    "frame_ms": 50,
    "k": 3,
    "mode": "NETO_CULLED",
    "check": "CULL_CLIP",
    "gate": "projected_trace",
    "trace_present": false,
    "trace_projected": true,
    "target_speed": 250.0,
    "grace_until_ms": 183130,
    "snapshot_seq": 4412,
    "included": true,
    "first_inclusion": true,
    "nonpvs_sounds_last_1s": 3
  },
  "geometry": {
    "map": "obj_team2",
    "corner_id": "hash-of-local-geometry",
    "approach_angle_deg": 12.5,
    "closing_speed": 287.4,
    "visibility_crossing_ms": 183041,
    "crossing_error_ms": 4.0
  },
  "client": {
    "packet_received_realtime_ms": 9928871,
    "server_time_delta_ms": -9745940,
    "cg_time_at_parse_ms": 182876,
    "entity_first_current_cg_time_ms": 182985,
    "first_position_branch": "trajectory_lerp",
    "extrapolated_ms": 0,
    "entity_first_rendered_cg_time_ms": 182985,
    "had_previous_state": false,
    "rendered_within_window": true
  }
}

10.3 Model checks

Bayesian syntax does not make a model trustworthy. The following checks matter more than which sampler was used.

Prior-predictive checks. Simulate complete matches from the priors before fitting. Do they imply plausible medians, tail spikes and map-to-map variation? If the prior regularly produces ten-second delays, negative leads, or a lead above \(kf\), which the implementation cannot produce, fix the model before looking at data.

Posterior-predictive checks. Can data simulated from the fitted model reproduce the empirical delay histogram, its extreme quantiles, the correlation with round-trip time, per-client differences, corner-specific behaviour and the rate of never-rendered crossings? A model that matches the mean and misses the tails is worse than no model here, because the tails are where the decision lives.

Calibration and out-of-sample evaluation. Hold out whole clients, sessions and maps, not random events: random splits leak repeated corner and client information and flatter the model. Use leave-one-group-out or its Pareto-smoothed importance-sampling approximation [30], report interval coverage, and score predictions with a proper scoring rule. For the simulation studies that precede any real data, use simulation-based calibration.

Sensitivity. Repeat the decision under alternative priors, tail distributions, censoring assumptions, clock-offset errors and cost ratios. A recommendation that changes from \(k = 1\) to \(k = 5\) under modest changes of assumption is not a recommendation; it is evidence that more telemetry is needed, and Figure 6 is the picture of that evidence.

The introduction listed the families of prior work this post leans on. This section goes through them one at a time, says what each contributes to the corner problem, and marks where I could not find a public treatment. It is a reading list with opinions, not a survey, and it is limited to what I could read and verify as of September 2026.

Cheating taxonomies

A wallhack is a consequence of giving an untrusted client state it is not entitled to use. Yan and Randell's classification of cheating in online games [1] puts it under cheating by exploiting a lack of secrecy: the protocol delivers information the rules of the game say the player should not have, and the client software is the only thing standing between the player and that information. Laurens, Paige, Brooke and Chivers [11] take the same view from the server's side and treat the problem as one of detecting the behavioural consequences of information a player should not have. Demenais' history of anti-cheat [2] traces the industry's response from server-side code to kernel-level drivers, which is the trajectory you get when the state cannot be withheld and the client must instead be watched; Riot's account of their own approach [16] is a first-party version of the same story. The framing of this post follows from the taxonomy: if the cheat is misplaced trust, the first question is how much to trust, and by how many milliseconds.

State exposure and preload depth

Park, Ahmad and Lee's BlackMirror [3] is the most careful public statement I know of the tension this post is about. They measure how much game state a client holds beyond what it is currently rendering, name the depth of that preloading as the resource a wallhack consumes, and observe that reducing it costs responsiveness; their solution is not to withhold state but to move the decision about what may be rendered into a trusted enclave. The same tension appears in Demenais' history [2] as the reason server-side approaches gave way to client-side ones. Section 3 of this post is an attempt to write the preload-depth tradeoff in time units rather than bytes, which is the unit in which both the cheat and the honest player experience it.

Server-side visibility filtering

The idea of not sending what cannot be seen is older than any of the implementations here: the potentially visible set [22] is a rendering optimisation that Quake-family servers reuse as a disclosure policy for free. The refinement that matters for wallhacks is a per-player line-of-sight test on top of the PVS. Medal of Honor: Breakthrough 2.30 shipped one, and OpenMoHAA reimplements and documents it as its anti-chams optimisation [4, 23]; sections 5.3 to 5.9 are my reading of that code. Counter-Strike: Global Offensive had a comparable server-side player occlusion feature, which I know only through third-party descriptions [5]. The CornerCulling projects implement the same idea for the Source engine and for Unreal with a stronger geometric test: they check whether any position the target could reach within a latency budget would be visible, using bounding volumes around the possible futures, where OpenMoHAA traces to one projected point. Riot's Fog of War for Valorant [6] is the best-known production system of this kind and is explicit about the two design choices this post keeps returning to: a look-ahead that is deliberately larger than the expected ping so that honest clients are not late, and a large investment in making the server-side test cheap enough to run for every pair of players every tick. CornerCulling's set-valued test and Fog of War's latency-aware horizon are the two natural upgrades to OpenMoHAA's single projected point, and box D10 sketches the second.

Snapshot interpolation and prediction

The client half of the corner is the subject of a large practitioner literature. Bernier's GDC paper [7] and the Valve wiki's description of Source networking [8], together with the GoldSrc lineage that preceded them [31], set out the standard vocabulary of client prediction, entity interpolation with a fixed delay, and server-side lag compensation. Gambetta's four articles and live demo [9] are the clearest short introduction I know. Van Waveren's account of the DOOM III architecture [10] is the interesting contrast: it kept PVS-filtered per-client snapshots but replaced remote interpolation with client-side simulation of every entity, corrected by snapshots, which changes what a late first snapshot means for the player being revealed. For the Quake III skeleton that OpenMoHAA inherits, Sanglard's review [17], jfedor's protocol notes [18], the Unlagged networking primer [20] and the Swinburne game-structures report [19] between them cover snapshots, delta compression, the client clock and the interpolation rule; section 6 of this post is those documents applied to the one situation they do not discuss, an entity that appears for the first time.

On the peeker's advantage specifically, Riot's netcode article [27] explains how they sized interpolation and buffering from measured population jitter; Tokey, Chen, Claypool and colleagues [24] measured the advantage under controlled added latency; Chen [25] works out who wins a peek when the two players have different latencies; and Liu, Xu and Claypool's survey [26] organises the compensation techniques whose side effects those measurements observe. Tariq10x's videos, cited here by title and channel, argue in an accessible register that client prediction changed online games [21], that Quake III's netcode is worth teaching [32], that sub-tick timing does not solve what people think it solves [28], and that these questions should be settled by simulation rather than folklore [29]; the accompanying simulator is a local sandbox for exactly the artefacts section 6 describes. Two MOHAA-specific artefacts belong here as well: sh-unlagged, a wrapper around Spearhead's game module that reconstructs and reworks its netcode from the outside, and my own interactive demo of the MOHAA snapshot pipeline, which section 3 leans on for intuition.

Probabilistic checking

If the server cannot withhold everything, it can ask how likely a player's behaviour is without the withheld information. Laurens and colleagues [11] do this for wallhacks directly: they estimate, from the server's own geometry, how often a player aims at opponents who are occluded, and flag those for whom that rate is implausible without cheating. The relation to this post is complementary. Their detector is a likelihood ratio on the player's behaviour; the model of section 9 is a likelihood on the system's timing. A disclosure policy chosen well makes their detector's job easier, because a cheat with a smaller window has less to act on, and their statistic is a natural addition to the telemetry of section 10.

Cryptographic hidden state

The strongest form of not trusting the client is to make the hidden state cryptographically inaccessible rather than merely unsent. Dark Forest [12] did this for a turn-based strategy game with zero-knowledge proofs: players prove that their moves are legal without revealing where they are. Ingonyama's discussion of a cryptographic fog of war [13] surveys what it would take to extend the idea. For a shooter at 20 server frames per second, with a visibility predicate that depends on a BSP trace between two moving eyes, the cost is far outside what a proof system can do today, and the essential difficulty of this post survives even in principle: whatever is proven, the client must eventually receive the opponent's position early enough to draw it, and that moment is the corner problem again.

Trusted client execution

BlackMirror [3] is also the reference point for the middle road between withholding state and trusting the client: run the visibility decision inside a hardware enclave on the client, so that the untrusted renderer only ever receives what an honest renderer would draw. The paper reports the overhead of doing this for a real game and is honest that the overhead is not free. Seen through section 3, an enclave moves the disclosure moment from the server to a trusted component on the same machine as the cheat, which removes the delivery delay from the cheat's window without changing the render delay; it is a way to buy back the milliseconds a conservative server horizon costs honest players, at the price of trusting the enclave.

Bayesian modelling under imperfect measurement

The statistical stance of sections 9 and 10 is standard and I claim nothing new in it. Gelman and colleagues [14] and McElreath [15] are the references for hierarchical models with measurement error and censoring, for prior and posterior predictive checking, and for the discipline of treating a logged quantity as a noisy observation of a latent one; Vehtari, Gelman and Gabry [30] for the cross-validation used in section 10.3; and PyMC for the notation of the sketch in box D6. What is specific to the corner is only the structure: a lead that is quantised to frames and scaled by geometry, two delays on different clocks, and a decision whose loss is asymmetric in a way the operator has to state.

Read together, these families cover information exposure, state dissemination, interpolation delay, visibility filtering, probabilistic verification and secure hidden-state handling. What I could not find, and what this post attempts, is a single probabilistic account in which the server's disclosure moment, the cheat's earliest access, the true visibility crossing and the honest client's first rendering are one timing model, fitted to one event trace, and turned into one decision. That gap may be a gap in my reading rather than in the literature, and I would be glad to be pointed to work that closes it.

I started this post to write down my own model of how a MOHAA server hides players and what that costs, and to check it against the code rather than against my memory of the code. What I ended up with is less a verdict than a vocabulary. There is no universal cutoff for how early a server should disclose a player, because the same setting is both too generous to the cheater with the best link and too stingy for the honest player with the worst one. But there is a universal structure. The disclosure lead \(H\), the delivery delay \(D_A\) and the render delay \(B\) fix the cheat's window \(W = [H - D_A]_+\) and the honest client's lateness \(L = [D_A + B - H]_+\); pushing \(H\) up buys less lateness with more early information, pushing it down buys the reverse, and inside the band where both are nonzero their sum is exactly \(B\). Everything else is a question about the distributions of those three quantities on a real population, and those are things to measure, not to argue about.

On that structure, OpenMoHAA at the revision I read sits at a defensible point. It filters per client rather than per PVS, it tests present line of sight first and projects both players three server frames ahead only when the present test fails, it keeps a released player visible for a 200 ms grace period, and it lets withheld players make themselves heard. My reading also found several places where the code does something other than what a comment or a name suggests, and I have tried to file each of them as an observation with a deterministic fixture attached rather than as a defect, because some of them will turn out to be intentional once someone who knows the history looks at them.

The Bayesian part is a proposal, not a result. What it would give a server operator is not a number but a sentence: given these clients, maps, corners, clocks and costs, here is what we believe will happen under each setting, and here is how uncertain we still are. Figures 5 and 6 are what that sentence looks like with simulated inputs; the point of section 10 is that the real inputs are logged at a dozen identifiable lines of code.

So this is where I would like help. If you know the OpenMoHAA or MOHAA source history better than I do, tell me where my reading is wrong or where an observation in section 8 is intentional. If you have a counterexample to the timing model, a corner that behaves differently from Figure 1 for a reason the model does not have room for, I want to see it. If you run a populated server and can log even a fraction of the event of section 10.2, I would rather fit a model to your data than keep simulating. And if you think the whole approach is wrong, I would like to hear that too, preferably with a measurement attached. The easiest way to reach me is on GitHub, as fecmtc. This post describes my current conceptual model of one codebase, chosen because it is the one I know best; it is not the project's documentation, it does not speak for the people who wrote the code, and it is offered in the hope of being corrected.

I used AI in many ways while writing this blog post. Here is exactly how I used it: (i) I used Claude to help with the frontend (HTML/CSS/JS), including the interactive figures; (ii) I used Claude to read and cross-check source code and commit history at the pinned revisions, and to keep every excerpt byte-identical to the source it links to. Every claim about what the code does was checked by me against those excerpts, and the mistakes that remain are mine; (iii) I used Claude and GPT to dig deeper into the literature. I was familiar with most of the netcode material, but they helped me find some references I had not seen before, such as the behavioural-detection and cryptographic-fog work; (iv) I asked both Claude and GPT to proof-read the mathematics and the prose. They caught notation inconsistencies and helped me trim the derivations; (v) finally, I tried my best to write things myself, in my own words. Yet, some parts were edited by GPT and Claude for readability. Ultimately, the views and opinions expressed in this post are entirely my own.