Proposing a new State table standard for DeHacked

However it is implemented - whether via an expansion to what is available with DeHackEd or with a new means of defining actors as suggested by Graf Zahl - a crossport feature set that allows greater flexibility than DeHackEd is a dream feature for me. Pretty much the holy grail. There's nothing I'd rather see.

Additionally, there would need to be a way to define new sounds and sprites.

(how do my replies get so big??)

Quasar said:

...number range limitations of Eternity...

Maybe some dynamic renumbering could get things to fit within your user-defined range on load?

Blzut3 said:

...a DECORATE to info.c converter...

Neat! This might become useful for me as well.

exl said:

If this proposed standard takes off, I would be happy to add support for it to WhackEd 4.

That's great news - thank you!

Gez said:

You might want to look at Fusion. :)

Wow, I always wondered what, if anything, made Fusion stand out as unique, and I think you may have found it. The "dehackin.txt" file describes 400 new code pointers...wow. Honestly, I don't know if we should just adopt all of those. Maybe, but some research is needed.

I honestly don't know how big this thing should get. I don't think anyone would object to the number of new code pointers, per se, but we do need to define what should be allowed. More on that below.

Gez said:

ComplEment: something that completes
ComplIment: something that flatters

Wow, I never realized that, and I think I use both of them randomly, though one could argue that they could be forcibly shoved into the same slot :)

Xaser said:

Hot dog! I love the uber-hell out of this idea, and I'll see if I can file through some mods of mine and come up with some sane action pointer suggestions.

Awesome!

Xaser said:

I realize this would be a side-suggestion to supplement what's being suggested here, but I wonder if a similar thing could be done for weapon slots and thing numbers (for adding entirely new things in addition to making major mods to existing stuff). The former's perhaps pipe-dreaming, but the latter (adding a bunch of "blank" things with some reserved doomednums) might be worth considering.

I'd love to include new weapon support, but I have to agree with esselfortium: Weapons are totally different, and there's NO standards for how ports handle them. Even if all ports did weapons the same way, it would involve more than just pasting new Action functions into a source port. With weapons, you're entering the realm where a port needs to provide it's own type of scripting capabilities, whereas this proposal is trying it's best to be Paste, Compile, Play, so to speak.

But the weapon's state table entries could certainly be discussed. I think I read one of Quasar's logs that talked about "thunking" player weapon actions to allow them to be used by monsters (or vice-versa). I think maybe that should be included in the spec, since it's basically just some more code pointers, if I'm not mistaken.

Graf Zahl said:

I don't know. This sounds like the entirely wrong approach to save this dilemma.
Dehacked is a crutch. It should remain so. And since all the ports this might be meant for already define their own means of defining new actors it might be better to define a simple surrogate format that can piggyback on the existing implementations.

It'd be a major win for mappers who want to do new stuff in a cross-port way. Extending Dehacked would just mean extending something utterly miserable.

Graf, you are absolutely right. Dehacked used to be really be a huge hack (exe hack, no less). Also, a simple, cross-port solution would be a major win.

I would like for you to be involved and aligned with the idea. Please keep an open mind, while I try to point out why I like the idea:

1. This proposal describes a simple, drop-in addition to what's already there.

2. We're not making DeHacked any crappier, just giving it, for the first time, the ability to not just edit, but add.

3. This is NOT just aimed at ports that have their own action definition language (for example, PrBoom+, Fusion, Doom Retro, Crispy Doom), but for all ports, except Chocolate, which has a conflicting mission. That includes any port that supports DeHacked, including ZDoom and derivatives.

4. I am all for a universal actor definition language. Is that to be DECORATE? Maybe. It would be hard to argue that DECORATE is immensely popular, and powerful. Problem is, some ports will never get there. ZDoom has bypassed everything else, with no sign of stopping. That's a good thing. But, some ports will never have full-blown actor definition support.

Here's a question for you: How would I take the latest ZDoom DECORATE parser code, and drop it into my C source port, and expect it to work? I have a feeling that that would be a massive project, and I would be translating code for weeks.

However, after implementing my proposal, I could sit down and spend a couple of nights writing a reduced-functionality, bare-bones DECORATE parser, and direct it to write the states into this new DeHacked buffer.

