DEHEXTRA discussion (split from Pr+ UMAPINFO thread)

[Aurelius]

3 hours ago, Gez said:

"Limitless" and "sensible" are antinomic notions.

 

Heh, true. It was a not-that-good of an attempt to convey that I understand DEHEXTRA and MBF21 are intentionally pushing past limits and extending the capabilities of DeHackEd, but at the same time when pushed far enough you might as well consider using a more advanced format for defining content, like DECORATE or EDF. MBF21 was never meant to go that far, but I don't think it means we can't reconsider the structure of DEHEXTRA to better suit the new format.

 

The reason I brought this up is that DEHEXTRA was made in the absence of MBF21, and hence was likely pictured to be used for much less ambitious modifications (and therefore be sufficient for that). My interpretation for the ethos behind DEHEXTRA was that the number of frames/things etc. available would be made practically a non-issue, which did seem to work fine. Maybe I'm wrong about that, and there was some other reason behind the particular numbers for extensions beyond an educated guess, but reading your message makes me think it wouldn't have been detrimental if it was, say, a 1000 new Things instead of a 100. 

 

3 hours ago, Gez said:

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

 

I used the word "sensible" just for this reason, because you can keep extending and enhancing, and the demand will never stop; you can always pine for new features. How much is "enough" is ultimately a choice the community makes, or at the very least source port devs who work the support into their ports. To put it into practical terms, I'd personally be happy with, say, a 1000 things and 10000 frames, but I wanted to open some discussion on it to find some common ground on how much of an extension would be a good compromise - or if there's even any demand for it. I'm perfectly fine with adhering to the limitation DEHEXTRA currently has, but I thought opening a discussion about it would be good, even if no extensions to DEHEXTRA were ultimately made.

 

3 hours ago, Gez said:

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?

 

I considered this (and mentioned it briefly at the end of my post), but given how recent MBF21 is it's unlikely there's gonna be an MBF22 in the near future (at least before 2022 if the naming convention is any indication :P). I thought that this would be a more fruitful attempt - especially since I personally think DEHEXTRA could be updated to better match MBF21, and any other possible new versions like MBF22. EDIT: I also thought that if direct value randomization was viable to implement it would already have been added with MBF21, considering how useful it is. Which made me think there was probably a reason it was omitted.

Edited June 28, 2021 by Aurelius

[GoneAway]

I plan on removing limits entirely in dsda-doom in the future (by the end of the year for sure), and I would personally vote for this as opposed to continuously pushing the goal posts forward every time someone hits the wall. BUT that's just me. It could be more of an issue to implement such a feature in other ports.

[Redead-ITA]

1 hour ago, kraflab said:

I plan on removing limits entirely in dsda-doom in the future

While i don't think that is a bad idea, i don't think we should try to make decorate obsolete either but thats just me.

hell even going for a end of a year deadline sounds Quite an objective, i would assume at least maybe by 2022.

[ChopBlock223]

Say, would it be at all possible to add features to enable Duke Nukem 3D style reloading? Like, so one could define a value on any weapon, and then make it so after, say, every 10 shots you fire with the Pistol, or every 50 shots with the Chaingun, they stop to do a reload animation before resuming firing?

 

Doesn't use a reload key, doesn't take ammo out of the regular pool and put it into a defined magazine, the Pistol still uses the Clip pool like normal, and shows that counter on the HUD as normal.

Effectively I'd like to use it to make guns have a brief cooldown, so that the Pistol can shoot pretty fast, and you can hold down fire, but it must stop to do a short animation before it can shoot again. That way a Pistol can be made a lot more useful and satisfying, but it doesn't get to be like a machinegun.

 

Could this be done to Extended DeHacked without affecting PRNG or demo compat? I can imagine quite a lot of different purposes for such a feature, aside from making the player's weapon reload, maybe a monster could too, but maybe it could also be used to make a weapon which has to be charged up before firing, or potentially a monster which will charge at the player if they go to their painstate enough times.

[TheMightyHeracross]

2 hours ago, Redead-ITA said:

While i don't think that is a bad idea, i don't think we should try to make decorate obsolete either but thats just me.

hell even going for a end of a year deadline sounds Quite an objective, i would assume at least maybe by 2022.

That would absolutely not, remotely, in any way make DECORATE obsolete. Like, not even close. In DECORATE you have the inventory system, player classes, new weapons and ammo types, altfires and reloading, ACS calls, damage types, customizable powerups... all sorts of fancy scripting and shit that even unlimited DEHACKED frames could ever remotely replicate. All this would do is let people add new monsters and decorative things, like what DEHEXTRA already does in the first place.

 

1 hour ago, ChopBlock223 said:

Say, would it be at all possible to add features to enable Duke Nukem 3D style reloading? Like, so one could define a value on any weapon, and then make it so after, say, every 10 shots you fire with the Pistol, or every 50 shots with the Chaingun, they stop to do a reload animation before resuming firing?

 

Doesn't use a reload key, doesn't take ammo out of the regular pool and put it into a defined magazine, the Pistol still uses the Clip pool like normal, and shows that counter on the HUD as normal.

