UMAPINFO "episode" Unspecified Behaviour Resolution

[Altazimuth]

This thread is intended to be a round-table between maintainers of ports with UMAPINFO support.

 

The ports I know of behaviour of are dsda-doom, Eternity Engine, GZDoom, Odamex, and Woof!. Knee-Deep in KDiZD in particular demonstrates an edge-case in episode-handling behaviour (Eternity it requires modification to do so) that the spec does not explicitly define the intended behaviour of. It only defines a single episode, and different ports handle this differently. There are two approaches that different ports take.

• GZDoom and dsda-doom show no episode select, but will respect the episode start, so will launch the single episode on the appropriate map.
• Eternity, Woof!, and Odamex all pop up an episode select with only an individual episode.

The core thing I want to do here is try and maybe get a Rev 2.2 which either clarifies this behaviour, or if we can't come to an agreement at least explicitly states the behaviour is implementation-defined.

 

I'm tagging a list of people who I know work on ports with UMAPINFO support. Apologies if I forgot to tag you, though others here with better knowledge than me please feel free to tag others. I want discussion of this to be as inclusive among the people actually having to develop support for this as possible: @fabian, @AlexMax, @Graf Zahl, @rfomin, @printz, @jval.

 

My personal opinion: I honestly don't mind if it becomes officially implementation-defined. My guess as to the most "sensible" answer is that dsda-doom (via PR+UM) and GZ have the reference implementations, so their behaviour should be considered the correct one and codified as such. By the same token though, I really don't think it's so overwhelmingly important that ports should have to conform to this very specific behaviour.

 

So what do others think? Should it remain implementation-defined, or should there be a default and if so what should that default be?

[Da Spadger]

1. [21:23]Altazimuth: 

   https://www.doomworld.com/forum/topic/132415-umapinfo-episode-unspecified-behaviour-resolution/ Countdown until non-dev weighs in.

 

 

Hello. :)

Edited November 12, 2022 by Da Spadger

[fabian]

Thanks for the heads up! I think there should be a difference between `episode = clear`, which should show no episode menu at all -- and explicitly defining even only one episode, which should get shown in the menu. 

[Xaser]

Semi-dev weighing in: I'm not sure how showing a single-episode menu is desirable in any way, and Doom 2 doesn't show anything at all so we'd certainly want some way of specifying "no episodes." If that becomes some sort of explicit thing so that mappers can choose whether they skip the episode screen or show a menu with a single choice, then that's fine I guess, in case someone really wants it. :P

 

re: fabian's suggestion, does UMAPINFO have any mechanism for specifying the start map other than an episode directive? If not, the suggestion makes it impossible to move the start map in Doom 2 to anything other than MAP01 without popping up a single-episode menu, which could be undesirable. This seems like an edge case, but KDIKDIZD hits it again (it starts on MAP13 so the secret exit goes in the right slot in vanilla).

 

[EDIT] thinking on it again, if "episode = clear" implicitly sets the start map to whatever map it's on, then that would totally work. Lets people pick whichever of the two behaviors they want, weird or otherwise. ;P

Edited November 12, 2022 by Xaser

[dasho]

Even before we started implementing UMAPINFO, we adjusted our DDFGAME behavior to not show an episode select menu if only one valid episode exists for the files that are loaded. As long as it doesn't fail to parse and starts on the correct map, I don't see why this shouldn't be implementation-defined. It feels like a gray area between the proper handling of a UMAPINFO lump and what your source port does with that information.

[Herr Dethnout]

Let me tag @bradharding, the developer of Doom Retro who also added UMAPINFO support.

[Doomy__Doom]

Not a dev, but I have released a level that interacts with the issue - a single-level pwad using MAP09 where I used umapinfo to spare the player an idclev (in this particular case map09 choice was for a joke/because I can). Back in testing I thought showing a single episode menu was weird, but the spec didn't say anything so I decided to not raise a discussion. So random thoughts, hopefully helpful:

 

1) I personally don't like "implementation defined" approach - it leads to gotcha moments at best, and arcane knowledge like "-" for cross-port invalid patch definition at worst.

 

2) "Show nothing if only 1 ep is defined" is certainly an option, although it sucks if someone is weirdly attached to their episode name like I was attached to slot 09. Other potential clashes - demo/teaser or WIP release, I guess.

 

3) Starting from arbitrary slot is desirable behavior for non-joke cases - if nothing else, afaik map 30 telefrag behavior cannot be enforced on an arbitrary slot via umapinfo. Things like map07 and secret exits are arguably covered, but clash with desire for pure vanilla compat (I guess KDIKDIZD is precisely this case?).

 

4) "Episode = clear + no episodes" as "start here" indicator sounds like it could work. Admittedly, so far I've put in both episode = clear and my episode(s) to be safe since the spec says it should be used if planning to define episodes and I doubt I'm the only person who read it as "I'd better use it, even if Doom 2 has no episodes", but oh well. That's more of a me problem I suppose.

 

Edited November 12, 2022 by Doomy__Doom

[JadingTsunami]

The only real use of episodes is to create menu select screen options as we know. The single episode = no menu option allows a sort of side-way of selecting the start map.

 