In fact, if there was a C DECORATE parser code package that could be dropped into the original Linux 1.10 source dump, and would replace info.c + info.h, without dependencies, I'd grab it in a second, and so would most port authors, I think.

But, my proposal can be dropped into most ports (ZDoom would require some work), and, all of a sudden, those ports can handle custom monster packs, without sacrificing original monsters, and maps made for the port would work most everywhere. It's a lot of value, for very little upfront work. That's what makes it a win.

Yes, DeHacked used to be pretty terrible, but, nowadays it enjoys near universal support, and BEX extensions improved it a lot. Yes, the syntax is not so pretty, but this proposal does not make it any worse. It makes DeHacked quite a bit more useful, and powerful, and it does that practically for free. Why not get all we can get out of it?

Again, we can start another thread and discuss a universal DECORATE language. But, to be practical, a few port authors need to show some interest, so we are not wasting our time.

Restrictions
I think we should limit our discussion to action pointers that could be implemented in MBF, without changing or adding any global structures (expect the action functions themselves). That means we are limited to the 2 misc 32-bit integer arguments (misc1 and misc2), and we do not create static variables, or call out to any external libraries, etc. Again, drop-in replacement if possible.

Now, optionally, if a non-vanilla port-specific feature is pretty common, I suppose we could add it, and support it conditionally via conditional compile defines. For example, a function to make an actor, say, 50% translucent could be added, along with a C define: #TRANSLUCENCY_SUPPORT. The translucency function would be available to all ports, but would only function in ports that support translucency. We should consider those on a case-by-case basis. I would find this particular function to be rather important, so I would push for its inclusion, for example.

EDIT: @VGA: I like GETHACKED, but, unfortunately it's 9 characters :( Maybe BEHACKED, UNHACKED, IMHACKED. HACKME. HACKYOU. :) What's wrong with DEHACKED?

kb1 said:

Neat! This might become useful for me as well.

Unfortunately I don't have time (or at least my wrists won't let me take the time) to complete the project myself. I'd need someone to step up to at least help with getting the base DECORATE script in order for that to go anywhere.

kb1 said:

4. I am all for a universal actor definition language. Is that to be DECORATE? Maybe. It would be hard to argue that DECORATE is immensely popular, and powerful. Problem is, some ports will never get there. ZDoom has bypassed everything else, with no sign of stopping. That's a good thing. But, some ports will never have full-blown actor definition support.

I think it's important to note that supporting the DECORATE language doesn't necessarily mean you need to support every feature in ZDoom's API. Just look at ECWolf (which has it's DECORATE code from scratch and targets a different engine altogether). If the mod author restricts themselves to the standard DeHackEd code pointers then DECORATE is nothing more than a declarative language for specifying the internal tables.

The code I linked is essentially what you're looking for a bare bones DECORATE parser that could feasibly multi-target (source code, dehacked, etc). I'm not sure why the parser would need to be written in C, you can certainly have a C port call into the C++-based parser and get the tables out of it without completely making the jump. (Although one should, but that's another holy war.) Note the code I have has no dependency other than the standard C++ library.

kb1 said:

Here's a question for you: How would I take the latest ZDoom DECORATE parser code, and drop it into my C source port, and expect it to work? I have a feeling that that would be a massive project, and I would be translating code for weeks.

I don't think taking the code from ZDoom would be very helpful. It not only has a really lax parser (which might be good if you're going to try to target 100% ZDoom mod compatibility, but I'm guessing we're not), but it also has a fair amount of backwards compatibility code for the old style DECORATE.

