Generated ultrawide loadscreen can be truncated and abort map loading

[y2keeth]

https://drive.google.com/file/d/1lKxQ4OOiMttAmC_lr27yEpnK-WbDwBst/view?usp=sharing

[y2keeth]

happened when loading a map from console if that helps
nope does it always even load game

[themuffinator]

interesting... i'll look into this, thanks

[themuffinator]

The screenshot identifies the exact failure:

LoadTGA( guis/assets/generated/loadscreens/core2_910x512.tga ): incomplete file

That is a runtime-generated ultrawide cache file under fs_savepath, not a damaged retail core2 asset. For 910×512 RGBA, the valid uncompressed TGA size is exactly 1,863,698 bytes.

Immediate workaround: with openQ4 closed, delete only:

<fs_savepath>/baseoq4/guis/assets/generated/loadscreens/core2_910x512.tga

and retry. The engine will regenerate it; no campaign save or retail file is affected.

Root cause: the generator wrote directly to the final name with truncation and ignored WriteFile's byte count. A failed/interrupted write—or two instances generating the same path—could therefore leave a short final file, which LoadTGA correctly rejected fatally on the next lookup.

The permanent fix now writes to a unique staging qpath, requires the exact byte count, atomically promotes it over the final file, cleans failed staging data, and falls back to the stock levelshot instead of aborting map load. A windowed 910×512 SP map run with an isolated savepath has passed: the generated TGA was exactly 1,863,698 bytes, no staging file remained, gameplay loaded, and the engine screenshot/log were clean. I will link the pushed commits/PR here.

[themuffinator]

The permanent fix described above is now in draft PR #104 via a8fc1b1c and 1e3dfed2.

Integrated verification used a forced-windowed SP map launch with an isolated savepath. It generated the 910×512 RGBA cache at exactly 1,863,698 bytes, left no staging file, reached gameplay, and wrote an engine screenshot with no fatal/write/load warning. The write-qpath and concurrency contracts also pass.

The PR uses Fixes #102; I am leaving the issue open while the PR is draft instead of closing it against unmerged code.

PR: #104

[themuffinator]

Independent review also hardened the concurrency guarantee in follow-up commit 3107f8f0 on draft PR #104.

The first staging name combined a high-resolution clock with a process-local sequence. That was unique in normal single-process use but did not strictly separate two live processes. Staging paths now include the operating-system process ID as well as the clock token and per-process sequence, with Windows, POSIX, and stub implementations covered by the filesystem contract. Atomic promotion and failure cleanup are unchanged.

[themuffinator]

Concurrent runtime follow-up on commit 3107f8f0 also passed. Two forced-windowed SP clients (PIDs 20088 and 35820) shared one isolated fs_savepath and entered game/storage1 together at 910x512. Their logs show separate staging qpaths containing the respective PIDs; both processes exited 0, the promoted storage1_910x512.tga is the exact expected 1,863,698 bytes, no *.partial remains, and neither log contains an incomplete-file, publication, or fatal error. No input injection or OS capture was used.

[themuffinator]

Follow-up after independent review and the refreshed smoke gate: the earlier PID-based staging draft has been superseded by 03c20342.

The final design uses the engine's existing OS CSPRNG API to generate a 128-bit staging nonce, plus a process-local sequence, before writing. That avoids a new engine/GameLib interface declaration and restores the required header-parity contract. If secure staging is unavailable, the engine now keeps the original source levelshot instead of publishing through any predictable fallback name.

I repeated the shared-savepath runtime test with the staged release build: two forced-windowed clients loaded game/storage1 concurrently and wrote distinct nonce paths (e6c6...6ec0 and 6114...66a3). Both exited 0. The final 910×512 32-bit TGA is exactly 1,863,698 bytes (SHA-256 4A1EA1DAB33DA521A237D6003EC9C7E238E3F26D306274A0DDA0A5C35B6B6DB6), with zero .partial files and no secure-staging, publication, incomplete-file, or fatal diagnostic. The focused write-qpath, engine/GameLib header parity, ARM64 portability, and full Windows build checks also pass.

PR #104 has been updated to describe this final implementation.

[y2keeth]

so I wait for the next release?