Defining a new enhanced source port standard (Boom+/MBF+)

2 minutes ago, Ladna said:

Just kind of personally weighing in a little:

 

- C++: no

- DECORATE: no

- thing/frame definition stuff: no (there's no general agreement on how to do this yet)

- HeXeN: no

- ACS: no

- PortType/MapType: no - see below

- UDMF: yes

- UMAPINFO: if it ends up being an INI file, yes

- Versioning: yes (integers only please)

 

C++: You already stated your dislike for C++ in another discussion, but that is no reason to keep the code base in the dark ages. In the end it is simply the need to integrate code that may sway this one way or the other. Fact is that all ports this may borrow features from are written in C++ and let me tell you one thing: I have absolutely no desire rewriting the code to C just because a few people cultivate a dislike for C++.

 

DECORATE/thing definition stuff: Why not? Give a better reason that 'there's no general agreement'. The inability to define some new things is one of the biggest limiting factors what Boom maps can achieve.

 

Hexen format/ACS: This would be a massive undertaking making it unlikely, but if you say 'no', please tell us why.

 

 

2 minutes ago, Ladna said:

 

Re: PortType/MapType/linedefs:

 

The right way to handle linedef collisions is port-specific configuration.  That port can use heuristics or a database to configure itself, or it can use command-line options, or whatever, but what's done is done.  I deeply dislike the idea of encoding port information in binary map data, which is what it seems like this does (using a mask on linedefs), or using lump files to configure ports on the fly.  These features would only entrench the incompatibility, which should be staunched now.

 

There should be some coordination when using new linedefs to avoid problems like this.  Maybe a linedef registry, I don't know, but something.

 

Actually, the only port that presents an obstacle here is Eternity, which blissfully had been ignoring all allocations ever since its inception, constantly adding new stuff with low numbers and clashing with the other ports which steered clear of each other - even all those Hexen specials that got added still waste this namespace.

ZDoom, Legacy and E/3DGE do not clash, if they use the same number it is for the same action, with the one exception of 272 which caused a fugly hack in ZDoom to support both.

My personal preference here would actually be to ignore Eternity because it blocks 200 numbers for mostly nothing and would force reallocating all the other ports' common features if brought into a standard.

 

12 minutes ago, Graf Zahl said:

C++: You already stated your dislike for C++ in another discussion, but that is no reason to keep the code base in the dark ages. In the end it is simply the need to integrate code that may sway this one way or the other. Fact is that all ports this may borrow features from are written in C++ and let me tell you one thing: I have absolutely no desire rewriting the code to C just because a few people cultivate a dislike for C++.

No standard should specify programming language.  The very idea is ludicrous.  Standards are supposed to allow for a diversity of implementation, not "everyone use this one piece of code I wrote".  That's not a standard; that's homogeneity and a monopoly.

 

I'm not at all interested in a language war.  I'd have the same problem specifying C, Ruby, Go, JavaScript, Rust, or whatever.  It's simply laughable for a standard to specify programming language.

 

13 minutes ago, Graf Zahl said:

DECORATE/thing definition stuff: Why not? Give a better reason that 'there's no general agreement'. The inability to define some new things is one of the biggest limiting factors what Boom maps can achieve.

 

Because DECORATE is a junk, Doom-specific format with no real standard.  I agree it would be fantastic to have a universal thing definition format, but I'd rather have nothing than DECORATE.  I'd rather tear off all my fingers than have DECORATE.  I'd rather eat cold oatmeal out of a bowl made with Fraggle's hair than have DECORATE.  I'd rather cover myself with maple syrup and try and slip through a hoard of pink demons than have DECORATE.

 

17 minutes ago, Graf Zahl said:

Hexen format/ACS: This would be a massive undertaking making it unlikely, but if you say 'no', please tell us why.

 

You're right, one reason is that ACS and Hexen format are big changes.  Implementing ACS touches nearly every part of the engine, and either you get a C++ implementation from ZDoom/Odamex/EE, or you write your own -- hahahahahahaha.  I actually think ACS should be its own standard, which could maybe be referenced by this one, but whatever.  Hexen map format is big because of all the features you need to add to support it; essentially you really mean "Hexen support", not just "Hexen map support".

 

The second reason is that if a port supports neither Hexen map format nor UDMF, it should skip straight to UDMF.

 

The third reason is that ACS (and you know this is coming) sucks and sucks hard.  It's a junk language, befouling the minds of any and all programmers who come into contact with it.  It shorts the circuits; it lubricates the soul grinders; it sharpens the heart stakes.  We may as well add Fragglescript (God Fraggle, I am so sorry) to the standard.

 

27 minutes ago, Graf Zahl said:

ctually, the only port that presents an obstacle here is Eternity, which blissfully had been ignoring all allocations ever since its inception, constantly adding new stuff with low numbers and clashing with the other ports which steered clear of each other - even all those Hexen specials that got added still waste this namespace.

ZDoom, Legacy and E/3DGE do not clash, if they use the same number it is for the same action, with the one exception of 272 which caused a fugly hack in ZDoom to support both.

My personal preference here would actually be to ignore Eternity because it blocks 200 numbers for mostly nothing and would force reallocating all the other ports' common features if brought into a standard.

 

 

I admit ignorance in this area, but I don't care about assigning blame at all.  From what I understand ports interpret some linedefs differently, leading to incompatibility.  This is solved in UDMF I think?  I don't really care.  EE devs can weigh in on how they prefer to handle non-EE-linedef maps, and I think that should be part of the standard: "Complying ports support [agreed upon linedef standard], either natively or via configuration", for example.

13 minutes ago, Ladna said:

No standard should specify programming language.  The very idea is ludicrous.  Standards are supposed to allow for a diversity of implementation, not "everyone use this one piece of code I wrote".  That's not a standard; that's homogeneity and a monopoly.

 

I'm not at all interested in a language war.  I'd have the same problem specifying C, Ruby, Go, JavaScript, Rust, or whatever.  It's simply laughable for a standard to specify programming language.

 

You said 'C++: no'. If it's not supposed to be part of the standard, why even bring it up?

 

 

13 minutes ago, Ladna said:

 

Because DECORATE is a junk, Doom-specific format with no real standard.  I agree it would be fantastic to have a universal thing definition format, but I'd rather have nothing than DECORATE.  I'd rather tear off all my fingers than have DECORATE.  I'd rather eat cold oatmeal out of a bowl made with Fraggle's hair than have DECORATE.  I'd rather cover myself with maple syrup and try and slip through a hoard of pink demons than have DECORATE.

Sorry to be harsh, but that's just stupid. What would you want? Reinvent the wheel again and still not getting anything better out of it?

You are throwing arounf lots of insults but give no reason for that.

 

13 minutes ago, Ladna said:

The third reason is that ACS (and you know this is coming) sucks and sucks hard.  It's a junk language, befouling the minds of any and all programmers who come into contact with it.  It shorts the circuits; it lubricates the soul grinders; it sharpens the heart stakes.  We may as well add Fragglescript (God Fraggle, I am so sorry) to the standard.

Again so much emotion. :D ACS is certainly not the best thing around, but as it stands, if there is a choice for simple map scripting, point me to something better that will be widely accepted and is already available. I doubt you'll find anything.

 

13 minutes ago, Ladna said:

 

 

I admit ignorance in this area, but I don't care about assigning blame at all.  From what I understand ports interpret some linedefs differently, leading to incompatibility.  This is solved in UDMF I think?  I don't really care.  EE devs can weigh in on how they prefer to handle non-EE-linedef maps, and I think that should be part of the standard: "Complying ports support [agreed upon linedef standard], either natively or via configuration", for example.

 

Small incompatibilities always exist, but that's not really relevant. The main problem is that Eternity clashes with everything else in the non-Boom department.

 

 

1 hour ago, Ladna said:

Because DECORATE is a junk, Doom-specific format with no real standard.

So what ISO-certified non-Doom-specific format exists for defining Doom engine actors?

 

If you want to suggest an XML or JSON encapsulation of the info.c state tables, no.

=== C++ ===

 

I'm just trying to vote on the various things getting a little traction in this thread.  I saw C++ in there early on.  If it's not being considered, then just ignore me!

 

=== DECORATE ===

 

DECORATE is bad because I need to write a parser for it, but I absolutely cannot write a parser for it.  It's a non-standard, poorly-specified, ZDoom-centric format.  If anyone disagrees that it's poorly-specified and ZDoom-centric, then answer a few questions:

 

  - What are the input types for the DECORATE expression functions?  What happens if I give them the wrong type?

  - What constitutes an identifier in DECORATE?

  - What encoding are DECORATE lumps in?  ASCII?  UTF-8?  What if I want non-ASCII characters in class names?

  - How are floating point numbers handled?  Are they IEEE-754, or are they string representations later converted to floats by ZDoom's CVar class?  Can I use exponents?

  - How is numeric overflow/underflow defined?

  - No behavior is specified for out-of-range values, like Actor Accuracy, for example

  - How should non-ZDoom ports handle things like stamina or waterlevel?

  - What if (for example) my port has a 'stamina' attribute on `mobj_t`, but I use `uint8_t` for it and use 0-255 for a slightly wider scale?  How should I translate that?

  - If I want to include quotes in my strings, can I backslash escape them?

  - Not everything supports all ZDoom's Actor flags.

 

I could go on for a long, long time.  Maybe the most damning thing of all is that I have to dig through dozens of ZDoom Wiki pages to figure out how DECORATE works.  Saying "put DECORATE in the standard" is essentially saying "make the standard ZDoom".  Plus, DECORATE is a (bad) programming language masquerading as a data description language.  If you just stripped out the evaluation parts and added more sane formatting, well hey it looks like you'd have JSON.

 

=== Not DECORATE ===

 

53 minutes ago, Gez said:

If you want to suggest an XML or JSON encapsulation of the info.c state tables, no.

I am definitely a fan of pre-existing formats, for a couple reasons:

 

- There are libraries to support them

- These libraries come with comprehensive test suites and high usage numbers, making it far less likely you find a fatal, fundamental flaw in the format

- Other non-Doom tools can read them

- I don't have to write a parser

- I don't have to write a shitload of test cases for the parser

- I don't have to convert my port to Graf's language of choice so I can use his parser

 

JSON, YAML, TOML, INI, I don't really care.  Most people will use frontends for this anyway, so JSON is probably the best.  There are bajillions of JSON libraries for pretty much every language.

 

If I were king, I'd say JSON and make the THING definitions essentially what they are in MBF.  It's not the end-all-be-all, but it's obviously better than info.c in MBF, which is what we're trying to evolve right?

 

Here's how this DECORATE example looks in JSON:

 

{
  "def": "actor",
  "inherit_from": "ZombieMan",
  "replace": "ArmorBonus",
  "name": "SuperZombieMan",
  "health": 1000,
  "speed": 16,
  "obituary": "%o was slaughtered by a strangely powerful zombie.",
  "states": {
    "pain": {
      "sprites": [
        {"frame": "E", "count": 10, "code_pointer": "A_FaceTarget"},
        {"frame": "F", "count": 8, "code_pointer": "A_PosAttack"},
        {"frame": "E", "count": 8}
        {"goto": "see"}
      ]
    }
  }
}

It's only 4 lines longer!  And they're like, all brackets or braces, man.

 

=== ACS ===

 

2 hours ago, Graf Zahl said:

ACS is certainly not the best thing around, but as it stands, if there is a choice for simple map scripting, point me to something better that will be widely accepted and is already available. I doubt you'll find anything.

 

"widely accepted", Graf you dog.  You know ACS is only the de-facto standard for Doom scripting because ZDoom questionably hoisted it from Hexen way back when ;).

 

