Maps that have underscores don't get sent when playing online

[SniperGoth]

If you have a map with underscores, like let's say, something you got from the temp folder, and you try to play it online with other people, it will just not get sent, making people hang up in the loading screen, at least from my observations.

Screenshots from Unixfreak trying to get into a match but not being able to due to that reason.

[Jigoku]

Antigravity reports this solution; Needs reviewing though whether it's correct;

Map Sync Investigation

Problem Description

When a client joins a server running a custom/modified map (e.g. icecap_0x764200c2), the map
auto-download succeeds (files are written to disk) but the engine fails to load the map afterwards.

Example log showing the failure:

Map change: icecap_0x764200c2 (2:2053) [0x764200c2] (Default)
Checking map: maps/icecap.mpz [0x00000000] (need: 0x764200c2)
Checking map: temp/maps/icecap_0x764200c2.mpz [0x00000000] (need: 0x764200c2)
Not found: temp/maps/icecap_0x764200c2.mpz
Unable to load icecap_0x764200c2

Sending you the map, please wait..
Wrote map file: temp/maps/icecap_0x764200c2_0x764200c2.mpz (622152 bytes) [0x764200c2]
Wrote map file: temp/maps/icecap_0x764200c2_0x764200c2.cfg (215454 bytes) [0x764200c2]
Wrote map file: temp/maps/icecap_0x764200c2_0x764200c2.png (158454 bytes) [0x764200c2]

Map change: icecap_0x764200c2 (2:2053) [0x764200c2] (Default)
Checking map: maps/icecap.mpz [0x00000000] (need: 0x764200c2)
Checking map: temp/maps/icecap_0x764200c2.mpz [0x00000000] (need: 0x764200c2)
Not found: temp/maps/icecap_0x764200c2.mpz
Unable to load icecap_0x764200c2

The engine looks for temp/maps/icecap_0x764200c2.mpz but the client wrote the file to
temp/maps/icecap_0x764200c2_0x764200c2.mpz. The download was pointless.

---

Root Cause Analysis

Step 1 — How the server stores and sends the map name

smapname is the authoritative map name on the server. It is set from the voted/chosen map name
and can be anything, including names that already contain a CRC suffix, like icecap_0x764200c2.

// server.cpp:3588
copystring(smapname, reqmap);

When the server sends map files to a client it passes smapname verbatim as the filename:

// server.cpp:3410
loopi(SENDMAP_MAX) if(mapdata[i])
    sendfile(ci->clientnum, 2, mapdata[i], "ri3s", N_SENDMAPFILE, i, smapcrc, smapname);
//                                                                            ^^^^^^^^
//                                                                  This is e.g. "maps/icecap_0x764200c2"

Step 2 — How the client writes the received file

The client's receivefile (client.cpp:1480) receives:

• filecrc = 0x764200c2 (from the smapcrc field)
• fname = "maps/icecap_0x764200c2" (from smapname)

It then unconditionally appends _0x{filecrc} to the name:

// client.cpp:1491-1492  (current code)
defformatstring(nfname, "%s", /* strip temp/ prefix */ ...);
defformatstring(ffile, "temp/%s_0x%.8x", nfname, filecrc);
// => "temp/maps/icecap_0x764200c2_0x764200c2"  ← DOUBLE SUFFIX

Because fname already contains _0x764200c2 and the code appends _0x764200c2 again,
the file is written as temp/maps/icecap_0x764200c2_0x764200c2.mpz.

Step 3 — How the engine looks for the map

load_world (worldio.cpp:1001) calls setnames(mname, crc) which does strip any
existing _0x suffix before appending the new one:

// worldio.cpp:83-89
void setnames(const char *fname, int crc) {
    ...
    char *fcrc = strstr(fn, "_0x");
    if(fcrc) *fcrc = '\0';           // ← strip existing suffix
    if(crc > 0) concformatstring(fn, "_0x%.8x", crc);
    ...
}

So load_world("icecap_0x764200c2", 0x764200c2) → setnames builds mapfile as
"temp/maps/icecap_0x764200c2.mpz".

The engine then looks for temp/maps/icecap_0x764200c2.mpz.
The client wrote temp/maps/icecap_0x764200c2_0x764200c2.mpz.
These do not match → "Not found" → load fails.

---

Why only "certain maps"?

This bug only manifests when smapname already contains a _0x... suffix. That happens when:

1. A server admin calls /sendmap while on a map that was itself downloaded from another server
   (and thus already has a CRC suffix in its mapname, e.g. temp/maps/icecap_0x764200c2).