The project I linked has a parser for most of the parts you would care about in just over 1,000 lines of code including comment parsing for meta data. (ECWolf's parser which includes parameterized code pointers and expression evaluation is about 3,000 lines of code.)

Blzut3 said:

(lots of info about DECORATE parsing)

Time is a precious resource here too. I agree - a universal parser does not need to target ZDoom's full function set (but should strive to be a 100% subset, or be called something different). I loathe incompatibilities, unless anyone didn't pick up on that.

Good to know about a clean DECORATE source. And, Eternity has some DECORATE support going as well. And, as Graf said, yeah there;s a lot of other actor def formats out there as well - KBDoom has one, it was called GAMEINFO before ZDoom grabbed that lump name for their own purposes... I like my parser, simply because I wrote it. And, that's the problem.

That's why I really don't want to create yet another parser, even if it's similar to others, without seeing if this preliminary DeHacked extension step can gain enough support to actually get implemented. At this stage, it's almost a lost cause to wish for universal compatibility across all features. It's a long road, anyway. But, I'll keep pushing for it, step by step. It should have been considered from the start.

If this first step gains some support, a standard, documented DECORATE syntax and parser is the next stage.

kb1 said:

EDIT: @VGA: I like GETHACKED, but, unfortunately it's 9 characters :( Maybe BEHACKED, UNHACKED, IMHACKED. HACKME. HACKYOU. :) What's wrong with DEHACKED?

REHACKED.

Xaser said:

REHACKED.

Heh, I was thinking of this earlier. Good name, that!

D3H4CK3D: 1337 3D1T10N

VGA said:

Dehacked is awesome, not miserable. This thread is getting way too complicated and nothing will come of it if it continues this way.

Indeed, nothing will come out of it.
People are correct when they say that without support by PrBoom+ it's all useless talk.

The irony is, there's sufficient ports out there that can do what people need, but since the overarching goal is some kind of 'Boom compatibility' such inane suggestions are made.

So, either stick to the basics or switch ports!

Or get the relevant players to sit together to draft a Boom 3 standard. And by 'standard' I mean real solutions instead of extending crutches.

Graf Zahl said:

Indeed, nothing will come out of it.

That's why nobody pays "an ideas guy."

Graf Zahl said:

Indeed, nothing will come out of it.
People are correct when they say that without support by PrBoom+ it's all useless talk.

The irony is, there's sufficient ports out there that can do what people need, but since the overarching goal is some kind of 'Boom compatibility' such inane suggestions are made.

So, either stick to the basics or switch ports!

So the answer to creating a crossport standard is to just use ZDoom?

Or get the relevant players to sit together to draft a Boom 3 standard. And by 'standard' I mean real solutions instead of extending crutches.

A Boom 3 standard would be fantastic, if developer interest was there for it. Maybe someday.

geo said:

That's why nobody pays "an ideas guy."

ok

Honestly, I think at this point the community is way past the idea of unification. Doom source ports are too big of a mess already.

Boom is the closest thing to a unified standart, and it's relatively simple, yet I'm making a badass special effect and it only works in PrBoom+, because even Eternity does some things differently. You can branch the code, pile up hacks and compatibility options, but something will always break somewhere, limiting the wad author's options.

Or maybe I'm just in a pessimistic mood.

esselfortium said:

So the answer to creating a crossport standard is to just use ZDoom?

No, but it's pointless to demand some extension just to be able to tag '(somewhat) Boom compatible' onto a map. Let's be frank here: Boom is not the right standard to do this stuff, so either do what the standard allows or choose another port that can do what the map needs. There's enough choices out there.

esselfortium said:

A Boom 3 standard would be fantastic, if developer interest was there for it. Maybe someday.

I will be the last person to object. But here, like with the Dehacked extension, it all depends on PrBoom+ being interested and an active participator. Otherwise it's all wasted effort.

But if you get PrBoom+, Eternity and ZDoom in - then it will have a good chance of succeeding.

Graf Zahl said:

I will be the last person to object. But here, like with the Dehacked extension, it all depends on PrBoom+ being interested and an active participator. Otherwise it's all wasted effort.

But if you get PrBoom+, Eternity and ZDoom in - then it will have a good chance of succeeding.

Those are the big three that I think would be worth aiming for with any sort of cross-port feature proposal, for sure. They already have a significant set of shared features that have become a sort of informal Boom-plus standard:

• Doubled limits on map structures
  
• Extended ZDBSP nodes to eliminate node format limits
  
• Tall patch format
  
• MBF sky transfers
  
• MBF codepointers/thingtypes/frames
  
• Possibly some other things I'm forgetting :)

No, but it's pointless to demand some extension just to be able to tag '(somewhat) Boom compatible' onto a map. Let's be frank here: Boom is not the right standard to do this stuff, so either do what the standard allows or choose another port that can do what the map needs. There's enough choices out there.

It's true that the term "Boom compatible" is pretty misused anymore, as they don't mean nearly the same thing that they used to, but we don't really have a name for the informal shared standard that exists between those three ports nowadays, so it all gets lumped in there.

That aside, though, the point of a proposal like this isn't to be able to use the words "Boom compatible" or anything else, it's to be able to do more without limiting players to a single port. And despite the fact that, yes, most of us have multiple source ports on our computer and will use the one that's required if we want to play something, supporting PrBoom+ is a huge benefit to any content creator because it means the demo-recording and speedrunning part of the community will be able to play their wad competitively, potentially significantly enhancing the wad's longevity and popularity. This is one of the biggest reasons so many mappers aim for "Boom compatibility".



Personally, I'm not attached to any one particular way of handling this. Obviously whatever would be most appealing to the actual source port devs would be the best starting point. kb1's original proposal was an attempt to keep things simple by leaning as much as possible on existing framework, but it seems that the reality is more complicated for ports at this point in time, so if this discussion is to continue, we probably do need an alternate idea.

Considering I couldn't get entryway to agree that allowing additional BEX string mnemonics would be acceptable (such as HUSTR_33 and higher, for allowing custom MAP33 and other such hidden maps to have a DEH/BEX specified name w/o any port specific hackery going on), I am not confident at the get go.

However, I am of course interested. EE dev is dormant at the moment due to my unforgiving schedule of commitments but I am hoping to be back on it by August of this year.

I'm not going to quote spam, as justified as it feels to do. But I do know that pissing on an idea because source ports haven't yet praised it is not the best way to get source ports to praise it.

Unification is, of course possible. And, I guarantee you, if 3 bad ass TCs are released, using extended states, and the only reason a port can't play them is because it hasn't implemented extended states, there's a good chance the ports will consider implementing extended states. (could I have said that in a more circular manner? :)

I'm pretty sure it's a viable idea - I see some big names in the Doom community, in this thread, that are interested. Combine that with the fact that, once developed, it can be dropped into a port's source code rather painlessly, it seems to me that it's a lot more work defending the idea, then just building it. How is that possible?

As far as PrBoom+ goes, entryway already stated that PrBoom+ was designed to emulate dead ports, so his focus may not be on new features. Then again, it doesn't look like he's had much time to work on Doom for a while now.

@Graf: I asked you specifically to openly consider a few points, and I spent quite a bit of extra time to explain those points, to you basically. Yet, instead of considering those points on their own, you foresee thye plan's death, call it inane, and suggest setting the "dirty, unwashed" ports adrift, and just use your port, basically. I wasn't asking for approval, just an honest, unbiased assessment of the pros and cons of the idea.

And, yes, ZDoom has changed the format and style of the engine, and the source, so dramatically, that implementing this idea is a little bit more work for ZDoom. Is that what this is about?

At the end of the day, I'm not playing a source port, I'm playing a Doom WAD. As much as possible, the tool I use to play that WAD should be my choice, just like I get to use which monitor I use, and which mouse I use. Now, I know that some ports have unique features that only they support. So be it. Custom monsters does not have to be one of those.

In my archive, I have 2 folders: Doom Wads, and Doom Wads That Require Source Port X. (not literally those names, but, yeah). I'd like that second folder to get smaller.

kb1 said:

I'm not going to quote spam...

Oops, I lied. In re-reading the thread, I wanted to address a few additional points:

Da Werecat said:

Honestly, I think at this point the community is way past the idea of unification. Doom source ports are too big of a mess already...
...maybe I'm just in a pessimistic mood.

No, you make very good points here. Unification is a huge undertaking, but is it not worth striving for? There are a lot of areas where unification would be very complicated, but there are some features that are simple, and provide huge benefits for map authors.

I would like to attack the problem from all directions. In this thread, I am trying to work from Boom/MBF forward, slowly inching forward. We're all at the Boom/MBF milestone. I'd like to go one step ahead: Boom/MBF+extra states. That opens up some pretty huge possibilities. We should all be excited and motivated to slowly push the standard model forward a bit, right?

esselfortium said:

...Personally, I'm not attached to any one particular way of handling this. Obviously whatever would be most appealing to the actual source port devs would be the best starting point. kb1's original proposal was an attempt to keep things simple by leaning as much as possible on existing framework, but it seems that the reality is more complicated for ports at this point in time, so if this discussion is to continue, we probably do need an alternate idea.

Honestly, this proposal should be do-able in all ports, without problems - that's why I proposed it that way. It's low-hanging fruit. Of course, it's not the "cleanest" editing method, but support for DeHacked is there already. I am proposing a teeny bit of coding, for a huge editing benefit - that's what makes this approach appealing on it's own. I didn't need to think any further than that.

Yes, we should create a nice, powerful, unified actor definition system, absolutely. But, imagine how many thread pages of arguments that will generate? :) Until then, we could be enjoying maps with tons of custom monsters with new attack/movement capabilities, in the port of our choice, with very little coding effort required. I think a port author could implement it, compile and release it to map authors in a day.

