DEHEXTRA discussion (split from Pr+ UMAPINFO thread)

[Ferk]

On 7/11/2020 at 3:26 PM, 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

 

What would you suggest could be a good way to represent a fractional factor in dehacked? (say.. we want an enemy to fire 2.5x more or 0.5x less)

So far DEH only accepted integers as field values (other than the mnemonics for the bit flags), so I can think of some options:

 

1) We don't allow any fractions at all and have the multiplier only work in integer increments (drawback of this is you cannot decrease the firing chance).

2) Support for decimal fractions (1.5 etc) should be added to the DEH parser, which source ports would interpret either as fixed point or float (potential precision incompatibilities?).
3) Keep parsing integers but agree on a specific unit divisor that maps cleanly to binary precision no matter if the engine wants to use floats or fixed point. I'd suggest 1024 since it's more user friendly and intuitive than 65536 (I don't think we need 16 bits precision).

4) Instead of having the value be the factor, make it be the exponential power (base 2) of it. So 0 is unchanged, 1 is double, 2 is quad (4x), -1 is half, -2 is 1/4 ... this has the advantage that the operation would be the same as vanilla (bitwise shift) so there would be less impact on the more vanilla ports.

 

Imho, option 3 seems like a good compromise, not too invasive without being too strange to edit the DEH. A value of 1500 would be close to 1.5x (even if it's actually lower, but at least it would be consistently the same across ports to the last decimal). It could be converted to float easy with 1500/(float)1024 and FRACUNIT-based fixed point with 1500<<6.

Edited July 19, 2020 by Ferk

[jeff-d]

0 - 100% - 200% etc

[fabian]

I am for the 3rd solution, but with FRACUNIT as the unit. Its 16 bits of precision are rarely needed anywhere in mobj handling, but its Doom's internal unit nevertheless. We could just FixedMul() the given value and be done with it. 

[esselfortium]

Using FRACUNIT would make sense for consistency. WhackEd already invisibly multiplies/divides relevant fields by FRACUNIT and displays them as decimals, so the user doesn't have to think about it, and in DEH9000 you're already expected to put "* FRACUNIT" on a lot of fields.

[Ferk]

1 minute ago, esselfortium said:

Using FRACUNIT would make sense for consistency. WhackEd already invisibly multiplies/divides relevant fields by FRACUNIT and displays them as decimals, so the user doesn't have to think about it.

 

Oh, I did not realize this was already a thing. Which other dehacked fields are FRACUNIT-based?

If that's the case then indeed that should be the way to go.

[esselfortium]

2 minutes ago, Ferk said:

 

Oh, I did not realize this was already a thing. Which other dehacked fields are FRACUNIT-based?

If that's the case then indeed that should be the way to go.

To my knowledge there's radius, height, and projectile speed (but not monster speed).

[JXC]

One thing I want to see is custom projectiles

[Shadow Hog]

Re: getting the sounds shifted over to accommodate Eternity: it appears I have it working. I'd never heard of "designated initializers" before this, but Visual Studio threw no errors, and one NULL check added to D_BuildBEXTables later, it works, as this (admittedly somewhat plain) video of the Half-Life VOX announcer counting from 200 to 0 every two seconds before you explode shows, so, sure:

 

I suppose I should ask a follow-up question: what is a good offset for this? If I were to leave room for every Heretic, Hexen and Strife sound effect (including VOICES.WAD) as well (starting at 300, as Eternity currently has it), I'd have to set it to just under 1200 (which is where that video currently has it). That seems rather high for ports that would rather keep memory count low. FWIW, I don't know that I intend to add more than the 200 added sounds the video showcases (the "die" just being DSSKLDTH), if only because cutting together those VOX sounds in Audacity for the sake of making sure the slots are working is way too time-consuming. That said, I also don't want to completely write off the possibility for somebody else to do in the future, either.

 

I also noticed Eternity had no entries for MINAT3, CHICPAI, CHICDTH, CHICACT, CHICPK1, CHICPK2, CHICPK3, RIPSLOP, BURN, GLOOP, HRNPOW, RAMPHIT, RAMRAIN, or LOBPOW from Heretic (but does have one for a nonexistent "NOWAY" sound - a clone of PLROOF I presume), though I have no idea if you guys care or not about that since I'm not certain how deep your Heretic implementation is at the moment. (This also isn't exactly material to the topic at hand, I suppose.)

