"UMAPINFO" discussion

Recently I added support for SIGIL to libretro PrBoom by simply checking what ExM1 maps exist on the WAD in M_Init and adding the entries that are available. That, combined with new strings on dehacked, some extra changes for the secret exit, etc. I added support for up to 7 episodes (more than that the episode selection starts getting crammed anyway).

It was very simple to add that, and it makes me wonder if an UMAPINFO format is really needed or if maybe assuming that a certain amount of episodes can be available and extending a bit dehacked to allow modifying them would already be enough to have a basic standard way for including custom episodes that's more in line with Boom.

There's the problem of having to keep a lot of pointers even when they are not necessary (like if we wanted to change sky on every level), but that's a general issue with dehacked, maybe there's a better way to tackle that.

How do you handle leaving the secret level?

I didn't actually take much care to allow customization so far, because it would require dehacked extensions that would only work in that port, and I doubt anyone would make a WAD specifically for this particular port. That's why I wanted to ask if it's a good idea first.

I set the default secret level exit to map 6, like sigil, but the value could be added as a dehacked entry to be customizable for each episode if people were willing to make use of it, same for the intermission texts/backgrounds, my port just defaults to a "The End" text for episodes > 5, but it could be made into dehacked BEX strings. Right now I only added to dehacked the entries for episode 5 with the values from SIGIL.

The problematic point would be if you wanted to have more than one secret level per episode, with different exits and enter points. Then you might need a lot more magic if it was to be done through dehacked.

Maybe if we add dehacked entries dynamically when reading the dehacked file there would be no need to have so many extra pointers for these things. Then that's basically like making a UMAPINFO with dehacked (perhaps uglier for modern ports, but less intrusive for Boom ports).

