Welcome to the ZDoom Forums!

ZDoom is no longer being actively maintained. So yes - everything goes to GZDoom.

Were these commits only made to GZDoom? I don't see them on the ZDoom git.

[quote="Eruanna"]But it just goes to show you - always, always, always, if you can, state the reason for your request. It really goes a long way towards resolving the issue you have if your request is not itself something the developers want to implement.[/quote]


Indeed. This one's a textbook example of "I want A to work and if B is done it will, so let's request B."

This report should probably be closed. While the original quest seems(?) to have been denied, the problem that it was originally trying to solve in the first place has actually been solved, albeit in a different (and in my opinion, more logical) way.

But it just goes to show you - always, always, always, if you can, state the reason for your request. It really goes a long way towards resolving the issue you have if your request is not itself something the developers want to implement.

[quote="Gez"]GAMEINFO doesn't have such a feature right now. If it were to get it at some point in the future, it'd be with a different key than IWAD -- possibly something like SELFIWAD.[/quote]
Yeah, I know it's not supported right now. I'm just saying that if you pass in the file's own name, ZDoom *does* load your file as an IWAD, but chokes afterward when everything conflicts internally because it then tries to load the same file as a PWAD.

GAMEINFO doesn't have such a feature right now. If it were to get it at some point in the future, it'd be with a different key than IWAD -- possibly something like SELFIWAD.

[quote="Gez"]Ideally, GAMEINFO could do that, since it's the one lump that is parsed before everything else. A FILTER key could work.[/quote]

Right now, if I try to set a file as it's own IWAD via GAMEINFO, it tries to load the specified file twice... Maybe I'm over-simplifying because I don't understand, but couldn't a check to make sure the same file isn't loaded twice be put in place? (remove the file from the pwads list in d_main.cpp if it specifies itself as an IWAD?)

Ideally, GAMEINFO could do that, since it's the one lump that is parsed before everything else. A FILTER key could work.

That *.ipk3/*.iwad sounds pretty good to me. Even as a modder who sometimes makes IWADs just for personal use, that would be very usable; allowing me to make a bunch of different IWADs, each containing their own IWADINFO and each being autodetected by ZDoom.

That would be ideal. And give them a unique extension that ZDoom can search for outside of a name list (i.e. .ipk3 and .iwad) so that the internal iwadinfo.txt file does not need to be updated - and it could just include its own iwadinfo.txt file with and IWad{} block that has definitions specific to itself.

Something like that may have to be agreed upon by the larger Doom community, though, considering the standards that had to be developed with UDMF and USDF.

How about a convention that goes the other way? Given that any new IWADs are just that, new, how about asking the people who produce them to include a lump that uniquely identifies them that ZDoom can search for and, perhaps, even interrogate for further details?

Changing things to a checksum would be more robust but IWADs can change (sometimes people edit their own (bad, I know) and, for example, people's smooshed ones will be different) and there are a few different versions out there anyway. e.g. A couple or more years back, for example, most people on Doomworld were surprised to find that my copy of TNT.WAD from the id Anthology had the map 31 fix already even though a version released after the Anthology didn't have the fixed WAD. Even some versions of the Anthology seemed to have a different TNT.WAD to mine.

Well, if the config file is an issue, the empty sections can certainly be removed, but I thought they were there so that you can load in your custom content without ever having to create them, yourself. Maybe what can be done, instead, is the empty sections are only created if ZDoom detects a matching WAD in its IWAD listing.

Addressing the original point though, I personally see no harm in supporting "plenty" (as you said) IWADs. I think the bigger issue is how complex they will end up being in the future, to the point where standard lump detection such as what we use may not work. This issue itself veers dangerously close to that, considering the discussion that spawned just from having "SMOOSHED" as the only required check lump. Inevitably it may also get to a point where someone names an IWAD the same as an existing PWAD with completely different content, and then ZDoom mistakenly detects said PWAD as an IWAD and doesn't know what it is and won't load it correctly. (Luckily, most PWADs do not contain a PLAYPAL lump but it's becoming increasingly common that some do)

[quote="Eruanna"]the total available IWADs right now out there are so few in number...[/quote]
A bit of a side point but looking through my ini file the other day, and IWADINFO.TXT in gzdoom.pk3, I was starting to get (albeit only very slightly) concerned about the number of auto-supported IWADs. The list is growing and with it the number of auto-added empty autoload sections in my ini and the general complexity of the IWADINFO.TXT.

I guess what I'm saying is that there is an increasing number of supported IWADs but I'm not convinced about the value of doing so. Some of them are relatively obscure and most people will not be playing them on a regular basis. Indeed, some are essentially projects a bit like add on mods that people will play once or twice and then forget about entirely. Would there be any real problem in leaving IWADs of that type needing to be loaded via the -iwad parameter?

How much value is there in supporting more and more IWADs? What makes an IWAD qualify for autodetection support?

Frankly, I don't know the answer but if the answer to question 1 is "plenty" then I'm happy with that but I just thought that it was worth asking.

Well I updated it yet again. This checks for a lot more lumps that are guaranteed to exist in WadSmoosh - however - the issue here is, most of the lumps being checked do exist in regular Doom/Doom2 IWADs. There is one other lump that doesn't, however - TEXTURES. Maybe that's enough?

I moved its detection right above Doom 1. In my test, it worked so far.

That's another thing I thought about, as well - the total available IWADs right now out there are so few in number that having a naming collision like that is extremely unlikely. But adding in additional check lumps really would be helpful, because what if someone in the future does want to make an IWAD with a "smooshed" texture? Ultimately, this may require JPL's involvement, as the original pull request did.