"UMAPINFO" discussion

2 hours ago, esselfortium said:

• Is there any plan for allowing sourceport-specific keys in this, so that users are less likely to feel the need to create 18 different mapinfos?

It doesn't seem like there was an authoritative decision on this, but enough people (inc. Quas & Graf) were in favor of the prefix approach (e.g. "zdoom.fancyproperty"; no parser changes required) that it's really worth declaring official at this point, if said key people would be so kind.

Related word of warning to @printz and @Altazimuth: The linked doc doesn't appear to be up to date; it doesn't reflect the curly brace syntax change.

This is really exciting,  I've wanted this feature for so long and we're finally on the brink of it becoming a reality! @bradharding @DaniJAny plans for your source ports to add this? 

Note that the syntax has changed to use curly braces. This was mainly done to use a real tokenizer. The orignal parser wasn't really that great.

The actual keywords haven't changed at all.

2 hours ago, esselfortium said:

Is there any plan for allowing sourceport-specific keys in this, so that users are less likely to feel the need to create 18 different mapinfos?

The format was designed to be able to skip over unknown keys, so yes, that should be doable.

I'd like a text file more than code, especially if it uses curly braces, which are supported as "EDF"/libConfuse in Eternity.

18 hours ago, Quasar said:

I had believed @printz and @Altazimuth were going to handle this stuff. I'm really busy given that I'm now a full-time dev for Nightdive so I've been avoiding these threads until they shifted from debate to a functional implementation.

I think a lot of devs are doing precisely the same thing, which makes sense. Best of luck at Nightdive!

14 hours ago, printz said:

Mostly not wanting to spend time on idle chatter about this until something concrete is done.

Yep, makes sense.

8 hours ago, esselfortium said:

Looks nice, it will be great to see this in some ports!

 

I have a couple questions:

• Which font is meant by the "HUD font"?
• Is there any plan for allowing sourceport-specific keys in this, so that users are less likely to feel the need to create 18 different mapinfos?

Give it time to materialize before it matures...you know, the 'walk before you run' thing.

18 hours ago, Ribbiks said:

https://github.com/coelckers/prboom-plus/blob/master/prboom2/doc/umapinfo.txt

Out of curiosity: I probably don't really know what I am talking about, but is stuff like "allow_jumping" or "force_pistolstart" is out of scope for this? Does UDMF cover this?

It seems like set of simple features that all semi-advanced or advanced ports should be able to support, but it might be not standardized for some historical reason.

16 hours ago, Xaser said:

Is there any plan for allowing sourceport-specific keys in this, so that users are less likely to feel the need to create 18 different mapinfos?

The feature set of the base spec is what a basic Doom port supports, not enhanced things only implemented by feature-centric ports. This stuff is for later.

8 hours ago, Bluefox_1 said:

Out of curiosity: I probably don't really know what I am talking about, but is stuff like "allow_jumping" or "force_pistolstart" is out of scope for this? Does UDMF cover this?

It seems like set of simple features that all semi-advanced or advanced ports should be able to support, but it might be not standardized for some historical reason.

Well not all ports feature jumping, so it wouldn't be a feature of UMAPINFO.  For now this just covers things present in the original Doom.

Force Pistol start might be useful, although there'd need to be some discussion about the best way to implement it (either one method for all ports, or perhaps ports could implement their own method if the end result is the same).  Again, probably not for version 1.  

@Graf Zahl Both printz and I are waiting for specs on the new lump. An updated version of what was already there would be much appreciated.

Personally, I'm busy between weapons-branch work and looking for a new dog; regardless, I don't feel like I'm in any position to attempt to construct an example lump based on reading the parser's code.

I'll try to get one done on Monday or Tuesday.

I feel ultimately that the reason people avoid MAPINFO when they want a more vanilla experience is because using it instantly makes Boom ports unusable. MAPINFO is a zdoom/gzdoom feature only, so if you use it to change the levels you go to or anything like that, it simply wont work.

Is the use of timeline.jpg still banned nowadays?

On 7/8/2017 at 4:17 AM, Altazimuth said:

looking for a new dog

I knew there was something I liked about you ;)

@Phade102The original question wasn't why mappers avoid it, but why other source ports like PRBoom+ avoid it. 

Although with a bit of luck, hopefully they won't for much longer. 

3 hours ago, Bauul said:

@Phade102The original question wasn't why mappers avoid it, but why other source ports like PRBoom+ avoid it. 

 

Although with a bit of luck, hopefully they won't for much longer. 