Effectively I'd like to use it to make guns have a brief cooldown, so that the Pistol can shoot pretty fast, and you can hold down fire, but it must stop to do a short animation before it can shoot again. That way a Pistol can be made a lot more useful and satisfying, but it doesn't get to be like a machinegun.

 

Could this be done to Extended DeHacked without affecting PRNG or demo compat? I can imagine quite a lot of different purposes for such a feature, aside from making the player's weapon reload, maybe a monster could too, but maybe it could also be used to make a weapon which has to be charged up before firing, or potentially a monster which will charge at the player if they go to their painstate enough times.

This on the other hand is 100% scope creep. There's a port for what you want already (compatibility + scripting), and it's called the Eternity Engine.

Edited June 29, 2021 by TheMightyHeracross

[Snarboo]

2 hours ago, ChopBlock223 said:

Say, would it be at all possible to add features to enable Duke Nukem 3D style reloading? Like, so one could define a value on any weapon, and then make it so after, say, every 10 shots you fire with the Pistol, or every 50 shots with the Chaingun, they stop to do a reload animation before resuming firing?

The best way of handling this would be through a set of "counter" action pointers (perhaps Set Counter, Add to Counter, etc), paired with another action pointer that jumps to a specific frame state if the Counter is a specific value. That way, it could also be used by weapons and monsters! Whether that's considered feasible or worth adding is another question, however. :p

[ChopBlock223]

1 hour ago, Snarboo said:

The best way of handling this would be through a set of "counter" action pointers (perhaps Set Counter, Add to Counter, etc), paired with another action pointer that jumps to a specific frame state if the Counter is a specific value.

That would be a much more versatile implementation, and similar to how I do things in Decorate, but I have no idea if that'd create issues with demo syncing.

One could say "just use GzDoom then," but that port seems to be increasingly demanding in hardware specs, doesn't have good demo support, and would seem overkill for what's (in my eyes), a pretty small change.

People also don't seem to want to play GzDoom mapsets as much as Boom/MBF ones.

 

1 hour ago, Snarboo said:

That way, it could also be used by weapons and monsters! Whether that's considered feasible or worth adding is another question, however. :p

Won't know if I don't ask :D

[MattFright]

Since i haven't seen anyone brought it up in a while, is there any interest from the devs working on this to expand DEHEXTRA support for Heretic? Given that Heretic doesn't have any widely compatible way to mod it and the only way to do it is through ZDoom family ports, and the fact that DSDA Doom added support for Heretic, i feel like this would be a great time to see it happen if ever.

 

And i'm not asking for the sake of it either, i'd probably spend a good few months working on a huge project if this came to be, i only haven't delved too much into Heretic yet because i really don't want to have to fall back on (G)ZDoom only given a few gripes i have with those ports, and i don't want to just make maps with plain unmodified Heretic either...

Edited July 4, 2021 by MattFright

[Snarboo]

46 minutes ago, MattFright said:

Seeing that i haven't seen anyone brought it up in a while, is there any interest from the devs working on this to expand DEHEXTRA support for Heretic?

I've been wondering this myself, and it's something I've been wanting for ages, too! It'd be nice to have an interport standard that works for both games, and even allows Heretic functions in Doom and vice versa. If that's not feasible, a separate HEREXTRA would be fine, too. :p

[Gez]

The way that would be the easiest to implement for ports like GZDoom and Eternity would be to simply add the Heretic actors, states, and codepointers to DeHackEd, and then make DeHackEd functional in Heretic mode.

 

Beneficial side effect is that it would also make these effects available in Doom.

 

Though if we go this way it might be worth to address the issue of sprite name conflicts, and how ZDoom does some behind-the-scene renaming (e.g. Heretic's HEAD are changed to LICH) because it could be a potential conflict point.

[GoneAway]

8 hours ago, MattFright said:

Given that Heretic doesn't have any widely compatible way to mod it and the only way to do it is through ZDoom family ports, and the fact that DSDA Doom added support for Heretic, i feel like this would be a great time to see it happen if ever.

Keep in mind that dsda-doom has no dehacked support for heretic at all, so applying dehextra there is actually not possible currently. I don't think it makes sense to work on more than one cross-port standard-pushing effort at a time, as we want to make sure the port and tool community can comfortably keep pace. Once mbf21 support has been well-established, Xaser and I might start looking into a new standard for heretic next...

[GoneAway]

On 6/29/2021 at 5:52 PM, kraflab said:

I plan on removing limits entirely in dsda-doom in the future (by the end of the year for sure), and I would personally vote for this as opposed to continuously pushing the goal posts forward every time someone hits the wall. BUT that's just me. It could be more of an issue to implement such a feature in other ports.

Had some time this weekend so I decided to take care of this. The next release of dsda-doom will support infinite things, states, sfx, and sprites (already merged into master). Well, until you run out of memory or hit the limit of dehacked indices 😸

 

You can see an example of the abstraction here (other entities are the same with slight variations): https://github.com/kraflab/dsda-doom/blob/master/prboom2/src/dsda/state.c

 

As I said previously, I can't vouch for how other ports manage things and states, but it shouldn't be a huge problem in general. That's my 2 cents.

[RonnieJamesDiner]

1 hour ago, kraflab said:

The next release of dsda-doom will support infinite things, states, sfx, and sprites (already merged into master).

 

[Redneckerz]

3 hours ago, RonnieJamesDiner said:

 

As someone who is bingewatching Star Trek Generations once more on NetFlix, i approve of any William Riker gif posted on DoomWorld.

 

Legendary man. Could've been DoomGuy's mentor.

[Gibbon]

9 minutes ago, Redneckerz said:

As someone who is bingewatching Star Trek Generations once more on NetFlix, i approve of any William Riker gif posted on DoomWorld.

 

Legendary man. Could've been DoomGuy's mentor.

I'm bingeing Voyager, but hey I grew up on that one.

Edited August 15, 2021 by Gibbon

[Redneckerz]

56 minutes ago, Gibbon said:

I'm bingeing Voyager, but hey I grew up on that one.

I binged that last year, and yes, grew up on it aswell.

 

I say there is coffee in that nebula. ;)

