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.
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:
[list][*]MAP06 normal exit
[*]MAP11 normal exit
[*]MAP15 secret exit
[*]MAP20 normal exit
[*]MAP30 normal exit
[*]MAP31 secret exit[/list]
Secret exits for all of the entries listed with normal exits [i]may[/i] 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.
[url=https://dl.dropbox.com/s/tk7okh6ylvjwbn5/20190617a_UMAPINFOBugExample.zip]Here is a ZIP file containing three WADs.[/url] 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:
[list][*]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).[/list]
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 [url=https://zdoom.org/files/examples/mapinfo-doom2.txt]this page with an example MAPINFO for [i]Doom II[/i][/url]).
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 [b]if[/b] it's fixed, even - up to you all.