Closed NightFright2k19 closed 1 year ago
I am not opposed to this idea, but there are some things to consider.
Take e.g. "requiem.wad", there is a patch for this available to fix some issues with MAP21. So, will savegames get stored into the "req21fix.wad" directory for this one map or will they also get stored into the "requiem.wad" directory as the for the other maps?
Gameplay mods do need to be considered. Dehacked can introduce hundreds of new entities and cause them to spawn in a level without editing the level itself. You wouldn't be able to properly load a save that uses xaser's mbf21 weapon set for instance if you don't have the mod loaded. Depending on what states are replaced and what woof does if it tries to load something that doesn't exist, you could have crashes immediately or delayed. Maybe you could link those non-map-wads to the save files implicitly and load the mod when you load the save. I don't really know what the expected behaviour should be.
Interesting points you are bringing up there. TBH I don't know right now how other ports are handling this.
I have asked in the ZDoom forums about how GZDoom handles this.
Graf Zahl wrote: "The whole thing only checks IWADs. All PWADs for the same IWAD still get saved to the same folder, unless you explicitly override the destination with -savedir or the save_dir CVAR (the latter is not recommended as it completely disables the system, but needs to be kept for compatibility)"
I guess they took the easy way out to avoid the system to get too complicated. For a port like GZDoom that supports a multitude of IWADs, this seems to be a sufficient approach.
If the distinction was just made between doom.wad, doom2.wad, tnt.wad and plutonia.wad (as it would be the case here), the whole thing wouldn't really be worth it. Personally I'd say new folders should at least be created for anything that adds new maps. Loading mods on top might have an impact on the functionality of the savefiles if they are removed again afterwards, but that's something users should generally be aware of. At least that's the way I see it.
The way dsda-doom does this is it generates a directory iwad/pwad1/pwad2/...
and stores the saves there, inside a root data directory that sits in the exe directory (there are things in there besides save files). The concatenated wad list ignores autoload files, so the idea is "these are meaningful files chosen for this session".
Well, we wouldn't need it for anything besides save files. But other than that, the concept seems good to me at first glance.
It would be a lot easier if we just did per-IWAD savegame directories.
That would basically mean just four different directories, for Doom 1+2, Plutonia and TNT (unless I forgot some)? I mean, most PWADs are for D2 these days, but well... it'd be something.
Chex, Hacx and (flavors of) Rekkr. 🤷
Ah right, those. Well, it's a sorting mechanism like that, even if it's basic. For me it would be OK.
We would still need a migration path from the current scheme, though.
It should be noted that some games have a DeHackEd patch that changes the filename. For instance HacX
Text 13 13 doomsav%c.dsghacxsav%c.dsg
In my port I've just changed the filename to match the wad filename that has maps if it's not been changed by other means.
Right now, Woof stores savegames in its root directory. If someone is switching between several addons within a short period of time, it's possible to accidentally overwrite savegames meant for a different PWAD. Therefore, it would be better if there was a way to keep them separate in a more fool-proof way, but also simply in order to maintain some order in the game root directory.
In other ports such as GZDoom, wadname-based savegame directories are created to avoid such situations. It's actually pretty much like the autoload folder works right now, just for savegames.
Suggested realization:
Things to consider: