127b8077f5828bba86db8a3b4d6e61921216ab83
207
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  CydandClaude Opus 5
|
127b8077f5 |
A solo race has no packets to keep
The SPOOLS folder was empty after a solo run because there was nothing to put in it, and the code said so nowhere. Recording captures the packets this station RECEIVES. A race with no other machines in it neither sends nor receives any - L4NetworkManager::ExclusiveBroadcast walks the remote host list and a solo race has none - so the tee is never called, the recorder never arms, and Save returned in silence. Correct behaviour, invisible reasoning. The comment I put in the front end claimed the opposite, that "a single-player run records as readily as a lobby one". It does not, and the claim is now the truth instead. The same gap has a consequence I had not drawn out either: a RACER's recording is not the whole race, because its own pod is simulated locally and never arrives as a packet. A Live Cam races nothing, so every pod reaches it over the wire - it is the only station that hears the lot, which is a better argument for the feature than the one I started with. Say all of this where it will be read: the log now explains an empty recording instead of leaving the folder to be puzzled over, and the front end explains why the row is offered on races that cannot use it (hiding it conditionally would read as a bug of its own). Not fixed here: capturing locally simulated entities, which would make solo recordable and a racer's spool complete. It is feasible - Entity::Execute already produces each local update in wire form every frame whether or not anyone is listening, and NetworkPacketHeader is four fields, all of them available locally - but it means synthesising packets that were never sent, and that wants proving against playback rather than landing on the evening of a test with players. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
f5ad3036cc |
Keeping the race, chosen under YOUR ROLE
The recording tee, which is what the Live Cam was for. L4SpoolingApplication turned out not to be the obstacle it looked like. The review build already records by teeing - it spools each packet and then hands it on - and what tied that to a review build was never the recording but where the buffer came from. MissionReviewApplicationManager is only a pool allocator, and SpoolFile takes whatever buffer it is handed, so SpoolRecorder owns one buffer and needs none of it. One hook covers what the review build taps in two places. Both InterestManager and NetworkManager derive from NetworkClient, so NetworkClient::ReceiveNetworkPacket sees entity updates and mission control alike, and it sits before Dispatch so a packet is kept whether or not anything downstream wants it. The recorder arms on the first packet rather than at the green light, because playback rebuilds the world from the LoadMission and RunMission packets and a spool that starts at the flag cannot be replayed. Two things a live recorder must do that the review one did not. It must not touch the packet. The spooler restamps in place with local arrival time, which is right in itself - playback paces off those stamps and packets from different senders carry different clock origins - but the sender's timestamp is what Simulation::ReadUpdateRecord hands to RP412NETCLOCK and from there to the projection. Overwriting it live would feed arrival jitter into where remote pods are drawn, which is the tick just fixed. So the write position is taken first and the COPY is stamped, in the spool, afterwards. And it must not take the race down. SpoolFile::SpoolPacket answers a full buffer with PostQuitMessage - a fair end to a replay, and killing the race being recorded on a live host. The recorder checks the room first and stops, and says so. RP412RECORDSIZE defaults to 100MB rather than the review build's 6, on Cyd's call: a full grid sends around 17KB a second, so six megabytes is six minutes and a hundred is an hour and a half, which costs nothing on any machine that can run this. Saved at the buzzer - the first of the two StopMissions, the end of the race rather than the fade timer - into SPOOLS\<timestamp>.spl and copied to last.spl, matching where the review build looks. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
94e1cf2cf0 |
A window that answers while it waits
Launching a network race connects to each machine in turn and retries while one is not listening yet, because they finish loading at different moments. That part is deliberate and stays. What was not deliberate is that the wait slept without pumping messages, so Windows saw a process that had stopped answering and painted the whole thing "Not responding" - for up to two minutes, with no indication of which peer was missing, how long remained, or any way out. It runs before the engine block, so there is no render loop keeping the window alive either. Three changes, both transports: Pump while waiting. Every sleep on the connect path goes through NetTransport_PumpAndSleep, so the window keeps painting and can be moved. It is re-entrancy guarded, because dispatching a message can run application code that reaches a connect of its own, and nested pumping would deliver messages twice and let an inner wait swallow the escape meant for the outer one. Shorten the deadline. Two minutes suited the arcade, where a pod that was still booting would always answer eventually on a LAN with nothing else to go wrong. Over the internet a machine silent for twenty seconds is not coming. RP412CONNECTWAIT, 2 to 300, default 20, documented in environ.ini. Say what is happening. The title bar names the peer and counts down, and ESC gives up at once - the title being the one surface guaranteed to exist this early, since there is no renderer yet to draw a progress screen with. The cancel latch is cleared when a connect sequence begins so that an escape pressed during one race cannot cancel the next. The Winsock path is only partly fixed and the code now says so: connect() there is still blocking, since the socket is only made nonblocking after it succeeds, so an unreachable host - filtered rather than refused - still sits in the OS SYN retry for around twenty seconds. Fixing that needs FIONBIO before connect() and a select() on our own timeout. Left for when LAN play comes up; a Steam host goes through SteamNetTransport::Connect, which is fully covered. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
b0b40559d5 |
A fraction of zero is a place, not an absence
The drawn pod stalled about fifteen times in 293 frames while the
simulation stepped perfectly smoothly through the same window - and 15 of
293 is 5%, which is exactly the count of frames the earlier trace found
sitting at a render fraction of zero. That was the whole clue.
GetRenderToWorld tested the fraction to decide whether to interpolate at
all:
if (renderStepFraction <= 0 || !RenderInterpolationEnabled())
*out = localToWorld;
Drawing at fraction f means drawing at the start of the step plus f of it,
so f = 0 means the START of the step. localToWorld is its END. The two are
a whole step apart, about a metre at racing speed.
behind is a whole number of milliseconds against a 20ms step, so it lands
on exactly zero roughly one frame in twenty. On those frames the pod was
drawn a full step ahead of itself and snapped back on the next one. Three
times a second at 59fps, regular because the beat between frame rate and
step rate is regular, and worst when a pod crosses the view quickly -
which is the symptom as it was first described, and it took this long to
find because every simulation trace was right. Only the drawing was wrong.
Ask renderStepTaken instead, which is what the condition meant all along.
Interpolating at f = 0 is continuous with its neighbours: each frame
advances the drawn position by frame_time / step whether or not a step
boundary falls between the two, which is the entire point.
The same mistake was in DPLEyeRenderable's rebuild gate, using the
fraction as a proxy for whether interpolation was running. Same fix.
renderStepTaken is cleared where localOrigin is assigned outside the step
loop, so a stale snapshot is never blended from.
Render path only - localOrigin is untouched, so physics, collisions and
determinism are unaffected.
The foreign-eye rejection added in the previous build turned out not to be
the cause: it rejected between zero and three samples per window against
stall counts in the twenties. Keeping it, since sampling one viewpoint
against another was still wrong, but it was not this.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
CydandClaude Opus 5
|
d680cce5a2 |
Twenty frames exactly is a render schedule, not a race
The anchor worked where it was aimed. Per-step stalls in the replicant went from 11, 16 and 36 in a window to 0, 0, 0, 0 - four consecutive windows clean - and the single capture that remains shows a pod braking, steps rising 0.214 to 0.261 and then shortening, which is a pod slowing down rather than a target jumping. The on-screen count did not follow, and its own numbers say why. The period came back as 0.34s with minimum and maximum identical to six figures: twenty frames, exactly, every time. Nothing in a network or a simulation keeps time that well. A render schedule does. A camera station draws the map on the gauge wheel as well as the world, and that pass runs the eye renderable too, so gEyeFrame ticked for it and the trace was comparing the map viewpoint against the main one. The stall and lurch counts converging on the same number said it too, since a stray viewpoint yields one short step going out and one long one coming back - in pairs, which is what the counts became. Reject a sample whose eye has jumped more than twenty metres since the last one, and count the rejections rather than hiding them. A real camera at racing speed moves under a metre between frames, so the threshold is far outside anything legitimate while still tolerating a genuine cut from one trackside camera to another. That is the fifth time in this hunt the instrument rather than the game turned out to be at fault, and all five were the same mistake: sampling across two frames of reference that were never the same one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
331bc10365 |
The deadline belongs on the sender's clock
The prediction test answered clearly, though not through the verdict label - that compared two noise floors with no absolute threshold and so cried TIMING over errors of a millimetre. Read the magnitudes instead: extrapolating the sender's own position and velocity across the gap between two of the sender's own timestamps lands within 0.0005 to 0.011m. Constant velocity holds to MILLIMETRES over one interval. Against corrections of 0.25 to 0.66m that is a factor of five hundred, so the two cannot be the same quantity. The corrections are not prediction failure at all - they are the latency offset, which is what a dead reckoner is supposed to carry. That leaves the target, and the fault is mine. The dead reckoner projects to updateOrigin + velocity * (nextUpdate - lastUpdate), so that difference becomes a DISTANCE once multiplied by speed. lastUpdate is the sampling moment RP412NETCLOCK computes, on the sender's clock. The median predictor I added set nextUpdate from Now(), ours - so the subtraction spanned two different timelines and yielded the interval plus however late that particular packet ran. At 52 m/s each millisecond of that is 52mm. Fifteen milliseconds of ordinary jitter is three quarters of a metre of target error, enough to collapse a one metre step to a third, and only on the packets that ran late. An intermittent tick, worst when a pod is close and fast - which is the symptom as it was reported. Anchor nextUpdate to lastUpdate and the difference is the predicted interval exactly. The target then depends on what the sender said and how fast it is going, and not at all on the route the packet took. NetClock confirmed live in the log, offset 52735ms, which is these two machines' launch times differing now that the clock counts from launch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
d147c093b2 |
Score the sender against itself
The tick is now fully accounted for. Corrections arrive about 26 times a second per pod, mean 0.25 to 0.66m against a step of roughly a metre. localOrigin is never snapped during a mission - only updateOrigin is replaced - so the pod position stays continuous and its TARGET jumps. The lerp then translates a target discontinuity into a step-size one: fifteen steps smooth to a tenth of a percent, then a single step at 20-33%, then recovery. Every capture has that shape and the ratios match the correction size arithmetically. Position is C0-continuous, so no amount of position interpolation can hide it; the discontinuity is in the rate. Before smoothing anything, ask whether the correction is even real. Half a metre at 52 m/s is ten milliseconds of travel, and a dead reckoner tracking constant velocity across a 38ms gap should be right to within centimetres. That smells like evaluating the projection at the wrong instant rather than like a prediction that genuinely failed. Settle it without involving any clock we do not trust. Take the position and velocity the sender reported last time, carry them forward by the gap between the two SENDER timestamps, and compare against the position the sender reports now. Both stamps come from one machine, so latency, clock offset and RP412NETCLOCK play no part whatsoever. Split the error along the path and across it. Along is time: divided by speed it IS the milliseconds the window is out by, and its sign says which way. Across cannot be a timing fault at all - that is a pod turning, and no clock fix would touch it. TIMING says fix the extrapolation window and the tick shrinks at the source with no smoothing and no lag. MANOEUVRE says the corrections are honest, the pods really are cornering, and smoothing is the only remaining answer. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
da7c35cac1 |
Sample the stall, not the calm before it
The raw step lengths came back immaculate - 1.02918, 1.03069, 1.03186, monotonic to a tenth of a percent - in the very window that counted sixteen stalls. Both readings are correct. The twelve printed steps were the FIRST twelve of the window and the sixteen stalls were among the other two hundred and thirty nine, so the trace sampled a calm quarter second and said nothing whatever about the tick. That also disposes of the alternation theory it was built to test: where the pod moves steadily the steps are steady, and no high-low beat exists to find. Keep the last sixteen steps rolling instead, and freeze a copy the instant a stall is seen, along with the ratio that triggered it and the dead reckoner blend fraction at that moment. What prints is then the run-up to an actual tick with the tick last in the list - the shape at the event rather than the shape near it. The stationary-pod windows remain ratio noise and stay discounted: steps of a few tenths of a millimetre make every ratio meaningless, which is why the capture requires a full sixteen-step history behind it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
3c49bc4fd1 |
A running mean is blind to alternation
The split is unanimous and one detail settles it: in two windows the eye travelled 0.0001m - a trackside camera standing perfectly still - and the pod stalled 15 and 29 times anyway. CameraShip::FollowGoal is exonerated, and so is the pan. It is the pod motion itself. That contradicts this trace only in appearance. It has been comparing each step against a RUNNING MEAN, and a running mean cannot see an alternating pattern: high, low, high, low averages to the mean and nothing ever looks anomalous. The renderer compares each frame against the PREVIOUS one, which catches exactly that, and counted 15 to 46 stalls in the same motion this trace called clean. So the mean test never ruled out uneven motion. It only ever ruled out drift. Apply the same consecutive test one level down, and keep twelve consecutive step lengths verbatim so the shape can be read rather than inferred from counters. Twelve steps is a quarter second at 50Hz - long enough to show a beat, short enough to fit on one line. The clock fix confirmed itself in passing: the reported intervals are now multiples of 17ms, the frame time, which is the honest resolution for a per-frame detector. The 1/32s artifact is gone. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
2bd824e16e |
The clock counts from launch, not from boot
Chasing the tick turned up why its period looked quantised: every interval the trace reported was a multiple of 1/32s, which is the spacing between representable float32 values near 474196 - this machine's uptime in seconds. GetRTC returned QueryPerformanceCounter scaled to milliseconds since BOOT, so (Scalar) Now() was a number near half a million and had lost resolution accordingly. That is not only a measurement problem. Scalar is a 32-bit float, so any absolute time held in one degrades as the number grows: 3.9ms apart after nine hours of uptime, 15.6ms after a day and a half, 31.25ms after three days - past which the clock cannot resolve a single 20ms physics step. Two places subtract absolute times in float and inherit it. L4CTRL polls the joystick when (Scalar)Now() - lastJoystickUpdate exceeds 50ms, and lastJoystickUpdate is a Scalar, so that test becomes 62.5ms after three days of uptime and 125ms after twelve: a player's controls get less responsive the longer their machine has been switched on, with nothing on screen to explain it. The smoke emitter in L4VIDRND compares myLastSmoke plus an interval against now, and once the interval falls under the spacing the addition rounds to no change at all. Separately, GetRTC returns a long, and milliseconds since boot overflow one after 24.8 days. Counting from launch fixes the whole class at the source. Every Time arithmetic path is untouched, because those subtract ticks as integers and were always exact - which is also why the simulation itself was never affected, and why the render fraction measured clean. The origin is taken in Startup rather than on first use, so it is fixed before anything reads the clock and no two threads can race to set it. Peer machines already disagreed about this origin, having booted at different moments, so the network is no worse off; reconciling that is what RP412NETCLOCK does. The fix is self-checking: the trace's interval readings should stop being multiples of 0.03125. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
5cd9783d38 |
Ask whether the pod stalled or the pan did
Two things are now ruled out with evidence rather than argument. Render interpolation is healthy. behind is computed by Time::operator-, which subtracts ticks and only then converts to float, so it carries the clock full millisecond precision. With a 20ms step that gives the fraction twenty possible values, and the measured 17 frames of 293 sitting at zero is 5.8% against the 5% a sawtooth crossing zero would produce by itself. Mean 0.474, never once pinned at 1: it is sweeping correctly. And the trace period was never a period. Every interval it reported - 0.03125, 0.125, 0.375, 1.90625 - is a multiple of 1/32s, which is the spacing of a float32 near 474196. That is this machine uptime in seconds, because GetRTC returns QueryPerformanceCounter scaled to milliseconds since boot, so (Scalar) Now() is a number near half a million and its resolution has decayed to 31ms - coarser than the physics step it is being used to time. The stall COUNT is unaffected and real, at three to five a second; the interval between them was measurement noise. Logged separately as its own defect. What is left is that the angle is measured BETWEEN the pod and the eye, so a hitch in the pan reads exactly like a hitch in the pod - and the symptom is a pod moving PAST, which is when the pan rate peaks. Measure each one on its own, by the same consecutive-frame ratio, and let the trace say which. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
9c886efd8d |
A running mean cannot keep up with a pod that is closing
The period trace came back with no period - intervals scattered from 0 to 2.5s - so the twenty-step renormalisation is not the culprit and neither is any other fixed cadence. That is a real answer, and it also exposed a fault in the instrument that produced it. The angular step varies six hundredfold across the samples, 0.12 mrad with the pod at 119m against 77 mrad at 5.4m. Judging each frame against a long running mean therefore reports the mean own lag as a lurch whenever the pod is closing, which is exactly what the window matching the reported symptom was doing: 26 lurches at 5.4m range, almost all of them measurement artifact. Compare each frame against the frame before it instead. Consecutive frames of a smooth pass are nearly equal however fast the sweep, so the ratio is immune to range, and a tick is specifically one frame that barely moves followed by one that catches up - so time the stalls, not the lurches. Also read renderStepFraction directly, per drawn frame, which should have been the first measurement taken. It is the number the interpolation actually uses. Sweeping smoothly from 0 to 1 means interpolation is working; pinned at 1 means the simulation is behind and every frame is drawing the same latest step, which is stepping at the physics rate no matter how clean the packets were. The camera station rasters the map and the gauges as well as the world, so falling behind is entirely plausible and would show here and nowhere else. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
8d372ec067 |
The tick has a period, and the period is the evidence
Rejecting the sender-stall theory was right: a gap of over a second is a death pause, not a tick. The remaining symptom is described precisely - a RHYTHMIC tick as a pod moves past the camera - and rhythm is the clue. A fixed period points at a cadence in our own code, because the network has no period. There are at least four candidates and they are only distinguishable by their interval: the 20ms physics step, the 30ms update rate, the sawtooth in the dead reckoner blend (percent climbs from 0.29 to 0.87 across each update interval as lastPerformance approaches nextUpdate, then resets), and the twenty-step quaternion renormalisation in Mover::BeginStep, which falls at 0.4s - a few times a second. So measure the interval rather than guess among them. Per frame, take the angle the traced pod subtends at the eye, flag the frames whose angular step is far above the running mean, and report the time BETWEEN those events. Angle rather than distance because a pod crossing the view moves far across the screen while barely changing range, which is the geometry the tick was reported in. Both samples come from one frame, marked by the eye's own frame counter rather than assumed from draw order, and the renderer reports on the same pod the mover trace describes - MoverTracedEntity now exposes that latch. Two traces about two different pods, or two different frames, would compare nothing; that mistake has already cost this investigation three wrong answers. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
9107fb4cd9 |
A quiet sender and a stalled loop are not the same silence
With the clamp in, spikes now occur only in windows where updates stopped arriving. Steady state is clean - zero spikes, 250 of 250 steps blending, the prediction within 18ms - while the one window holding a 1.236s gap carried all four spikes. The clamp is doing exactly what it was built to do: 0.01976 / (0.25 + 0.01976) is 0.0733, matching the logged blend floor of 0.0732601 against the old 0.0097. So what is left is not jitter. It is the absence of data for over a second, and no predictor can invent motion it was never told about. The useful question is whose silence it is, and the answer is already in the arrival pattern. A long gap followed by ordinary 30ms gaps means the sender went quiet - their machine or the connection. A long gap followed by a burst of near-zero gaps means the packets were sitting in the queue while OUR loop was busy elsewhere, and we read them all at once the moment it came back. From inside the dead reckoner the two are indistinguishable, and they want opposite fixes. Record the widest gap, the count over 200ms and the count under 5ms, per entity, and let the trace name which pattern it saw. This matters more than it might: the camera station only recently began rastering the map, which is exactly the kind of work that stalls a main loop. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
178714198a |
The warmup path was the one that skipped the clamp
Live trace of the median predictor: in steady state the tick is gone - zero spikes over five seconds where there were seven, every step blending instead of 182 in 250, the blend fraction floored at 0.294 instead of 0.014, and the prediction within 13 to 20 ms of the gap that followed it. But the log also read "predicting 2.054s", above the 1.0s clamp, which should not have been reachable. It was: the fewer-than-three-samples path returned the raw gap without clamping it. The arithmetic identifies it exactly - 0.0201 / (2.054 + 0.0201) is 0.009685, against a logged blend fraction of 0.00968523. So the old near-stall survived, confined to the first three updates after an entity appears. That is every respawn, and a pod is being watched closely at exactly that moment. Route every path through one ClampPredictedInterval, and tighten the bounds now that the real send rate is known to be about 30ms: nothing slower than half a second enters the sample window, and no prediction reaches beyond 250ms. The second of those puts a floor under the blend fraction itself - at a 20ms step the worst case is 0.02/(0.25+0.02), roughly 7% of the gap per step, so a pod converges on its projection in a dozen steps rather than crawling toward it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
ec815b6216 |
One late packet is not the new rate
Another player's pod is moved between updates by dead reckoning, which
advances it toward the projected position by a fraction of the remaining
gap each step:
percent = time_slice / ((nextUpdate - lastPerformance) + time_slice)
That fraction is decided by nextUpdate, so predicting when the next
packet lands is not cosmetic - it sets how far every step moves. The
prediction was labelled HACK in the original source and deserved it: the
next gap was assumed to equal the previous gap. On a LAN the gaps were
all alike and it held. Over Steam a single late packet doubles the
expected gap, percent collapses, the pod barely advances for one step and
then catches up on the next - a visible tick.
Measured on a live connection, in the replicant's own step grid: 7 spikes
in 5 seconds, about 1.4 a second, matching the reported symptom, with
percent bottoming out at 0.014 against a normal range of 0.27 to 0.95.
Predict from the median of the last eight gaps instead. A median has a
breakdown point of half its samples, so one straggler - or three - moves
it not at all, while a genuine change in the send rate still carries it
within a few updates. Gaps that are non-positive (duplicate or reordered)
or multi-second (a join or a stall) never enter the window, and the
window is reset outright when the stream is interrupted.
Against the measured jitter pattern the blend fraction holds 0.282..0.286
where it previously swung 0.095..0.294 - a spread fifty times smaller.
This changes how remote pods MOVE, not merely how they are drawn, so it
feeds collisions with them as well. RP412NETPREDICT=0 restores the old
prediction for comparison on the same build, and the environ.ini entry
says to keep the setting alike on every machine in a race.
The RP412CAMLOG trace now also reports the interval being predicted and
the worst one-step-ahead miss, scored per entity rather than through the
file-scope statics the percent readings use - those are written by
whichever mover ran last, which is exactly the crossed frame of reference
this whole investigation kept tripping over.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
CydandClaude Opus 5
|
e029113ade |
A replicant is measured in its own step
Three previous attempts at "is the watched pod's motion uniform" all
sampled it from somewhere else - the camera's step grid, or an arriving
packet's timestamp - and two independent clocks alias against each other
whatever the game is doing. Those numbers could never separate a real
hitch from the measurement's own beat, and each of them cost a deploy to
find that out.
This one has a single frame of reference: consecutive steps of the entity
being asked about, taken inside Mover::DeadReckon, which IS a replicant's
own per-step performance.
It also reports the mechanism rather than only the symptom. percent is how
far each step moves toward the projected position:
percent = time_slice / ((nextUpdate - lastPerformance) + time_slice)
so it depends on nextUpdate being a decent guess at when the next packet
lands. A poor guess makes the fraction swing, and a swinging fraction is
uneven motion however clean the packets were. The trace reports its range,
how many steps blended rather than snapped, and spikes and stalls against
the entity's own running mean.
One entity only, the first replicant seen, because the counters are shared
and a full grid would blend into noise.
What confirms: spikes or stalls in the entity's OWN steps, or a percent
range that swings. Either is real, because there is no second clock here to
blame. What refutes: uniform steps and a steady percent - then a replicant's
motion is fine and the tick is in presentation, and the remaining suspects
are frame delivery and the map raster.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
CydandClaude Opus 5
|
9a674e9241 |
The camera measures its own smoothness
The last instrument was mis-specified: it compared an arriving update against our current position, but those are at different times, so most of the 0.40 m it reported was latency times speed rather than prediction error. It could not have shown a visual jump even if one existed. The follow trace agreed - per-step motion stayed tight at 1.36 to 1.68 m and tracked speed, with no outliers riding on top. It did settle one thing: corrections arrive 43 times a second, near the 50 Hz step rate, so whatever ticks a few times a second is not one per correction. So measure the symptom instead of a theory about its cause. A visible tick IS a step that moves much further, or much less, than the steps around it, and that is now counted directly: spikes above 2.5x a short running mean, stalls below 0.4x, judged against the mean rather than an absolute distance because a pod at 75 m/s moves 1.5 m per step and one against a wall moves nothing. Respawns are counted and excluded - they teleport hundreds of metres and are meant to be discontinuities. Stated in advance, so the result cannot be read to taste: spikes at a few per second confirms the tick is in entity motion and gives its rate; spikes and stalls near zero refutes it, and points at frame delivery or the newly-active map raster instead. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
5c7e218c98 |
A room cannot mix builds, and the log stops hiding things
Three guards, all of them paid for by an actual wasted afternoon.
THE BUILD GUARD. kNetRevision is hand-maintained and only bumped when
someone judges that a change alters the simulation, so two different builds
normally carry the same revision and will race each other happily - which
is how a 4.12.184 machine and a 4.12.187 machine sat in the same room all
day. The exact build now travels as lobby data and member data, and it is
checked in two places:
- on JOIN, before the room is ever entered, with a dialog naming both
builds. The owner's launch check would have caught it eventually, but
only after everyone had picked a loadout and pressed go, and all it can
do then is decline to start - which reads as the host's button being
broken.
- at LAUNCH, beside the revision check, so a member seated before the
guard existed still cannot race.
The room screen shows BUILD <version> against an offending row, because a
host is owed the reason as well as the refusal. An absent value counts as a
mismatch: a build older than the key cannot be trusted to match. Both
guards stay - the revision still refuses a mix known to simulate
differently even where the build strings agree.
THE DUPLICATE KEY WARNING. environ.ini is applied line by line, so a second
copy of a key silently beats the first. A TARGETFPS added at the top of the
file was overridden by the one the template ships further down, and the test
it was written for looked as though it had failed rather than never having
run. Now: "TARGETFPS is set twice - line 1 and line 8; the LATER one wins",
naming the key and both lines, because which and where is the whole value.
THE MISSING FACTS. TARGETFPS appeared nowhere in the log, so no run could
be checked afterwards against what it was actually asked for, and
interpolation only announced itself when switched off - there was no way to
confirm from a log that it was on. Both are now stated outright, with a
warning when a frame target differs from the physics rate AND interpolation
is off, which is the combination that steps.
Verified: the duplicate warning names lines 1 and 8 of a file carrying both,
the frame line reads "144 fps, drawing on exact physics steps" with the
mismatch note when interpolation is off, and "60 fps, drawing interpolated
across the physics step" with no note when it is on.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
CydandClaude Opus 5
|
46aef0691e |
The replicant says how hard each update moves it
A tick a few times a second survived render interpolation, and it would: interpolation smooths WITHIN a fixed step, and this is a discontinuity in the stepped values themselves. Between updates a replicant is dead-reckoned from updateOrigin over (lastPerformance - lastUpdate); when the next update lands the basis is replaced and the position jumps by however far the prediction had drifted. A few updates a second is a tick a few times a second. So Entity::ReadUpdateRecord now measures the correction before applying it: how many arrived in the last five seconds, and the mean and worst distance between where we had the entity and where the update says it was. Replicants only, behind RP412CAMLOG, on a clock so a busy race cannot bury the log. If that reads a few per second at tens of centimetres, the tick is named and the fix is to damp the correction in rather than apply it instantly - which is a real piece of work and worth sizing on evidence. If the corrections are tiny, the tick is something else and this rules it out. Also worth recording: RP412GAUGEDIAG is blind on a camera station. It only reports when a full display sweep completes, and the missing-MFD bail resets that counter every cycle, so the gauge theory could not be tested that way. The camera's own symptom description did the work instead. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
adcb81e7fc |
Replicants interpolate too
The first cut hung the snapshot off Mover::BeginStep, which is inside Entity::PerformAndWatch's fixed-step interleave - and that interleave sits entirely inside "if (GetInstance() != ReplicantInstance)". A replicant never runs it; it reaches the step loop through Simulation::PerformAndWatch instead. Every remote pod is a replicant, so on a Live Cam the camera was being interpolated while the car it was watching still stepped. Smoother, and most of the way to nowhere - which is exactly what "still some hitching" was. So the hooks move to Simulation::PerformTo, where both paths meet: SnapshotRenderOrigin before each Perform, SetRenderStepFraction after the loop, two virtuals that do nothing by default and are overridden by Entity because Entity owns the origin. Mover::BeginStep goes back to what it was, so there is now one mechanism instead of two. Taking the snapshot inside the step loop is also strictly better placed than BeginStep was: it lands immediately before the integration, and still after any BeginStep teleport, so a VTV's scheduled respawn stays a cut. Entity::PerformAndWatch keeps computing the fraction itself after its interleave, because there PerformTo is called once per step with a till one step ahead and so sees no leftover at all - it needs the FRAME's till, which only the interleave has. Determinism re-proved, and more thoroughly than the first time. The scripted lap at 240 fps, interpolation on and off, on both the old build and this one: all four runs agree to the last decimal at the same simulation time - pos -15.06739 3.01541 388.02603 at t=15.260. The one "differing" sample in the raw comparison was the trace sampling at t=1.260 in one run and t=1.280 in the other and then realigning, not divergence. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
9e8a94c436 |
RP412INTERP is in the documented file
Every knob the code reads belongs in environ.ini's template, and the interpolation switch was missing from it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
449ed5d297 |
Drawing interpolates across the fixed step
The simulation advances in whole 50 Hz steps and the renderer draws whenever it can, so the drawn position only changed fifty times a second and was held for however many frames fell inside a step. That is visible as stepping, and it got WORSE the faster the machine: at 240 fps each position is held for nearly five frames, which is why a fast PC looked like a rabbit on crack while TARGETFPS=50 looked perfect. Matching the two rates hid it, but locking the frame rate to the physics rate throws away the entire point of having a fixed step. So drawing now blends. Entity keeps renderPreviousOrigin - its origin at the start of the step it is in, snapshotted by Mover::BeginStep - and renderStepFraction, how far through that step the frame falls, which is the leftover Entity::PerformAndWatch deliberately does not simulate. GetRenderToWorld blends the two with Origin::Lerp, which already did position and shortest-arc quaternion with normalisation. It is RENDER ONLY. localOrigin and localToWorld are untouched, so physics, collision, scoring, the nav map's queries and the network update records all still see exact stepped values. Three call sites. RootRenderable::Execute, which was the single place a vehicle's transform reached the matrix stack - the renderable already ran per frame and simply re-read a value that changed at the physics rate. The eye needed its gate widened as well: it rebuilt the view only when localToWorld CHANGED, so the world would have glided while the camera went on stepping and the judder would have moved rather than gone. And a teleport must stay a cut - that falls out free, because VTV::BeginStep applies a scheduled respawn and THEN calls Mover::BeginStep, so the snapshot lands post-teleport and the blend has nothing to travel. The picture trails the simulation by up to one step, 20 ms at 50 Hz. That is the standard price of interpolating rather than extrapolating, and much the lesser evil: guessing forward overshoots and shimmers every time the guess is corrected. RP412INTERP=0 turns it off so the stepping can be seen again without a rebuild. Determinism proved rather than asserted: a scripted lap (RP412INPUTSCRIPT, throttle and steering and pitch) at 240 fps with interpolation on and off, 90 PHYSTRACE samples over 22 seconds of driving, zero differ. Two earlier attempts at that comparison were invalid and both were my method - the first did not pin RP412SPAWNZONE so the runs began on different pads, and the second had no input script, so a joystick sitting on the desk drove the two runs differently. The template warns about the first of those in as many words. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
55e751648f |
The camera says whether it is tracking a staircase
Janky tracking on a Live Cam, and the rotation is a spring-damper on the
fixed simulation step, so it should glide. Which leaves the input rather
than the smoothing: the camera follows a REMOTE pod, whose position only
changes on this host when an update lands. If the watched point sits still
for most steps and then leaps, the camera is tracking a staircase
faithfully and nothing in the rotation can hide it.
So FollowGoal now reports, every five seconds: how many simulation steps
it ran, how many of those saw the target move at all, the largest single
jump in metres, and how many times the trackside camera was cut to a
different one. At 50 Hz that is about 250 steps per report, so:
moved near 250 the target moves every step - look elsewhere for
the jank, most likely frame pacing
moved near 50 the target changes about ten times a second and the
camera is stepping between arrivals
biggest jump large confirms leaps rather than drift
several cuts the trackside camera is flip-flopping, which snaps
rather than glides and is its own kind of jank
The cut count is worth having because timeOnCamera is 0 for a race - the
director sets it to 0 outside football - so the closest-camera choice is
re-evaluated every step and only hysteresis stops it oscillating.
Not baselined locally: FollowGoal only runs on a camera station with a
peer, so unlike the nav and copy traces this one goes out unverified
against real numbers. The counters are simple enough to trust; the
interpretation above is what to hold it to.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
CydandClaude Opus 5
|
7a3b117f61 |
The sweep steps past a display it cannot draw
A Live Cam's map was blank and its score frozen at 1000 while the gauge canvas underneath was being drawn perfectly - 50 static entities and one mover, every sample, centre tracking the camera. The trace that settled it found zero "map copy running" lines against that: the canvas was alive and simply never reached the pane. SVGA16::Update services one display per call and steps mDisplayToUpdate at the END of the function. Both of its early bails returned before ever getting there. A camera's cameraInit page configures the secondary port and nothing else - no auxUL2, auxC, auxUR2, auxLL or auxLR - so the MFD branch could never be serviced, and the first time the counter landed on an MFD slot it stopped dead. Display 0's copy is the map, so it ran once, early, and never again. The pane kept that one frame for the whole race: a blank map, because nothing had registered with the renderer that early, and a score showing its opening value. "It had name and score at the start of the mission" was the tell, and it was accurate. Both bails now step the rotation on the way out, so the sweep moves past a display it cannot service instead of parking on it. A station with no MFDs therefore copies its secondary every third call, which is the same cadence a pod gets. Pod regression: the map copy still runs every pass at the same ~9900 lit pixels as before. A pod has all five MFD ports and never takes either bail, so that path is untouched. Three wrong diagnoses preceded this one - the gauge page, the renderer link, and a snapshot theory - and each died to a measurement rather than an argument. The trace that found it was worth more than any of them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
d08404bf50 |
The room calls you what you typed
The lobby published SteamFriends()->GetPersonaName() as each member's name, so the callsign box on the setup screen changed nothing anybody could see - the room and the race both showed Steam personas instead. And because the name never came from a file, wiping the install directory did not shake it loose either, which is what made it look like stale data being read from somewhere. It now publishes the callsign. The persona stays as the fallback for a player who has never set one, on the grounds that appearing as yourself beats appearing as "Pilot". This fixes the race as well as the room: a member's name in the egg comes from the same published field, so the owner was building eggs full of Steam personas too. The owner's own entry already used the typed callsign, so the two were inconsistent in the same race. RPL4FrontEnd_Callsign exposes what the front end already keeps and persists in pilot.cfg. Verified the accessor reads it: a pilot.cfg carrying callsign=TESTCALL logs FrontEnd: callsign "TESTCALL". The lobby publish itself needs a room with a member in it, so that part rides on the next two-machine run. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
0371544b88 |
The map copy says whether the canvas went dark
A Live Cam's secondary display carries its name and score at mission start and is black later on. Placement is not the cause - a POD with L4RADARPOS=LEFT fills the same corner properly, track lines, labels, mini-map and all - so the pane and its position are fine and something stops. Three faults wear that one symptom: the per-frame copy stopping, the source gauge canvas going blank underneath it, or the pane not repainting what it was given. The copy now reports, every five seconds, that it ran and how many non-zero pixels the source canvas holds (one row in sixteen sampled, enough to tell blank from not). So: no line at all the copy stopped line, lit falls to ~0 the gauge canvas went blank line, lit stays high the pane is not showing what it was handed Baseline from a pod, whose map demonstrably works: a steady 9900 or so lit pixels every pass, 640x480 source, mask 0xff. Verified before shipping this time, rather than after drawing a conclusion from it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
2adbeba6c4 |
The nav trace was measuring the wrong five seconds
It sampled the first five sweeps, which run while the mission is still coming up and nothing has registered with the renderer yet. So it reported "0 static, 0 moving" on a POD, whose map demonstrably works - and I took that reading at face value and concluded the map was broken for everyone. It was the instrument, not the game. Now sampled on a clock like the ranking trace, every five seconds, and the bounds line repeats too so the centre can be seen tracking. The real baseline from a pod race: CamLog: nav in bounds - 0 static, 0 moving (first sample, loading) CamLog: nav in bounds - 44 static, 1 moving (running, and stays) 44 static is the track, 1 moving is the player, and the centre walks with the vehicle. That is what a working nav display looks like, so a camera station can now be compared against something real rather than against a startup artefact. Found by putting the pod's map on screen next to its own trace, which is what should have happened before the first conclusion. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
04f72d4e3f |
A camera's map is placed by its own knob
The host picks Racer or Live Cam from the setup screen, so the two roles cannot share one placement setting - switching would mean editing environ.ini every time, which is not a thing to ask of anyone. L4MAPPOS places the camera's map and L4MAPSCALE sizes it, taking the same values as L4RADARPOS and L4RADARSCALE and defaulting to the bottom-left corner. A pod keeps its own pair and its dead-centre default, which is where the cabinet had it. Each role remembers its own; one file serves both. The scale is split for the same reason as the position: a host who wanted a bigger map while camming would otherwise have hit exactly the same problem the next time out. The log now names which variable it read - "map on the bottom left (L4MAPPOS)" - because a setting that silently loses to another one is how this went unnoticed in the first place. Both new keys are in the shipped environ.ini template, so they are discoverable without reading the source. Nothing to edit on an existing install: a file with L4RADARPOS set and no L4MAPPOS gives the pod its centre and the camera its corner. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
1cd8911df0 |
The nav display says what it can see
A Live Cam's map came up as furniture with nothing in it, and two confident explanations for that turned out to be wrong in a row - the cameraInit gauge page exists, and the gauge renderer IS linked to the camera ship, so both the page and its centre were fine all along. Two falsified guesses is the signal to measure instead, so RP412CAMLOG now traces the nav display: the scale and centre it resolves, the bounds it asks about, how many static and moving entities come back, and whether the sweep reaches the phase that actually draws. The ranking widget reports the players it can see with their rank and score, every five seconds so movement shows without flooding the log. It answered both questions on the first run, from a plain POD race: CamLog: nav scale 1000m across, 0.448 px/m, centre 12,416 CamLog: nav in bounds - 0 static, 0 moving CamLog: nav drew (phase 3 reached) A pod's nav map is as empty as a camera's. Sane scale, resolved centre, drawing phase reached, and nothing registered to draw - so this is not a Live Cam defect at all, it is a hole in whatever should be filling the gauge renderer's staticEntities and movingEntities, and it has been there for every station all along. A camera only made it obvious by having nothing else on the glass. The score, by contrast, tracks properly on a pod - 1000, 1005, 1148 across half a minute - so a camera host frozen at 1000 is genuinely camera shaped, and the ranking trace will say whether it sees the racer at all. Also here: a camera station's map defaults to the bottom-left corner rather than the pod's dead centre. Centre is where a cabinet wanted it and the worst place to put a panel on a picture. L4RADARPOS still overrides. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
af82cac5d2 |
A Live Cam keeps the map and drops the panes
A Live Cam host raced with the full glass cockpit over its view: five instrument MFD panes with no pod behind them, compositing as black rectangles across the viewscreen, and the map stood on end. Both are cabinet artefacts. The panes belong to a pod; the map is portrait because that is how the glass was bolted into the cabinet. A camera has no cabinet, so it keeps the map - landscape - and nothing else. The arcade got the same result by running its camera cabinet with -lc. The role is picked in the lobby, so there is no -lc on the command line to carry it to the renderers. Application::IsCameraStation joins suppressGauges, set by the front end where the egg settles owner_is_camera - before the renderers exist, since the single-binary race loop builds a fresh application per race after the menu. Set on every launch either way: a stale True would strip the cockpit off the next pod. In the compositor: the five MFD panes are not built, which LayoutCockpit and FillSplitMFD already tolerate, so no layout surgery; the map's glass swaps to 432x324 while still honouring L4RADARSCALE and L4RADARPOS; and the per-frame copy runs straight through rather than rotating 90 degrees clockwise. The pane's source dimensions swap to match, so the buffer the copy fills is the size the pane allocated - checked both ways. Untested on screen, unlike the rest of this work: it only engages with a lobby member present and that needs the second machine. What is checked is that it builds, that the buffer arithmetic agrees, and that every pane access on the glass-cockpit path is NULL-guarded. L4MFDSPLIT=2 and =0 are left alone. The exploded view still opens five empty MFD windows for a camera; it is a diagnostic view where that is arguably the point, and its layout derefs the panes unguarded. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
aa2ca0376a |
The camera HUD only reads the slots it filled
A Live Cam host launched into a real race took the process down with an access violation. WER put the fault at image offset 0x76239, which with this build's fixed base resolves against the shipped PDB to CameraShipHUDRenderable::Execute - the dereference in the ranking loop. Two defects, both older than Live Cam. playerRank is SPARSE: it is sized for the racing players plus the camera players and filled by playerBitmapIndex - 1, exactly as the constructor's own comment says. But it was allocated with new[], which does not zero, and Execute walked it densely to playerCount and dereferenced every slot. Any bitmap index that nobody claimed was therefore uninitialised heap read as an int*. Live Cam is simply the first thing that can leave a gap at the front. The host takes bitmap index 1 and, being the camera, is not in the "Players" group, so slot 0 was never claimed while playerCount was still 1 and the loop still ran. The arcade never hit it because its camera cabinets sat after the pods in the egg, so slot 0 belonged to a real racer and the dense walk was accidentally safe. So: clear the array on allocation, remember its real length as rankCount, and iterate that while skipping the unclaimed slots. The playerCount bound was wrong on its own terms too - a race whose bitmap indices run past it would have missed the tail. Everything before the crash worked on the first try, which is the other half of the news: with a live racing peer the camera director builds, the camera ship comes up and starts directing. The map-load hang that stopped a camera host before was an artefact of it having no peers. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
1a5a4a220c |
A Live Cam host brings no vehicle
Picking Live Cam and then hosting still showed the host in the room with a VTV and a colour, because the room row draws whatever loadout the member published and nothing on the wire said the host had given up its grid slot. The lobby now publishes a cam key with the rest of the member data, carries it in MemberInfo, and the owner's row reads LIVE CAM where a loadout would go. The loadout itself still goes out unchanged. Live Cam is a role, not a vehicle, so vh/cl/bd keep carrying what was picked and switching back to Racer finds it all still there. Only the owner's row shows it. The host is the one that writes the egg, so the host's pick is the only one acted on; a member who set Live Cam is still going to race, and its row goes on saying so. Painting every cam=1 row as LIVE CAM would have the room screen lying about the grid. Letting members spectate too is a real feature - the same hostType=1 on their egg entry, plus a guard that one racer is left - but it is not this change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
487eaa3a36 |
The host can watch instead of racing
YOUR ROLE joins the setup screen at the head of the loadout column - Racer or Live Cam - so the host still picks the track, the conditions and the length, and still owns the lobby and marshals every pod, but can hand its own grid slot back and watch. It rides the existing group machinery (kRoles through GroupSize/GroupTitle/ItemName), so there is no new UI code, and it persists in pilot.cfg beside the rest of the loadout. Offered only when Steam is configured, the same condition the HOST and JOIN buttons use: the role means nothing without a lobby to host. In the egg the host's own entry becomes hostType=1 and vehicle=camera. Those two are what RPRegistry::MakePlayer reads to build a camera director rather than a racer, and they are all it takes - the arcade selected its camera cabinet exactly this way, from egg data alone. The pick is honoured only when other pods are actually in the race. pilot.cfg remembers Live Cam, so someone who set it for a lobby race and later launched a single-player one would otherwise hand the map load a camera host with no peers, which is the one configuration known to hang it. With no extras the choice is logged and ignored and the host races, which is what pressing LAUNCH on a solo game meant anyway. Still open: a camera host with real racing peers has never been tried, so whether the map-load hang survives contact with a live race is the next thing to find out; and nothing yet tells lobby members that the host is spectating, so their room screen just shows one fewer car. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
a5c1e0291c |
The camera bring-up says how far it got
A Live Cam station is selected entirely by egg data - hostType=1 on that host's entry plus vehicle=camera - so no code path announces itself and a station that fails to come up leaves a log that simply stops. RP412CAMLOG=1 traces the sequence: the stand-alone host and its type, the local player node and game model, the interest-arena and interest-manager loads, the registry choosing a director, the director making its camera ship, and the launch handshake it waits on. Off by default. What it found immediately: a camera host wedges inside InterestManager::LoadMission - the map-entity load - and never returns. Everything upstream is correct (the egg parses, hostType 1 is adopted, gameModel reads 'camera'), and the same call with a racing egg passes straight through to making the player and launching. Same map both times, so it is the local host's TYPE that the map load cannot digest, not the map. That is a defect to fix before a lobby has anything to switch on. Also recorded while chasing it: a racing -egg run sits in application state 11 with the low-priority queue never empty for its whole life, and still simulates - so CheckLoad's no-console self-launch is not what starts a stand-alone race. Worth knowing before trusting that path. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
ef4a5e501d |
The wireframe stands against black
Alt+W held the sky dome solid so the edges had something to read against. Looking at it, the dome was the problem: lit, fogged and filling the upper half, it washed out everything behind the near geometry. A whole structure over the track in the middle distance was invisible until the sky came away. So the view now clears to BLACK under wireframe and the sky pass is skipped entirely. Skipping costs nothing - the dome only ever covers pixels the clear already owns - and it removes the two fill-mode brackets that used to wrap the pass, so the frame is simpler than it was. Both changes are conditional on gWireframe; the solid path clears to the fog colour and draws its sky exactly as before. Fog still applies to the edges, which is why the middle distance tints toward the fog colour instead of staying bright. That is depth information, so it stays. environ.ini's template and BUILD.md both said the sky stayed solid. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
0f4592c39a |
The wireframe key works and Steam is optional
Alt+W had been a no-op since the 2007 DPL->Direct3D port, which stubbed DPLToggleWireframe along with every other dpl_ call. D3D9 has no global wireframe property, so the toggle now records the intent in gWireframe and ExecuteImplementation applies D3DRS_FILLMODE once per frame - which also means it re-asserts itself after a device Reset. The sky dome and the 2D pass are held solid: a wireframed dome buries the geometry you turned the key on to look at, and the gunsight would otherwise come out as bare diagonals. Proving it needed a working copy, and that turned up a separate problem. steam_api.dll was a hard import, so a machine without it died at load time with 0xC0000135 - before a window, before a log line. It is now delay-loaded, and because delay loading only moves that failure to the first call, every Steam path is gated on SteamNetTransport_ClientLibraryPresent(): Install and the two lobby entries, with everything else downstream of one of them. Absent DLL boots and races; absent DLL with RP412STEAM=1 logs the reason and stays on TCP; DLL present brings the transport up exactly as before. The documentation now says which debug keys are real. Five of the seven are still 2007 stubs and always have been, so they are named as inert in environ.ini's template and at the dispatch site - that beats letting the next person debug a dead key, which is how this started. BUILD.md gains a debug-key table, the delay-load contract for anyone adding a Steam call site, and the environ.ini BOM trap that silently reverts L4CONTROLS to KEYBOARD and then fail-fasts for want of a pod mapper. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
34abf40e7f |
Fifty hertz is the physics
RP412PHYSICSHZ defaults to 50: the simulation advances in fixed 20 ms steps whatever the display does, and every machine plays the same race. The proof preceded the promotion - a scripted lap with a crash, a burn, a tumble and two respawns runs bit-identical at 30, 60 and 144 fps, and identical runs reproduce exactly, neither of which was ever true of this engine at any frame rate. Fifty because it is exact on the engine's millisecond clock (a rate like 60 quietly becomes 17 ms steps wearing the wrong name), and because its settled hover ride height measured closest to the frame-coupled physics the game has always run - the least change of feel for the most change of correctness. The pods' 25 and the smoother 100 stay one line away for the play testers, and 0 keeps the original frame-coupled behaviour for comparison, where the frame rate is part of the simulation. Carried-over environ files do not mention the option, so existing testers get 50 on their next build and rpl4.log names both the option they have not heard of and the mode every launch. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
67d57452ba |
The podium hold asks whether there is a podium
RP412PODIUM=0 promises "straight to the results" and delivered eleven seconds of black screen first: the winners' circle hold was applied unconditionally at the buzzer, and the timer never asked whether there was a stand to hold the mission open FOR. Found by the -egg harness, which could reach the end of a race unattended and noticed the promise not being kept. With the podium off, the hold now stands aside and the base 3-second race fade runs the show. With it on, RP412PODIUMHOLD tunes the length (1-60 seconds, default the same 11 as always) - eleven seconds of one parked pod is a long look in single player, and that is now a choice rather than a constant. The decision point logs which path it took and the value it applied, verified all three ways: podium off - the race fade stands (3s) and the results come straight up holding the mission open 5s for the stand holding the mission open 11s for the stand Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
c479cd48e9 |
The death cycle is deterministic
A scripted lap - full throttle, a steer, a crash at speed, the burn, the tumble, death, respawn, a second crash, a second respawn - now plays out bit-identical between identical runs and across 30 and 144 fps under RP412PHYSICSHZ. Ninety of ninety samples exact in the repro pair, sixty of sixty across frame rates, max difference 0.000000. The crash was already deterministic; this makes the RECOVERY deterministic, and it took five pieces, every one found by measurement: - The respawn teleport moves onto the vehicle's own step grid. VTV::ScheduleRespawn stores it and BeginStep applies it at the first step whose clock reaches the due time, teleport and turn-toward-goal together, because the goal flip reads the POST-reset heading. The old path applied the Reset from the event queue, which runs on wall clock, and identical runs diverged on the first step after the pod stood back up. - The handler keeps its Reset for the FIRST spawn of a mission, gated by a flag rather than by mode. A Mover is born in StasisState and the first Reset is what wakes it; gating on "is fixed stepping on" - the first attempt - skipped that wake-up and parked the pod frozen at its spawn point for an entire race. The scripted-lap harness caught it in one run. - The vehicle stamps its own death clock, at the single site that sets BurningState - inside the step machinery, which is why the crash measured exact. The schedule anchors to the death, the last step-exact event in the chain. - The due time is quantized to a half-second grid ANCHORED AT THE DEATH. The instrument showed the naive anchor was four seconds stale by scheduling time: the fry chain reposts itself at wall-clock Now()+2.0 and the drop-zone reply lands about five sim-seconds after death, jittered by a few steps of queue timing. Firing "next step" inherited that jitter whole. Rounding up to the next half-second after the death puts hundredths of jitter against tenths of headroom, so every run lands in the same cell - and the felt delay stays the six-ish seconds it has always been. - The out-of-world tumble draws from a per-vehicle random stream seeded by creation order. The global Random is shared with the frame loop's consumers - particles, mostly - so its position at the moment a burning pod drew from it depended on how many frames had rendered, and the kick went straight into angular velocity. Last wall-clocked input in the whole death cycle. The respawn scheduling and firing log under RP412PHYSTRACE in run-comparable terms - pad identity, due offset, lateness - because those lines are what cracked this: "due in -4.06 sim-s" said more in one glance than three rounds of hypothesis. Still outside the claim: multi-vehicle contact (DynamicBounce writes the victim's state from the striker's step) and network play. That is the lockstep frontier, and it now has a harness waiting for it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
af52476603 |
The pod can drive a scripted lap
RP412INPUTSCRIPT names a timeline file - one row per change, throttle, stick X and Y, pedals, held until the next row's time - and the pod drives it instead of listening to the controls. Times are SIMULATION seconds from the green light, evaluated per step in the one place every mapper funnels through (VTVControlsMapper::InterpretControls), so the same script is the same lap at any frame rate. Rows hold rather than interpolate on purpose: interpolation would sample differently at different physics rates, and nothing on this path is allowed to. The script shares the green-light anchor with RP412PHYSTRACE - its clock starts at the instant the vehicle is stopped dead - because a timeline that starts when the loader happens to finish is a different lap every run. A race is only deterministic if somebody DRIVES it, and a human cannot drive the same lap twice. The first scripted lap - full throttle, a steer, a crash at speed - earned the harness immediately: - The drive, the crash, the death and the respawn teleport were all BIT-EXACT between identical runs, through t=13.5. Collisions with world geometry and the damage path are step-deterministic, which is better news than the code reading suggested. - The first divergence is the step AFTER the respawn: the DropZoneReply that stands a dead pod back up is posted at wall-clock Now()+1.0 (RPPLAYER.cpp), so the reset lands on a different sim step every run and everything after is time-shifted. The crash is deterministic; the RECOVERY is not. That is the next fix, and it is now a measurement, not a theory. Values are clamped at load, once and visibly, so a script asking for throttle 2.0 cannot trip the mapper's own range Verifies. Off unless the environment names a file; it would be a cheat in a real race. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
c2e2df1dce |
Every knob the code reads is in the documented file
A sweep of every getenv() in the tree against the environ.ini template found five options the code answers to that the file never mentioned: the physics trace, the spawn-zone pin, the gauge profiler, the renderer diagnostic and the joystick-scan log. They were deliberately env-only once - scaffolding, not settings - but scaffolding that cannot be found is scaffolding that gets rebuilt, and RP412RENDERDIAG had already been forgotten thoroughly enough that this sweep is what rediscovered it. They get their own section, between the shipped configuration and the optional extras, with the header saying what they are for: making a claim about the game testable instead of arguable. All five ship commented out, cost nothing when off, and none belongs in a real race. The sweep now closes empty - there is no environment variable the game reads that the file does not document - and the mention-check keeps it honest from here: a build that grows a new option names it in rpl4.log for every carried-over file. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
9643e02198 |
The physics rate is the play testers' question now
RP412PHYSICSHZ documented in environ.ini, under TARGETFPS where it belongs, with the three rates worth testing: 25, the arcade pods' rate and the step the original handling was tuned against; 50, the middle road; 100, the smoothest contact response. All three divide the engine's millisecond clock exactly and all three are verified bit-identical across frame rates. The entry says what to feel for - hover bounce, wall hits, how the pod takes a hill crest - and asks for the rate alongside the verdict, because whichever one the testers pick becomes the canonical physics for PC and pods alike. It ships commented out: the default stays the frame-coupled game everyone knows until that decision is made on purpose. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
2a679ab571 |
A race can be replayed exactly, so physics claims can be tested
Three pieces of harness, all env-gated and inert in normal play, that turn "do two frame rates play the same race?" from an argument into a number: - RP412PHYSTRACE=1 samples the player vehicle's position on the SIMULATION's own clock - the vehicle's lastPerformance, which advances in whole fixed steps - so two runs sample at identical step counts and their traces compare exactly. Frame-time sampling compares different instants and calls the difference physics; an earlier version of this trace did exactly that, and its noise was chased as if it were drift. At the green light it stops the vehicle dead, because the pod simulates on its pad while the mission loads and a load is never the same length twice: two runs reached the start 776 and 599 steps in, same position, different velocity. - RP412SPAWNZONE pins which drop zone is tried first. The pick is Random(), and Random() is seeded - but a seed only repeats a run if the same NUMBER of draws precedes the pick, and that count rides on load timing. Same seed, different pad, incomparable traces. Pinned, the zone is tried first and falls back to the random walk if taken, so it cannot wedge and changes nothing unless set. - The trace prints the global step counter, which is what caught the force-accumulator bug: the position columns can look plausible while the step column says the physics ran a different number of times. With these three and RANDOM= (which already existed), a race is repeatable to the bit, and the determinism matrix - rates by frame rates by repeats, run as parallel sandboxed instances - is a regression suite: any mismatch in any cell is a real bug. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
5e47987508 |
The simulation steps at a fixed rate
RP412PHYSICSHZ names a rate and the simulation advances in whole steps of exactly that size on every machine, whatever the display does. 0 - the default, and the shipped behaviour until the play testers have spoken - is the game as it has always run: the step is however long the last frame took, which makes the frame rate part of the physics. Measured over two seconds of free fall, a 30 fps machine's pod fell three times further than a 144 fps machine's. Two players on the same track were not in the same gravity. With a rate set, the same race is bit-identical across frame rates: 30, 60 and 144 fps produce the same trajectory to the last printed digit, and identical runs reproduce exactly - which was never true of this engine before, at any frame rate. It took three pieces, and every one was found by measuring, not by reading: - Simulation::PerformTo turns lastPerformance into the accumulator it always secretly was: whole steps while time remains, the remainder carried to the next frame. Watchers and update records stay once per frame - stepping is physics, watching is I/O. - Entity::PerformAndWatch interleaves subsystems and entity per STEP. The frame loop ran all subsystems to the frame boundary and then the entity, indistinguishable from correct at one step per frame - which is why thirty years of code never noticed - and wrong at two: the thrusters raycast twice from a vehicle that had not moved, and the hover spring fired twice on one stale height sample. The subsystems are also snapped onto their entity's step grid; each Simulation anchors its grid at its own creation time, a per-run phase no seed could pin. - Mover::BeginStep clears the force accumulator per step. It was cleared once per frame while the thrusters ADD per step, so step two of a frame integrated step one's thrust again - and how many steps a frame holds rides on wall-clock jitter, which is why identical configs measured a quarter-metre apart. The quaternion renormalise counts steps now too, for the same reason. The catch-up clamp is a quarter second of simulation whatever the rate, so a machine that cannot keep up slows down rather than seizing, and does so identically everywhere. The engine's clock counts milliseconds, so rates that do not divide 1000 - 60 among them - quietly run at the neighbouring millisecond step; the log now says so and names the exact ones. 25, 50 and 100 are exact, and all three are verified bit-identical across frame rates and across runs. Verified for a single vehicle settling under gravity and hover. Driving, collisions and the network are the next frontiers, in that order: the collision path writes the victim's state with wall-clock stamps and a hard-coded 0.1 s bounce, which single-player survives and lockstep will not. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
74aa5ae98d |
A hand-fed egg can run a whole race
'-egg' skips the menu and drops straight into a mission, which is the developer shortcut - and it installs no console, so nothing ever ends the race. Everything after the chequered flag was therefore unreachable from the command line: the buzzer, the fade, the winners' circle, the teardown. All of it could only be exercised by hand through the menu. RP412MISSIONSECONDS now marshals a hand-fed run as well, so a whole race plays out unattended. That is the difference between a shortcut that can be watched and one that can be TESTED, and it immediately earned itself: it caught RP412PODIUM=0 holding the mission open for its full eleven seconds with the podium switched off. The environ file promises "straight to the results"; the hold is applied without asking whether the podium is on, so what you actually get is the same wait against a black screen. That one is not fixed here - it wants a decision about the hold's length as well - but it is now reproducible in one command. pack-dist keeps frontend.egg for the same reason. It is written on launch and holds the menu's last selection, so it is what lets '-egg frontend.egg' drop back into the track under test - and a repack was wiping it, which turns the next run into a zero-byte file and an abort on "no map in egg". Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
1dd40be0a3 |
The map draws on every step of the rate wheel
The renderer walks a sixteen-step rate wheel: one step per full pass over the gauge list, shifted right each pass and reset at the bottom. A gauge redraws only on the step its configured rate names, so the map - on one step - waited a whole turn of the wheel however cheap its redraw was. With the frame budget fixed the wheel turns about fifty times a second and one-in-sixteen would be tolerable. It is still the wrong shape for the map: the thing a pilot reads to navigate should not be the display that updates least often, and RP412MAPRATE says how many of the sixteen steps it draws on. Sixteen by default, one for the old data-driven behaviour. Each extra step costs one gauge's redraw against a pass that runs ninety of them, which measured as nothing. The write has to be QUALIFIED, and that is worth recording because it cost hours. GPS's constructor takes its rate as a parameter also called 'rate', which shadows the inherited Gauge::rate for the whole body - so a bare assignment sets the parameter and leaves the member holding whatever the gauge data asked for. oldRate is not shadowed, so it took the value, and the pair then disagreed: rate=2000, old=ffff. That looked exactly like something writing the member from outside, and there is no such writer - Gauge touches rate in three places, none of which can produce that pair. A hardware write-watch on the member settled it by reporting an address on the STACK. Also here, the terrain-arrival work on the map background. It draws one placement into the cached picture when the static bounds are unchanged, and rebuilds the whole thing only when they move - the bounds set the scale, and the scale is what everything already on the picture was drawn at. It is honest to say this fires rarely: the logs show terrain arriving in one burst at mission load, not streaming in as you drive, so the incremental path is mostly insurance. What it does close is real, though - departures now order a rebuild. Nothing listened for those before, and they had been swept up by the rebuild the next ARRIVAL ordered, which on a track whose terrain all arrives at load is a rebuild that never comes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
b7b2c3b148 |
The GPU transforms the vertices
The cockpit displays were updating every two to three seconds while the 3D view held a perfectly smooth 55 fps. This is why, and it is one line. Every device was created D3DCREATE_SOFTWARE_VERTEXPROCESSING - every vertex on the track transformed and lit on the CPU, on the one core this game uses for everything. That was not a choice when the engine was written; there was no hardware to hand it to. The error message beneath the call still says "Couldn't create HARDWARE_VERTEXPROCESSING device", so the flag was changed at some point and the message left behind. Measured on the biggest track, 1920x1080: software foreground 17.2 ms background 1.2 ms 2.4 gauge passes/s hardware foreground 0.2 ms background 17.9 ms 50.0 gauge passes/s The frame loop runs the foreground and then spends whatever is LEFT on the background gauge work. A foreground costing 17.2 ms of an 18 ms frame leaves nothing, so the gauge loop got the single pass it is guaranteed and no more. A pass needs about twenty steps - eighteen gauges and three display copies - so the cockpit ran at two passes a second, and since the renderer walks a sixteen-step rate wheel, a gauge on one step redrew once per SIXTEEN of those. Three seconds. The map, the clock, the boost gauge and the sim still running after the fade to black were all that one number. Hardware T&L is now the default and sw is the way back. Fixed-function lighting and fog are not bit-identical between the old software path and a driver, so the escape hatch stays - but the picture was checked against both and the difference is not the one worth defending. A cockpit whose instruments update twice a second is. It falls back to software by itself if the adapter has no hardware T&L. The instruments that found it stay in, because nothing about this was visible from outside: - FrameSplit, under RP412GAUGEDIAG, reports foreground against background against whole frame. APPMGR has computed those four timestamps every frame since forever and never reported one of them; it would have pointed here on the first day. - FrameDiag reports frames per second on the same window, so the gauge sweep rate can be read against the frame rate rather than guessed at. - ProfileReport, which already existed and was only reachable through F11 on the RIO controls mapper - not the mapper a desktop player runs, so in practice unreachable - now runs on a timer under RP412GAUGEPROFILE. Its per-gauge line gains the rate mask and tier, which is what names a display as one-in-sixteen rather than merely slow. - The winners' circle logs what its exterior and name-plate rebuilds cost, since nothing else runs while they do. RP412VSYNC is here too, and it is honest about itself: presenting IMMEDIATE was measured and made no difference to the frame budget, because the frame was full of work rather than waiting. It stays as a latency-against-tearing preference, not a fix. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
827c5b295b |
The controls answer only while the game is the window in front
Testers taking notes in another window were flying the pod while they typed. RP412INPUTFOCUS=1 is the new default; 0 restores the old behaviour. The pod was the only thing running on its cabinet, so the virtual RIO reads the key state directly rather than waiting on the message pump. That is the right call for latency and it is why the pedals feel like pedals - but a direct read is a read of the WHOLE keyboard, whatever has focus. On a cabinet that distinction did not exist. On a desktop it is the difference between writing a bug report and steering into a wall while you write it. One choke point does the whole job: PadRIO::PollInputs is where the keyboard, the XInput pad and the DirectInput stick are all read, so a single flag covers the three of them. The joystick needs no change of its own - unfocused the resolve block is skipped, every device slot stays at -1, and the button, hat and axis loops find no device and read released on their own. It is opened DISCL_BACKGROUND on purpose, or it would stop answering the moment a cockpit pane took focus, so declining to poll it is what makes it go quiet. Each source reads as RELEASED rather than the poll returning early, and that is the part worth keeping: bail out instead and whatever was held at the moment you switched away stays held until you come back, which is the stuck throttle this is meant to prevent rather than cause. Reading released lets the diffs already in there turn it into proper release events. The throttle accumulator is the deliberate exception. It is the pod's one sticky axis and it integrates what the controls ask for, so controls asking for nothing simply stop moving it - you come back to the speed you left rather than to a dead stop. Focus is tested per PROCESS, not against one window handle. The cockpit is a shell full of child panes, the exploded view is six windows of its own and the plasma glass another; matching a single HWND would drop the controls the moment somebody clicked an MFD. Real RIO cockpit hardware is untouched - this is the keyboard, pad and joystick path only. The volume and bass keys in L4CTRL were already gated this way, unconditionally, which is where the idiom comes from. On by default because the alternative is every tester editing a file before the fix reaches them: an environ.ini written by an older build does not carry the line, so the built-in default is what they get. The log says which way it is set, and the option-mention check names it as one they have not heard of. Verified against the built exe both ways: a fresh run writes the documented default and applies 14 settings where it applied 13, and a file with the line removed reports exactly one unknown option and falls back to focus-gated. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
4410febd4c |
The particle engine hands the device back at the end of the race
A fresh renderer is built per mission, and the particle engine's vertex buffer is D3DPOOL_DEFAULT with a texture to match - both bound to the device that made them. Initialize overwrote the two pointers with the new device's resources without releasing the old ones, so the old device kept a reference from resources nothing could reach any more. ~DPLRenderer's SAFE_RELEASE(mDevice) therefore never took it to zero. Every race left a whole live device behind it - back buffer, depth buffer and all, at whatever the render target is, which on the tester's machine is 2560x1440. The next race's Initialize was the only thing that ever let one go, so quitting from the front end let it go never. Measured rather than assumed, with a standalone test using the same pool and usage: release the device with the buffer outstanding and it reports 1 reference left, still alive. Release the buffer first and it reports 0. Three parts to it: - Destroy is null-safe now, and clears what it drops. It was neither, and it runs on the device-lost path AHEAD OF A RESET - so a texture that never loaded, which a missing VIDEO\particles.png is enough to cause, took the Reset down with it. A released pointer left in place is a dangling one the moment anything looks again. - Initialize calls it first. The device-lost path already released before re-initialising; this is the same contract for the case where the device is not lost but REPLACED, which is what a new race is. - ~DPLRenderer calls it before releasing the device, next to the texture cache flush that is there for exactly this reason and had missed this one. The device now dies with the mission that made it. Destroy clearing mDevice is what makes the gap between it and the next Initialize safe: the paint paths already test that pointer before they touch anything. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |