"UMAPINFO" discussion

[Graf Zahl]

Universal means that the lump can be read universally, not that its contents are understood universally. Port specific features should still be kept to a minimum and only be done where it is helpful.

 

[Ladna]

What would those features be?

[Ladna]

(double post, yeh)

 

Hmm, thinking about it, I kind of agree with Gez.  I think a prefix format like "-zdoom.blah" makes sense.  And then, just like with CSS, when most ports support "blah", you move it up into non-prefixed namespace.  +1.

 

EDIT: Not gonna triple post, too classy

 

UMAPINFO.txt uses ',' for multiline strings, but I can't find an INI library that matches this.  INI files don't require quotes around the values, so they either just detect the multiline string:

 

[magic]
multiline_string = this is a
                   multiline string

Or they use '\':

 

[use_slash]
multiline_string = this is a \
                   multiline string

So the main incompatibilities I see so far are:

- Requires quoted values

- Uses ',' for multiline strings instead of just detecting them or '\'

 

I am completely happy to do the work to use INI files instead of the current proposed format.  If no one volunteers instead, I'll try and find some time in the next couple days.

 

EDIT AGAIN:

 

It turns out that time is now.  Graf, I sent you a PR.  The main things are:

- INI format

- UTF-8 OK

- Multiline strings are magically stuck together

- Maybe better number handling (don't accept floats when you want ints)

- Much more flexible identifiers.  Because everything's a string, you can have values like 112302@@*923, or maybe more importantly UTF-8 identifiers.

 

It's a little rushed, it's 2:30am here and I have a busy day tomorrow so I wanted to push through it.  It compiles, but I haven't tested it on a test lump yet.

 

LMK :)

Edited April 30, 2017 by Ladna

[Graf Zahl]

I'll have a look. The good thing is that this builds on a ready-to-use parser, which is always an advantage, but I can't say I like the quote-less syntax.

 

Since you mentioned the tabs in the PR, that's done by Visual Studio's autoformat. The main problem I see with the PrBoom source is that it is atrociously formatted, so any time an autoformatter goes at it it will change things. Indentation in many parts of the code base is so way off the charts that the code is close to unreadable. I can tell you that if I ever take this as a project I'm going to do more work on, some serious reformatting is coming.

 

[Ladna]

Oh I see.  Yeah it's basically just fucked up.  I use uncrustify liberally, basically on every file before I start editing it if I haven't before.

 

Quote-less feels a little too free form to me too, but I guess that's what INI files are *shrug*.  I was a little surprised.  On the bright side, users might like it better.

[Shadow Hog]

I only just heard about this today, but I gotta say, this is the sort of functionality I've been wishing PrBoom+ would have for years now. The whole "secret maps are always in MAP15 and MAP31, MAP07 is the only map you can do sector-effecting specials in" schtick that every single megaWAD worth noting has adhered to was getting rather stale (even if the rest of their content made up for these shortcomings), so anything to help mix that up, I approve of. Hope this takes off!

[Marcaek]

Don't forget monsters telefragging on map30!

[Ladna]

Hey Graf.  Re: your comments in the other thread I made the following changes to the PR:

• Allocate lines on the heap on the stack
• Increase the line length limit to 1MB
• Add line number information to errors

These are done via preprocessor defines, so you'll probably have to modify the VS project.  Here's what I set:

/* Pass line number to INI key/value handler (required) */
#define INI_HANDLER_LINENO 1
#define INI_MAX_LINE 1048576
/* Define to stop INI parsing on the 1st error */
#define INI_STOP_ON_FIRST_ERROR 1
/* Define to allocate INI lines on the stack */
#define INI_USE_STACK 0

 

Edited May 5, 2017 by Ladna

[printz]

Since Graf Zahl mentioned he prefers a more structured format than INI, hinting at DECORATE, and I said in another thread that it would be quite nice if it works with the EDF parser. Any subset is fine by me. UDMF TEXTMAP itself is a subset to EDF/Extradata. Equals and semicolons are optional in EDF. What is not optional yet is commas in braced lists of data (e.g. args {1, 2, 3, 4, 5}). What Quasar added in the latest versions are some new tricks, such as what you see in thingtype damagefactor, or colon-noted doomednum and inheritance.

 

INI is what EMAPINFO most resembles. I think it's fraggle's creation when he was a teen (congrats making a port at that age...) working on SMMU.

 

