Ferk

True, but you can't solve that either with a new lump, whereas extending the old one does ensure the support for some of the older fields. It's nice to be able to have the port automatically know which iwad to select for which pwad, or which extra resource wads to load. Now ports have to support both lumps if they want to ensure they cover both old wads and new wads. And it's likely wads will start including both lumps as well, for old ports. So it's a lot of duplication just for the sake of JSON. They could have also added an alternative format to dehacked, but that would have meant ports need to either support both parsers (with wads also likely duplicating the lumps anyway if the want wider support), or drop support for old wads using dehacked (which doesn't seem reasonable at this point).

What does "breaking older parsers" mean here? Will the whole port crash? will it skip the lump entirely? or will it just skip the lines it does not understand while outputting warnings? I mean, afaik, dehacked is meant to follow the third approach, which is why it's relatively easy to add extra fields for extra functionality (or even new fields with different parsing rules) without completely throwing older parsers under the bus. Even this new standard adds dehacked extensions. In a way, that's comparable to ignoring a field in a JSON lump when it does not match any of the expected fields from the spec, or has a different type than specified. Using JSON does not automatically free you from unexpected input. I feel that full compatibility with old ports should not be a goal here. Nobody expects to be able to run flawlessly Boom WADs in a non-Boom port. Of course it's best to handle unexpected input gracefully, which is why I expect most of these ini-like formats should always ignore what they don't understand, at a line level (and I think that's why generally discouraging nesting in those formats is a good idea too). Something that makes more sense to me is the opposite: supporting older WADs in a new port. And that's why I feel supporting GAMEINFO would have made more sense than introducing a new lump. Because now we have some overlap in different lumps. Specially after Sigil gave some level of "officiality" to that lump, and I'm sure it's not the only one amongst the Official Add-ons (I just checked and even Legacy of the Rust itself has a GAMEINFO lump, despite it not being part of ID24).

Note that nowadays, most modern sourceports are able to read the DEH content from a lump included within the WAD itself (so no need for a separate .DEH file, it's included inside the WAD). That's why it's not so common to see separate DEH files if the WAD is already targeting a more or less "modern" port (eg. Boom and up...). They might still use dehacked, but it's just bundled inside a text lump in the WAD. The reason you still see separate .DEH is because it would work in more places (particularly older ones, like the original DOOM.EXE ..and specially if the wad targets/comes from the early days). It also would allow you to apply those changes for other wads (if for example it's actually a gameplay mod in DEH that just uses the vanilla graphics), and some people might also find it easier to make changes to the DEH when it's a separate file so that they don't have to change the WAD to update the behavior (or to make it optional for people who don't like it). And btw, chocolate also supports reading the internal dehacked lump when passing the -dehlump option, so even chocolate has the feature, in theory it does not require the DEH file to be separate. However, it might not be obvious that the wad requires -dehlump if you don't know it contains a dehacked mod, by default chocolate would ignore the lump and behave as vanilla would.

Do you have DEHACKED / UMAPINFO support? If you do, then you still need to worry, right?

both MISSILEMORE and MISSILEEVENMORE have the same effect as setting the "Missile chance Multiplier" from crispy to 0.5 or 0.125 (in FRACUNIT) respectivelly (or 0.0625 if you combine both flags). That is the one new value that is more flexible there than ZDoom, because in ZDoom they use flags for setting arbitrary values on the multiplier for the perceived distance.

The thing is that rather than it being a change of parser, it's an additional parser. So now there's 2 vectors instead of one. The UMAPINFO & DEHACKED parsers still are part of the standard and if so, it makes more sense to me to clarify the undocumented behavior when found, rather than introducing an extra parser without resolving the potential problems of the previous one, which is too, part of the standard.

In some ways, some of the features might be not as easy for pure C and minimalistic ports to implement than it would have been if they had chosen to selectively pick existing ZDoom equivalents and adapt/extend when needed (and the "Min Missile Chance" / "Melee Threshold" are good examples of adaptations from ZDoom in a way that makes sense for those ports). For example, I feel it might have been a good idea to extend the existing GAMEINFO lump for ZDoom instead of introducing a new JSON lump, which will require an entire new parser and would not be compatible with previous wads using that (eg. Sigil, to name one that was sort of "official" and had a GAMEINFO). In general, it would have been better if the same ini-like format (which is also sort of what's used in UMAPINFO) could have been used for all those lumps, instead of adding yet another one with extra dependencies. JSON is not particularly easy to parse without using external libraries, so I'm expecting that for a lot of the "simpler" ports it's a bit of an overkill format.

I feel the idea of two licenses being "compatible" is very unclear, it can be confusing what that even means. I mentioned about it before here. IANAL, but the way I understand it, in the context of the GPL, "compatible" just means that you can use together code that's under that "compatible" license with code under the GPL for the same program. Because ordinarily, the GPL would forbid you from doing that. But it doesn't mean the whole thing can be redistributed as if it were BSD (or GPL).. so if any GPL content was included, the game would need to include a notice making clear what content is GPL and which one is BSD, because people using the content would still need to follow the license of each respective piece of work. So far the project has been distributed entirely as BSD, instead of having to keep track of different licenses for different assets.

I feel the main reason it's hard to read is a lack of features. One example being the lack mnemonics/names that forces a lot of numerical ids. BEX was a significant improvement on this, but not enough. One alternative I heard someone mention somewhere was using the JSON format used in ID24, which happens to be sticking with ISO/IEC 21778:2017 version of JSON. But personally I believe that ISO standard is very stiff, it does not even allow including comments (which could be useful in something like this). I also feel JSON is neither necessarily easier to read (I keep having to use "beautifiers" at work to read JSON API responses comfortably) nor is it necessarily easier to edit (make sure you place the right bracket/brace/quote/comma in the right place).

About the GAMECONF lump, the spec mentions the load order to first include the IWAD (destructively) then any PWADS (additively). I'm wondering what would happen if the lump were to be included in a resource file like id24res.wad (or more specifically, a custom version of it, like Freedoom's) Perhaps the lump should be included in the custom IWAD, to be more fitting with the spec.. but I was wondering what would ports do if the ID24 specific lumps were actually found in resource files like id24res which are meant to be loaded before the IWAD (as far as I understand).

Ugh.. sorry for the constant edits.... but I kept re-checking and re-thinking... I think that effect does match what was called "Missile chance Multiplier" here: https://github.com/fabiangreffrath/crispy-doom/pull/636/commits/2c3ff5f74f594a2586da1111c829078675e69ff3 Though perhaps the name is not great, since it multiplies the "perceived distance", as you said... however, "Min missile chance" (borrowed from ZDoom) is also just setting a limit for the "perceived distance" in that same logic, isn't it? Isn't that distance later compared with a random value to determine whether the range check for shooting passes? If so, this effectively is a multiplier on the chance that the range check required for shooting fails. The point is that the behavior was de-hardcoded using a scalar that allows finer values while keeping demo compatibility.

Oh, thanks for the clarification, the wording is confusing ^^U They still encode a behavior that could have easily been made scalar instead of hardcoding arbitrary distances linked to booleans. I added that as "Max target range" in one of the commits I referenced earlier, it was actually something that @Graf Zahl did first in an earlier iteration of his prboom+ fork.

Yes, this is exactly the kind of thing that I meant when I was saying "some of which didn't actually need to be booleans and could have allowed more flexibility". Things should not be a boolean if making them a scalar is actually possible. I remember ZDoom also had flags like "MISSILEMORE" for increasing shooting chance and then later "MISSILEEVENMORE" was added to increase it further... instead of actually offering the chance as a value. MBF21 did not learn from that and added their very own flag for that.

To me, these sound much better ideas than throwing away DEHACKED. Yes, this is also a good idea. Though personally, to me it would be cleaner to fully get away from using bitfield representation to store arbitrary boolean properties. Something like "whatever = TRUE" would make more sense to me than including MF_WHATEVER in a chain of flags. It should be up to each port to decide what's the data structure in which they want to store those booleans, using bitfield values like that is exposing implementation details that just add baggage. Though I understand that in the end what you propose is sort of "faking" internally the Bitfield value.

Yeah, but the alternative to that is to make up a new format that would either have the exact same problem, or require a string-based ThingType identifier. Which is why I was proposing extending dehacked to support something like "Thing type = whatevernewname" to create a new thing and using the name as string identifier I expect one problem would be the map format (and many other places I expect) referencing Things by numeric ID.. but you'd have the same problem with any alternative, I expect