The binaries and packages committed as RC2 in 8bfaf9b9 no longer match the
source tree: MW4.exe, mw4print.exe and three resource packages have all changed
since. RC2's own notes warn about exactly this situation with RC1, so this is a
version bump rather than an edit in place.
Console title -> V5.1.0b3, with a new dated line in the ConLobby.script
changelog block; the existing lines are left alone. That string lives in
props.mw4, so it only appears on a pod after the repack, which is what makes it
a usable "did this machine get the new content" check.
Release notes and checklist renamed RC2 -> RC3. The notes' front matter was
restructured rather than having a third block stacked on it: "Already testing
RC2? Here is what is new in RC3" now leads, followed by "What was new in RC2"
for anyone jumping two versions.
New in the notes, written for pod owners rather than engineers:
* Damage displays corrected on 22 'Mechs, described as the two faults an
operator would actually notice -- the figure was mirrored, and the zones did
not line up with the artwork -- plus the note that Rifleman and Battlemaster
had been using another chassis' layout entirely.
* The target picture on the MFD showed the wrong 'Mech. Includes the
gos-displays.txt line to look for, and what it means if the card refuses the
larger atlas and falls back.
* High Explosive charges now fire, how to use them (weapon group, not eject),
the NARC side effect, and the advice to refit the charge on saved variants.
* Three content faults corrected. Cauldron Born is explicitly flagged as
behaviour-unchanged so nobody hunts for a difference that is not there.
* mw4print -debug.
* A warning that this build changes artwork as well as the executable, and
upgrade step 2 now says to copy the whole folder. An old hsh\ with a new
MW4.exe gives wrong damage displays, which is the trap this build creates.
Checklist gained sections 18-22, 88 -> 133 checkboxes, all marked as never
having been run on hardware:
* 18 names every one of the 22 chassis individually for both displays, and
makes handedness an explicit check, since the mirroring is the fault that
reads as "slightly odd" rather than obviously broken. Calls out that the
Atlas MFD doll was regenerated and so replaces shipped art.
* 19 leads with targeting a Zeus, and requires flying a Behemoth II in the
RELEASE build -- that fault was fatal in Release and masked in Profile by the
placeholder texture, so testing it with MW4pro.exe proves nothing.
* 20 includes the NARC ammo-count regression check.
* 21 frames the content fixes as "confirm nothing moved".
* 22 covers mw4print -debug.
The build-requirements header was materially wrong and has been rewritten. It
named props.mw4 only; core.mw4 and textures.mw4 now change too, each must be
deleted before repacking because the packer carries stale entries forward and
never drops deleted ones, coord.cpp is #included by DXRasterizer.cpp so a
mapping change needs a full exe rebuild, and the 21 changed hsh\ dolls are
loose files that arrive only via deploy-mw4.ps1.
All three documents remain pure ASCII with CRLF endings so they open correctly
in Notepad on a pod; the HTML was checked for balanced tags.
Nothing here covers the six staged V4H chassis. They are not in the source tree.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
358 lines
20 KiB
Plaintext
358 lines
20 KiB
Plaintext
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 (new switch)
|
|
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. Uses DDSCL_NORMAL + GDI: no exclusive mode, no display mode change.
|
|
|
|
[ ] MW4.exe -tident on a 4-monitor pod: every monitor shows a distinct
|
|
colour and a large number; no monitor is left on the desktop
|
|
[ ] 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
|
|
[ ] Typing those numbers into -tmon puts each panel on the intended monitor
|
|
|
|
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
|
|
|