ZDoom

That would be really bad, in my opinion. Because what is to stop someone from creating an LZDoom mod that might be compatible with both GZDoom and QZDoom?

LZDoom is kind of the odd-man-out on this one. The accounting can be done either on LZDoom or GZDoom side (i.e. GZDoom just loads a "modern" filter folder), but the separation should be the ports that already exist, not the 26 different letters of the alphabet that happen to get stuck in front of the "ZDoom" name, or probably what might be better if a port just created its own name instead of using "ZDoom" whatsoever.

Things are far more likely to be compatible with GZDoom than with LZDoom, and most ports will derive from GZDoom.

I think the way to do it would be to add/use some kind of name string in the source code (i.e. GZDoom or LZDoom), and use that as the name of the filtered folder. The main benefit of this would be future proofing it for other forks of GZDoom, so the that if some other port comes around, say, YZDoom, then they simply need to change the name that string, and then you can just use the [i]yzdoom[/i] folder automatically as a filter for that port. I believe the already existing [url=https://github.com/coelckers/gzdoom/blob/55ce0510c2b181b941d30778f29b83a06955bb56/src/version.h#L101]GAMENAME string[/url], or related string, would be perfect for this, as they are already designed to be changed with forks of GZDoom anyway.

Careful: You may need multi-layer filters for cross-game support.

mymod.pk3
—menudef.txt   < loaded by gzdoom
—lzdoom/
——menudef.txt  < override when loaded with lzdoom

That sounds like a reasonable compromise since LZDoom is usually the "secondary" target for a lot of gameplay mods. So something like this I imagine? [code]mymod.pk3
—menudef.txt < loaded by gzdoom
—lzdoom/
——menudef.txt < override when loaded with lzdoom[/code]

8-)

Do you mean adding a lzdoom filter to override common lumps? If it's easily doable...

But then the burden is on LZDoom - if it wants to support such a thing.

Considering the major differences between mainline GZDoom and LZDoom, it'd definitely be useful.

[quote="Graf Zahl"]That would have been my idea as well - but I'm not really sold on the idea. This would be something that might just encourage people to continue using old versions and then come here whining if it actually doesn't.[/quote]
I mean that happens anyway :laff: and we deal with it on a "how convenient is it for me to support these requests" basis. For a while I had a "Legacy" version of my mod for LZDoom compatibility with... one line of MENUDEF removed, because that was extremely simple to do. This would make it twice as simple. The onus for support would remain solely on the mod authors like it is now, but version filtering would make things more [i]convenient[/i] in terms of maintenance and distribution.

Anyway just some thoughts. I support the feature in theory, I can see the valid use cases, but have little stake in the game so I'll leave it at that.

8-)

[quote="Apeirogon"]Is there are any examples of it?[/quote][url=https://forum.zdoom.org/viewtopic.php?f=43&t=37044&start=6855#p1184441]Yes.[/url]

[quote="m8f"]GZDoom API changes so a mod no longer works properly or doesn't load, and the user cannot fix it. [/quote]
Is there are any examples of it?

That would have been my idea as well - but I'm not really sold on the idea. This would be something that might just encourage people to continue using old versions and then come here whining if it actually doesn't.

mymod.pk3
—version/
——gzd.4.4/     < matches any gzdoom v4.4.x
——gzd.3/       < matches any gzdoom v3.x.x
——gzd.4.4.1    < matches specifically gzdoom 4.4.1, taking precedence over 4.4.x

[i]Were this to be considered[/i] (which I doubt it will and I have little need for it but just in case), I feeel an extension of the filter system would be the ideal implementation because then it could address issues in every lump type rather than specifically code lumps. IMO mixing versioned code / classes in the same lump would quickly become a maintenance nightmare anyway, as would needing to define versioning syntax for multiple varied lump types.
[code]
mymod.pk3
—version/
——gzd.4.4/ < matches any gzdoom v4.4.x
——gzd.3/ < matches any gzdoom v3.x.x
——gzd.4.4.1 < matches specifically gzdoom 4.4.1, taking precedence over 4.4.x
[/code]
Something like that perhaps.

8-)

I agree with Graf on this actually. Your use case with LZDoom does have some merit, however, but that's as far as my support for it goes. It's bad enough already with people coming with versions 4.4.x and 4.3.x when 4.5.x has already been out a while, the last thing we need is people complacent in the idea that they'll never need to upgrade because the mod will work around whatever version they decide they want to be stuck with, for better or worse, giving the delusion that the mod works properly on all versions of GZDoom when it clearly does not since the mod has to downgrade its own features to support them.

It can be made to work retroactively - if new GZDoom sees lumps (in some special directories) that old GZDoom does not, and overrides common lumps with them.

Currently, I was asked to make LZDoom version of one of my mods, because the latest version of LZDoom doesn't have some more recent features.
Another use case is when a mod developer wants to use features that are not yet in the release, but also wants to provide support for users who use the latest release.

I'M not sure I want that. Our approach has always been to only support the latest version, not older ones. And retroactively this has no effect anyway.