Detect cancel reviving a hero

[ZiBitheWand3r3r]

Dead hero is reviving by a player in Altar. If player cancels revive (clicking hero icon) I'm unable to detect this event.
Already tryed event "Unit cancels reviving" and "Unit is issued an order with no target" with no success..
By the way cancel training can detect cancel by clicking hero icon in queue section, but for some reason cancel revive does not.
Anyone can help with this event detection?

 

[KILLCIDE]

I believe @IcemanBo made a system related to this. He might be able to give some insight.

 

[LordDz]

You could remove the "revive hero" and instead have a dummy unit of the same name level become trainable when the hero dies.
Detect when it finishes training and instantly revive your hero then.

That way you can detect when it's canceled too.

Will have to do fixed proper names or not include it in the tooltip, but other than that it should look alike.

 

[ZiBitheWand3r3r]

@LordDz thanks for this idea.
It is altered melee with several custom races map.
My 1st thought: this will affect AI, doesn't it?
Training time cannot be changed (as hero level 1 should revive faster then hero level 10)
creating over hundred new dummy units is not a thing I'm dreaming about

 

[IcemanBo]

Before a unit starts reviving, the altar makes a special revive order. For the altar's very first hero it will be always 852027, for the second 852027+1, then 852027+2, etc, etc.
You need a queue like data strcuture, something where you can enqueue and dequeue data -- so each time when a building makes such a order from 852027 to 852027+4 (if max hero is 4) then the building gets into the queue.

The next thing what happens is that the event "a unit starts reviving" will fire. When this happens you put the reviving unit into data structure, a unit group, or so. You must bind the respective altar unit to the reviveable unit here. We use the queue from above to find the needed altar, it will be always the first one in the altar queue. (the altar can be un-queued now, so the next one moves at first position)

So now we basicly have a reviveable unit instance, and the respective altar binded to it.
We can periodicly make a order for the altar forcing it to revive <unit>, and the function will return true if it succeded, and false, if not.
So, if the order returns false, it means it's still being revived, but if it returns true, it means it's not in the revive queue anymore. So it was either cancled, or what ever.
Then you can run your custom event here, that the altar canceled the revive.
There of course also need to be events that un-register the whole thing, in case a unit finished reviving, etc.

It's not really a straight forward way, but atm I wouldn't know a better one.

 

[ZiBitheWand3r3r]

well, indeed it is crooked way
I know those orders, get them during testing, they are target orders so we have access to altar and revivng hero, no need to catch "unit starts reviving" event I think.

So, if the order returns false, it means it's still being revived

or no $money$..
Also we have to check if reviving hero is alive, altar is destroyed (hero may be finishing revive and altar may be destroyed between periodical checks)
If check-order returns "true" we have to cancel it after 0sec timer.
IcemanBo Im very grateful for your tips but I feel its too much complicated to get it 100% save

 

[IcemanBo]

target orders so we have access to altar and revivng hero

ehm, this would make it a bit easier indeed, but can you show how to make it? I might try the rest then.

 

[ZiBitheWand3r3r]

GetOrderedUnit() //altar
GetOrderTargetUnit() // reviving hero

    call TriggerRegisterAnyUnitEventBJ( gg_trg_ReviveStartOrd, EVENT_PLAYER_UNIT_ISSUED_TARGET_ORDER )

 

[IcemanBo]

Ah, I had a stupid mistake in my demo code, that's why it wasn't workig at first. Nice, thanks. I'll share when there is progress.

 

[IcemanBo]

Do you need GUI support?