Version dependent code

[m8f]

Disclaimer: I don't know how feasible this is, and I'm not sure if it's a good idea at all.

Classes and/or functions with different contents depending on GZDoom version. Something like this:

Code: Select all

class A {...} // default implementation.
class A [[version < 6.6.6]] {...} // implementation for GZDoom before version 6.6.6.

class B
{
  void do() {...} // for all versions, except the following:
  [[version == 4.2.0]] void do() {...} // specific implementation for GZDoom v4.2.0.
}

Or, even more general, something like filter system, but for versions, not games. So it can be made that newer versions of GZDoom override lumps.

Why?
- for graceful degradation for mods that require most recent features of the engine to, but can function in some way without them.
- for workarounds for engine behavior that changed, so a mod can behave in the same way even if underlying functions work differently between GZDoom versions.

I wish that all users would use the latest GZDoom all the time, but in real world it doesn't happen. Somebody is always stuck on an older version because
- it can be a fork of GZDoom with a specific feature, and that fork is no longer updated;
- some versions of GZDoom don't support their hardware/OS.
- in rare cases, GZDoom API changes so a mod no longer works properly or doesn't load, and the user cannot fix it. The user has to use older engine version to play that mod.

[Graf Zahl]

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.

[m8f]

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.

[Rachael]

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.

[Caligari87]

Were this to be considered (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: Select all

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

Something like that perhaps.

[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.

[Apeirogon]

GZDoom API changes so a mod no longer works properly or doesn't load, and the user cannot fix it.

Is there are any examples of it?

[m8f]

Is there are any examples of it?

Yes.

[Caligari87]

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.

I mean that happens anyway 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 convenient 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.

[Marisa the Magician]

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

[Graf Zahl]

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

[drfrag]

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

[Caligari87]

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: Select all

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

[Graf Zahl]

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

[3saster]

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 yzdoom folder automatically as a filter for that port. I believe the already existing GAMENAME string, or related string, would be perfect for this, as they are already designed to be changed with forks of GZDoom anyway.