"UMAPINFO" discussion

[Graf Zahl]

I think the decision should be left to the player, not the modder. Some people want to see it, others will not. I just went with how Doom originally did it.

 

[printz]

No, it should all be up to the author. The author needs full freedom on how to present his or her work. It's up to the player to judge it as worth playing. The player should only have three options: play, avoid the wad or cheat (i.e. through console commands).

[Da Werecat]

I sense another debate on the player's freedom to break everything, make everything ugly, and then think that the wad is to blame.

 

Original Doom had ExMy as a part of the string, in other words - editable. Doom 2 turned to a more aesthetically pleasing "level x" in the name, but ZDoom cuts it off and displays the lump name for some reason. I wonder what kind of fun accidents this might cause. Does it always remove everything before the first colon?

 

Edited July 30, 2017 by Da Werecat

[Graf Zahl]

 

1 hour ago, printz said:

No, it should all be up to the author. The author needs full freedom on how to present his or her work. It's up to the player to judge it as worth playing. The player should only have three options: play, avoid the wad or cheat (i.e. through console commands).

I see that on this topic we'll never come to an agreement so I won't even try.

 

[Graf Zahl]

1 hour ago, Da Werecat said:

I sense another debate on the player's freedom to break everything, make everything ugly, and then think that the wad is to blame.

 

That's what you have to live with. The player is the ultimate decisionmaker here, if they think you screwed up they can do whatever they like to 'correct' things, that goes from editing the maps or just using another engine that's more customization friendly.

 

 

1 hour ago, Da Werecat said:

 

Original Doom had ExMy as a part of the string, in other words - editable. Doom 2 turned to a more aesthetically pleasing "level x" in the name, but ZDoom cuts it off and displays the lump name for some reason. I wonder what kind of fun accidents this might cause. Does it always remove everything before the first colon?

 

Yes, ZDoom does precisely that. If there's any problem here, it's prepending the lump name unconditionally and not doing it the same way as Doom 2 for MAPxx maps which prepended 'Level x' instead.

