Version dependent code

Remember, just because you request it, that doesn't mean you'll get it.

Moderator: GZDoom Developers

Version dependent code

Postby m8f » Mon Apr 05, 2021 10:02 am

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 allExpand view
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.
User avatar
m8f
dreamer
 
 
 
Joined: 29 Dec 2017
Location: Siberia (UTC+7)
Discord: m8f#0629
Github ID: mmaulwurff
Operating System: Debian-like Linux (Debian, Ubuntu, Kali, Mint, etc) 64-bit

Re: Version dependent code

Postby Graf Zahl » Mon Apr 05, 2021 10:29 am

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Version dependent code

Postby m8f » Mon Apr 05, 2021 10:47 am

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.
User avatar
m8f
dreamer
 
 
 
Joined: 29 Dec 2017
Location: Siberia (UTC+7)
Discord: m8f#0629
Github ID: mmaulwurff
Operating System: Debian-like Linux (Debian, Ubuntu, Kali, Mint, etc) 64-bit

Re: Version dependent code

Postby Rachael » Mon Apr 05, 2021 11:11 am

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.
User avatar
Rachael
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: ATI/AMD with Vulkan Support

Re: Version dependent code

Postby Caligari87 » Mon Apr 05, 2021 11:22 am

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 allExpand view
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.

8-)
User avatar
Caligari87
I'm just here for the community
User Accounts Assistant
 
Joined: 26 Feb 2004
Location: Salt Lake City, Utah, USA
Discord: Caligari87#3089

Re: Version dependent code

Postby Graf Zahl » Mon Apr 05, 2021 11:31 am

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Version dependent code

Postby Apeirogon » Mon Apr 05, 2021 11:57 am

m8f wrote: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?
User avatar
Apeirogon
I have a strange sense of humour
 
Joined: 12 Jun 2017

Re: Version dependent code

Postby m8f » Mon Apr 05, 2021 12:01 pm

Apeirogon wrote:Is there are any examples of it?
Yes.
User avatar
m8f
dreamer
 
 
 
Joined: 29 Dec 2017
Location: Siberia (UTC+7)
Discord: m8f#0629
Github ID: mmaulwurff
Operating System: Debian-like Linux (Debian, Ubuntu, Kali, Mint, etc) 64-bit

Re: Version dependent code

Postby Caligari87 » Mon Apr 05, 2021 2:27 pm

Graf Zahl wrote: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 :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 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.

8-)
User avatar
Caligari87
I'm just here for the community
User Accounts Assistant
 
Joined: 26 Feb 2004
Location: Salt Lake City, Utah, USA
Discord: Caligari87#3089

Re: Version dependent code

Postby Marisa Kirisame » Tue Apr 06, 2021 12:47 am

Considering the major differences between mainline GZDoom and LZDoom, it'd definitely be useful.
User avatar
Marisa Kirisame
ZScript Crimester
 
 
 
Joined: 08 Feb 2008
Location: Vigo, Galicia
Discord: 霧雨魔理沙#1666
Twitch ID: magusmarisa
Github ID: OrdinaryMagician
Operating System: Other Linux 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Version dependent code

Postby Graf Zahl » Tue Apr 06, 2021 1:09 am

But then the burden is on LZDoom - if it wants to support such a thing.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Version dependent code

Postby drfrag » Wed Apr 07, 2021 2:57 am

Do you mean adding a lzdoom filter to override common lumps? If it's easily doable...
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: Version dependent code

Postby Caligari87 » Wed Apr 07, 2021 9:51 am

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 allExpand view
mymod.pk3
—menudef.txt   < loaded by gzdoom
—lzdoom/
——menudef.txt  < override when loaded with lzdoom


8-)
User avatar
Caligari87
I'm just here for the community
User Accounts Assistant
 
Joined: 26 Feb 2004
Location: Salt Lake City, Utah, USA
Discord: Caligari87#3089

Re: Version dependent code

Postby Graf Zahl » Wed Apr 07, 2021 10:14 am

Careful: You may need multi-layer filters for cross-game support.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Version dependent code

Postby 3saster » Thu Apr 08, 2021 1:34 pm

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.
User avatar
3saster
 
Joined: 11 May 2018
Location: Canada

Next

Return to Feature Suggestions

Who is online

Users browsing this forum: No registered users and 1 guest