Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
kb1

Proposing a new State table standard for DeHacked

Recommended Posts

In my previous Ideas for complimentary custom monsters thread, I found that DoomWorld users have some great custom monster ideas! However, only some of them can be implemented in many Boom/MBF level ports that lack direct State table editing (via DECORATE, DDF, EDF, etc). Ports without such support rely on supporting DeHacked.

As most people know, DeHacked allows you to edit existing actor frames definitions to achieve some new monster/thing behaviors. But, it has many limitations:

. You must "steal" frames from other monsters/things to use for your custom monster.
. Monsters typically require a lot of frames.
. Frames are a very precious resource - there are only a few frames that usually won't be missed.
. All but the most basic, common actions are done with "Action code pointers".
. The available actions are limited in various ways, and/or not appropriate for "general use".

Soon after the source code was released, Boom was born, and MBF was spawned from Boom. These source ports brought many new features that, today, are considered to be standard features of all but the most pure ports, such as Chocolate Doom.

This thread is concerned with 2 of these new features:
* an expanded state table (more entries)
* some new action code pointers

The Proposal
So, basically, the proposal is:
Boom and MBF added extra states, and a few new actions, and many new source ports support them as standard.

I propose that we try to devise another standard. I have 2 changes in mind:

1. Increase the state table by adding, say, 1,000 blank entries (640k is enough RAM for anyone, right??) to be used by DeHacked. (Also, update the various DeHacked editors to be aware of the new states). Perhaps a new DeHacked setting could specify the number of new states, and the port builds the new states dynamically. But, maybe that's not supported by all ports, so, I say we choose a minimum of 1,000. That's room for about 40 full-frame new monsters, or so.

2. Collaborate to devise a list of the most useful, generic, Doom-compatible (no Hexen/ACS/scripting stuff) action code pointers that are desired/needed but not available in Doom at the moment. A good start would be to add the functionality required to implement the custom monster ideas from that "Ideas for complimentary custom monsters" thread.

3. Have a small team of programmers create some nicely documented and formatted, highly-compatible C code module that implements the new Action functions.

4. Create a snazzy name for this new Doom extension, and promote it as a new standard.

Details

Speaking of standards, at this point in time, as has been discussed countless times before, the highest level of cross-port compatibility any port can hope for today is "MBF-compatibility". From that point, each source port has gone in it's own direction. That's exactly why some of the nicer new features do not get used as much: Cause using a port-specific feature ties your mapset to that port!