[GoneAway]

https://www.doomworld.com/forum/post/2370413 released here.

[NoWits]

On 7/27/2020 at 10:50 AM, NiGHTMARE said:

Silly question, but does Crispy's DEHEXTRA support also include all of MBF's DeHackEd extensions, i.e. the new flags such as BOUNCY and the action function parameters?

 

On 7/27/2020 at 6:17 PM, Shadow Hog said:

I believe it is intended to extend BEX, which should have all of those things (the extra action specials at least), so, yes?

 

No, it does not, and neither does Doom Retro. I made a video to demonstrate:

 

 

Example .BEX file attached, plus in the video description.

 

Not sure if there are plans to implement these or fix for MBF compatibility, but it means if you want to use these features then the only popular source port your WAD will work on is PrBoom+, which kinda defeats the purpose of using DeHackEd/BEX over something port-specific like DECORATE or EDF.

 

(On a side note, the Mushroom codepointer only works properly in PrBoom+ with -complevel 11. On default settings the speed and angle parameters are ignored, so the mushroom fireballs always shoot straight up.)

BouncyNotWork.bex.zip

Edited October 21, 2021 by NoWits
fix missing word, attach bex

[VGA]

Main purpose of DEHEXTRA was to overcome the very limited number of unused frames and things. 

[Redead-ITA]

1 hour ago, VGA said:

Main purpose of DEHEXTRA was to overcome the very limited number of unused frames and things. 

And also adding a lot of audio files, or was that from MBF21?

[NoWits]

21 hours ago, VGA said:

Main purpose of DEHEXTRA was to overcome the very limited number of unused frames and things. 

 

If DEHEXTRA includes and supports MBF thing flags (which it does), then those source ports that claim to be DEHEXTRA-compatible should implement those thing flags.

[NiGHTMARE]

On 10/22/2021 at 12:02 AM, NoWits said:

 

 

No, it does not, and neither does Doom Retro. I made a video to demonstrate:

 

 

Example .BEX file attached, plus in the video description.

 

Not sure if there are plans to implement these or fix for MBF compatibility, but it means if you want to use these features then the only popular source port your WAD will work on is PrBoom+, which kinda defeats the purpose of using DeHackEd/BEX over something port-specific like DECORATE or EDF.

 

(On a side note, the Mushroom codepointer only works properly in PrBoom+ with -complevel 11. On default settings the speed and angle parameters are ignored, so the mushroom fireballs always shoot straight up.)

BouncyNotWork.bex.zip

 

Thanks for that! GZDoom should be fine for most things, too - it's missing some of MBF's codepointers (although it has its own equivalents), but supports its flags.

 

EDIT: Good to know Retro does support the BOUNCY and FRIENDLY flags, as they're the main reason I asked :)

Edited October 25, 2021 by NiGHTMARE

[Gez]

Crispy is not supposed to be Boom- or MBF-compatible AFAIK.

 

Doom Retro on the other hand probably ought to fix the issues.

[maxmanium]

5 minutes ago, Gez said:

Crispy is not supposed to be Boom- or MBF-compatible AFAIK.

 

Right, it supports the BEX format but not any new codepointers.

[bradharding]

Hi @NoWits, the issues regarding the bouncy flag for the beta BFG will be fixed for the next version of DOOM Retro. I'll point out though, that if you test in PrBoom+ further (perhaps in a larger area), the projectiles don't bounce either. That's because in info.c PrBoom+ sets both the NOGRAVITY and BOUNCES flags for thing 141 and 142. But things can't bounce if they have no gravity. So DR will remove the NOGRAVITY flags by default in the same file, and then if you remove the NOGRAVITY flag from your .bex file everything works as expected.

[Gibbon]

One thing I'll point out (I am glad nobody raised it) but for ReBOOM Experimental I included the Bouncy and Touchy flags as it was in the spec but these aren't in the code as functionality.  So those won't work at all.  At least I don't think so..  I'll have to look as I haven't touched it in a month, it's probably full of bugs though.  Beta BFG is also not there.

Edited October 30, 2021 by Gibbon