I swear I'm having trouble understanding Quasar's Eternity XL_ parser source code, despite his boasting he made it for all those legacy Hexen and EMAPINFO formats...

Edited May 6, 2017 by printz

[Death Egg]

I have yet another reason to add port-specific blocks; for a mod I'm throwing around the idea of having port-specific maps to get people to try and get out of their comfort zone. Would UMAPINFO adding this feature be the best way about it?

[Gez]

I'd say that sounds like kind of the opposite of what we're trying to achieve with UMAPINFO, really.

[Da Werecat]

I had the same thought: a few "bonus" port-specific maps in one of my planned wads, but I think my initial idea of using port-specific MAPINFO lumps for this is cleaner.

Edited May 10, 2017 by Da Werecat

[Graf Zahl]

I just updated UMAPINFO to use curly syntax and added a new tokenizer for that, taken from USDC.

That new tokenizer also will come in handy when implementing some DECORATE lite.

 

My goal here is that the parsers and tokenizers can be taken as-is by other ports and only need to fill in the blanks to store the data in an engine dependent data.

Regarding DECORATE lite, I'll only expose the common Boom code pointers plus a very small set of added functions like generic projectile spawning, A_SeekerMissile and A_Jump, so that it can do a little bit more than just replicate Doom monsters. I'll also not use the name DECORATE here for technical reasons.

The entire thing should have minimal impact on game logic but it may be necessary to turn a few monster specific checks into actual properties in order to make them generally usable (like the special attack range checks for Revenants and Arch Viles, and the attack probability modifications for the boss monsters, plus turning immunity to radius damage and full volume sight and death sound into flags.)

 

[kb1]

On 5/20/2017 at 7:29 AM, Graf Zahl said:

I just updated UMAPINFO to use curly syntax and added a new tokenizer for that, taken from USDC.

That new tokenizer also will come in handy when implementing some DECORATE lite.

 

My goal here is that the parsers and tokenizers can be taken as-is by other ports and only need to fill in the blanks to store the data in an engine dependent data.

Regarding DECORATE lite, I'll only expose the common Boom code pointers plus a very small set of added functions like generic projectile spawning, A_SeekerMissile and A_Jump, so that it can do a little bit more than just replicate Doom monsters. I'll also not use the name DECORATE here for technical reasons.

The entire thing should have minimal impact on game logic but it may be necessary to turn a few monster specific checks into actual properties in order to make them generally usable (like the special attack range checks for Revenants and Arch Viles, and the attack probability modifications for the boss monsters, plus turning immunity to radius damage and full volume sight and death sound into flags.)

 

Are you considering writing this now? If so, that's very cool. But, please expect that there's the possibility to need some slight modification in the future.

[Graf Zahl]

I'll do the DECORATE stuff when I have time. Of course, before finalizing it we first need a working draft and that's what this is about.

 

[Blastfrog]

Can we please consider renaming it to Decolite in both branding and actual lump name? At least two people seem to have responded positively to it even though I wasn't all too serious at the moment I suggested it.

 

Giving it some more thought, I think it might actually be a good choice of name. It's shorter, remains just as descriptive, and distinguishes it more from Decorate itself.

Edited May 24, 2017 by Blastfrog

[Graf Zahl]

We can name it whatever the consensus says. We only should make sure it's not something that may have been used as a texture name.

 

[Death Egg]

If it counts for anything, I liked DECOLITE too.

[Shadow Hog]

Sure, why not? If they have to be distinct names from one another, and the "DECOLITE" name's apt enough, then I guess it'd work.
 

[Blastfrog]

Another thing to consider; the new format may or may not end up being compatible with actual Decorate, and there are instances where you'd want to have both without conflict.

 

Yes, mainline GZDoom has ZScript now, but there are going to be plenty of modders sticking to old Decorate even when they shouldn't. Also, Zandronum, short of a total rewrite, is probably going to be pretty stuck in how GZDoom was circa 2012 or so.

[Graf Zahl]

1 hour ago, Blastfrog said:

Zandronum, short of a total rewrite, is probably going to be pretty stuck in how GZDoom was circa 2012 or so.

Why that? I am not closely following their development but Torr Samaho had some input with ZScript and to my knowledge they are keeping a branch that is up-to-date with GZDoom. They are merely slow with releases.

 

[Blastfrog]

I could very well be wrong about that, and probably am.

 