This proposal should be do-able by most any source port, without creating any conflicts. (Ports that have added states beyond the MBF states may have to do a little bit of arithmetic, offsetting DeHacked indexes so they point to the chunk of new states.

Furthermore, the new Action functions will have to be written in a similar style to the original v1.10 source dump, and be highly compatible with that source. Port authors may have to make small adjustments to the official State Library Extension for Doom (SLED, there's a name) to make it work in their port, but these would be minor.

Implementation
For this to become a reality, we will need the following community support:
* Someone to write and maintain the official documentation on the new standard
* Collaboration from everyone on which Actions functions are needed
* A small team of programmers to write the Action code library
* A programmer to add support for the new frames/Action pointers to DeHacked tools
* A brave port author willing to implement v1.0 of the library into their port
* Some WAD/DeHacked authors who will create some custom monsters and DeHacked file, using the new frames/actions

Closing Thoughts
I like ZDoom and derivitives a lot, and no one can deny the awesome power it provides WAD authors. But, the way I see it, there's no reason ZDoom gets to have all the fun :) Probably the main reason you don't see more non-ZDoom projects using custom monsters is that the DeHacked method is very limited.

Please note that, if this proposal is accepted and implemented, there's nothing stopping port authors from providing a reduced-functionality DECORATE parser, that parses DECORATE code into this new state block. And that can be done in ports that don't otherwise implement dynamic state generation.

Finally, for this proposal to have a chance, it needs your support. I really don't want to start another 8-page debate on whether or not this is a good idea, and, why not implement full-blown DECORATE/scripting/etc. I am asking about the merits of this strictly-defined proposal as-is, unless I've really missed something.

So, let's talk about what action functions would be nice to add.

When a state (frame) has an action code pointer assigned, it can also pass 0 to 2 32-bit integers to that action. These integers are called "misc1" and "misc2".

Here's a couple of new Actions to get you started:

A_Wander()/A_RandomChase() - Walk in random directions, to emulate NPCs, cattle, other outdoor animals, etc.

A_RandomJump(probability) - Choose to jump to the defined "next" state, or to the following state, based on the outcome of a random number. ZDoom has a similar concept. This allows a monster to have multiple attacks, for example, chosen at random.

1. Is this a good idea? (please, a simple opinion only, no big debates :)
2. What are some ideas for some new Action pointers?
3. Any volunteers for the tasks listed above?

Share this post


Link to post

Since this "new standard" involves enhancing source ports, it can affect basically anything. The goal is supposedly flexibility and convenience. Instead of "raising limits" of DEHACKED, why not develop an entirely new scripting language that will allow every mapper/modder to directly touch game data and define their own codepointers, things, states and functional stuff like that? Then bundle it with a few standardized definitions of useful codepointers like you proposed, etc. I mean to say, if a new standard, then no lesser than the most efficient one possible.

Share this post


Link to post

I kind of understand why you'd want to update the DeHacked standard rather than implement some new scripting language. Many source ports honestly already have their own scripting language, but that requires learning an entirely new approach to modifying the core behaviors of Doom, and they're not compatible across source ports. I can't speak for everyone, but myself, I never really learned how to modify Doom behavior outside of DeHacked, and I don't really care to learn something new. Maybe I'm old, or maybe I'm lazy, but that's the way I'd feel. For myself anyway, I'd just prefer to have Dehacked, but with the prior restrictions removed, so I could make minor changes as I saw fit without having to learn something entirely new. I dunno, I'm probably in the minority on this, I've never been a huge modder anyway, so I don't think my opinion carries much clout, but it's always been my secret wish that the capabilities of DeHacked were simply expanded, rather than having to learn some completely new scripting language or whatever to do what I wanted.

Share this post


Link to post

scifista42: It would have been nice to have an entirely new cross-port standard to supplant DeHackEd, but I imagine that that ship sailed roughly 15 years ago. I doubt many port authors today would be interested in supporting another completely different system for actor and state definitions, when many of them already have their own proprietary systems (DECORATE, EDF, DDF, etc.) implemented. On the other hand, DeHackEd is already implemented in every modern port, and states and codepointers have been extended in a cross-port manner before.

kb1: I like it! I could definitely see this getting some use :)

A couple of other (hopefully not too complicated) things I'd want to see as part of it:

- A bunch of new, unused thingtype slots to go along with the new, unused states.

- A codepointer that fires an arbitrary thingtype as a projectile, ideally with an optional angle offset for spread attacks. MBF has a pointer to Spawn arbitrary things, but there's no way to make those things behave as a projectile, so currently monsters' projectile attacks in cross-port-compatible wads are still limited to the original types and behaviors.

BTW, I think MBF already has a Jump pointer for random frame jumps.

Share this post


Link to post

One thing that would be nice is custom puffs for gauss like explosive weapons. The area denial aspect of having to watch back blast of a rocket is not really explored with hitscan enough.

Share this post


Link to post

It's a nice idea. I reject all of your proposals for inclusion in Chocolate Doom.

Share this post


Link to post
fraggle said:

It's a nice idea. I reject all of your proposals for inclusion in Chocolate Doom.

I think that goes without saying :) This is presumably intended for the subset of ports already supporting MBF features.

Share this post


Link to post
geekmarine said:

I kind of understand why you'd want to update the DeHacked standard rather than implement some new scripting language...

geekmarine, you read my mind! Your DeHacked code would work in, say, PrBoom+, Eternity, any port that decided to take an hour to drop the code in place :) Then, suddenly, custom monsters in near-vanilla-like ports becomes feasible, accessible even.

geekmarine said:

...it's always been my secret wish that the capabilities of DeHacked were simply expanded, rather than having to learn some completely new scripting language or whatever to do what I wanted.

What's cool is that, if this proposal is used, it does not block a port from adding it's own DECORATE/DDF/lmnop parsers. This code, once modified, could (should) be added to ZDoom as well. Again, it's a universal idea. All it does do is give DeHacked some breathing room, and add a few sought-after code pointers.

