"UMAPINFO" discussion

[Graf Zahl]

Blocks or not, that problem is the same.

 

[esselfortium]

2 hours ago, Gez said:

If you just skip unknown keys, you remove an error checking mechanism. Suppose there's a "skytxeture" key, if it's ignored the user won't be told about the typo. A way to distinguish between skippable keys and core keys is needed.

Would it be a fair compromise to have some sort of debug mode that outputs unknown keys to the console, while avoiding error messages for standard play? Ports like EE and ZDoom that have consoles could include this, at least.

[Gez]

How so? A typo in a core key would be detected by any engine; a typo in a ZDoom section would be detected by ZDoom and ignored by other engines. Makes sense.

 

 

Alright, let's go look at a real-world, Doom-related example. Editor_keys

 

This is a mechanism by which map editors (DB2 & forks and SLADE 3 so far) can have extra data given to them in DECORATE code. The system uses comments so that these editor keys are skipped over by ZDoom. It's not the most elegant thing because it has to highjack the comment functionality, but it works. Do their existence mean that ZDoom has to handle them? Nope, the only handling needed is to skip them, which it does. Everyone is happy.

 

Let me give you a good example for why extra keys need to be namespaced somehow: we'll go back to your example of a skybox property. There's one for ZDoom, where it's defined by listing the skybox textures in order, let's say, top, bottom, east, north, west, south. Now independently EE comes up with a skybox property as well, but it's an independent implementation that didn't even know there was one in ZDoom and the textures are listed in the order east, north, west, south, top, bottom.

 

With namespacing the extra keys, you get

• Smart error checking
• Collision avoidance
• Infinite extensibility
• De-duplication of work

Without namespacing the extra keys, you get

• Either no error checking or spurious error checking
• Potential collisions causing incompatibilities
• Frozen design or the need to maintain some sort of permanent standard committee
• Need for modders to maintain three or four separate map definitions instead of just one

 

There are only good things to come from defining a namespacing mechanism for arbitrary extra keys, and only drawbacks from refusing to do so.

[Graf Zahl]

23 minutes ago, Gez said:

How so? A typo in a core key would be detected by any engine; a typo in a ZDoom section would be detected by ZDoom and ignored by other engines. Makes sense.

 

Other ports still need to check the section for syntax errors instead of blanketly skipping it, so we're back to square one.

The worst thing imaginable is a lump that works with port A and aborts with a syntax error in port B.

 

[Gez]

If we use sub-blocks like this:

zdoom
{
	blah zdoom options
}

Then what the engine must do when it reaches the { is skip until the }. It doesn't have to try to validate the content of a block it doesn't know about.

 

Would it be possible that someone messes up in a sub-block and create error message in the port targeted by this sub-block? Sure; but how is that different from making a mistake in an EMAPINFO or ZMAPINFO lump? I remember that the first release of Doom: The Lost Episode had a bogus EMAPINFO definition.

 

One thing to keep in mind is that if someone adds some port-specific fine-tuning, presumably, they should test that it works with that port.

 

 

Think about what happens when you load something like Valiant in PrBoom+ right now: there is a ZMAPINFO lump that is ignored. PrBoom+ does not try to validate the syntax of ZMAPINFO. There is an EMAPINFO lump that is also ignored. PrBoom+ does not try to validate the syntax of EMAPINFO either. Here the point of UMAPINFO is that it allows to remove the need for work duplication by using the same, universal map definition for every port. There can still be some port-specific fine-tuning settings that will be needed, and for them we want to keep the existing behavior of having other ports just ignore it without needing to have duplicated effort by forcing modders to maintain three or more MAPINFO lumps.

 

Take a community project, where up to the last minute some maps get shuffled between slots. Figure that someone forgot to update, say, the EMAPINFO lump and it goes out of sync with the rest, resulting in the wrong map information because it still says that MAP27 is "The Crushcible" while it has been replaced by "Cyberdrome" or whatever. Now add to this that with UMAPINFO in the picture the errors could go beyond just a wrong title and par time, but also include stuff like wrong boss death or wrong secret exit.

 