But seriously anything is better.  COAL was better.  SMALL was better.  Fragglescript was better.  QuakeC was better.  Existing embeddable languages like (and this is saying something coming from me) JavaScript, Lua, Squirrel, or AngelScript are better.  Languages that have things like real types, or real data structures, or real namespaces, or real coroutines, or real libraries like interfaces to databases, file formats, canvas drawing libraries, font libraries, are better.  ACS sucks ass.  It sucks so much ass!

I feel like there's some highly unintentional irony about you wanting to avoid C++ ... and then going on about how JSON would be a great format because it has libraries, despite in one of the sister threads JSON was denied as a potential format for UMAPINFO because all the not-cruddy libraries for JSON are in C++.

 

Also, like almost all of those concerns with Decorate are pretty much out the window, anyway, since the actual idea is a "Decorate lite" - aka something based on the Decorate syntax, but with a lot of the flub cut out since, y'know, most of that flub is completely irrelevant to the type of custom actors you'd be making for a Boom+ wad anyway.

 

Also preferably with a standard parser that is unlike ZDoom's, because ZDoom's has the absolutely dreadful bit where it's completely valid to surround anything in quotation marks, which is probably more due to having to deal with backwards compatibility than anything but it'd still be fantastic to remove from something made with a hundred times the foresight.