scifista42 said:

Since this "new standard" involves enhancing source ports, it can affect basically anything. The goal is supposedly flexibility and convenience. Instead of "raising limits" of DEHACKED, why not develop an entirely new scripting language that will allow every mapper/modder to directly touch game data and define their own codepointers, things, states and functional stuff like that? Then bundle it with a few standardized definitions of useful codepointers like you proposed, etc. I mean to say, if a new standard, then no lesser than the most efficient one possible.


scifista42: My proposal is literally adding a big chunk of zeros to an existing table, and a handful of Action functions, each with probably 20 or fewer lines of code that look awful similar to what's already in Doom, yielding a huge benefit towards Doom modding. It would work 100% correctly in all ports, to the level of demo compatibility, and it's easy to implement.

Your proposal involves the implementation of a new scripting language which, I assume, involves expression evaluation, boolean and arithmetic, nested functions, variable storage and retrieval, conditional control statements, bla bla...literally thousands of lines of code that would be implemented differently by port authors, out of necessity, would most likely not produce identical output, and would not be compatible with, say, Java/Delphi source code. You would either need a separate program to compile it into byte-code, or you'd build the parser right into the program, along with the bytecode engine that executes the code.

I tend to go for the most bang for your buck. Yes, all that stuff would be nice, and we have ports that do that. I am trying to create a standard that has a chance of being adopted universally. The only way that will happen is if it is shit-easy to implement, powerful, useful, and basically already written. See the difference?

esselfortium said:

kb1: I like it! I could definitely see this getting some use :)

A couple of other (hopefully not too complicated) things I'd want to see as part of it:

- A bunch of new, unused thingtype slots to go along with the new, unused states.

- A codepointer that fires an arbitrary thingtype as a projectile, ideally with an optional angle offset for spread attacks. MBF has a pointer to Spawn arbitrary things, but there's no way to make those things behave as a projectile, so currently monsters' projectile attacks in cross-port-compatible wads are still limited to the original types and behaviors.

BTW, I think MBF already has a Jump pointer for random frame jumps.

Thanks, esselfortium!

. Yes, I forgot about thingtypes - also important. Could cause a slight conflict with doomednums - again, maybe that's a new property for DeHacked (custom_starting_doomednum = 12000), for example.
. Yes, an A_GenericMissile would be nice, as well as an A_GenericMelee. I guess you'd have to use a non -1 doomednum thing as the missile, so you could identify it in the action.
. And, yes, I think you're right about MBF's Jump.

You know, this might be easier to adopt the idea of skipping the Action functions, and just adding a bunch of blank states and thingtypes. That alone would allow a lot of new functionality. Just an idea. It really is not an active idea unless someone is willing to add it to their source port. And, I won't be releasing mine for a while :(

@Linguica: I think you should add back a single carriage return above the top quote line - to me it looks a bit busy (Maybe that's the way I posted?). Then again, I obsess on formatting, so, for what it's worth :)

Share this post


Link to post

Oops - can't consolidate double-post: Delete failed to work for me.

fraggle said:

It's a nice idea. I reject all of your proposals for inclusion in Chocolate Doom.

A preemptive strike? Heh heh (thanks for the "arms-length" approval though :)

I think a minimum requirement is that the port supports Boom and MBF, realistically. That guarantees identical support (almost).

Share this post


Link to post

Oh don't get me wrong. I think it's an awesome idea and I wholeheartedly support it.

Share this post


Link to post
kb1 said:

You know, this might be easier to adopt the idea of skipping the Action functions, and just adding a bunch of blank states and thingtypes. That alone would allow a lot of new functionality. Just an idea. It really is not an active idea unless someone is willing to add it to their source port. And, I won't be releasing mine for a while :(

I suppose so, but a couple of action functions to fill obvious gaps like projectiles would make a huge difference to any modder aiming for this standard.

Share this post


Link to post
fraggle said:

Oh don't get me wrong. I think it's an awesome idea and I wholeheartedly support it.

Thanks, fraggle. I believed you, it was just kinda funny :)

esselfortium said:

I suppose so, but a couple of action functions to fill obvious gaps like projectiles would make a huge difference to any modder aiming for this standard.

I think you're right - the action functions need to be in version 1.0, otherwise I'm just asking port devs to add large blocks of zeros to their exes...