Last time I messed with Zandronum about a year ago (the latest in-dev version of the time, not a release), everything just looked and felt ancient. The menus were all organized like old versions, lots of little extra features still didn't seem to be ported in, etc.

 

I also was under the impression that it would be a monumental task to update the engine. GZDoom 1.9 wasn't really all that long ago, and now 3.x seems to be a complete overhaul since then. I thought Zandronum wasn't even up to date with 1.9, yet.

[kb1]

14 hours ago, Graf Zahl said:

I'll do the DECORATE stuff when I have time. Of course, before finalizing it we first need a working draft and that's what this is about.

 

Ok, understood - sounds good.

[Death Egg]

I still think that what should happen is that GZDoom should get it's own C/S multiplayer and, once it's completely stable and on par with Zandronum, move the dev team over and just have GZDoom. That still leaves the task of deciding what to do with the monumentally different ZDoom and Zandronum communities, but why not just leave them separate and use the same port? All Zandronum is anyway is GZDoom with better multiplayer and less features. I imagine it would be years for that to take place but it'd be worth it.

 

Regardless, this is getting offtopic. Feel free to ignore this rant or split it into a different discussion if it keeps up.

[Blastfrog]

At risk of derailing, I'll toss in some of my own thoughts on the subject:

 

If doing some kind of "unification" thing, might as well just call it "ZDoom" while you're at it. For years, all ZDoom amounted to was GZDoom minus GL rendering and a few features like Fragglescript support (IIRC), Randi wasn't even actively working on it (exceptions here and there, but really, he wasn't working on it). The project had already changed hands. By making a final release, Randi acknowledged the reality that his version of ZDoom had, in fact, been dead for years.

 

Problem is, Randi won't give up the name. In that case, why not register a gzdoom.org domain and stop using the zdoom.org domain? Or just give up the name because it's the sensible thing to do? Seems pointless to maintain the discrepancy, and it will confuse newcomers.

 

On that note, why GZDoom Builder? It's just Doom Builder. 3dge? Just Edge. PrBoom+? No, it's PrBoom. These are merely the newest versions of staple software that happen to have new maintainers, they are not truly distinct from their "predecessors" in any real way.

Edited May 25, 2017 by Blastfrog

[Coraline]

3DGE and EDGE are not compatible with each other anymore. We have done such a huge amount of work on new features, changes to original behavior, and bug fixes that we had to add a compatibility switch for emulated original EDGE behavior.

 

So, its not entirely wise to just call it EDGE unless people know it won't work with the original 1.35 release. I know there are still people that use the original EDGE releases and it can get quite confusing, but its ultimately up to the maintainer. 

[Blastfrog]

Ah, okay. My misunderstanding then, I hadn't realized that it changed so much to the point of incompatibility.

 

I think what I said still applies to those other programs, however (and in the case of one of them, I know the maintainer agrees with me).

[Graf Zahl]

So, seeing that the 'enhanced features' thread got talked to death by not focussing on the essentials and I received absolutely *ZERO* feedback on the entire UMAPINFO discussion after my last update, not to mention a profound display of disinterest by other port developers I'd like to ask if it makes even sense to continue with this.

 

I am a bit puzzled. There seems to be some interest among mappers to get a 'better Boom' but nobody who is in a good position to make it happen seems to want to do it and instead stick to the same ancient feature set from almost 20 years ago. It should be said clearly that in this situation it may all just be a waste of time.

 

No, I do not want to see this all go to waste but it's not something I can do all on my own.

 

[Urthar]

I've often refrained from posting in the enchanced features thread, since I had no expertise regarding implemention, and I was paranoid of derailing a thread that could possibly lead to 'good things' happening. And UMAPINFO would probably be the most important of those good things, from my own point of view.

 

I did feel the whole scripting discussion was going down a blind alley. Did any mappers actually come forward to ask for it? I have to suspect it's something that's best left to Hexen and UDMF formats.

 

It might be useful to start a private thread amongst source port developers to ask whats the minumum feature set, that everyone is willing to implement.

 

Edited June 20, 2017 by Urthar

[Graf Zahl]

1 hour ago, Urthar said:

It might be useful to start a private thread amongst source port developers to ask whats the minumum feature set, that everyone is willing to implement.

 

Agreed. That is, if the relevant ports' authors had even shown more than some superficial acknowledgement.

 

Like I said: The main problem with the whole thing is to get the major ports on board, not discuss theoretical features that ultimately only serve to keep those people away whose support is most needed.