TL;DR: without namespacing extra keys, redundant lumps are needed; redundant lumps increase the potential for errors. You're a coder, you know code duplication is bad!

[Graf Zahl]

Can you please stop this unproductive discussion? In the current state it leads absolutely nowhere!

 

You've been ranting on and on about a technicality here that needs to be addressed once the lump gets universal support. Until that point I won't waste any thought about how to best approach these things because it also requires input from the actual port developers that have to maintain this.

Where precisely is your stake in the matter that you are so insistent on this particular way of solving the issue?

 

[Quasar]

I'd also note that, if port specific keys are really necessary, you could always just prefix them with the name of the port (ala "zdoom.someoption") rather than having to over-complicate the parser by requiring it to skip an arbitrary token stream to look for the next curly closing brace.

[Graf Zahl]

That was precisely my thought about that matter as well.

In the end the property's parameters need to obey the same syntax as the basic keys so whether the parser skips a block or just the parameters of an unknown property will effectively be the same - but skipping just the parameters is a lot simpler because it can entirely build upon the base implementation, unlike the block!

 

[Gez]

11 minutes ago, Graf Zahl said:

Can you please stop this unproductive discussion? In the current state it leads absolutely nowhere!

 

You've been ranting on and on about a technicality here that needs to be addressed once the lump gets universal support. Until that point I won't waste any thought about how to best approach these things because it also requires input from the actual port developers that have to maintain this.

Where precisely is your stake in the matter that you are so insistent on this particular way of solving the issue?

 

I know you well enough to know that your "I don't want to think about it now" means "I will make sure this never happens".

 

7 minutes ago, Quasar said:

I'd also note that, if port specific keys are really necessary, you could always just prefix them with the name of the port (ala "zdoom.someoption") rather than having to over-complicate the parser by requiring it to skip an arbitrary token stream to look for the next curly closing brace.

Yes, I did mention two possible approaches for namespacing extra keys, sub-blocks and prefixing. I also cited CSS as an example of language in which prefixes are used. But there needs to be a namespacing mechanism, I don't care which one.

[Graf Zahl]

1 minute ago, Gez said:

I know you well enough to know that your "I don't want to think about it now" means "I will make sure this never happens".

 

Again: What's your stake in this?

[Bauul]

I can see where @Gez is coming from: you don't want to have to duplicate (and risk differences in) basic MAPINFO variables if you had to have port-specific MAPINFOs in addition to UMAPINFO.

 

Original message: "We could have two lumps!"

 

Edited message: ah, ok, if that isn't feasible (though I still don't quite see it as the nightmare described) then ok.

 

Although now I'm more confused than before, because if we genuinely should have just one lump then Gez is right, we do need to define where the port-specific stuff falls. Not yet, but at some point anyway.

 

I'll sit this one out and let you experts work it out! :D

Edited April 26, 2017 by Bauul

[Xaser]

There would absolutely be duplication if I (a mapper) had to make both a UMAPINFO and a ZMAPINFO lump. If I've got a 9-level wad, I've got to write the "MAP01", "MAP02"... "MAP09" headers twice each.

[Graf Zahl]

12 minutes ago, Bauul said:

I can see where @Gez is coming from: you don't want to have to duplicate (and risk differences in) basic MAPINFO variables if you had to have port-specific MAPINFOs in addition to UMAPINFO.

 

But... you wouldn't have to duplicate stuff. All the universal variables like name, sky etc. would only need to appear in UMAPINFO. You wouldn't have to rewrite them in ZMAPINFO or whatever.

 

ZMAPINFO would contain just one variable: skyfog.

 

It doesn't work like that. Allowing both to be read from the same mod and mixing their definition is the ultimate nightmare implementation.

