DEHEXTRA discussion (split from Pr+ UMAPINFO thread)

Of course it would present the same issues! The effect is the same (more weapons and more weapon slots) and that would require a lot of extra logic to conditionally enable them only if they're needed (otherwise, demo desyncs guaranteed) and that would also require from ports like Eternity and GZDoom, which have their own custom actor systems, a lot of extra work to fit these optional weapons into said custom actor systems.

The thing to keep in mind is that weapons are not just free-floating actors that can be added or removed without affecting the rest, like adding a new imp variant or whatever. Weapons are actually a part of the player avatar's definition. For a weapon to work, it has to be connected to the player, and that's what makes adding dummy weapon slots a tricky prospect.

I see. I hope in the future there's a planned workaround for that, because a hard cap of nine weapons might be limited in the long run when many modern gameplay mods/TCs have at least ten.

yeah, no use to make a difficult task like that when EE is already and option for new content and demo compatibility.

Aside from that, is there already a project that is using dehextra?

I remember Smoothed, but any other?

@Shadow Hog Any word on the extra sounds? EE 4.01.00 is around the corner and it'd be nice to get all the new sounds in beforehand, assuming other ports are ready to onboard them too. I just need to know what the mnemonics and lumpnames are. I was guessing something like ext[xyz] so ext000, ext001, etc. (ds before actual lump names as is standard) with default Doom pitch variance and a priority of 64 (default). There's other sane naming conventions too, like snd500... or what have you.

Also I realise now I made a mistake. Would 500-699 be suitable instead of 400-599?

7 hours ago, Altazimuth said:

@Shadow Hog Any word on the extra sounds? EE 4.01.00 is around the corner and it'd be nice to get all the new sounds in beforehand, assuming other ports are ready to onboard them too. I just need to know what the mnemonics and lumpnames are. I was guessing something like ext[xyz] so ext000, ext001, etc. (ds before actual lump names as is standard) with default Doom pitch variance and a priority of 64 (default). There's other sane naming conventions too, like snd500... or what have you.

Also I realise now I made a mistake. Would 500-699 be suitable instead of 400-599?

Sorry, got engrossed in touching up an SSF-MIDI-extractor I was writing in Java this weekend, and thus didn't touch this too much. Since reading your post I've been working on getting my old PrBoom+ fork up-to-snuff after gathering dust for years so I can do a proper pull request, but it decided that like 100 commits to Graf's repo simply never happened, and trying to merge the two repos so I'm at some level of parity has been like pulling teeth. For some reason, despite insisting I was merging in Graf's master branch, Git insists I want code from the DECOLITE branch instead. Except I don't. What the hell. (Even using Git regularly at work, I swear this program still finds ways to completely confound me.) Still working on it, hope to have something ASAP.

