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>

RELEASE-NOTES-5.1.0b_RC1.html

@@ -168,11 +168,34 @@ with no dgVoodoo2 at all, using every available configuration. Modern Windows on
 display at a time to take exclusive fullscreen control, so the extra MFD panels are refused.
 Windows XP allowed it; Windows 10 does not. dgVoodoo2 works around this. There is no setting
 or switch that avoids it.</p></div>
+<h3><code>-tident</code> -- find out which monitor is which</h3>
+<p>Before using <code>-tmon</code>, use this to find out what numbers to type:</p>
+<pre><code>MW4.exe -tident
+</code></pre>
+<p>Every monitor fills with a colour and shows, in large text, the number to use for it. Something
+like:</p>
+<pre><code>              3
+        use 3 in -tmon
+    device 2   currently: main
+</code></pre>
+<p>Walk the pod, write down what each screen says, then set <code>-tmon</code> in the order
+<strong>main, radar, MFD 1, MFD 2</strong>. The game exits on its own when the time is up -- it does not start
+a mission, and it does not change any display setting. The display lasts 20 seconds by default;
+<code>-tident 45</code> gives you longer, and anything from 3 to 120 seconds is accepted.</p>
+<div class="note"><p><strong>Why this exists.</strong> The monitor numbers Windows shows in Display Settings <strong>cannot be read by
+any program</strong> -- Windows simply does not make them available. They often happen to match the
+numbers <code>-tmon</code> wants, but on some machines they do not, and there is no way for the game to
+tell the difference. This is the same reason Windows gives you an <em>Identify</em> button instead of
+just telling you. <code>-tident</code> is the game's own Identify.</p></div>
+<p><strong>Do not read monitor numbers off the Windows Display Settings screen and type them into
+<code>-tmon</code>.</strong> That is the single most common way to get a wrong or non-working display setup, and
+it can look like a hardware fault. Use <code>-tident</code>.</p>
 <h3><code>-tmon</code> -- fix monitors coming up in the wrong order</h3>
 <p>If your panels appear on the wrong physical monitors, you can assign them explicitly, in the
 order <strong>main, radar, MFD 1, MFD 2</strong>:</p>
 <pre><code>MW4.exe -tmfds 4 -tmon 1,2,3,4
 </code></pre>
+<p>Use the numbers <strong><code>-tident</code> showed you</strong> (see above), not the numbers in Windows Display Settings.</p>
 <p>Use <code>0</code> in any position to leave that one on automatic -- <code>-tmon 2,1,0,0</code> swaps only main and radar.
 <strong>Leave the switch off entirely and everything is detected automatically</strong>, which is correct on
 most pods.</p>
@@ -223,6 +246,18 @@ ever need to force it, ask and it can be added.</p>
 <p>If a display comes up in the wrong place, check <code>gos-displays.txt</code> next to the game (see
 section 8). It lists every display found, which role each was given, and whether each <code>-tmon</code>
 position was accepted or ignored.</p>
+<h3>Two panels on one monitor -- now reported</h3>
+<p>If <code>-tmon</code> accidentally puts two things on the same monitor, the second one cannot start: the
+first already has that display. Previously this produced a confusing DirectDraw error naming
+neither of them. <code>gos-displays.txt</code> now says so plainly:</p>
+<pre><code>*** CLASH: main  and mfd2  are BOTH on device 0 ***
+</code></pre>
+<h3>Panels are now released correctly when the display mode changes</h3>
+<p>A fault that could stop the MFDs working after the game changed display mode, or recovered from
+another program taking the screen. The panels were being re-opened without the previous ones
+being closed first, so they collided with themselves. Most pods never saw it; it showed up
+reliably on machines where one of the panels was on the monitor Windows treats as primary.</p>
+<p><strong>Applies automatically.</strong> No configuration needed.</p>
 <hr>
 <h2>5. 'Mechs and content</h2>
 <h3>Six rookie 'Mechs instead of four</h3>
@@ -330,6 +365,16 @@ and it costs nothing when unused.</p>
 <p>When display problems occur, the game now writes <strong><code>gos-displays.txt</code></strong> next to the exe listing
 every monitor it found, which role each was assigned, and the exact reason any panel failed to
 start. Previously such failures were completely silent. Include this file with any display fault report.</p>
+<p>The log now follows the whole start-up sequence in order: what Windows reports is attached, what
+the game found, how it matched the two up, which display it chose for each role and why, and what
+each <code>-tmon</code> position did. Near the end it prints the monitors in left-to-right order with the
+number to use for each -- the same numbers <code>-tident</code> puts on the screens:</p>
+<pre><code>  Desktop arrangement, left to right (compare with Display Settings):
+    position 1 : device 0 -&gt; \\.\DISPLAY1  800x600 at 0,0   [WINDOWS PRIMARY]
+    position 2 : device 3 -&gt; \\.\DISPLAY4  640x480 at 800,122
+</code></pre>
+<div class="note"><p>The file is rewritten every time the game starts. If you have a failure worth reporting, copy
+the file before launching again.</p></div>
 <hr>
 <h2>9. New command line switches at a glance</h2>
 <table>
@@ -347,6 +392,11 @@ start. Previously such failures were completely silent. Include this file with a
 <td>Existing MFD mode unchanged</td>
 </tr>
 <tr>
+<td><code>-tident [secs]</code></td>
+<td>Show each monitor's number on the monitor itself, then exit. Use this to work out what to put in <code>-tmon</code></td>
+<td>Game starts normally</td>
+</tr>
+<tr>
 <td><code>-tmon a,b,c,d</code></td>
 <td>Force monitor order: main, radar, MFD1, MFD2. Positions 3 and 4 apply only to <code>-tmfds 4</code></td>
 <td>Automatic detection</td>
@@ -399,6 +449,8 @@ start. Previously such failures were completely silent. Include this file with a
    mode. Only console mode, on a single display, does without it. Windows XP pods never
    need it.</li>
 <li>Launch and confirm the console lobby reads the new version.</li>
+<li>If your pod uses MFDs or a cameraship, run <code>MW4.exe -tident</code> once and check each monitor
+   shows the role you expect. If any are wrong, note the numbers shown and correct <code>-tmon</code>.</li>
 <li>Play one mission end to end before putting the pod back into service.</li>
 <li>Optional: add <code>[automaticmode]</code> and <code>[RookieMission]</code> to <code>options.ini</code> if you want the new
    Load File button or custom rookie missions.</li>