 |
No new CCMDs, I just added a "*" parameter to the existing ones. |
 |
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? |
 |
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. |
|
|
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. |
 |
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 :] |
|
|
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?) |
|
|
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. |
|
|
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. |
|
|
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? |
- Anonymous
