a57be4bd126b069e3cf99a93c5acd6fda4a07d53
112
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 
|
a57be4bd12 |
Add sync-from-windows.sh to pull build outputs back from the build machine
sync-to-windows.sh pushes sources out; there was no inverse, so every build
had to be retrieved by hand. This pulls back only GENERATED artefacts:
the linked output dirs (rel/dbg/pro/arm/ice.bin), the per-project VC6
intermediates, packed Resource/*.mw4 + *.dep, the MW4/ deploy, the binaries
deployed into Gameleap/mw4, and the build logs. Source, content and assets
are never pulled, so a stale copy on the build machine cannot clobber local
edits made since the last push.
Two things it has to get right, both found by running it:
It does not use rsync -a. The CIFS mount reports every file as 755 while git
tracks these as 100644, so preserving permissions would flip the exec bit on
every file pulled -- a spurious mode change on ~2000 paths. It uses
-rlt --chmod=F664,D775 instead. Verified: 1994 files pulled, 0 mode changes.
It excludes dgVoodoo2 from the MW4/ deploy (DDraw/D3D8/D3D9/D3DImm.dll,
dgVoodoo.conf, dgVoodooCpl.exe). That is a Win10/11-only prerequisite which
must never enter the repo because it breaks the XP pods; it was removed
deliberately in
|
||
|
|
42fe0a7b6a |
Update the six chassis STATUS files to record what was installed
These are the per-chassis completeness trackers, and they still described the
pre-install state: header said STAGED, jenner2c listed jenner_2c.* filenames
that no longer exist, and every one carried the "REVIEW MOVEMENT TYPE" item
that has since been decided.
Each file now has three sections. "installed" lists exactly what landed for
that chassis and what is shared with the other five. "applied" records the
data decisions and, for dasher and marauder, records that nothing was changed
and why - a deliberate no-change is a result worth tracking, not an omission.
"still to do" keeps the registration steps, renumbered without the settled
movement-type item, and adds a final step to delete the STATUS file once the
chassis is registered.
Per-chassis notes worth having written down:
- dasher is the only one that added zero textures.hint pages; it reuses the
existing @adas0-5 skins, footsteps and the Dasher_destroyed wreck.
- dasher and marauder keep LeftJumpJetSiteName=';' as decompiled, where our
own five LEGMOVETYPE chassis leave it empty. Inert while CanLoadJumpJets
is No, and recorded as a residual rather than quietly edited.
- jenner2c is the only one of the six with its own animscript; the other
five borrow dragon, hauptmann or loki.
- jenner2c's decision block now records that our copy was deleted rather
than overwritten, and why.
STATUS files are LF-only and stay that way; they are notes, not engine input.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
|
||
|
|
8e859007c8 |
Author the two generic HUD images for the six new chassis
Decisions 1 and 2 settled on one shared damage doll and one shared target-MFD tile for all six chassis. V4H supplied the two 512x512 dolls (installed in the previous commit) but neither of these, so both are ours. Content/textures/HUD/generic.tga (128x128 RGBA) is the in-cockpit doll. It is an exact 4:1 downscale of hsh/hud/generic.bmp, alpha carrying the zone mask and RGB flat shading with a one-pixel dark edge. The doll is exactly 4x this size, so keeping its layout means the cockpit texuv/offset rows are the doll rectangles divided by four -- no new coordinate authoring in the registration phase. Header is byte-for-byte the shipped shape: type 2, 32bpp, 65580 bytes. hsh/MFD/generic.bmp (120x120, 8bpp) is the target-MFD tile: a whole-mech front silhouette composed from the doll's own eight zone blobs (two legs, two arms, two side torsos, centre torso, head) rather than drawn from scratch, so it stays consistent with the damage doll used for the same chassis. Structure matches hsh/MFD/annihilator.bmp (8bpp, 1078-byte data offset). Also adds the [hud\generic] page to textures.hint, held back from the previous commit until the texture existed so a repack could not reference a missing source. textures.hint is now 4747 pages, 46 of them new, still pure ASCII with consistent CRLF. Note the cockpit texture is deliberately flat-shaded rather than a rendered mech; it reads correctly and is zone-accurate, but it is placeholder-grade next to the hand-painted per-chassis art and can be replaced without touching any coordinates. Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com> Co-authored-by: GitHub Copilot <copilot@github.com> |
||
|
|
a67d1c00d2 |
Install six V4H chassis as content assets (no registration yet)
Lands the art and data for Champion, Dasher, Griffin, Jenner IIC, Marauder
and Thunderbolt. Nothing is registered in core.build, the code arrays or the
shell scripts yet, so this commit is inert at runtime: packing is manifest
driven, the editor never enumerates Content\Mechs, and deploy drops Content\*.
The one exception is textures.hint, which is not inert -- textures.build has
no explicit .tga lines and packs via texturepool=textures\textures.hint, so
these pages will be picked up by the next textures.mw4 repack.
Contents:
- 11 chassis/wreck folders (658 files), 30 skin TGAs, 15 footstep TGAs
- 6 mech portraits (800x250, 24bpp; hsh/Mechs already mixes 8/24bpp)
- generic damage dolls into hsh/hud and hsh/radar/hud
- 45 textures.hint pages, copied verbatim from the Annihilator template
(30 skin mip pages + 15 footstep pages); Dasher needed none, its
@adas* and footstep pages already exist
Our own Jenner IIC was deleted first rather than copied over. Only 2 of its
84 files shared a path with the V4H set, so a copy would have left 78 stale
j2c_* files behind.
Decisions applied:
- jump jets: LEGJUMPMOVETYPE on champion, griffin, jenner2c, thunderbolt.
Dasher and Marauder declare CanLoadJumpJets=No and are left alone.
- Champion gets its own wreck instead of borrowing Loki's.
- Renames to canonical stems: jenner_2c.* -> jenner2c.*,
champion_stroyed.* -> champion_destroyed.*,
thunderbolt_destroyed.obb -> thunderbolt_destroyed_solid.obb.
All internal references updated to match.
- jenner2c.instance page [jenner_iic1] -> [jenner2c]. Every one of the 89
shipped mechs and all five staged siblings name the page after the
chassis; this was the sole outlier.
- thunderbolt.data footstep typo thunerbolt_dirt -> thunderbolt_dirt.
Verified: 1217/1217 file references resolve, 273 text files are pure ASCII
with consistent CRLF (the staged .data files arrived with an LF-only
Shadow={} block), no hint page duplicates a existing name, and all 278
binaries are stored as LFS pointers.
Still to come: Content/textures/HUD/generic.tga and hsh/MFD/generic.bmp must
be authored, then the [hud\generic] page, then the registration phase.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
|
||
|
|
c0daa2d920 |
Rewrite -tident: it painted one screen and left the rest blank
Reported from a four-monitor pod: -tident filled the main screen green and did
nothing to the other three.
The first version opened each DirectDraw device with DDSCL_NORMAL and drew on
that device's primary surface. Under DDSCL_NORMAL a secondary device's primary
surface is not that monitor's framebuffer - it either fails to create or
resolves to the desktop primary - so every device painted the SAME screen, each
over the last. Green is acrFill[1], so device 1 painted last and devices 2 and 3
failed outright, which matches the report exactly.
Now does what the Windows Identify button does: one borderless topmost GDI
window per monitor, positioned from the rectangle that device's HMONITOR
reports, with a real message pump so the windows actually receive WM_PAINT.
Nothing takes exclusive mode and no display mode is changed, which was the point
of the original design and still holds.
Two things fall out of the rewrite:
* Devices resolving to the same rectangle are now grouped behind one window
labelled with both numbers ("1 & 2") instead of overpainting each other. That
was a parked item in CLAUDE.md - it happens when a driver presents one monitor
as two devices, which is common on a single-screen test PC.
* A device reporting no HMONITOR is the primary display driver alias and now
falls back to the primary monitor rectangle rather than being lost.
gos-displays.txt gains a painted size/position line per monitor, a
"shares a monitor with device N" line, and a summary count, so a failure to show
anything is visible in the log instead of silent.
Docs: this matters because RC2 told pod owners to run -tident and it did not
work. Added to the RC3 change list, corrected the now-obsolete known issue about
single-monitor overpainting, and rewrote checklist section 12 to lead with the
regression - all four monitors must be covered.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
|
||
|
|
1684c3fbd2 |
Bump to V5.1.0b_RC3 and document everything since the RC2 build
The binaries and packages committed as RC2 in
|
||
|
|
6c8650fa98 |
mw4print: declare the -debug globals in mw4print.cpp
Release build failed:
mw4print.cpp(60) : error C2065: 'g_bDebugLog' : undeclared identifier
mw4print.cpp(61) : error C2065: 'DbgLog' : undeclared identifier
|
||
|
|
2dea177909 |
Fix the 2D target-MFD mech image: atlas capacity and two name mismatches
Three separate defects, all the same class: a per-mech image is looked up by string, the lookup misses, and nothing says so. Two were pre-existing and live; all three would have been inherited by the six V4H chassis. 1. The atlas was full, so mech id 64 showed another mech. HSH_CreateMFDTextures built a 1024x1024 texture holding one 128x128 tile per chassis, 8 per row, indexed by mech id -- 64 tiles for 65 names. Zeus (id 64) addressed y=1024. On write, DrawBitmapToSurface blits through a GDI DC, so the blit fell outside the clip rect and was discarded. On read, DrawTexture2 divides by tw/th, giving v = 1.000..1.117; the MFD device never sets D3DTSS_ADDRESS so it is D3D7's default WRAP, and that range wrapped to 0.000..0.117 -- exactly tile 0. Targeting a Zeus therefore displayed the Annihilator: not garbage, not black, a clean picture of the wrong mech, which is why it went unnoticed. The atlas is now 1024x2048 (128 tiles). Tile origins are unchanged and the draw derives UVs from pixel coordinates over tw/th, so the taller surface re-normalises automatically: all 64 other chassis sample byte-identical regions, and only Zeus moves -- from the Annihilator's pixels to its own. CreatePixelFormatTexture returns NULL on failure and SetTexture(0,NULL) renders untextured rather than crashing, so on a card that caps texture dimensions at 1024 an unguarded change would have silently blanked all 65 images. It now falls back to the original size, which restores exactly the previous behaviour, and says which size it got in gos-displays.txt. The granted height travels on the device as m_nMechAtlasH because mode 4 gives each of the two panels its own IDirectDraw7 and swaps the texture between them. A capacity guard now logs and skips a tile past the end instead of writing it off-surface and reading back someone else's picture, so this cannot recur silently when the roster grows. 2. Assassin II had no target image at all. |
||
|
|
42a66157ea |
Add PHOTOMODE.md: shelved design for automatic mech photo capture
Records the research behind a proposed capture mode for producing clean head-on
mech renders as source art for the damage paper dolls. Nothing is implemented;
this exists so the investigation does not have to be repeated.
The key finding is that the capture already exists and ships. MechView
(-mechview / -mv, documented in -help) bakes a 25-frame turntable of the
MechLab mech into a 2048x2048 atlas and plays it back on the pod's radar screen.
That bake renders the mech alone, on a solid background, at stepped rotations,
and reads it out of the back buffer - which is exactly the capture wanted. It
just writes a texture rather than files, and is gated behind CTCL.
Two things confirmed from source that remove the main uncertainties:
- MechLab::UpdateDisplay() is only s_MechCamera->DrawScene(true), so the
capture draws no UI at all; and gos_SetupViewport already takes the
background colour as a parameter.
- MechLab exposes GetChassisCount() and SetMech(), so a batch mode can walk
the whole roster without any interaction.
Proposed shape is "MW4.exe -photoall": boots, writes photos\<chassis>.bmp for
all 65 chassis, exits. No hotkeys or new UI. A new MechLab tab was considered
and rejected - tabs need shell-script plus callback work, and the tab's own UI
would be on screen during the capture. Recommended route into MechLab is to
bypass the shell and construct it directly, as MW4Shell.cpp:4693 does, rather
than adding a shellStart mode.
The only genuinely new code identified is a ~40 line BMP writer; the tree has
no screenshot facility at all. Everything else is wiring together routines that
already run in the shipped game.
Open questions needing a real run are recorded: per-chassis camera framing, and
which yaw is actually head-on. Constraints noted: run windowed for 32-bit colour
(fullscreen is bitdepth 16), and refuse to arm when -mechview or CTCL owns the
render hook, since MW4Shell.cpp:1623 asserts a single owner.
All 21 source references in the document were verified against the tree.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
|
||
|
|
7d71d2a771 |
Regenerate the Atlas MFD paper doll from its Radar art
The Atlas was the worst-fitting mapping left in the tree at 0.795. Its Radar
sheet is detailed and correct, but its MFD sheet is a much cruder silhouette
with loose boxes and pieces that do not meet, so no coordinate edit could fix
it - the artwork itself was the limit.
Because the two authoring pipelines are 1024->320 and 1024->400, the MFD is
exactly 0.8x the Radar. That makes the whole MFD sheet derivable: threshold the
Radar art, fill each component's interior holes to get a solid silhouette,
scale by 0.8, and scale texuv3/offset3 by the same factor. The pieces are then
spread outward from the CT centre so nothing collides, with CT and HD anchored
and each L/R pair mirrored exactly.
Reviewed adjustments on top of that: torsos and legs down 3, arms down 5, S2
down and right 3, and S1 reseated into the notch in RT.
Three things worth recording, all now in MFD-RADAR-MAPPINGS.md:
- Collisions must be tested on PIXELS, not bounding boxes. These silhouettes
are concave, so a piece can nest into a neighbour's notch while the boxes
overlap heavily. The S1 position that the box test rejected outright has
zero touching pixels.
- The right leg carried a hole the left leg did not. Replacing its art with a
horizontally flipped copy of the left leg makes them identical - 7612 px
each - and the placement is mirrored about the CT centre to match.
- The CT art under HD plus a 1px ring is blacked out, so the head reads as a
separate part rather than a patch on the torso. Verified as "CT pixels
within 1px of HD == 0".
S1 and S2 remain deliberately asymmetric (22x20 and 21x50, different places).
That is faithful to the Radar and to the chassis, which declares both specials
with their own erf assets.
atlas mfd 0.795 -> 0.956, no cross-piece clipping, no zone overlaps
whole tree 130 combinations, mean 0.950, minimum now 0.851
Note this replaces shipped art with generated art, unlike the earlier commits
which restored intent. It is reversible via git. Confirm it on a physical MFD
before applying the same technique to the other crude sheets (thor, loki,
bushwacker, solitaire and similar all sit in the 0.85-0.90 band).
Requires a Windows VC6 rebuild of MW4.exe; loose hsh art needs no repack.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
|
||
|
|
a26ff967d8 |
Repair the four broken Radar damage mappings; document the findings
The whole-tree audit after the previous commit found four Radar rows scoring
0.266-0.638 against their artwork, with boxes bounding blank space. All four are
chassis whose Radar sets J&J never delivered, so the rows had never been checked
against the art. They are pre-existing, not regressions.
With each chassis's MFD now correct, the Radar mapping is derived from it rather
than measured by hand: source boxes come from the Radar art's own connected
components, zone identity is matched from the MFD by normalised position plus a
size-consistency term, and placement scales each piece's ART CENTRE by ~1.25.
Two details that matter and are easy to get wrong. Position-only matching swaps
CT and HD, because a head and a torso can sit at similar normalised positions;
the size term fixes it. And scaling a piece's corner rather than its centre
misplaces it whenever the Radar piece is a different proportion from its MFD
counterpart - the Longbow's Radar CT includes the pelvis while its MFD CT does
not, which put CT 23px off centre until centre-scaling was used.
kodiak 0.266 -> 0.962
longbow 0.379 -> 0.959
argus 0.457 -> 0.956
fafnir 0.638 -> 0.963
Longbow additionally had a phantom special zone. The chassis declares no
Special1Internal, no joint_specialone and ships no *_specialone.erf, yet both
displays mapped S1. On the Radar that piece is the cockpit canopy - it matches
the CT's recess exactly - so it is remapped to HD and S1 is cleared. On the MFD
the S1 piece is the pelvis, a genuinely different component, and is deliberately
retained so the pelvis still renders; it simply never takes damage.
Whole tree after this change: 130 mech/display combinations, mean 0.949, median
0.955, minimum 0.795, none below 0.75 (was four).
MFD-RADAR-MAPPINGS.md is corrected and expanded. Three things it stated were
wrong and had caused real defects:
- it instructed storing the unexploded rect in texuv and the exploded origin
in offset, which is backwards and broke all 21 imported rows;
- it cited Behemoth MFD x=281 and Black Hawk Radar x=85 as intentional odd
coordinates to preserve, when both are transcription errors bounding blank
space (218 transposed, and a lost leading digit of 285);
- it recorded all 19 supplied BMPs as pixel-identical to the runtime art, when
all 19 differ by 6-35% because the art had never been installed.
Added: the handedness rule and its one-line assertion; the .damage cross-check
for special zones; the derivation method above; a catalogue of every verified
defect; and a tooling-pitfalls section covering blob thresholds hiding small
parts, unreliable hole detection on anti-aliased art, ink coverage not implying
correct placement, and overlap audits needing blob ownership to avoid ~107 false
positives. It also notes that generate_comparison_maps.py compares coord.cpp
only to the measurement files and never to the artwork, so it reported "19
exact" throughout every one of these failures.
Requires a Windows VC6 rebuild of MW4.exe and hardware testing on physical
MFD/Radar displays.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
|
||
|
|
ef4e014066 |
Install J&J MFD/Radar art and repair the damage-zone mappings
The STEP 13 install put the J&J data into coord.cpp with two systemic faults. Both are fixed here, along with eight transcription errors in the source files. texuv/offset were transposed. texuv2/texuv3 must hold the EXPLODED-layout box and offset2/offset3 the assembled placement point; the previous install had them the other way round, so no rectangle bounded its own artwork. Left and right were mirrored. The engine draws the doll facing the viewer, so the mech's right side must appear on the viewer's left for damage to map to the side actually hit. All 19 J&J sets were authored from the mech's own viewpoint. Confirmed by handedness audit: every display with J&J data was mirrored and every display without it was correct, so the fault came in with that import. The seven untouched displays (argus/fafnir/flea/gladiator/kodiak/longbow radar, hellspawn MFD) are original game data and are left alone. The art itself had never actually been installed - all 19 files differ from the supplied exploded BMPs by 6-35% of pixels, despite MFD-RADAR-MAPPINGS.md claiming they were pixel-identical. Sources are normalised to 512x512 8-bit greyscale to match the existing hsh format. behemothii art is resynced from behemoth since mech ID 12 inherits ID 11's coordinates. Source-data errors found and corrected during review: annihilator radar RA dropped digit in y1 iou 0.13 -> 0.96 assassin2 radar CT omitted the pelvis flare iou 0.51 -> 1.00 behemoth mfd LA x 281, transposed from 218 iou 0.25 -> 0.81 blackhawk mfd RT transposed leading pair iou 0.13 -> 0.99 blackhawk mfd HD box only 4px tall iou -> 0.80 blackhawk radar LT lost leading digit of x0 iou 0.27 -> 0.97 blackhawk radar LA box clipped 2 rows of art Fafnir mfd RT, LA boxes overlapped the neighbouring piece Plus 15 reviewed placement corrections: mirrored pairs levelled on art extents rather than box edges (box padding differs between mirrored pieces), Behemoth torso/arm alignment, Kodiak head moved into its cockpit slot, and Warhammer CT shifted 19px left, which also re-centred its head. All 19 sets were reviewed individually against the exploded sheet and the assembled result. Lowest set mean IoU is 0.851; arrays remain 65x11 and the file remains CRLF-only. Requires a Windows VC6 rebuild of MW4.exe (DXRasterizer.cpp includes coord.cpp) and hardware testing on physical MFD/Radar displays. MW4/hsh is deliberately not updated; it is regenerated by deploy-mw4.ps1 on the build machine. Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com> Co-authored-by: GitHub Copilot <copilot@github.com> |
||
|
|
1a0c178759 |
Repair MFD/Radar damage mappings for all seven borrowed-row chassis
Rebuilds texuv2/offset2/texuv3/offset3 for Archer, Ares, Battlemaster, Battlemaster IIc, Rifleman, Sunder and Victor. Every one had rows copied verbatim from another chassis, so the game sampled the wrong regions of their damage art and assembled the pieces into a foreign layout. Requires a Windows VC6 Release/Profile rebuild - DXRasterizer.cpp includes coord.cpp directly - plus a physical MFD/Radar hardware test. Result (mean IoU of each texuv rect against its own art) chassis MFD Radar archer 0.23 -> 0.85 0.19 -> 0.86 ares 0.51 -> 0.80 0.35 -> 0.81 battlemaster 0.14 -> 0.77 0.22 -> 0.91 battlemaster IIc 0.18 -> 0.83 0.25 -> 0.97 rifleman 0.14 -> 0.86 0.25 -> 0.87 sunder 0.28 -> 0.96 0.86 (radar was already correct) victor 0.33 -> 0.85 0.44 -> 0.86 mad cat (control, untouched) 0.88 / 0.88 Every remaining sub-0.55 entry in the file is now the separate 2026-08-07 J&J batch; no other chassis is misaligned. Scale of the errors ------------------- These were not small drifts. Archer's RT was 132 px wide and swallowed an arm plus a missile rack, where the actual rack is 46 px. Sunder's RT and LT pointed at y200-306, down in the legs, while the real racks sit at y38-144. Rifleman's CT indexed empty black space. Method ------ texuv comes from the art: each zone's rectangle is the bounding box of its component blob, x1/y1 + 1. Zone labels were confirmed visually chassis by chassis - an automatic classifier trained on the healthy rows reproduces only ~70% of them, because zone placement is conventional but not guaranteed. offset is the assembled-doll layout and cannot be derived from the art. It is built by starting from the exploded view (offset = the piece's own art position), freezing every y, anchoring CT, and sliding limbs horizontally until exactly 3 clear pixels separate neighbouring white pixels. Pieces are compared per row rather than by box edges, so boxes may overlap while the artwork stays clear. Two constraints are required or the solver misbehaves: a piece must never cross the CT centre line, and it must be free to move outward as well as inward. Radar is done first and the MFD derived from it, because the MFD art is a reduction of the radar art - scaling down is more accurate than scaling up. Every MFD y is taken as mfd_CT_y + (radar_y - radar_CT_y) * CT height ratio; reusing the MFD art rows directly puts the torsos ~27 px too high, as Victor showed. Per-chassis notes ----------------- - Battlemaster IIc is NOT the same art as Battlemaster despite appearances: 11 components vs 9, only 6 bounding boxes matching. The IIc fuses each arm with its weapon into a single piece and has no S2 at all. Its shared zones reuse Battlemaster's geometry unchanged; only the arms differ, anchored by their inner-top corner so the wider Clan arms grow outward. - Sunder's radar was already correct and is untouched; only the MFD moved. - Ares needed a different approach entirely - 16 art fragments for 10 zones, with both specials populated. The content data settled it: ares.damage lists the zone pages, ares.subsystems shows Special1 = 2 Beams and Special2 = 3 Missiles (identifying the six-tube rack as S2 and the two-bolt mount as S1), and Ares.contents shows CenterTorso owns both joint_centertorsorear and joint_hipbelow, so CT is the torso column and the hip merged. Detail rings inside the limbs are separate blobs but not separate zones, and were discarded. Head placement -------------- The CT art usually contains a purpose-cut slot the same size as the HD piece, so seating the head is a pure vertical move with x unchanged. Archer radar is exactly 13x11 for a 13x11 head. Where no slot exists - Rifleman radar, Victor - the head is placed from the counterpart display's proportional position instead. File remains CRLF-only; all four arrays verified at 65 rows x 11 zones. Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com> Co-authored-by: GitHub Copilot <copilot@github.com> |
||
|
dicion
|
9092b78dbf |
Correct STEP 14 deployment notes for the High Explosive fix
Record the actual packages for the two edited content files: HighExplosive.data is packed by core.build into core.mw4, not props.mw4, and weapons.script by props.build into props.mw4. build-resources.ps1 repacks on newer sources, so both are picked up automatically; the distinction only matters for selective repacks. Also document that restoring the NARC Beacon ammo-round display is an intended consequence of moving the highexplosive UI flag from ID 84 to 87, note that authored .subsystems loadouts need an explicit AmmoCount=1 because Weapon_Tool defaults ammoCount to -1, and record that a sweep of every weapon subsystem found High Explosive to be the only one whose starting-ammo formula truncated to zero. |
||
|
dicion
|
cd10398f71 |
Fix High Explosive firing from MechLab
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. |
||
|
|
3e48718330 |
Ignore Python bytecode; untrack two stale committed .pyc files
Adds __pycache__/ and *.pyc to the root .gitignore, and removes from version control the two bytecode files that had been committed under build-env/__pycache__/. The repo had no ignore rule for bytecode anywhere except MW4COMPARE/tools/.gitignore, which I added with the decompiler toolchain and which only covers that subtree. So running any script under build-env/ leaves an untracked .pyc behind; extract-mw4.cpython-312.pyc appeared while the decompiler was reusing build-env/extract-mw4.py for .mw4 container parsing. Untracked: build-env/__pycache__/replay-mr.cpython-314.pyc build-env/__pycache__/variant-to-subsystems.cpython-314.pyc These are generated artefacts, and the filename carries the interpreter tag - both are cpython-314 while this machine runs 3.12, so they are stale bytecode that no interpreter here will load and that will never be refreshed in place. Removed with `git rm --cached`, so both files remain on disk and simply stop being version-controlled; they regenerate on import as needed. Note a .gitignore rule does not affect already-tracked files, which is why the explicit untracking was required in the same change. Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com> Co-authored-by: GitHub Copilot <copilot@github.com> |
||
|
|
ad49ec708f |
Fix Rifleman MFD/Radar damage mappings; document the authoring pipelines
Repairs Rifleman's external MFD and Radar paper-doll source rectangles,
removes the dead commented-out Dasher rows, and records the canonical
authoring pipelines that had never been written down.
Requires a Windows VC6 Release/Profile rebuild - DXRasterizer.cpp
includes coord.cpp directly - plus a physical MFD/Radar hardware test.
The Linux workflow validates data and geometry only.
How the mapping was validated
-----------------------------
Ground truth is Mad Cat (ID 40), whose mapping is known-good in game and
user-confirmed. It establishes the invariant:
texuv2/texuv3 rectangles must bound the component blobs in the runtime
BMP, and the rule is exact - texuv = blob bounding box with x1,y1 + 1.
offset2/offset3 are on-screen placement and deliberately do NOT align to
the BMP; overlaying them against the art is meaningless.
Scoring each rectangle by IoU against the nearest art blob gives a clean
bimodal split: healthy chassis 0.78-0.99 (the single sub-0.5 zone is
normally HD, which has no blob of its own), broken chassis below 0.5.
Rifleman
--------
Its texuv2 row was a verbatim copy of Mad Cat's, so CT landed in empty
space, S1/S2 enclosed nothing and the legs hung off the art. Its texuv3
row was independently misaligned.
MFD 0.14 -> 0.86
Radar 0.25 -> 0.87
(Mad Cat control, unchanged: 0.88)
Zone labels were confirmed by eye, not inferred - an automatic classifier
trained on the 42 healthy chassis reproduces only ~70% of labels, because
zone placement is conventional but not guaranteed. HD is the small 3-bar
element under the centre torso, recovered by merging three sub-300px
fragments that the blob threshold had discarded.
Note the Radar layout is NOT a mirror of the MFD one: the legs move up
into the middle row and the wide S1 slab moves from the top to the
bottom. Radar S2 is now zeroed; the previous {186,10,312,78} had no
corresponding art.
Dasher rows
-----------
Dropped the four commented-out M_Dasher rows from all four arrays. Dasher
is not in the 65-ID roster, and a commented row is an active hazard: any
tool that parses these arrays or texturename[] without stripping comments
first picks it up and shifts every later chassis by one. That exact bug
produced a bogus "id41 madcat" during this work.
(huddamage.cpp still has a commented "hud\\dasher" entry - same hazard,
left for a separate change.)
MFD-RADAR-MAPPINGS.md
---------------------
Adds the project owner's verbatim MFD and Radar authoring pipelines as
the authority, plus the fact that coord.cpp is edited via the GameOS
project's "External Dependencies" folder in the VC6 IDE.
Records the distinction that caused a wrong diagnosis during this work:
Radar expands its canvas to 512 BEFORE the unexploded view is saved, so
Radar coordinates are measured in 512 space, whereas MFD expands to 512
AFTER all coordinates are recorded, so MFD coordinates are in 340 space.
Also MFD separates sections with a 4x4 black line while Radar outlines
with 2x2 white, both rectangles are measured on the unexploded view, and
the exploded view saved in indexed mode is the runtime BMP.
File remains CRLF-only; all four arrays verified at 65 rows x 11 zones.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
|
||
|
|
83478b7666 |
Add MW4COMPARE: .mw4 decompiler toolchain and V4H comparison harness
Tooling built to recover editable source for six 'Mech chassis that exist
in the parallel FS_Build_V4H build but not in this repo. Reverse-engineers
every compiled record type in the .mw4 package format back to the .data /
.instance / .subsystems / .damage / .contents / .torso / .engine /
.armature sources the content pipeline consumes.
Nothing here is wired into the game build. It is a standalone analysis
harness run from Linux.
Package format
--------------
"#VBD" container. Directory records are [len][name][FILETIME][origSize]
[storedSize][offset], payload base at dword 0x0C. A record is stored raw
when storedSize == origSize, otherwise LZW (9->12-bit LSB-first codes,
256=clear, 257=EOF, dict from 258), per Database.cpp:451.
GameModel records are flat /Zp4 structs following the C++ inheritance
chain Entity(0) -> Mover(28) -> MWObject(80) -> Vehicle(664) -> Mech(756),
1636 bytes total. CreateMessage records follow Replicator -> Entity ->
Mover -> MWMover -> MWObject -> Vehicle -> Mech from start=16 (the
undeclared Connection__Message header), ending at 341 and padded to 344.
tools/decompile/
----------------
datamap.py header-driven layout engine; CHAIN + ANCHORS
{Vehicle:664, Mech:756} assert the struct offsets
mw4msg.py CreateMessage reader/walker
data.py .data constants.py define/table symbol resolution
damage.py .damage contents.py .contents
smallmodel.py .torso + .engine instance.py .instance
armature.py / armature_parts.py .armature + armaturedata/armaturevideo
assembly.py joint hierarchy renderer
make_generic_doll.py builds generic MFD/Radar damage dolls
verify_*.py per-type round-trip verifiers
Verified round-trip across all 64 shared chassis:
.armature 2938/2976 pages .subsystems 7579/7585 keys
.data map 6071/6071 values .data trip 8291/8306 keys
.damage 6605/6605 keys .contents 7480/7480 keys
.torso+.engine 1280/1280 keys .instance 896/896 keys, 64/64 pages
armature_parts 1202/1202 .data, 1149/1202 .video
Layout-discovery lessons (documented in DECOMPILING.md)
-------------------------------------------------------
- Never let a field map be discovered by the values that verify it. A
value-matching pass reported 4288/4288 while mis-assigning 34 keys. The
map was rebuilt from header declaration order, anchored on uniquely
resolved fields.
- Read the factory, not the data. 12 .data fields and 5 Torso fields are
declared plain Stuff::Scalar but multiplied by Radians_Per_Degree in
Mech_Tool.cpp:889 / Torso_Tool.cpp.
- Strip typedefs before walking a header. A stray `typedef int AttributeID;`
masked a missing ClassID - two 4-byte errors cancelling out, caught only
by the ANCHORS assertion.
- A verifier that silently narrows its own input reports success. Braced
blocks must be hidden before splitting pages, replacing both CR and LF,
because a `Shadow={...}` block contains a line reading `[shadow]` and
splitlines() also splits on bare CR.
- NSWIZZLE is undefined, so the #else branch is live and orders members
differently. bool is 1 byte; char x[MaxStringLength] is 256.
- V4H carries stale Mech IDs (their Atlas is 5, ours 6), so 64 of 65 shared
chassis are off by one; --retarget-ids emits $(M_<Chassis>)/$(IDS_<Chassis>).
reports/ holds generated diffs. The two ~5 MB manifest-*.tsv intermediates
are gitignored; regenerate everything with run-comparison.sh.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
|
||
|
|
e088555b96 |
Fix content defects found while decompiling V4H packages
Three unrelated source-data bugs surfaced while round-tripping our own Content/Mechs tree against the decompiled V4H packages. All three were found because a decompiler verifier disagreed with the shipped data, not by inspection. Hellspawn / Sunder: unterminated section headers ------------------------------------------------- hellspawn.subsystems:101 [HeatSink10 -> [HeatSink10] sunder.subsystems:120 [HeatSink16 -> [HeatSink16] The notation parser keys a page on the bracketed name. With the closing bracket missing the page name is malformed, so that heat sink's block is not registered as its own page and its Model/ExecutionState/ InternalLocation keys are absorbed by the preceding page. Net effect: one heat sink silently missing from each mech (Hellspawn LeftTorso, Sunder LeftArm), and the preceding sink's location keys overwritten. CauldronBorn: undefined macro in TwistRadius -------------------------------------------- cauldronborn.torso:15 TwistRadius=$(OBSTUSE_TRADIUS) -> 100 OBSTUSE_TRADIUS is a typo and is defined nowhere in the define tables; the intended symbol is OBTUSE_TRADIUS (=140). An undefined macro does not fail loudly - the factory substitutes its own default - so this shipped for years as a silent fallback. Resolved to the literal 100 rather than $(OBTUSE_TRADIUS) because the compiled .torso record in the shipped package holds 100.0f, i.e. the factory default that has always been in effect. Using 140 would change long-standing behaviour; 100 preserves it and makes it explicit. Verified against the packaged record: verify_smallmodel now reports 1280/1280 keys. Lesson recorded: an undefined macro is not a build error here. Check what the compiled package actually holds before "correcting" a symbol name. Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com> Co-authored-by: GitHub Copilot <copilot@github.com> |
||
|
|
77e19a723c |
mw4print: document known issues and research notes
Captures all findings from the 2026-08-07 debugging session: print flow diagram, DoPrint error codes, which commits changed what, hypotheses explored/ruled out, and next steps once the -debug log is available. Co-authored-by: Claude Sonnet 4.6 (Anthropic) <noreply@anthropic.com> Co-authored-by: GitHub Copilot <copilot@github.com> |
||
|
|
3256c103a2 |
mw4print: add -debug flag for step-by-step diagnostic logging
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> |
||
|
dicion
|
10301ee5dd | Document external MFD and radar mapping work | ||
|
dicion
|
deafc2b01b |
Make Behemoth II inherit validated display mappings
Copy Behemoth's validated texuv2, offset2, texuv3, and offset3 rows from Mech ID 11 to Behemoth II at Mech ID 12. Both variants intentionally share the same external MFD and Radar geometry. Add an inherited-mapping assertion to the J&J comparison generator so future runs fail if any Behemoth II coordinate row diverges from Behemoth. Record the passing inheritance check in the generated summary. Document the inherited variant relationship and effective mapping count in MFD-RADAR-MAPPINGS.md. Compare hud/behemothii.bmp and radar/hud/behemothii.bmp against the corresponding Behemoth runtime assets. Both 512x512 grayscale images are already pixel-identical, so no hsh art files are copied or replaced. |
||
|
dicion
|
9755803949 |
Fix external MFD and radar damage mappings
Install the validated J&J coordinates for 19 external display sets across 13 chassis. Update all affected texuv2/offset2 and texuv3/offset3 rows while preserving the 65-mech positional layout and coord.cpp CRLF encoding. Add a reusable Pillow comparison generator, 38 red/green review maps, and a generated summary. The final audit reports 19 exact mappings, zero differences, zero input warnings, and seven display sets without complete supplied inputs. Normalize four unambiguous measurement transcription issues: Behemoth MFD LT 1742 to 174, Behemoth Radar CT punctuation and blank S2, and Fafnir MFD LL punctuation. Document the complete authoring and runtime workflow, including legacy tuple normalization, MFD/Radar scaling, odd-coordinate handling, canonical runtime names, pixel-versus-byte BMP comparison, validation checks, rebuild requirements, and the final installed-set inventory. Compare every supplied exploded runtime BMP against Gameleap/mw4/hsh. All 19 are already pixel-identical, so no runtime art files are replaced. |
||
|
dicion
|
13675c8cf4 | move important documentation to main folder. | ||
|
|
8bfaf9b9ad |
Publish V5.1.0b_RC2: rebuilt binaries, repacked props, RC2 documentation
RC2 build, verified to launch on the Windows box and copied back into the deployment at MW4/. Supersedes RC1 ( |
||
|
|
9bf49a8084 |
Bump console title to V5.1.0b2
Console lobby now reads "BattleTech Console V5.1.0b2", covering the 240-minute time limit work and the default-time fix on this branch. Also corrects the testing checklist, whose section 5 still asserted the V5.1.0b1 title and an 18-entry time list -- both would now fail on the bench. Added a check for the 7-minute default, which was silently landing on 4 before this branch's TIME_LIST_DEFAULT fix. Content only, no MW4.exe rebuild. ConLobby.script lives in props.mw4, so this needs build-env\build-resources.ps1 to appear in game. Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com> Co-authored-by: GitHub Copilot <copilot@github.com> |
||
|
|
136e2ff05c |
Extend MP mission time limit to 240 min (from LYLT 3514acf6)
Time-limit pick lists go to 23 entries: 1-15, 20, 25, 30, 45, 60, 120, 180, 240. Content + console only, no MW4.exe rebuild -- nothing between the dropdown and the mission timer clamps the value, and m_gameLength is 8 bits on the wire (MWApplication.cpp:790), so 255 was always the ceiling. Hand-applied rather than merged. LYLT reverted |
||
|
|
020dc04612 |
Add HD-AUDIO.md: multi-channel audio investigation notes
Research only, no code changes. Captures why the pods play in stereo and
what it would take to drive a 4-speaker (quad) rig on Win10/11.
Key findings:
- "Channels" is ambiguous in this codebase: 32 mixer voices (Adept splits
them 1 VO / 2 music / 1 Betty / 6 mechanical / 21 spatialized SFX) versus
the speaker output, which is hardcoded stereo at 22050 Hz.
- The blocker is DS3DALG_HRTF_LIGHT, a two-speaker head model, requested
unconditionally because dwFreeHw3DAllBuffers is always 0 on Vista+ where
DirectSound hardware acceleration no longer exists. hardwaremixing=true
is therefore inert, and the EAX reverb path has been dead since XP.
- GameOS has a full gosAudio_SetSpeakerConfig API that nothing ever calls.
GetSpeakerConfig also has no 5.1 case, so it returns 0 on such systems.
- Cheapest route is DSOAL (drop-in dsound.dll over OpenAL Soft) plus
hardwaremixing=true, which re-enables the existing hardware-3D branch
with no code change. Verified in source that Libraries.cpp:376 calls
LoadLibrary("dsound.dll") unqualified, and dsound.dll is not a KnownDLL,
so a local copy next to MW4.exe wins over System32.
- Same deployment rule as dgVoodoo2: per-machine Win10/11 prerequisite,
must NOT be committed, XP pods need the native dsound.dll.
Also documents the reverted fallback design (a third NO_VIRTUALIZATION
branch, a -tspk override and a gos-audio.txt trace) as a re-implementation
recipe, plus a verification plan and caveats.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
|
||
|
|
b3c5ecfe56 |
CLAUDE.md: note two -tident/clash-check gaps found on a single-monitor VM
Parked, not fixed. Diagnostics-only and impossible on a real pod, but the second one produces a confidently wrong "all clear" on exactly the kind of machine someone would bench-test with, so it is worth recording. Both stem from one physical monitor being exposed as two DirectDraw devices. The NULL-device merge is gated on NumMonitors>=2 - deliberately, it is a multi-monitor fixup - so a single-monitor box keeps the alias in slot 0 alongside the real device. 1. -tident overpaints itself. Device 0 (NULL alias) and device 1 (the real output) resolve to the same screen, so it paints red/"1" and then immediately green/"2" over the top. Observed on a VM as a brief flash before the second number appears. Behaving as written; there simply is not a second screen to paint. Should detect devices sharing an HMONITOR and label them together rather than painting sequentially. 2. The consistency check compares device INDICES, not resolved monitors. On the same VM it reported "No duplicate device assignments" while main -> device 0 (primary alias) and radar -> device 1 (\\.\DISPLAY49) were the same physical monitor - the exact collision the check exists to predict. Fix would be to treat a device with no HMONITOR as the Windows primary and compare resolved HMONITORs. Context for the VM in question: RDP session (Microsoft Remote Display Adapter, 1870x985) with the Microsoft Basic Render Driver and no real GPU, dgVoodoo2 masquerading as its default emulated NVIDIA device. MFD modes cannot work there regardless - only two DirectDraw devices exist and one of them is an alias. Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com> Co-authored-by: GitHub Copilot <copilot@github.com> |
||
|
|
22495d7245 |
Docs: research notes on making -window work for all display modes
Research only. Nothing implemented, nothing scheduled. Captured now so the
investigation does not have to be repeated when we come back to it.
New file: WINDOWED-MODE.md (repo root), indexed from README.md and the
CLAUDE.md next-steps list.
Goal being assessed
-------------------
Make -window work for every pod configuration, so a full pod (main + radar
+ MFDs, or a cameraship pair) can be tested on a single monitor as a set
of moveable windows. Target order: console (already works), cameraship,
-tmfds 1, -tmfds 4. -tmfds 3 deliberately out of scope.
Headline finding
----------------
-window does NOT fail for the MFD and cameraship modes - it silently
DISABLES them, and the reason is a single line:
MW4Application.cpp:1373
use_shgui = Environment.fullScreen ? 1 : 0;
use_shgui is the master switch for the entire secondary-panel subsystem
and is derived from fullscreen, so with -window it is 0 and
DXRasterizer.cpp:1131 never calls HSH_EnterFullScreen2(). No panel is ever
created. Console mode only appears to work windowed because it has no
panels to lose.
What the document covers
------------------------
* Why it behaves the way it does today, with the exact gating code.
* What already exists in our favour: the main display is a working
windowed reference implementation (primary + clipper + offscreen
backbuffer, presented with Blt); the clipper wrappers are already in
use; and none of the panel DRAWING code would change, because panels
render to an offscreen target and composite - they are indifferent to
whether the present is a Flip or a Blt.
* The six things that must change, with quoted code: decouple use_shgui;
windowed variants of CHSH_Device::InitFirst (DDSCL_NORMAL, no
SetDisplayMode, per-panel HWND) and InitSecond (plain primary + clipper
+ offscreen backbuffer, D3D device on the offscreen); one window per
panel; 8 Flip->Blt sites in WinMain.cpp; and explicit frame pacing.
* Frame pacing is called out as the item that will actually bite: sh_step
advances once per frame and drives MFD channel cycling, so an uncapped
windowed rig would not faithfully represent pod behaviour. Same root
cause as the known mechlab fast-spin bug.
* Reference tables: every panel class with its InitFirst location, device
slot and resolution; the SwapRightState member-swap mechanism that any
windowed work must keep intact; and the full lifecycle/gating map.
* Suggested phasing, with radar-only as the decisive Phase 1 experiment.
The risk that decides it
------------------------
Windowed D3D7 device creation is per-GPU, and this would need four
windowed devices in one process. Precedent runs both ways: the mission
editor hit DDERR_INVALIDOBJECT creating a windowed D3D device on Win11 and
needed DDrawCompat (STEP 8), while the game's own windowed main display
succeeds on the W4100. Nothing has proven four. If it fails, the fallback
means rewriting the panel RENDER path, not just its present - a
substantially bigger job.
Why this may be worth more than a test convenience
--------------------------------------------------
Windowed mode removes exclusive-mode contention entirely, which is the
whole reason dgVoodoo2 is currently mandatory for every multi-display
configuration on Windows 10/11 (STEP 10). If windowed panels work
natively, that is a route to dropping the dgVoodoo2 prerequisite WITHOUT
breaking the XP pods, since it needs no external DLL on either OS. Same
groundwork as the borderless-windowed migration already parked in STEP 10.
Note on citations
-----------------
All 22 file:line references were derived directly and verified to resolve
to the expected symbol. An exploratory pass had produced line numbers that
were substantially wrong (CHSH_Device::InitFirst reported at 717, actually
627; IsMultimonitorAvaliable at 2178, actually 2961), and a claim that the
radar renders at 480x640 rotated - the code passes 640,480 like the
others. Worth knowing before trusting generated citations in a document
intended to outlive the session.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
|
||
|
|
4e04fd1fb2 |
Displays: -tident identify mode, panel re-entry fix, desktop-order log
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> |
||
|
|
2e85cd2066 |
GameOS: full display enumeration trace in gos-displays.txt
Motivation ---------- A tester's 3-display Intel integrated-graphics box (main + 2 MFDs on the iGPU, radar on a USB adapter) failed MFD bring-up with the second MFD panel returning DDERR_EXCLUSIVEMODEALREADYSET, while the same build works on a W4100 and on a Quadro. The old report showed only the final device list and role numbers, which was not enough to tell whether the cause was device count, capability, index shifting, or a duplicate assignment. The report now traces every stage of display discovery in the order the game performs it, so the cause can be read off the file instead of inferred. What gets logged ---------------- * Header: executable path, full command line, and the requested -tmfds / -tmon values already converted from the 1-based command-line form to the 0-based DirectDraw indices the code uses. That conversion is an easy off-by-one to miss: "-tmon 1,..." means device 0. * Windows desktop topology via EnumDisplayDevicesA + EnumDisplaySettingsA - every \\.\DISPLAYn adapter, its friendly name, attached/primary state and current mode. Stated explicitly so it can be compared against the DirectDraw order, which is NOT the same ordering. * Stage 1, enumeration callbacks: each callback as it fires, with driver description, driver name, GUID, and the HMONITOR resolved through GetMonitorInfoA to \\.\DISPLAYn plus desktop rect and primary flag. Entries with no HMONITOR are named as the primary-display-driver alias, noting that NumMonitors is not incremented for them. * Stage 2, capability check: per device ACCEPTED (with assigned index and whether a HAL was found) or REJECTED. * Device table printed THREE times - before the NULL-device merge, after it, and final. Each entry shows description, driver, DeviceGUID, guidDeviceIdentifier, vendor/device IDs, hardware-rasterizer flag and its monitor. Followed by an adapter grouping listing which device indices belong to the same physical card, since guidDeviceIdentifier identifies the ADAPTER and not the output - which is precisely why a single card and a mixed iGPU + USB adapter setup enumerate differently. * Stage 3, the NULL-device merge: whether the NumMonitors>=2 guard passed, which device matched the primary's adapter GUID, and every index shift printed individually. If nothing matches, it says so loudly - slot 0 then remains the alias and any role pointed at device 0 lands on the Windows primary monitor. * Stages 4-7, role selection: span / main / radar / MFD searches, each printing the device chosen AND the reason every skipped device was skipped. Then the -tmon overrides, each showing what auto-detection had chosen and what the override replaced it with, or why it was rejected. * Final summary: role -> device -> physical monitor, plus a consistency check that reports two roles landing on one device as an explicit CLASH, with the explanation that the second panel will fail with DDERR_EXCLUSIVEMODEALREADYSET. That is the suspected failure on the Intel box and nothing in the old log pointed at it. Fixes ----- * Monitor/device desync: the NULL-device merge shifted DeviceArray but nothing tracked which monitor each slot drove. g_ahDevMonitor[] is now shifted in lockstep; without this every monitor attribution after a merge would be off by one, i.e. confidently wrong rather than absent. * HMONITOR is now retained. The Ex enumeration callback is the only place the device-to-monitor association is available and it was being discarded, so videoDevices gained an hMonitor field and BufferDevice takes it. Behaviour --------- No functional change. Every condition, code path and assignment is unchanged - only logging was added, plus the monitor-array shift above. -tmon still applies each slot independently and still does not reject duplicates; the duplicate is now merely visible. Whether to make it an error is a separate decision, pending test results. Cost ---- Startup only. Nothing added is reachable from the frame loop, so there is no runtime cost of any kind. Roughly 255 writes for a 4-monitor pod, at ~25-130 ms total on a warm cache - inside the noise of FindVideoCards() itself, which creates DirectDraw objects and enumerates every display mode per device. Worst case is antivirus on-access scanning of each CreateFile, which could reach ~1 s; a folder exclusion removes it. Lines remain open-append-close so the report survives a hard crash during panel init, which is exactly when it is most needed. gos-fps.txt is the buffered log; this one deliberately is not. Portability ----------- GetMonitorInfoA and EnumDisplayDevicesA are resolved with GetProcAddress and the MONITORINFOEXA / DISPLAY_DEVICEA layouts are declared locally, so nothing depends on the 1998 SDK headers carrying multimon support. If the APIs are unavailable the report degrades gracefully instead of failing to build. ENUM_CURRENT_SETTINGS is defined defensively. Testing ------- Not yet built. Requires a rebuild of MW4.exe (Release + Profile) as this is CoreTech GameOS. Note the report is truncated on every launch - a failing run's log must be copied before relaunching. Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com> Co-authored-by: GitHub Copilot <copilot@github.com> |
||
|
dicion
|
e912c58843 |
README: rewrite with project background and history
Add Background section covering what FireStorm is, the full VWE / BattleTech Center history from ESP (1988) through Tesla II FireStorm (2002) and community continuation, and a summary of V5.1.x changes since the 5.07D official release. Reorganize build instructions under a dedicated 'Building from source' heading. Demote Outputs / Design / _UNUSED from top-level headings to subsections under the layout section. |
||
|
dicion
|
07750da2fa | Delete daf52e2c-8107-4f40-88df-a2744c8861f6.mr | ||
|
|
24ce46ab6d |
Cameraship Map/Armor diagnostics: -tmr ladder, draw counter, CTCL type log
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> |
||
|
dicion
|
b40892910b | fix filename for db structure file to match the new naming convention. | ||
|
|
0f901f71d5 |
Release notes: document which -tmon positions apply in each MFD mode
-tmon has four positions (main, radar, MFD1, MFD2) but only the first two do anything in the spanned modes. Positions 3 and 4 write to the mode 4 MFD device slots, which -tmfds 1 and -tmfds 3 never read -- they drive both MFDs from one wide display instead. The switch accepts them either way, so an operator could reasonably assume they had taken effect. Also states what was previously undocumented: the spanned MFD display itself cannot be assigned with -tmon at all. It is chosen automatically as the first display advertising a 1280x480 mode, which is a distinctive enough signature that it normally lands correctly. Noted that it can be added if anyone needs to force it. Adds a per-mode table, a pointer to gos-displays.txt for diagnosing a display that lands in the wrong place, and a qualifier on the -tmon row of the switch summary. No code changes -- documentation only. Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com> Co-authored-by: GitHub Copilot <copilot@github.com> |
||
|
|
7fc9089aad |
Clarify dgVoodoo2 scope: any second display, cameraship included
The dgVoodoo2 requirement was written as an MFD-mode problem. It is not. The limitation is per SECONDARY DISPLAY, not per feature, so it applies to every mode that lights up a second monitor -- including cameraship mode, which uses two displays and no MFDs at all. Console mode is the only configuration that does not need dgVoodoo2, because it is single-display. This matches the code: IsMultimonitorAvaliable() returns false for _ECTCL_CameraShip, so cameraship falls through to IsSecondaryMonitorAvaliable() and the single-secondary mr_device path -- which is still a second exclusive IDirectDraw7, and therefore still refused by modern Windows for exactly the same reason as the MFD panels. Release notes updated in all three places it appears -- section heading and opening, the known-issues entry, and upgrade checklist step 4 -- so an owner running cameraship pods cannot read the requirement as "only applies to MFD setups" and skip it. CLAUDE.md STEP 10 and repo memory corrected likewise, since both stated the narrower "-tmfds 1/3/4" scope. Both release-notes formats regenerated; still plain ASCII with CRLF. Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com> Co-authored-by: GitHub Copilot <copilot@github.com> |
||
|
|
7f7f98d992 |
Release notes: soften dgVoodoo2 wording, note -tbaud is hardware-limited
Two wording corrections from the project owner, plus repair of three characters left mangled by the earlier CP949 encoding problem. 1. dgVoodoo2 known-issue entry. "This is a Windows limitation, not a bug we can fix" overstated it -- it reads as permanent. Replaced with a statement of what dgVoodoo2 actually does (works around a limitation on exclusive full-screen use of multiple displays on platforms after Windows XP) and that a future release may address it. The borderless-windowed design assessed in CLAUDE.md STEP 10 is exactly such a route, so leaving the door open is the accurate framing. 2. -tbaud. The notes implied any rate in the 9600-921600 range simply works. The software will set any of them, but the achievable rate is bounded by hardware at both ends: the serial UART in the pod PC and the RIO or replica RIO board. Added that, with the symptoms of an unsupported rate (garbled input, dropped buttons, no response) and the advice to step down. Without it an owner could conclude a high rate is broken in the game when it is the UART or board refusing it. Also repaired three leftovers from the CP949 encoding issue: two em dashes at ends of lines that the earlier pass missed because it only matched dashes surrounded by spaces, and the warning glyph on the MySQL export note, which had become a literal "??" and is now a WARNING: label. It renders as a styled warning callout in the HTML alongside the XP one, so both hazards look like hazards. Both formats regenerated and verified: 0 non-ASCII bytes, 0 remaining artefacts, 2 warning and 5 note callouts in the HTML. Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com> Co-authored-by: GitHub Copilot <copilot@github.com> |
||
|
|
a0331e78d2 |
Compiled Build 5.1.0b_RC1 Files
Deployed game tree copied back from the Windows build machine, containing the compiled 5.1.0b_RC1 binaries and every asset the deploy produces. 846 files: 21 added, 825 modified. Freshly built binaries: MW4.exe, Launcher.exe, autoconfig.exe, ctcls.dll, MissionLang.dll, ScriptStrings.dll, Language.dll and the rest of the runtime DLL set, carrying everything merged this cycle -- the 16-pilots-plus-cameraship launch fix, the MFD mode 4 split-display support and its stutter fix, -tmon, -tcoop, -fps, -tbaud, the Load File console lobby feature, configurable Rookie Mission, and the English Language.dll build. New in the deployment: - set-appcompat.bat / set-appcompat.ps1 -- the one-click AppCompat shim installer, now shipped by deploy-mw4.ps1 so any copy of an install can repair its own registration (the layer is keyed on the exe's full path). - libmysql.dll -- required by mw4print 2.0's MySQL export, late-bound at runtime. - Four hsh art files restored from 5.0.7D: MFD/assassin2.bmp, Mechs/battlemaster iic.bmp, Mechs/behemoth ii.bmp, Mechs/mad cat mkii.bmp. - banner.txt, dbstruct.txt -- mw4print banner text and the exported DB structure reference. dgVoodoo2 is included as MW4/dgvoodoo2_files/ -- deliberately in a subfolder and NOT alongside the executable. Nothing loads from there, so the files are available for a pod owner to install on Windows 10/11 without being active by default. This keeps XP pods safe: they use native DirectDraw, and having dgVoodoo2 loose in the game folder would break them. Do not move these files up a level in the repo. Runtime leftovers from testing on the build machine are included as well (DDrawCompat logs, DebugLog.txt, mw4-help.txt, two screenshots), consistent with this repo's stated purpose as a full disaster-recovery mirror in which nothing is excluded on purpose. All binaries and art are stored via Git LFS per .gitattributes; verified that MW4.exe, libmysql.dll, the dgVoodoo2 DLLs and the screenshots staged as LFS pointers rather than raw blobs. Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com> Co-authored-by: GitHub Copilot <copilot@github.com>firestorm |
||
|
|
1b931d5fb8 |
Correct dgVoodoo2 guidance: never ship it, XP pods must not have it
Two corrections from the project owner.
1. dgVoodoo2 must NEVER be added to the repo or the deploy script.
The pod fleet is mixed. XP pods use native DirectDraw and need nothing extra --
installing dgVoodoo2 on them BREAKS them. Only Windows 10/11 pods need it, and
only for the MFD modes. It is therefore an installed-per-machine, OS-dependent
prerequisite that the pod owner sets up, not a build artifact.
This reverses the recommendation added in the previous commit, which suggested
versioning the working dgVoodoo.conf and having deploy-mw4.ps1 place it. That
advice was wrong: it would have pushed a Win10-only dependency onto every XP
machine. dgVoodoo.conf and dgVoodooCpl.exe were removed in
|
||
|
|
10dab8f2d5 |
Add V5.1.0b_RC1 end-user release notes (markdown + HTML)
Release notes covering the 58 commits since
|
||
|
|
2f4ed244ea |
Fix -fps logger measuring its own overhead; buffer output, fix percentiles
First real run of -fps (222 seconds, 4-monitor bench, in-mission) showed a
rock-solid 60.0 fps average but a worst frame of ~24ms in 82% of seconds, with a
median of 24.4ms and a minimum of 23.2ms. That regularity was the tell: 60Hz vsync
intervals are 16.7 / 33.3 / 50.0 ms, so 24ms is not a multiple of anything and had
no business recurring once per second with that consistency.
Cause: the logger was measuring itself. The per-second line was written straight to
the file with WriteFile on the render thread, and the frame duration is recorded
BEFORE the line is emitted -- so the write's cost landed in the *next* frame's
measurement, which belongs to the next second's bucket. Result: exactly one
inflated frame per second, indefinitely. Holding the handle open (as the first
version did) was not enough; a single WriteFile is still several milliseconds when
something like antivirus is in the path.
Three fixes:
1. Buffered output. Lines accumulate in a 128 KB static buffer (~2000 rows, about
33 minutes at one row per second) and are flushed only when the buffer fills or
at exit via atexit(). A normal measurement session now performs no file writes
at all while running. Trade-off, deliberately accepted: a hard crash loses the
un-flushed tail. gos-displays.txt remains the crash-survivable log; gos-fps.txt
is a measurement instrument and must not perturb what it measures.
2. Meaningful percentiles. A "1% low" over 60 samples per second computes
nFrames/100 = 0, which was clamped to 1 -- so the column was literally
1000/worst_frame, i.e. the worst-frame column restated in different units.
Verified against the log: worst 24.1ms -> 41.5 fps, exactly the "1% low" printed.
Per-second is now a 5% low (worst 3 of 60), which is a number that actually
differs from the worst frame. True whole-session 1% and 0.1% lows are computed
at exit from a 0.5ms-bucket frame time histogram (2000 buckets, 0-1000ms) and
printed in a new session summary along with total frames, elapsed time, average,
and total hitches. The histogram gives exact-enough percentiles over an entire
session without retaining every frame time.
3. Carry-over. A single frame longer than one second (a level load: the log shows
4338ms and 4799ms frames) left the accumulator above the 1000ms threshold, so
the next few frames each emitted their own bogus one-frame row -- visible in the
log as rows reporting "1 frame, 1339 fps". The excess is now discarded.
Also adds #include <stdlib.h> to WinMain.cpp for atexit(); it was not reachable
through pch.hpp. GOS_FpsAtExit is declared __cdecl: GameOS builds with /Gz, which
makes __stdcall the default calling convention, but atexit() takes a __cdecl
callback -- without it VC6 rejects the call with C2664.
What the run did establish, and still stands: 60 frames per second sustained for
~150 seconds with no rhythmic multi-hitch pattern, so the mode 4 split-MFD stutter
fix (
|
||
|
|
9c67dddd83 |
Display diagnostics + -fps/-tcoop; native multi-monitor MFD ruled out
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
|
||
|
|
f402e5becc |
Add OPTIONS-INI.md reference
options.ini had no documentation. This documents every section and key, compiled by reading the actual read sites rather than by describing the shipped file, so that settings which look active but are not are identified as such. Covers [graphics options], [sound options], [special commands], [server], [joystick], [Cameraship Params], [Battle Tech Misc], [RookieMission] and [battle tech print], plus how the file is loaded, which parts the game writes back, and the per-role options-game/cam/mr variants. Notable findings, all verified against source: - The entire [network options] section is DEAD. None of connectiontype, connectionspeed, packetsize, defaultconnection, playericon or teamicon is read by any code; the connection type actually used comes from the multiplayer connection wizard. These are stock MW4 leftovers. - Several [Battle Tech Misc] keys have names that do not describe what they do, and the real meanings are now recorded: RuleBook sets g_nMechVariant, DawnWar sets g_nMechLabOp, BiggieSizeIt sets g_nMechPodNum (the console lobby's larger roster flag), and CanYouHearTheFootSteps sets g_nBlackMech. - The shipped options.ini misspells two keys. It contains secmissionreplay and secmissionreport, but the code reads SecsMissionReplay and SecsMissionReport. The shipped values are therefore ignored and the compiled defaults apply. - Three keys are read and then immediately overridden, so editing them does nothing: videodriverindex (device forced to 0), huddamagemode and hudtargetdamagemode (both forced false). Their GetEntry calls are commented out. - [special commands] killgame is a self-clearing kill switch: if true at startup the game rewrites it to false, saves options.ini and exits immediately. - maxplayers/maxbots are serialised to clients as 5-bit fields, so 31 is the maximum usable value; cross-referenced to RAISING-PLAYER-CAP.md. Also records why a typo produces no diagnostic: GetEntry returns false and the compiled default is kept silently. Page and key lookup were confirmed to be case-insensitive (NotationFile::FindPage lowercases; Page::FindNote uses _stricmp), so the capitalisation differences between the shipped file and the code are harmless -- the misspellings above are not. Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com> Co-authored-by: GitHub Copilot <copilot@github.com> |
||
|
|
308fe041d4 |
Make -help a complete command line reference
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> |
||
|
|
0009f868eb |
RAISING-PLAYER-CAP.md: sharpen the drop-zone wording
The previous correction overstated the case by implying the code reading was wrong outright. It was not. The engine really does place surplus 'Mechs on already-occupied spawn points -- two 'Mechs dropped on the same spot -- exactly as reading the code suggests. The only wrong part was the predicted consequence. The original draft said those players "silently fail to spawn". They do spawn; the collision system then pushes the stacked 'Mechs apart within a second or two, costing some minor contact damage, and play continues normally. Reworded Layer 7 and the known-traps entry to separate the two claims: the spawn-point reuse is real and code-predictable, the failure-to-spawn conclusion was not. Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com> Co-authored-by: GitHub Copilot <copilot@github.com> |
||
|
|
33c28cf816 |
RAISING-PLAYER-CAP.md: correct the drop-zone analysis
The original draft claimed that players beyond a map's available drop zones "silently fail to spawn", and called per-map drop-zone authoring the true gating task for raising the player cap. That was inferred from reading the code and is wrong. Corrected from real pod testing: when there are more 'Mechs than drop zones, the surplus 'Mechs spawn on top of each other. They clip and collide briefly, take some minor damage, then separate and play normally. It resolves itself within seconds. So a drop-zone shortfall is a quality-of-experience issue, not a functional failure. It does not block raising the cap and should not gate the schedule. Adding start points to busy maps is still worth doing eventually -- overlapping spawns are untidy and hand out free chip damage -- but it can happen at any point and never needs to be complete. Updated accordingly: the TL;DR table, Layer 7, the implementation order (drop zones moved from step 5 to last and marked optional), the verification checklist, and the known-traps list. The biggest remaining non-code task is now the lobby pod-grid and scoreboard layout rework. Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com> Co-authored-by: GitHub Copilot <copilot@github.com> |
||
|
|
a41dfb4aa8 |
Add RAISING-PLAYER-CAP.md reference
Captures the full audit of every player-count limit in the codebase, done while tracking down the "16 pilots + 1 cameraship" launch failure. Research only -- nothing in it is implemented. Key finding: the practical ceiling without a wire-format change is 31, not 32. m_maxPlayers and m_maxBots are serialized as 5-bit fields in NetMissionParameters, so 32 truncates to 0. This supersedes the "32" figure in the existing CLAUDE.md plan sections. Documents, with file references: - what is NOT a limit (Adept::Maximum_Players is 255, connectionID is a BYTE, DirectPlay imposes nothing, and there is no 32-bit player bitmask) - the 5-bit serialization ceiling and what widening it would cost - the compiled defaults in CTCL_DefaultHostSetup that actually gate connections - the CTCL roster arrays, including that g_aPlayerInfos[20] has NO bounds check in CTCL_AddPlayer and that ctcl.h is duplicated across ~6 directories - MAX_LANCEMATES 16 for bots - the lobby script constants and the pod-grid UI work - scoreboard/radar/review layout work - per-map drop zones, which is the real gating task and produces silent spawn failures when short - the O(n^2) replication cost, reframed as verify-don't-assume on modern hardware Also records the failure signatures to expect, so a future attempt recognises them quickly: silent launch hang from a count mismatch, silent non-spawn from missing drop zones, and 5-bit truncation looking like "max players became zero". Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com> Co-authored-by: GitHub Copilot <copilot@github.com> |