"UMAPINFO" discussion

[printz]

Typical @Graf Zahl issuing ultimatums instead of trying to understand from my POV. I'll have none of this while playing Doom (whatever playing means). I'll just support UMAPINFO so that MBFish wads don't have to write EMAPINFO.

 

The examples on the post before mine already look stupid with the lump name shoved in front. 

 

Edited June 25, 2019 by printz

[Graf Zahl]

29 minutes ago, Ferk said:

 

 

I assume "Hub 1: Badlands" in GZDoom has the "Hub 1:" as part of the actual level name instead being the label, and GZDoom defaults to not show the label in Hexen in an attempt to workaround its own assumption that it's the lumpname what should be prepended and not a custom string that coincidentally could match the lumpname. 

 

Hexen never shows the map label or hub label. The default is to just show "Badlands" (The actual text in the internal MAPINFO is "BADLANDS", actually.) This is also the default in GZDoom, but there's a user side option to force the map label to be shown. So it's either "Badlands" or "MAP45: Badlands", depending on how you have set it.

 

 

29 minutes ago, Ferk said:

Just like how you get "E1M1: C1M1: Outer Prison" in Freedoom.

 

This is precisely the edge case I was talking about where the engine cannot take apart the string because the map label bears no machine recognizable pattern to find.

If this bothers you in GZDoom, switch the map label display off, but in the end that's a poor solution for something that should be dealt with in a sane fashion. Having both of these things lumped together in one string is just a relic of a long gone past, that should be avoided in future features, not encouraged. Just because something is "as it always has been" doesn't mean it's not broken.

 

And it's precisely this case I was trying to avoid by defining a sane and well defined framework, but got ultimately sabotaged by Printz.

 

 

 

 

 

 

[Graf Zahl]

30 minutes ago, printz said:

Typical @Graf Zahl issuing ultimatums instead of trying to understand from my POV.

 

Your POV was to blatantly ignore all sane settings for a standard (as already implemented by the two supporting ports!) and instead forcing your view of things without any compromise. I tried to give you a compromise that would have worked fine for every eventuality but instead you dumped a mess on me and the modders to sort out I am not willing to sort out.

 

Seriously, what reaction did you expect here? It makes no sense defining a standard if one person in power chooses to ignore it, despite opposition by everybody else weighing in their opinion.
 

[Mordeth]

11 minutes ago, Graf Zahl said:

 ultimately sabotaged by Printz.

 

Can we tone down the outright hostility here, please? To make absolutely sure: this is not a question.

[Ferk]

57 minutes ago, Graf Zahl said:

And it's precisely this case I was trying to avoid by defining a sane and well defined framework

 

Other engines show "C1M1: " instead of "E1M1: C1M1: " by default so I'd say ZDoom is already deviating from the spec set by the BEX Strings.

You might think it's worth to break the BEX convention. I'm not saying that's wrong... just saying that each engine author might have its own reasons to deviate in small points from whichever standards they might want to follow.

 

I think printz and you have different concepts on what's a "mess" and what's "sane".

 

I still think it's ok to leave each engine have whatever they want as a default as long as there's a way for mappers to clearly define their intent, if the "Label" field is not included, then there's no way for the mappers to define any intent and then that's when it will be a mess, because then people will be forced to include "C1M1" in the levelname. That will look ok in Eternity, but bad in GZDoom. I think it's in GZDoom's interest to have it be part of the standard, honestly.

[Altazimuth]

3 hours ago, Gez said:

My two cents on the topic of map label: the wiki.

https://doomwiki.org/wiki/MAP01:_Entryway

The intermission screen calls it "Entryway", the automap calls it "Level 1: Entryway", community people tend to call it "MAP01" or "Entryway" or similar, so going by the wiki's article naming convention isn't a sure thing.

 

At this stage I'd put forward my idea: A defaults section.

I didn't want to bog implementation down with this feature but it seems like it can solve this issue, so I'll put forward an extra thing.