I agree. it it became something that  PRBoom+ could use, it would completely remove any sort of issues with it.

On 7/8/2017 at 3:40 PM, Phade102 said:

I feel ultimately that the reason people avoid MAPINFO when they want a more vanilla experience is because using it instantly makes Boom ports unusable. MAPINFO is a zdoom/gzdoom feature only, so if you use it to change the levels you go to or anything like that, it simply wont work.

Right: The reason MAPINFO was not used was simply because ports never implemented it in a standard way, or at all. That will soon be a thing of the past!

Trying to look into this today; hopefully XL parser will be able to handle this if slightly extended. EDF cannot due to the ; for comments (# would work though). If I can't get this done today then I just won't be able to do it myself, as we found a dog to adopt and she will be arriving home tomorrow.

You also could just use the parser that is included... ;)

@Graf Zahl: does UMAPINFO allow single-line text? Like this:

map jackson{levelname="michael jackson"endgame=false partime=30}

Yes, but I'm not sure about the missing space after the quoted string.

"Enterpic" from UMAPINFO doesn't look like anything familiar to Doom. Only exitpic (intermission pic) is expected. Enter pic looks like something that would need adding bigger features for.

Have a look at the code in my Github repo and check out the changes. It's far less work than you may think. Most in there should be directly usable in Eternity as well, considering that wi_stuff hasn't changed that much.

The main motivation here was to allow clean transitions between Doom 1 levels from different episodes and show the proper map for each screen. Expanding that to a user-definable feature was very little work after that.

Should strings allow escape sequences or be multiline?

Common escape sequences, including octal and hexadecimal should be supported. Multiline is not needed.

Here are my comments on the "ending" fields of UMAPINFO:

1. "endgame = false / true" only has meaning when overriding the stock level lump names. What if I have a custom level lump name and set endgame=true?
2. "endbunny" and "endcast" seem only useful for source ports and wads very close to original vanilla. They're worthless for any ambitious wad running on more complex source ports. Final presentations and cutscenes are the stuff which is best defined through scripting.
3. "nointermission = false / true": you're saying that it's "Currently only working for levels that end the game" but I really see it useful anywhere, not just there.
4. episode: I guess you want to put the episode menu definition in UMAPINFO too. Why not use a cluster definition like in ZDoom's MAPINFO? I always assumed clusters are like the Doom 2 (or why not also Doom 1) episodes…

The main issue with the above limitations has nothing to do with usefulness but with what I could do with PrBoom's code. Doom's original intermission code is extremely badly coded and PrBoom has done little to fix this. Some stuff simply was not doable without major rewrites which I wanted to avoid.

In particular:

1. This is a misunderstanding. 'endgame = false' only has meaning if you want to clear a default exit. These only exist for the default maps, if you have a custom name it does not come with a default to clear. 'endgame = true' can be used everywhere.

2. So? You still want to be able to set those if they are useful, wouldn't you? Anything more complex simply is beyond the scope of a feature aimed at PrBoom compatibility.

3. I agree but failed to implement that part in PrBoom - the code is too messed up. Feel free to do it right, I will do the same in ZDoom.

4. First and foremost I wanted to keep the feature simple, so the needed info to add an episode entry to the menu is defined in the map definition itself. Clusters really have no meaning here, the way they were used in ZDoom is also something I'd like to fix eventually and make the intermission texts map properties, except for hubs.

You added "levelname" to UMAPINFO, whose presence will result in both automap and intermission name to be changed to that, and the automap text will also be prefixed with the lump name. But what if I don't want the lump name to show up in the automap? Maybe I don't want to expose to the user the internal names (or numbers! see Hexen's case) of the maps.

Also, if I want different names for automap name and intermission name, I have to use "levelpic", which requires me to draw it instead of taking advantage of the font. Maybe there should be an "automap prefix" string (if I wanted a Doom2-like megawad, I still wouldn't use "MAP01", but "level 1" instead), and an optional "intermission name" string.

Those suggestions may have some merit as an extension but not as part of the base feature. Let's not overcomplicate this stuff.

Well I'm still against it, as it results in cookie-cutter design where every pwad with UMAPINFO appears as "CASTFEAR: Castle of Fear", which is less immersive than just showing "Castle of Fear" or "Final Mission: Castle of Fear".

I'd add at least "levelname" which is the default and common and without prefix, and optional "automapname" and/or "intername" which would override "levelname" in either respective case.

Wait why the fuck is the lump name exposed to the player?