2 Commits

Include renames

Author	SHA1	Message	Date
CydandClaude Opus 5	82e733c1a6	Replicants reckon from when an update was sent ... Simulation::ReadUpdateRecord threw away the sender's timestamp and stamped lastUpdate with its own arrival time. The line carried the original authors' own note: "HACK - should be based upon message->timeStamp". The dead reckoner extrapolates a replicant over (lastPerformance - lastUpdate), so starting that clock at ARRIVAL rather than at SEND leaves every remote vehicle exactly one network latency behind where it should be. On the 1 ms LAN inside an arcade that is nothing. Over Steam Datagram Relay it is 50-150 ms of positional lag on every other player - a constant bias, not jitter, and the information needed to remove it was already in the packet. The timestamp cannot be used as it stands: both machines run QueryPerformanceCounter since their own boot, so the two clocks share no epoch. The offset is estimated per peer instead. Each record gives sample = ourNow - theirStamp = trueOffset + oneWayLatency and latency is never negative, so the smallest sample seen is the closest to the truth. A rolling minimum over 128 samples follows crystal drift and re-adapts when a route gets slower, rather than being pinned forever by one lucky packet; a shorter path is believed immediately. Applied with two clamps: never ahead of our own clock, and never further back than 500 ms. Past that the packet is stale or the estimate is wrong, and throwing a vehicle half a second forward does more damage than the lag being corrected. Entity::UpdateMessageHandler is the only point on the receive path that knows whose update this is - records carry a timestamp but not an owner - so it publishes the sender around the loop, and only for entities somebody else owns. Offsets are forgotten in CreateMission: the hosts in the next race are not the hosts in the last one and a HostID gets reused. RP412NETCLOCK=0 restores the arrival-time behaviour, documented in environ.ini, so a test machine can compare the two without a rebuild. The estimate is logged per host when it first settles and whenever it moves more than 50 ms, which is what a three-machine session should be read against. WHAT IS AND IS NOT VERIFIED. A full single-player race runs unchanged - the path is never entered without replicants, which is the regression risk that reaches everybody. The behaviour this exists for needs real latency between real machines and is therefore untested: a two-instance loopback race would only have exercised the zero-latency case, where the correction is a no-op by construction. Expect remote vehicles to sit further forward than before, and watch for overshoot when somebody changes direction sharply - that is the tradeoff this makes, and the clamp above is what bounds it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-05 15:50:28 -05:00
CydandClaude Opus 5	4f34684b16	environ.ini is written on first run, not shipped ... Packing one into every zip meant a tester who unzipped a new build over their folder got their configuration replaced. bindings.txt has never had that problem, because the exe carries the template and writes the file only when it is absent. environ.ini now works the same way, so a new build can land on an existing folder and every setting survives. The 245-line template moves out of pack-dist.ps1 and into RPL4ENVIRON.cpp as the exe's own literal, which also means the exe alone can produce a working install. It was lifted mechanically rather than retyped, and the file it writes is line-for-line identical to the one we have been shipping - only the line endings changed, from a mongrel 243 LF plus one stray CRLF that PowerShell's Set-Content left on the end, to the uniform LF the game already writes bindings.txt with. It cannot simply become optional. Without environ.ini, L4GAUGE is unset - which disables the gauge renderer and takes every MFD with it - and L4MFDSPLIT is unset, which is the packed-window arcade layout rather than the glass cockpit. The shipped values ARE the desktop game; the built-in getenv fallbacks are the 1995 pod. So the game writes the file rather than tolerating its absence. The cost of a file that is never overwritten is that a tester carrying one across many builds stops being offered new options. Nothing breaks - an option added later defaults to "behave as before" - but it goes unnoticed, and "the podium does not work" is a confusing bug report when the real answer is that their environ.ini predates RP412PODIUM. So the load names every template key the player's file has never mentioned, and says they are at built-in defaults and that deleting the file brings the documented one back. A stale seven-line file lists all 40. The file is read, never rewritten. The mention test is deliberately generous - a key counts as known if it appears in any form, commented or not - because the failure it guards against is worse than a missed notice: environ.ini is applied line by line, so a second copy of a key appearing later in the file would silently override the player's own. The version line also moves to the top of WinMain. It used to print after the environment was loaded, so the first thing in rpl4.log was a message about environ.ini rather than which build wrote it. Verified: the written file matches the old shipped one line for line; an edited file with a hand-added comment survives another run untouched; a seven-line file from an older build boots and names all 40 options it has never heard of; and a full mission on a self-written file brings up the glass cockpit at 125% with the virtual RIO active and nothing alarming in the log. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-05 14:46:18 -05:00