Within the defaults section can be a default label which is some kinda format string, though such a feature would be a bit of a kludge to get reasonably flexible (you'd need specifiers for lump name, episode number, map number, overall number, and the ability to have precision or whatever if you wanted something like "LEVEL 01").

 

Then you can just default the label to nothing and if people want the label can be "%l" for lump or whatever.

[printz]

@Graf Zahl I think you're just preventing potential users from using custom labels by forgoing the "label" key. Map names will start looking cookie-cutter because of that. What if a megawad has two alternating paths and one wants to call them E1M3A and E1M3B? As far as I know, PrBoom+UMAPINFO doesn't yet support custom lump names. If you read my post again, I never said I'm absolutely against showing the label. The behaviour I'm thinking of:

1. "label" unspecified: hide it in the automap (may reconsider if label=clear is available), definitely show it in the EE console. Anyone curious will be able to lower the console to see the map number. It will not be there for nothing.
2. "label" specified: obviously always show it.
3. And....... If the "label = clear" variant is accepted, I may decide to hide the label in the automap only in that case, while otherwise it would always show up, in all its "MAP57" or "Le niveau cinquante-sept" glory. Fine with this? 

Are you worried people might be incentified to put the label in the leveltitle and mess up other ports' display? I guess I'll emphasize in the EE wiki to avoid doing that.

 

@Altazimuth dunno, that looks programmerish to me...

Edited June 25, 2019 by printz

[Ferk]

6 minutes ago, printz said:

Are you worried people might be incentified to put the label in the leveltitle and mess up other ports' display? I guess I'll emphasize in the EE wiki to avoid doing that.

 

Honestly, this looks like a good reason to show something as a default. People are lazy and not everyone reads documents. And including MAP01 in the levelname actually saves some typing than adding a new line with "Label" (again, lazyness).

It seems reasonable to expect that the default behavior should be the most common and traditional behavior.

[Altazimuth]

I think including the label by default just isn't intuitive. It makes a lot more sense to manually add a label to the name of the map than remove it. Also it takes me reading and effort to know you have to manually set the label.

[Ferk]

4 minutes ago, Altazimuth said:

I think including the label by default just isn't intuitive. It makes a lot more sense to manually add a label to the name of the map than remove it. Also it takes me reading and effort to know you have to manually set the label.

 

I think the main problem with this is that then you are forced to have a picture for the intermission title that's shown between levels, which currently falls back to the levelname text when no levelpic is provided. Traditionally, Doom does not show the label there.

 

And it's possible some other ports might want to use the levelname (without label) in other port-specific places.

[Shadow Hog]

3 hours ago, printz said:

@Graf Zahl I think you're just preventing potential users from using custom labels by forgoing the "label" key. Map names will start looking cookie-cutter because of that. What if a megawad has two alternating paths and one wants to call them E1M3A and E1M3B? As far as I know, PrBoom+UMAPINFO doesn't yet support custom lump names. If you read my post again, I never said I'm absolutely against showing the label. The behaviour I'm thinking of:

1. "label" unspecified: hide it in the automap (may reconsider if label=clear is available), definitely show it in the EE console. Anyone curious will be able to lower the console to see the map number. It will not be there for nothing.
2.  "label" specified: obviously always show it.
3. And....... If the "label = clear" variant is accepted, I may decide to hide the label in the automap only in that case, while otherwise it would always show up, in all its "MAP57" or "Le niveau cinquante-sept" glory. Fine with this? 

 Are you worried people might be incentified to put the label in the leveltitle and mess up other ports' display? I guess I'll emphasize in the EE wiki to avoid doing that.

This works for me, provided #3 is in fact the case. I think everyone in this argument was cool with "label = clear", yes?

[printz]

Yeah, maybe the way I worded "I may" makes it sound like I'm still undecided, but it's pretty clear.

 

Label missing: display_name = lumpname + ": " + levelname

Label given: display_name = label + ": " + levelname

Label "" or clear (you pick one): display_name = levelname.

 

I just want a way to disable label.

 

I'll only do all this with UMAPINFO and potentially anything derived from it, the rest stays grandfathered in Eternity.

[dew]

Just so you know... Romero seems to want a 1.2 of Sigil and I've been cooperating with a few guys on patches. Including UMAPINFO seems like a logical choice, but it needs to be... presentable. Get that shit straightened out, please.

[Shadow Hog]

Apologizing in advance for tooting my own horn, but I went ahead and released a version of the mod I've been working on using this feature. So, now there's content using it you can test against.

 

In fact, while I'm aware there's still discussion to go about how UMAPINFO WAD demos are going to need to be formatted going forward, I've nevertheless made a recording of me playing through one path of the mod, going across two secret exits and such. Plays back fine in PrBoom+/UMAPINFO 2.5.1.7. IDK if this is of any use to anyone, but in case it is, there you go.

 

I do have another feature to request, though I'm not sure how we'd go about implementing it (and if it doesn't happen, I can deal with it): some way to do Doom [1]-esque splats/"YOU ARE HERE" on the intermission screen, indicating where you are and where you've been. Given the nature of the mod I made, having some way to track what maps you've visited on a chart would be useful. Granted, I'm not sure how it's handled in the original Doom; maybe it just blindly puts splats on every map before the current one, maybe with a special case for secret maps? I haven't paid very close attention to it, I admit. (EDIT: I went ahead and checked it and it does appear to do exactly that, blindly put the splats on every map before the current one. Didn't check how it handled secret levels.)

 

17 hours ago, dew said:

Just so you know... Romero seems to want a 1.2 of Sigil and I've been cooperating with a few guys on patches. Including UMAPINFO seems like a logical choice, but it needs to be... presentable. Get that shit straightened out, please.

That would be a great way to promote the feature. What more do you think needs to be done as far as presentation goes?

 

Edited June 27, 2019 by Shadow Hog

[Xyzzу]

I would like to have no map labels displayed, too, pretty please!

Also, is ResetHealth and ResetInventory possible in UMAPINFO yet? It'd be nice to completely forgo old-fashioned death exits!

[fabian]

On 6/27/2019 at 1:23 AM, dew said:

Just so you know... Romero seems to want a 1.2 of Sigil and I've been cooperating with a few guys on patches. Including UMAPINFO seems like a logical choice, but it needs to be... presentable. Get that shit straightened out, please.

 

And this depends on the specification of the "label" key? Others have already provided a UMAPINFO lump for Sigil, so...

[Graf Zahl]

On 6/27/2019 at 5:24 AM, Shadow Hog said:

I do have another feature to request, though I'm not sure how we'd go about implementing it (and if it doesn't happen, I can deal with it): some way to do Doom [1]-esque splats/"YOU ARE HERE" on the intermission screen, indicating where you are and where you've been. Given the nature of the mod I made, having some way to track what maps you've visited on a chart would be useful. Granted, I'm not sure how it's handled in the original Doom; maybe it just blindly puts splats on every map before the current one, maybe with a special case for secret maps? I haven't paid very close attention to it, I admit. (EDIT: I went ahead and checked it and it does appear to do exactly that, blindly put the splats on every map before the current one. Didn't check how it handled secret levels.)

 

Since I wouldn't want to reinvent the wheel, I'd just copy over that part from GZDoom and use the same definition files, if I were to implement such a thing. It's certainly doable without too much effort.

[Phobus]

I've just given this a go with a currently WIP project that was using ZMAPINFO but is otherwise just limit-removing and I'm very happy with it. In fact, it's almost everything I could have hoped for, plus some intermission screen and BossAction customisation I wouldn't have been brave enough to request. I really hope this takes off so that the traditional megaWAD format is less prevalent in the future and we get more tailored episodes. Like Xyzzy01 I'd be pretty keen to see ResetHealth and ResetInventory (or a "pistol start" equivalent key). It would also be nice if any map that doesn't have a specified InterText, but is specified in a UMAPINFO lump, is set to "= clear" by default, rather than MAP06, 11 and 20 giving us the Doom II script, but I understand that this default behaviour may be in for a reason.

 

I'll have a look through the bug reports for this and see if I've got anything to add, but so far I've noticed GZDoom 4.1.3 crashing outright if I specify an incorrect string for music or a graphical lump name (e.g. episode title patches) and not getting a difficulty selection choice with custom UMAPINFO episodes. Otherwise the parser is letting me know when stuff is missing in the console like I'd expect.

[Graf Zahl]

If you experience crashes with GZDoom, please report them in the proper place so that the reports do not get lost.

 

[DoomGater]

On 7/15/2019 at 7:37 PM, Graf Zahl said:

If you experience crashes with GZDoom, please report them in the proper place so that the reports do not get lost.

 

No offense intended, but a link would be helpful for the unknowing...:-)

[Graf Zahl]

There was no "unknowing" one, though. :P

 

[Phobus]

I'm working on a UMAPINFO megaWAD and have a functional definition together for 31 maps, with custom episodes and whatnot and that's all working pretty well, barring the various known bugs that are being fixed.

 

I've not noticed any definition or handling of monster telefragging behaviour in the documentation. Does that mean that MAP30 will always have the default behaviour to allow the Icon of Sin to be useable? If so, it's not a major issue as I can just use a different map slot and skip 30 entirely.

[ketmar]

what will be really helpful is umapinfo->zmapinfo converter module. so i can take it and integrate into k8vavoom. i'm not going to implement umapinfo anyway, but with ready-to-use module... yes, i know, DIY and all that. but it doesn't hurt to ask first. ;-)

 

like, literally, parse umapinfo, and build a textbuffer with zmapinfo. so i can feed it to zmapinfo parser.

[Graf Zahl]

2 hours ago, Phobus said:

I've not noticed any definition or handling of monster telefragging behaviour in the documentation. Does that mean that MAP30 will always have the default behaviour to allow the Icon of Sin to be useable? If so, it's not a major issue as I can just use a different map slot and skip 30 entirely.

 

Correct. That part hasn't been addressed yet, as is also the case with compatibility flags and a few other things that may warrant configurability.

 

@ketmar: That's not going to work out because both lumps are semantically different. UMAPINFO builds on game defined map defaults, like predefined intermissions or monster death actions, while ZMAPINFO never inherits anything from a previous map definition - it always builds upon the current defaultmap. If you try to do an intermediate conversion, that conversion has to add all the predefined defaults to its output, at which point keeping both parsers separate becomes less work. There's a reason why I haven't merged both in GZDoom.

 

 

[ketmar]

@Graf Zahl tnx, i see. RIP to umapinfo support in k8vavoom.

[Ferk]

Since the issue about the level label did reach some consensus... are there any further points that could be a problem for backwards compatibility before Sigil v1.2 is released? (which includes UMAPINFO and it seems like it might be soon)

 

In particular, it might be good to clarify these two points from printz:

 

On 6/22/2019 at 11:04 PM, printz said:

• endgame=true: unless endpic is set, this sounds like I should scan the lump name if it starts with E1M, E2M etc., and use one of the canned Doom endings. Perhaps for nonstandard lump names I can just use the most basic choice from the game (i.e. credits screen).
• endpic. If set to a valid lump, does it require endgame=true to have any effect?

 

For the second point: it seems from umapinfo.cpp that endgame=true actually overrides the endpic. So if you have both endpic and endgame in the same umapinfo definition for a map, the last one written would be the one in effect.

 

According to the documentation, "endgame=true" is meant to show the vanilla ending for the map, and "endgame=false" would remove any ending scene previously set.

endgame = false				; Overrides a default map exit (e.g. ExM8 or MAP30)
endgame = true				; Ends the game after this level, showing the default post-game screen for the current episode.
endpic = "graphic"			; Ends the game after this level, showing the specified graphic as an end screen.
endbunny = true				; Ends the game after this level, showing the bunny scroller.
endcast = true				; Ends the game after this level, showing the cast call.

All these options are mutually exclusive. You only need to provide one of them, and the last one provided is the one in effect (even writting  "endbunny=false" would also reset the endpic and have the same effect as "endgame=false").

I think "endgame" wasn't really a good choice of a name, although I can't come up with anything better ("endvanilla"? "enddefault"?)

 

About the first point, this might require more testing. From the code it seems that it's setting endpic to an internal special value ("!") in the prboom-plus fork, but I don't find any logic that checks for this when actually showing the ending scene. So I'm not sure how it actually works, or if it actually works.

Edited August 12, 2019 by Ferk

[Shadow Hog]

On that note, it might be nice if we could extend "endbunny" to support arbitrary images and/or directions. I assume, as it stands, it literally only offers the ability to use "PFUB1" and "PFUB2", starting on the former and scrolling left to reveal the latter, as per the end of Episode 3 of Doom.

[printz]

39 minutes ago, Shadow Hog said:

On that note, it might be nice if we could extend "endbunny" to support arbitrary images and/or directions. I assume, as it stands, it literally only offers the ability to use "PFUB1" and "PFUB2", starting on the former and scrolling left to reveal the latter, as per the end of Episode 3 of Doom.

Yeah but do mind that both "endbunny" and "endcast" are provided to allow the highly specific sequences grandfathered from original DOOM. "Endbunny" is not just scrolling two screens, it also splats "THE END" using the handgun sound, and has that music. The only example which follows your suggestion exactly is the Heretic E3 ending. Your suggestion raises the question about adding even more end-scene animations later along the way. To avoid cluttering the UMAPINFO fields with niche items, perhaps better is to think about a scripting language for end-game scenes, as they can vary a lot in complexity. Maybe this is out of UMAPINFO's scope, whose role was (I assume) just to raise PrBoom+'s stakes a bit to the 21st century (not to turn it into some kind of Eternity), mainly to escape the 32-level jail.

[Graf Zahl]

The biggest problem with such things is not defining them, it is that the current intermission/end sequence code is barely prepared to handle such things. It will need some refactoring, and if we want to repurpose already existing implementations, like the one I made for ZDoom many years ago, some code in there will have to be ported to C++. As long as PrBoom+ is a pure C-application, disregarding the minor bits of C++ code in the UMAPINFO parser it will always be an uphill battle to borrow code from other projects.

 

This also runs the risk of breaking demo compatibility if we are not very careful about what's allowed to be used where.

 

 

[printz]

8 hours ago, Graf Zahl said:

As long as PrBoom+ is a pure C-application, disregarding the minor bits of C++ code in the UMAPINFO parser it will always be an uphill battle to borrow code from other projects.

I wouldn't listen to anyone who complains about presence of C++ in a mostly C (by legacy) project (unless they own it, that is). Extern "C" markers will always be there to solve this interop problem.