Certain pawns won't be killed by a Trigger>SpecialEvent combination

[)Leela(-[otS]-]

Hi

I have a map with a deep shaft and I want to kill randomly spawned monsters in this shaft. This shaft is not extra zoned so I used a Trigger>SpecialEvent combination for it.
My first setup was:

Trigger: TriggerType == TT_PawnProximity

SpecialEvent: InitialState == DamageInstigator; Damage == 1000000

This worked good for all pawns, but not for Pupae, Slith and IceSkaarj.

Then I changed TriggerType to TT_ClassProximity and ClassProximityType to ScriptedPawn.
After that also Pupaes were killed, but Sliths and IceSkaarjs still survived.

As a last try I altered ClassProximityType to Slith and in another Trigger to IceSkaarj, but they still can't be killed.
Why do these two pawns survive when all others get killed by the SpecialEvent? IceSkaarj is even only a childclass of SkaarjWarrior and SkaarjWarriors get killed at once with TriggerType == TT_PawnProximity.

PS: The monsters fall into the Trigger radius, they are not spawned inside of it. Also several Triggers stacked one above the other were used.

[Hellkeeper]

No idea why this wouldn't work, your setup seems flawless...
Try adding a DynamicZoneInfo with enough damage to kill the pawns. It will create a "zone" without the need for portals or any actual zoning. See if that works.

[Masterkent]

By default, Pupaes have too low Intelligence (BRAINS_None), so when TT_PawnProximity is used, the Trigger's function IsRelevant returns False

Code: Select all

function bool IsRelevant( actor Other )
{
      if ( !bInitiallyActive )
            return false;
      switch ( TriggerType )
      {
      case TT_PlayerProximity:
            return Pawn(Other)!=None && Pawn(Other).bIsPlayer;
      case TT_PawnProximity:
            return Pawn(Other)!=None && ( Pawn(Other).Intelligence > BRAINS_None );
      case TT_ClassProximity:
            return ClassIsChildOf(Other.Class, ClassProximityType);
      case TT_AnyProximity:
            return true;
      case TT_Shoot:
            return ( (Projectile(Other) != None) && (Projectile(Other).Damage >= DamageThreshold) );
      }
}

and the SpecialEvent won't be triggered at all.

Sliths and IceSkaarjes trigger the SpecialEvent actor, but they can't harm themselves via TakeDamage called by the SpecialEvent actor. By default, Sliths and IceSkaarjes are supposed to be completely immune to some damage types: Sliths cannot be corroded, IceSkaarjes cannot be frozen. This is implemented by setting default values of ReducedDamageType and ReducedDamagePct to

'Corroded' and 1 respectively for Slith, and
'Frozen' and 1 respectively for IceSkaarj.

When a SpecialEvent calls TakeDamage for a Slith or an IceSkaarj, Engine.Pawn.TakeDamage is called. This function includes the following lines:

Code: Select all

      if ( bIsPlayer )
      {
            if (ReducedDamageType == 'All') //God mode
                  actualDamage = 0;
            else if (Inventory != None) //then check if carrying armor
                  actualDamage = Inventory.ReduceDamage(actualDamage, DamageType, HitLocation);
            else actualDamage = Damage;
      }
      else if ( (InstigatedBy != None) && (InstigatedBy.IsA(Class.Name) || IsA(InstigatedBy.Class.Name)) )
            ActualDamage = ActualDamage * FMin(1 - ReducedDamagePct, 0.35);
      else if ( (ReducedDamageType == 'All') || ((ReducedDamageType != '') && (ReducedDamageType == damageType)) )
            actualDamage = float(actualDamage) * (1 - ReducedDamagePct);

When the event is initiated by the same pawn for which TakeDamage is being called and its bIsPlayer == false, we have evaluation of

Code: Select all

ActualDamage = ActualDamage * FMin(1 - ReducedDamagePct, 0.35)

Therefore, in case of Slith or IceSkaarj whose ReducedDamagePct is 1, the actual damage will be reduced to zero.

I have no idea why Epic decided to overload the meaning of ReducedDamagePct in such perverted way, but this is how it works now.

If InitialState of a SpecialEvent actor is set to 'KillInstigator', then pawn's function Died will be called instead.

[)Leela(-[otS]-]

Hiya

for the replies
I worked for several hours today on this map when I came to this point and I guess I was already a bit too tired for appropriate tests.
After a pause and reading the replies I gave it another shot.
Now I use two SpecialEvents, one set to KillInstigator and the other to DamageInstigator.
(I use one with DamageInstigator because then the monsters also get gibbed )
Five Triggers are stacked above each other because sometimes one is not enough when a bunch of monsters is falling down.
I tested it with each monster and really threw bunches of about 20 monsters from each sort down. Nothing survived this.

@Hellkeeper
This DynamicZoneInfo really sounds very interesting. Unfortunately I'm not yet very familiar with 227 actors. But I will for sure look into it. Thx for the hint.

[Masterkent]

Now I use two SpecialEvents, one set to KillInstigator and the other to DamageInstigator.
(I use one with DamageInstigator because then the monsters also get gibbed )

Then you could try to use just one actor of a class type inherited from SpecialEvent where the state DamageInstigator would be defined as follows:

Code: Select all

state() DamageInstigator
{
      function Trigger( actor Other, pawn EventInstigator )
      {
            Global.Trigger( Self, EventInstigator );
            if ( Other.bIsPawn )
                  Level.Game.SpecialDamageString = DamageString;
            // parameter instigatedBy is initialized with none
            Other.TakeDamage( Damage, none, EventInstigator.Location, Vect(0,0,0), DamageType);
      }
}

[Hellkeeper]

Great info MasterKent. I agree that Epic's decision to add tons of condition to the DamageInstigator is inexplicable and sounds a bit dumb.