See, I'm definitely wanting it for the ability to define a secret exit on any arbitrary stage. Even Romero's new episode was stuck using the sixth map as holding the secret exit, because he had to replace one of the existing episodes for maximum compatibility with source ports (though I suppose he had some freedom to choose which episode he wanted to replace, and adjust where the secret exit appeared accordingly, as long as it was E4M2, E1M3, E2M5 or E3M6). My current project designed to show off UMAPINFO is predicated on the idea that every map has a secret exit, something that wouldn't work with the standard progression system, and thus wouldn't work at all under your stricter definition (plus it's a Doom 2 mapset, not a Doom episode, though I assume your proposal of making it possible to redefine what levels have the otherwise-fixed secret exits would have allowed for two secret exits in Doom 2 mapsets anyway).

That said, Sigil's recent release does have me wondering how you'd handle new episodes. I assume you can define the maps just fine, but I don't believe it currently has any way to add a new episode definition to the episode selection screen; thus, you'd have to warp directly to them, assuming that works and isn't capped at "49". There are other keywords I've been wanting to see, like NoJump or NoCrouch - meaningless for PrBoom+, of course, it would just parse them and do nothing with the info, but ZDoom would adjust its jumping and crouching accordingly as if I were using ZMAPINFO instead of UMAPINFO. Lastly, I have the issue where BossAction only works if the enemy calls A_BossDeath in some capacity. I can add those in with a BEX patch so it works if you're not using any mods, but my tests with mods show it breaks the instant they replace the same monsters, so I dunno what to do about that. Probably just put up a giant "NO THIS IS NOT COMPATIBLE WITH BRUTAL DOOM" disclaimer for now.

I'm up to 10 maps, which is probably good enough for a release (been working on an 11th for God-knows-what reason though, might toss it in as a bonus). I'm just not sure about the logistics behind doing so, especially since I wanna keep slowly chipping away at it, and especially since the only playtester these maps have had is myself.

8 hours ago, Shadow Hog said:

That said, Sigil's recent release does have me wondering how you'd handle new episodes. I assume you can define the maps just fine, but I don't believe it currently has any way to add a new episode definition to the episode selection screen; thus, you'd have to warp directly to them, assuming that works and isn't capped at "49".

If you are referring to UMAPINFO here, it surely can define new episodes.

Looking at the parser code you have to add

EPISODE "patchname", "episodename", "shortcut"

to the definition of the starting map.

Here "patchname" is the graphic to be used in the menu, "episodename" the same in text form (mainly relevant for scripting in ZDoom-derived ports which allow retrieving this via ACS) and "shortcut" the key to press to select the given menu item.

8 hours ago, Shadow Hog said:

There are other keywords I've been wanting to see, like NoJump or NoCrouch - meaningless for PrBoom+, of course, it would just parse them and do nothing with the info, but ZDoom would adjust its jumping and crouching accordingly as if I were using ZMAPINFO instead of UMAPINFO.

You are obviously correct here that advanced features are not present yet, but please keep in mind that this was done as a first draft in the hope to get picked up by PrBoom itself, so once it became apparent that this wasn't going to happen the whole thing went dormant.

(Thinking about it, maybe I should invest some time to make a release of the current state of things and not wait for Godot (sorry - Entryway of course :P ) to do it.

On the other hand, the parser has been designed to skip over unknown properties, so such properties could just be added by implementing ports without having to bother with the base implementation - of course I'd suggest to add a prefix to them like "ext_" for common extended properties, "zdoom_" for ZDoom specific ones and "Eternity_" for Eternity specific ones (same for other ports, of course.)

8 hours ago, Shadow Hog said:

 

Lastly, I have the issue where BossAction only works if the enemy calls A_BossDeath in some capacity. I can add those in with a BEX patch so it works if you're not using any mods, but my tests with mods show it breaks the instant they replace the same monsters, so I dunno what to do about that. Probably just put up a giant "NO THIS IS NOT COMPATIBLE WITH BRUTAL DOOM" disclaimer for now.

Yes, that's correct. A_BossDeath is the sole place where these special actions are being checked. If you do the same in ZDoom with MAPINFO, the same will happen.

It's an unfortunate limitation of the whole death action system as implemented and for obvious reasons cannot be changed retroactively - the issues this would cause are magnitudes worse.

Quote

That said, Sigil's recent release does have me wondering how you'd handle new episodes. I assume you can define the maps just fine, but I don't believe it currently has any way to add a new episode definition to the episode selection screen

If named as ExM1 the episode x would be added automatically, if it's MAPx then I could add a dehacked extension for replacing the map name for each episode.

It was just an idea I'm not saying it's the best method, I was just curious to see if there would be some reaction from other source port devs that have not added UMAPINFO support.

But yes, honestly UMAPINFO is more flexible. I was just a bit disappointed that it wasn't picking up and since SIGIL does not include the lump I had to implement some new logic to have support for it anyway, and this was also the case for other source ports like Doom Retro, who added additional logic for it too, not too different from what I did.

42 minutes ago, Graf Zahl said:

but please keep in mind that this was done as a first draft in the hope to get picked up by PrBoom itself, so once it became apparent that this wasn't going to happen the whole thing went dormant.

 

(Thinking about it, maybe I should invest some time to make a release of the current state of things and not wait for Godot (sorry - Entryway of course :P ) to do it. 

Honestly, even though PrBoom+ support would be perfect I don't think it's a requirement in order to quickstart the standard. There are other Boom-compatible source ports, it just needs agreement and adoption in general. I don't think you necessarily need even an actively maintained and developed PrBoom+ fork, just a stable one (it's not like PrBoom+ development is very active anyway).

But I think@printzraised some concerns about inconsistencies between the documentation and the implementation. I still didn't get to see what he meant. I think the standard would need Eternity support for it to work out.

15 minutes ago, Ferk said:

But I think@printzraised some concerns about inconsistencies between the documentation and the implementation. I still didn't get to see what he meant. I think the standard would need Eternity support for it to work out.

It does allow specifying which of the original end-of-game scenarios is to be used (i.e. it allows an 'endpic' or the specialized 'endbunny' and 'endcast' actions.) However, since this is merely an add-on to the base logic, it will fall back on the defaults if no exit scenario gets specified. This was all done in the framework dictated by PrBoom, i.e. a basic Boom compatible port.

I never spent much time to think about features that go beyond the requirements of such a basic port. When porting the parser to GZDoom I implemented it so that it modifies the underlying base information so that the assumptions being made here would hold, unless explicitly specified otherwise.
 

So, if there's pending issues that need to be resolved I definitely need to get a bit more detailed info about what is wrong here.

map E5M1
{
	LevelName = "Baphomet's Demesne"
	LevelPic = "WILV40"
	Next = "E5M2"
	Music = "D_E5M1"
	SkyTexture = "SKY5"
	ExitPic = "SIGILINT"
	Episode = "M_EPI5", "SIGIL", "S"
}

map E5M2
{
	LevelName = "Sheol"
	LevelPic = "WILV41"
	Next = "E5M3"
	Music = "D_E5M2"
	SkyTexture = "SKY5"
	ExitPic = "SIGILINT"
}

map E5M3
{
	LevelName = "Cages of the Damned"
	LevelPic = "WILV42"
	Next = "E5M4"
	Music = "D_E5M3"
	SkyTexture = "SKY5"
	ExitPic = "SIGILINT"
}

map E5M4
{
	LevelName = "Paths of Wretchedness"
	LevelPic = "WILV43"
	Next = "E5M5"
	Music = "D_E5M4"
	SkyTexture = "SKY5"
	ExitPic = "SIGILINT"
}

map E5M5
{
	LevelName = "Abaddon's Void"
	LevelPic = "WILV44"
	Next = "E5M6"
	Music = "D_E5M5"
	SkyTexture = "SKY5"
	ExitPic = "SIGILINT"
}

map E5M6
{
	LevelName = "Unspeakable Persecution"
	LevelPic = "WILV45"
	Next = "E5M7"
	NextSecret = "E5M9"
	Music = "D_E5M6"
	SkyTexture = "SKY5"
	ExitPic = "SIGILINT"
}

map E5M7
{
	LevelName = "Nightmare Underworld"
	LevelPic = "WILV46"
	Next = "E5M8"
	Music = "D_E5M7"
	SkyTexture = "SKY5"
	ExitPic = "SIGILINT"
}

map E5M8
{
	LevelName = "Halls of Perdition"
	LevelPic = "WILV47"
	EndPic = "CREDIT"
	InterText = "Baphomet was only doing Satan's bidding",
				"by bringing you back to Hell. Somehow they",
				"didn't understand that you're the reason",
				"they failed in the first place.",
				"",
				"After mopping up the place with your",
				"arsenal, you're ready to face the more",
				"advanced demons that were sent to Earth.",
				"",
				"Lock and load. Rip and tear."
	Music = "D_E5M8"
	SkyTexture = "SKY5"
	ExitPic = "SIGILINT"
}

map E5M9
{
	LevelName = "Realm of Iblis"
	LevelPic = "WILV48"
	Next = "E5M7"
	Music = "D_E5M9"
	SkyTexture = "SKY5"
	ExitPic = "SIGILINT"
}

EDIT: Dammit, no, I didn't want to erase the entire post to post that... Okay, I can't recover what I wrote, but the gist of it was that I used the above text as a UMAPINFO lump for SIGIL to test the Episode functionality, because I hadn't yet, and while the episode listing showed up correctly, it was taking me to E4M1 instead of E5M1. Also, all the IWAD episode listings now took me to E1M1. The UMAPINFO lump was the only lump in the WAD, and it was used with SIGIL.WAD v1.1. "Episode = Clear" was also tried, which cleared out the IWAD definitions, but the new one still took me to E4.

Also I linked to my compile of the current codebase in case anyone wanted to try it for themselves - the bug, sure, but also UMAPINFO in general.

This is obviously a bug. Will have to check later.

Apparently this feature got never tested... :?

Yeah, sorry, all the testing I've done with UMAPINFO's been for Doom 2 to this point, and I never thought to add episode definitions to my mapset so I never got around to testing it there either. For what it's worth the other features defined in umapinfo.txt seem to work flawlessly.

EDIT: Also it just dawned on me that I should be using "SkyTexture" instead of "Sky" in the map defintions, but I'm not sure what the result of that error will be since I can't even get into E5M1 at the moment. I'll correct the above UMAPINFO accordingly; this post shall mark that I did "Sky = "SKY5"" instead of "SkyTexture = "SKY5"" for posterity I guess.

so what the hell is umapinfo and hows it different from different mapinfo?

i look it up and all i find is this thread and a prboom+ doc explaining how to use it (but not what it is)

UMAPINFO is a bare-bones version of MAPINFO that is designed so that as many ports as possible can potentially be compatible with it. The goal with this is to have a "modding standard" that all limit-removing source ports are compatible with. Normally, if you want to change the order of maps, you have to go instantly to GZDoom or Eternity compatibility, even if you just want to make boom-format maps. With UMAPINFO(If developers support it), you could just make a UMAPINFO and you don't have to go overkill with sourceports.

On 6/3/2019 at 10:01 AM, Shadow Hog said:

  Reveal hidden contents

map E5M1
{
	LevelName = "Baphomet's Demesne"
	LevelPic = "WILV40"
	Next = "E5M2"
	Music = "D_E5M1"
	SkyTexture = "SKY5"
	ExitPic = "SIGILINT"
	Episode = "M_EPI5", "SIGIL", "S"
}

map E5M2
{
	LevelName = "Sheol"
	LevelPic = "WILV41"
	Next = "E5M3"
	Music = "D_E5M2"
	SkyTexture = "SKY5"
	ExitPic = "SIGILINT"
}

map E5M3
{
	LevelName = "Cages of the Damned"
	LevelPic = "WILV42"
	Next = "E5M4"
	Music = "D_E5M3"
	SkyTexture = "SKY5"
	ExitPic = "SIGILINT"
}

map E5M4
{
	LevelName = "Paths of Wretchedness"
	LevelPic = "WILV43"
	Next = "E5M5"
	Music = "D_E5M4"
	SkyTexture = "SKY5"
	ExitPic = "SIGILINT"
}

map E5M5
{
	LevelName = "Abaddon's Void"
	LevelPic = "WILV44"
	Next = "E5M6"
	Music = "D_E5M5"
	SkyTexture = "SKY5"
	ExitPic = "SIGILINT"
}

map E5M6
{
	LevelName = "Unspeakable Persecution"
	LevelPic = "WILV45"
	Next = "E5M7"
	NextSecret = "E5M9"
	Music = "D_E5M6"
	SkyTexture = "SKY5"
	ExitPic = "SIGILINT"
}

map E5M7
{
	LevelName = "Nightmare Underworld"
	LevelPic = "WILV46"
	Next = "E5M8"
	Music = "D_E5M7"
	SkyTexture = "SKY5"
	ExitPic = "SIGILINT"
}

map E5M8
{
	LevelName = "Halls of Perdition"
	LevelPic = "WILV47"
	EndPic = "CREDIT"
	InterText = "Baphomet was only doing Satan's bidding",
				"by bringing you back to Hell. Somehow they",
				"didn't understand that you're the reason",
				"they failed in the first place.",
				"",
				"After mopping up the place with your",
				"arsenal, you're ready to face the more",
				"advanced demons that were sent to Earth.",
				"",
				"Lock and load. Rip and tear."
	Music = "D_E5M8"
	SkyTexture = "SKY5"
	ExitPic = "SIGILINT"
}

map E5M9
{
	LevelName = "Realm of Iblis"
	LevelPic = "WILV48"
	Next = "E5M7"
	Music = "D_E5M9"
	SkyTexture = "SKY5"
	ExitPic = "SIGILINT"
}

and while the episode listing showed up correctly, it was taking me to E4M1 instead of E5M1. Also, all the IWAD episode listings now took me to E1M1. The UMAPINFO lump was the only lump in the WAD, and it was used with SIGIL.WAD v1.1. "Episode = Clear" was also tried, which cleared out the IWAD definitions, but the new one still took me to E4.

 

Should be fixed now. The default episode range checks got into the way of launching non-standard episodes. Those checks will now be disabled when UMAPINFO defines its own episodes.

I think this warrants an official release:

https://github.com/coelckers/prboom-plus/releases/tag/v2.5.1.5um

Windows 32 bit only so far. No XP support because I no longer have a compiler capable of targeting that platform.

If someone wants to provide release packages for macOS and Linux, please contact me.

Just wanted to pop in and say I got it compiled and running on mac, after making a couple hacky alterations to makefiles similar to what I had done before. I know jack about professional software distribution so surely there's a more sensible way to accomplish the same thing upstream (in the autotools or configure steps).

I poked around the Sigil UMAPINFO posted by Shadow Hog, and had a couple observations:

Is it possible to add idclev support for maps with names specified by umapinfo? That sounds thorny to implement but would be neat.

On the EndPic screen if you hit space the screen will melt into itself again, which seems funky.

I think adding idclev support for names specified by UMAPINFO would be a very good idea. I think it could be called something like a "level number", because the -warp parameter uses the numbers of maps and not the mapname itself. Idclev is probably a more immediately useful use-case, though.

IDCLEV should be possible. At the moment the engine cannot handle non-standard map names so it'd be enough for most cases to remove the range check on the enterable numbers. (stuff like E1M10 would be trickier.)

I've finally started revisiting my attempt at UMAPINFO on Eternity. I waited for awhile for this idea to stabilize and @Graf Zahl has just now released his PrBoom+UMAPINFO proposal, so I guess the community is happy about this feature.

I've looked up this document: https://raw.githubusercontent.com/coelckers/prboom-plus/master/prboom2/doc/umapinfo.txt. Is it up to date?

My observations so far:

1. levelname: seems that you must have levelpic as well if you want any of these things which involve different texts: (1) show level number prefix in the automap (e.g. "Area 1: Towers") without it appearing in the intermission, (2) show different names between automap and intermission (e.g. "Gate to Limbo" / "Limbo"). I will not tack the lump name (e.g. "MAP01: Towers" for levelname "Towers") in Eternity.
2. 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).
3. endpic. If set to a valid lump, does it require endgame=true to have any effect?
4. interbackdrop: I guess I'll have to pick another default texture in Heretic. Probably whatever is used in episode 1.
5. bossaction: dunno what to do if map is UDMF. Use the classic special namespace regardless?

OK, I know you designed this for MBF format Doom, so Heretic and UDMF are out of scope, but I'm trying to somehow embrace UMAPINFO as an EDF component (on top of which I can add the port-specific stuff), and for that I need to isolate the classic Doomisms away.

Considering that DEHACKED has always considered the "MAP01: " or "E1M1: " prefix from the automap as part of the modifiable string, it makes the most sense for it to remain that way, to be honest.

I feel like it's different in PrBoom+/UMAPINFO just because that's what GZDoom does. Maybe it does make sense to have a separate "maptitle" or so for the name in the automap and "levelname" for the name when transitioning between levels, it would also give more flexibility for the mapper so they can show different things... you can always have the maptitle default to lumpname + ": " + levelname

I suppose it's pretty much like in vanilla if you want a level marker in the automap display and a picture without the marker in the intermission. 

@Graf Zahl did you have this in mind?

Levelname = "Level 1: towers"

Levelpic = "MWILV00" (bitmap of text "Towers")? 

1 hour ago, printz said:

I suppose it's pretty much like in vanilla if you want a level marker in the automap display and a picture without the marker in the intermission. 

 

@Graf Zahl did you have this in mind?

 

Levelname = "Level 1: towers"

Levelpic = "MWILV00" (bitmap of text "Towers")? 

No. I'm sorry but here your ideas do not mix with mine, because in ZDoom it has always been a hassle to remove that map label in front so that we have a sane text to work with. With too many Dehacked modifications that were limited by available character space it cannot do it correctly.

I'll comment on the rest later.

Well I will not change Eternity to display anything more than the levelname as-is. Let mod author decide how to display the level number, if they want to. Lump name is an internal matter. 

1 hour ago, Graf Zahl said:

because in ZDoom it has always been a hassle to remove that map label in front so that we have a sane text to work with.

You can leave the levelname without the map label in front if an additional optional "maptitle" field was added for the display name in the automap.

When "maptitle" is not provided it could default to the zdoom constructed string, but it'd still give mod authors the option to change it.

33 minutes ago, printz said:

Well I will not change Eternity to display anything more than the levelname as-is. Let mod author decide how to display the level number, if they want to. Lump name is an internal matter. 

So, I guess with such an attitude we can bury the thing right away, huh?

Sounds like a good case for an "IntermissionName" property -- that would cover all the cases without requiring the author to make an LevelPic image, and GZD/Eternity can do what they've always done with the automap name string.

35 minutes ago, Graf Zahl said:

 

So, I guess with such an attitude we can bury the thing right away, huh?

It's not attitude, it's different opinion, that's why other ports exist.

18 minutes ago, Xaser said:

Sounds like a good case for an "IntermissionName" property

Yeah and even if he doesn't add it, I'll add it as something like "ee_inter_levelname". But I'm tempted to just add an internal eternity{} block inside this map{} block because it looks cleaner.

I am thinking of working on some common Hexen-like fields for an extended UMAPINFO that can't exist in PrBoom+ but would work in ports supporting Hexen/Heretic features (I know Eternity is at snails pace even adding Heretic, but it adopted several of Raven's features much longer ago). What comes to mind is:

