"UMAPINFO" discussion (prev: Why is it MAPINFO is avoided by most 'vanilla true' ports?)

Lately there's been a lot of questions regarding how ports should advance I've noticed. A lot of this is focused on map features or scripting, but MAPINFO is something I've felt should have been adopted widely for a very long time.

 

How is using it considered against the spirit of vanilla? I'm not sure if I have seen it directly, but there seems to be a consensus among people that this is the case. What's so important about, say, loading up a 5 level map pack and once you beat MAP05 you're sent to MAP06 to quit the game on your own?

 

What about unfinished projects that release and have blank map slots so the best they can do is tell the player to skip to the next map and lose all weapons and items in the process? Deus Vult II wouldn't have had to put those filler maps in with MAPINFO.

 

What about people who want story text between each map but can only have it after random specific ones?

 

What about people who don't want that text at all?

 

Some people prefer the episode format of Ultimate Doom but want Doom II enemies, and vice versa. There's no option for them in prboom+ or Crispy Doom, so their only choice is to upgrade to ZDoom or Eternity and the likes.

 

What about mapping projects that get so many map submissions they have to cut ten or so into that ZDoom-specific episode only a handful of people play?

 

There's probably plenty of other reasons to list, but honestly this should be enough just to bring up the topic for discussion. There plenty of projects this would benefit, and might even help get rid of the all powerful and great "32 map megawad" that half of anyone who joins the community feels obligated to create and finish as some sort of ritual to prove your mapping worth, or help some struggling community projects find an easy way to finish.

Edited by Death Egg
2 people like this

Posted (edited)

Share this post


Link to post

It always depends on what the port author wants.

 

Someone with a special interest in demo compatibility may not think about gameplay enhancements. That seems to be the current situation with PrBoom+.

Ports like Chocolate Doom, by their very mission statement are out anyway, but if you ask me, the main problem is that even now there's no common format for shared by more than one port.

 

I already said in the other thread that it may help if there's one format that both Eternity and ZDoom can read - maybe that may convince others to jump on board. So yes, I definitely plan to implement an EMAPINFO parser for ZDoom - and then let's hope for some actual progress on the matter.

 

3 people like this

Share this post


Link to post
7 hours ago, Death Egg said:

so their only choice is to upgrade to ZDoom or Eternity and the likes.

And? What is wrong about updating to those ports to achieve this feature? You're not forced to use other features, even though you may like to, if they become available anyway.

Share this post


Link to post
37 minutes ago, printz said:

And? What is wrong about updating to those ports to achieve this feature? You're not forced to use other features, even though you may like to, if they become available anyway.

So, you're a strong supporter for 100% vanilla Doom 2 map sets being limited to only ZDoom and Eternity, due to using map progression that isn't the standard 32 maps with secret exits only being available in MAP15 and MAP31?

2 people like this

Share this post


Link to post

@Printz:

 

I have read your post 5 or 6 times now and still haven't understood what you are trying to say here.

 

Concerning EMAPINFO: While I appreciate that the format is better suited to more basic ports than ZMAPINFO because it doesn't have the concept of clusters, I have to admit after closer analysis that I'd prefer to define something new. The reason for that:

 

1. The format looks like it's exceedingly problematic to parse, unless one uses the same parsing backend as Eternity. The lack of any quotation marks is a serious problem for implementing a generic portable parser.

2. The format is ill suited to contain text literals for intermission texts, it all has to be done through some indirect means which is not user friendly. I prefer the ZDoom way which is either providing the text directly in the lump, putting a reference to the global string table, but of course also allow loading a separate text lump here.

3. There's no direct way to put episode definitions into the lump - they have to be done explicitly in EDF as a menu definition, which is definitely not cross-port compatible - ZDoom is using the episodes for some statistics gathering so they are not just mere menu entries. I think for a user friendly definition format they should be defined inside the map definition lump and then be synthesized from that.

 

Would you be interested if I wrote up a spec for a universal MAPINFO format?

Share this post


Link to post

From a port authors point of view:

First, you need another text parser to read in the MAPINFO lump and fill the data structures. This sucks, because text parsers are always error-prone. Think of line endings, character sets and handling of syntax errors.

Second, you need to parameterize the entire level change and intermission logic to make use of the new data structures. And this code, due to the Vanilla engine already supporting all the possible game modes, is already full of switch/case/if/then/else spaghetti which needs to get preserved for demo and network compatibility. This is quite some effort and not a rather tempting task for a port that aims to remain close to Vanilla.

Share this post


Link to post

How should progress be possible if the very first thing that comes up is not some thoughts how to do it, but some thoughts why NOT to do it?