The first step to achieve unification is to unify ourselves. (whoa...heavy, man!)

Quasar said:

Considering I couldn't get entryway to agree that allowing additional BEX string mnemonics would be acceptable (such as HUSTR_33 and higher, for allowing custom MAP33 and other such hidden maps to have a DEH/BEX specified name w/o any port specific hackery going on), I am not confident at the get go.

I think PrBoom+ will catch up, eventually. Entryway appears to be busy with other things at the moment.

Quasar said:

However, I am of course interested. EE dev is dormant at the moment due to my unforgiving schedule of commitments but I am hoping to be back on it by August of this year.

Quasar: EE is a powerful beast of a source port, man! It has tons of potential. EE is, and you are, in a unique position of authority on the matters of compatibility, and unification. Mad respect to you for your efforts! Those include:
. Fully-compatible, precise FP rendering
. UDMF: Universal Doom map format
. Old demo compatibility, up to MBF I believe
. Because of the above, EE has a vintage feel, yet boasts a host of new editing features
. Demo-compatible Strife "reassembly"
. Some ZDoom compatibility, including DECORATE support
. Many others I'm forgetting

Again, your attention to detail, towards vintage gameplay feel, and vanilla thru MBF demo compatibility, combined with your port's feature set gives you a voice of authority, and even of wisdom, in the area of unification.