[NiGHTMARE]

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?

Edited July 27, 2020 by NiGHTMARE

[Shadow Hog]

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

[Redneckerz]

Bippity Bump, DEHEXTRA is now a Doom Wiki lump.

 

Obviously this is not finished in terms of documentation, as i can imagine a lot more can be done to it (Finishing what Things can be used for, a tutorial how to expose these features into Whacked, more examples of DEHEXTRA) but i feel confident in saying this provides a good base to expand upon.*

 

^{*Perhaps ironically, this page has a lot more ''meat'' than the BEX page.}

 

Other affected/referenced pages will be updated to reference the DEHEXTRA page.

 

Thanks:

• @VGA for the examples Smoothed/Black Ops
• Exl for making a Whacked4 configuration parameter.
• @bradharding for his Wiki entry regarding his additional states, which was invaluable into making this possible.

[bradharding]

@Redneckerz I'd suggest removing mention of "Retro bits", "Blood" and "Shadow offset" from the new wiki page, as they are for DOOM Retro-specific features only. As for the other additional entries, are they all really to be part of DEHEXTRA?

[Redneckerz]

4 minutes ago, bradharding said:

@Redneckerz I'd suggest removing mention of "Retro bits", "Blood" and "Shadow offset" from the new wiki page, as they are for DOOM Retro-specific features only.

Splitted them, one general and one stating Doom Retro-specific ness.

4 minutes ago, bradharding said:

As for the other additional entries, are they all really to be part of DEHEXTRA?

I mean, i don't know :P As the general author of these extensions, i would fully appreciate additional details on the thing blocks and further general details on its possibilities.  :)

[Ferk]

The "Dropped item" field is already in both Crispy and PrBoom+ (other than Doom Retro). But I don't know if the other ones are meant to, I don't know if maybe they are too specific to Doom Retro.

 

There were also these additional fields that were merged in Crispy with the idea of dehardcoding some of the vanilla behavior, but they haven't been added to other ports yet (should I open a PR in PRBoom+ for it?):

 

- Melee threshold: distance to switch from missile to melee attack -  [the vanilla Revenant has 196 as threshold]

- Max target range: Maximum distance range to start shooting (zero for unlimited) -  [the vanilla Archivile has 14*64 as limit]

- Min missile chance: Minimum chance for firing a missile [standard value from vanilla is 200, except Cyberdemon being 160, the lower the number the higher minimum likelihood]

- Missile chance multiplier: multiplier that factors the likelihood of missile attack (FRACUNIT being the base value, lower values will proportionally increase the firing chance, while higher values will reduce it) - [Cyberdemon, Spider Mastermind, Revenant and Lost Souls have FRACUNIT/2 making them fire twice as often in vanilla]

Edited August 8, 2020 by Ferk

[bradharding]

I'll look at updating that page soon. :) (BTW, just released a new version of DR that includes the Melee threshold, Max target range and Min missile chance entries.)

[NiGHTMARE]

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?

 

Well they're not part of the original Boom specs, so just thought I would make sure :)

 

12 hours ago, Ferk said:

The "Dropped item" field is already in both Crispy and PrBoom+ (other than Doom Retro). But I don't know if the other ones are meant to, I don't know if maybe they are too specific to Doom Retro.

 

It would be amazing if DEHEXTRA became a repository for at least the most useful thing bits and codepointers for the ports which support it. There are also ZDoom's thing bits and its codepointers, and Eternity's thing bits and its codepointers.

 

A lot of ZDoom's are already supported by Eternity, so those at least are excellent candidates for becoming part of the standard.

Edited August 9, 2020 by NiGHTMARE

[Da Werecat]

7 hours ago, Ferk said:

dehardcoding

 

Hmph. Is there a comprehensive list of such quirks exhibited by certain thing numbers, states, or codepointers? I only knew about arch-vile. I also know that moving around chaingun flash states can be disastrous if done wrong, and maybe a couple more minor things.

 