Regardless, the way to deal with this is not inventing new and mostly pointless keys for UMAPINFO (In all those 18 years there hasn't been one single request for a separate automap string at ZDoom which clearly shows how much demand there is for it!) but synthesizing a proper string in the MAPxx case.

 

 

[Da Werecat]

26 minutes ago, Graf Zahl said:

That's what you have to live with.

Not in the normal gamedev.

 

27 minutes ago, Graf Zahl said:

The player is the ultimate decisionmaker here, if they think you screwed up they can do whatever they like to 'correct' things, that goes from editing the maps or just using another engine that's more customization friendly.

Let them edit whatever they want - this is something you can't really do anything about in the world of modding. The important thing here is that the player would have to actively interfere with how things work, which means that either they know what they're doing, or at the very least they can't blame anyone but themselves if something falls off in the process.

 

Tinkering with options isn't the same, because in the normal gamedev it's supposed to be harmless. You just don't have options that break things. If they do, it's a bug.

 

Then again, we're talking about a small cosmetic issue here, and when it comes to important game-breaking things, I think everyone understands that having a MAPINFO key is a good thing.

 

[printz]

I just tested "enterpic" in Eternity (after I added it as a feature). In Doom 2 the time is way too short for you to have time to notice it. I will make it in EE so if "enterpic" is present, the display time will be as long as in Doom 1, because it's probably something you want to see.

 

As for Eternity UMAPINFO extensions: I'll probably prefix them with ee- or eternity-.

Edited July 30, 2017 by printz
Eternity prefix stuff.

[Graf Zahl]

4 hours ago, printz said:

As for Eternity UMAPINFO extensions: I'll probably prefix them with ee- or eternity-.

Use '_' instead of '-'. Any parser which reads common identifiers would stumble over the '-'.

 

[printz]

It's unclear from the source code what "endgame = true" does. It seems to temporarily set endpic to "!", which is soon replaced with an empty string, and the already-default final maps are re-given their endpic values (which they have by default). And if the map is not a traditional boss map, nothing special happens (it just loses its secret next level).

 

From description it looks like it allows you to finish an episode prematurely or later, but I don't see that in the code.

Edited July 30, 2017 by printz

[Graf Zahl]

There's an 'else' missing in the processing code. This apparently happened when I transitioned the format to curly syntax.

 

[Altazimuth]

So I'm extremely pleased with the progress made so far, but there's still one hurdle that needs to be considered if we're to fully implement this in PRBoom+ without compromising one of the project's core values:

DEMO COMPAT

 

Hypothetical: I have a complevel 9 (Boom) wad. It's got 17 maps. OK I record it with -complevel 9. I then add UMAPINFO and make it so that a secret level can be accessed from MAP03, and the secret level is 17; 16 is the big finale. A -complevel 9 demo should ignore this, but how do we define a demo that is "-complevel 9 but it pays attention to UMAPINFO"? A quick and dirty method would be to have a command line switch for recording (this is fine) and playback (this is not fine). The other solution would be to put some extra data in the footer of the demo, which would be more in-line with what the user expects.

 

Thoughts?

 

EDIT: I want to make clear, if we (port devs and demo-recording folks) can come to an agreement on methods, I am willing to change this code myself (though getting the building working might be a schlep), and make a pull request.

Edited July 30, 2017 by Altazimuth

[Mánibranðr System]

15 hours ago, Graf Zahl said:

 

I see that on this topic we'll never come to an agreement so I won't even try.

 

This isn't about you. What a port should do with the lump name whether or not it should be up to the user or the author will be decided by the community. And to be honest, whole idea of MAPINFO is to give map makers more control of how their map should be presented. Shouldn't you be more worried about bringing vanilla demo compat back into zdoom?

 

@Altazimuth

I think adding data to the footer of the demo would work, as it would not require any extra effort on the person recording other than add a command line switch for recording with the UMapInfo lump in consideration that wouldn't be needed in playback, because the data is already baked into the demo.

[Graf Zahl]

6 hours ago, ArcheKruz said:

This isn't about you. What a port should do with the lump name whether or not it should be up to the user or the author will be decided by the community. And to be honest, whole idea of MAPINFO is to give map makers more control of how their map should be presented.

 

That's up to debate who should be in control: The mapper or the end user? For some aspects I favor the end user where other developers favor the mapper. There is no "correct" here, both standpoints are valid. Just keep in mind: In ZDoom you can start a map by typing "map mapname" in the console. So there's a valid reason to show that map name to the user.

 

 

6 hours ago, ArcheKruz said:

Shouldn't you be more worried about bringing vanilla demo compat back into zdoom?

 

Yet another person who should do some reading on the subject matter before making such suggestions. Sorry, that ship has sailed many, many years ago.

 

 

[printz]

9 hours ago, Graf Zahl said:

There's an 'else' missing in the processing code. This apparently happened when I transitioned the format to curly syntax.

 

It's still difficult for me to follow. I see that the exclamation mark then simply resets nextmap, next secret and endpic to 0, which apparently are used elsewhere (in two places, one named after entryway, e6y.c). But I couldn't easily find the logic which triggers the victory screen(s). I may see it when I manage to compile PrBoom+.

Edited July 31, 2017 by printz
Corrected a keyword.

[Da Werecat]

34 minutes ago, Graf Zahl said:

Just keep in mind: In ZDoom you can start a map by typing "map mapname" in the console. So there's a valid reason to show that map name to the user.

I thought that might be among the reasons. But it means that displaying the lump name is a "here's how you cheat" feature, with specific conditions for when it's useful.

[Gez]

Since the automap only displays the map name of the current map, the same purpose could be achieved by having "map" (without parameter) print the lump name of the current map.

 

For other levels, there's "listmaps".

[Graf Zahl]

1 hour ago, printz said:

It's still difficult for me to follow. I see that the exclamation mark then simply resets nextmap, next secret and endpic to 0, which apparently are used elsewhere (in two places, one named after entryway, e6y.c). But I couldn't easily find the logic which triggers the victory screen(s). I may see it when I manage to compile PrBoom+.

 

The relevant part is having 'nextmap' 0. It was quite messy to integrate this stuff with the haphazard progression logic from the original source which PrBoom preserves to large degrees so yes, it is indeed a bit hard to follow.

 

[dew]

8 hours ago, ArcheKruz said:

I think adding data to the footer of the demo would work, as it would not require any extra effort on the person recording other than add a command line switch for recording with the UMapInfo lump in consideration that wouldn't be needed in playback, because the data is already baked into the demo.

Personally, I'd like to see a new header for this, or perhaps a different signature like MBF's. If all the extra info goes into the footer, incompatible ports or old releases may simply ignore it, play the demo as if nothing's wrong and only desync at the map progression fork.

[Maes]

On 4/18/2017 at 11:45 PM, Death Egg said:

How is using it considered against the spirit of vanilla?

 

Maybe it doesn't work in vanilla? That sounds pretty much against vanilla (and not just its "spirit"), period.

 

Still, if the intention if making a truly vanilla-compatible map, I guess it doesn't hurt to include "alien" lumps if they don't interfere with anything. If however in a vanilla map MAPINFO is the only way to provide custom map names and other amenities, then yeah, pure "vanilla" becomes a second-class citizen.

Edited July 31, 2017 by Maes

[Da Werecat]

Don't you think that "not working in vanilla" should be a subset of "against the spirit of vanilla" and not vice-versa?

[Altazimuth]

12 minutes ago, dew said:

Personally, I'd like to see a new header for this, or perhaps a different signature like MBF's.

A new header is definitely feasible. Eternity does this. Its header (post 329) has the demo_version always as 255, then 6 chars that spells "ETERN", then 4 bytes for the true demo version, and a byte for subversion. This could easily have a similar system but with a field of flags, one of which would be "respects UMAPINFO".

 

The hard part will probably be making sure that UMAPINFO gets ignored.

[Death Egg]

I shouldn't have worded it like that originally. By the time you get to ports like prBoom+ the spirit of vanilla is already pretty faded. I should have said something more like it being against a more purist style of gameplay, even though having it is nothing but convenient for modders and players alike, plus it doesn't even detract from any part of the doom experience unless that experience is "when I finish a map pack that's less than 32 maps I expect to be taken to the rest of the original Doom 2 levels".

[Maes]

In that sense, merely having a MAPINFO lump shouldn't be viewed as "against the spirit of vanilla" IMO, as it's pretty much a superset functionality that's transparent to vanilla/chocolate/non-MAPINFO aware ports. However, if someone releases a cool new "all vanilla" megawad, and then cheapens out on the "proper" way of doing map names by throwing in a MAPINFO lump and telling ya "play it on ZDoom if you want to see new map names", then yeah, something is amiss there.

Edited July 31, 2017 by Maes

[Altazimuth]

An addition to my prior thought, perhaps a better solution for the end-user would be to have every UMAPINFO property assigned a "demo-critical" flag internally, and then at runtime determine what to ignore. This means you could have purely aesthetic settings still hold true whilst recording and playing back demos (the same way that sky transfers work in -complevel 9 under PRBoom+).

Edited July 31, 2017 by Altazimuth

[printz]

It seems that ; (semicolon) is not a valid UMAPINFO comment, despite the text file displaying comments as such. How do comments look like in UMAPINFO? // and /* */?

 

EDIT: I just tried "endgame = true" in Doom 1 E2M3, and nothing special happened after exiting.

 

Also @Graf Zahl your branch of PrBoom+ has serious problems with the Doom 1 intermission, at least what I saw in E2M3. The overview map is all garbled and gets mixed with the E1 map.

Edited July 31, 2017 by printz

[Graf Zahl]

8 minutes ago, printz said:

Also @Graf Zahl your branch of PrBoom+ has serious problems with the Doom 1 intermission, at least what I saw in E2M3. The overview map is all garbled and gets mixed with the E1 map.

Weird. Last time I checked it worked fine. I fear that something broke when I rewrote the parser.

 

10 minutes ago, printz said:

It seems that ; (semicolon) is not a valid UMAPINFO comment, despite the text file displaying comments as such.

That's just the documentation. The parser I use cannot handle semicolons as start of a comment, neither can ZDoom's, so that's not going to be supported.

 

[Altazimuth]

Wait so what is a supported comment?

 

Also, @Graf Zahl my demo thoughts were aimed at partially at you, since you have to be receptive to any pull requests I make since you're the repo owner on GitHub. I'm not going to try and do this airtight demo system without you at least saying "yes I'll accept any pull as long as your code isn't hot garbage." To make it clear, I am not asking you to do any of the grunt work on this, as demos aren't your thing. The most I'd ask for is maybe some technical advice on disabling certain aspects of UMAPINFO for strict demo compat.

[Graf Zahl]

Supported comments are C and C++ style ( /*..*/ and //.. )

If you make PRs, of course I will merge them. But please note that I may not have much time to work on this myself in the coming weeks so it may take a few days until I can review them.

 

[Altazimuth]

Oh cool (comment stuff being standard).

I totally understand being occupied with IRL stuff. I'm trying to fit in my healthy dose of coding between play sessions with the dog, whilst she's calming down.

[kb1]

Re: The showing of Level #: Personally, I do like to know which level number I'm in, but I agree, the author should have the freedom to present the map as he/she wishes, including hiding the lumpname. What about suppressing lumpname, but showing "ExMx/Level nn", even if the maplump has a different name? Or, better yet, an option makes everyone happy. End of debate :)

 

@Graf Zahl Just wanted to say: Thank you for your quick implementation of UMAPINFO! This is one of the most important elements of compatibility. I know that you had limited time to work it out, and yet, here it is. We may need to adjust a couple of things to get it exactly perfect, but it's basically functional. Good job!

 

@Altazimuth: There's no precedent for allowing demos to survive its parent WAD changing. Most UMAPINFO have a detrimental effect on the critical timing required for the proper playing of demos. If you add a UMAPINFO to a wad after demos have been created, there is a good chance that the demo (or demo 2 of a multi-level demo) will go out of sync. There are workarounds, but they are not feasible or easy:

• Enforce vanilla timing upon UMAPINFO entries regardless of what they specify (not ideal)
• Enforce vanilla timing upon UMAPINFO entries regardless of what they specify,, only if the demo is of a version before UMAPINFO was added, and write out timing information into a new demo format (and, hopefully, the UMAPINFO does not get changed again...)
• Omit UMAPINFO time from a new demo format (will make end-level display suck, or non-existent).
• Build hashes of the wads and a new demo format, and store these in the new demo. Use the UMAPINFO timing stored in the demo, unless the UMAPINFO has changed since the demo was recorded...YUCK...in that case, use default timing...YUCK...
• Some combination of the above. One day, we might be able to standardize on a demo format, to a point, at least.

 

 

@printz @Altazimuth, and other developers:

I was kinda hoping that there'd be more time, before this started getting implemented en masse, in multiple ports, with multiple changes to fix this or that. It would be nice, if any fixes were done to Graf's PrBoom+ implementation only, at first. Here's my concerns:

 

This is supposed to be a Universal MAPINFO implementation. I know Graf wants to see it tested and used more (and it will be). The tendency should not be to immediately start adding port-specific extensions. Instead, it should first be verified to work EXACTLY like Doom, Doom II, TNT, Plutonia, and Chex Quest works, including placement, timings, exact texts, specialized tower icons, etc. For example, where vanilla code shows ExMx: and Level XX:, UMAPINFO should default to doing the same. Likewise, the omission of UMAPINFO should produce a 100% vanilla mapinfo experience. And, the possibility should exist to create a UMAPINFO lump set to defaults, also producing a 100%-vanilla compatible game. I do have code that may be useful to support 100% compatibility, if the need arises.

 

Any extensions should be added first to the UMAPINFO implementation in Graf's PrBoom+, and brought into other ports as standard features, not port-specific features. I'm not saying that the format should not be able to handle port-specific features. I'm saying that that should be a last resort.

 

@printz: There's no reason the features you mention cannot be available as standard features. "Standard" does not mean "vanilla".

 

"Standard" means:

1. Exists in all implementations as an option.
2. "Standard" options default to 100% vanilla behavior, as do their omission.

UMAPINFO is a huge step forward towards a level of compatibility not enjoyed for many years. It is an integral part of the DEX/CDX/Boom+/whatever specification. Please use your wisdom and discrimination before deciding that you need to add a port-specific feature. You can never roll back features once they are published, because someone might use them in a map. Here's a hypothetical:

 

Say EE wanted to add a "ee-hubs" feature. But, in a few months, PrBoom+ got hubs working. Should PrBoom+ define a "pr-hubs"? Or does everyone need to look for "ee-hubs" OR "hubs"?

 

I am working on a Phase 1 spec, but once that's completed, I am really hoping that the developers can start to work together towards a Phase 2 and beyond, by embracing a compatibility mindset. Ideally, UMAPINFO itself would only specify features in the common compatibility set for that current phase, and would grow with each phase. The advantage is that mappers specifying the need for, say, Phase 2 support, would know which features UMAPINFO supports, which linedefs and sector types were available, which definition lumps could be used, etc. This would simplify the understanding of phases, what tools could be used, and which engines were compatible.

 

(I am not suggesting that you are not embracing this mindset - I just wanted to add my 2 cents, and provide some feedback into a yet-unreleased spec. Please forgive me if I made any ill assumptions. I'd like to hear any feedback you may have as well.)

 

One more point: I am not trying to halt progress here. Instead, I want us to implement the basics, and, for the new features, I want us to take our time, and collaborate on possible joint solutions. I would rather have 1 partial solution than 5 incompatible advanced solutions. Again, once we release it, it can't be easily changed. Let's get it right the first time!