I'd like to think that this thread aligns with your efforts, and I'd like to be a part of that effort. I see it as a movement, to attempt to correct the sins of the past, where port devs split into every direction, and created the mess we have today.

I should mention: I know that you've also been struggling to choose and implement a fully-featured scripting engine for your products.

Maybe it's wrong to wish that there was one universal idTech1 source engine that does everything. But I strongly believe that ALL ports should know what they are being asked to do, and they should gracefully decline trying to render a map containing features not supported. In other words, all ports should, at least, know that, say, 3d floors are being asked for, or that this TC requires script interpretation, or that textures are in PNG format, etc, etc.

With universal formats, ports can knowingly accept or decline a wad, map, or whatever, and be able to inform the user what's happening. With universal formats, the need for "hacks" diminishes to nil. Universal ways of thinking promote limit removal, clean code, easy-to-read source data - the list goes on and on.

I am glad you're interested, and value your input. The way I see it is that your energy is moving in the right direction, as is some others in this thread. It's usually the same people, harboring this same energy, in similar previous threads.

Thanks, all of you, for your interest, and support. Let's move forward!

past the first few posts I've only skimmed, but I would love to see a more useful, universal feature set :D MBF was really exciting at first but I quickly realized how oddly limited its features still are, so getting something a little more would be great

kb1 said:

. Some ZDoom compatibility, including DECORATE support

Don't be mistaken here. Eternity supports using DECORATE syntax for defining new actor states in EDF. It's a convenience for EE modders because DECORATE state syntax is the simplest, cleanest syntax available; but it's not here for ZDoom compatibility. To start with, EE does not parse DECORATE lumps at all...
http://eternity.youfailit.net/index.php?title=DECORATE_state_syntax

Gez said:

Don't be mistaken here. Eternity supports using DECORATE syntax for defining new actor states in EDF. It's a convenience for EE modders because DECORATE state syntax is the simplest, cleanest syntax available; but it's not here for ZDoom compatibility. To start with, EE does not parse DECORATE lumps at all...
http://eternity.youfailit.net/index.php?title=DECORATE_state_syntax