"episode = clear" marking the starting map would seem like a surprise to me and not intuitive. So I would avoid it personally. It will also break in today's implementations (e.g., in PrBoom-Plus one can move the cursor to invalid locations and crash the game) and for that reason would not be backward-compatible.

 

Better could be to specify the episode as today and a new key "showepisodemenu = true/false" to provide explicit instructions on whether to show the episode menu or not for single-episode campaigns. Since unexpected key/value pairs are ignored this should be backward-compatible.

[rfomin]

I think we can add an explicit "startmap" field for this case and not show the single episode menu for compatibility with PrBoom+/GZDoom etc.

 

While we're here, can we consider other UMAPINFO updates?

1. Update map entries instead of replacing them when parsing multiple UMAPINFO lumps. Discussion at PrBoom+ GitHub: https://github.com/coelckers/prboom-plus/pull/391

2. Sky Scrolling field (feature request from @Arsinikk)

3. Ability to disable text screen at episode/game ending. This is a problem for demo compatible ports (PrBoom+/DSDA-Doom/Woof), it seems GZDoom works correctly.

[Altazimuth]

I would appreciate if we address ancillary concerns after a concensus is reached on the main matter. I'd like to try keep things focused for now.

[Lobo]

21 hours ago, Altazimuth said:

...is that dsda-doom (via PR+UM) and GZ have the reference implementations, so their behaviour should be considered the correct one and codified as such...

Even though both have different behaviours with other commands? i.e. the end map08 of DBP36:Aquatic_wonder.
DSDA(and EDGE-Classic and Woof!) do one thing, GZDoom does another for example.

Edited November 13, 2022 by Lobo

[rfomin]

19 minutes ago, Lobo said:

i.e. the end map08 of DBP36:Aquatic_wonder.
DSDA(and EDGE-Classic and Woof!) do one thing, GZDoom does another for example.

 

The original implementation in PrBboom+UM has some bugs, and DSDA-Doom inherits them, and we've copied them over to Woof for the demo compatibility. The implementation in GZDoom is slightly different and more correct in most cases. For example, in PrBoom+ you can't turn off the text screen at the end of an episode, but it works in GZDoom (although I may have forgotten the details).

[dasho]

What is the bug in this case? We show the intermission screen and text after MAP08 as defined in the UMAPINFO lump, so does Eternity and DSDA. GZDoom doesn't. Is this a setting I'm missing, or simply a case of implementation differences? At first blush, it would seem the former behavior is 'more correct.'

[rfomin]

5 minutes ago, dasho said:

We show the intermission screen and text after MAP08 as defined in the UMAPINFO lump, so does Eternity and DSDA. GZDoom doesn't. Is this a setting I'm missing, or simply a case of implementation differences? At first blush, it would seem the former behavior is 'more correct.'

Perhaps this is a bug in GZDoom. My point is that there are bugs/inconsistencies in Pr+UM/DSDA/Woof's implementation of UMAPINFO. 

[Graf Zahl]

The main issue here is that the internal handling of map progression is very different between ports. Since this part had been completely redone and generalized in ZDoom long ago it was quite natural to extend the existing rules to UMAPINFO in GZDoom.

Writing the corresponding code for PrBoom+ was an entirely different matter and I may have missed a few details as a result. This code needs to handle the defaults after all which GZDoom does not - all internal episodes are defined with MAPINFO after all.

 

Regarding the single episode thing, this is also just a carryover of the ZDoom rules. As a menu with a single entry is redundant and for Doom 2 it needs to skip this single entry menu anyway to be 'correct'. this is what happens with UMAPINFO and what I implemented in PrBoom+ as well.

 

Regarding the summary screen, it gets skipped in E?M8 because the original MAPINFO record says so. UMAPINFO does not touch that field.

 

[jeff-d]

Knee-Deep in KDiZD has the following in the UMAPINFO:

 

    episode = clear
    episode = "", "", "1"

This clearly isn't meant to be shown.

[Altazimuth]

4 minutes ago, jeff-d said:

Knee-Deep in KDiZD has the following in the UMAPINFO:

<snip>

That is not accurate as of the latest release, which fixes that issue.

[rfomin]

4 hours ago, Altazimuth said:

That is not accurate as of the latest release, which fixes that issue.

Not yet, at least not in "Public Build 3". Anyway, we decided to bring Woof in line with Pr+/DSDA/GZ.

[Altazimuth]

17 hours ago, rfomin said:

Not yet, at least not in "Public Build 3".

Are you sure you have Public Build 3? It's fixed in mine. Anyway, I will try and work on a hack to make Eternity behave the same as the rest of them. I already have one working, I just need to make sure it works properly.

EDIT: It works properly in Eternity now.

Edited November 14, 2022 by Altazimuth

[Ralphis]

Tagging @Death Egg and @killingblair, as they put in varying degrees of work on Odamex's umapinfo implementation.

[Death Egg]

 

On 11/20/2022 at 9:04 AM, Ralphis said:

Tagging @Death Egg and @killingblair, as they put in varying degrees of work on Odamex's umapinfo implementation.

Specifically, I was the one who did the initial implementation. It was a direct port of the code from PR+UM, I tried to be as faithful to that implementation as possible, also using GZ as reference too when necessary.