I don't want to avoid C++ (OK I do, like I want to avoid MRSA and canned spinach), I just think specifying a language in a standard is bananas.

 

There are many JSON libraries for C.  The ones I can think of are: cjson, json-c, and jansson.  If you have glib (and if you have FluidSynth you do) you can also use json-glib.

 

So I fail to see the irony.

 

What's the difference between DECORATE-lite and JSON, besides having no implementations?  Is DECORATE-lite exactly like DECORATE insofar as it's wholly unspecified, existing completely in the minds of its imaginers?

 

---

 

EDIT:  I spent literally 5 seconds googling and found: https://github.com/miloyip/nativejson-benchmark

Goddamn people.

Edited April 30, 2017 by Ladna

Re: linedef type conflicts do any ports use the range above the current boom generic type range ie: >30000?

 

How about between 8000 & 8192?

3 minutes ago, traversd said:

Re: linedef type conflicts do any ports use the range above the current boom generic type range ie: >30000?

 

How about between 8000 & 8192?

Not that I know of. That's one reason I started with trying to fill in the unused bit between 8192 and the first BOOM generalized special at 0x2F80 with my idea for generalized lighting triggers which didn't work out since I forgot the trigger bits. I'd like to give that another try but on the high-end of the range, though I feel maybe there are too many cooks in the kitchen right now, all stirring the same pot with conflicting ideas.

