FelipePrado0/SpartanPort windows-v2.6.0-issue345-test1

Test build issue345-test1 on 2.6.0: WAD loading diagnostics

on GitHub

Diagnostic test build for the endless WAD loading in #345, with similar reports in #428, #636 and #701.

This is a diagnostic build, not a confirmed fix for the campaign hang. Source: 397c307a86c7f270dca0fbd44b9aaa5d103d0f8c on fix/issue-345-wad-loading, based on main commit 4b843a7dd10bc6f159da378e308b89c1627392f4.

Download spartanport-windows.zip, the complete Windows executable package. No source patch or separate activation helper is required. No Linux package is included in this Windows test release.

What changed

• Added optional WAD file tracing with SPARTAN_FILE_TRACE=1. It is off by default.
• WAD opens, sequential reads, positioned reads and closes have paired phase=begin / phase=end entries with a shared ID. They record guest paths, descriptors, offsets, requested and returned bytes, errors, file sizes on open, and timing. Entries are flushed so the last unfinished operation can survive a hang.
• Only WAD files are traced, case-insensitively. Host filesystem paths and file contents are not included in the new trace records. Non-WAD files are filtered out.
• Retained the protected-page read recovery and synthetic regression from the preceding candidate. The player retest below does not support that recovery as the explanation for the post-Hades hang.

Thanks to @Azaberth for the original patch, the checkpoint retest, log and autosave. On 2.4.0, his patched build still hung after HADESDEATH; the attached log reports reads recovered=0. The purpose of this build is to find where WAD file operations stop, without assuming the cause is file reading, GPU synchronization or scheduling.

How to test

1. Close other instances of the launcher and game. Back up your saves and keep your working installation available. Extract spartanport-windows.zip into a separate folder, select the same game files, and use a copy of the save that reproduces the hang. Keep your previous settings, mods and translation for the first comparison and report them.

2. In the folder containing the extracted SpartanPort.exe, open PowerShell and run the commands below. They enable tracing for that PowerShell session. No administrator privileges are needed. Launch the game using Play.

   $env:SPARTAN_FILE_TRACE = "1"
   .\SpartanPort.exe

3. Confirm user/last_run.log contains Runtime: WAD file tracing enabled (SPARTAN_FILE_TRACE=1) and File trace: entries. If they are missing, report that before drawing conclusions from missing WAD operations.

4. For #345, load the original autosave, defeat Hades, and let HADESDEATH finish without skipping. Other useful points: enter the Forge after the statue fight (#428), the Cav600 transition (#636), or the hidden passage after Helios (#701).

5. Record whether loading completes and roughly how long you waited. If it remains stuck, copy the available user/last_run.log before closing or restarting. If it completes, close normally and copy the log before the next launch.

6. Reply in #345 with this build tag, CPU, GPU/driver, Windows version, game region/update version, affected checkpoint, mods/translations, and the complete log. If possible, compare the same checkpoint with your previous build. Do not upload game files.

Interpretation guide: no open for the target WAD means the request has not reached the traced file-open path; a begin without a matching end identifies an in-flight operation; completed reads, their offsets and the file size help identify how far the file was processed. These observations narrow the investigation, but do not by themselves identify a GPU fence, decompression or Fios bug.

Tracing deliberately adds logging and flushing overhead. Use it only for reproducing the loading problem, not for FPS comparisons. Close that PowerShell session and launch the EXE normally to leave tracing disabled.

Validation so far

• Added the tracing contract test before implementation. It failed because the previous runtime produced no WAD trace records.
• Windows: compiled with GCC 16.2.0 and ran trace-on, trace-off, and protected-page regression cases with warnings treated as errors.
• Linux: compiled with GCC 15.2.0 under WSL/musl and ran the same cases plus the existing file-mods test. A temporary header shim handles existing runtime names that collide with newer musl declarations; it is not shipped.
• Checked matched operation IDs, successful and failed opens/reads, sequential and positioned offsets, file sizes, negative offsets, WAD/non-WAD filtering, and no diagnostic output when disabled. The earlier protected-page regression still passes.
• Checked shell syntax and Git whitespace errors.
• Full Windows package build with MSYS2 CLANG64 and clean-runner startup checks passed in GitHub Actions run 39426658134. The workflow did not publish a release.
• Downloaded the produced ZIP and verified its SHA-256 and ZIP integrity. Confirmed the compiled probe contains the new trace markers. With a clean PATH, the packaged probe completed --cpu-features, and the packaged launcher ran the import check and preserved the diagnostic environment in script mode. These checks do not exercise gameplay or WAD loading.
• Not validated: gameplay, the affected checkpoints, the loading-hang cause, tracing overhead in the game, or a Linux distributable.

SHA-256 of spartanport-windows.zip: 91027afa366c38a877f192e3282a44b2b31d64e9a65787ede5ac56b41e9290a5. The checksum is provided here for download verification.

You need your own game files. None are included.