You know the best way to discover what action functions are needed? Have a port dev work with a monster resource wad dev to implement both the monsters in that recent Monster Ideas thread, plus all of Tormentor's Realm667 Doom Bestiary (or, as many as reasonably possible). That would create a kick-ass resource, and pretty much define EXACTLY what code pointers would be useful. That would literally cover all the monsters that people have recently made, or wanted.

From there, you'd work on other semi-animated objects: I'd like an ambient sound codepointer, like a fire-crackle sound for torches (Could be done trickily now, with a see sound, or something, but ugh).

Maybe a continuous spawnner, like a steam/smoke/leaf spawner (like Hexen has). I have some of these implemented in KBDoom, and Heretic and Hexen have some good ones too. (Hexen is not fully supportable in a Doom-only engine, though).

How about a missile fired up at a steep angle, that falls with gravity? That'd be a lot of fun to try to dodge, and anticipate where it'll land.

Lot's of possibilities. I'm wondering if bradharding or fabian would be interested in being a guinnea pig with their source ports? :) I'd be using my source today if it were releasable...I've got to find the time. Maybe, more work and less forum posting??

Share this post


Link to post

Not to betray our beloved Doom, but why make another source port when you can make your own game?

There are already plenty of source ports that add new enemies. Just ask them to do it.

So you just want Dehacked with extra parameters in a source port to make new enemies?

Its just easier to program new enemies with various new stats and then have an editor. Make your own editor like DeHacked if you're going through all the work.

Limitless variables is possible. Even editing a text file to put them all in.

Share this post


Link to post

The Realm667 bestiary has hundreds of monsters at this point, and a lot of them are dependent on elaborate DECORATE madness, so that's probably not a realistic goal :)

I feel that there would be worthwhile gains even from a relatively small set of action codepointers, and plugging the most obvious gaps probably ought to be the main priority, rather than getting so carried away with features that the complexity risks inhibiting developer interest.

On the subject of elaborate frame scripting, though, something similar to EDF's counters would add a lot of power, though it might be awkward to squeeze them into the misc1 and misc2 parameters. The general idea is that each thing is given a fixed number of numeric variables called "counters" that can be set, incremented (or have other math operations performed on them), copied, etc., and then frame jumps can be performed based on the value of a counter. Again, though, I'm not sure how feasible that necessarily would be here.

geo said:

Not to betray our beloved Doom, but why make another source port when you can make your own game?

There are already plenty of source ports that add new enemies. Just ask them to do it.

This isn't a proposal for a source port, it's a proposal for an extension of a feature that's already shared across several popular ports. Adding some new features with cross-port compatibility is the goal here. Skillsaw's recently released megawad Valiant makes extensive use of MBF's additional frames and codepointers to add new monsters (among other things) in a way that's compatible with ZDoom, PrBoom-Plus, and Eternity. This proposal would allow more modders to do cool stuff like that (and more of it) without limiting themselves to a single port and sacrificing the potential audience of the demo-recording/speedrunning community.

Share this post


Link to post

So just go to the Dehacked author? is there one? Its been like 18 years since I've used it.

Share this post


Link to post

Yeah I probably did its late for me. Sorry for late night bleh posts.

Share this post


Link to post

Eternity already imposes its own constraints on DeHackEd because it has interop with EDF. User-defined entities are only allowed to use DeHackEd numbers greater than or equal to 10000, and DoomEd numbers >= 20000. All other numbers are reserved for use by the game engine. This is completely non-negotiable in terms of being changed at this point.

Share this post


Link to post

I suppose this is a good excuse to make this repository public: https://bitbucket.org/Blzut3/declarate/overview

What is it? It's a DECORATE to info.c converter I was speed programming as a curiosity since someone was having trouble understanding what DECORATE is exactly. The idea being that once I get a complete recreation of the C structures I could then add allocation strategies to try to do a best effort compile of DECORATE into DeHackEd code. (Similar to what USDC does for USDF scripts. Also note that if Chocolate Doom were to add support for BEX code pointer assignment this tool would be a lot more useful.)