But my concern still stands: Not only is Gez's approach putting a lot more strain on the parser, but before thinking about such stuff we need to get the baseline working and getting accepted! Before that isn't complete it is utterly pointless to think up how to implement extensions.

[Bauul]

Instead of derailing the conversation by attempting to talk about stuff I'm not very familiar with, I thought I'd be a bit more useful and spend a few hours playing around with your PRBoom+ test build @Graf Zahl, and see if I could provide any feedback.

 

Attached is a 3 map test wad I created for Ultimate Doom, with as complete a UMAPINFO as I could without bits being contradictory.

 

Most things, bar one, worked pretty perfectly after a bit of figuring out.  Below are a few notes I made as I went along on the specific functions that took me a little time to get right.

 

levelpic = "graphic"

Your original instructions say “Specifies the patch that is used…” This confused me for a while as I kept trying to use textures patches.  Once I realized you meant a graphic entry, it worked.

 

partime = "seconds"

Tried “600” and got a “cannot find a property value in line 8” error.  Dropped the “”s and it worked, but then noticed this version of PRBoom doesn’t seem to list PAR values anyway (or is that a setting?)

 

endgame = true

Doesn’t seem to work properly, just moves to the next level. Overwrites the “next = nextmap” value in the process though.

 

endpic = "graphic"

Triggers the end of the game even if “endgame = true” isn’t present.  So at the moment "endgame = true" seems somewhat redundant?

 

endcast = true 

Crashes Doom 1, unsurprisingly.  Although for a second I was super hopeful it'd somehow work!

 

Intertext = …

If text is defined here, it seems to be used for all subsequent intermission screens until either new text is defined, or intertext = clear is used.  For example if E1M1 uses intertext, and then E1M2 has “endgame”, then unless new text is defined it’ll reuse E1M1’s text again.  It's not an issue if every map is defined properly, just something I noticed.

 

"Intertext = clear" seems to overwrite the endgame function though.  As in, if you define this in a map, any "endgame" or "endpic" functions don't seem to work.

 

bossaction = thingtype, linespecial, tag

The one thing I couldn’t get to work.  I could define the thingtype fine, but I wasn’t sure what was supposed to go in linespecial or tag.  E1M3 of the wad is meant to open a door to the exit once the imp is killed, but I couldn't work out what to type.  Any suggestions?

 

But generally speaking even for a complete coding novice like myself it was pretty damn easy to apply.  Very nicely done!

UMTest.zip

[Graf Zahl]

40 minutes ago, Bauul said:

 

partime = "seconds"

Tried “600” and got a “cannot find a property value in line 8” error.  Dropped the “”s and it worked, but then noticed this version of PRBoom doesn’t seem to list PAR values anyway (or is that a setting?)

 

I know. It was a typo but the forum wouldn't let me correct it because it was inside a [ code ] tag which got converted to something non-editable.

 

40 minutes ago, Bauul said:

partime = "seconds"

Tried “600” and got a “cannot find a property value in line 8” error.  Dropped the “”s and it worked, but then noticed this version of PRBoom doesn’t seem to list PAR values anyway (or is that a setting?)

Indeed. There seems to be something else preventing proper display.

44 minutes ago, Bauul said:

endcast = true 

Crashes Doom 1, unsurprisingly.  Although for a second I was super hopeful it'd somehow work!

It will work if the proper assets are provided. The crash is simply the result of not finding them (quite unsurprisingly, indeed.)

46 minutes ago, Bauul said:

Intertext = …

If text is defined here, it seems to be used for all subsequent intermission screens until either new text is defined, or intertext = clear is used.  For example if E1M1 uses intertext, and then E1M2 has “endgame”, then unless new text is defined it’ll reuse E1M1’s text again.  It's not an issue if every map is defined properly, just something I noticed.

Actually, I haven't tested that particular case. This is owed to the crappy end of game code which doesn't work without a text.

