Morgalm, you are listed as an author now, so you should be able to SVN commit. If not, let me know.
Hey, before I commit your update, I have question. In the options, lines 153 - 166, is it still appropriate to call self:Disable() and self:Enable() even though your changes implicitly removed those functions? Also, because I have it coded that disabling the addon is a True value, how will lines 114 - 115 be handled? Will that affect anything after OnInit() if the user turns off SR2 later?
OK, reverted my workaround for cross realm players, as it did not work. Unless anyone has any bright ideas, I may have to rewrite LibResComm-1.0 as LibResComm-1.1, giving it cross-realm knowledge; might as well add the engineering devices while I'm at it. No Raise Ally, as that is an insta-cast, and pointless because of such.
You can throw this in LibResComm-1.0 where appropriate without having to bump its major version.
local real_target, realm = string.split("-", targetName, 2)
-- If the target is on the current realm, real_target will be nil - set it as targetName.
real_target = real_target or targetName
I have question. In the options, lines 153 - 166, is it still appropriate to call self:Disable() and self:Enable() even though your changes implicitly removed those functions?
self:Enable() calls the OnEnable() function same for disable.
Need copious amounts of testing in PUG cross-realm settings using the latest alphas of SmartRes2 and LibResComm-1.0. Yeah, I realize most of the time nobody conveniently dies in daily Heroics. I was thinking of bribing players: here's 10 gold -- just die once so I can test something...
The latest package of SR2 comes with the latest alpha of LRC1, but for those with independent libs, you will have to specify the alpha in the Curse Client. OK, OK, you guys already know that; I'll shut up and wait for feedback.
Had a couple of players die conveniently a few times today. They were cross-realm, and the auto res button worked just fine. I will test again later after some sleep. If all works out, I will push a new beta build.
This was with the latest alpha of LibResComm-1.0 and the latest alpha (straight up, not developer copy) of SmartRes2.
There was a bug at logon with r149 solved with the current r150, posted about by someone in the mod comments section on the WowAce download page. But another bug with r150, occurred sometime after the start of a raid (likely when resing people):
["message"] = "SmartRes2-r150\\SmartRes2.lua:853: attempt to index field '?' (a nil value)\nCallbackHandler-1.0-5:147: in function <...onLoader\\CallbackHandler-1.0\\CallbackHandler-1.0.lua:147>\n<string>:\"safecall Dispatcher[2]\":4: in function <[string \"safecall Dispatcher[2]\"]:4>\n<in C code>: ?\n<string>:\"safecall Dispatcher[2]\":13: in function `?'\nCallbackHandler-1.0-5:92: in function `Fire'\nLibResComm-1.0-90051:259: in function `popupFuncRessed'\nLibResComm-1.0-90051:311: in function `OnShow'\nInterface\\FrameXML\\StaticPopup.lua:3434: in function `StaticPopup_OnShow':\n<string>:\"*:OnShow\":1: in function <[string \"*:OnShow\"]:1>\n<in C code>: in function `Show'\nInterface\\FrameXML\\StaticPopup.lua:3271: in function <Interface\\FrameXML\\StaticPopup.lua:2943>:\n<in C code>: in function `StaticPopup_Show'\nInterface\\FrameXML\\UIParent.lua:3238: in function `ShowResurrectRequest':\nInterface\\FrameXML\\UIParent.lua:508: in function <Interface\\FrameXML\\UIParent.lua:454>:\n\n ---",
["type"] = "error",
["session"] = 391,
["counter"] = 1,
And something brought up some time ago, but still really think its something to implement in SmartRes2 (SR2).
Right now, SR2 relies completely on people having LibResComm-1.0 for you to get feedback on who's resing who. With SR1, it relied on "guessing"/detecting events. For months now, I get far (far) more res bars showing other people resing through SmartRes (which I still use) than I ever have with SR2.
Besides the modern library framework, I have yet to see any advantages to using SR2 here over the original SmartRes unfortunately yet.
Thanks for the bug report Zidomo. I know there are some issues still for me to deal with.
As for LibResComm vs SRv1: based on what I can tell on the Cataclysm beta, the original SmartRes will die. It will throw endless amounts of errors, roll over, and die a horrible Ace2 related/incorrect variable returns death.
I get that the original picks up more casts, guessed or not, but its day is done. Right now, there is no real advantage, but eventually there will be no choice.
I get that the original picks up more casts, guessed or not, but its day is done. Right now, there is no real advantage, but eventually there will be no choice.
Right now, SR1 does have a very real advantage. It shows you a lot more resing than SR2 does in average usage in a non-hard-core raid guild/PUGing where most people (apparently) aren't running LibResComm-1.0.
Over a fairly significant sample size (of one tester) over several months, I have barely ever seen a SR2 bar come up using working versions of it. The unfortunate question that arises due to this: what's the point of using SmartRes2?
Thus my request for SR2, if its possible for you to implement.
You can throw this in LibResComm-1.0 where appropriate without having to bump its major version.
local real_target, realm = string.split("-", targetName, 2)
-- If the target is on the current realm, real_target will be nil - set it as targetName.
real_target = real_target or targetName
eh? strsplit will return the full string if there's no delimiter match, not nil. It ends up working like intended, but not as described (real_target will either be targetName or the name part of a name-realm string)
Edit: just realized that was from three weeks ago, lol.
Kind of silly SPELL_CAST_START and UNIT_SPELLCAST_START don't include the target and UNIT_SPELLCAST_SENT is player only ;[ Not having a way to programmatically get the spell target at the start of the cast is just plain annoying.
Need to slip LibResComm into something like pitbull, grid, or dbm, lol
<snip>
Thus my request for SR2, if its possible for you to implement.
It is indeed possible, and I have been working on it in an alternate file, which is why you haven't seen it in alpha. The trick is, using the spellcasting events, not to trample all over the LRC events. Can't prove it yet, but I would guess the Blizzard events will fire before the library, so I have to be careful not to create duplicate caster info and artificially create collision bars.
But it is something I am working on.
The main reason why SRv1 will die with Cataclysm is (besides Ace2 itself probably not working) is the SpellIDs will all be different. While yes, that is just a few changed lines, and yes, LibResComm and SR2 will need those same changes, I do not plan on making those changes in the original. Assuming Ace2 works with the expansion, it is a very easy fix, but honestly, I would prefer the original SmartRes to die peacefully in its sleep. Or choking on its own code vomit. Whichever! :D
OK, uploaded r152 with the dry code for non-CTRA casts, got into a group. SR2 threw errors, and I thought I would look at them after the run. Sadly WoW crashed just as I opened BugSack, so all the errors are gone!
GRRRRRR. Yeah, so I know there are bugs, but I can't get into another group until way later tonight. Please post bugs to the tracker, or in the forum as a second option.
heh, my point was to get the library into popular addons simply so people will have it and send you their infos :D
UNIT_SPELLCAST_SENT is player only ;[ I basically rewrote LibResComm before testing the only event you can use to get a target at the start of a cast, then went to play with it only to find it was only catching my spells z.z
http://paste.wowace.com/2264/ was my result if you want to look at it (not much testing, just sat in a party with someone and we both starting ghealing), did work as a drop in replacement for LibResComm as far as SmartRes2 was concerned though :p), but in the end if it's not the player it relies on guessing /shrug
Edit: So I was bored and fleshed out that library a bit more, but I can't edit the paste :'(. And no offense, but your dry coded code is a train wreck >.>
Nebula, you can always create a new addon called LibRes. Might confuse people, however, and you probably are better off asking to take over LibResComm-1.0, as I don't think DathRarHek is still around.
I know my dry code is a train wreck; feel free to fix it (anyone can) and commit to the repository. Turns out I may not be in game for a few days anyway, so I can't test or fix the code. And given that I'm going on vacation in two weeks for a week, most likely I will be gone for a total of about three weeks.
Should you want to up a few alphas, be my guest. If not, please be patient. :)
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
self is undefined in that section of code as it is a local funtion (ie doesn't start with Smartres2:) so you need to use:
http://www3.telus.net/MorgDKP/SmartRes2.zip
Hey, before I commit your update, I have question. In the options, lines 153 - 166, is it still appropriate to call self:Disable() and self:Enable() even though your changes implicitly removed those functions? Also, because I have it coded that disabling the addon is a True value, how will lines 114 - 115 be handled? Will that affect anything after OnInit() if the user turns off SR2 later?
self:Enable() calls the OnEnable() function same for disable.
The latest package of SR2 comes with the latest alpha of LRC1, but for those with independent libs, you will have to specify the alpha in the Curse Client. OK, OK, you guys already know that; I'll shut up and wait for feedback.
This was with the latest alpha of LibResComm-1.0 and the latest alpha (straight up, not developer copy) of SmartRes2.
And something brought up some time ago, but still really think its something to implement in SmartRes2 (SR2).
Right now, SR2 relies completely on people having LibResComm-1.0 for you to get feedback on who's resing who. With SR1, it relied on "guessing"/detecting events. For months now, I get far (far) more res bars showing other people resing through SmartRes (which I still use) than I ever have with SR2.
Besides the modern library framework, I have yet to see any advantages to using SR2 here over the original SmartRes unfortunately yet.
As for LibResComm vs SRv1: based on what I can tell on the Cataclysm beta, the original SmartRes will die. It will throw endless amounts of errors, roll over, and die a horrible Ace2 related/incorrect variable returns death.
I get that the original picks up more casts, guessed or not, but its day is done. Right now, there is no real advantage, but eventually there will be no choice.
:lol:
Right now, SR1 does have a very real advantage. It shows you a lot more resing than SR2 does in average usage in a non-hard-core raid guild/PUGing where most people (apparently) aren't running LibResComm-1.0.
Over a fairly significant sample size (of one tester) over several months, I have barely ever seen a SR2 bar come up using working versions of it. The unfortunate question that arises due to this: what's the point of using SmartRes2?
Thus my request for SR2, if its possible for you to implement.
eh? strsplit will return the full string if there's no delimiter match, not nil. It ends up working like intended, but not as described (real_target will either be targetName or the name part of a name-realm string)
Edit: just realized that was from three weeks ago, lol.
Kind of silly SPELL_CAST_START and UNIT_SPELLCAST_START don't include the target and UNIT_SPELLCAST_SENT is player only ;[ Not having a way to programmatically get the spell target at the start of the cast is just plain annoying.
Need to slip LibResComm into something like pitbull, grid, or dbm, lol
It is indeed possible, and I have been working on it in an alternate file, which is why you haven't seen it in alpha. The trick is, using the spellcasting events, not to trample all over the LRC events. Can't prove it yet, but I would guess the Blizzard events will fire before the library, so I have to be careful not to create duplicate caster info and artificially create collision bars.
But it is something I am working on.
The main reason why SRv1 will die with Cataclysm is (besides Ace2 itself probably not working) is the SpellIDs will all be different. While yes, that is just a few changed lines, and yes, LibResComm and SR2 will need those same changes, I do not plan on making those changes in the original. Assuming Ace2 works with the expansion, it is a very easy fix, but honestly, I would prefer the original SmartRes to die peacefully in its sleep. Or choking on its own code vomit. Whichever! :D
GridStatusRes
Grid2StatusRes
@Nebula169: Sometimes I am dumb. Like right now. What was your point?
GRRRRRR. Yeah, so I know there are bugs, but I can't get into another group until way later tonight. Please post bugs to the tracker, or in the forum as a second option.
UNIT_SPELLCAST_SENT is player only ;[ I basically rewrote LibResComm before testing the only event you can use to get a target at the start of a cast, then went to play with it only to find it was only catching my spells z.z
http://paste.wowace.com/2264/ was my result if you want to look at it (not much testing, just sat in a party with someone and we both starting ghealing), did work as a drop in replacement for LibResComm as far as SmartRes2 was concerned though :p), but in the end if it's not the player it relies on guessing /shrug
Edit: So I was bored and fleshed out that library a bit more, but I can't edit the paste :'(. And no offense, but your dry coded code is a train wreck >.>
I know my dry code is a train wreck; feel free to fix it (anyone can) and commit to the repository. Turns out I may not be in game for a few days anyway, so I can't test or fix the code. And given that I'm going on vacation in two weeks for a week, most likely I will be gone for a total of about three weeks.
Should you want to up a few alphas, be my guest. If not, please be patient. :)