Of course the system needs to be done in a way that maintains the precise timing of the original as long as the transitions remain the same.

 

If you are concerned about screwing up the original transitions, the easiest soluition for a demo compatibile port is to just run the existing code as-is if a map doesn't have a valid definition entry. That should solve all the problems right from the start - one 'if' in the right place and offloading the new code so that it never comes into play if no redefinitions are loaded.

Of course, if something gets redefined, the same assumption as for everything else needs to be made: Demo playback requires the demo to be played with the same resources as with which it was recorded, as even changing intermission text through Dehacked would be a problem for  multi-map demos.

 

 

 

Share this post


Link to post

What does a barebones MAPINFO format need? A way to associate a map slot with the following information:

  1. Map name (automap)
  2. Map name (intermission graphic)
  3. Music
  4. Sky
  5. Par time
  6. Next level (normal exit)
  7. Next level (secret exit)

Anything else would require non-vanilla features. E.g. Hexen has two skies and Hexen skies have an additional speed parameter, those things would be superfluous for Doom which does not have doublesky or thunder or scrolling sky.

 

Now there's also the question of how to define where episodes start and where text screens are inserted (and what text they contain). In ZDoom, episodes are defined explicitly (name, graphic, shortcut key, and starting map), and text screens are handled by clusters, each map belonging to a cluster and clusters having enter or exit texts. But a different system could be envisaged if desired.

2 people like this

Share this post


Link to post

What I think is essential:

 

Whatever you listed plus:

 

- Episode name (if map is an epoisode start.

- Episode name graphic

- Intermission text

- Intermission text background

- Intermission music

- Status screen background, depending on feasibility separate ones for finished and entering screens.

 

Of course the entire feature needs a design to omit unknown keywords so that we don't end up with people still providing a ZDoom or Eternity MAPINFO becasue the basic one cannot do anything that is needed.

 

1 person likes this

Share this post


Link to post

Heck we could go all out and have something like this (syntax is just an example):
 

MAP01
{
	name = $HUSTR_1
	patch = CWILV00
	music = D_RUNNIN
	sky = SKY1
	par = 30
	exit = MAP02
	secret = MAP30
	prboom
	{
		complevel = 9
	}
	zdoom
	{
		forcenoskystretch
	}
}

Putting port-specific options in the relevant port sub-block would allow parsers to know for sure when something can be ignored.

Share this post


Link to post

Why is name $HUSTR_1 and not "MAP01: ENTRYWAY"?

 

The rest is pretty self-explanatory though.

Share this post


Link to post

$HUSTR_1 will reference the BEX string for map01's name.

Share this post


Link to post

Question still stands in a way; either the string reference or "plain text in quotes" should be parsed IMO.

Share this post


Link to post

@Gez:

 

I don't think subblocks are a good idea. That part wasn't even something I consider essential.

One thing: This is a problem with ZDoom's sc_man which allows quoted and unquoted tokens to be mixed liberally, and even worse with EMAPINFO which has no quotes at all. So, all non-identifiers must be enclosed in quotes. Period.

 

@Jayextee:

 

I don't understand what you are saying. Of course string literals must be allowed, but so must be the option to access the string table.

The '$' prefix to access the string table has been common syntax in ZDoom for a decade and to avoid needless keyword clutter I'd keep that part around.

And also, the 'MAP01' part should be synthesized by the engine, not part of the name, because it will also be needed for the status screen or some other places where a map name will be printed, outside of the automap.

 

One thing that's very important here is that the parser is trivially simple and portable. If the whole thing comes prepackaged with a ready-to-use parser it is far more likely to be used than if it came with a spec saying 'here's what is does, now implement it'.

 

Share this post


Link to post
8 minutes ago, Graf Zahl said:

I don't understand what you are saying. Of course string literals must be allowed, but so must be the option to access the string table.


If string literals are in there, I have no problem. I admit to have no knowledge of BEX or whatever, but am definitely interested in adopting to a universal MAPINFO format. Move along, I guess, nothing to see here. ;)

Share this post


Link to post

+1 to "I like this idea and hope it goes somewhere"

8 people like this

Share this post


Link to post

The spirit of vanilla for me has to do with it being a fixed standard. How Doom is, out of the box, untouched by anyone outside of id software.

 

There's no problem with source ports adopting this feature, but vanilla goes by the assumption that everything will work exactly as intended when used with the product you get when you purchase the game. Any feature that depends on source port authors or the community changing its standards is bending this definition.

1 person likes this

Share this post


Link to post

Since 'vanilla' means that a map set is to work with the original EXE that's obvious.

