God-like Phoenix-Rebirth spell bug

[Unregret]

I found this bug when trying combat using a unit with Phoenix-Rebirth spell. Its health can not fall below 1 hp and can not be killed by any means.

This is really creep me out.

 

[Kyrbi0]

Please give us a little more to go on; context for the test that brought this about, perhaps uploading the map in question.

I am personally curious about this because I have big plans for the "Egg-Morphing" Phoenix Rebirth, and don't want to run into a bug like this... But also, I've tested it a bit & it seemed to work perfectly well for me.

 

[Cuore]

While experimenting on an autocast of the phoenix spell, i also noticed that a phoenix dying doesnt trigger a death event. Only when the egg dies, the phoenix dies for real and i can use that as an event.
It would be interesting to test what happens when the phoenix dies on water and there's no place near where an egg can spawn. (I bet an egg will spawn at the nearest location possible. I wonder what happens if the map is entirely covered in water though)

The behavior unregret ascertains must be necessary to allow for the spawning of the phoenix egg without having the phoenix die in the meantime.

If it's useful, there are some comments on this in the test map of the opening post of [Solved] - Essence of blight as an autocast base. Small issue.

Unrelated to this thread.

 

[Kaijyuu]

(I bet an egg will spawn at the nearest location possible. I wonder what happens if the map is entirely covered in water though)

Generally if there's nowhere for something to go, it will just plop down on unpathable terrain. You can accomplish this by having a builder make a building in such a way as there's no more pathable ground on that z level to go; they'll just be inside the building. Your egg would just be in the water.

 

[Unregret]

While experimenting on an autocast of the phoenix spell, i also noticed that a phoenix dying doesnt trigger a death event. Only when the egg dies, the phoenix dies for real and i can use that as an event.
It would be interesting to test what happens when the phoenix dies on water and there's no place near where an egg can spawn. (I bet an egg will spawn at the nearest location possible. I wonder what happens if the map is entirely covered in water though)

The behavior unregret ascertains must be necessary to allow for the spawning of the phoenix egg without having the phoenix die in the meantime.

If it's useful, there are some comments on this in the test map of the opening post of [Solved] - Essence of blight as an autocast base. Small issue.

I found your avatar is how a Lich should look like. I read that post but it seems not connected to the bug.

Guys, IT IS something like this

Hope Blizzard fully aware of this

 

[Cuore]

I concur, it's completely unrelated to this. I apologize.

 

[Arrr]

Hi

I've done some testing, and it seems that if the phoenix dies while stunned, it will not transform into an egg until the stun duration has ended.
Now, if the phoenix takes lethal damage while stunned and is issued any order during the stun duration, it will go god-mode.
It will still go down normally if it does not get any orders during the stun duration.

As shown in the video, the phoenix dies while stunned by the inferno spell, and most likely recieves and order during the stun duration.
It is a pretty easy bug to replicare in world editor.

I do not have any solution for this tho, just wanted to share my results

 

[BloodSoul]

Well, considering what Arrr said, you could (for now) either remake the spell or use a DDS and check if the phoenix current life is less than or equal to the amount of damage taken - if that condition is true, you simply remove all buffs from it.

EDIT: Added a map demonstrating it

 

[Dr Super Good]

There is a good chance that the reason the bug still exists is because pulling it off is near impossible in melee. It requires that Phoenix, a unit with both spell immunity and resistant skin, be stunned, killed during the stun and ordered away before the stun ends.

As shown in the video, one of the few and possibly only ways to do this reliably is to web the Phoenix (web/ensnare ignore magic immunity) so that it is ground targetable and then hit it with Inferno, an ultimate with stun so can stun magic immune units. It might also be possible with Mountain King Bash if the Mountain King is carrying an orb so can attack air however it would depend heavily on luck.

Maybe one can undo the orders sent to the Phoenix while it is stunned? For example if someone sends it a move order then maybe having a trigger replace that with a stop order might work? What is the current order of the Phoenix when stunned and after taking fatal damage?

 

[Arrr]

^
Even the stop order will cause the bug