But this seems to go deeper, with subtle changes in behavior that wouldn't be noticeable right away.

[JXC]

I would like to see SkullAttack speed dehardcoded so I can replicate the Heretic Imp

[P41R47]

Dehardcoding the hardcoded TNT and Plutonia strings, for sure.
I would love to see this on normal dehacked and it can be applied to dehextra that would be awesome, too.

Edited September 26, 2020 by P41R47

[Gez]

One ZDoom bit I'd suggest for inclusion in the DEHEXTRA evolving standard would be the scale property. This is AFAIK all that is required to support Harmony -- well, that and MAPINFO but the latter is less critical.

[Shadow Hog]

As long as the thread's been bumped up, I was kinda hoping for a response from anyone when I posted the video of the 200 sounds working - specifically, a bit of discussion as to what number to start them at. I've proven (to myself, if nobody else) that the starting number can be completely arbitrary and skip as many as needed in PrBoom+UM, and I'd like to try and make a pull request to at least that port at some point. Given this is a new standard we're writing here, though, I also don't want to either box people in too hard or leave so much empty room that it causes other issues.

 

Unrelated to this, but as long as we're making requests while shooting for the stars, some sort of mechanism to group together specific sounds for randomization (e.g.: zombie seesound/deathsound, imp deathsound) would be nice, if entirely new to DEH. To some extent you can already randomize some things using A_RandomJump, but if it was, say, the ActiveSound you wanted to be randomized, that might not help you out too much.

[Altazimuth]

200? I dunno where 200 is available in EE. I'll need to look into it. 150 from 150 to 299 was the prior I stated, though if you want I can try find either a contiguous 200, or broken-up extra 50 in addition to the 150.

[Shadow Hog]

It'd probably be best to be contiguous, regardless of what the final figure ends up being. I will say I have no inclination to go over 200, that seems like more than plenty for most use cases.

 

What should we mark the range between the start of this range and the end of the standard MBF-compatible sounds, though? "Engine-specific"?

[Gez]

"Reserved" is usually how this kind of things is called.

[Altazimuth]

Well EE can do 400-599 if 200 sounds is necessary. Just requires moving some stuff up in the Strife branch.

[mammajamma]

What about adding an extra slot to weapons 2 and 4-7 to make it an even 14? That would help something like D4V so you could have a version where you can have every weapon in the mod at once without having to swap out .deh files.

[Altazimuth]

5 hours ago, mammajamma said:

What about adding an extra slot to weapons 2 and 4-7 to make it an even 14?

That's... probably not feasible across all the ports. The weapon code is pretty rigid and dehacked would need a lot of extensions to make such a prospect at all useful. Additionally, you'd need to dynamically enable weapons and it's a whole bother.

[P41R47]

37 minutes ago, Altazimuth said:

That's... probably not feasible across all the ports. The weapon code is pretty rigid and dehacked would need a lot of extensions to make such a prospect at all useful. Additionally, you'd need to dynamically enable weapons and it's a whole bother.

Maybe not across all the ports, but surely deharcoding the SSG behaviour to one slot is a really good idea that could add a lot to limit removing and boom/mbf. Maybe even making it usable on Ultimate Doom would be cool.

As you say, it may be really bothersome, but the result might be far than awesome.

Edited October 3, 2020 by P41R47

[Shadow Hog]

21 hours ago, Altazimuth said:

Well EE can do 400-599 if 200 sounds is necessary. Just requires moving some stuff up in the Strife branch.

Works for me. When I'm over this hard drive about-to-die slump (data should already be backed up, just trying to ID what's been lost to failing sectors if anything), I'll see what I can do to push this to PrBoom+UM and I guess we work from there.

[mammajamma]

On 10/3/2020 at 4:19 PM, Altazimuth said:

That's... probably not feasible across all the ports. The weapon code is pretty rigid and dehacked would need a lot of extensions to make such a prospect at all useful. Additionally, you'd need to dynamically enable weapons and it's a whole bother.

If not entirely new slots, what about simply cloning them (ie, another shotgun, another plasma rifle, etc.)? Or would that present the same issues?