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

[Ladna]

Just now, Graf Zahl said:

There is no consensus for the sole reason that you are opposing it.

That's how I knew ;)

 

Just now, Graf Zahl said:

If this thing devolves into a design by committee issue it will go the same route as any previous attempt to do something

That's how standards work, via consensus.  Otherwise they're just decrees.  I'll only back a standard if it's built on widely-used data formats.

 

Just now, Graf Zahl said:

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

What mapper can't use INI?  Even ZDoom uses it for configuration, right?  Isn't there a zdoom.ini?

 

1 minute ago, Graf Zahl said:

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.

Agreed, which is why INI is desirable.  There are multiple INI libraries for all mainstream languages.  It is, BY FAR, more desirable to use one of these libraries than convert your code base to C++ and use ZDoom code, or to write a parser yourself.

 

I honestly don't know what your opposition to an INI thing def format is.  Doesn't ZDoom already read INI files?  If not, why are you asking other ports to write a totally new DECORATE parser (or convert their codebases to C++) when you don't even want to use an INI library?

 

(also maybe we should split this off into a different thread, mods)

[Fonze]

Don't want to derail the discussion, but I wanna get this down while I'm thinking about it: one thing I would really like to see in an expanded Boom format is an increase in general limits; sure ~32.7k linedefs is a lot to work with, but my worms eat lines in the thousands which doesn't leave much "map" to go around them, lol.

 

All the stuff about doing the same things in easier ways seems bunk to me at this point in development; extra functionality strikes me as the way to go.

[Graf Zahl]

That limit has already been lifted and is 65535. But that's a hard limit of the map format, to be more precise the hard limit is 65535 sidedefs which will always be hit before the linedefs - to go beyond that UDMF is a necessity.

 

[Fonze]

I apologize; I'm thinking in terms of linedefs from years of DB2 usage and that number being the more easily accessible number to keep track of. 

 

In terms of sidedefs, yeah ~65k, but that still ain't enough sometimes when one small piece of a puzzle takes up 2k :)

 

But hard-coded is a thing... Still, we are talking of making a new map format here; is it that wedged in that it cannot be changed without borking everything?

[esselfortium]

Adding some new line specials is relatively easy for any sourceport, it doesn't require any change in the actual map format. Supporting more than 65535 sidedefs requires the entire map format to be replaced with a different one, requiring a major operation for any port to implement it, and is way out of scope of this discussion. (Plus, if that was the intent, then just supporting the already-existing UDMF would be by far the most sensible choice rather than creating another competing standard.)

[Fonze]

Understood, thank you.

[Arctangent]

1 hour ago, Ladna said:

What mapper can't use INI?  Even ZDoom uses it for configuration, right?  Isn't there a zdoom.ini?

You are massively overestimating how much .ini tweaking one has to do when there's a proper menu with the only missing options being the ones only relevant for start-up, like autoloading certain files.

 

I wouldn't even be surprised if a significant chunk of ZDoom users don't know that their .ini file for it exists, since it's pretty irrelevant for most users.

[Gez]

7 hours ago, Graf Zahl said:

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.

There's a tokenizer in SLADE 3, it doesn't use a code generator.

https://github.com/sirjuddington/SLADE/tree/master/src/Utility

[BigDickBzzrak]

22 hours ago, traversd said:

How about between 8000 & 8192?

Risen3D uses those, sorry. (edit: not all though)

 

Another little feature request if it's doable: having teleporters that preserve Z-height, like that buggy Final Doom executable. I could do so much...

Edited April 30, 2017 by bzzrak

[Graf Zahl]

46 minutes ago, Gez said:

There's a tokenizer in SLADE 3, it doesn't use a code generator.

https://github.com/sirjuddington/SLADE/tree/master/src/Utility

C++ again. I bet some people won't like where this is going to head.  :D

Like I said before, in order to borrow code from other projects it is a foolhardy proposition to keep the code base plain C and compilable with ancient compilers.

[Gez]

As long as there are a few extern "C" wrappers there's no problem with putting some C++ module in an otherwise plain C project.

[Ladna]

4 hours ago, Arctangent said:

You are massively overestimating how much .ini tweaking one has to do when there's a proper menu with the only missing options being the ones only relevant for start-up, like autoloading certain files.

 

I wouldn't even be surprised if a significant chunk of ZDoom users don't know that their .ini file for it exists, since it's pretty irrelevant for most users.