2. A voted map name was specified with a CRC suffix already baked in.

For plain maps like maps/wrath the name has no suffix and the single appended suffix is correct.

---

Fix

The fix mirrors what setnames in worldio.cpp already does: strip any _0x... part from
nfname before appending the new CRC. This makes receivefile consistent with load_world.

Proposed patch for src/game/client.cpp

--- a/src/game/client.cpp
+++ b/src/game/client.cpp
@@ -1488,6 +1488,10 @@ void receivefile(uchar *data, int len)
                 if(!*fname) copystring(fname, "maps/untitled");
                 // Remove any temp/ prefix from file name before testing and rebuilding.
                 defformatstring(nfname, "%s", (strstr(fname, "temp/") == fname || strstr(fname, "temp\\") == fname) ? fname + 5 : fname);
+                // Strip any existing _0x... CRC suffix so we don't end up with a double suffix.
+                // The server sends smapname verbatim (e.g. "maps/icecap_0x764200c2") and we are
+                // about to append filecrc ourselves — mirroring what setnames() in worldio.cpp does.
+                char *fcrc = (char *)strstr(nfname, "_0x");
+                if(fcrc) *fcrc = '\0';
                 defformatstring(ffile, strstr(nfname, "maps/") == nfname || strstr(nfname, "maps\\") == nfname ? "temp/%s_0x%.8x" : "temp/maps/%s_0x%.8x", nfname, filecrc);

Result of the fix:

• fname = "maps/icecap_0x764200c2" (received from server)
• After stripping: nfname = "maps/icecap"
• After appending: ffile = "temp/maps/icecap_0x764200c2"
• Written file: "temp/maps/icecap_0x764200c2.mpz" ✓

This now matches what load_world → setnames expects to find.

---

Secondary Issue: Flakiness / Maps not loading after auto-send

From the logs, even after the download, the map still fails because:

1. Files are written after the second N_MAPCHANGE is processed (the server re-sends
   N_MAPCHANGE after the map upload completes, server.cpp:6455).
2. At that point load_world runs again and looks for the (correctly named) file. With the
   double-suffix bug fixed this second attempt would succeed. Without the fix, both attempts fail.

So fixing the double-suffix is the primary fix. The second "Unable to load" after the
download is a symptom of the same bug, not a separate issue with the auto-send timing.

Server-side: No timeout on map provisioner (mapsending)

There is a secondary flakiness vector. When the server needs to download the map from a client it
picks a "best" client as the provisioner and locks mapsending to that client number:

// server.cpp:3468
mapsending = best->clientnum;
sendf(best->clientnum, 1, "ri", N_GETMAP);

Problem: If that client does not respond (slow connection, crashed, etc.) mapsending
stays locked to a dead/slow client forever. Other clients cannot provide the map, and any client
wanting a download just gets "The map is being uploaded, please wait.." indefinitely.

There is no timeout on mapsending during a live game. (The waiting-phase timeout only applies
to G_S_GETMAP state, not to a mid-game map request.)

Proposed patch for src/game/server.cpp — provisioner timeout

--- a/src/game/server.cpp
+++ b/src/game/server.cpp
@@ -489,7 +489,7 @@
-    int smapcrc = 0, smapvariant = MPV_DEFAULT, mapsending = -1, mapgameinfo = -1, mapvoter = -1,
+    int smapcrc = 0, smapvariant = MPV_DEFAULT, mapsending = -1, mapsendingmillis = 0, mapgameinfo = -1, mapvoter = -1,

@@ -3466,6 +3466,7 @@
         if(best)
         {
             mapsending = best->clientnum;
+            mapsendingmillis = totalmillis ? totalmillis : 1;
             ...

// In serverupdate(), after the existing control loop:
+        if(mapsending >= 0 && !hasmapdata() && mapsendingmillis && totalmillis - mapsendingmillis > 60000)
+        {
+            srvoutf(4, colouryellow, "Map provisioner timed out, resetting..");
+            mapsending = -1;
+            mapsendingmillis = 0;
+        }

---

Summary of Proposed Changes

File	Line(s)	Change	Priority
src/game/client.cpp	1491-1492	Strip _0x... from received fname before appending CRC	Critical
src/game/server.cpp	~489, ~3468, ~5600	Add mapsendingmillis and provisioner timeout in serverupdate	Low/Nice-to-have

The critical fix is entirely in client.cpp — two lines, matching the pattern already used in
worldio.cpp::setnames.