DEHEXTRA discussion (split from Pr+ UMAPINFO thread)

[Ferk]

Would a "Missile Chance Multiplier" as a new field be suitable?

 

It might make more sense than the flags MISSILEMORE(ZD) / HIGHERMPROB (EE) (which are 2x multiplier like vanilla) which ZDoom also awkwardly further increased with a "MISSILEEVENMORE" ^^U

[esselfortium]

 

3 hours ago, Redneckerz said:

Boom Plus has a nice ring to it :) If that is going to be the defacto name sake for ports that support these extended features (Which is Retro, Crispy, PrBoom Plus UM, GZDoom and Eternity) then i have to ask: When can this be set in stone? I realize that you need most of the authors involved to be in agreement with this.

I don't think I was the person to originally coin "Boom+", but it's been a long time now so I can't remember. I've just been using it as a term for the ever-evolving cross-port standard that still tends to be referred to as "Boom format" or "Boom-compatible" but which really means "works in PrBoom+, ZDoom, and Eternity", which makes it a (slowly-)moving target rather than something set in stone. Over the past 15 years or so it's grown to encompass at least these things:

· Doubled sidedefs limit using the lower half of the unsigned field, and doubled segs limit in the same way

· MBF sky transfer lines (and arguably the other MBF stuff too, nowadays)

· DeePSea tall patch format support

· ZDBSP extended nodes format

· Music-changer things

· Probably some other additions I've forgotten about at this point

 

And now UMAPINFO and EXTRADEH :)

[Altazimuth]

5 minutes ago, Ferk said:

Would a "Missile Chance Multiplier" as a new field be suitable?

 

It might make more sense than the flags MISSILEMORE(ZD) / HIGHERMPROB (EE) (which are 2x multiplier like vanilla) which ZDoom also awkwardly further increased with a "MISSILEEVENMORE" ^^U

I've been wanting to make this settable as a number via EDF anyway. Varies on what the other folks think I spose.

 

 

[Shadow Hog]

I think the only flag I currently really want, one that I know both EE and GZDoom have something for, is a flag to make sight/deathsounds full-volume when played, a la Cyberdemon/Spider Mastermind/Oremor Nhoj.

[Da Werecat]

Death is easy, just use custom MBF action for playing sounds. Sight - I don't know, doing the same sounds hacky to me, requires some testing.

[ReaperAA]

On 7/10/2020 at 11:43 PM, Da Werecat said:

Suggestion: infinite ammo with non-melee attack codepointer = shouldn't subtract ammo from anywhere. A weird omission in BEX patches, since it shouldn't be that hard to implement.

 

I would love to see this.

[Da Werecat]

On 7/10/2020 at 9:52 PM, esselfortium said:

It'd definitely make sense to have some new entries in the Misc section to get around some of Doom's hardcoded weapon behaviors, like the fact that the BFG and rocket launcher weapon slots don't auto-fire like other weapons.

 

I don't know about Misc, more like I thought it would be useful to simply make it work by default, provided that the dehacked entry is of the expanded type. I actually tried to imagine a way to abuse the behavior of subtracting the max shells counter until it's in the negatives, but I'm yet to come up with something non-broken.

 

Auto-fire is EZ though, just mix some ReFire into WeaponReady, much like one would do when disabling the first precise pistol/chaingun shots. Wasn't sure it would work, but tested it just now.

 

Of course, as with many hacks, an additional state is wasted.

[Altazimuth]

Making any behaviours different by default isn't a good idea IMO. It invariably breaks old shit.

[esselfortium]

1 hour ago, Da Werecat said:

Auto-fire is EZ though, just mix some ReFire into WeaponReady, much like one would do when disabling the first precise pistol/chaingun shots. Wasn't sure it would work, but tested it just now.

 

Of course, as with many hacks, an additional state is wasted.

Woah, good catch :)

[bradharding]

@VGA is yet to provide his input on what to call these extensions, but it was Boom that provided the BEX (Boom EXtended) extensions for DeHackEd support, so I propose we call this new set of extensions "REX (Retro EXtended)". Thoughts?

[Da Werecat]

8 hours ago, Altazimuth said:

Making any behaviours different by default isn't a good idea IMO. It invariably breaks old shit.

 

Wouldn't extending the feature set already break things? Old behavior should be used with old spec patches.

[VGA]

On 7/10/2020 at 11:39 AM, fabian said:

Well, the initial implelentation of this can be found in Doom Retro and it was added there to be able to load both of VGA's "Smoothed" and "Black Ops" mods at the same time, IIRC. 

Black Ops (smooth weapon animations) uses the MBF extensions to Dehacked, I had to ask Brad to add the extra states from MBF in 2015

https://github.com/bradharding/doomretro/issues/125

 

 

Then after that mod was completed I got more ambitious but I realised SMOOTHED (smooth monster animations) could never be possible without hundreds and hundreds of extra states so I asked Brad to add that stuff to Doom Retro and around September he added thousands of them.