Great, so we can could look to extend one of Boom's current features (a lot of the recent talk has covered additional or reworked features) that shouldn't directly clash with existing ports offering greater than Boom support.

 

yeh it seems easy to slip further down the road feature wise in discussion. Unless I've misunderstood @kb1 this is intended as a fairly small increase in existing Boom/MBF capability.

 

@Quasar could you dot point the lighting options you've got in mind? I think I understand some of the code you posted but concede I'm probably not appreciating it in full :D

This will never happen because of selfishness of the source-ports authors.

14 hours ago, Arctangent said:

Also, like almost all of those concerns with Decorate are pretty much out the window, anyway, since the actual idea is a "Decorate lite" - aka something based on the Decorate syntax, but with a lot of the flub cut out since, y'know, most of that flub is completely irrelevant to the type of custom actors you'd be making for a Boom+ wad anyway.

Pretty much that. Back when the original parser was written, Hexen's sc_man was the only thing available, the better parts only got added when it was too late to change things. Stuff I'd leave out for sure is the entire expression evaluator (seriously, the parser for that is just awful and it's total overkill) and a lot of the added functions. I think getting the initial basics of the 2004 implementation working with a better parser would be all that Boom needs.

But as things stand, people are familiar with the syntax and none of the competing format really are better.

My idea would be to make something that is forward compatible with DECORATE, i.e. all valid syntax is valid DECORATE but certainly not the reverse.

 

About writing a parser,  I think what is needed here first is a generic tokenizer. So is there anyone capable of writing such a thing without some code generator like either Flex or RE2C? These generator tools are something I'd prefer to avoid for this.

 

 

 

People (programmers) are proposing all kinds of features in this thread. Can we focus on small things that would make mappers' lives easier, rather than a grand plan to reinvent DECORATE?

 

On 4/26/2017 at 0:40 PM, esselfortium said:

If an extended Boom feature set is developed, please consider making sane versions of the line scrollers. The ones Boom comes with are truly baffling, and all but useless in most situations.

So there's been some discussion in response to this, which is great. What other things are there that making mapping for Boom annoying? Other mappers too, I'd like to hear from you. Ideally this discussion should be driven by the actual users (ie. mappers) rather than programmers - it's too easy for us to invent a bunch of stuff just because we think it's helpful. We ought to be listening more.

Awhile back I did make a start at writing a tool to turn a DECORATE dialect into Chocolate Doom's info.c.  Might be useful for inspiration here: https://bitbucket.org/Blzut3/declarate/overview

 

It's not complete, but it gets a decent ways in with 1,000 lines of code for parsing and output, and under 1,000 lines for the entire tokenizer which is ripped from ECWolf so has a few unneeded features (like sc_man style unquoted strings).  The input file I was using can be found on the downloads page there.

 

In terms of parser cross compatibility, like with ECWolf there are things that are valid here that would be invalid in ZDoom and vice versa.  But any well written code (i.e. you don't go out of your way to do things wrong) would parse in both.  There's details on that in the markdown file I posted on the downloads page as well.

 

The idea of the project was to demonstrate that DECORATE can be a one to one mapping to vanilla structures.  To that end it's definitely possible to finish it as a tool for building custom games on Chocolate Doom.  But as a way of demonstrating a reference implementation of DECORATE as a candidate for a universal language, when Ran this by Quasar early on and he pointed out one of the key problems with it is that vanilla's model of inventory doesn't really fit the way that DECORATE wants to represent such things.  (I'll let someone more intimately knowledgeable repeat the details.)

16 minutes ago, fraggle said:

People (programmers) are proposing all kinds of features in this thread. Can we focus on small things that would make mappers' lives easier, rather than a grand plan to reinvent DECORATE?

You are correct, of course, but I'd still like to have some very basic actor definition capabilities, because, to be honest, the one thing about Boom mods I find boring these days is that new enemies are utterly predictable in what they can do. Even if all that was added is a new projectile firing function with proper offsetting of the launch position it'd be a huge win.

 

And about only programmers tossing ideas around, yes that is definitely not helping, because much of the proposed stuff is way, way too complex. The scrollers being mentioned would be the #1 thing, here's one question, though: Since the line's special will be taken by the scroller special, this can use the tag for the scroll speed, so it should all be doable with 8 types to handle all cardinal and all diagonal directions. Or am I missing something? Of course the tag needs to be deleted afterward so that this won't be affected by some line-to-line special like some teleporters.

 

@Blzut3:

That thing might be a good starting point for a basic actor definition capability. Concerning inventory items, my guess is that this part has to be off-limits, because the way Doom originally implemented inventory items is just not even remotely extensible. I'd just block off the MF_SPECIAL flag and all weapon code pointers and leave it at that. Anything further would cause problems with at least one port because inventories are implemented differently, for 3DGE, for example I can't even say what it can handle and what not. Better restrict this to stuff that can be handled universally.

33 minutes ago, fraggle said:

People (programmers) are proposing all kinds of features in this thread. Can we focus on small things that would make mappers' lives easier, rather than a grand plan to reinvent DECORATE?

 

So there's been some discussion in response to this, which is great. What other things are there that making mapping for Boom annoying? Other mappers too, I'd like to hear from you. Ideally this discussion should be driven by the actual users (ie. mappers) rather than programmers - it's too easy for us to invent a bunch of stuff just because we think it's helpful. We ought to be listening more.

I think creating new generalized line types is probably a waste -- the basic important ones for most common uses already exist, and adding more would occupy so much of the remaining space available in the spec. For adding other esoteric specials, I'd suggest keeping to just what's reasonably needed, while making sure that mappers who need more versatility can use them in voodoo doll scripts.

 

Actually, now that I think about it, I wonder if any sort of voodoo script helper specials would be sensible, to make more advanced logic easier to create, and what that might actually entail. Counters with math operations and "silent-teleport if counter > X"-type walkovers for jumps? That sort of thing can generally be done already with some other tricks, though, so this idea might be nonsense or overkill, especially if ACS is being considered. Most voodoo doll scripts are admittedly pretty simplistic so I'm not sure how much use this would actually see in practice outside of experimental test wads, haha.

 

edit: What Graf said about new projectile types and such is a great suggestion. That's definitely an area that's been severely limited outside of more advanced ports. Being able to launch any thingtype as a projectile would be good, and even better if custom angles can be set for spread attacks and such.

From a mapper's point of view, the way I see it is this should definitely be focused on a few small and widely wished-for features.

 

More advanced stuff I don't think should be a focus, because if someone chooses to map in Boom it's because they've already rejected using advanced features. They want something that is basically vanilla+.

 

If they want to use advanced features, they'll just target GZDoom.

 

As for which features to target, it's hard for mappers to know what's basic for you coders to implement and what's very hard. For example, using textures on floors and flats on walls is an obvious first choice, but I've no idea how much implementing that would break things. 

8 minutes ago, esselfortium said:

Actually, now that I think about it, I wonder if any sort of voodoo script helper specials would be sensible, to make more advanced logic easier to create, and what that might actually entail. Counters with math operations and "silent-teleport if counter > X"-type walkovers for jumps? That sort of thing can generally be done already with some other tricks, though, so this idea might be nonsense or overkill, especially if ACS is being considered. Most voodoo doll scripts are admittedly pretty simplistic so I'm not sure how much use this would actually see in practice outside of experimental test wads, haha.

I'd rather implement Doom64 macros before doing stuff like that...

Or maybe some very simple, very basic scripting that only allows to do some predefined actions and wait, and nothing else.

14 minutes ago, esselfortium said:

That's definitely an area that's been severely limited outside of more advanced ports. Being able to launch any thingtype as a projectile would be good, and even better if custom angles can be set for spread attacks and such.

There are only two fields available for such a codepointer, unfortunately, and the first one must be reserved for the thing type. What's the other one? Spread angle? Spawning height is probably insignificant compared to it, but I don't know.

 

Some variation can be achieved by implementing more than one codepointer with some adjustments. Seeker missile codepointer seems like an important thing to have.

Just now, Bauul said:

As for which features to target, it's hard for mappers to know what's basic for you coders to implement and what's very hard. For example, using textures on floors and flats on walls is an obvious first choice, but I've no idea how much implementing that would break things. 

The main issue with that is that the more basic ports expect textures to be in the internal format the renderer needs. Once you have a converter that can handle this part it's mostly setting up some rules how to order the textures, all which has already been solved.

 

On the game side this won't have any effect whatsoever, it is entirely a renderer/data management thing.

 

Just now, Da Werecat said:

There are only two fields available for such a codepointer,

 

That isn't a big issue. The first DECORATE had the same problem, it just used the 'misc' fields as an index into a parameter table where each function could store as much data as it wanted (ok, not quite. Back then it had two bytes, meaning 65536 parameters for the entire game, but nothing ever got even close.) And PrBoom has two longs here, that's more than enough to store an index into a table spanning the entire RAM.

 

 

Oh so old DECORATE?  Like:

 

FastBloodyTwich 
{ 
    DoomEdNum 20000 
    Sprite GOR1 
    Frames "1:A*B*C*B*, 10:ABCB" 
    SpawnCeiling 
    Solid 
    NoGravity 
    Radius 16 
    Height 68 
}

projectile FooShot
{
    SpawnNum 255
    Sprite PLSS
    Frames "24:AB"
    DeathSprite PLSE
    DeathFrames "ABCDE"
    Radius 13
    Height 8
    Speed 70
    Damage 1
    NoBlockmap
    NoGravity
    ActivatePCross
    ActivateImpact
    NoTeleport
    SpawnSound "weapons/plasmaf"
    DeathSound "weapons/rocklx"
    ExplosionRadius 1024
    ExplosionDamage 16
    DamageType Ice
    DoNotHurtShooter
}

breakable FooTree
{
    Sprite TRDT
    Frames A
    DeathFrames "BCDEFG"
    GenericIceDeath
    BurnDeathFrames "H*I*J*K*L*M*N*OPQ"
    BurnDeathSound TreeExplode
    BurnHeight 20
    SolidOnBurn
    SolidOnDeath
    DeathHeight 20
    DeathSound BishopDeath
    Solid
    Radius 15
    Height 180
    Health 70
    Mass 700000
    NoBlood
    BurnsAway
}

pickup SuperBlueKey
{
    DoomEdNum 20001
    Sprite BKEY
    Frames "2:AB*"
    PickupMessage "You got that funky key-like thing."
    PickupSound "*xdeath"
}

It feels like something that fits very easily into an INI:

 

[thing.FastBloodyTwitch]
DoomEdNum = 20000
Sprite = GOR1
Frames = 1:A*B*C*B* 10:ABCB
Flags = SpawnCeiling Solid NoGravity
Radius = 16
Height = 68

[projectile.FooShot]
SpawnNum = 255
Sprite = PLSS
Frames = 24:AB
DeathSprite = PLSE
DeathFrames = ABCDE
Radius = 13
Height = 8
Speed = 70
Damage = 1
Flags = NoBlockmap NoGravity ActivatePcross ActivateImpact NoTeleport
        DoNotHurtShooter
SpawnSound = weapons/plasmaf
DeathSound = weapons/rocklx
ExplosionRadius = 1024
ExplosionDamage = 16
DamageType = ice

[breakable.FooTree]
Sprite = TRDT
Frames = A
DeathFrames = BCDEFG
Flags = GenericIceDeath SolidOnBurn SolidOnDeath NoBlood BurnsAway Solid
BurnDeathFrames = H*I*J*K*L*M*N*OPQ
BurnDeathSound = TreeExplode
BurnHeight = 20
DeathHeight = 20
DeathSound = BishopDeath
Radius = 15
Height = 180
Health = 70
Mass = 700000

[pickup.SuperBlueKey]
DoomEdNum = 20001
Sprite = BKEY
Frames = 2:AB*
PickupMessage = You got that funky key-like thing.
PickupSound = *xdeath

 

I don't really know about those `frames` values, but whatever.  I'm OK w/ this.

Edited April 30, 2017 by Ladna : Switched to PascalCase to appease Graf :)