Not *entirely* accurate as EE *also* supports a (slowly) growing suite of compatible action pointer implementations, such that it's possible to port over a good number of DECORATE monsters almost directly. I've done a lot of work to try to minimize the differences between EDF and DECORATE just so that knowledge of the latter will translate more to the former.

Am I wrong or after many years the only ports that support UDMF is ZDoom + family ?

VGA said:

Am I wrong or after many years the only ports that support UDMF is ZDoom + family ?

Depends if you count Vavoom as being in ZDoom's family. :p

But yeah, other than that it's still just ZDoom, GZDoom, and Zandronum. I think there's a bit of a chicken and egg thing going on. Since UDMF is only supported by ZDoom & co, only ZDoom will load UDMF maps, so there is no reason not to use the ZDoom namespace and all its extra features, so if some other port such as Doomsday or PrBoom+ suddenly implemented UDMF support they still wouldn't be able to load them, so there's no incentive for port programmers to add UDMF support, and so on.

Gez said:

Depends if you count Vavoom as being in ZDoom's family. :p

But yeah, other than that it's still just ZDoom, GZDoom, and Zandronum. I think there's a bit of a chicken and egg thing going on. Since UDMF is only supported by ZDoom & co, only ZDoom will load UDMF maps, so there is no reason not to use the ZDoom namespace and all its extra features, so if some other port such as Doomsday or PrBoom+ suddenly implemented UDMF support they still wouldn't be able to load them, so there's no incentive for port programmers to add UDMF support, and so on.

And, it takes time, and it takes having a port that has a lot of custom editing features, where there's a need for a non-hack way to enable those features.
Ports that don't really go far past Boom features have a hard time justifying the extra work to support UDMF (though they could benefit from it).

It's usually those ports that would benefit from the new frames described in this thread. In other words, ports that have custom a actor definition language are, by definition, interested in custom editing, so they may also want to implement UDMF. But, please note that these are 2 very different things, of course!

From what I'm reading in this thread and others, it looks like DECORATE could become a standard that's promoted as such, but I worry about the action functions. Is it possible to standardize those, without bringing in Hexen/Strife-specific support code, mobj field additions, new mobj flags, etc? In other words, would it be possible to define a standard that could work, out-of-the-box, for a Doom-only port?

kb1 said:

From what I'm reading in this thread and others, it looks like DECORATE could become a standard that's promoted as such, but I worry about the action functions. Is it possible to standardize those, without bringing in Hexen/Strife-specific support code, mobj field additions, new mobj flags, etc? In other words, would it be possible to define a standard that could work, out-of-the-box, for a Doom-only port?

Full DECORATE is not going to become a standard; there's no chance of that. It would take me months of dev time to write a parser for it because it has so many special cases, and all this just to adapt something largely redundant to my own content definition language that I invested years of dev time into, and implying support for dozens if not hundreds of features that Eternity does not have and in some cases has no plans to *ever* have. Nah.

Whatever this proposed cross-port standard thing is going to be, it has to be relatively simple. Clean, concise, and most importantly, consistent grammar.

The main interest of the UDMF for a pure limit-removing port with no extra fancy features (besides Boom stuff) is that it's a limit-removing map format, where you aren't restricted by the number of vertices, linedefs, sidedefs, and sectors that can be placed. This allows to create really huge maps.

The Doom map format uses signed shorts to represent a linedef's vertices and sides, and a side's sector. Therefore, you are limited to 2^15 = 32768 vertices, sides, and sectors; in practice the side limit is the first one to be reached, though the vertex limit can be broken through when nodebuilding, which led to adoption of ZDBSP's extended nodes to separate seg vertices from "normal" vertices.

These limits were mitigated a bit by using unsigned shorts (and using 65535, instead of -1, to mean "none"), and by using so-called "sidedef compression" where lines that have perfectly identical sides will share the same side instead of each having their own (but this has its own side effects, pun not intended, on things such as the scrolling texture line types). The efficiency of this compression also depends on the existence of many sides having perfectly identical properties, something that has probably become less common now that editors automatize texture alignment instead of always defaulting to offset values of zero.

ZDCMP2, for example, has 136855 sidedefs, more than twice the maximum for the Doom or Hexen format, and I really doubt sidedef compression could bring it under the limit.