47 minutes ago, Bauul said:

bossaction = thingtype, linespecial, tag

The one thing I couldn’t get to work.  I could define the thingtype fine, but I wasn’t sure what was supposed to go in linespecial or tag.  E1M3 of the wad is meant to open a door to the exit once the imp is killed, but I couldn't work out what to type.  Any suggestions?

Any linedef type that can be activated as a switch or by crossing it should do, this actually worked for me as intended. The tag obviously needs to be the sector tag that should be triggered, like 666 in E1M8, but can be any number.

 

 

 

[kb1]

4 hours ago, Graf Zahl said:

It doesn't work like that. Allowing both to be read from the same mod and mixing their definition is the ultimate nightmare implementation.

But my concern still stands: Not only is Gez's approach putting a lot more strain on the parser, but before thinking about such stuff we need to get the baseline working and getting accepted! Before that isn't complete it is utterly pointless to think up how to implement extensions.

Graf's right here - it's about the baseline. Weigh the pros and cons:

 

Pros: PrBoom and others can define MAPINFO!!! And that one lump serves all of them!

Cons: You might have to do a cut and paste for a period of time, until the format can catch up and handle advanced stuff.

 

Again, it is the first rollout. It may be all that some ports require. This alone is reason enough to halt development and deliver version 1.0. There is a chance that port devs still don't adopt it. But it will never be universally adopted if it never gets released.

 

This is the first time in a long time that productive standards discussions have picked up momentum. Graf took it a step further and actually built the first part! Thanks, Graf! Please give it a chance, and let's see what develops. It doesn't make sense to put a lot of additional effort into this first part, before seeing if this thing can get off the ground. As it stands, it provides some nice functionality that never existed in these ports. Any issues will be worked out in time. For now, may you have to cut and paste a few text lines. It's worth it.

[scifista42]

10 hours ago, Bauul said:

bossaction = thingtype, linespecial, tag

The one thing I couldn’t get to work.  I could define the thingtype fine, but I wasn’t sure what was supposed to go in linespecial or tag.  E1M3 of the wad is meant to open a door to the exit once the imp is killed, but I couldn't work out what to type.  Any suggestions?

Linespecial is presumably the number of the respective special, as referenced on doomwiki or that you can see in a map editor next to the special's name. But is bossaction supposed to work if thingtype is not one of those things that call BossDeath in their death states? Which, out of unmodified stock monsters, are only Baron, Cyberdemon, Mastermind, Mancubus and Arachnotron.

Edited April 27, 2017 by scifista42

[Graf Zahl]

Bossaction requires calling A_BossDeath. With, with Dehacked you can put onto any item in the game so I made no restrictions.

 

[scifista42]

If Bauul didn't know about BossDeath and thought that the action would be activated by mere death of the monsters, he might have incorrectly expected it to work on a regular non-DEHACKED-modified Imp, though.

Edited April 27, 2017 by scifista42

[Graf Zahl]

This will obviously require some more detailed documentation later, the stuff I wrote was just a quick summary.

 

[scifista42]

Oh, and by the way:

13 hours ago, Graf Zahl said:

It was a typo but the forum wouldn't let me correct it because it was inside a [ code ] tag which got converted to something non-editable.

Code tag blocks can be edited, either by double-clicking them or by selecting them and using the same button that you use to create a new code tag block.

[Bauul]

6 hours ago, scifista42 said:

If Bauul didn't know about BossDeath and thought that the action would be activated by mere death of the monsters

Oooh I'd completely forgotten about the BossDeath flag! Yup, that'll be why it didn't work. Thanks Sci!

[Graf Zahl]

4 hours ago, scifista42 said:

Oh, and by the way:

Code tag blocks can be edited, either by double-clicking them or by selecting them and using the same button that you use to create a new code tag block.

Like much of the post editor, not really intuitive...

 

[Blastfrog]

A few suggestions:

 