For god's sake, no. What I mean was my initial submission plus Randi's syntactic changes to make it work better.

Also, no to INI. The one thing we do not need is yet another format. And what's with your love for underscores? Most people hate them.

 

16 minutes ago, Graf Zahl said:

What I mean was my initial submission plus Randi's syntactic changes to make it work better.

Where is your initial submission?  I looked through this thread and couldn't find anything.  I seriously have no idea what DECORATE-lite is, and not for lack of asking and looking.

 

17 minutes ago, Graf Zahl said:

The one thing we do not need is yet another format.

 

I completely agree, which is why I'm 100% against creating another hacked together Doom-only format with no independent implementations that other ports will have to support.  You're right insofar as it's not yet another format for ZDoom, but for any other port (except Zandronum and VAVOOM) it is.  The only question is what format will it actually be.  We should be using common file formats with existing, widely-used, tested libraries, not stuff we glom together on forums.

 

You have to look at it from the perspective of someone like EE, Legacy, or PrBoom+.  They don't have DECORATE parsers, and they'll need one if they want to support this standard (if DECORATE ends up being a part of it).  They *could* use ZDoom's (I'm guessing you'd like a format ZDoom already understands), but PrBoom+ can't because it's not C++.

 

Even if they write their own parser, they can only use that code for DECORATE.  So if they want to use a different format for something else, they have to have yet another parser.  Let's say I want a configuration file for something.  Will DECORATE work for that?  Maybe, but it means my DECORATE parser will have to be generalized: it can't be tied to specific property names; it needs to accept anything and have a separate validation step.  And then what have I gained over using something like INI?  I have less functionality, I have a lot of custom, relatively untested code, and nothing outside the Doom world can use my configuration file.

 