Quasar said:

Whatever this proposed cross-port standard thing is going to be, it has to be relatively simple. Clean, concise, and most importantly, consistent grammar.

I think a "strict DECORATE" could provide this easily. One would have to go out of their way to make a strictly parsed DECORATE script be incompatible with ZDoom's lax parser, but at least the rules for it are much easier to define.

ECWolf's DECORATE parser is able to ignore pretty much anything unknown it comes across. Off hand, once you get past the extremely weird tokenizing which happens because it's using a hacked up sc_man, I think the only oddity in DECORATE's syntax is the damage property which can take an expression in parentheses to remove the random factor.

I certainly think it would be unreasonable for any port to have to support old style decorate or any of the other compatibility stuff which would be implied with "full" DECORATE support.

Let's see a proposal of this now, then, to get it out of the way early. Write up what a new actor with states would look like declared in this restricted subset and show me how it *won't* require me to completely refactor my engine to have everything internally in line with how ZDoom works and I'll be satisfied.

Note the moment that any reference to a native class name or inheritance from native classes is implied, you've already lost that capability. The moment that I have to realign my bitflags, you've lost it.

It needs to be careful to abstract everything from port specifics or it won't achieve anything.

I'll also note that, if we're still entertaining the notion of dragging prboom-plus into this, that it simply has no capability at all currently that would lean in this direction - it still has mobjinfo, states, and sprites as static arrays. It's basically in the situation of vanilla Doom. For that port, a spec capable of defining an arbitrary number of actors and states is tantamount to a decree that it should develop its own EDF/DECORATE type architecture first.

Quasar said:

I'll also note that, if we're still entertaining the notion of dragging prboom-plus into this, that it simply has no capability at all currently that would lean in this direction - it still has mobjinfo, states, and sprites as static arrays. It's basically in the situation of vanilla Doom. For that port, a spec capable of defining an arbitrary number of actors and states is tantamount to a decree that it should develop its own EDF/DECORATE type architecture first.

Static arrays aside, consider that earlier in this thread I posted a prototype that would in theory allow even Chocolate Doom to adopt DECORATE (with comment parsing extensions) as a compile time feature. It's certainly possible for any source port to implement the vanilla subset of DECORATE.

But sure, give me some time and I'll do a full write up on DECORATE.

Please, guys, this talk about a unified actor definition language is great, but not in this thread. The new State table standard DOES work with static tables, and has none of the compatibility concerns or issues that a custom actor definition language discussion has.

This thread describes a simple way for ports that have not implemented a custom actor definition language, to be able to render games with new monsters beside the originals. This is about a method that works for those ports, as well as the more advanced ports that do support custom actor/state definitions.

Respectfully, please start a separate thread for a unified actor definition language. And, remember, it's not just the states, but also the monster definitions themselves.

Haha Fusion is fun.

New codepointers:

// Fusion Codepointers

// Len's Codepointers
extern void A_DistanceDamage();
extern void A_SplitAttack();
extern void A_ProjectileFire();
extern void A_DetonateMisc();
extern void A_FireMancubus();
extern void A_FireBaron();
extern void A_FireArachnotron();
extern void A_FireCaco();
extern void A_FireImp();
extern void A_ProjectileFire2();
extern void A_SkillJump();
// End Len's Codepointers

// Hakx's
extern void A_Massacre();
extern void A_EnemyFireBFG();
extern void A_EnemyFirePlasma();
extern void A_EnemyFireBetaPlasma1();
extern void A_EnemyFireBetaPlasma2();
extern void A_EnemyFireRocket();
extern void A_Burn();
extern void A_MFC_Shadow();
extern void A_MFC_ShadowOn();
extern void A_MFC_ShadowOff();
extern void A_MFC_Float();
extern void A_MFC_FloatOn();
extern void A_MFC_FloatOff();
extern void A_MFC_Touchy();
extern void A_MFC_TouchyOn();
extern void A_MFC_TouchyOff();
extern void A_MFC_Friend();
extern void A_MFC_FriendOn();
extern void A_MFC_FriendOff();
extern void A_MFC_Translucent();
extern void A_MFC_TranslucentOn();
extern void A_MFC_TranslucentOff();
extern void A_MFC_Bounces();
extern void A_MFC_BouncesOn();
extern void A_MFC_BouncesOff();
extern void A_MFC_Noblood();
extern void A_MFC_NobloodOn();
extern void A_MFC_NobloodOff();

