"UMAPINFO" discussion

1. I really think other source port authors should weigh in, but especially entryway as Graf you are adding things to his project.  It would be cooler to talk to him and others first before getting users and players excited.  If entryway doesn't want to accept it, then he has to deal with the pressure of the community.

 

2. Can we just use JSON and a schema?  I really feel like the days of "Doom-specific formats" should be over.

 

3. Not for nothing but EMAPINFO doesn't look at all hard to parse.  There's ~30 keywords, the sound-* ones you can just check for that prefix, and the map sections are surrounded by brackets.  It actually looks super easy.

 

4. Everytime this comes up, isn't the question port support for features?  I remember various threads about a database of port/map settings for demos and what-not.  Doesn't this have the same problem?  Not that I don't think there are solutions, but I haven't seen it discussed at all.

Share this post


Link to post
7 minutes ago, Ladna said:

2. Can we just use JSON and a schema?  I really feel like the days of "Doom-specific formats" should be over.

Weren't most ports made in C or C++, I'd be screaming for this in a heartbeat. Considering C lacks pretty much everything that makes JSON... That's a harder sell.

Share this post


Link to post
3 hours ago, Ladna said:

1. I really think other source port authors should weigh in, but especially entryway as Graf you are adding things to his project.  It would be cooler to talk to him and others first before getting users and players excited.  If entryway doesn't want to accept it, then he has to deal with the pressure of the community.

 

2. Can we just use JSON and a schema?  I really feel like the days of "Doom-specific formats" should be over.

 

3. Not for nothing but EMAPINFO doesn't look at all hard to parse.  There's ~30 keywords, the sound-* ones you can just check for that prefix, and the map sections are surrounded by brackets.  It actually looks super easy.

 

4. Everytime this comes up, isn't the question port support for features?  I remember various threads about a database of port/map settings for demos and what-not.  Doesn't this have the same problem?  Not that I don't think there are solutions, but I haven't seen it discussed at all.

Graf is forking the source, making it a port all in itself. And, it will get picked up and advanced from that point, trust me!

 

Yes, the database of port/map settings was my thread (I think). It's a huge problem, and it gets worse every year. Compatibility is a big issue, it makes things difficult for everyone involved. But, it doesn't have to remain that way. Please see this thread for the beginnings of a master plan to try to attack this monster once and for all. It won't be easy, or fast, but it's worth a shot.

 

2 hours ago, Albertoni said:

Weren't most ports made in C or C++, I'd be screaming for this in a heartbeat. Considering C lacks pretty much everything that makes JSON... That's a harder sell.

JSON is easily parsed in C, as long as it doesn't get too crazy. But, we're talking about name/value pairs - it really doesn't get much easier than that.

Share this post


Link to post
2 hours ago, kb1 said:

But, we're talking about name/value pairs - it really doesn't get much easier than that.

Don't get me wrong, 99% of MAPINFO is easy to parse. It's just that the other 1% will need 50% of the work. Intermission scripts, in particular, make me shudder in fear.

Share this post


Link to post
6 hours ago, Ladna said:

1. I really think other source port authors should weigh in, but especially entryway as Graf you are adding things to his project.  It would be cooler to talk to him and others first before getting users and players excited.  If entryway doesn't want to accept it, then he has to deal with the pressure of the community.

 

As has been said, I forked the source. Moreover, PrBoom+ doesn't even have its own repository, it still lives as a branch of PrBoom, so RjY's opinion is also important here.

If entryway doesn't want it it's his choice, but as interest in a more active fork of PrBoom is more than obvious, I think the project will gain momentum and eventually supplant PrBoom+ if it continues treading water. The only thing is that the existing demo compatibility must be taken seriously and releases carefully planned.

6 hours ago, Ladna said:

2. Can we just use JSON and a schema?  I really feel like the days of "Doom-specific formats" should be over.

A schema for what? MAPINFO? I don't really think that it's a good idea. While JSON is a really nice format to store interchange data, syntactically it's *just* a tiny bit too temperamental with its syntax and excessive use of quotation marks. I'm open to suggestions, though, if the consensus is that this is a good idea I won't block it.

 

6 hours ago, Ladna said:

3. Not for nothing but EMAPINFO doesn't look at all hard to parse.  There's ~30 keywords, the sound-* ones you can just check for that prefix, and the map sections are surrounded by brackets.  It actually looks super easy.

