Correct the High Explosive ammo key and ensure positive-capacity weapons receive at least one starting round and ammo per pack. Apply MechLab special handling to weapon ID 87 and document activation, stacking, validation, and deployment requirements.
Adds runtime diagnostic logging to track down why printing is broken.
Pass -debug (or /debug) on the command line; all output goes to
mw4print-debug.txt next to the exe (append mode, timestamped lines).
No effect on normal operation when the flag is absent.
What is logged:
- Startup: AssetsDirectory1 path and full command line
- OnCreate: DB config loaded, timer created
- DoCopyData / OnFileOpen: each file queued for printing with filename
- OnTimer: which file is being processed each second, LoadPR result
- DoPrint: nPlayers count, PrintDlg call + result (on failure logs
CommDlgExtendedError hex code), DB export call/result, SetupFonts
result, StartDoc result, EndDoc vs AbortDoc, final return code
The CommDlgExtendedError value on a PrintDlg failure will identify the
root cause (e.g. CDERR_NODEFAULTPRN = no default printer configured).
Co-authored-by: Claude Sonnet 4.6 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
RC2 build, verified to launch on the Windows box and copied back into the
deployment at MW4/. Supersedes RC1 (a0331e78), which predates everything in
sections 12-17 of the test checklist.
Binaries and content
--------------------
* MW4.exe / MW4pro.exe rebuilt from CoreTech GameOS + MW4Application. Carries
the display work that landed after the RC1 build: -tident, the full
gos-displays.txt start-up trace with the CLASH and CTCL-type reports, the
HSH_EnterFullScreen2 panel re-entry fix, the -tmr cameraship ladder, and the
updated -help text.
* Launcher / autoconfig / mw4print / ctcls / MissionLang / ScriptStrings
relinked in the same pass.
* props.mw4 + props.dep fully repacked (deleted first, not incremental), so the
23-entry time list, the restored 7-minute default and the V5.1.0b2 console
title are actually in the package rather than only in the source tree.
* mw4-help.txt regenerated from the new exe; the diff is the proof the built
binary carries the documentation changes.
Documentation, renamed to RC2
-----------------------------
* RELEASE-NOTES-5.1.0b_RC1.{md,html} -> ..._RC2.{md,html}, both hand-maintained
in step, ASCII + CRLF so they open correctly in Notepad on a pod.
- New "Already testing RC1?" block at the top. RC1's notes already described
-tident and the CLASH report, but the RC1 BINARY does not contain them, so
anyone comparing the two needed that stated explicitly.
- Time limits corrected to 23 entries (1-15, 20, 25, 30, 45, 60, 120, 180,
240) with the 7-minute default restoration called out.
- New section on the cameraship Map/Armor screen: background but no overlays
is -ctcltype 2 on a cameraship, not a video card. Includes the
"CTCL type =" log line and -tmr 3 as the follow-up check.
- -fps description corrected: the per-second column is a 5% low and the 1% /
0.1% lows are in the session summary. The old text described behaviour that
had already been changed.
- Switch table gained -tmr; known issues gained stereo-only audio and the
single-monitor -tident caveat; upgrade checklist now names V5.1.0b2.
* testing-checklist-5.1.0b1.txt -> testing-checklist-5.1.0b_RC2.txt, with a
build-requirements header and new sections 12-17 covering -tident, the
display trace (including a deliberate -tmon clash to exercise the CLASH
report), the panel re-entry fix, cameraship/-tmr, 240-minute missions and a
-help verification pass.
* OPTIONS-INI.md: TimeList_Index is documented as no longer driving the console
lobby default (the script uses a literal since the list was expanded) while
TimeList_Value remains live; added a table of the files the game writes next
to MW4.exe. Also repaired the CP949/CP1252 damage in that file - it carried
literal 0xA1 0xE6 arrows, 0x97 em dashes and ~20 '?' characters where dashes
had been lost. Now pure ASCII.
* README.md points at the RC2 notes.
Source
------
MW4Application.cpp help text: -fps now matches what gos-fps.txt actually
prints, and -ctcltype states that a cameraship must use 3 and what goes wrong
when it does not. Audited all 80 switches parsed in the file against the help
array - none missing, and no game-facing switch is parsed anywhere else.
Deployment housekeeping
-----------------------
* dgVoodoo.conf: ScalingMode = stretched_ar, which is the setting the release
notes require and which fails SILENTLY when wrong. FPSLimit was left at 20
from bench testing and would have shipped a 20 fps cap to every Win10/11 pod
- raised to 60.
* banner.txt reset from a test string to the shipped placeholder.
* Removed two stray screen000*.bmp captures and the duplicate dbstruct.txt
(db_schema.sql is the current name, per b4089291).
* .gitignore: gos-displays.txt and gos-fps.txt are truncated on every launch
and are per-machine, so they are no longer mirrored.
Not yet done: multi-monitor pod testing of this binary. -tident, the re-entry
fix and -tmr have not been exercised on real MFD hardware - that is what the
new checklist sections are for.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
Follow-up to the gos-displays.txt enumeration trace. The expanded log
arrived from the Intel tester and settled the failure - and disproved the
hypothesis it was written to test.
What the log showed
-------------------
The consistency check printed "No duplicate device assignments", so the
suspected -tmon clash was NOT the cause. The actual evidence was that
HSH_EnterFullScreen2 runs TWICE: the first entry brings every panel up
DD_OK, the second fails on the same device with
DDERR_EXCLUSIVEMODEALREADYSET and then DDERR_NOCOOPERATIVELEVELSET.
Two independent causes, one operational and one a real defect.
Cause 1 - Windows Display Settings numbers are not DirectDraw indices
--------------------------------------------------------------------
The operator set -tmon by reading the numbers off the Display Settings
arrangement diagram. On that machine all three numbering systems differ:
Settings 3 -> \\.\DISPLAY1 -> device 0 (primary, 800x600, main)
Settings 4 -> \\.\DISPLAY4 -> device 3 (USB adapter, radar)
Settings 2 -> \\.\DISPLAY2 -> device 1 (mfd1)
Settings 1 -> \\.\DISPLAY3 -> device 2 (mfd2)
A permutation with two accidental fixed points - no derivable rule, and
the Settings ordinal is not exposed by any documented API, so it cannot
be translated in code. -tmon 1,4,2,3 worked first try (user-confirmed).
This is why Windows ships an Identify button rather than publishing the
mapping.
Cause 2 - panels re-opened without being released (REAL BUG, all machines)
-------------------------------------------------------------------------
EnterFullScreenMode() calls HSH_EnterFullScreen2() on every mode change
and every lost-front-buffer recovery, but the teardown
HSH_DirectDrawRelease2() was only wired to DirectDrawRelease(), i.e. full
shutdown. CHSH_Device::InitFirst() therefore overwrote pDD with a fresh
IDirectDraw7 while the previous one still held exclusive fullscreen,
leaking it and its exclusive claim for the life of the process.
It only bites when a panel sits on the Windows primary: secondary outputs
grant exclusive mode again, the primary does not. Every working pod
happens to have the main display on the primary, so no panel is ever
there - which is the whole reason this looked hardware-specific.
FIX: HSH_EnterFullScreen2() now releases first when hsh_initialized ||
hsh_mrdev_initialized. Tagged [panelreinit]. Reuses the existing teardown,
which already restores the display mode, drops the coop level and clears
the flags for both the MFD/radar and cameraship paths.
New: -tident, the game's own Identify
-------------------------------------
MW4.exe -tident [3..120, default 20] fills every display with a distinct
colour and prints, huge, the number to type into -tmon, plus its device
index and the role currently assigned to it. Then exits.
Deliberately uses DDSCL_NORMAL and paints via GDI on the primary surface:
no exclusive mode, no display mode change. Taking exclusive fullscreen on
several devices at once is the very failure being diagnosed, and a
diagnostic that trips over that fault is worthless - this works even on a
pod where the MFD modes are broken.
It opens the real DirectDraw devices rather than positioning GDI windows
by HMONITOR, so it proves the device-index -> physical-output association
through the same path the panels use. Positioning by DirectDraw's own
reported HMONITOR would be circular.
Implemented as IdentifyDisplays() in VideoCard.cpp, called at the end of
FindVideoCards() followed by ExitProcess(0). Everything it paints is also
written to gos-displays.txt, so the mapping survives even if a monitor is
dead.
Also added: desktop-order block
-------------------------------
gos-displays.txt now prints the monitors sorted left-to-right by desktop
position with their device indices, which maps directly onto the picture
in Display Settings. For the reporting machine it reads out as
-tmon 1,4,2,3 with no derivation required.
Documentation
-------------
* -help: new -tident entry. The -tmon text now states outright that these
are NOT Display Settings numbers and points at -tident. Its old
"-tmon 1,2,3,4" example was actively inviting the mistake that caused
this report, so that section was rewritten rather than appended to.
* Release notes (md + html, both hand-maintained): -tident section with
sample output and the reason it has to exist; -tmon warning; new
sections for the CLASH report and the re-entry fix in operator terms;
switch-table row; expanded log description with the copy-before-relaunch
warning; upgrade-checklist step to run -tident once after upgrading.
* CLAUDE.md: STEP 12 with the full engineering record, including the
three-way numbering table and both causes.
* OPTIONS-INI.md: videodriverindex note now points at -tident.
Cost
----
-tident is opt-in and exits immediately after. The desktop-order block is
a handful of extra startup writes. Nothing added is reachable from the
frame loop.
Testing
-------
-tmon 1,4,2,3 confirmed working on the reporting machine, which validates
the diagnosis. The -tident and re-entry changes are NOT yet built or run;
both need a rebuild of MW4.exe (Release + Profile) as they touch CoreTech
GameOS. Worth checking on the W4100 bench first that
CreateSurface(PRIMARYSURFACE) under DDSCL_NORMAL succeeds on secondary
devices through dgVoodoo2 - if a panel comes up blank the log names the
failing call.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
Investigating a field report that the cameraship secondary armor/score/map
screen showed its background BMP but no overlay graphics "on certain video
cards". The video card was a red herring: the machine was launched with
-ctcltype 2 (game pod) instead of 3 (cameraship), and the overlay block in
hudchat.cpp is gated on CTCL_GetType()==_ECTCL_CameraShip, so it never ran.
This is hard to spot because the two gates are independent. HSH_EnterFullScreen2
and CMR_Device open the screen and paint its background based purely on whether
a spare secondary monitor exists, and never consult the CTCL role. A wrong
-ctcltype therefore yields a screen that lights up, shows the correct artwork
and renders nothing, which is visually identical to a DirectDraw failure. The
same background-only screen also appears on a game pod when an MFD mode finds no
dual-head span and falls through to the single-secondary mr_device path.
Diagnostics added:
- render.cpp: log the CTCL type in gos-displays.txt from HSH_EnterFullScreen2,
via the existing g_pfnCTCL_GetType hook so GameOS gains no game-code
dependency. Always logged, and states in words whether overlays will be drawn.
- render.cpp/.hpp: CHSH_Device::m_nDrawCalls, incremented in DrawQuad,
DrawThickFrame and DrawTexture, reset in CMR_Device::BeginScene and reported
for the first 5 frames from CMR_Device::EndScene when -tmr is active. Zero
draws proves the overlay code never ran; non-zero with a blank screen would
mean it ran and drew invisibly. This distinction is what settled the case.
- render.cpp: log CMR_Device surface creation plus the overlay texture's
dimensions, depth and channel masks.
- New -tmr <0-3> switch (MW4Application.cpp, documented in -help): 0 normal,
1 background blit with DDBLTFAST_WAIT|DDBLTFAST_NOCOLORKEY, 2 Clear instead of
the background blit, 3 as 2 plus alpha blending off and an untextured magenta
DrawQuad.
Mode 3 drew magenta and mode 2 was pure black, which cleared the 3D device, the
flip and the background blit in two runs; the draw counter then reported 0 and
pointed straight at the gate. Documented as STEP 11 in CLAUDE.md, including the
field triage rule: read "CTCL type =" in gos-displays.txt before suspecting
drivers.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
Four-monitor MFD bring-up on the new bench (MR_new: AMD FirePro W4100, 4 outputs,
Win10). Adds permanent display diagnostics, a Release-capable frame pacing logger,
a self-locating AppCompat shim installer, and settles -- empirically -- whether
dgVoodoo2 can be dropped for the multi-monitor MFD modes. It cannot.
WHY THIS WAS HARD
-----------------
CHSH_Device::InitFirst/InitSecond discarded EVERY HRESULT (SetCooperativeLevel,
SetDisplayMode, CreateSurface, GetAttachedSurface, QueryInterface, CreateDevice)
and returned true unconditionally. A panel that failed to open produced no error,
no crash and no log entry -- the monitor just stayed on the desktop. SPEW is
compiled out of shipping builds, so none of it was visible. Restoring that
visibility is what unblocked everything else.
DIAGNOSTICS ADDED (keep these)
------------------------------
* VideoCard.cpp -- LogDisplayDevices() writes gos-displays.txt next to the exe:
NumDevices/NumHWDevices/NumMonitors, every DirectDraw device with its
hw_rasterization flag, the role assignment (FullScreenDevice / g_nNonDualHead /
g_nDualHead / g_nDualHead2 / g_nMFD1 / g_nMFD2), per-slot -tmon APPLIED/REJECTED
(previously silent), and whether mode 4's "BOTH mfd1 and mfd2" requirement is met.
* render.cpp -- HSH_LogInit()/HSH_CheckHR()/HSH_HRName() log every DirectDraw call
in the panel init path with its HRESULT decoded by name (27 DDERR_* codes, all
verified present and collision-free against build-env/dx7asdk/include/ddraw.h).
Each line is opened/appended/closed individually so the log survives a crash.
* WinMain.cpp -- GOS_LogFrameRate() writes gos-fps.txt: per second, frame count,
average fps, 1% low (mean of the worst 1% of frames), worst frame in ms, and a
count of frames exceeding 2x average ("hitches"). Average fps alone cannot
distinguish 60fps from 60fps-with-a-dropped-frame-every-second; the 1% low can.
The engine's own FrameRate readout is #ifdef LAB_ONLY (MWMission.cpp) so it only
exists in MW4pro.exe; this works in Release, which is what runs on the pods.
NEW SWITCHES (both documented in -help)
---------------------------------------
* -fps Enable the frame pacing report. Off by default: the gate is the first
statement in GOS_LogFrameRate, so an unflagged run does no arithmetic
and does not even create the file. The file handle is held open for the
process lifetime -- opening/closing it every second would put a syscall
of unpredictable latency on the render thread, i.e. the measurement tool
perturbing what it measures.
* -tcoop <0-5> Selects the SetCooperativeLevel form used by the radar/MFD panels.
0 = legacy (unchanged shipped behaviour, remains the default).
Exists so every candidate fix could be compared on real hardware without
a rebuild between attempts.
CRASH-SAFETY FIX
----------------
hsh_initialized was set unconditionally after panel init, so a failed panel left
null surfaces and a null IDirect3DDevice7 behind and the per-frame path called
straight through them. Now:
- all four InitSecond overrides (CMR/CRadar/CMFD/CMFDRight) bail on base failure,
- CMFD_Device::InitFirst reports its real result instead of always returning true,
- hsh_initialized is only set when the panels genuinely came up.
A display failure now leaves the game running without MFDs instead of bombing to
desktop. Crash signature for the record: `call [ecx+0x44]` with ECX=0 is
IDirectDrawSurface7::GetDC on a never-created surface (vtable offset confirmed
against the DX7 header), reported as "Attempt to read from address 0x00000044".
APPCOMPAT SHIM INSTALLER (new)
------------------------------
build-env/set-appcompat.ps1 + set-appcompat.bat. Self-locating via $PSScriptRoot:
applies DWM8And16BitMitigation to the MW4 executables sitting next to it, wherever
that install lives. HKCU always, HKLM too when elevated (the HKLM value format
differs -- it carries a leading "$" marker -- so the two must not be interchanged).
Verifies by reading back; detects the HIGHDPIAWARE-only entry that SUPPRESSES the
automatic shim; supports -Remove and -WhatIfOnly. deploy-mw4.ps1 now ships both
files into every deployment.
This matters because the layer is keyed on the executable's FULL PATH -- any copy
of an install to another folder or machine silently loses it, and the resulting
error is actively misleading (see below).
WHAT WE LEARNED
---------------
* The AppCompat shim SYNTHESISES 16-bit display modes. Proved directly: the crash
dump shows "16 bit modes :" EMPTY without it and fully populated with it. MW4
renders at bitdepth=16 and modern GPUs expose no 16-bit modes at all.
* Without the shim, GameOS reports "Another application is preventing use of full
screen mode" (GOS_DXRASTERIZER_NOFULLSCREEN, DXRasterizer.cpp ~1125). That is a
catch-all fired after every SetDisplayMode attempt fails -- it even scans for
NetMeeting -- and it sends you looking for a conflicting program that does not
exist. The real cause is the missing shim.
* Exclusive fullscreen DOES work on Win10 with the system ddraw.dll and dgVoodoo2
physically removed, once the shim is applied to that exe path.
* Windowed mode works natively with no shim at all: the windowed path sets
Environment.bitDepth = DesktopBpp (32), so there is no mode switch. Verified for
the console/shell; a full mission windowed is still untested.
* Native DirectDraw enumerates all four W4100 outputs, so dgVoodoo2 was never
needed for device enumeration.
* The engine is 4:3 ONLY. ImageHlp.cpp ~464 asserts the complete supported set:
640x480, 512x384, 800x600, 960x720, 1024x768, 1280x1024 (5:4), 1600x1200. No
16:9 mode and no aspect correction anywhere in the codebase. On a 16:9 monitor
the scaler must adapt: plain stretch distorts geometry, keep-aspect pillarboxes.
* -2dt is not a recognised switch anywhere in the codebase, despite appearing in
production ctcl.ini launch lines. Completely inert.
* NumHWDevices (5) can exceed NumDevices (4): it counts D3D device-enumeration
callbacks, and an adapter exposing both a HAL and a T&L HAL yields two. Benign.
WHAT WE TRIED AND WHY IT FAILED
-------------------------------
The panel cooperative-level call was genuinely wrong -- a latent 2002 bug. Every
panel asked to be BOTH the process focus window AND its own device window, on the
one shared hWindow, after the main device had already taken exclusive mode on it.
The main device (DXRasterizer.cpp ~1027) already uses the correct two-call idiom
(SETFOCUSWINDOW alone, then EXCLUSIVE|FULLSCREEN) -- tagged //sanghoon, the same
author. The panels never were.
Results on real hardware, no dgVoodoo2, shim applied, -tmfds 4:
-tcoop 0 SETFOCUSWINDOW|CREATEDEVICEWINDOW|ALLOWREBOOT|EXCLUSIVE|FULLSCREEN
-> DDERR_EXCLUSIVEMODEALREADYSET
-tcoop 1 CREATEDEVICEWINDOW|EXCLUSIVE|FULLSCREEN (no focus claim)
-> DDERR_INVALIDPARAMS (CREATEDEVICEWINDOW needs a focus window)
-tcoop 2 SETFOCUSWINDOW, then CREATEDEVICEWINDOW|EXCLUSIVE|FULLSCREEN
-> DDERR_INVALIDPARAMS
-tcoop 3 SETFOCUSWINDOW, then EXCLUSIVE|FULLSCREEN
-> first panel collides, but that collision STEALS exclusive mode from
the main display, after which panels 2 and 3 fully initialise (the
radar reached CreateDevice(HAL) = DD_OK -- a secondary panel running
entirely on native DirectDraw). Side effect: the desktop was left at
1920x1080 16bpp. Not viable.
-tcoop 4 EXCLUSIVE|FULLSCREEN only -> EXCLUSIVEMODEALREADYSET, all panels
-tcoop 5 ALLOWREBOOT|EXCLUSIVE|FULLSCREEN -> EXCLUSIVEMODEALREADYSET, all panels
CONCLUSION: on modern Windows only ONE DirectDraw object per process may hold
exclusive fullscreen. The main display takes it; every secondary panel is refused.
XP allowed multiple. dgVoodoo2 allows it because it is a full reimplementation of
ddraw and is not bound by that rule -- it is not papering over a bug we can fix.
=> dgVoodoo2 CANNOT be removed for -tmfds 1/3/4 by correcting these flags. The
default stays -tcoop 0. The switch is retained because it is how this was settled
and it will re-settle it on different hardware.
The only native path is a borderless windowed panel design (DDSCL_NORMAL + clipper
per monitor, no exclusive mode anywhere). Assessment and staged plan are recorded
in CLAUDE.md STEP 10; not started.
WORKING 4-MONITOR CONFIG (with dgVoodoo2)
-----------------------------------------
dgVoodoo2 Scaling mode MUST be "Stretched, Keep Aspect Ratio". Plain "Stretched"
fails silently: main and radar go fullscreen black, both MFD monitors keep showing
the desktop, and every DirectDraw call still returns DD_OK -- the devices are alive
but dgVoodoo2 never drives those outputs. Diagnosed with a temporary per-panel
colour-flash test (since removed), which also established that device index maps
1:1 to physical monitor on this bench, so -tmon 1,2,3,4 equals auto-detection.
Confirmed working end to end: all three secondary panels present, full mission
played.
KNOWN GAP: the working dgVoodoo.conf is still not versioned in the repo (removed
in 0ceba9c7), so a fresh deploy will reproduce the silent MFD failure.
Behaviour with no new switches supplied is unchanged from the previous build
except on failure paths, which now degrade gracefully instead of crashing.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
MW4.exe accepts 76 command line switches. Only 27 of them appeared in the old
-help output, that output went to the debug log rather than to the user, and it
did not stop the game from launching afterwards -- so in practice the switches
were undocumented.
-help now writes a full, categorised reference to mw4-help.txt next to the
executable, opens it in Notepad, and returns from WinMain without starting the
game. If Notepad cannot be launched, a message box reports where the file was
written. The check runs immediately after the command line is lower-cased at the
top of WinMain, before any subsystem is initialised.
A file plus a viewer was chosen over a message box because MW4 is a GUI-subsystem
application with no console, and 76 switches with real descriptions do not fit
legibly in a dialog.
The reference documents every switch actually parsed, grouped as: display and
video, audio and plasma display, pod hardware and arcade (CTCL), zoom and field
of view, multiplayer and network, logging and diagnostics, development and test
builds, and other. Each entry records the accepted value range where the parser
enforces one -- for example -tbaud 9600-921600, -armorlevel 0-4, -tmfds 0-4,
-zmfovb 0.01-0.5, and the -zmtime special case where 0 means instant.
Two switches are listed under "recognised but inactive" so their behaviour is not
misrepresented: -join, whose consuming line is commented out, and -noabzug, which
is only parsed inside a disabled code path. The LAB-only switches are marked as
accepted and ignored in Release builds.
The old partial SPEWALWAYS list in GetGameOSEnvironment was removed so there is a
single maintained reference rather than two that can drift apart. A comment there
points at the new one.
Also adds an explicit #include <stdio.h>; this translation unit previously had no
direct stdio use and relied on transitive inclusion.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
Display roles are auto-detected in FindVideoCards(): the main view takes the
first hardware-rasterizing device that is not a 1280x480-capable span, the radar
takes the next, and mode 4's two MFD panels take the two after that. That works
until DirectDraw enumerates the adapters in an unexpected order, at which point
the wrong content appears on the wrong monitor with no way to correct it.
Adds an override that keeps auto-detection as the default:
-tmon <main>,<radar>,<mfd1>,<mfd2>
Values are 1-based, so the normal case is "-tmon 1,2,3,4". A value of 0 leaves
that slot auto-detected, so "-tmon 2,1,0,0" swaps only main and radar. Separators
may be ',' '/' or ':'. mfd1/mfd2 are only meaningful with -tmfds 4. Omitting the
switch entirely preserves existing behaviour exactly.
Implementation:
- Parsed in MW4Application's WinMain alongside -tmfds. That runs before GameOS
calls FindVideoCards(), so the values are in place for device selection.
- Stored in g_naMonitorOverride[4] (VideoCard.cpp), extern'd in MW4Application.cpp.
- ApplyMonitorOverride() validates the index against NumDevices, so a stale -tmon
on a machine with fewer monitors falls back to auto-detection rather than
breaking startup.
- Ordering matters and is deliberate: main and radar are applied BEFORE the mode 4
MFD search so that search still skips whichever devices the operator picked;
mfd1/mfd2 are applied after it. Partial overrides therefore compose correctly.
Role map: main = Environment.FullScreenDevice, radar = g_nNonDualHead,
mfd1 = g_nMFD1, mfd2 = g_nMFD2. The mode 1 span (g_nDualHead) is intentionally
not overridable -- it is detected by 1280x480 mode support, which only the span
card advertises, so that detection is reliable.
Also adds a SPEW line logging the final role -> device map and device count.
Note this is only visible in Profile/LAB builds; SPEW compiles out in Release
(gos2X/Gos.h), so in Release the order is determined by observation.
Verified: compiles clean, console launches. Multi-monitor testing pending.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
A full 16-'Mech roster plus a cameraship silently refused to launch: the console
sat in nLaunchState 3 ("loading") forever with no crash and no error. 15 mechs +
camera worked, and 16 mechs with no camera worked.
Two independent bugs, both counting the cameraship against the 16 'Mech slots.
1. Session capacity (broke all-human rosters)
CTCL_DefaultHostSetup derived the camera reserve from
CTCL_GetTeslaCountAll() - CTCL_GetTeslaCount(). Those counters read the CTCL
tesla table, which is only populated when CTCL_IsConsoleOrCOOP() is true --
i.e. only on the console. But the machine that creates the network session is
the cameraship pod (CTCL_DoMission sets g_nServer = nCameraship, and that pod
runs CTCL_DoCreateGame -> CTCL_DefaultHostSetup(0) -> Mech4CreateGame ->
gos_CreateGame(..., Environment.NetworkMaxPlayers, ...)).
On that pod both counters return 0, so the reserve collapsed to +0 and the
session was created with dwMaxPlayers = 16. The 17th connection was refused,
CTCL_CheckServerReady never saw nCount == g_nTeslas + 1, and the launch hung.
Fixed by reserving with a constant, MW4_CAMERASHIP_RESERVE (4, matching
MAX_CAMERAS), which is valid on every machine regardless of the tesla table.
2. Bot admission (broke any roster containing bots)
MW4Shell::AddBot rejects when (player_count + bot_count) >= m_maxPlayers.
player_count is the DirectPlay player count, which includes the cameraship
connection, so with m_maxPlayers = 16 the last bot was silently refused.
g_nBOTs then never matched the connected lancemates and the same readiness
check spun forever.
Fixed by subtracting cameraship participants from player_count under CTCL,
via a new CTCL_CountCameraShipsInGame() helper (non-bot entries with
m_nMechIndex == 0). Cameraships hold a network slot but pilot no 'Mech, so
they must not consume a 'Mech slot.
Also applies the constant reserve in the PLAYER_LIMIT_PARAMETER path, guarded by
!CTCL_IsNone() so a standalone non-pod host keeps its exact configured limit.
This supersedes commit f76dc05f, which had the right formula but evaluated it on
the console rather than on the pod that actually creates the session.
Note for later: m_maxPlayers is serialized in only 5 bits (MWApplication.cpp),
so 31 is the hard ceiling for any future player-cap work. See
RAISING-PLAYER-CAP.md.
Requires rebuild: MW4.exe (Release + Profile). No script or resource changes.
Verified: compiles clean, console launches. Pod testing pending.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
- Stabilize Load File first-click behavior across mission/map/options/slots.
- Fix map sequencing by rebuilding game-type scenario list before mission lookup.
- Resolve mission-name miss to map index 0 fallback for selected game type.
- Fix decal handling: map INI decal IDs to dropdown indices, clamp invalid indices, display actual decal IDs in UI labels, and avoid redraw-time decal overwrite.
- Fix option apply timing and UI visibility issues, including Weapon Jam refresh.
- Add NoReturn support end-to-end: parse/store in MW4Shell auto globals, expose script variable, and apply to respawn/no-return mission params and UI checkbox.
- Update autoconfig spec to reflect actual parser/default/fallback behavior and add NoReturn examples.
Issue 1 — double press to fix team/FFA display:
cur_team_val is updated by ConLobbyMission's -9998 signal which was async.
Fix: call SetNetworkMissionParamater(team_allowed, ...) directly in ConLobby
before the slot loop, then re-read cur_team_val via CTCL_GetTeamParams.
This is synchronous so the slot display is correct on the first click.
New file keys: TeamAllowed=0/1, TeamCount=2 (default 2 teams).
Issue 2 — Default button broken after Load File click:
CTCL_LoadAutoFile was overwriting g_nRookieGameType/g_szRookieMission etc.
so the Default button loaded the last auto-file params instead of defaults.
Fix: 14 new dedicated g_nAutoXxx/g_szAutoMission globals. CTCL_LoadAutoFile
populates ONLY these. Rookie Mission globals are never touched.
New MAIL_LOAD_AUTO_MISSION (-6666) sent to ConLobbyMission applies the Auto
globals (mirrors MAIL_SET_ROOKIE_MISSION_PARAMS but uses g_nAutoXxx).
ConLobby reads game type/mission from Auto globals directly into the
ConLobbyMission dropdowns (@ConLobbyMission@o_game_options[N].nselected).
Files changed:
MW4Shell.cpp: 16 new globals, StartUp/ShutDown registration, CTCL_LoadAutoFile
ConLobby.script: MAIL_LOAD_AUTO_MISSION define, updated handler
ConLobbyMission.script: MAIL_LOAD_AUTO_MISSION define + handler
autoconfig-file-spec.html: document TeamAllowed + TeamCount fields
Rebuild required: MW4.exe (Release + Profile).
1. Expose g_bAutomaticMode as gosScript variable so ConLobby can check
it at init time. o_load_file.state is set to 3 (disabled/hidden) if
automaticmode != 1 in options.ini. Button is fully visible and active
only when the feature is intentionally enabled.
Rebuild required: MW4.exe (Release + Profile).
2. Remove cur_team_val conditional for team/skin slot assignment.
Previously, only one of o_team[k] or o_skins[k] was set depending on
cur_team_val at click time, but MAIL_SET_ROOKIE_MISSION propagates the
new game type asynchronously -- cur_team_val would not reflect the
file's GameType until the next frame, requiring a second click.
Fix: always set both o_team[k] and o_skins[k] unconditionally. The
mission launch code uses whichever is relevant for the active mode;
the other is harmlessly ignored. No rebuild (script-only).
Script calls callback(CTCL_GetAutoSlotInt, k, 0/1/2/3) where 0-3 are
integer literals. The script engine passes literals as (void*)N directly
(not as pointers), so INTPARM(1) = *((int*)data[1]) dereferences NULL
when field=0, producing the 'Attempt to read from NULL' STOP.
Fix: VALUEPARM(1) = (int)data[1] reads the value without dereferencing.
k (data[0]) remains INTPARM because it is a script variable (passed as
a pointer to the variable's storage, not a literal).
Also add exists(@ConLobbyMission@) guard before MAIL_SET_ROOKIE_MISSION
for defensive safety if the sub-script is not running.
Rebuild required: MW4.exe (Release + Profile).
options.ini [automaticmode] section:
automaticmode=1
automaticfile=c:\path\to\config.ini
Right-click was considered then dropped in favor of a dedicated button
at 467,510 (below Pick Cond., left of Reprint).
C++ (MW4Shell.cpp):
- SAutoFileSlot struct + g_aAutoSlots[16], g_bAutomaticMode, g_szAutomaticFile globals
- [automaticmode] ini read at StartUp
- CTCL_LoadAutoFile: checks file exists, reads [mission] page into existing
g_nRookieXxx globals + [slot0]..[slot15] pages into g_aAutoSlots[]; returns 1 if loaded
- CTCL_GetAutoSlotName(out_str, k): pilot name for slot k
- CTCL_GetAutoSlotMech(out_str, k): mech display name for slot k
- CTCL_GetAutoSlotInt(k, field): Type/Team/Skin/Decal for slot k (fields 0-3)
- Register/unregister all 4 callbacks in StartUp/ShutDown
Script (ConLobby.script):
- o_load_file button at 467, 510
- Handler: CTCL_LoadAutoFile -> if loaded, sends MAIL_SET_ROOKIE_MISSION to
ConLobbyMission (game options), clears all slots, then applies per-slot data
in a loop (pilot names, mech by display-name lookup in allowed_mechs[], team,
skin, decal). USE_ALLOWED_MECHS/non-ALLOWED_MECHS both handled via #if.
File not consumed (stays on disk); external app overwrites for next load.
Rebuild required: MW4.exe (Release + Profile).
MW4Shell.cpp:
- CTCL_DefaultHostSetup (non-coop): replaced hardcoded
Environment.NetworkMaxPlayers=16 with
params->m_maxPlayers + (CTCL_GetTeslaCountAll() - CTCL_GetTeslaCount())
so DirectPlay reserves one extra slot per installed cameraship.
CTCL_GetTeslaCountAll() - CTCL_GetTeslaCount() = camera-only seat count.
- SetNetworkMissionParamater / PLAYER_LIMIT_PARAMETER: applied the same
camera-slot formula when the host changes the player limit at runtime.
Also restored the gos_NetServerCommands(gos_Commend_UpdateMaxPlayers)
call (was accidentally dropped) and the missing break that caused
fall-through into JOIN_IN_PROGRESS_PARAMETER.
- COOP branch: no change (capped at 9+bots; camera seats not needed there).
ConLobby.script:
- Raised the launch-guard cap from nTempPlayerCount > 16 to > 17,
allowing the 17th connection (the cameraship) to not trigger the
'Too many player/bots' error.
MySQL database export (dbexport.h / dbexport.cpp):
- New files dbexport.h / dbexport.cpp implement late-bound MySQL export.
libmysql.dll is loaded at runtime via LoadLibrary/GetProcAddress so no
MySQL SDK is required at compile time; the app runs normally if the DLL
is absent.
- After each print job, match data is exported to a MySQL server before
PrintDlg() is called: one row in 'match', one row per player in
'player_result', one row per attacker/victim pair in 'pvp'. An optional
'event' table records every individual SRecScore entry (off by default).
Tables are created automatically (CREATE TABLE IF NOT EXISTS) on first
connect.
- Config stored in mw4print.ini (app directory), section [MySQLExport]:
Enabled, Host, Port, Database, Username, Password, ExportEvents.
- Config loaded at startup (OnCreate); DB_LoadConfig() / DB_SaveConfig().
- Connection timeout set to 5 seconds so the app does not hang if the
server is unreachable.
- libmysql.dll (MySQL Connector/C 32-bit) added to Gameleap/mw4/ so the
deploy script copies it to MW4/ alongside mw4print.exe.
Database Settings dialog (File > Database Settings... / Ctrl+D):
- MFC dialog: enable checkbox, Host/Port/Database/Username/Password fields,
Export Events checkbox, Test Connection button with live status label,
OK/Cancel. OK persists settings to mw4print.ini immediately.
Configurable banner text (File > Banner Setting...):
- The 'WWW.MECHJOCK.COM' URL string printed at the bottom of every score
sheet is now configurable. Stored as BannerText= in options.ini under
[battle tech print] (same section/file as the other print layout params).
File > Banner Setting... opens a dialog to edit it; OK saves to options.ini
and takes effect on the next print job with no restart needed.
Default value is the original MECHJOCK string if the key is absent.
Incremental Release + Profile builds (0 errors) picking up the
CRIOMAIN.CPP UpdateThrottle change; rel.bin\MW4.exe and MW4pro.exe
deployed to MW4\. Build logs in build-env\build_pr4_*.log.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Removes the if(lT!=0) guard in UpdateThrottle that made an exact-zero
throttle reading keep the previous throttle value; adds a negative
clamp. Zero now falls into the deadzone branch -> ZERO_THROTTLE.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
-tbaud <rate> (9600-921600) overrides the COM1 baud rate while keeping
old-RIO (type 0) protocol behavior unchanged; independent of -trio.
SetupComm buffers 2/2 -> 1024/1024 only when the override is active.
Rebuilt Release + Profile (0 errors), deployed rel.bin\MW4.exe to MW4\.
run-firestorm driver: game-start now takes optional extra args.
CLAUDE.md: branch notes incl. the CP949 comment-encoding hazard
(mw4 sources must be edited byte-safely).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
FS507D_20161015 release analysis wrap-up (drop itself is gitignored; art-review
folder kept local for review):
- Recovered the only assets our tree lacked: 13 hsh HUD/radar/mech bmps and the
two 5.07D lobby decals (decal_46/47.tga, extracted from release props.mw4 via
a ported gos_LZDecompress).
- ResourceImagePool.cpp: missing-texture placeholder is now LAB_ONLY (editor
keeps degraded mode); Release restores the original fatal STOP. Release +
Profile rebuilt, 0 errors.
Console script reconciled:
- ConLobby.script.new ("BattleTech Console V5.0.7Df", newest revision anywhere)
promoted to Content\ShellScripts\ConLobby.script; .new removed; stale loose
deploy copy removed. Verified in-game (console title shows V5.0.7Df).
- Corrected CLAUDE.md: the release never "renamed" the console to
ComputerPlayer.script -- the resource packer stores script contents under
alphabetically skewed entry names (runtime resolves the same pairing).
Packer quirks documented (stale entry carry-forward on incremental builds,
name/content skew in directory sweeps).
Mechlab bug fix (first FireStorm bug hunt):
- New-Mech dialog showed blank rows for Wolfhound/Zeus and crashed (KERNELBASE
read AV) when creating a Zeus. Root cause: newmech in chassis.script created
its Type droplist without setting $$m_listBoxSize$$, so capacity defaulted to
60 while 65 chassis were written in -- OOB script-array writes. Fixed by
sizing the list from $$m_chassisCount$$. Latent stock-MW4 bug armed when the
FireStorm roster passed 60 chassis. Verified: Zeus variant creates cleanly.
props.mw4 fully repacked (decals + promoted console + mechlab fix, junk
.new/.org entries gone); game deploy refreshed at MW4\. Gitignore: FS507D drop
and player-created MW4\Resource\Variants.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Complete disaster-recovery snapshot: engine/game source, game data assets,
VC6 toolchain + DX SDKs, build outputs, deployed game, and _UNUSED archive.
Large binaries in Git LFS; text preserved byte-for-byte (core.autocrlf=false,
no eol attributes). See RECOVERY.md for the one-clone rebuild procedure.
dicion
CydandClaude Fable 5