You're probably right, but "there will be a frontend" is an argument for a non-human-readable format, and Graf (and you, I think?) are arguing for a format you think is more human-readable.  If your argument is "no one will ever manually edit this", then that's a whole different discussion.  INI files are crazy simple.  There are no special rules.  Everyone's seen one.  Let's stop pretending old DECORATE is this nice, comfortable format everyone likes and is perfectly easy to deal with.  INI is obviously just as simple, more powerful, and better in basically every way.

 

Plus, the point is that ZDoom can already read INI files, so I don't know what Graf's opposition is.  Still waiting on that one.

 

=== Tokenizer stuff ===

 

Tokenizing is easy, it's just a matter of what you think identifiers, keywords, symbols, numbers, and strings are.  In C, at least GLib contains a tokenizer, and its defaults are pretty much what every programming language uses (identifiers are alphanumeric + '_' and start with a letter, etc.).  There are probably other libraries and such for it too, but again it's pretty easy.  In fact, writing tokenizers, lexers, and parsers in general is pretty easy; it's a little boring and subtle bugs can creep in, but hey welcome to programming.

 

I just don't know why I would do any of that for a custom, Doom-specific format, when it will have fewer features, have fewer tests, have a higher maintenance burden, have more bugs, and will force me to give up interoperability with other tools.

 

To put it another way, look at this hilariously soul-crushing (and almost certainly incomplete) list of formats I need to support in D2K in order to support ZDoom mods:

 

• Distinct formats:
  • ACS
    • More than a format obviously, but hey, it still needs parsing
  • ALTHUDCF
  • ANIMDEFS
  • CVARINFO
  • New DECORATE
  • DEFBINDS
  • GAMEINFO
  • KEYCONF
  • LANGUAGE
    • A tweaked INI format
  • LOADACS
    • I think this is just a newline-separated list of ACS library names
  • MENUDEF
    • Kinda like old DECORATE, except it allows quoted 2nd block names like `OptionValue "CHUD_HUDColors"` and commas to separate name/value pairs, but IfGame/IfOption/Else is really different from old DECORATE
  • PALVERS
    • Easy, but still
  • REVERBS
    • Again kinda like old DECORATE but `"Castle Alcove" 30 0 { ... }` is different from `projectile blah { ... }`
  • SKIN
    • INI-like, but no sections
  • SECRETS
  • SNDINFO
    • ZDoom's version is a lot different than the simple version in Hexen/EE
  • SNDSEQ
  • TEXTCOLO
  • TEXTURES
  • TRNSLATE
  • VOXELDEF
  • XHAIRS
  • X11R6RGB
    • Maybe a pass on this one since it isn't Doom-specific
  • Intermission scripts
  • Map arrow
  • Map translator
• Old DECORATE:
  • DECALDEF
  • FONTDEFS
  • LOCKDEFS
    • Maybe?  `Any { RedCard RedSkull KeyGreen }` doesn't look like old DECORATE
  • MODELDEF
  • SBARINFO
    • Maybe?
  • TEAMINFO
  • TERRAIN

A quick count says that's roughly 5,847 goddamn formats.  All of these (except ACS) can easily be captured in JSON and INI, and most would be better for it.  I legit never want to hear anyone from ZDoom-land accuse me of being obsessed with adding more formats.  It's like Usain Bolt telling you to slow down.  It's like Bernie Sanders telling you to comb your hair.  It's like Donald Trump telling you to cool it on the spray tan and racism.

 

3 hours ago, Graf Zahl said:

Like I said before, in order to borrow code from other projects it is a foolhardy proposition to keep the code base plain C and compilable with ancient compilers.

 

I desperately wish this thread could be less OT.  Let's focus maybe.

Edited May 1, 2017 by Ladna : Clarify a little

[Arctangent]

1 hour ago, Ladna said:

I legit never want to hear anyone from ZDoom-land accuse me of being obsessed with adding more formats.

I feel like you've never read xkcd.

[Ladna]

Man, is this gonna be the "we'll make a new format, now there's 1 more format" comic?

 

INI already exists.  It predates DECORATE, by I don't know, 500 years.  I'm pretty sure the 10 commandments were in INI format.  Look inward, and you might realize that comic applies a lot more to ZDoom than to someone like me, who's advocating the use of pre-existing standards over new standards.

[Graf Zahl]

