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>

RAISING-PLAYER-CAP.md

@@ -21,7 +21,7 @@ see "Why 31, not 32" below.
 | Hard ceiling if you also widen one serialized field | 255 (engine arrays are sized 255) |
 | Is 16 an engine limit? | **No.** It is a set of independent constants and one 5-bit field |
 | Biggest *code* task | CTCL roster arrays + lobby UI layout |
-| Biggest *non-code* task | **Per-map drop zones** ? most maps only define ~16 |
+| Biggest *non-code* task | Lobby pod-grid / scoreboard layout. Drop zones are **not** a blocker ? see Layer 7 |
 | Does netcode bandwidth block it? | Almost certainly not on modern hardware; verify, don't assume |
 
 ---
@@ -171,16 +171,25 @@ teams is beyond the 4-bit `m_teamCount` limit of 15, so they are fine.
 These are cosmetic and non-blocking: 31 players can connect, spawn and play with an ugly
 scoreboard. Defer.
 
-### Layer 7 ? Map content (**the true gating task**)
+### Layer 7 ? Map content (drop zones: a polish item, NOT a blocker)
 
-Every MP map used at high player counts must define **¡Ã N drop zones / start points**. Most stock
-maps define ~16. Players beyond the available start points **silently fail to spawn** ? no error.
+Most stock maps define ~16 drop zones / start points.
 
-This is per-map authoring work in the mission editor (`Gameleap\mw4\run-editor.bat`), completely
-independent of the code changes, and it is the item most likely to dominate the schedule.
+**This was previously assumed to be the gating task. It is not.** Verified empirically on real
+pods: when there are more 'Mechs than drop zones, the surplus 'Mechs **spawn on top of each
+other**. They clip and collide for a moment, take some minor damage, then separate and play
+normally. It resolves itself within seconds.
 
-Audit approach: enumerate drop zones per map, produce a table of map ¡æ start-point count, and
-decide which maps are certified for 31-player play.
+So a drop-zone shortfall is a **quality-of-experience issue, not a functional failure**. It does
+not block raising the cap, and it should not gate the schedule.
+
+Worth doing eventually for the maps that see the most high-count play ? an overlapping spawn is
+untidy and hands out free chip damage ? but it can happen any time, before or after the code work,
+and it never needs to be complete.
+
+Audit approach if/when you want it: enumerate drop zones per map, produce a map ¡æ start-point
+count table, and add start points to the busiest maps first in the mission editor
+(`Gameleap\mw4\run-editor.bat`).
 
 ### Layer 8 ? Network performance (verify, don't assume)
 
@@ -201,18 +210,19 @@ design suggests none exist, but grep for it.
    add the missing bounds check in `CTCL_AddPlayer`. Nothing else is safe until this is done.
 3. **Layer 2** ? raise the compiled defaults. Rebuild `MW4.exe` (Release + Profile).
 4. **Layer 4** ? decide and implement the bot cap.
-5. **Layer 7** ? audit maps for drop zones; author more on the maps you care about. Runs in
-   parallel with everything else and will take the longest.
-6. **Layer 5** ? lobby UI rework (roster rows, pod grid, launch guard).
-7. **Layer 6** ? scoreboard/radar/review polish.
-8. **Layer 8** ? one live load test.
+5. **Layer 5** ? lobby UI rework (roster rows, pod grid, launch guard).
+6. **Layer 6** ? scoreboard/radar/review polish.
+7. **Layer 8** ? one live load test.
+8. **Layer 7** ? optional: add drop zones to the busiest maps. Non-blocking; surplus 'Mechs
+   already spawn stacked and separate on their own.
 
 ## Verification checklist
 
 - [ ] Rebuild clean (0 errors) in Release and Profile
 - [ ] Host a game; lobby shows the new slot count and the launch guard accepts it
 - [ ] Player N connects (watch `Environment.NetworkMaxPlayers` ¡æ DirectPlay `dwMaxPlayers`)
-- [ ] All N players actually **spawn** on a map with ¡Ã N drop zones (this is where it will fail)
+- [ ] All N players actually **spawn** (surplus 'Mechs stacking on shared drop zones is expected
+      and self-correcting ? not a failure)
 - [ ] Cameraship still connects on top of the pilot cap (regression from the 2026-07-24 fix)
 - [ ] Bots fill correctly to the intended bot cap, and `g_nBOTs` matches connected lancemates
       (mismatch = silent infinite "loading", the classic failure mode)
@@ -230,6 +240,7 @@ design suggests none exist, but grep for it.
   `nLaunchState = 3` forever because `CTCL_CheckServerReady` never sees
   `nCount == g_nTeslas + 1` and matching lancemates. If you see that, suspect a count mismatch,
   not a crash.
-- **Drop-zone shortfall produces no error** ? just missing players.
+- **Drop-zone shortfall is benign** ? surplus 'Mechs spawn stacked, bump, take minor damage and
+  separate. Do not mistake this for a bug, and do not let it gate the work.
 - **Writing 32 into a 5-bit field truncates to 0**, which will look like "max players became
   unlimited/zero" rather than an overflow.