Default/global damagetype properties

[FDARI]

Plugged into DECORATE parsing (it would be possible to move it to a separate lump as well).

Syntax:

Code: Select all

DAMAGETYPE TypeName
{
    [Declaration]
    [Declaration](...)
}

Available declarations are:

DamageFactor <multiplier> (default 1.0) - Defines a default damage factor for this damage type. If a mobj is taking a type of damage it has no specific modifier for, this factor is applied. If the mobj has a general untyped damage factor, it is combined with this for this damage type.

Replacefactor - Replace an actor's untyped damage factor instead of combining (multiplying) with it.

Noarmor - This damage type always ignores armor


The damage factors only apply to the mobj that is receiving damage; they have no effect on powerups that modify damage.

Important note: Actors that define a specific damage factor for a damage type are not affected by the default value at all.

Important note: The basic damage factor (no type specifier whatsoever, just a number) always applies. This submission does not affect that. "DamageFactor 0" on an actor, makes that actor mostly invulnerable.

Main purpose: Define special damagetypes that normal actors are immune to without having to redefine and replace every actor in the game.

Code: Select all

Damagetype SpecialDamage
{
    DamageFactor 0
}

Actor SpecialActor
{
    DamageFactor SpecialDamage, 1
}

Given the above decorate code, SpecialActor is the only actor that will be affected by SpecialDamage.

EDIT: Files no longer required; feature is added.

[Blue Shadow]

Yes! Finally someone has coded this, and I really hope it gets in. Very Nice!

[Graf Zahl]

There's a few minor issues in here that need changing:

1. There's no need to hardcode damage type "Drowning" anymore. This should be added as a definition to one of the internal DECORATE lumps.
2. A multiple definition of a damage type must not result in a warning but in a silent replacement. The system has to allow for this situation. How else would you handle multiple WADs defining the same damage type?

[Graf Zahl]

Added but removed the 'redefinition' warning message. I didn't do anything about 'Drowning' yet.

[FDARI]

I'm not sure I'm applying the non-0 damage factors correctly. Essentially, I'm not sure what's the best way to express a fixed_t literal in c++/zdoom, but I'm also uncertain if I'm getting it correctly from decorate, and if I am applying it correctly thereafter.

Pending fixes (I'll try to get you a patch if you don't just fix it with superior knowledge)
Drowning in decorate
Missing damage factor: if the mobj has damage factors, but not the right one, and not a fallback, then the default is not applied either
Non-0 default damage factor working correctly?

[Graf Zahl]

I'm not sure what's the best way to express a fixed_t literal in c++/zdoom

Just an int. int 0 == fixed_t 0.
Otherwise intval * FRACUNIT

[FDARI]

The ones I get wrong are the non-0 values. Particularly, (fixed_t)1 results in (int)1 the way I used it, and something similar seems to happen when I convert a float/double (sc.Float) to fixed_t. Which creates a really diminutive damage factor.

[Graf Zahl]

1 has to be FRACUNIT and for fixed/float conversion use the FIXED2FLOAT and FLOAT2FIXED macros.

[Gez]

fixed_t fixval = intval<<FRACBIT;
int intval = fixval>>FRACBIT;

fixed_t fixval = intval * FRACUNIT;
int intval = fixval / FRACUNIT;

fixed_t fixval = FLOAT2FIXED(floatval);
float floatval = FIXED2FLOAT(fixval);


There are some places in the code where 65536 or 65536. is explicitly used instead of using the macros; I don't know if it's an oversight or motivated by some obscure reason.

[Edward-san]

Oh, talking about that (sorry for the OT):

Code: Select all

Index: p_spec.h
===================================================================
--- p_spec.h    (revision 3532)
+++ p_spec.h    (working copy)
@@ -95,7 +95,7 @@
 
 // Factor to scale scrolling effect into mobj-carrying properties = 3/32.
 // (This is so scrolling floors and objects on them can move at same speed.)
-enum { CARRYFACTOR = ((fixed_t)(FRACUNIT*.09375)) };
+enum { CARRYFACTOR = (3*FRACUNIT >> 5) };
 
 // phares 3/20/98: added new model of Pushers for push/pull effects
 

I'm not sure why you use floating point constant inside an enum (would be rejected by a pedantic compiler). Did I get the value right?

[Gez]

Did I get the value right?

It translates to 6144 either way, so yes.

[FDARI]

Ok. Got the damage factors right. Exported drowning to decorate. Fixed a flaw in the mobj calculation. Tested, packed and submitted.
(Drowning is now fully overridable; you can for mysterious purposes choose to apply armour.)

[Graf Zahl]

Fix applied.