Testing Checklist -- V5.1.0b_RC3 (eaa5fd3 through 2026-08-09) Branch: 5.1.0b-in-progress Last known-good pod test: before eaa5fd3 Sections 1-11 were already in RC1; 12-17 were added for RC2; 18-22 are new in RC3 and have NEVER been run on hardware. Build requirements: * MW4.exe (Release + Profile) -- CoreTech GameOS and MW4Application changed (-tident, display trace, panel re-entry fix, -tmr, help text), and since the first RC2 build also coord.cpp, render.cpp/.hpp, huddamage.cpp and Weapon.cpp. coord.cpp is #included by DXRasterizer.cpp, so a damage-mapping change needs a full exe rebuild, not just a repack. * mw4print.exe -- new -debug switch. Builds with MW4Application. * Resource repack, now THREE packages, not just props: props.mw4 ConLobby.script / ConLobbyMission.script / MechBay weapons.script / the mech .subsystems core.mw4 HighExplosive.data, cauldronborn.torso, hellspawn.subsystems, sunder.subsystems textures.mw4 textures.hint page renames + the HUD .tga rename/removal Delete resource\.mw4 and .dep for each, then run build-env\build-resources.ps1, so every repack is full rather than incremental. (The packer carries stale entries forward on an incremental rebuild and never drops deleted ones -- see CLAUDE.md, "Resource packer quirks".) * Loose hsh\ art -- 21 damage dolls changed and 2 were deleted. These are NOT packed; deploy-mw4.ps1 copies them. No repack needed, but the deploy must run or the dolls will not match the new coordinates. * Redeploy with build-env\deploy-mw4.ps1, then run set-appcompat.bat at the install path. ================================================ 1. DUAL MFD (mode 4) -- right device stagger fix [ ] In a pod with two MFD screens (mode 4), verify right MFD shows correct channel data (channels 3-4) and does not flash blank/grid-only frames [ ] Left MFD still shows channels 0-2 correctly at all times [ ] Radar display unaffected [ ] Mode 1 (single MFD) still works normally (code path unchanged) 2. SERIAL RIO / -tbaud BAUD RATE SCALING [ ] Default 9600 baud RIO board: poll timeout is 50 ms (same as before) [ ] High-speed board at 115200 baud: poll timeout is ~5 ms (faster response) [ ] Custom -tbaud 31250: timeout is ceil(480000/31250) = 16 ms [ ] Verify no regression in button/lamp/analog response at all three rates [ ] Verify game launches normally without -tbaud flag 3. MULTIPLAYER -- 16 PILOTS + 1 CAMERASHIP [ ] Host a 16-player game; a 17th connection as cameraship can join without "Too many player/bots" error [ ] The cameraship slot does not count against the pilot cap in the lobby [ ] Standard 16-pilot session (no cameraship) still works normally [ ] Player limit slider in lobby still functions correctly at runtime [ ] COOP mode unaffected (still caps at 9 pilots + bots) 4. MECH LOADOUTS [ ] Battlemaster IS: spawns with PPC, 6x ML (3 RT/3 LT), 2x MG (200 rds), SRM6 (15 rds) [ ] Battlemaster IS: all weapons in group 1 except SRM6 (group 2) [ ] Battlemaster Clan 2C: spawns with ER PPC, 6x ER ML, 2x Clan Gauss (16 rds each), Clan SSRM6 (15 rds) [ ] Behemoth / Behemoth II: Gauss rifles fire with group 1 (not group 3) 5. CONLOBBY -- V5.1.0b3 / SUPER6 MECH ROTATION [ ] Console title displays "BattleTech Console V5.1.0b3" [ ] Rookie mech cycle shows 6 mechs: Archer, Loki, Madcat, Thor, Vulture, Warhammer [ ] Right-click random mech picks from all 6 (not 5) [ ] MP time-limit dropdown shows 23 entries (1-15, 20, 25, 30, 45, 60, 120, 180, 240 min) and scrolls correctly [ ] MP time-limit defaults to 7 min (was wrongly defaulting to 4) [ ] Lobby launches correctly with 1-16 players 6. MW4PRINT v2.0 [ ] Print job completes normally; version banner shows "2.0 / 2026" [ ] File -> Database Settings (Ctrl+D) dialog opens; MySQL host/user/pass/db fields editable [ ] With a MySQL server configured, a print job exports match data to the database [ ] Without MySQL configured (or libmysql.dll absent), print job completes silently with no crash [ ] File -> Banner Setting... opens; changing the text updates the printed bottom-of-sheet URL [ ] Banner setting persists after closing and reopening mw4print 7. LANGUAGE DLL -- ENGLISH BUTTON LABELS [ ] After a game crash/exception, the GameOS error dialog shows English button labels (More Details / Continue / Exit) instead of Korean ??? characters 8. SOURCE ENCODING / BUILD HEALTH [ ] Full Release build completes 0 errors (the min/max fix was the last issue) [ ] No new warnings introduced beyond the pre-existing 384 ------------------------------------------------ Added 2026-07-23 (commit 5813aeb6) ------------------------------------------------ 9. ROOKIE MISSION -- CONFIGURABLE DEFAULTS VIA options.ini These defaults are read by CTCL_SetCDSP at startup and exposed as gosScript globals (g_szRookieMission, g_nRookieGameType, g_nRookieTimeLimit, etc.). The console script reads them instead of hardcoded values when "Default" is clicked or when the Rookie mission auto-loads. [ ] Without [RookieMission] section in options.ini: Rookie mission defaults to "ScarabStronghold - Attrition", game type Attrition, unlimited ammo on, all other params at zero/off -- same behavior as before [ ] Add [RookieMission] section to options.ini with MissionName and GameType overridden; restart game; "Default" button in console loads the specified mission and game type correctly [ ] TimeLimit=-1 in options.ini: lobby uses the server's default time setting (g_nTimeList_Value); TimeLimit=5 sets the lobby time limit to 5 minutes [ ] All 12 overridable params work individually: Visibility, Weather, TimeOfDay, Radar, HeatOn, FriendlyFire, SplashDamage, UnlimitedAmmo, WeaponJam, AdvanceMode, ArmorMode [ ] Game launches and functions normally when [RookieMission] section is absent (no crash, no STOP on missing keys) [ ] Requires rebuild: MW4.exe (Release + Profile); ScriptStrings.dll 10. MECHLAB -- TURN RATE LABEL (StringResource.rc) IDS_ML_CH_TURNRATE changed from "Turn Rate (Degrees/Sec.):" to "Turn Rate (Top Speed Rad/Sec):". ScriptStrings.dll must be rebuilt. [ ] In mechlab, the turn rate stat row label reads "Turn Rate (Top Speed Rad/Sec):" [ ] No other mechlab labels affected [ ] Requires rebuild: ScriptStrings.dll (part of normal MW4Application build) 11. HSH ASSET FILE RENAMES -- MFD AND MECHS PORTRAITS Several hsh/ BMP files were misnamed relative to what the game loads. Filenames now match the canonical stems used in huddamage.cpp texturename[] (hsh/MFD, hsh/hud, hsh/radar/hud) and GetLocString DNL strings (hsh/Mechs). hsh/MFD/ -- in-game target MFD damage display (uses texturename[] canonical): [ ] Assassin II: MFD shows correct silhouette during combat (was assassinii.bmp, now assassin2.bmp -- matches M_Assassin2 entry) [ ] All other MFD silhouettes display correctly in combat for all 65 mechs (bulk refresh from 5.0.7D release; verify no missing/black MFD panels) hsh/Mechs/ -- mw4print post-match scorecard portraits: [ ] Print a post-match scorecard featuring a Battlemaster IIc pilot; portrait image appears (was battlemasteriic.bmp, now "battlemaster iic.bmp") [ ] Print a scorecard featuring a Behemoth II pilot; portrait appears (was behemothii.bmp, now "behemoth ii.bmp") [ ] Print a scorecard featuring a Mad Cat MKII pilot; portrait appears (was "mad cat mk.ii.bmp", now "mad cat mkii.bmp") [ ] Scorecards for all other mechs still show portraits correctly ------------------------------------------------ Added for RC2 (2026-07-25 through 2026-08-07) ------------------------------------------------ 12. -tident DISPLAY IDENTIFY MODE MW4.exe -tident [3..120, default 20] paints every display with a colour, its -tmon number, its DirectDraw device index and its current role, then exits. No exclusive mode, no display mode change. REWRITTEN FOR RC3 -- in RC2 this did not work. It opened each DirectDraw device with DDSCL_NORMAL and drew on the device's primary surface, but a secondary device's primary surface under DDSCL_NORMAL is not that monitor's framebuffer, so on a 4-monitor pod every device painted the MAIN screen in turn and only the last survived. Observed symptom: one green rectangle on the main monitor, nothing anywhere else. It now creates one borderless topmost GDI window per monitor, positioned from that device's monitor rectangle, and runs a real message pump so the windows actually paint. [ ] MW4.exe -tident on a 4-monitor pod: ALL FOUR monitors are covered, each a different colour with a large number. This is the RC2 regression -- check it first [ ] The role shown on each monitor (main / radar / mfd1 / mfd2) matches what that monitor actually displays during a mission [ ] The game exits on its own when the timer expires, and does NOT start [ ] -tident 5 exits after ~5 s; -tident 200 clamps to the accepted range [ ] After -tident, the desktop is unchanged: same resolution, colour depth and monitor arrangement as before (nothing to restore by hand) [ ] Works on a pod where the MFD modes are currently failing (that is the case it exists for) [ ] Everything painted on screen also appears in gos-displays.txt, including the new "N window(s) shown across M device(s)" line [ ] gos-displays.txt reports a painted line per monitor with its pixel size and desktop position, and those match the physical layout [ ] Typing those numbers into -tmon puts each panel on the intended monitor [ ] On a SINGLE-monitor test PC (not a pod): if the driver presents one monitor as two devices, one window appears showing both numbers, e.g. "1 & 2", rather than two windows overpainting. gos-displays.txt says "shares a monitor with device N" 13. gos-displays.txt FULL START-UP TRACE Startup-only logging; no frame-loop cost. File is truncated each launch. [ ] File is created next to MW4.exe on every launch, including launches that fail during panel bring-up (open-append-close, survives a crash) [ ] Header shows the exe path, the full command line, and -tmfds / -tmon converted to 0-based device indices [ ] Windows desktop topology section lists every \\.\DISPLAYn with its friendly name, attached/primary state and current mode [ ] Each enumeration callback is logged with GUID and resolved monitor [ ] Device table appears three times (before merge, after merge, final) and the adapter grouping lists devices sharing one card [ ] Role selection prints the chosen device AND the reason each skipped device was skipped [ ] Each -tmon override reports APPLIED or REJECTED with what auto-detect had chosen [ ] "Desktop arrangement, left to right" block matches the physical layout [ ] CLASH check: deliberately run -tmon with the same device twice (e.g. -tmon 1,1,3,4) and confirm the report names the clash explicitly [ ] "CTCL type = " line is present and correct on console, game pod and cameraship [ ] Startup time is not noticeably longer than the previous build 14. PANEL RE-ENTRY FIX (HSH_EnterFullScreen2 releases before re-opening) Panels used to be re-opened without the previous DirectDraw objects being released, leaking the exclusive claim. Bites hardest when a panel sits on the monitor Windows treats as primary. [ ] Full MFD pod (-tmfds 4) survives an Alt-Tab out and back with all panels still drawing [ ] Panels still work after a display mode change (shell -> mission -> shell, and mission restart) [ ] gos-displays.txt shows HSH_EnterFullScreen2 running more than once with NO DDERR_EXCLUSIVEMODEALREADYSET / DDERR_NOCOOPERATIVELEVELSET on the later entries [ ] Cameraship (mr_device) path: same Alt-Tab / mode-change test [ ] Test at least once on a machine where a panel IS on the Windows primary monitor -- that is the configuration that used to fail 15. CAMERASHIP MAP/ARMOR SCREEN AND -tmr Field report root cause was -ctcltype 2 (game pod) on a cameraship, not a video card. Overlays are gated on the CTCL role; the background is not. [ ] Cameraship launched with -ctcltype 3: Map/Armor screen shows background AND armour/score/map overlays [ ] gos-displays.txt reads "CTCL type = 3 (cameraship - overlays WILL be drawn)" [ ] Launch the same machine with -ctcltype 2 and confirm the documented symptom (background only, no overlays) and the matching log line -- this is the triage rule, worth seeing once [ ] -tmr 0 (default / switch absent): behaviour identical to the previous build [ ] -tmr 3 paints a magenta test rectangle on the Map/Armor screen [ ] -tmr 1 and -tmr 2 run without crashing [ ] Draw-call counts are reported for the first 5 frames when -tmr is set 16. MP TIME LIMITS TO 240 MIN -- IN-MISSION BEHAVIOUR Extends section 5, which covers the lobby dropdown, the 7-minute default and the console title. Content only (props.mw4). Requires a full repack: delete resource\props.mw4 and props.dep first, then run build-env\build-resources.ps1. [ ] Default button returns the time limit to 7 minutes [ ] Select 240 minutes, launch, and confirm the in-mission timer starts at 240:00 and counts down correctly [ ] Mission ends on time expiry at a long setting (spot-check one, e.g. 45) [ ] PC host lobby (HostLobbyMission) time list shows the same 23 entries and does not crash when opened -- the else-branch re-brace 17. -help AND DOCUMENTATION [ ] MW4.exe -help writes mw4-help.txt and opens it; game does not start [ ] -tident, -tmr, -tcoop, -tbaud, -tmfds 4, -tmon and -fps all appear with correct ranges [ ] -tmon entry states these are NOT Windows Display Settings numbers [ ] -ctcltype entry states a cameraship must use 3 [ ] -fps entry describes the per-second 5% low and the session 1% / 0.1% summary (matches what gos-fps.txt actually prints) ------------------------------------------------ Added 2026-08-09 -- NOT yet tested on hardware ------------------------------------------------ 18. EXTERNAL MFD AND RADAR DAMAGE PAPER DOLLS -- 22 CHASSIS REMAPPED coord.cpp texuv2/offset2 (external MFD) and texuv3/offset3 (Radar) were repaired, and 21 loose hsh\ doll images were replaced with the J&J art. Two faults were systemic and affected every chassis touched by the 2026-08-07 import: the texuv and offset values were transposed, and the figure was mirrored left-for-right. Both are fixed. Needs the external MFD and Radar panels, i.e. -tmfds 1/3/4. None of this is visible in console mode. Baseline: take one intact 'Mech and one badly damaged 'Mech per chassis. [ ] Doll is the RIGHT MECH -- silhouette matches the chassis, not another [ ] Handedness: damage to the 'Mech's RIGHT arm/torso/leg lights up on the VIEWER'S LEFT. This is the mirroring fault; check it explicitly on an asymmetric chassis (Rifleman, Warhammer, Longbow) [ ] Zones line up with the artwork -- no piece floating in empty space, no leg box running past the feet [ ] Left/right pairs sit at the same height [ ] Colours track real damage: shoot one limb, only that zone changes MFD changed (21), verify each: [ ] annihilator [ ] archer [ ] ares [ ] argus [ ] assassin2 [ ] atlas [ ] avatar [ ] battlemaster [ ] battlemasteriic [ ] behemoth [ ] behemothii [ ] blackhawk [ ] fafnir [ ] flea [ ] gladiator [ ] kodiak [ ] longbow [ ] rifleman [ ] sunder [ ] victor [ ] warhammer Radar changed (18), verify each: [ ] annihilator [ ] archer [ ] ares [ ] argus [ ] assassin2 [ ] avatar [ ] battlemaster [ ] battlemasteriic [ ] behemoth [ ] behemothii [ ] blackhawk [ ] fafnir [ ] hellspawn [ ] kodiak [ ] longbow [ ] rifleman [ ] victor [ ] warhammer Specific cases worth calling out: [ ] Rifleman and Battlemaster previously used another mech's rows entirely (Mad Cat's and Atlas's). Both should now fit their own art. [ ] Atlas MFD doll was REGENERATED from its Radar art -- this replaces shipped artwork rather than restoring intent. Look at it carefully. [ ] Behemoth II deliberately shares Behemoth's art and geometry; the two should look identical, and that is correct. [ ] Longbow: the piece formerly mapped as Special1 on the Radar is the cockpit canopy and is now mapped as Head. On the MFD the same piece is the pelvis and is still drawn. Confirm neither looks wrong in game. [ ] Chassis NOT in the lists above are untouched -- spot-check two (e.g. madcat, thor) and confirm no regression. 19. 2D TARGET MFD MECH IMAGE -- ATLAS CAPACITY AND TWO NAME MISMATCHES This is the small picture of your TARGET on the MFD, not the damage doll. The atlas held 64 tiles for 65 chassis, so the last one wrapped around and displayed a different mech. Two chassis also had art the code could not find. Requires -tmfds; default (2D) target mode, i.e. NOT -3dt. [ ] Target a ZEUS -- the MFD shows a Zeus. Before this build it showed the ANNIHILATOR, cleanly and convincingly, which is why it was never reported. This is the headline check. [ ] Target an ASSASSIN II -- an image appears at all (previously the tile was never written, so it showed whatever was in video memory) [ ] FLY a BEHEMOTH II in the RELEASE build, into a mission, and confirm it does NOT stop with "Texture ... could not be found!". This one was fatal in Release and masked in Profile by the placeholder texture, so it MUST be checked with MW4.exe and not MW4pro.exe. [ ] Spot-check five other chassis targets still show the correct picture [ ] gos-displays.txt contains a line reading "[mfd] target atlas 1024x2048, 128 tiles, 65 chassis" [ ] If it instead reads "1024x2048 target atlas refused by the driver; using 1024x1024", the card will not take the taller texture. That is a supported fallback: everything behaves exactly as the old build, including the Zeus fault. Note the machine and report it. [ ] No "*** atlas full ***" line appears [ ] -3dt (live 3D target model) still works and is unaffected 20. HIGH EXPLOSIVE CHARGES NOW FIRE Weapon ID 87. Previously installable in MechLab but impossible to fire: HighExplosive.data used an unregistered key, and MechLab's starting-ammo formula truncated to zero rounds. Requires MW4.exe rebuild + core.mw4 and props.mw4 repacks. [ ] Fit a High Explosive in MechLab; it shows as installed [ ] Take it into a mission and FIRE it via its weapon group (group 3 by default). It is a normal one-shot weapon -- it is NOT triggered by ejecting [ ] It detonates: ~100 damage in a 30 m radius, and ~200 damage to your own centre torso [ ] Fit several in ONE group and use Group Fire -- all detonate together. Chain Fire sets off one at a time [ ] NARC BEACON REGRESSION CHECK: NARC (ID 84) shows its ammo round count in MechLab again. The UI flag was previously on the wrong weapon id, so NARC was wrongly being treated as a one-shot charge [ ] No other weapon's starting ammo changed -- spot-check an AC20, an LRM20 and a Medium Laser in MechLab [ ] Any saved variant that already had a High Explosive: remove and refit the charge, in case zero ammo was serialised into the variant 21. THREE CONTENT DEFECTS FOUND WHILE DECOMPILING V4H Pre-existing faults in our own content, unrelated to the V4H merge. All three are core.mw4; the two heat-sink ones also affect props. [ ] Cauldron Born: torso twist still feels normal. Its .torso referenced $(OBSTUSE_TRADIUS), a typo for OBTUSE that is defined nowhere, so the engine silently fell back to 100. It now says 100 outright, so behaviour is UNCHANGED by design -- this is a "confirm nothing moved" check, not a "confirm something improved" one [ ] Hellspawn: spawns and runs normally, heat behaves as before (its .subsystems had a page header "[HeatSink10" with no closing bracket) [ ] Sunder: same check ("[HeatSink16") [ ] Both mechs' heat sink counts in MechLab are unchanged from RC1 22. MW4PRINT -- NEW -debug SWITCH [ ] mw4print.exe runs normally with no switch, exactly as before [ ] mw4print.exe -debug produces a step-by-step diagnostic log [ ] The log records the assets directory and the command line at startup [ ] A normal print job still completes with -debug active [ ] /debug is accepted as well as -debug