The problem with EMAPINFO is that it chose to go without quotes and without clearly defined argument separators. That works if the format is fixed but it was precisely for similar reasons that some years ago the ZDoom MAPINFO format was rewritten to be better structured. The very minimum I consider necessary is to enclose string literals in quotation marks and to separate arguments with commas. As designed EMAPINFO is not really capable of dealing with multiline string literals because there's no good way to parse them. My first idea was actually to use EMAPINFO syntax, but due to these problems I chose a slightly modified format with a few syntactic changes that address the issues I mentioned.

6 hours ago, Ladna said:

4. Everytime this comes up, isn't the question port support for features?  I remember various threads about a database of port/map settings for demos and what-not.  Doesn't this have the same problem?  Not that I don't think there are solutions, but I haven't seen it discussed at all.

Right now all this is is adding a MAPINFO format. This means that as long as no such information is added, nothing will change because no code got replaced.

And like I said elsewhere: PrBoom could add lots of features without ever running the risk of losing demo compatibility. The important thing here is that such a port cannot be developed like ZDoom where new code is added or changed rather indiscriminately, as all it needs to care about is keeping the feeling of gameplay identical, not the mathematical intricacies. Things have to be weighed a lot more carefully, but I think there's enough competent coders here who can manage it.

 

 

Share this post


Link to post
3 hours ago, kb1 said:

JSON is easily parsed in C, as long as it doesn't get too crazy. But, we're talking about name/value pairs - it really doesn't get much easier than that.

Correct. I'd still use a dedicated JSON library, but in that case that module would probably have to be C++ because the better C libraries I know are far too clumsy, while in C++ I already have everything working in ZDoom, and backporting the code would be a non-issue - but it uses RapidJSON which uses C++.

 

I already mentioned this in the other thread, but it might be a good idea anyway to make the code compile as C++ without changing anything beyond the needed casts to make it compile, because it gives a far wider access to other code to borrow from than sticking with C, which makes it very hard to take code from ZDoom or maybe even Eternity without heavily rewriting it.

 

Share this post


Link to post

Boss death actions are in now, too. I think this covers the base.

 

Share this post


Link to post

Would it be possible for something like UMAPINFO to treat a map name of "Level 1: Level Name" as the actual name instead of it showing up in game as only "Level Name"? Normally now GZDoom for example ignores everything before the colon. However if you use a language string that is nonstandard like LEVELNAME = "Level 1: Level Name" in-game it will show up as "MAP01: Level 1: Level Name"

Share this post


Link to post

UMAPINFO does not in any way preprocess the string, i.e. MAP01: or E1M1: may not be part of it because it'd also show up on the automap twice. The ZDoom hack is for old BEX patches which require this part to be in there.

 

Share this post


Link to post

Here's some brief docs:

 


UMAPINFO uses an ini-like syntax.
A map starts with

[mapname]

follwed by

key = value
key = value1, value2,...

