firestorm/testing-checklist-5.1.0b_RC3.txt

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\<pkg>.mw4 and <pkg>.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 = <n>" 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