Strictly speaking I can do any number, though I can't attest to how other port authors will take to having a large "reserved" block in their sound listings going completely unused before actually-used sounds. Suppose I'll have to wait and see on that. I already know WhackEd4's JSON configuration files can't handle sparse arrays like that (rather, JSON itself can't, by design), so I've had to pad it out with hundreds of "RESERVED" sound definitions - which is about as ugly as it sounds, and is presently completely visible to the end-user as such.

On the subject of other ports - PrBoom+UM is one, and Eternity will be another, but what else was there that I'll probably need to make patches/pull requests for? Doom Retro?

Double post, but I've submitted the pull request to Graf's fork. Hopefully the SNAFU with my local fork won't be hugely detrimental to his; else I guess I can figure out some way to trash my fork from GitHub and start over from the top with a fresh fork, it's not like I'm especially attached to that thing.

Sweet. I've added the 200 sounds (fre[xyz]) from 500 to 699 to EE and they'll be in 4.01.00 which should hopefully be out later today. Thanks for this.

Edit: It's out and has the sounds.

.

Useless historic update:

Found out that the ZDaemon community, in 2009, covered a different extended DeHacked proposal with a very similar name, called EXTRADEH. The principles behind it, however, seem different as the main point of EXTRADEH is to make DeHacked patches ''stackable'' using the include directive:

Fortunately the XDEHLOAD wad featured here was archived here. (Direct DL)

This is very much a nothingburger i reckon in terms of usefulness, but perhaps its interesting for someone to take a peek into this little 2009 well.

Just noting it here that my pull request has been accepted, so sound slots 500-699 now refer to DSFRE000-199 in repo builds of PrBoom+UM as well.

I know I'm late to the party (and this has mostly settled), but wanted to say that I was messing around with the DEHEXTRA extensions so far and it's pretty amazing - especially in combination with a tool like DecoHack that does a lot of the state management work for you. DeHackEd is far more comprehensible and extendible now.

I'm curious if there is any traction for additional features - I've seen a request for custom monster projectiles called out 3-4 times in this thread and want to echo that it would be a killer feature, especially if it can be parameterized to allow some angles and/or offsets to allow custom firing patterns.

I'll copy/paste some ideas that may fit to expanding DEHEXTRA from this post I've made, since here may be seen by more people:

1 hour ago, skillsaw said:

I know I'm late to the party (and this has mostly settled), but wanted to say that I was messing around with the DEHEXTRA extensions so far and it's pretty amazing - especially in combination with a tool like DecoHack that does a lot of the state management work for you. DeHackEd is far more comprehensible and extendible now.

 

I'm curious if there is any traction for additional features - I've seen a request for custom monster projectiles called out 3-4 times in this thread and want to echo that it would be a killer feature, especially if it can be parameterized to allow some angles and/or offsets to allow custom firing patterns.

I was going to ask what you meant with DecoHack - But it is part of MTrop's toolbox.

I love to see a tutorial on DecoHack, though!

1 hour ago, jval said:

I'll copy/paste some ideas that may fit to expanding DEHEXTRA from this post I've made, since here may be seen by more people:

 

  Reveal hidden contents

// New thing/mobj extended declaration

NewThing "Afrit"                                              // New thing/mobj with name "Afrit". Adds a new thing without a fixed number reference - No more need for fixed extra mobjinfo
Inheritsfrom = -1                                              // Inheritance addition
Id # = 20001
Initial Frame = NewFrame 0                             // Initial frame is a new frame, new frames are counting from 0 and are referenced by the NewFrame keyword
Hit Points = 800
Alert Sound = dsbrssit                                    // Sound name, not number, no more need for extra predefined extra sounds FRExxx. New sound names are automatically added
Reaction Time = 8
Attack Sound = 0

....

Bits = SOLID SHOOTABLE COUNTKILL NOGRAVITY FLOAT                    // BEX

....

Respawn Frame = OriginalFrame 0             // Referencing the build-in frames with the OriginalFrame keyword (could be omitted)

....

Missiletype = AfritBall                                 // Missiletype is custom field, but notice that references a thing class with it's name (AftirBall), not with a fixed number.

....

 

// New state/frame declaration

Frame NewFrame 0                                      // This is the first new frame, you do not have to worry about numbering, you start your counting from 0 - No need for fixed extra states
Sprite Number = FRIT                                   // No need for fixed/predefined sprites, the engine will automatically add sprite "FRIT" 
Sprite Subnumber = Bright 0                       // No need to add 32768 to the subnumber (maybe this is already in BEX ?)
Duration = 4
Next Frame = NewFrame 1                        // Reference next frame with the NewFrame keyword
Codep Frame = A_Look

 

....

Frame NewFrame 17
Sprite Number = FRIT
Sprite Subnumber = Bright 6
Duration = 6
Next Frame = NewFrame 6
Codep Frame = A_CustomMissile "AfritBall" "44" "1" "0"    // Actions can also have parameters, no more dependency/limit of "Unknown 1" & "Unknown 2" (A_CustomMissile(missiletype, height, offset, angle....)
 

SubmitNewFrames                                      // The SubmitNewFrames keyword is used to reset the new frame counter, it is done automatically at the end of the DEHACKED file and can be omitted , but may be used if you want to reset the counter inside the same file.

 

You did mention that FPCDoom has had a strong DeHacked extension before. I'd love to read more about this :)

1 hour ago, Redneckerz said:

You did mention that FPCDoom has had a strong DeHacked extension before. I'd love to read more about this :)

Most of the extensions are described in the quoted example above. A lot of these additions could fit the DEHEXTRA extensions, such as:

• Referencing new sounds with it's lump name (or even with an alias, using SNDINFO lump) - no need for FRE000 etc, no limit to only 200 new sounds
• New sprites as 4 character string, the engine will automatically attach a number internally, and transparently from the user. No limit of only 100 new sprites
• Dynamically adding new things/actors with the NewThing keyword (instead of Thing keyword). Next word will be the thing's name, not a number. The engine will attach internally a number. No limit of only 100 new things.
• Dynamically adding new states with the NewState/NewFrame keyword (instead of State/Frame keyword). Next word will be a number, starting for 0 (reset within the same DEHACKED file with the SubmitNewFrames keyword). The engine will attach internally a number. Reference of standard frames with the OriginalFrame keyword, that can be omitted. Reference new frames with the NewFrame keyword that can not be omitted.
• Additional fields, additional code-pointers with as many parameters  you like (in addition DelphiDoom and RAD allow complex expressions as parameters), without the limit of Unknown1 & Unknown2 (i.e. only 2 extra and static parameters).

I've been out of the Doom loop for a while, and was curious if anything had changed in terms of interport modding and scripting. Seeing that an enhanced form of DEHACKED not only exists, but has been adopted by a large number of ports has me really excited! Besides a generic projectile function, and @jval's proposal for further enhancements, there's only a few things I'd like to see added, mostly related to weapons:

• Enhancements to the ReFire function using the existing Unknown1 and Unknown2 flags. The first is the ability for ReFire to jump to a specified frame # instead of to the first frame in the Fire state. This is for weapons like the Gauntlets from Heretic, which have a brief wind up before firing.
• The second enhancement is the NOFIRE and NOFIRE_RETURN functions from EDGE added to the ReFire function. The first works like the opposite of the ReFire function: if the player is not holding the fire button, the weapon immediately returns to the Idle state. NOFIRE_RETURN does the same, but remembers the last frame the weapon was on during the Fire state and returns to it when the player fires again. This would allow for weapon behavior similar to the Super Nailgun from Quake, or the primary fire on Blood's shotgun, which alternates barrels before reloading.
• A generic CheckReload function that checks the remaining ammo for the current weapon. This would be handy for burst fire weapons that aren't the Chaingun. This could also be expanded via the Unknown1 or Unknown2 flags to specify a frame # to go to when there isn't enough ammo to fire.
• A generic PlaySound function. This may already exist, as I haven't had a chance go over all the new features introduced by DEHEXTRA.

I know how much programmers love random feature wishlists, so I'll stop here. :V Even without any new functionality, the possibilities provided by extra frames and things is exciting enough.

Those two unknown fields control the weapon sprite offset. It's not an extremely useful feature, but I know of at least one mod that put it to use: InstaDoom.

Huh, I never realized that! What I proposed would require additional flags, and I'm not sure how likely those are to be implemented.

IIRC it's also used in a few mods to make weapon switching faster. I think Rowdy Rudy uses this trick, notably. This makes the ReFire suggestion moot, because weapon codepointers are the ones that cannot be allowed to make use of these fields for secondary purposes.

Excuse the self-promotion, but I'm just chiming in to say that DECOHack supports DEHEXTRA, including the additional sounds.

As far as Function Pointers are concerned, maybe an A_ProjectileAttack that uses the first parameter to specify the thing ID to spawn as a projectile?

Also, maybe an A_ProjectileFire as the player weapon variant?

And an A_WeaponSound for a weapon-friendly A_PlaySound?

You'd probably have to be careful to not use a mnemonic already in use in other Source Ports to ensure easy backporting.

The best way to resolve the misc1/misc2 conflict for parameterized weapon action functions is simply to skip setting the offsets if a state uses one of these new functions (i.e. build a "blacklist" of action pointers; if it's one of those, skip setting the offset). I took a quick peek at prboom-plus's source, and it wouldn't be hard to do this at all.  

All that said, it feels lazy of me talking about this rather than actually writing code. Maybe I'll tinker with some things when Texas un-freezes. :P

In addition to MTrop's suggestion, I would love a feature that would allow multiple projectiles to be spawned at once.

23 minutes ago, JXC said:

In addition to MTrop's suggestion, I would love a feature that would allow multiple projectiles to be spawned at once.

Although it would be useful, if an A_ProjectileAttack(thing id, horizontal angle) code pointer were implemented, you could also fire multiple projectiles in the same instant by using multiple 0 duration states in a row - which would probably be the preferred approach, since it's only possible to provide two parameters.

1 hour ago, skillsaw said:

 

Although it would be useful, if an A_ProjectileAttack(thing id, horizontal angle) code pointer were implemented, you could also fire multiple projectiles in the same instant by using multiple 0 duration states in a row - which would probably be the preferred approach, since it's only possible to provide two parameters.

That sounds great! I also would like to see the speed of A_SkullAttack be dehardcoded.

Sorry to bump an old thread, but is this still open to suggestions for the MBF21 implementation? I may have some suggestions (if they're feasible/appropriate for the standard).

Can we put some sort of edit on the first post of this thread that includes known DEHEXTRA wads or something? That would be very useful to know in the early days of this new standard

I am happy collating examples if people have them. I know of Black Ops and SMOOTHED, but everything else is WIP afaik.

My mod used dehextra if that helps.

17 hours ago, Altazimuth said:

I am happy collating examples if people have them. I know of Black Ops and SMOOTHED, but everything else is WIP afaik.

While it is experimental it doesn't really use them to a full extension the new monsters added could might as well be deployed as a replacement of the wolf ss and nobody would have been wiser, but it's still an attempt

Now that MBF21 is out there, DEHEXTRA has become even more important with it's extended capability to support the various new introduced features. However, after more than 3000 lines of DECOHack code I've come to notice that while DEHEXTRA was a welcome addition to the DeHackEd scene of old, it is woefully incomplete in properly supporting the kind of capabilities introduced in MBF21. This is made even more apparent by the ease of modification made possible by software like DECOHack, which makes more complex edits and experiments possible with a fraction of the time compared to something like Whacked.

With the introduction of a generalized spawn and projectile codepointers, things like complex projectile attacks, projectile trails, particle effects and other behavior more commonly used in DECORATE are now made available to modders. The demand for Things and Frames for these kind of effects can become quite extensive. For example, creating a working version of the Diabolist (as implemented in tango's Supercharge) would require 8 additional Things just to create a proper timing for the attack (assuming the Diabolist was implemented alongside the Arch-Vile, and not as a replacement), and this is even before any particle effects are introduced into the mix. Due to the lack of direct value randomization in MBF21, each "randomized" variant of an effect needs to have it's own set of Frames or Things, reachable by the different Jump functions.

Now you might read this and say "just don't use all those fancy effects", but I feel like the purpose of DEHEXTRA and MBF21 were to make possible, to a degree, "limitless" editing within the confines of what was sensible to implement. Hence I'd like to know if it was possible to extend the already extended DEHEXTRA with even more additional Things, Frames, Sprites and Sounds to better cater to this new standard? Were the current numbers (initially introduced in Doom Retro as I understand) just educated guesses on how many Frames/Things/Sounds people would need in practice, or are there some practical and non-arbitrary limitations to how many new ones can be added? The original DeHackEd limits were mostly due to actual limitations in game itself, but since the idea behind DEHEXTRA was to add more substance to work with, should the arbitrary limit be pushed further now as new functionalities have been made available?

Here's a few observations based on a few weeks spent intensively working with MBF21:

• Thing slots are the worst offender, and I feel they should be extended not just by a few hundred, but as far as it is sensibly possible to extend them. This is based on the aforementioned assumption that the original DEHEXTRA additions were made to create practically "limitless" capabilities, which made sense considering the tools available at the time. Projectiles, trails, randomized things and ambient sounds all need Thing slots, and can easily eat up the current set before you know it.
• Frames come a close second, but not quite as glaring since many effects can be made using the same Frames, but with different Thing properties. Ultimately I think both Things and Frames are important because you can optimize one with the other, and possibly in my case I happened to optimize Frames with Things, causing the shortage on that side to appear first. But like with Things, I'd like to see these extended as far as practically and sensibly as possible.
• Sprites and Sounds aren't quite as critical (coming from someone who has very liberally been using sound effects), but if extensions were to be made I think these would warrant some additions as well, for the sake of future proofing.

I'm honestly not sure what the current mood is around DEHEXTRA, specifically ideas around it's possible extension, but I thought I'd drop in some thoughts. I guess there are things could that could be done on MBF21's side to appease some of these issues as well, but at this point I think the easier and more sensible thing would be to further extend the extended limits of DEHEXTRA.

24 minutes ago, Aurelius said:

Now you might read this and say "just don't use all those fancy effects", but I feel like the purpose of DEHEXTRA and MBF21 were to make possible, to a degree, "limitless" editing within the confines of what was sensible to implement.

"Limitless" and "sensible" are antinomic notions.

The thing is that Doom is built around a fixed-size state table. To extend that table, you can either make a bigger table, or you can change it into a dynamically-sized table.

DEHEXTRA does the former. For the latter, you want DECORATE.

Sure, you could have a DEHSUPRA format with a static table containing ten thousand extra frames. Why not. A state is what, something like seven values in vanilla? Sixteen with the MBF21 addition of a bitfield flag and eight parameter values? All of them are on four bytes, so that's 640k extra size for your executable just to store the enlarged frame table...

Ultimately I think the issue is that if you grow the offer, you grow the demand even more. Any "sensible" size will be reached immediately, especially when they get swallowed extra-fast by hacks such as:

43 minutes ago, Aurelius said:

Due to the lack of direct value randomization in MBF21, each "randomized" variant of an effect needs to have its own set of Frames or Things, reachable by the different Jump functions.

Wouldn't it be better to obtain support for direct value randomization (perhaps in MBF22) than to encourage code duplication with minor changes in this way?