entries. Values can be strings, enclosed in quotation marks ("), numbers or identifiers. Identifiers are case insensitive names that start with a letter and may only contain letters, numbers or the underscore ('_')

The map names are limited to the format of the currently loaded IWAD, i.e. Doom 2 only supports MAPxx entries and Doom 1 only ExMy entries.
The numbers x and y can exceed their original limits, though, so MAP50, E5M6 or even MAP100 or E1M10 are valid map names for their respective game.
This limit comes from the game using numeric variables 'gameepisode' and 'gamemap' to identify a level. It may later be decided to lift the naming restriction but this cannot be done without some extensive refactoring which simply exceeded the scope of the initial implementation.

Currently the follwing keys are supported. If not given, the hardcoded default will be used, unless the following list says differently.

levelname = "name"            ; Specifies the readable name of the level (e.g. "Hangar") This will be used in the automap and also on the status screen if no name patch is specified.
levelpic = "graphic"        ; Specifes the patch that is used on the status screen for 'entering' and 'finished'. This can be omitted, in that case the levelname will be printed with the HUD font.
next = "nextmap"            ; Specifies the map the regular exit leads to. In Doom 1 this may cross episodes.
nextsecret = "nextmap"        ; Specifies the map the secret exit leads to. In Doom 1 this may cross episodes.
skytexture = "texture"        ; Specifies the sky texture to be used for this map.
music = "song"                ; Specifies the music to be played on this map.
exitpic = "graphic"            ; Specifies the background for the 'level finished' screen. This can override Doom's animated screens for E1-3.
enterpic = "graphic"        ; Specifies the background for the 'entering level' screen. This can override Doom's animated screens for E1-3.
partime = "seconds"            ; Specifies the level's par time.
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.
nointermission = true/false ; Currently only working for levels that end the game: When true skips the 'level finished' screen.
intertext = "text"            ; Shows an intermission text screen after the level is exited through the regular exit. "text" can be multiple lines, for ease of reading they can be specified as multiple parameters over several lines (see example below.)
intertext = clear            ; Disables default intermission text for the given map (e.g. to go from MAP06 to MAP07 without a text showing up.)
intertextsecret = "text"    ; Shows an intermission text screen after the level is exited through the secret exit. This will never default to 'intertext'. If not given, the defaults will be used
intertextsecret = clear        ; Disables default intermission text for the given map's secret exit.
interbackdrop = "flat"        ; Backdrop to be used for intertext and intertextsecret. If not specified FLOOR4_8 will be used, regardless of which map it is used on.
intermusic = "song"            ; Music to be used for intertext and intertextsecret. If not specified D_VICTOR/D_READ_M will be used, depending on the IWAD.
episode = clear                ; Clears the episode menu of all previous entries. Should be used on the first map if a mod wants to define its own episodes.
episode = "patch", "name", "key"    
                            ; Defines an entry for the episode menu. If all defined episodes define a valid patch, those will be shown, otherwise the names will be used with the HUD font. At most 8 episodes can be defined.
bossaction = thingtype, linespecial, tag
                            ; Defines a boss death action. Tag 0 is not allowed except for level exits. Shoot triggers, teleporters and locked doors are not supported. A map may define multiple death actions. Thingtype uses ZDoom's class names (see list below.)

                            
Default handling:

Normally, if some information cannot be found, the engine will fall back to its hard coded implementation, with a few exceptions:

- nextsecret: If not present, it will use the normal exit's map if the current map has a MAPINFO record. This also applies to maps which by default have a secret exit!
- enterpic: If the map that was just left has an exitpic entry and the map to be entered has no enterpic entry, the previous map's exitpic entry will be used for both screens.
- levelpic: If not given, the status screen will instead print the map's name with the HUD font to ensure that the proper name is used.
- interbackdrop: This will not look up the default backdrop for a given map but always use FLOOR4_8.

4 people like this

Share this post


Link to post
15 minutes ago, Graf Zahl said:

UMAPINFO does not in any way preprocess the string, i.e. MAP01: or E1M1: may not be part of it because it'd also show up on the automap twice. The ZDoom hack is for old BEX patches which require this part to be in there.

Is there a way around this so that it can display the entire name as-is, not showing MAPxx or ExMx twice?

Share this post


Link to post

What do you want to achieve?

 

Share this post


Link to post

This is cool, really looking forward to trying it out, but I'm getting an error with the exes saying they're not valid Win32 applications on my winxp computer.

Share this post


Link to post

That's because I compiled them with the non-XP toolset which gets set by default on modern MS compilers. Will change for the next build.

 

Share this post


Link to post

I'll give this a try now, but at first glance it looks absolutely excellent Graf. Really, really thoroughly done!

 

Couple of quick questions:

 

How unlimited is the ExMx format? I.e. could we have E1M100 for example?

 

In the long term, if a wad includes both a UMAPINFO and a MAPINFO file, which takes priority in a port (i.e. ZDoom) that supports both? Or is that something to be decided down the road?

Share this post


Link to post

The format is limited by the 8 character limit. As long as the map name can be generated with the "E%dM%d" formatting template it should work, but I haven't run full tests on that part yet.

 

Concering ZDoom, it will always priorizize its own format because that may contain other stuff as well, like global settings or fields that UMAPINFO does not support. The whole thing was designed to make mods like Valiant and Ancient Aliens independent of port specific features. The list of keys may be extended later, it may even get port specific additions but right now the important thing is to either get this into the PrBoom+ mainline or get a forked port up and running, so that it isn't all for nothing. Judging from the reactions here, though, I think this will gain some momentum with or without Entryway's participation. He hasn't done much over the last year anyway.

 

 

1 person likes this

Share this post


Link to post

Makes sense, thanks.

 

And I agree. A proper MAPINFO for PRBoom is a wonderful thing: it's always bugged me that if you wanted to define something as simple as map progression you had to leap all the way to an advanced port, even if the maps themselves were as simple as limit removing.

 

Certainly as a spring board for adoption of a PRBoom++ (if you will) this is a logical place to start. 

Share this post


Link to post

I mean prboom+ is the continuation of a port that was the continuation of two other ports, and it basically became the new Boom standard. If prboom+ doesn't adopt the new stuff and the other port takes off, it'll end up either becoming obsolete or best case scenario the lesser of two ports.

Share this post


Link to post
On 4/22/2017 at 7:25 AM, Graf Zahl said:

First test version:

 

https://github.com/coelckers/prboom-plus/releases/tag/2.5.1.4_umapinfo_beta

 

 

Documentation is in the works and will come later today.

 

This is great news! Great job, Graf!

On 4/23/2017 at 2:08 AM, Death Egg said:

I mean prboom+ is the continuation of a port that was the continuation of two other ports, and it basically became the new Boom standard. If prboom+ doesn't adopt the new stuff and the other port takes off, it'll end up either becoming obsolete or best case scenario the lesser of two ports.

I have decided to operate on the assumption that most ports will adopt an enhanced standard, especially as the benefits become clear. Either way, there will be ports with the enhanced spec, in time.

Share this post


Link to post

Ultra-cool! I'll see if I can rig up Lost Episode with this later (assuming PR+ is okay with the doom2 content imports), for fun n' profit.

 

Since inevitably this thread is going to devolve into name suggestions in case PR+ does end up getting forked, allow me to be the first to toss "KaBoom" out there. Bacronym at your leisure, folks.

2 people like this

Share this post


Link to post

PrBoom still maintains the original restrictions, i.e. it blocks spawning the Doom2 monsters, and the SSG and Megasphere are nonfunctional. This would actually be one of the first things I'd lift for a new complevel because come on - that's really not necessary and can be handled more smartly.

 

Share this post


Link to post

Did vanilla (Ultimate Doom EXE) even enforce such a thing? I swear I remember importing Doom2 assets and having them work (sans SSG), but this would've been a near-decade ago so my memory may be faulty.

Share this post


Link to post
On 4/22/2017 at 9:06 AM, Graf Zahl said:

What do you want to achieve?

I want to be able to put something like

D64HUSTR_1 = "Level 1: Staging Area";

into LANGUAGE and have MAP01 display everywhere as Level 1: Staging Area and not MAP01: Staging Area.

Share this post


Link to post
50 minutes ago, Xaser said:

Did vanilla (Ultimate Doom EXE) even enforce such a thing? I swear I remember importing Doom2 assets and having them work (sans SSG), but this would've been a near-decade ago so my memory may be faulty.

Well, you can use the new monsters and all of their functionality, provided you change the editor numbers.

 

SSG and megasphere, however, are rekt on a deeper level.

Share this post


Link to post
51 minutes ago, Nevander said:

I want to be able to put something like


D64HUSTR_1 = "Level 1: Staging Area";

into LANGUAGE and have MAP01 display everywhere as Level 1: Staging Area and not MAP01: Staging Area.

Display of the map level is a user option in ZDoom, not a mapper option. And that's entirely intentional.

 

Share this post


Link to post
3 hours ago, Xaser said:

Ultra-cool! I'll see if I can rig up Lost Episode with this later (assuming PR+ is okay with the doom2 content imports), for fun n' profit.

 

Since inevitably this thread is going to devolve into name suggestions in case PR+ does end up getting forked, allow me to be the first to toss "KaBoom" out there. Bacronym at your leisure, folks.

I knew I should have called dibs on the name "KBoom" for my sourceport several days ago. :V

Share this post


Link to post
40 minutes ago, Xaser said:

Did vanilla (Ultimate Doom EXE) even enforce such a thing? I swear I remember importing Doom2 assets and having them work (sans SSG), but this would've been a near-decade ago so my memory may be faulty.

Yep.

 

	// Do not spawn cool, new monsters if !commercial
	if ( gamemode != commercial)
	{
	    switch(mt->type)
	    {
	      case 68:	// Arachnotron
	      case 64:	// Archvile
	      case 88:	// Boss Brain
	      case 89:	// Boss Shooter
	      case 69:	// Hell Knight
	      case 67:	// Mancubus
	      case 71:	// Pain Elemental
	      case 65:	// Former Human Commando
	      case 66:	// Revenant
	      case 84:	// Wolf SS
		spawn = false;
		break;
	    }
	}
	if (spawn == false)
	    break;

Note that it will spawn everything else that's not listed -- decorations, commander Keen, no problem. Note also that you can bypass this by using dehacked to change the editor numbers to something else that's not on this list. Note finally that while you can spawn  a supershotgun or a megasphere, they'll be disabled elsewhere.

Share this post


Link to post

If you're going to do a rerelease of The Lost Episode, Xaser, you could always just edit the newer Lost Episode version to remove the SSG. It took away from the feeling of Doom 1, personally.

Share this post


Link to post

Just gonna note that some of the semantics aren't currently compatible with how EE handles some things, so we'd have to make various changes to fully support it to spec (as opposed to just being able to parse/load it, with some things not behaving in a compliant fashion). I don't have time to sum that up right now but hopefully I can do it later.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now