[GZ 4.1.3] UMAPINFO and ZDoom clusters do not mix well

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: [GZ 4.1.3] UMAPINFO and ZDoom clusters do not mix well

Re: [GZ 4.1.3] UMAPINFO and ZDoom clusters do not mix well

by Enjay » Wed Jun 19, 2019 11:44 am

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?

Re: [GZ 4.1.3] UMAPINFO and ZDoom clusters do not mix well

by Graf Zahl » Tue Jun 18, 2019 1:17 pm

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.

Re: [GZ 4.1.3] UMAPINFO and ZDoom clusters do not mix well

by Shadow Hog » Tue Jun 18, 2019 1:07 pm

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.

Re: [GZ 4.1.3] UMAPINFO and ZDoom clusters do not mix well

by Graf Zahl » Tue Jun 18, 2019 12:55 pm

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

Re: [GZ 4.1.3] UMAPINFO and ZDoom clusters do not mix well

by Enjay » Tue Jun 18, 2019 12:46 pm

I don't know about the UMAPINFO spec, but could a new (z)mapinfo specific cluster format not also call a named exittext too?

Code: Select all

Textblock "MyCoolEnteretext"
{
flat = FLAT1
music = D_RUNNIN
Text = 
"blah blah",
"blah blah."
}

Textblock "MyCoolExittext"
{
flat = FLAT2
music = D_RUNNI2
Text = 
"meh meh",
"meh meh."
}



clusterdef 1
{
flat = FLAT14
entertextnamed="MyCoolEntertext"
exittextnamed ="MyCoolExittext"
}
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.

Re: [GZ 4.1.3] UMAPINFO and ZDoom clusters do not mix well

by Graf Zahl » Tue Jun 18, 2019 12:41 pm

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

Re: [GZ 4.1.3] UMAPINFO and ZDoom clusters do not mix well

by Graf Zahl » Tue Jun 18, 2019 11:02 am

That neither mixes with the needs of clusters nor UMAPINFO.

Re: [GZ 4.1.3] UMAPINFO and ZDoom clusters do not mix well

by Enjay » Tue Jun 18, 2019 10:59 am

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.

Re: [GZ 4.1.3] UMAPINFO and ZDoom clusters do not mix well

by Graf Zahl » Tue Jun 18, 2019 3:20 am

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.

Re: [GZ 4.1.3] UMAPINFO and ZDoom clusters do not mix well

by Graf Zahl » Tue Jun 18, 2019 12:20 am

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? :?

[GZ 4.1.3] UMAPINFO and ZDoom clusters do not mix well

by Shadow Hog » Mon Jun 17, 2019 5:03 pm

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.

Top