In that case, I'd choose INI for my configuration file.  But then I'd have a DECORATE parser AND an INI parser, which is ridiculous.  This is why I'm so against Doom-specific formats like DECORATE.  One of two things ends up happening:

• You have Doom-specific parsers for formats like DECORATE AND widely-used parsers for formats like INI, suffering the effects of code bloat and maintenance overhead

• You shoehorn your needs into Doom-specific formats, you give up a lot of features,  you have a lot of custom, relatively untested code, and no other tools can work with your format

I mean, this is not an unfamiliar story to anyone who's worked with ZDoom derivatives.

 

20 minutes ago, Graf Zahl said:

And what's with your love for underscores? Most people hate them.

I don't want to get into a style preference war but, it's not true that "most people hate them".  Underscored identifiers are the style standard for wildly popular languages like Python, C, PHP, and Ruby, as well as newer languages like Rust, Crystal, Pony, and Julia.  I think they're easier to read than ThisIsAnIdentifier or thisIsAnIdentifier, but I understand not everyone feels that way (ex: Go, Nim, and R use PascalCase or camelCase).  I do agree underscores are somewhat harder to type, but I'm a ridiculously fast typist anyway and I spend 10x more reading code than writing it, so I think the optimization is worth it.  I don't care about it for this format though, I'm just saying personally.