INI format does not exist for parsing actors. It's be defining a new 'standard' for defining actors and would require that mappers have to learn yet another method.

 

Let's just give them something they already know, ok? It's not like we want to add a multitude of new formats to a basic port.

My ideal solution would be: EMAPINFO compatible for map definitions and DECORATE compatible for actor definitions.

 

And please don't start about ZDoom's incoherent mess of file formats. Most of that comes from a time where awareness did not exist and neither did a decent parser. I'd do it differently today.

 

[Ladna]

4 hours ago, Graf Zahl said:

INI format does not exist for parsing actors. It's be defining a new 'standard' for defining actors and would require that mappers have to learn yet another method.

There is nothing to learn.  Look at my conversion above.  A child could do this.

 

4 hours ago, Graf Zahl said:

Let's just give them something they already know, ok?

INI format is ubiquitous, and there is nothing to learn.

 

4 hours ago, Graf Zahl said:

It's not like we want to add a multitude of new formats to a basic port.

Your arguments so far have been, "INI is bad because there aren't quotes in the values", "JSON is bad because there are too many quotes", and "we should only consider formats already in use for the specific use" (i.e. DECORATE for thing defs).  Based on these, I have no faith we won't have this discussion again when it comes to any other data format.

 

4 hours ago, Graf Zahl said:

And please don't start about ZDoom's incoherent mess of file formats. Most of that comes from a time where awareness did not exist and neither did a decent parser. I'd do it differently today.

Hey look, it's today.

 

I will never, in any way, support a standard based on formats that are Doom-specific.  I've been pretty clear about this, and I've laid out probably a dozen reasons why.  The only argument I've heard is, "we already use(d) this format in the past", which is a bad argument for essentially anything.  We used to dig holes outside, build shacks over them, and call them bathrooms.  If we were in charge of that, I'd be saying, "Graf, look at this toilet.  Look how amazing it is.  Look how it works INSIDE and how you literally just push this ONE THING and it cleans itself.  Everyone everywhere else has been using them since before we even existed, and they're 100000000x better.  They'll visit us!", and you'd be saying, "Ladna, we've been shitting in holes for thousands of years.  Let's just give the people what they know.  Why do you have to be such a jerk?  I don't care one bit if anyone visits us ever."

 

I care.  I'm tired of Doom being mired in crap-tech built by kids.  I want it to be easier to play Doom and to work with Doom with tools I never even thought of, like a JavaScript map builder or a Clojure deathmatch bot.  I think it's horseshit that like, maybe 300 people tops have played BTSX or Sunder.  We're professional engineers.  We know this situation is dumb.  Why are you at all considering codifying all this technical debt into a standard?

[Arctangent]

Y'know, I can't help but feel like you're blaming the moon for the night being dark, all while trying to make it sound like astrophysicists are in 100% agreement with your assessment when it's blatantly obvious that they're not.

[Gez]

9 hours ago, Ladna said:

Man, is this gonna be the "we'll make a new format, now there's 1 more format" comic?

 

INI already exists.  It predates DECORATE, by I don't know, 500 years.  I'm pretty sure the 10 commandments were in INI format.  Look inward, and you might realize that comic applies a lot more to ZDoom than to someone like me, who's advocating the use of pre-existing standards over new standards.

The big issue with INI for actor definition is the state definitions.

 

Something like this is very simple in DECORATE:

    See:
        TROO AABBCCDD 3 A_Chase
        Loop

 

But if you want the INI version, you'll get:

 

[DoomImp]
SeeState = S_TROO_RUN1

[S_TROO_RUN1]
Sprite = TROO
Duration = 3
Frame = A
Codepointer = A_Chase
NextState = S_TROO_RUN2

[S_TROO_RUN2]
Sprite = TROO
Duration = 3
Frame = A
Codepointer = A_Chase
NextState = S_TROO_RUN3

[S_TROO_RUN3]
Sprite = TROO
Duration = 3
Frame = B
Codepointer = A_Chase
NextState = S_TROO_RUN4

[S_TROO_RUN4]
Sprite = TROO
Duration = 3
Frame = B
Codepointer = A_Chase
NextState = S_TROO_RUN5

[S_TROO_RUN5]
Sprite = TROO
Duration = 3
Frame = C
Codepointer = A_Chase
NextState = S_TROO_RUN6

[S_TROO_RUN6]
Sprite = TROO
Duration = 3
Frame = C
Codepointer = A_Chase
NextState = S_TROO_RUN7

