Engine version checking for mods

[Caligari87]

Perhaps this has been suggested before (in which case I apologize for duplicating discussion, not sure what to search for...) but this is something that ZDoom (and its children) need to address. Development often moves so fast, mods may struggle to keep up. New features supersede old ones, old bugs being fixed breaks mods which relied on incorrect behavior... we're all familiar with this.

What I propose is a feature to allow mods to specify which version of the engine they're intended to work with. GAMEINFO would probably be the best place for this, perhaps a keyword like

Code: Select all

ENGINE = "<version string>"

which would match the format of the version seen in the console, or other options like a simplified engine name (such as like "gzdoom" if the modder intends for the GL renderer only) or a major version ("zdoom 2"), anything like that.

The result for the end user would be a soft warning popup at the loading window before any code loads: "This mod appears to be designed for <engine oldversion>. You are currently running <engine currentversion> Certain features may not work as expected. Do you wish to continue?" In case of mods without a version specified, check the date on the wad/pk3 against the build date of the engine. If it's outside a certain range (a year? six months?), populate a warning message in the console but no Y/N popup. Of course have a cvar to disable engine version warnings, possibly under the compatibility options.

Basically some way for modders to specify a target version, and a helpful message for users to note if something appears broken, even if the modder doesn't opt-in. Thoughts?

[Graf Zahl]

If you seriously mean that modders can set an older version as baseline and print a warning on a never version, this is a 'no', if the other way around, it may be doable.

[NeuralStunner]

Here's the thing, though: If a mod built for an older version is not working properly in a newer version, it's most likely a compatibility bug and should be addressed. If it's a misuse of feature then the mod needs to be patched.

As for the other way around: I'd be all for a minimum version setting. A clear, concise message with a link back to the downloads/devbuilds page would help. (Or to this post if you'd rather.) Granted, it's been a long time since I've seen an "i get a crash" post, but then I don't follow the projects forum as closely as I used to.

[Caligari87]

I suppose it could be "intended for version x or newer". I had envisioned it working both ways honestly, some way for the engine to soft-warn the player if the mod they're running may break in a newer version. Seems that could help cut down on bug reports (and subsequent well-intentioned under-the-radar fixes) where the engine is showing objectively correct behavior but the mod is using buggy behavior in non-obvious ways. Since checking each possible use case is far too intensive, it seems a simple date range would be the easiest solution.

But if that's a no, at least a minimum version check would be a huge improvement.

[Graf Zahl]

Making it both ways would send a signal to the users I don't like. Yes, there can be regressions, but they need to be reported and fixed. Not guarded by a "Use an older version" message that causes them not getting reported.

[Gez]

some way for the engine to soft-warn the player if the mod they're running may break in a newer version. Seems that could help cut down on bug reports

But we don't want that. If something that used to work breaks in a new version, that's called a regression, and it is a bug.

The idea is that a user should always be able to just update to the latest build and everything will work. The idea of forcing users to keep around three dozen old versions of ZDoom is not desirable.


Note for smartasses who want to bring up demos: don't. We're not talking about backward demo compatibility here.

[Caligari87]

My contention is that the correct behavior still sees some older mods often break in non-obvious ways because they were designed around a regression or incomplete feature in the first place.