I was thinking about making it an April fools joke of sorts, but I didn't have time to do the monkey work required (a lot is already done in ZDoom, but it's not precisely 1:1. I showed the program to a few people and none of them seemed too interested). Once the base script is done, using inheritance and replacements (including frame garbage collection) would allow scripts that work both with this program and natively with ZDoom. (Or more realistically, it could be used to create custom games using the Chocolate Doom engine which automatically run in ZDoom.)

If anyone is interested the base script thus far is on the downloads page. Just run it with the program and it'll spit out source files for compiling with Chocolate Doom.

What does this have to do with this thread? Not a whole lot, but food for thought on developing a cross port scripting standard I guess.

Share this post


Link to post

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

Share this post


Link to post
kb1 said:

1. Increase the state table by adding, say, 1,000 blank entries (640k is enough RAM for anyone, right??) to be used by DeHacked. (Also, update the various DeHacked editors to be aware of the new states). Perhaps a new DeHacked setting could specify the number of new states, and the port builds the new states dynamically. But, maybe that's not supported by all ports, so, I say we choose a minimum of 1,000. That's room for about 40 full-frame new monsters, or so.


You might want to look at Fusion. :)

In fact, I think this whole proposal could basically be summed up as "let's adopt the Fusion standard feature set", though I'd personally object to the hardcoded transparency tables as being too cumbersome to implement. Everything else seems okay.



Also:
ComplEment: something that completes
ComplIment: something that flatters

Share this post


Link to post
kb1 said:

Maybe a continuous spawnner, like a steam/smoke/leaf spawner (like Hexen has). I have some of these implemented in KBDoom, and Heretic and Hexen have some good ones too. (Hexen is not fully supportable in a Doom-only engine, though).

This would be super useful! Eternity's SteamSpawn codepointer is a nice, powerful implementation of this, though things get tricky with only misc1 and misc2 fields...

FadeIn, FadeOut, and SetTranslucent would be very useful accompaniments to any sort of effect-spawning pointer, for steam sprites that fade away or whatever. (Among countless other uses of course!)

How about a missile fired up at a steep angle, that falls with gravity? That'd be a lot of fun to try to dodge, and anticipate where it'll land.

You can already enable gravity on projectile types, so this would just be a matter of allowing projectiles to be fired at vertical angles in addition to horizontal ones.

That's when things get really tricky for misc1 and misc2 again, though. I wonder how much more painful it would be for the supporting ports (ideally PrBoom-Plus, Eternity, and ZDoom) to support some additional arguments from these extended-bex patches? D:


exl said:

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

Fantastic, thank you!


Quasar said:

Eternity already imposes its own constraints on DeHackEd because it has interop with EDF. User-defined entities are only allowed to use DeHackEd numbers greater than or equal to 10000, and DoomEd numbers >= 20000. All other numbers are reserved for use by the game engine. This is completely non-negotiable in terms of being changed at this point.

What does this mean for the proposed extensions? Would this prevent this sort of bex extension from being supported in EE, or just require some specific conditions to be kept in mind when official specs are decided?

Share this post


Link to post
esselfortium said:

That's when things get really tricky for misc1 and misc2 again, though. I wonder how much more painful it would be for the supporting ports (ideally PrBoom-Plus, Eternity, and ZDoom) to support some additional arguments from these extended-bex patches? D:


ZDaemon has added arg1-arg9 to state defintions some time ago for just that purpose.

Share this post


Link to post

Idea: add action pointers corresponding to all ACS instructions, or alternatively devise a minimal set of action pointers that can be used to make state tables turing complete.

Share this post


Link to post

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.


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.

Share this post


Link to post

I might be wrong but I'm pretty sure expanding the weapons slots would be a different project entirely. Reconciling that with ports' existing weapon/inventory systems would probably add more complexity than would be ideal. Adding some unused thingtype slots would definitely be a valuable part of the spec, though.

Share this post


Link to post

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.

Share this post


Link to post

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


Bottom line is, we want a TON of empty frames and some parameterized code pointers, especially for guns, I should add.

I propose the name GETHACKED (with .GEH extension)

Share this post


Link to post
Da Werecat said:

Good luck convincing entryway that all these additions won't ruin his port. :)

Easy: get Eternal to use them in his next project.
His last major release (Voodoo Guns) is almost exactly as old as the last stable Prb+ release, (not) coincidentally.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×