[S_TROO_RUN7]
Sprite = TROO
Duration = 3
Frame = D
Codepointer = A_Chase
NextState = S_TROO_RUN8

[S_TROO_RUN8]
Sprite = TROO
Duration = 3
Frame = D
Codepointer = A_Chase
NextState = S_TROO_RUN1

Is the one that's like 99% boilerplate better than the one that's been tailormade to reduce verbosity?

[Ladna]

Is that DECORATE lite?  I thought it was basically `type name { pairs }`.  Which is why I keep asking what DECORATE lite is.

 

Either way, you wouldn't need to break it all out like that, so your example is kind of a strawman.  But if that is DECORATE lite then I'm definitely against it.  It looks way, way too specific.

 

I'm on my phone so I can't give a good counter example.  But it's straightforward, even if it means having a special string format for "frames" value.

[esselfortium]

Please just use EDF or DECORATE, they're sensible and actually written for humans

[Altazimuth]

I'd chip in my two cents on DECORATE-lite and EMAPINFO and whatever, but honestly I think that fretting about this now is overcomplicating everything. If we keep on stressing over large sweeping changes at first then this whole idea will come apart due to conflict between the various source-port devs (if they're not chased off by the conflict before that). I think it would be a better idea to try and come to a compromise about the big features for the future whilst focusing on the small features for the now. I'm in total agreement with fraggle's post on page 4:

 

22 hours ago, fraggle said:

So there's been some discussion in response to this [BOOM's line scrollers], 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.

 

Before we pimp our car to a level that would make Xzibit blush we should take it to the mechanic and fix anything that isn't working as well as it should. Let's get a discussion going about the small things in BOOM/MBF that are problematic and try to fix them, before making big sweeping changes.

[Graf Zahl]

Sorry, Ladna, but this is truly ridiculous. INI is a simple 'key = value' format, so it is fine for simple stuff like a MAPINFO where you assign values to properties.

Defining new actors is only partially covered by that, the states, as has been mentioned need some heavy abstraction to make them manageable by mere Humans without tearing one's hair out.

 

@Altazimuth Agreed. This kind of discussion is really helping nobody, but what can we do if it gets brought back constantly? It's certainly not motivating if one person tries to push their agenda through without listening to even the people who have to use this stuff later. This is also not really on my list of immediate priorities, but if some options present themselves, like Blzut3's tool, I'd prefer to hear what people think about it.

 

By now I think the only chance for some objective evaluation is to take the code, try it out and write an opinion about it.

[esselfortium]

It might be sanest to start by implementing a simple agreed-upon standard for extending line/sector/etc types, and then consider map and thing definitions afterwards, just because they're harder to reach an agreement on and can easily run the whole conversation into the ground. Having some things that are easier to agree on get done first is better for mappers, instead of trying to work out every possible expansion of the crossport standard simultaneously and hoping that the whole thing doesn't crash and burn.

[Gez]

Defining actor properties is very simple and just about any format can do.

 

This:

ACTOR DoomImp
{
	Health 60
	Radius 20
	Height 56
	Mass 100
	Speed 8
	PainChance 200
}

Is not different from this:

[DoomImp]
Health = 60
Radius = 20
Height = 56
Mass = 100
Speed = 8
PainChance = 200

Is not different from this:

<class name="DoomImp">
  <Health>60</Health>
  <Radius>20</Radius>
  <Height>56</Height>
  <Mass>100</Mass>
  <Speed>8</Speed>
  <PainChance>200</PainChance>
</class>

 

No, the biggie is the state syntax.

 

I'm not teaching you anything: a state has a sprite, a frame (might include a flag for full brightness), a duration, a codepointer (might be null), a pointer to the next state, and two offset values (unused in Doom, hacked as parameter for the codepointer in MBF). DECORATE gives an implicit way of declaring most of that stuff to reduce as much as possible the boilerplate. But it's there and it has to be handled.

 