And obvious 'Boom 2' means the widely accepted editing standard, plus maybe the MBF sky transfers.

 

But that's what these are: Mapping standards. They have absolutely nothing to do with what a port actually implements and I haven't seen any rule saying that any demo-compatible port is not supposed to get a bit further out with its capabilities.

1 person likes this

Share this post


Link to post

I vote the name of this, should it not just be MAPINFO, could be UMAPINFO for Universal MAPINFO, in reference to the same way UDMF is Universal Doom Mapping Format.

Share this post


Link to post

Just a +1 to say this is a brilliant idea.  Obviously Chocolate is out (as it should be) but given MAPINFO doesn't actually change anything in a map, merely information around that map, I see no reason why even something as basic as Crispy couldn't support it in good faith.

 

It really doesn't have to contain much information, but even the basic stuff (name, music, sky, next map) would be a huge boon to pretty much every mapping project out there.

Share this post


Link to post
5 hours ago, Graf Zahl said:

So, if someone volunteers:

 

https://github.com/coelckers/prboom-plus

 

It took me some time to clean it up because the tagging was somewhat weird and did not get converted well.

Volunteers for...? Modifying prboom+ to accept mapinfo?

I'd be up for it, been hunting for a good reason to work with some C code for a while.

 

Just let me know if you'll do a spec I should follow, yes?

 

8 hours ago, fabian said:

Second, you need to parameterize the entire level change and intermission logic to make use of the new data structures. And this code, due to the Vanilla engine already supporting all the possible game modes, is already full of switch/case/if/then/else spaghetti which needs to get preserved for demo and network compatibility. This is quite some effort and not a rather tempting task for a port that aims to remain close to Vanilla.

Isn't a demo's data just "Tic 1: x and y speed, this turning speed, these buttons pressed. Tic 2: x and y speed, this turning speed, these buttons pressed."?

That would mean, in a non-hacky world, that changing how level changes work should have no effect in the demo playback. Same with intermissions.

Edited by Albertoni

Posted (edited)

Share this post


Link to post
15 minutes ago, Albertoni said:

Volunteers for...? Modifying prboom+ to accept mapinfo?

I'd be up for it, been hunting for a good reason to work with some C code for a while.

 

Just let me know if you'll do a spec I should follow, yes?

 

I'll do the parser myself because I want to have one piece of code for all ports interested that can just be dropped in.

For PrBoom my preference would be if it could be merged into the official release, but if that doesn't work out I'll look for alternatives.

 

18 minutes ago, Albertoni said:

Isn't a demo's data just "Tic 1: x and y speed, this turning speed, these buttons pressed. Tic 2: x and y speed, this turning speed, these buttons pressed."?

Yes, but due to the shitty coding the timing of the entire intermission is also relevant, so this needs to be done with care.

(Just looking at the PrBoom code made me realize again how sloppy the original code really was...)

 

1 person likes this

Share this post


Link to post
4 hours ago, Graf Zahl said:

I don't think subblocks are a good idea. That part wasn't even something I consider essential.

The alternatives to subblocks are:

  1. Force multiplication of MAPINFOs (so, UMAPINFO or whatever else for this proposed standard; ZMAPINFO for ZDoom with the ZDoom options, EMAPINFO for Eternity with the Eternity options, BMAPINFO for PrBoom+ with PrBoom+ options, etc.)
  2. Allow everyone to just dump any new keyword they want in the core block, and what happens if two different ports adopt the same keyword but in different ways?

Subblocks seem to me to be the perfect solution to have a one-lump-fits-all system in a forward-compatible manner.

Share this post


Link to post

Let's first develop the basics. The most important thing here is not to define a format but to make something work in PrBoom which still keeps the full mess of how id defined episodes and map progresssion. I won't invest more time in the format itself unless I know if it's doable without disturbing demo sync or not.

 

I also do not want to run into a situation where some keys could be shared but aren't because of subblocks. So before going into details we need to know what is actually needed, and ultimately develop a spec that covers all supporting ports. If that is done right we may not even need subblocks at all.

Edited by Graf Zahl

Posted (edited)

Share this post


Link to post
44 minutes ago, Graf Zahl said:

I'll do the parser myself because I want to have one piece of code for all ports interested that can just be dropped in.

For PrBoom my preference would be if it could be merged into the official release, but if that doesn't work out I'll look for alternatives.

 

Yes, but due to the shitty coding the timing of the entire intermission is also relevant, so this needs to be done with care.

(Just looking at the PrBoom code made me realize again how sloppy the original code really was...)

We just have to summon @entryway and see if he agrees with the concept. :)

 