https://github.com/bradharding/doomretro/commit/17d2cb772f0f42e15832ec2ace8757ef94e30859

 

Then I needed more sprite names

https://github.com/bradharding/doomretro/issues/232

 

Then I needed more things

https://github.com/bradharding/doomretro/issues/249

 

With his work and after toiling away for hours at a time in Whacked, the result was pretty impressive IMO!

 

As for the name, I think DEHEXTRA sounds good and generic (I have been calling them extra states all along) and I hope more ports add support, since it is not very hard and doesn't mess with compatibility. I hope even prboom and ZDoom add support so projects using the extra states are compatible with every active port higher than Chocolate Doom. Someone said something about Eternity in one of my threads, I will check that out now.

 

 

[Ferk]

15 minutes ago, VGA said:

Black Ops (smooth weapon animations) uses the MBF extensions to Dehacked, I had to ask Brad to add the extra states from MBF in 2015

https://github.com/bradharding/doomretro/issues/125

Brad's commit there includes not only MBF but also the S_PLAY_GDIE1 to S_PLAY_GDIE9 that Eternity didn't add, I think (or at least Gez suggested him to mark as "RESERVED -- DO NOT USE" and disallow them from dehacked).

Does Black Ops use those?

Edited July 12, 2020 by Ferk

[VGA]

12 minutes ago, Ferk said:

Brad's commit there includes not only MBF but also the S_PLAY_GDIE1 to S_PLAY_GDIE9 that Eternity didn't add, I think (or at least Gez suggested him to mark as "RESERVED -- DO NOT USE" and disallow them from dehacked).

What are they? Are they from MBF's dehacked additions?

 

EDIT: Oh, it's "prboom-plus player gibbed death"

[Gez]

1 hour ago, VGA said:

What are they? Are they from MBF's dehacked additions?

No. If they were, they'd be part of the standard, like the extra states for beta BFG, dogs, beta plasma balls, extra bonus items, and whatever else there might have been.

 

The GDIE stuff is a PrBoom+ Easter egg.

[Redneckerz]

4 hours ago, VGA said:

As for the name, I think DEHEXTRA sounds good and generic (I have been calling them extra states all along) and I hope more ports add support, since it is not very hard and doesn't mess with compatibility. I hope even prboom and ZDoom add support so projects using the extra states are compatible with every active port higher than Chocolate Doom. Someone said something about Eternity in one of my threads, I will check that out now.

So you used Whacked to addresss these extra states and pointers?

 

If nobody else objects or suggests otherwise, lets call it DEHEXTRA then.

Edited July 12, 2020 by Redneckerz : Mobile typo's

[Altazimuth]

@Ferk I added the states, I just didn't add the few mobjs before the official "extra" mobjs since there was clashing between Retro and PR+.

[esselfortium]

For a 3-letter DEHEXTRA abbreviation like DEH and BEX, how about DHX?

[Tango]

I am really stoked about this effort. having a generic projectile-firing codepointer would be huge. don't know if it's already been brought up, but having something similar for player weapons would be most welcome too, and would alone open up a ton of potential for weapons. having the ability to set pitch on either the monster or weapon variants somehow would be swell too, but even without that, a generic projectile function would be amazing

[esselfortium]

3 minutes ago, Tango said:

I am really stoked about this effort. having a generic projectile-firing codepointer would be huge. don't know if it's already been brought up, but having something similar for player weapons would be most welcome too, and would alone open up a ton of potential for weapons. having the ability to set pitch on either the monster or weapon variants somehow would be swell too, but even without that, a generic projectile function would be amazing

Setting pitch is a tough one because there are only the misc1 and misc2 fields, one of which has to be used to determine which mobj type should be used as the projectile. I suggested horizontal angle offset as misc2 since it seemed like the most useful one to have (for mancubus-style spread attacks and such). Adding additional parameter fields to the standard might be worth considering, though, especially if we're already considering an additional flags field.

[Redneckerz]

2 hours ago, esselfortium said:

For a 3-letter DEHEXTRA abbreviation like DEH and BEX, how about DHX?

I was going to say DEX, but that sounds too similar to BEX. DEHEX/DHEX are longer, but the former sounds too much like DeHackEd (Which might be a good thing) and DHEX might be confused with the executable name used in DOS builds of Hacx (Which was called DHACX.)

DHX is a nice one:

• Shortening of DeHacked eXtensions
• Makes it clear its something extra/additional next to DEH
• Is a good name for documentation and/or a possible format

So i wonder how @VGA Fabian or Brad see this, but the DHX abbreviation has my vote. :)

 

[Tango]

1 minute ago, esselfortium said:

I suggested horizontal angle offset as misc2 since it seemed like the most useful one to have (for mancubus-style spread attacks and such).

 

definitely, that seems a lot more useful than pitch in most cases. I guess I didn't really have an idea of how a third (or more) parameter might be implemented, but I wouldn't say no to additional parameter fields :^) some of the other MBF codepointers (maybe just A_Mushroom?) use things like the actor's pain chance for additional "parameters", but that's a wacky solution and additional parameters would definitely be preferable. but at the same time... I understand the desire to keep things simple.

 