- sky2

- skies' speeds

- lightning effects

- fadetable (not sure Eternity has it, but it should have it eventually).

- hub system (Eternity seemingly has neglected this feature, but it must have them…)

Regarding sub-blocks, other parsers probably don't support that, so that's a no-go -- this discussion was already had long ago, and the common decision was "prefix the property name", e.g. "ee_something_or_other". Let's focus on getting it implemented so mappers can use it, rather than try and reopen closed discussions.

Wouldn't it be a mess if each engine interprets the levelname differently?

If a WAD actually uses "MAP01: Towers" as the levelname, then it would show "MAP01: MAP01: Towers" in both the PrBoom+ fork and GZDoom. So I expect most authors wouldn't want to do that and would rather it just shows as "Towers" in Eternity's automap, instead of making use of the "ee_inter_levelname".

I still think it's better to instead have a "maptitle" or an "automap_name", or whatever you wanna call it.

I'm just proposing each engine does what it already does -- GZDoom has code that strips the "level: " part out and places the lump name in its place; EE doesn't; not sure what the pr+ fork does offhand, but if you set "level 1: towers" as levelname, "Towers" as ee_enter_levelname, then GZDoom shows "MAP01: Towers" in the map, EE shows "level 1: towers" in the map, and both of them show "Towers" in the intermission screen. The duplicate lump name scenario doesn't happen in either case.

52 minutes ago, Xaser said:

GZDoom has code that strips the "level: " part out and places the lump name in its place

Is that what GZDoom is doing? I just tested it and it does show the duplicate lump name when loading a WAD that contains the lump name in the UMAPINFO levelname.

When loading Freedoom in GZDoom (which uses a BEX [STRINGS] field) the title in the automap shows as "E1M1: C1M1: Outer Prison" in GZDoom.

EDIT: Oh, in the case of BEX STRINGS it does strip it when it matches exactly the lumpname (Freedoom2 MAP01 shows as "MAP01: Hydroelectric plant")

So I guess in your example, it'd show as "MAP01: level 1: towers", but it'll show "MAP01: towers" if the prefix was "MAP01" instead of "level 1".