Enable the Delay option in the Rez module, and then manually click Cancel. With the changes I committed, it will no longer accept the summon anyway at the end of the delay period after you've hit the Cancel button.
There isn't really a way (as far as I'm aware) to know what the spell name was that wants to resurrect you. It wouldn't be terribly practical to check for the caster's combat status either. You'd have to pick the name out of the dialog text, then scan through everyone in the party/raid to find a matching name, and check combat status on that unit.
I'm working on an option to set the delay time (1min 40sec is way too long IMO) for both the Rez and Summon modules; once that's done you can set it to something short like 5 or 10 seconds, which will give you time to cancel the resurrection manually, but won't make you wait forever to auto-accept either.
That sounds marvelous. I like the longer summon time, since I am often finishing up poison-crafting or something merchant-related when summoned. However, I agree that time is far too long for a rez accept.
Well the player name is passed with the event, but yeh it would suck trying to find the player's class given a name and no unitId.
A 5-10 sec delay would be nice. After a wipe I want the autorez to be near instant for faster recovery/buffing. Although for battle rez's I may need to wait longer than 10 sec before accepting and it's never acceptable to decline a battle rez (they're too valuable). An example might be getting a brez but then needing to wait for a boss stage transition to complete before accepting it.
So if determining rez'ers class isn't practical and use a short delay instead. Is it possible to allow the cancel button during the countdown cancel the countdown and leave the rez request window open? So to decline the request during a delayed accept you would need to click twice, but you could cancel the countdown and accept manually when it's safe.
Thought about it a little more and changed my mind:)
Having either more delay options or a configurable delay value would be nice.
Also having the ability to cancel a delayed accept without canceling the request is important.
Aside from this, I think an additional option for battle rez's is still needed.
Even a short timer with ability to cancel could result in disaster. Example, if I've been dead for a min and go afk for some reason, a 5-10 sec timer could still autorez me to my death even if it's cancelable.
Given that the rez'ers name is an argument for the request event, it would simply take looping through the group/raid to find a matching unit and checking if it's class is a druid.
Sure looping through the raid isn't performant, especially for an automated action. However, the looping only needs to occur if the option is enabled, AND the player is dead already so performance for a quick check like this is irrelevant.
I'm not sure if it's possible to only close the popup on the second press, or how difficult it would be. The OnCancel function for each popup (which is what's called when you press the Cancel button) doesn't handle closing the popup, so I'm not sure what would be required. I'll have to look into it. If I can't do this, or if it would be too difficult to warrant adding (like overwriting significant amounts of Blizzard code), would it suffice to add an option to not auto-accept resurrections from druids?
Yeh I think having an option to not autoaccept res's from druids is the best way to handle all these cases sufficiently. It should provide all functionality desired for raids without risking auto accepting or cancelling a brez at the wrong time.
Well, my druid isn't high enough to have flight forms yet, but as far as I know you just get a "you are shapeshifted" error message when trying to herb, and there's no way to distinguish between that message coming from clicking an herb and that message coming from trying to create a bandage, without independently tracking every time you mouseover an herb. I can add cancelling forms when you get the shapeshifted error, but it'll unshift you every time you get it, not just for herbs.
Automaton-1.3.0\modules\Mailer.lua:55: AceHook-2.1: "ContainerFrameItemButton_OnModifiedClick" already has an active hook from this source.
<in C code>: in function `TurnOrActionStop'
<string>:"TURNORACTION":4: in function <[string "TURNORACTION"]:1>
Well, unless you can reproduce it, and unless it's causing issues with functionality, I'm not going to attempt to fix it. Like I said, I don't use the Mailer module, so I'm not familiar with how it works or why it might be trying to hook that function twice.