Did some more testing:
The phoenix will not go god-mode only if a non order interrupting order/ability is used while stunned (or doesn't recieve any orders).

Using a non interrupting ability and then shift-issuing any bug triggering order will make the phoenix work normally.
Issuing non-interrupting and interrupting orders without shift-queue will trigger the bug.

(it seems to be having something to do with overriding the "phoenixmorph" order, not sure though)

 

[Cuore]

Is it thinkable to efficiently detect the dangerous situation: "phoenix is dying"&"phoenix is stunned", for example like Bloodsoul suggests, or in another way?

If it's catchable, can then every order issued be automatically followed by a "phoenix morph" order? It is my understanding that the last order issued during a stun period is the one that gets through: ensuring that there is always a "phoenix morph" at the last position of the queue could potentially return the behaviour to normal.

But in the end, wouldn't this be a royal pain to trigger explicitly in every single melee map in existence? Wouldn't this be the case of a bug quickly solvable by the producer?

 

[BloodSoul]

Indeed, it would be a pain for every melee map maker to add a DDS only for that situation. The optimal solution would be Blizzard fixing that bug, of course. However, while that's not part of our reality, something should be done in order to no longer allow it to be reproduced (haha - as if it were easy to do so, as DSG said).

Uh, forget that DDS suggestion, because I hadn't seen the whole video. Now I noticed that the bug is fixed when the phoenix current life is increased. So, something simple like this solves it:

• Fix it through adding life
  • Events
    • Unit - A unit Is attacked
  • Conditions
    • (Unit-type of (Triggering unit)) Equal to Phoenix
  • Actions
    • Set oldLife = (Life of (Triggering unit))
    • Unit - Set life of (Triggering unit) to (oldLife + 1.00)
    • Unit - Set life of (Triggering unit) to oldLife

 

[Unregret]

Indeed, it would be a pain for every melee map maker to add a DDS only for that situation. The optimal solution would be Blizzard fixing that bug, of course. However, while that's not part of our reality, something should be done in order to no longer allow it to be reproduced (haha - as if it were easy to do so, as DSG said).

Uh, forget that DDS suggestion, because I hadn't seen the whole video. Now I noticed that the bug is fixed when the phoenix current life is increased. So, something simple like this solves it:

• Fix it through adding life
  • Events
    • Unit - A unit Is attacked
  • Conditions
    • (Unit-type of (Triggering unit)) Equal to Phoenix
  • Actions
    • Set oldLife = (Life of (Triggering unit))
    • Unit - Set life of (Triggering unit) to (oldLife + 1.00)
    • Unit - Set life of (Triggering unit) to oldLife

+rekt

 

[Dr Super Good]

Now I noticed that the bug is fixed when the phoenix current life is increased. So, something simple like this solves it:

An improvement on that trigger would be to only have it turned on when a Phoenix exists. This avoids overhead for every time any unit is attacked.

 

[Kyrbi0]

Uh, forget that DDS suggestion, because I hadn't seen the whole video. Now I noticed that the bug is fixed when the phoenix current life is increased. So, something simple like this solves it:

• Fix it through adding life
  • Events
    • Unit - A unit Is attacked
  • Conditions
    • (Unit-type of (Triggering unit)) Equal to Phoenix
  • Actions
    • Set oldLife = (Life of (Triggering unit))
    • Unit - Set life of (Triggering unit) to (oldLife + 1.00)
    • Unit - Set life of (Triggering unit) to oldLife

Alright, so, awexome. Something like this solves the problem? I had hoped to use this on a Hero, and so aside from making sure the variable has a player index, should this work? No adverse affects on life-gain or whatever?

 

[Marcos_M]

Can't you force the morph ordering "phoenixmorph" or whichever is the orderid?

 

[BloodSoul]

An improvement on that trigger would be to only have it turned on when a Phoenix exists. This avoids overhead for every time any unit is attacked.

Even with that existing condition (unit-type one)? If so... well, a map maker could easily do what you said, then - add new triggers checking when a phoenix is summoned (enabling that specific trigger), and detect when one dies (turn it off when no more phoenixes exist).

Alright, so, awexome. Something like this solves the problem? I had hoped to use this on a Hero, and so aside from making sure the variable has a player index, should this work? No adverse affects on life-gain or whatever?

I can only think of a flaw: A phoenix can still be invulnerable while no one attacks it. So, if a phoenix happens to be invulnerable, and there's only attacking ground units close to it, no one will be able to stop it. Regarding other things, I can't really say it, but I believe it won't interfere with anything else, because its effect (adding/restoring life) is instantaneous. Unless you have a particular trigger containing ''Unit - Life" event.

In order to fix that little flaw, you can use this instead:

• Fix it through adding life
  • Events
    • Unit - A unit Is attacked
  • Conditions
    • Or - Any (Conditions) are true
      • Conditions
        • (Unit-type of (Triggering unit)) Equal to Phoenix
        • (Unit-type of (Attacking unit)) Equal to Phoenix
  • Actions
    • Custom script: local unit u = GetTriggerUnit()
    • Custom script: local real oldLife
    • -------- Check if phoenix is the attacked or attacking unit. --------
    • Custom script: if GetUnitTypeId(u) != 'hphx' then
    • Custom script: set u = GetAttacker()
    • Custom script: endif
    • -------- Modify its HP --------
    • Custom script: set oldLife = GetWidgetLife(u)
    • Custom script: call SetWidgetLife(u, oldLife + .5)
    • Custom script: call SetWidgetLife(u, oldLife)
    • Custom script: set u = null

 

[Dr Super Good]

Even with that existing condition (unit-type one)?

Every time a unit is attacked, a trigger thread has to be created to evaluate the condition.

 

[Daffa]

Using a spell cast detection for phoenix to active the trigger should lower the overhead though.in most cases, the overhead should be negligible.