So I've already posted the DECORATE format of the imp's See state sequence (or run states as they're called in the original source). Let's look at how other formats did it!

 

DOSDoom DDF (current 3DGE version):

STATES(CHASE)=TROO:A:3:NORMAL:CHASE,
              TROO:A:3:NORMAL:CHASE,
              TROO:B:3:NORMAL:CHASE,
              TROO:B:3:NORMAL:CHASE,
              TROO:C:3:NORMAL:CHASE,
              TROO:C:3:NORMAL:CHASE,
              TROO:D:3:NORMAL:CHASE,
              TROO:D:3:NORMAL:CHASE;

Eternity EDF (before adoption of DECORATE state syntax):

frame S_TROO_RUN1 { cmp = "TROO| *|*| 3|Chase |@next"; dehackednum = 444 }
frame S_TROO_RUN2 { cmp = "TROO| *|*| 3|Chase |@next"; dehackednum = 445 }
frame S_TROO_RUN3 { cmp = "TROO| 1|*| 3|Chase |@next"; dehackednum = 446 }
frame S_TROO_RUN4 { cmp = "TROO| 1|*| 3|Chase |@next"; dehackednum = 447 }
frame S_TROO_RUN5 { cmp = "TROO| 2|*| 3|Chase |@next"; dehackednum = 448 }
frame S_TROO_RUN6 { cmp = "TROO| 2|*| 3|Chase |@next"; dehackednum = 449 }
frame S_TROO_RUN7 { cmp = "TROO| 3|*| 3|Chase |@next"; dehackednum = 450 }
frame S_TROO_RUN8 { cmp = "TROO| 3|*| 3|Chase |S_TROO_RUN1"; dehackednum = 451 }

Doomsday DED:

State {
  ID = "TROO_RUN1";
  Sprite = "TROO";
  Frame = 0;
  Tics = 3;
  Action = "A_Chase";
  Next state = "TROO_RUN2";
}

State {
  ID = "TROO_RUN2";
  Sprite = "TROO";
  Frame = 0;
  Tics = 3;
  Action = "A_Chase";
  Next state = "TROO_RUN3";
}

State {
  ID = "TROO_RUN3";
  Sprite = "TROO";
  Frame = 1;
  Tics = 3;
  Action = "A_Chase";
  Next state = "TROO_RUN4";
}

State {
  ID = "TROO_RUN4";
  Sprite = "TROO";
  Frame = 1;
  Tics = 3;
  Action = "A_Chase";
  Next state = "TROO_RUN5";
}

State {
  ID = "TROO_RUN5";
  Sprite = "TROO";
  Frame = 2;
  Tics = 3;
  Action = "A_Chase";
  Next state = "TROO_RUN6";
}

State {
  ID = "TROO_RUN6";
  Sprite = "TROO";
  Frame = 2;
  Tics = 3;
  Action = "A_Chase";
  Next state = "TROO_RUN7";
}

State {
  ID = "TROO_RUN7";
  Sprite = "TROO";
  Frame = 3;
  Tics = 3;
  Action = "A_Chase";
  Next state = "TROO_RUN8";
}

State {
  ID = "TROO_RUN8";
  Sprite = "TROO";
  Frame = 3;
  Tics = 3;
  Action = "A_Chase";
  Next state = "TROO_RUN1";
}

Bonus: the multigen code:

S_TROO_RUN1	TROO	A	3	A_Chase	S_TROO_RUN2
S_TROO_RUN2	TROO	A	3	A_Chase	S_TROO_RUN3
S_TROO_RUN3	TROO	B	3	A_Chase	S_TROO_RUN4
S_TROO_RUN4	TROO	B	3	A_Chase	S_TROO_RUN5
S_TROO_RUN5	TROO	C	3	A_Chase	S_TROO_RUN6
S_TROO_RUN6	TROO	C	3	A_Chase	S_TROO_RUN7
S_TROO_RUN7	TROO	D	3	A_Chase	S_TROO_RUN8
S_TROO_RUN8	TROO	D	3	A_Chase	S_TROO_RUN1

 

So no, my example isn't a strawman.

 

Heck, I can even mention how SRB2 does it even if they're not going to have a definition of the Doom Imp I can copy-paste. Suffice to say, it wouldn't be sensibly different; it's still something where each state is defined in its own block or subblock. DECORATE is the only format which abstracts that away into implicit definition in a way that is both very compact and very human-friendly. There's a reason why Quasar adopted DECORATE state syntax in EDF, and it wasn't to read ZDoom files (since it's just the state syntax that's adopted, and it still has to wrapped in an EDF definition). You keep going on about using standard libraries to parse standard formats, but that's because you have a program-centric approach. All these standard formats are handy for when you have your text files both written and read by programs. Content definition is going to be written by humans (unless you figure the next fad is going to be procedural actor generation) so it needs to be a format that's as human-friendly as possible. Copy-pasting and then modifying a lot of nearly-identical stuff isn't human-friendly: it's how you can make sure the maximize the risk of error or oversight.

[Graf Zahl]

And let me state: What you posted there was exactly the state of things when the initial DECORATE got developed, that was around 2003. The only one of the listed formats that was somewhat acceptable was DDF, the rest was, pardon the harsh words, utter crap - totally unusable for more complex stuff.

Why not DDF then? Because it still focussed too much on easy parsing than easy writing, even though it eliminated the biggest issue in there, which is the explicit state link required by all other formats (even the '@next' in EDF was too much.)

 

The bottom line is, they all were written as a 1:1 representation of the underlying data, screw that the underlying data can be deduced to a very large degree by inferring the values from the given information. And they all were tedious to the extreme by their verbosity and/or very human-unfriendly syntax. Considering that they all existed when DECORATE came to be, I think it is very telling that DDF was the only one that actually got used for real-life actor definitions in larger quantities.

 

 

 

[kb1]

On 4/29/2017 at 4:43 PM, 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.

 

 

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.

 

 

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.

 

 

 

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.

Then pour syrup and cold oatmeal all over yourself. First you come in and SPECIFY" "No", "No", and "No". Then you claim that this and that suck, without technical reasons. Finally, no one has specified languages that your port may or may not use. However, if you want to be able to add the source code others have built, without having to rewrite it yourself, then, yeah, it's going to be in whatever language it has been written in.

 

Sorry about the attitude, but look at what you did: You basically just went down the list, and poo pooed every line item. What we are trying to do is massive, it's difficult, and it's going to require some give and take from everyone involved. But the reward for success is just as massive. I need cooperation, or constructive criticism, not "this sucks, that sucks". WTF? I need your help here.

 

Look, these are all just ideas right now. No one is trying to box anyone in. As far as DECORATE goes, it is supported in 2 families of source ports right now, it is compact (you can define multiple frames on one line, in some cases), and it's shit-easy to parse. Don't want to write the parser? That's ok, someone will write it for you. By the time we have solidified the standards, we will have parsers and support modules for ALL of these standards. And, yes, DECORATE is widely used, and can handle all the needs of thing/frame def. ZDoom has proven that DECORATE can handle anything thrown at it. But, that doesn't mean that the decision is made. But, it's awfully compelling, and it excludes no port.

 

Yeah, it's different. Hell, KBDoom already has a thing/frame/mapinfo parser, so implementing DECORATE is extra work for me. But, I am considering taking the sacrifice, because it's ridiculous for each port to do it differently. We're all doing the same thing - why are we doing it differently?

 

When Boom released its source, what did every port dev do? They imported genlin.c and ran with it, they didn't rewrite it from scratch. That's the idea with this new standard as well. We'll collaborate on writing it, and then everyone should be able to drop it in, hook to it, and then call it, and, with some tweaking, your port now supports the new standard. That's the goal. Same with UMAPINFO, same with a potential DECORATE, or whatever.

 

The goals: Easy to implement in a port, easy to use, works everywhere, respects port-specific features.

 

I am completely open to discussion, and I will be the first to admit I am wrong. But arguing that red is better than blue, without proof, is not productive - it's just arguing, and I won't participate.

 

Edited May 1, 2017 by kb1

[kb1]

On 4/29/2017 at 8:41 PM, Quasar said:

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.

It's just ideas now, Quasar. Please do work on your lighting triggers. We'll work out the conflicts too. So far, they're not that bad. My goal is to provide some manner for all port changes to have a way to live within the new standard.

 

On 4/30/2017 at 11:49 AM, 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.

You're right, Fraggle. Thing/frame def is down the road. I did ask for everyone to contribute ideas, though, so I can't complain.

 

On 4/30/2017 at 11:59 AM, Blzut3 said:

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.)