Eternity has a DECORATE state parser, at least. It expects such states to appear in multi-line strings within EDF, and presumably doesn't have full support for the top-level DECORATE syntax... which is fairly close to EDF anyway, so maybe it's not far off.

 

I dislike how Eternity has the EMAPINFO lump totally separate from EDF (whereas ExtraData is clearly using the same parser). I guess it's because of SMMU legacy. And what I'm trying to say here: isn't EMAPINFO precisely INI? Other than supporting // comments, sure.

7 minutes ago, printz said:

And what I'm trying to say here: isn't EMAPINFO precisely INI?

Lol yeah, I looked at it briefly last night (after I discovered INI files don't use quotes) and thought, "Huh, how is that different than INI".

 

INI does comments, most libraries support either '#' or ';'.  So I guess that's a slight difference.

Sigh...

 

This is a totally pointless discussion that is going nowhere. If there's 5 developers with 5 different visions and each one preferring to do their own thing without even trying to build on established formats the MAPPERS know we may just bury the whole thing.

 

The only reason I didn't use EMAPINFO syntax for UMAPINFO was a parsing issue, I would have preferred to use EMAPINFO as a template - maybe I'll do that now with the INI parser.

 

My personal idea is to provide the parsers along with all data formats that get implemented so that other port developers can import the whole thing from top to bottom without having to think about how to do it again. As soon as each port starts implementing their own thing we have lost because a) it's redundant work and b) creates incompatible implementations.

 

