70 - smartrez2 will repeatedly rez the same corpse

What steps will reproduce the problem?
1. Be part of a group; almost exclusively LFR to date.
2. Watch a few people die, and combat ends. (Because priest, no battle rez here.)
3. Hit control-R to trigger smartrez with the autorez key. (Casting my priest resurrection)
4. Rez a not-entirely-random person, awesome; cast completed.
5. Hit control-R to trigger smartrez again, because someone else is down.
6. Look surprised because it decided to send the same person a rez, a second after my last cast landed on them.

What is the expected output? What do you see instead?

I expected to see the rez move on to the next person, and so forth -- rather than getting "stuck" on the same character. At least, not going back until a little time had passed and they had a chance to accept/reject the rez request. Heck, if they got a rez I expect them to be last in the priority list, because you missed it, you don't deserve to get back up quickly. ;)

What version of the product are you using?

SmartRez2 2.5.6

Do you have an error log of what happened?

There are no error logs; it isn't an "error" in the sense that bugsack catches, but rather a surprising behaviour WRT who is selected.

Please provide any additional information below.

This is pretty much one hundred percent reproducible for me, in LFR. The rez tends to work, too; eventually the person jumps up, even without a recast of the spell. It just makes using the tool much, much slower than expected because I have to wait for someone to get up before I can start on the next person.

I am also happy to try and debug this; my best guess is that it comes from libresinfo not picking up the state, or something akin to that. I will try and figure out where that is going wrong and add the details here, but I figured to let you know sooner rather than later.

From my settings:

SmartRes2DB = {
["profileKeys"] = {
["Thelladmina - Proudmoore"] = "Default",
["profiles"] = {
["Default"] = {
["enableTimeOutBars"] = false,
["timeOutBarsX"] = 0,
["hideAnchor"] = true,
["autoResKey"] = "CTRL-R",
["resBarsY"] = 679.9998618125974,
["resBarsTexture"] = "Armory",
["randChatTbl"] = {}, -- elided for space here :)
["reverseGrowth"] = true,
["customchatmsg"] = "rez incoming for %t",
["resBarsX"] = 436.4800032806379,
["resExpired"] = true,
["timeOutBarsAnchor"] = false,
["chatOutput"] = "INSTANCE",
["timeOutBarsY"] = 487.1997268200066,

User When Change
myrroddin Apr 25, 2014 at 13:31 UTC Changed status from Accepted to Fixed
myrroddin Aug 24, 2013 at 19:56 UTC Changed status from New to Accepted
slippycheeze Aug 20, 2013 at 02:36 UTC Create

You must login to post a comment. Don't have an account? Register to get one!

  • Avatar of myrroddin myrroddin Jan 18, 2014 at 16:09 UTC - 0 likes

    @Stronguard: Go

    Thank you for the update. I haven't closed this ticket because occasionally I see the behaviour myself. I am debugging the issue, but as you can see given the length this has been an open issue, solving is not a cut and dry case.

    Don't worry, I plan on fixing this come hell or high water!

  • Avatar of Stronguard Stronguard Jan 16, 2014 at 05:37 UTC - 0 likes

    We have just started trialing this add-on in our guild are experiencing this result. It's a 25 player raid guild so there is a reasonable chance more than one player will be casting on the same target however even if I cancel casting an hit the auto res again, it will sometimes continue to attempt to res the same player, exactly as described in the ticket.

  • Avatar of Gjerdesmett Gjerdesmett Sep 04, 2013 at 05:42 UTC - 0 likes

    I am seeing this behaviour too.

  • Avatar of myrroddin myrroddin Aug 20, 2013 at 13:22 UTC - 0 likes

    Hmmm, interesting. Is anyone else casting on the same target at the same time?



Last updated
Apr 25, 2014
Aug 20, 2013
Fixed - Developer made requested changes. QA should verify.
Defect - A shortcoming, fault, or imperfection
Medium - Normal priority.

Reported by

Possible assignees