As for the timing of the intermission, I can't see it being different at all, if we're only allowing changes to what the next maps are, background pictures and positioning for the blood splat in Doom 1. I might bite my tongue on that later, after all this is just from a quick read of wi_stuff.c.

The text screens and cluster definition would be pre-processed on wad load as well, then just change StartFinale in f_finale.c and modify G_WorldDone in g_game.c.

 

I'm honestly thinking I'm overlooking something, this looks way too easy.

 

3 minutes ago, Graf Zahl said:

I won't invest more time in the format itself unless I know if it's doable without disturbing demo sync or not.


Give me some time. Any suggestions for demos to test with? The TASs feel suitable.

Edited by Albertoni

Posted (edited)

Share this post


Link to post
11 hours ago, Graf Zahl said:

@Printz:

 

I have read your post 5 or 6 times now and still haven't understood what you are trying to say here.

 

Concerning EMAPINFO: While I appreciate that the format is better suited to more basic ports than ZMAPINFO because it doesn't have the concept of clusters, I have to admit after closer analysis that I'd prefer to define something new. The reason for that:

 

1. The format looks like it's exceedingly problematic to parse, unless one uses the same parsing backend as Eternity. The lack of any quotation marks is a serious problem for implementing a generic portable parser.

2. The format is ill suited to contain text literals for intermission texts, it all has to be done through some indirect means which is not user friendly. I prefer the ZDoom way which is either providing the text directly in the lump, putting a reference to the global string table, but of course also allow loading a separate text lump here.

3. There's no direct way to put episode definitions into the lump - they have to be done explicitly in EDF as a menu definition, which is definitely not cross-port compatible - ZDoom is using the episodes for some statistics gathering so they are not just mere menu entries. I think for a user friendly definition format they should be defined inside the map definition lump and then be synthesized from that.

 

Would you be interested if I wrote up a spec for a universal MAPINFO format?

I am all for universal formats - I'd love to have one defined. But please consider a format that allows advanced features to be skippable by ports that don't want to implement certain advanced features. For example, indirect translatable strings is a nice feature, but not necessarily supported by all, so maybe the inclusion of a literal default string would be wise. I know it's a tall order to make something powerful, yet backward compatible - so a universal format might be difficult. Maybe you support 2 lumps - the universal one, and a specialized one that takes precedence? Just some thoughts. Good luck!

 

 

Share this post


Link to post
3 minutes ago, kb1 said:

I am all for universal formats - I'd love to have one defined. But please consider a format that allows advanced features to be skippable by ports that don't want to implement certain advanced features. For example, indirect translatable strings is a nice feature, but not necessarily supported by all, so maybe the inclusion of a literal default string would be wise. I know it's a tall order to make something powerful, yet backward compatible - so a universal format might be difficult. Maybe you support 2 lumps - the universal one, and a specialized one that takes precedence? Just some thoughts. Good luck!

 

 

Actually, indirectly translatable things are a necessity if you want to support BEX. Seeing Boom as the minimum standard there's really little point not to do it. All the ports this targets have some means of maintaining a string table. The main issue would be not to use strings that do not exist by default on ports that cannot extend the table, but that's something on a different scale. But like I said earlier, let's first do the basics before going at the more complex stuff. The string indexing is a high level feature that doesn't even come into play for the parser itself.

 

Share this post


Link to post
24 minutes ago, Albertoni said:

As for the timing of the intermission, I can't see it being different at all, if we're only allowing changes to what the next maps are, background pictures and positioning for the blood splat in Doom 1. I might bite my tongue on that later, after all this is just from a quick read of wi_stuff.c.

The text screens and cluster definition would be pre-processed on wad load as well, then just change StartFinale in f_finale.c and modify G_WorldDone in g_game.c.

Careful. Remember that the text is typed on? If the length is different, so is the timing, so this is important. Of course one should assume that it is constant as long as the same text is used.

 

Share this post


Link to post
27 minutes ago, Graf Zahl said:

Careful. Remember that the text is typed on? If the length is different, so is the timing, so this is important. Of course one should assume that it is constant as long as the same text is used.

 

I might be missing something, but if that's true, isn't that an issue with even vanilla Doom?  I.e. if I went into a wad and removed/changed the intermission text using Dehacked, that would presumably screw up any demos recorded on it that crossed an intermission screen too?

 

Maybe I'm just being confused, but are we talking basically about desync issues if someone attempted to run a demo on a wad that had been updated with new MAPINFO?  Because almost aside from MAPINFO, that's inviting problems.  Everyone knows you don't try to run demo files on anything other than the exact version of the wad it was recorded on.

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