Thanks, Blzut3 this will be helpful - you've done a bunch of the work already! With some help from Graf and ZDoom, this can be the basis for an exacting specification. Good stuff!

 

EDIT: By the way, FraggleScript was a pretty bad-ass language that doesn't get enough credit. Sure, it has some bugs, and was not complete, but that basically describes most things. Language parsing and executing is hard. FraggleScript took a nice stab at the problem. A lot can be learned from it.

Edited May 1, 2017 by kb1

[Arctangent]

If there's one thing that I can say foul about Decorate after all that, it's the fact that it ties states to actors, which is quite a bit of a jump from how Dehacked, the current universal standard for this kind of thing, works.

 

Of course, that's probably completely irrelevant for most people when just recreating the states among several actors is a mere copy-and-paste job, and something like keeping inheritance will remove a lot of the typical use cases for keeping states disconnected from actors. Not to mention, being able to create an entirely new actor and define their states right away seems a lot more newbie friendly than defining the states separately and having the actor definition be given identifiers to the relevant parts of the resulting state table. I can only see this being really considered if people can actually bring up a good reason to keep states and actors disconnected.

[Ladna]

Hey I'm back from work.  Thanks Gez, I didn't realize before we were doing things AND states.  Fortunately, with the power of INI, this is wildly easy: 

