Auto res key is Win. Back in BC I got my guild to use Smartres1, and it *greatly* speeds up recovery when everybody is instantly rezzing unique targets in the proper order. It also suits my laziness incredibly well.
I noticed also one time when I was running back after a wipe, a Smartres2 bar showed up indicating someone was rezzing me, so I just stopped and accepted the rez rather than zone in halfway through his cast.
Ever since Smartres1 stopped functioning properly I have been hoping for this replacement!:)
Tried it out in right this night and it works pretty well. Only one thing bothers me. The anchor should be in a sensible default position (i suggest right above center), and hidden by default. It's annoying when you log into a new char (that possible doesn't group/raid) that you get this inferno of unconfigured addons littering the screen.
1x SmartRes2-Beta 1.01\SmartRes2.lua:729: bad argument #1 to 'sgsub' (string expected, got nil)
SmartRes2-Beta 1.01\SmartRes2.lua:729: in function `?'
CallbackHandler-1.0-5 (Ace3):147: in function <...Ons\Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:147>
<string>:"safecall Dispatcher[4]":4: in function <[string "safecall Dispatcher[4]"]:4>
<in C code>: ?
<string>:"safecall Dispatcher[4]":13: in function `?'
CallbackHandler-1.0-5 (Ace3):92: in function `Fire'
LibResComm-1.0-90048:143: in function `?'
LibResComm-1.0-90048:48: in function <...ibs\LibResComm-1.0\LibResComm-1.0\LibResComm-1.0.lua:47>
---
The first error is fixed in my newest version I'm testing; the faulty code became unnecessary, and was removed.
Working on your second error.
I don't mind anyone posting errors on this thread, as I check it regularly. However, if it is possible, I would prefer using the ticket tracker. If that is inconvenient, then by all means post here. Either way, I'll see and respond.
@xbeeps, configured, as per your suggestion. You will see it in the next alpha, and certainly in the next beta. I had misspelled a variable, now fixed, that prevented the anchor from copying its settings along with everything else.
Both errors should be fixed in/by Beta 1.03. Also fixed or adjusted
The texture a user sets for the res bars should now persist through logouts, and not revert back to "Blizzard"
I added a redundancy check to the feedback chat for dead out of range. Hopefully the feedback chat no longer tells you everybody is alive instead of telling you OOR as it should be doing
Finally gave this a test. As you know, been using the original SmartRes for ages; finally decided to see how this compares. Tried Beta 1.03.
No bugs or errors encountered. But as per your sexy FAQ on the SmartRes2 page:
Q: You said in the Known Issues that the Blizzard events don't accurately return a target, but the original SmartRes does. Um, what?
A: Actually, the original SmartRes fakes it, sometimes with the wrong information. While it is possible to be accurate about your own target, getting other players targets is not; the original SmartRes guessed for other players. SmartRes2 is 100% accurate, because it is only concerned with you, the player. To see other players' casts, they need LibResComm-1.0 or an addon that uses LRC.
This last sentence is, unfortunately, a "fatal" flaw with SmartRes2 (as with other res-indicator mods like it that rely solely on LibResComm-1.0).
Was testing along with the original SmartRes simultaneously in several raids this past week. Whenever other people were ressing a body I was targeting, the SmartRes bar(s) nearly always showed up. But SmartRes2 bars never did. The only time I got a bar from SmartRes2 was when I was ressing someone.
Relying on LibResComm-1.0 to provide other-player res info may be 100% accurate, but if only 10% (for instance) of people are running it, it sort of defeats the point. There just doesn't seem to be enough people running it or unit frame & other mods with it embedded. Less of an issue in a raid guild that "require" certain mods to be run, but not many people are a part of those.
So if you could add a fallback to the "guessing" that the original SmartRes does when it doesn't receive info from LibResComm-1.0 for the current res target, this could finally fully replace that old, creaky mod.
Hmm that is strange I have been the only one using smartres2 in my raid for a month and never missed anyones res bar and I am sure they don't all have librescomm.
Any res monitor that uses either, or both, LibResComm-1.0 or CTRA protocol, both SmartRes 1 & 2 will pick up; the latter through LRC1, the former natively.
I do plan on adding an optional "guess" feature, default off, but that's only because I keep getting asked over and over about it. It is against my better judgment, as I believe in moving forward, and letting go of old, faulty code.
Not sure when I'll get the feature in, but in it will go...
when i press the autorezzbutton i get 2 messages 1) all players are alive , congratulations and 1 sec later 2) You are rezzing SOMEONE
looks like a bug ;)
Hmm that is strange I have been the only one using smartres2 in my raid for a month and never missed anyones res bar and I am sure they don't all have librescomm.
Well I didn't receive any additional bars in SmartRes2 through three different raids which did show up in SmartRes. Thus the suggestion.
Different testing environments, your people having LibResComm/CTRA, only you doing the resses, etc. etc..
Oops, sorry, read that backwards. Good catch; however, it is has been broken for a long time, and I wonder why it didn't bug out earlier. No matter, I will commit the fix.
r99 should be the newest alpha
I was using r99 earlier and my own res + bars seemed to be working okay, but I think I'm the only one in my 10-man who uses this sort of addon, so I don't tend to see collisions. (I'm not suggesting that's an issue, I'm just not able to comment on how that part's working.)
Alright, I am going to have to go through the logic step by step one day soon when I have the time; even before I fixed the IsCastableSpell() 1nil error, when I pressed the auto res key, I got "everybody is alive, congratulations!" which certainly was not correct.
That means, just guessing here, that the "find an appropriate dead dude" logic is flawed, and not returning valid units. What I am going to do is turn the code into pseudo code and see where it is breaking.
The manual res key, the bars, textures, chat (afaik), and other features work as intended; it is the auto res key and the cast command that return incorrect data.
Auto res key is Win. Back in BC I got my guild to use Smartres1, and it *greatly* speeds up recovery when everybody is instantly rezzing unique targets in the proper order. It also suits my laziness incredibly well.
I noticed also one time when I was running back after a wipe, a Smartres2 bar showed up indicating someone was rezzing me, so I just stopped and accepted the rez rather than zone in halfway through his cast.
Ever since Smartres1 stopped functioning properly I have been hoping for this replacement!:)
Thanks for picking up this project!
and
Working on your second error.
I don't mind anyone posting errors on this thread, as I check it regularly. However, if it is possible, I would prefer using the ticket tracker. If that is inconvenient, then by all means post here. Either way, I'll see and respond.
@xbeeps, configured, as per your suggestion. You will see it in the next alpha, and certainly in the next beta. I had misspelled a variable, now fixed, that prevented the anchor from copying its settings along with everything else.
No bugs or errors encountered. But as per your sexy FAQ on the SmartRes2 page:
Q: You said in the Known Issues that the Blizzard events don't accurately return a target, but the original SmartRes does. Um, what?
A: Actually, the original SmartRes fakes it, sometimes with the wrong information. While it is possible to be accurate about your own target, getting other players targets is not; the original SmartRes guessed for other players. SmartRes2 is 100% accurate, because it is only concerned with you, the player. To see other players' casts, they need LibResComm-1.0 or an addon that uses LRC.
This last sentence is, unfortunately, a "fatal" flaw with SmartRes2 (as with other res-indicator mods like it that rely solely on LibResComm-1.0).
Was testing along with the original SmartRes simultaneously in several raids this past week. Whenever other people were ressing a body I was targeting, the SmartRes bar(s) nearly always showed up. But SmartRes2 bars never did. The only time I got a bar from SmartRes2 was when I was ressing someone.
Relying on LibResComm-1.0 to provide other-player res info may be 100% accurate, but if only 10% (for instance) of people are running it, it sort of defeats the point. There just doesn't seem to be enough people running it or unit frame & other mods with it embedded. Less of an issue in a raid guild that "require" certain mods to be run, but not many people are a part of those.
So if you could add a fallback to the "guessing" that the original SmartRes does when it doesn't receive info from LibResComm-1.0 for the current res target, this could finally fully replace that old, creaky mod.
I do plan on adding an optional "guess" feature, default off, but that's only because I keep getting asked over and over about it. It is against my better judgment, as I believe in moving forward, and letting go of old, faulty code.
Not sure when I'll get the feature in, but in it will go...
looks like a bug ;)
Well I didn't receive any additional bars in SmartRes2 through three different raids which did show up in SmartRes. Thus the suggestion.
Different testing environments, your people having LibResComm/CTRA, only you doing the resses, etc. etc..
if outOfMana == 1 then NOT if outOfMana ~= 1 then
Won't rez anybody atm.
r99 should be the newest alpha
Great work on this btw.
That means, just guessing here, that the "find an appropriate dead dude" logic is flawed, and not returning valid units. What I am going to do is turn the code into pseudo code and see where it is breaking.
The manual res key, the bars, textures, chat (afaik), and other features work as intended; it is the auto res key and the cast command that return incorrect data.
Stay tuned.