• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • 🏆 Hive's 6th HD Modeling Contest: Mechanical is now open! Design and model a mechanical creature, mechanized animal, a futuristic robotic being, or anything else your imagination can tinker with! 📅 Submissions close on June 30, 2024. Don't miss this opportunity to let your creativity shine! Enter now and show us your mechanical masterpiece! 🔗 Click here to enter!

Detect cancel reviving a hero

Not open for further replies.
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?
Level 25
May 11, 2007
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.
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.
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 :(
Not open for further replies.