[Solved] Why does this work?

[Aeroblyctos]

Hey,

• BERSERK DAMAGE
  • Events
    • Unit - DRAGON 2 0027 <gen> Takes damage
  • Conditions
  • Actions
    • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
      • If - Conditions
        • ((Life of (Triggering unit)) - (Damage taken)) Less than 0.41
      • Then - Actions
        • Unit - Set life of (Triggering unit) to ((Damage taken) + 0.41)
      • Else - Actions

Just wanted an explanation to this mystery. Why doesn't this unit die?

 

[ap0calypse]

Because the trigger runs before any damage is actually dealt.
So you increase the HP before the unit dies.

 

[edo494]

maybe it has something to do with the fact that this runs slightly earlier then the damage is done(damage is done when all Takes damage triggers are ran) but the damage dealt is already calculated, so you heal the unit and it survives with 1 hp

so the unit is healed a little bit before it takes the damage

 

[Bannar]

Bribe's GUI friendly damage engine should give you better insight into the case.

 

[themerion]

In other words, the unit WILL die if damage dealt is greater than its max hp.

 

[Almia]

Why does this work?

Let's ruin the code so it won't work

 

[Maker]

If you are wondering about the 0.41, then it is because units are considered dead when their hit points go below 0.405. GUI can't use 0.405, so 0.41 is used and it is close enough.

 

[Dr Super Good]

The WarCraft III engine apparently runs the JASS damage handler before actually dealing the damage. This makes preventing death from any reasonable damage source very easy but makes blocking damage when at maximum health very difficult. This is why so many damage block abilities have a bug where they will lose some health when at maximum HP.

 

[Kitabatake]

The WarCraft III engine apparently runs the JASS damage handler before actually dealing the damage. This makes preventing death from any reasonable damage source very easy but makes blocking damage when at maximum health very difficult. This is why so many damage block abilities have a bug where they will lose some health when at maximum HP.

I wouldn't call that very difficult as you can just refill the lost health after a 0.01s timer.

 

[looking_for_help]

I wouldn't call that very difficult as you can just refill the lost health after a 0.01s timer.

Only if the damage is less than the units max hp...

 

[Kitabatake]

Only if the damage is less than the units max hp...

In that case you just temporarily increase the max hp with a dummy ability.

 

[edo494]

but that will as result make the health bar flicker and sometimes you could spot the 500k addition under units portrait, which is not best but its as close as it can get

 

[Dr Super Good]

I wouldn't call that very difficult as you can just refill the lost health after a 0.01s timer.

Incorrect, you use a 0 expiration timer and even that is too slow. It is possible for many damage instances to be done to the unit in the time it takes the timer to fire and each has to be accounted for to prevent the final health being computed incorrectly. Especially if you are using a shield ability with a fixed quantity or absorption percentage less than 100% as you want to correctly credit any killing units that do reduce health below 0.405, preferably without generating another damage instance (so the killing blow has to be handled differently from non-killing blows).

Only if the damage is less than the units max hp...

Yes but I think each damage instance is atomic so you only need to run handling code if the unit receives damage greater than the maximum health at a single instance (which no well made map should ever do, but in any case you can just pump unit health to the millions with a health increasing ability). The problem complexity still remains with the 0 timeout timer used to correct health to appropriate levels as that needs to handle many damage instances correctly.

but that will as result make the health bar flicker and sometimes you could spot the 500k addition under units portrait, which is not best but its as close as it can get

Incorrect as all this happens sub frame so the health number cannot flicker. The health bar does flicker because damage instances instruct a bar reduction on the next frame which does not reflect the unit's actual health. The flicker is due to the bar graphics responding to the damage instance and not the delay in handling the damage instance by the 0 timeout timer. I have made one of these systems before and can report that the bar does flicker but the health numbers below the unit portrait remain accurate at all times.

 

[Aeroblyctos]

Thanks guys for the answers. I got my answer already but you can discuss as much as you want. I'm out!

 

[looking_for_help]

Yes but I think each damage instance is atomic

No, damage events can run a coupled instance and thats exactly where most systems fail. The bugs in Bribes DDS for example are cause by exactly this problem.

Incorrect as all this happens sub frame so the health number cannot flicker.

I tested the following systems that allow damage modification while developing my system:

• GUI Damage Engine v2.2.1.0 by Bribe
• DDS - Damage Detection System by Nestharus
• DamageEvent & DamageModifiers by Anitarf
• Damage by Jesus4Lyf
• Shield by Cokemonkey11

All of these, including my system, can have flickering health values on damage blocking. It happens very rare and usually only under extreme conditions, but it happens.

This has nothing to do with the graphic responding to slow, but just because a 0-timer runs asynchronous. Health bar flickering can be avoided by the way easily.

 

[Dr Super Good]

No, damage events can run a coupled instance and thats exactly where most systems fail. The bugs in Bribes DDS for example are cause by exactly this problem.

So you mean a few damage events can run before damage is dealt to the unit? It seems a bit illogical for that to happen but maybe is a sub-frame optimization preventing the game from booting the JASS interpreter multiple times.

 

[Maker]

I think he refers to the 0.00 timer, but I'm not sure. Most systems do not check for stacked damage during that timer.

 

[looking_for_help]

So you mean a few damage events can run before damage is dealt to the unit?

No, I didn't meant that, but this can happen anyways. As a good DDS should allow you to allocate damage from an allready running damage event (e.g. for reflecting purposes), you can never be sure any damage event runs atomic.

Every damage event can potentially get interupted at any time and a good system should be able to deal with this.

I think he refers to the 0.00 timer, but I'm not sure. Most systems do not check for stacked damage during that timer.

Yes, I refered to the 0-second timer. There are basically three different cases and each has to be considered appropriately. In the enclosed diagram I listed these three cases:

Cases

Greetings,
lfh

 

[Dr Super Good]

Every damage event can potentially get interupted at any time and a good system should be able to deal with this.

You should never deal damage to the same unit in response to it taking damage as that opens infinite looping problems. In any case the behaviour of that damage would need to be investigated, as it could happen that by the time the interpreter gets back to executing the initial damage event, the resulting damage and event are already processed and dealt to the unit.

What we know is that the game engine signals the damage event before it carries out the damage to a unit. What needs investigating is if damage can get queued, where multiple damage events fire before multiple damages are deducted. Knowing this behaviour is important as it could potentially allow for some optimizations.

A timer with a timeout of 0 still has a timeout. The script will be scheduled when the next timer check is run. One can safely assume that the game engine does not interrupt running tasks (such as computing movement or damage) to check for timer timeouts as this could cause strange behaviour and bugs. The reason such a timeout is used is because some delay is needed to allow the game engine to deal the damage to the unit and any other JASS method still runs atomically with the damage event response (before the damage is dealt to the unit).

The main complexity comes from running a good shield system with the damage events. If the shield fails (runs out of absorption) and the unit has low health you may want to let the blow kill the unit for accurate credits. If you block all the damage then you have given the shield more absorption than it should have had (bug). Throw in shields with fractional blocking and it is possible that a unit will run out of life before absorption in any case and so need to credit the correct killer. Throw in multiple shields at the same time and you will need to run an appropriate stacking behaviour, removing from each shield in a certain way.

Blocking all damage from is easy. Blocking damage for a damage absorbing shield is not.