(1) ConstrainedLanguage mode (locked-down Windows, WDAC/AppLocker) blocks .NET method calls, so [Environment]::GetFolderPath('Desktop') returned nothing -> null DestinationPath -> no zip, and [math]::Round blew up on the size. Desktop is now resolved from OneDrive/USERPROFILE env vars (still honouring a redirected Desktop) and the size via -f formatting. Deeper trap found while testing: Compress-Archive ITSELF cannot run in that mode -- it is a script module that calls .NET internally -- so fixing the path alone would only have moved the failure downstream. The zip is now built with Windows' native tar.exe (immune to language mode, present since Win10 1803, verified to emit a real Explorer-readable zip), with Compress-Archive kept only as a fallback.
(2) A log still held open by a running BattleTech made Compress-Archive abort the ENTIRE zip -- one locked file, no logs at all. Files are now staged with Copy-Item first: an unreadable one is skipped and NAMED, the zip still gets made from the rest, and the tester is told to close the game and re-run to capture the missing one.
(3) The script announced 'Wrote <path>' and 'Attach the BTLOGS zip' unconditionally -- tester 2's screenshot shows it claiming '11 files, 0 MB' for a zip that was never created. Success is now gated on Test-Path, failure exits 1, and the batch prints 'Nothing was created' instead of sending people to hunt for a file that does not exist.
Also adds ABOUT.txt inside the zip (machine, pack time, install folder, exe build date/version) so a report can be tied to a BUILD -- the ambiguity that has cost us repeatedly when a Pass/Fail arrives with no build number.
Verified on four scenarios: normal run, a log locked by another process, a session downgraded to ConstrainedLanguage (reproducing tester 1's exact MethodInvocationNotSupportedInConstrainedLanguage error first), and running from a folder with no content dir. Handout updated: close the game first, and what SKIPPED means.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>