the reason I thought of pitch specifically is that there were some cool things I thought I would be able to do with the existing A_Mushroom codepointer but couldn't due to all of its dumb hardcoded behavior. but I guess the nature of an intentionally more simple system, especially compared to things like DECORATE and EDF, means that there will inevitably always be modders down the road thinking if only they implemented XYZ when they designed this new spec

[VGA]

7 hours ago, Redneckerz said:

So you used Whacked to addresss these extra states and pointers?

 

If nobody else objects or suggests otherwise, lets call it DEHEXTRA then.

I created a new Whacked preset (it is a text file format, json maybe?) and used an Autoit script to programmatically create the state definitions, all those thousands of entries resulted in an unwieldy big file but it worked. Later, I explained the additions to Whacked's author @exl and he created a more proper "Doom Retro" preset for the next update since it was the only port for it.

 

Is a new file extension needed? I don't see why. I don't want to add unneeded overhead to ports and launchers.

[Redneckerz]

5 minutes ago, VGA said:

I created a new Whacked preset (it is a text file format, json maybe?) and used an Autoit script to programmatically create the state definitions, all those thousands of entries resulted in an unwieldy big file but it worked. Later, I explained the additions to Whacked's author @exl and he created a more proper "Doom Retro" preset for the next update since it was the only port for it.

 

Is a new file extension needed? I don't see why. I don't want to add unneeded overhead to ports and launchers.

Excellent explanation, thank you.

 

I agree that a whole new format is not needed, but perhaps the Whacked preset (Doom Retro) bears more explaining in what you can do with it?

 

I definitely need to download Whacked4 and take a look aswell.

 

Aside that, what do you think of Essels abbreviation?

 

[Shadow Hog]

3 hours ago, VGA said:

Is a new file extension needed? I don't see why. I don't want to add unneeded overhead to ports and launchers.

If it's anything like BEX, it's not really a new file extension, so much as a way to easily indicate to human readers what format DEHACKED file it is without them having to open it up and compare header numbers. The ports would only care about that header, and the launchers... well, okay, they might need to add one more file type, sure, but at the same time IIRC the launcher I occasionally used didn't even support DEH (you'd have to forcibly add it with "All Files (*.*)"), so no loss there. (At least, I think ZDL didn't. I'm going to have to check that now and suddenly learn I must eat crow, aren't I.)

[Shadow Hog]

Double post, but I suppose I should ask this now rather than get my head bitten off later: is DSFRExxx a good lump name for the added sound effects, or have we settled on some other standard already? I'm mostly just using that since it's what SRB2 used when it did its own DEHACKED equivalent's similar expansion a few years ago. I noticed the new sprites are SPxx, but I'm not sure if that's because they're "SPecial", or because they're of type "SPrite" or what. If it's the latter, maybe DSSNDxxx would be better (although I suspect the "DS" prefix is enough of a hint).

 

FWIW I have a compile of PrBoom+UM that implements 140 new sounds (again, chosen to round the number of SFX slots up to a nice round 255). It's working well with my test case of the Half-Life VOX counting down every two seconds from 140. Kinda want to tweak it a bit more before releasing it though.

[Altazimuth]

Well in terms of collisions looking here at sounds.h in EE there appears to be a nice big gap in the sfx from 127 all the way to 299 (inclusive). Before that it's EE sounds (which could be moved without huuuuge issue I suppose since it's just 13 sounds) and after that is Heretic sounds (100+ sounds) so my personal preference would probably be to occupy 100 sounds from 156 to 255 or something (150 from 150 to 299?), since I'd want extra space to expand the EE sounds list without having to have them all split up. I dunno if having non-contiguous sounds is a problem for PRB+ though. If it is then the EE sounds could probably be moved without too much issue.

 

On 7/12/2020 at 7:59 AM, Da Werecat said:

Wouldn't extending the feature set already break things?

Sorry, didn't see this before. Not really? It would only break already-broken deh patches. I've extended feature sets countless times to EE without breaking anything older, but defaults for externally-facing modding stuff are effectively set in stone. To change the defaults for dehacked would mean breaking vanilla, Boom, and MBF compat.

Edited July 15, 2020 by Altazimuth

[Da Werecat]

How would they break if it will only work with the new spec patches?

 

Or will the new spec patches be exactly like the old patches including DEHACKED lump name?

[Altazimuth]

Just now, Da Werecat said:

Or will the new spec patches be exactly like the old patches including DEHACKED lump name? 

In EE so far the answer is yes, and looking at patches to other projects it's the same there. This is being treated as an extension to the existing format rather than a new extended format (it's the path of least resistance for implementation).

[Shadow Hog]

Actually, gaps might be doable, comparing the sounds enum to the states enum. I could shift the new sounds to 512 or something- I'd kind of like the room to expand them, too, so...