View Issue Details

IDProjectCategoryView StatusLast Update
0000633Gameplay + OpenGL[All Projects] Featurepublic2017-04-28 15:19
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Status resolvedResolutionfixed 
PlatformAllOSAllOS Version
Summary0000633: Console command to reload current map
DescriptionI'm working on a mod with multiple maps, and it'd be nice to be able to reload a map after making changes in an editor by pressing a single key instead of opening the console and typing "map map01". The single key binding isn't currently possible because the command's argument will change based on which map is loaded. So a new command, named something like "reloadcurrentmap", would be ideal. Bonus: an analogue of this new command for "changemap", ie does same thing but retains the player's inventory and health.
TagsNo tags attached.



Graf Zahl

Graf Zahl

2017-04-28 04:40

administrator   ~0001559

No new CCMDs, I just added a "*" parameter to the existing ones.
Blue Shadow

Blue Shadow

2017-04-28 07:34

reporter   ~0001560

Something I don't understand; if you edit the map, you need to reload it, which means you need to restart GZDoom, and at this point, you need to explicitly specify the name of the map you want to load. So how is this feature going to help in this situation?


2017-04-28 10:05

administrator   ~0001562

If you somehow got past the file sharing locks, the original Doom source code allows for live map reloads without restarting the game. I don't know if this still applies in ZDoom or not, but it would be easier to test this on Linux than on Windows.
Graf Zahl

Graf Zahl

2017-04-28 11:49

administrator   ~0001566

Reloading a map that was open in an editor is not possible because the engine keeps the file open which prevents writing to it.

The only way to reload an edited map is the 'open' CCMD.


2017-04-28 11:58

reporter   ~0001567

Thanks for implementing this! It works for its intended purpose for me. I open a map in GZDoom, open it in SLADE, make changes in SLADE, then "map *" and the change is reflected. I only filed this request because I'd observed that "map map01" works as described to reload map01, etc.

I didn't test it robustly; is this behavior just a total accident and could break at any time? I hate it when that happens :]
Graf Zahl

Graf Zahl

2017-04-28 12:07

administrator   ~0001570

Since the WAD directory is not reloaded this sounds like an accident indeed.
Can you give a more detailed description of what precisely you did (e.g. command line options for starting GZDoom?)


2017-04-28 12:50

reporter   ~0001574

Last edited: 2017-04-28 12:51

View 2 revisions

Sure. My mod is ZDoom/UDMF-based, and I'm working out of loose files in a directory.

My workflow is:
1. open map in SLADE
2. load map in GZDoom via shell script, described below
3. make changes in SLADE (modify things, linedefs, sectors etc)
4. press F5 (which I have bound to "map *") in GZDoom

I launch GZDoom with a shell script (I work in Linux) called runmap:

gzdoom pk3/ -warp "$mapnum" > run.log

(where "pk3/" is the subdir with my content in it)

But this shouldn't matter to the map load process, right?

Hmm... so, I've tried variations on those steps a few times now, and about half the time it /does/ fail, with an error, eg:

"Cannot load broken WAD file maps/map33.wad"

At first I thought this might have come down to whether I opened the map in SLADE or GZDoom first - something about grabbing a read/write handle to the file - but that doesn't seem to affect it, or at least have any bearing on the frequency of the "broken WAD file" error.

Graf Zahl

Graf Zahl

2017-04-28 13:59

administrator   ~0001575

Yes, that all makes sense. If you load the map from a subdirectory it will of course pick up the new file, but since the internal lump directory won't get updated, if the WAD's file size changes the subsequent load will fail, resulting in that error message.


2017-04-28 15:18

reporter   ~0001576

Last edited: 2017-04-28 15:19

View 4 revisions

Ah, so the "accident" was just that the file sizes happened to be the same? Guess that's what I get for testing only with trivial changes.

The "open" CCMD works for this actually, provided I invoke it with (as designed) the full path of the WAD file, and the rest of my mod stays loaded because each level WAD only contains a single level's data.

How difficult would it be to implement the same functionality you committed yesterday for map/changemap for open? I realize these commands do pretty substantially different things. Theoretically "filename of WAD of current loaded level" is within reach from the open CCMD's code?

Issue History

Date Modified Username Field Change
2017-04-27 13:49 JP New Issue
2017-04-28 04:40 Graf Zahl Status new => resolved
2017-04-28 04:40 Graf Zahl Resolution open => fixed
2017-04-28 04:40 Graf Zahl Note Added: 0001559
2017-04-28 07:34 Blue Shadow Note Added: 0001560
2017-04-28 10:05 Rachael Note Added: 0001562
2017-04-28 11:49 Graf Zahl Note Added: 0001566
2017-04-28 11:58 JP Note Added: 0001567
2017-04-28 12:07 Graf Zahl Note Added: 0001570
2017-04-28 12:50 JP Note Added: 0001574
2017-04-28 12:51 JP Note Edited: 0001574 View Revisions
2017-04-28 13:59 Graf Zahl Note Added: 0001575
2017-04-28 15:18 JP Note Added: 0001576
2017-04-28 15:18 JP Note Edited: 0001576 View Revisions
2017-04-28 15:19 JP Note Edited: 0001576 View Revisions
2017-04-28 15:19 JP Note Edited: 0001576 View Revisions