UMAPINFO cross compatibility investigation

[elf-alchemist]

The inclusion of port-exclusive *MAPINFO type lumps, in addition to UMAPINFO, is inadmissible. Any and all situations in which an actively maintained port (such as GZDoom, for example) requires the addition of it's own *MAPINFO type (ZMAPINFO, for example) are to be considered bugs and a limitation of the UMAPINFO, requiring consideration in later revisions.

UMAPINFO implies defaulting/falling-back to vanilla hardcoded values, any difference in such behavior across ports (forcing the inclusion of every map property) is a bug -- the same UMAPINFO lump should work the same, no matter what, across each and every UMAP-compliant port.

The QoL patch DW thread is a prime example of the unnecessary extra work put into duplicated lump types and possible excessive property definitions.

Points to investigate:

• fallback values, how does each active UMAPINFO port default to vanilla values, on each and every slot?
• is each parser similarly behaved? does it give warnings, fatal errors, or remains silent upon encountering an unknown keyword?
• which areas are demo-breaking or not? which parts can be safely changed, or have to stay the same as current demo-accurate ports, i.e. Woof, DSDA, Eternity?

[elf-alchemist]

https://www.doomworld.com/forum/post/2972065

From @andrikpowell:

Examples being Doom 1 vs Doom 2, UMAPINFO or not, Pressing a key to push text forward or not, etc. The behaviour even changes depending on the Complevel (Vanilla vs "Boom and Up").

Regarding Vanilla behaviour this is how it currently works:

• Doom 1 / Heretic - Unable to press key to move text forward. Once it reaches the end, it will pause for a bit and then move forward to the end episode screen
• Doom 2 - Can press key to skip text screen. When pressing a key, the text screen does NOT skip to the end, but will move onto the next map. If you just let the text screen play out, once it reaches the end, it will wait indefinitely for the player to press a key to move forward.

Regarding "Boom and Up" behaviour:

• Doom 1 - Same as Vanilla.
• Doom 2 - Can press key to move text forward (NOT the same as the Vanilla "skip"). When pressing a key, the text screen will speed up to fill the entire screen, and then wait, eventually entering into the next level automatically. If you just let the text screen play out, once it reaches the end, it will wait indefinitely for the player to press a key to move forward.

Regarding UMAPINFO behaviour (overrides Vanilla/Boom behaviours above - complevel does nothing to change UMAPINFO behaviour):

• Doom 1 - Unlike Vanilla/Boom, you can press a key to move text forward. Note that regardless of pressing a key or not, it will automatically move forward to the end episode screen.
• Doom 2 - Can press key to move text forward. Regardless of waiting for the text, or pressing a key to move it forward, the text screen will eventually move forward unto the next level automatically. 

It's worth noting that in the latest Nyan Doom update, I've tweaked some of this behaviour for casual play (meaning no demo recording / playback). I have the Doom 1 screens all use the "UMAPINFO" Doom 1 behaviour (so that you can skip move the text forward on Doom 1 AND Heretic text screens), and I tweaked the Doom 2 "Vanilla" behaviour to match the "Boom and Up" behaviour instead.

[andrikpowell]

Regarding UMAPINFO behaviour (overrides Vanilla/Boom behaviours above - complevel does nothing to change UMAPINFO behaviour):

Honestly I'm not a big fan of the current UMAPINFO behaviour of "auto advancing" to the next map / screen. I don't think I've met many people that like that it auto advances, and would prefer to move it forward via a key press (so that you can read the story screen on your own time).

[electricbrass]

I definitely always prefer it waiting til I press a key, and for pressing a key before the text is all onscreen, for it to draw the rest of the text and wait. If it were up to me, it would always be that behavior, all the time.

[elf-alchemist]

EndGame problems, how does each port handle it on Doom/UltimateDoom ExM8?

From @thecnoNSMB:

for some reason the scroller after episode 3 crashes dsda with a segfault, any idea why? (wad from devalaous's QoL patches thread, edited by me to convert the png patches to doom format)
serenity_fix_fix.zip

@andrikpowell:

I assume it's using UMAPINFO?
Is E3M8 missing endbunny?

Noticed that DSDA doesn't like it when endbunny isn't specified for E3M8.

Tbh prob should fix that or do something to avoid a crash...

@thecnoNSMB:

that occurred to me as i was going to sleep last night, and that does in fact seem to be the issue:

map E3M8
{
    LevelName = "Church of the Poisoned Minds"
    LevelPic = "WILV27W"
    Label = "E3M8"
    Music = "D_E3M8"
    SkyTexture = "SKY3"
    Endgame = true
}

I don't believe a segfault is the correct way to handle that lol

[thecnoNSMB]

For context, the quoted discussion took place on the "Hell On Earth" DSDA-Doom Discord server. I am not a source port developer, just a curious gamer.

[elf-alchemist]

team-eternity/eternity#722

is there a reason why in the EE UMAPINFO handling the parser sets endcast and endbunny to PropertyType::setTrue rather than ::setBoolean? was this a mistake or do they always have to be true?

I only ask because EE currently cant handle UMAPINFO lumps that try and set endcast or endbunny to false and it seems like itd be a simple fix. I could make a pr for it rn

I was trying to play Tele-Direct Atlantic Doom, an MBF21 wad which recommends Nugget Doom, DSDA-Doom or Woof. Since EE is MBF21 compatible, I decided to try and play it in. When attempting to load the wad, it hits endcast (and presumably would also hit endbunny) and aborts loading. So perhaps these ports have diverted from the spec?