And the absolutely last thing I am going to invest work in is to cook up yet another syntax to do stuff that has been solved before, that also goes for the actors. The main thing here is the state parser. Good luck finding a good general purpose library that can do that in a way that is end user friendly. INI is not going to cut it, and looking at EDF, it parses the states as multiline raw strings that then get dissected by a second parser. And EDGE's DDF is simply too verbose and not the most readable format out there to begin with. Which leaves DECORATE as the obvious template to work from. Blzut did the right thing by pointing us to his project which really looks like a great starting point.

 

40 minutes ago, Ladna said:

I don't want to get into a style preference war but, it's not true that "most people hate them".  Underscored identifiers are the style standard for wildly popular languages like Python, C, PHP, and Ruby, as well as newer languages like Rust, Crystal, Pony, and Julia.  I think they're easier to read than ThisIsAnIdentifier or thisIsAnIdentifier, but I understand not everyone feels that way (ex: Go, Nim, and R use PascalCase or camelCase).  I do agree underscores are somewhat harder to type, but I'm a ridiculously fast typist anyway and I spend 10x more reading code than writing it, so I think the optimization is worth it.  I don't care about it for this format though, I'm just saying personally.

 

The thing here is that the target audience of what gets done is not programmers. For non-programmers, treating the underscore as a letter is a strange convention so for external definition formats I try to avoid it if posssible. Sometimes one slips through but that should be the exception, not the rule.

 

17 minutes ago, printz said:

I dislike how Eternity has the EMAPINFO lump totally separate from EDF (whereas ExtraData is clearly using the same parser). I guess it's because of SMMU legacy. And what I'm trying to say here: isn't EMAPINFO precisely INI? Other than supporting // comments, sure.

 

Just to get a different view on the whole thing, my main issue with EDF it is that EDF is doing everything, from actors to sounds to terrain to whatever else.

Take just the sounds for example: EDF's implementation is a lot saner that ZDoom's ugly SNDINFO (one of those crusty - and very broken - legacies from the early years), and I'd really love to have a unified format for all advanced ports. But with EDF being so universal it is impossible to pick parts of it and declare them a unified standard. To get a piece, everything needs to be parsed and that makes the entire notion DOA.

 

My personal vision would be to have sanely defined formats for everything that try to use a somewhat common syntax but still keep then separated by function so that individual replacements can be done on a lump naming basis, not by having one master lump that includes what is needed.

I'd really like to deprecate the old age crap that has accumulated in ZDoom over almost 2 decades, but what point is there if this cannot be used as the chance to define something truly universal and compatible? It wouldn't be worth the effort.

 

 

2 minutes ago, Graf Zahl said:

And the absolutely last thing I am going to invest work in is to cook up yet another syntax to do stuff that has been solved before, that also goes for the actors.

All this is why I said in my initial voting post "there's no consensus on how to do this" when it comes to thing defs.  I think we should never have gone down this rabbit hole, like Fraggle was warning against.

 

I'll reiterate my support for UDMF and the INI version of UMAPINFO.  I went through the thread to try and gather the ideas so far:

• Fixing linedef incompatibility
• Line scroller stuff
• Widen potential projectile types
• Custom projectile angles (heights too?  idk)
• traversd's posts: (here and here)
• Blastfrog's post here

 

There is no consensus for the sole reason that you are opposing it. So far nobody else has said anything negative.

If this thing devolves into a design by committee issue it will go the same route as any previous attempt to do something, i.e. it will die. In the end it's really simple:

 

- make it simple for the mappers by providing a simple to use format.

- make it simple for the programmers by making the parser a drop-in component. Of course each port will have to do some work to connect the dots but if that is only putting the values into the proper fields it is manageable.