ZDoom

There is an inconsistency between PrBoom+/UMAPINFO 2.5.1.7 and GZDoom as to how intermission screens are handled, and when to clear them out in UMAPINFO using the "InterText = clear" keyword. To my understanding, PrBoom+ will only display the default intermission texts if the map progression is any of the following:

• MAP06 normal exit
• MAP11 normal exit
• MAP15 secret exit
• MAP20 normal exit
• MAP30 normal exit
• MAP31 secret exit

Secret exits for all of the entries listed with normal exits may also show the intermission screen but I am not 100% at the moment on if they do or not.

If no intermission screens are desired to be shown, it is a simple matter to define "InterText = clear" or "InterTextSecret = clear" (as relevant) for the specified exits; that will remove all of the text screens for PrBoom+. However, due to how these are handled in GZDoom with clusters, a lot more would be required; any transition from one predefined cluster to another would require an accompanying "InterText[Secret] = clear" to stop the predefined intermission text screen from displaying.

Here is a ZIP file containing three WADs. Only UMAPINFOBugExample.wad is particularly relevant to this report; the others are present for other bug reports. The UMAPINFO is set up such that no intermission screen displays on PrBoom+/UMAPINFO 2.5.1.7; however, a few still show up in GZDoom, specifically:

• transitioning from MAP05->MAP08 (take the secret exit);
• transitioning from MAP13->MAP11 (take the normal exit);
• or transitioning from MAP12->MAP11 (take the secret exit).

There is no question in my mind that this is because you're leaving clusterdef 5 in the first case, and leaving clusterdef 7 in the latter two cases, in each case triggering the appropriate ExitText definition internally defined in the GZDoom executable (as per this page with an example MAPINFO for Doom II).

To be honest, I don't know if this would be an easy fix, but I leave the decision on how it's fixed - or if it's fixed, even - up to you all.

Tying the exit texts to the clusters instead of the maps was one of the dumbest things ZDoom ever did. I would have liked to undo this 14 years ago already, but how if so much material depends on such a broken system?

Thinking about it, the only workable solution I can come up with is to deprecate exit texts in clusters and remap them to the respective maps after parsing, and add a feature to regular MAPINFO to do it like UMAPINFO. Once the exit texts are solely defined in the maps themselves the problem should resolve itself. This is going to be messy, though, to allow full backwards compatibility.

I was just thinking something like that might be required.

As a slight alternative, rather than defining exit texts in a map definition, would there be any merit in defining them in a similar way to endgame and intermission texts? I.e. a block that defines the text, the background, the music etc that can then be called from the map definition. The first obvious benefit I can see there is that different maps could call the same text definition without the need to copy/paste the whole thing for every map.

That neither mixes with the needs of clusters nor UMAPINFO.

Should be better now. I hope I haven't overlooked something.

I don't know about the UMAPINFO spec, but could a new (z)mapinfo specific cluster format not also call a named exittext too?
Obviously that pseudocode is a mess, but that's the kind of idea that I was thinking of, and maps could call the texts too.

I can't think of any scenario where two map transitions may have the same text.

The only scenario I can think of for such a thing is if the cluster had an EnterText, and thus any transition into it would display that screen. That would be a curious setup, but I cannot claim to say nobody would ever want it - maybe it's super important that they see that particular text blurb before that particular map.

It's not like that's hard to implement in UMAPINFO if it comes to that, though; just liberally use copy-paste for any map transitioning in there. Prone to propagating errors as copy-pasting is wont to be, of course, but doesn't require anything special.

Enjay: If you're interested, the UMAPINFO spec is right here.

Shadow Hog wrote:The only scenario I can think of for such a thing is if the cluster had an EnterText, and thus any transition into it would display that screen.

That case is already covered by the current cluster definitions.

Multimap setup with alternative branches coming back together at certain points?

Fairly generic ending texts (or intro texts) just to set up some context for a series of separate mission maps or give a generalised "well done" and maybe some credits?