[DoomImp]
DoomEdNum = 3001
DeHackEdNum = 12
SpawnHealth = 60
PainChance = 200
Speed = 8
Height = 56
Flags = Solid Shootable CountKill FootClip SpacMonster PassMobj
Sound.See = bgsit1
Sound.Pain = popain
Sound.Death = bgdth1
Sound.Active = bgact
Obituary.Normal = was flamed by an imp
Obituary.Melee = was torn apart by an imp
State.Spawn = TROO AB 10 A_Look
              Loop
State.See = TROO AABBCCDD 3 A_Chase
            Loop
State.Missile = TROO EF 8 A_FaceTarget
                TROO G  6 A_TroopAttack
                Goto See
State.Pain = TROO H 2
             TROO H 2 A_Pain
             Goto See
State.Death = TROO I  8
              TROO J  8 A_Scream
              TROO K  6
              TROO L  6 A_Fall
              TROO M -1
              Stop
State.XDeath = TROO N    5
               TROO O    5 A_XScream
               TROO P    5
               TROO Q    5 A_Fall
               TROO RST  5
               TROO U   -1
               Stop
State.Raise = TROO ML  8
              TROO KJI 6
              Goto See

Specifying "sprite" "frames" "rate" "bright" and "codepointer" for every state, as in having keys for them, does suck, so I think DECORATE-in-INI is great for this.

 

8 hours ago, Gez said:

So no, my example isn't a strawman.

Just sort of for your own edification (and I recognize how condescending this comes across, but bear with me), a strawman is when you argue against something your opponent didn't say, bonus points if it's easily ridiculed.  It's so you can say things like, "Ladna believes in Marxism, but let's hear him defend Soviet Russia!" or "Ladna is in favor of organ donation, let's hear him defend organ harvesting!".  I never advocated for such a drawn-out, obviously ridiculously verbose version of the states.  It's also, for what it's worth, a polemic and not a great way of achieving consensus.

 

8 hours ago, Graf Zahl said:

It's certainly not motivating if one person tries to push their agenda through without listening to even the people who have to use this stuff later.

I'm, maybe obviously, not the only one who has an agenda.  This is a discussion about a proposed standard, and I'm saying what I do and don't support and why.  Pretty well I'd say!  And I am listening to people who have to use this stuff later.  Hey look, DECORATE-in-INI just after essel said something.

 

8 hours ago, Gez said:

You keep going on about using standard libraries to parse standard formats, but that's because you have a program-centric approach.

If that were my only concern I'd use a binary format.  I do want them to be readable with minimal effort across a host of technologies, but I also get that a lot of will be done manually.  Fortunately INI files are crazy easy to edit and understand.

 

1 hour ago, kb1 said:

First you come in and SPECIFY" "No", "No", and "No". Then you claim that this and that suck, without technical reasons. Finally, no one has specified languages that your port may or may not use. However, if you want to be able to add the source code others have built, without having to rewrite it yourself, then, yeah, it's going to be in whatever language it has been written in.

Whoa!  I said "Yes" TWICE!

 

ACS and DECORATE do suck, and Graf has admitted as such.  I don't personally even like DECORATE-lite, because there's no reason for it not to be an INI file, but I've been pretty in-depth about my reasons, both technical and otherwise, for it.

 

Graf has specifically given me shit about C vs. C++ multiple times, and while I enjoy a good ribbing (and endeavored admirably to stay on-topic), I worry that the standard will end up with a bunch of C++ libraries like, "here, just (convert your port to C++) and use this".  Shit, his solution to pretty much all the stuff is, "just (convert your port to C++ and) take support from GZDoom".  No thanks.  That's not a standard.

 