extern void A_FireBetaPlasma1();
extern void A_FireBetaPlasma2();
extern void A_FireRevenant();

extern void A_MoveForward(); // Hakx 8/21/1999
extern void A_MoveBackward();
extern void A_MoveUp();
extern void A_MoveDown();

// Hakx 10/7/1999 [Shooters]
extern void A_ShooterPistol();
extern void A_ShooterShotgun();
extern void A_ShooterDoubleShotgun();
extern void A_ShooterRocket();
extern void A_ShooterPlasma();
extern void A_ShooterBFG();
extern void A_ShooterBetaPlasma1();
extern void A_ShooterBetaPlasma2();

// Fusion States

  // Hakx 10/7/1999 [Shooters]
  S_SHTR_PSTL,
  S_SHTR_PSTL2,
  S_SHTR_SHOTGUN,
  S_SHTR_SHOTGUN2,
  S_SHTR_DSHOTGUN,
  S_SHTR_DSHOTGUN2,
  S_SHTR_ROCKET,
  S_SHTR_ROCKET2,
  S_SHTR_PLASMA,
  S_SHTR_PLASMA2,
  S_SHTR_BFG,
  S_SHTR_BFG2,
  S_SHTR_BETAPLS1,
  S_SHTR_BETAPLS1_2,
  S_SHTR_BETAPLS2,
  S_SHTR_BETAPLS2_2,

  NUMSTATES_1  // Counter of how many there are
} statenum_t;


#define NUMSTATES NUMSTATES_1+2000

Gez said:

Haha Fusion is fun.
... lots of redundancy...

Wow. I know that you get it trouble when monsters use player attacks and/or vice versa. I *guess* it could be cool to have those specific attacks predefined?? But, generic action funcs could basically emulate *most* all of those. Giving players a homing missile, or a vile attack could be exceptions to that rule.

Personally I'd prefer less, more-powerful funcs myself, depending on misc1 and misc2 making them specific.

However, I have to say that, while some posts here have been very encouraging, some others have not. That's ok, and expected, but, I feel a sense of duty to offer more than just suggestions. To really have a chance, I need to get serious, and step up to the task.

That involves me setting up a web site and forum, dedicated to Doom port development. I also need to get some source up and running, with my new ideas for universal compatibility. I can't really expect everyone to embrace a universal idea, without an example. That includes a port, with UDMF support, expanded state table (and mobj table) support, and a few other ideas I've been silently working on. This would, otherwise, be a bare-bones MBF-compatible port.

This web site would be a place for developers to discuss ideas for ways to implement new data formats that could potentially be applied to all ports. Many port authors will initially resist the idea of altering their own proprietary formats, whcih stems from "pride of workmanship", among other things. I am sensitive to that, and I would use this web site to try to accomodate ideas from various sources. It would be nice to encapsulate the idiosyncrasies of everyone's formats into a grand format.

Now, I must admit that design-by-committee usually moves way too slow, and has poor results. At the end of the day, someone has to make a final decision. I feel like I am level-headed enough to be up to the task, but I would also like to have a few select others are responsible, and can take charge of specific formats, and decide on the final spec.

Maybe it's just a dream. But, if you think about it, all ports are basically doing the same things on a whole - rendering 2.5d worlds, populated with monsters, weapons, props, pickups, etc. All of the port-specific additions are basically tweaking what's already there.

There are a lot of obstacles to making this happen myself. I am working toward this goal, however.

As far as this proposal goes though, I think the idea of adding new action funcs is holding it back. If we are to add new funcs, I suggest that it's less than a dozen, and that they are very generic, like A_Generic_Melee(), and A_Generic_Missile(). Bang for your buck!

Gez said:

#define NUMSTATES NUMSTATES_1+2000
[/code][/spoiler]Yeah, "NUMSTATES" is 2000 more than what's actually used, two thousand dummy frames, woohoo!

Heh. Well, that's part of it. I forgot to mention the need to add some mobj slots too (oops). Maybe 1 for every 10 new states, or so?