Each pod sandbox keeps its own copy of rpl4opt.exe, planted by setup.ps1.
Run a batch without refreshing it and you are testing whatever was built the
last time setup ran - so a bug you fixed an hour ago reproduces perfectly, on
the binary that still has it, and reads as the fix having failed.
That is not hypothetical. The playerVehicle fix went in at 11:20; a 20-launch
batch started at 11:23 trapped at 00486ebe, the same address as before,
because all four pods were still running the 09:33 exe. Ten minutes of
looking at a crash that had already been fixed.
So the loop now copies Release\rpl4opt.exe into every pod before it starts,
and logs the hash and build time it planted. A batch whose first line does
not name the build you expect is a batch you can throw away without reading
the rest.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
CydandClaude Opus 5
5c597edf68