ZDoom

You can now get ZDoom 2.1.4.

Changes:

• Added a queryiwad_key cvar to control which key can force the IWAD selection to appear. It can be either "shift" or "control". Any other value will disable its functionality.
• Added some simple translucency map analysis for BOOM maps to more intelligently pick the value to use for TranslucentLine's second argument.
• Something MinGW users will probably like: i_crash.cpp no longer needs dbghelp.h if you compile with GCC.
• Added deprecation warnings for the DontHurtShooter, ExplosionRadius, and ExplosionDamage actor "properties." They were considered deprecated before; now this is explicitly stated when they are used. The problem with them is that they are not really properties and do not behave like other properties and cannot be inherited, because they are really just an alternate way of specifying parameters for A_Explode. (Anything that currently prints a deprecation warning will be removed completely in 2.2.0, which will be the version where custom state labels make their debut.)

Fixes

• A_SkullPop() and A_FreezeDeathChunks() did not transfer the player's inventory to the new dismembered head "player."
• MeleeDamage was initialized to random values for each decorate actor if it wasn't explicitly specified.
• Friendlies would not turn to face you when you engaged them in conversation, nor would any actors reliably return to their original facing when you stopped talking to them.
• Some crashes fixed.

Yay for crash fixes!

Awesome.

randy wrote: Added deprecation warnings for the DontHurtShooter, ExplosionRadius, and ExplosionDamage actor "properties." They were considered deprecated before; now this is explicitly stated when they are used. The problem with them is that they are not really properties and do not behave like other properties and cannot be inherited, because they are really just an alternate way of specifying parameters for A_Explode. (Anything that currently prints a deprecation warning will be removed completely in 2.2.0, which will be the version where custom state labels make their debut.)

As much as I agree with officially deprecating them I really don't think it's a good idea to remove them completely. It would break more than half the WADs out there that have been released since DECORATE monsters are available. Unlike the state assignments these have been used extensively.

These are only the ones I found while checking my play directory for 'explosiondamage'. But it should be obvious that every major ZDoom release from the last 2 years is on this list:

- The monster pack
- The ZDoom Community Map
- Super Sonic Doom
- Cold as Hell
- Simplicity
- NeoDoom
- Zaero
- A New Hellspawn
- Resurrection of Chaos
- Operation Overlord
- Enjay's Thief level
- TNT:LE
- Hell's Twisted Influence 1+2
- Italian Doom 1

So to sum it up, I think it is a really bad idea to remove these 'properties'. It would create a huge mess.

randy wrote:

• MeleeDamage was initialized to random values for each decorate actor if it wasn't explicitly specified.

Yay! So this means it defaults to what now?

It defaults to 0 now.

As for the explosion stuff, I took the time to clean it up and make those properties actually useful so there should be no need for deprecation anymore. Now A_Explode can also be used with expressions which didn't work before due to the special handling for the fake properties.

randy wrote:

• Added deprecation warnings for the DontHurtShooter, ExplosionRadius, and ExplosionDamage actor "properties." They were considered deprecated before; now this is explicitly stated when they are used. The problem with them is that they are not really properties and do not behave like other properties and cannot be inherited, because they are really just an alternate way of specifying parameters for A_Explode. (Anything that currently prints a deprecation warning will be removed completely in 2.2.0, which will be the version where custom state labels make their debut.)

Those properties have always stupidly overpowered small projectiles and weapons that inherit from explosive weapons and the poison cloud for me. But I second Graf's post - PLEASE don't remove them completely.

Sounds better now, doesn't it?

- Used the new explosion handling to clean up the old style projectile
definitions. The SimpleProjectile class is gone and it uses the meta
data and A_ExplodeParms instead now.
- Removed the deprecation warnings for explosion parameters again because
the new system is fully inheritable and therefore useful again.
- Changed the explosion properties into meta data and adjusted A_ExplodeParams
to use these when called without any parameters. Also removed all special
parsing for A_Explode so now this function can be called with expressions
like any other function.
- Changed DECORATE parsing so that functions with completely optional
parameter lists don't create an empty list when called without parameters.

Graf Zahl wrote: - Operation Overlord
- Enjay's Thief level

Ooops, that was a touch foolish of me. Especially with the Thief level, with it being so recent. I probably did know the properties were being deprecated but just copied come older code or something and simply didn't realise/think that it would be a problem.

With so many WADs relying on these properties, it does seem a bad idea to remove them completely. Witness how many error reports there still are about the Inventory/CutomInventory thing - and that was only from an unofficial version, the correct method was explained a long time ago and not as many WADs use it compared to the ones using the above examples. Imagine the flood of "oh gno, miy wodd duzzn't werk NE moar" posts there will be, and will continue to be for months, maybe years afterwards.

How much of a problem is it to keep them in and keep them working? What is the need to remove them? Breaking a fair number of commonly played WADs does seem ill advised if there is no significant advantage to doing so. Hopefully a clear warning in the Wiki, and continuing a console Warning in Zdoom itself should be enough to deter people from using the old method for newer work without having to break existing mods.

Personally, I probably would "fix" my WADs, but not everyone will and even with that being done, a lot of people will have the older versions on their HDs and not even realise a fix is available.

[EDIT]

Graf Zahl wrote:Sounds better now, doesn't it?

Is this something you have done, or just something you are proposing?
[/EDIT]

rpmz. I compiled it on FC5, and tested that binary on a SUSE 10.1, and it worked. Therefore I assume the SUSE 10.1 binary works on FC5 too, so there is only one i586 package (created on SUSE) for both on SF.

Enjay wrote: [EDIT]

Graf Zahl wrote:Sounds better now, doesn't it?

Is this something you have done, or just something you are proposing?
[/EDIT]

It's already committed. It eliminates all the problems of the old implementation while keeping it mostly compatible. I don't think removing these properties is a good idea when they still can be salvaged. It cost me ca. 30 minutes of work to change.

Good news. Makes sense to me.

randy wrote: Fixes

• A_SkullPop() and A_FreezeDeathChunks() did not transfer the player's inventory to the new dismembered head "player."

Now maybe Hexen Co-Op wont break if I get freezed.

Also, I too agree with Graf about depreciating but not removing the DECORATE flags. Breaking a lot of wads doesn't sound very great.

Heh, thanks Graf for fixing the flags so they won't be removed... Zen in particular is chock full of these crazy deprecation errors, and I was quite scared for a moment.

Just a quick question: I know I should know this, but what is the current replacement for the DONTHURTSHOOTER flag? I wasn't aware that the flag itself was deprecated and stuff.

A_SkullPop?