I concede there's sometimes no real way to tell if a broken behavior in an old mod is a genuine regression or bad design, but regardless: It's not about forcing or suggesting the player to use an old version; it's about giving a warning that there may be regressions because the mod was designed around an old (possibly broken) version, even if it compiles and runs with no other errors or warnings. Yes, patch the mod, but also warn they may need to be patched so someone doesn't think the error is itself a regression (generally those don't survive a year).

Like I said though, if that's generally considered a bad idea then so be it, let's skip that part. I still think a minimum-or-newer version check is a sorely-needed feature and can help shield less-knowledgeable users from scary errors when all they need to do is upgrade.

[Blue Shadow]

The idea of forcing users to keep around three dozen old versions of ZDoom is not desirable.

That's my main gripe with such a feature.

[Graf Zahl]

Sorry. No, Caligari, that simply would do major harm to ZDoom as a project so it's not going to happen.

[Caligari87]

Okay no problem. Here's what I understand then:

• Warn on newer engine if mod is old - Bad idea, scratch this one.
• Warn on older engine if mod sets minimum version - Good idea, this could be useful.

That works for me if you're okay with it.

[Player701]

IMHO, if modders / mappers use hacks or workarounds, the developers cannot be held liable if mods or maps made by those people break in newer engine versions. The authors have to fix their content themselves. Of course, if the content follows the standards, and in a newer version something stops working, it is a regression which needs to be fixed in the engine.

Unfortunately, it is often difficult to follow this rule, as a lot of maps released nowadays still use the original map format which is far too restrictive. But if we're talking about ZDoom features only, it should be mostly OK.

[Enjay]

I dunno, I try to keep my mods in compliance with ZDoom spec and I avoid hacks. If I think I might be doing something wrong, I ask if it's the right way to do it or not. But I've still had problems.

The thing is, if you don't know something is wrong, you don't know to ask in the first place or that you should avoid using it. You believe that you are doing things right and it doesn't even cross your mind that you might not be. So it is possible to make a mistake perfectly innocently, assuming what you are doing is correct because you see nothing to indicate that what you are doing is incorrect and, of course, what you are trying to do works in the engine at the time. It doesn't seem hacky, it works; why would you even think it is wrong? I've done that often enough.

Sometimes, even after asking about a particular way of doing things, it's possible to find out later that the advice you were given on the forum was not correct. It's happened to me more than once. Sometimes you find out that what you were doing was in the grey area of "undefined behaviour" and tightening up the engine breaks what you did in your mod.

So, as someone who genuinely makes an effort to stay within spec and do things properly, I have released a number of mods which have something about them break with future releases of GZDoom/ZDoom. I don't recall anything that was actually mod-breaking happening but there have certainly been things that broke visual features and minor behavioural ones.

Sometimes it's even possible to stay perfectly within spec yet still find things breaking. An example (that will probably be fixed) from only a day or two ago is that using the A_M_Refire code pointer perfectly in spec for mods with altered scripted marines (indeed, copying code from either the Wiki or zdoom.pk3 itself) will break in the latest ZScript versions. This is a bit of a false example because the ZScript versions are very much WiPs and this problem with be addressed but the use of that pointer is a rare one and it could easily have slipped through to an official version. The change in code was made for good reasons; as Graf said, to "sanitize" the code.

I'm sure I have even seen more than one situation where the answer was basically "the way the [ZDoom] code is now is better/more robust (etc) and breaking the feature of your mod has no effect on the playability of the mod so we're just going to have to accept that situation".

____________________________________________

All that being said, I agree with the principle of graf's stated policy. If a version check becomes available to modders, it should be to check for a minimum version required and not to ensure that a mod is being played with an old version. New mods use new features and old versions of ZDoom may not have them. That's the obvious point of the check and one common throughout the computing industry.

Yes, there can be times when a mod breaks and it is sensible to include which version a mod was made for in the text file (hell, if you're paranoid, print it on screen) but having users keep old versions of ZDoom around and locking mods to them seems very wrong.

And let's not forget that modders can't know if the next version of the engine will break their mod or not (unless they're time travellers or something) so locking a mod to the version that is current at the time of the release doesn't make much sense and is a bit paranoid anyway. The mod may (and, despite my introductory paragraphs, should) be perfectly fine with future versions.

[Blzut3]

Probably wouldn't be a bad idea to take inspiration from CMake's cmake_minimum_required. Every now and then we come across regressions where there have been multiple stable releases since which makes them awkward to fix. If mods declared the version they were designed for automatic compatibility would be a bit easier.

[Graf Zahl]

This won't be so easy. We got 3 ports, each with their own version number and their own release schedule, so it's rather arbitrary what should be placed in there, and it would require some change to the current versioning system, which I am not willing to do right now.