My preference is to not write code.  I want libraries for my language that have been used by thousands of people, thoroughly tested by the developers, and have multiple uses.  I don't want libraries that are:

• not for my language
• pretty much untested
• used by Doomworlders only
• usable for nothing else

Furthermore, I've tried multiple times to shelve the thing def discussion, even going so far as to collect the ideas from the thread so far.  But this is evidently what Graf and Gez want to talk about.  That's cool, but don't put it on me :)

 

2 hours ago, kb1 said:

Yeah, it's different. Hell, KBDoom already has a thing/frame/mapinfo parser, so implementing DECORATE is extra work for me. But, I am considering taking the sacrifice, because it's ridiculous for each port to do it differently. We're all doing the same thing - why are we doing it differently?

I don't really know if it's ridiculous for each port to do it differently.  For example, I'm probably gonna have a Lua API to create things, and odds are I'll probably end up using that API at startup to create the things.  Lua's good at being "declarative", so (totally making this up out of nothing):

 

Thing('DoomImp', {
    DoomEdNum = 3001,
    DeHackEdNum = 12,
    SpawnHealth = 60,
    PainChance = 200,
    Speed = 8,
    Height = 56,
    Flags = {Solid, Shootable, CountKill, FootClip, SpacMonster, PassMobj},
    Sounds = {
        See = bgsit1,
        Pain = popain,
        Death = bgdth1,
        Active = bgact
    },
    Obituaries = {
        Normal = 'was flamed by an imp',
        Melee = 'was torn apart by an imp'
    },
    States = {
        Spawn = {
            {TROO, 'AB', 10, Look},
            Loop
        }
        See = {
            {TROO, 'AABBCCDD', 3, Chase},
            Loop
        }
        Missile = {
            {TROO, 'EF', 8, FaceTarget},
            {TROO, 'G',  6, TroopAttack},
            Goto('See')
        }
        Pain = {
            {TROO, 'H', 2},
            {TROO, 'H', 2, Pain},
            Goto('See')
        }
        Death = {
            {TROO, 'I',  8},
            {TROO, 'J',  8, Scream},
            {TROO, 'K',  6,},
            {TROO, 'L',  6, Fall},
            {TROO, 'M', -1},
            Stop
        }
        XDeath = {
            {TROO, 'N',    5},
            {TROO, 'O',    5, XScream},
            {TROO, 'P',    5},
            {TROO, 'Q',    5, Fall},
            {TROO, 'RST',  5},
            {TROO, 'U',   -1},
            Stop
        }
        Raise = {
            {TROO, 'ML',  8},
            {TROO, 'KJI', 6},
            Goto('See')
        }
})

But that's just the base format.  Because it's a programming language, you can build stuff like inheritance on top of it.  You can save your states into a variable and reuse them instead of typing them all out all the time (like SASS is for CSS).  You can change this stuff at runtime.

 

Anyway, I wouldn't at all ever expect any other port to do something like this.  It would be an extra thing my port did.  I'm fine with there being some sort of standard like DECORATE-in-INI that does some basic stuff.  I don't really know how I feel about defining states along with things, mostly because that state syntax locks you into a lot when it comes to thing definitions and capabilities, but whatever.  It's progress.

 

2 hours ago, kb1 said:

The goals: Easy to implement in a port, easy to use, works everywhere, respects port-specific features.

No offense, but those are your goals.  My goal is to avoid having the community foist a bunch of garbage onto me and wall Doom off from the outside world in an oblivion of not-invented-here hell.

 

P.S. I'm also into FraggleScript.  I mean, I wouldn't use it, but just like there's chocolate pudding, canned spinach and barf, there's Lua, FraggleScript, and ACS ;)

[Gez]

9 minutes ago, Ladna said:

Hey I'm back from work.  Thanks Gez, I didn't realize before we were doing things AND states.  Fortunately, with the power of INI, this is wildly easy: 

 

<snip>

 

Specifying "sprite" "frames" "rate" "bright" and "codepointer" for every state, as in having keys for them, does suck, so I think DECORATE-in-INI is great for this.

And what you're doing here is exactly what you call it: DECORATE-in-INI, as in, you've got to add a DECORATE parser to process the ini keys. Which means that the whole thing about not having a DECORATE parser because that's some non-standard NIH shit that hasn't been tested by millions of people kind of goes by the wayside...