1. If the start map of an episode is missing, don't crash, just skip displaying it as if it weren't defined. This would be useful for creating modular level sets that could be loaded via optional additional PWADs.

2. Allow definition of a custom demo loop. Just like episodes, missing demos should be skipped as well.

3. Allow definition of "Read this!" text to appear on menu optionally, and alternately in Doom 1, be able to remove it.

4. Allow definition of the duration that the titlescreen lasts, preferably in tics.

5. Allow for unique intermission music and background to be defined per map and/or per group of maps. (including the ability to specify animations and Doom 1 style location marks)

[Graf Zahl]

2., 3. and 4. have nothing to do with map progression so this needs to be put somewhere else.

5.: Will come later. This code is incredibly messed up and can benefit from some cleanup, that could include support for ZDoom's intermission screen scripts. I wouldn't try to reinvent this wheel when it already works elsewhere. Of course this needs to be carefully done because - how else could it be - there were timing differences in there between Doom versions that affect demo sync.

 

 

[kb1]

3 hours ago, Blastfrog said:

A few suggestions:

 

1. If the start map of an episode is missing, don't crash, just skip displaying it as if it weren't defined. This would be useful for creating modular level sets that could be loaded via optional additional PWADs.

2. Allow definition of a custom demo loop. Just like episodes, missing demos should be skipped as well.

3. Allow definition of "Read this!" text to appear on menu optionally, and alternately in Doom 1, be able to remove it.

4. Allow definition of the duration that the titlescreen lasts, preferably in tics.

5. Allow for unique intermission music and background to be defined per map and/or per group of maps. (including the ability to specify animations and Doom 1 style location marks)

Good ideas! But:

3 hours ago, Graf Zahl said:

2., 3. and 4. have nothing to do with map progression so this needs to be put somewhere else.

5.: Will come later. This code is incredibly messed up and can benefit from some cleanup, that could include support for ZDoom's intermission screen scripts. I wouldn't try to reinvent this wheel when it already works elsewhere. Of course this needs to be carefully done because - how else could it be - there were timing differences in there between Doom versions that affect demo sync.

 

 

...I'd say GAMEINFO, but ZDoom and KBDoom both use that lumpname (for different reasons..errr. I'll change my port to use a different name). Maybe "USYSINFO"? I like the thought of starting these types of lumps with "U" for "universal", and the "...INFO" is similar to "UMAPINFO", which is nice. but I don't know about the "...SYS...". Not too many good 3-character options. Hmmm "options"...  "UOPTINFO"?

 

[Graf Zahl]

Something like that. In ZDoom that would go into the 'gameinfo' section of MAPINFO but I do not want to make UMAPINFO a catch-all for such stuff, it is something I'd do differently these days even in ZDoom.

 

[kb1]

20 hours ago, Graf Zahl said:

Something like that. In ZDoom that would go into the 'gameinfo' section of MAPINFO but I do not want to make UMAPINFO a catch-all for such stuff, it is something I'd do differently these days even in ZDoom.

 

Agree. Small, slow changes in the right places. There's no pressing need for any of this to happen quickly. We, therefore, can take our time, and build it right. It's a good time to be doing this - I don't think it would have worked earlier.

[Ladna]

Hey, is this format a valid INI file?  As in, can I use an existing INI library in mainstream languages and read it?  If not, please make it so.

 

Re: prefixes/subblocks --

 

I don't think there should be port-specific things in a universal lump.  It's contradictory.  If you need Eternity/ZDoom/Boom-specific features, use EMAPINFO/ZMAPINFO/MAPINFO.  If your port doesn't implement something specified in UMAPINFO, then your port doesn't support UMAPINFO, too bad.  Am I missing something (probably)?

[Da Werecat]

13 minutes ago, Ladna said:

Am I missing something (probably)?

UDMF comparison maybe.

 

It seems to be down to individual understanding of the word "universal".

Edited April 29, 2017 by Da Werecat