Doesn't seem to have an affect. I'm using 61908, and the itemlevel setting is still on for every character I login to, even though I'm turning it off each time.
Screw it, I'm just going to hardcode the damn thing to "off" in the ratingbuster code and stop updating. This is really annoying.
The tank summary settings keep being reset to none.
Actually, all summary settings keep being reset.
I keep getting the itemlevel setting reset to "on", even though I had it set off all along. Now I have to keep turning it off for every character, even though they all share the same profile.
Now, it is my understanding (well, assumptions) that:
1. Buffing does zero threat (but will put you on a mob?s threat list if you buff someone who is in combat).
This doesn't match up with my experience, at least for self-buffs. They seems to cause *just* more than zero threat -- less than a nondamaging debuff that shows up with an icon, but more than zero.
Many times we've used a hunter pet to pull a boss, and when the boss is running towards the raid -- that is, before anybody has any threat -- we've seen a priest cast Inner Fire, or a mage cast Ice Armor, etc, and the boss will turn and go right for that person.
This might have changed in the last few months, we haven't needed to do that kind of pull in a while. Any other method of pull causes more threat than that, so we wouldn't have noticed.
UPDATE: LibParser-4.0 does not have a single division operation in it, so the source must be in one of the Threat modules. Antiarc should have updated his libraries by now to prevent 1/0 values from being transmitted as well as adding in additional anti-infinity checks. According to Antiarc, this most likely comes from a Warrior/Druid's Demo shout/Roar because the code divides the threat generated by the number of targets that it hit - which could be 0.
If it helps any, I see it all the time on my warrior without using demo shout.
I join a party. Other party members don't need to be anywhere close; assume I'm soloing something. First attack on a mob will cause the error.
Farmbuyer, may i know your warrior's name? This could help in assisting me to track down the cause of the issue. I have detected and found 2 more bugs in AceComm-2.0 that is in the process of being fixed sometime this week.
That's not a bug, it's a feature and has been explained in the WAU thread.
I don't know anybody who treats trolling through these forums (I see seven WAU threads) as documentation. That's the sort of thing we'd expect to find on the addon's wiki page, since almost everything else is on that page.
What Omen revision do you have? If you open the AceComm-2.0.lua file in a text editor, what revision is listed at the top?
I've re-downloaded Omen and Recap (the only other Ace2 mod that uses acecomm) multiple times from various places (SVN, "files", etc), and the latest acecomm I can find is 57236. I've looked over the code briefly, and it's all local to that file, none of that part is using other Ace libs. It's also uncommented and undocumented, so I'm not really keen on trying to debug it myself.
Yes. It never updates its index without forcing a refresh, but I can live with that.
Do you update with or without externals,
With. (I'll mention that there is no definition of what "externals" are anywhere on the WAU wiki page, and searching doesn't turn up a definitive description. I can probably guess what they are, from experience as a mod author, but many others are just left clueless.)
Is that the "Omen\Libs\AceComm-2.0\AceComm-2.0.lua:307: bad argument #1 to 'string_char' (invalid value)" bug? Because as of Thursday night, it's still happening with whatever revision is handed out by the WowAceUpdater (including a forced reload of index) and with whichever version the http://files.wowace.com/Omen/Omen.zip symlink points to.
I fixed the AceComm error today, so that should be fixed.
Is that the "Omen\Libs\AceComm-2.0\AceComm-2.0.lua:307: bad argument #1 to 'string_char' (invalid value)" bug? Because as of Thursday night, it's still happening with whatever revision is handed out by the WowAceUpdater (including a forced reload of index) and with whichever version the http://files.wowace.com/Omen/Omen.zip symlink points to.
Same here, it sells some grey items but not all of them.
This isn't just Automaton, other auto-sell mods are experiencing the same thing. There's a thread in the Blizz UI&Macros forum about it. No real explanation yet, but I'm debugging it as I have time.
0
Screw it, I'm just going to hardcode the damn thing to "off" in the ratingbuster code and stop updating. This is really annoying.
0
I keep getting the itemlevel setting reset to "on", even though I had it set off all along. Now I have to keep turning it off for every character, even though they all share the same profile.
0
This doesn't match up with my experience, at least for self-buffs. They seems to cause *just* more than zero threat -- less than a nondamaging debuff that shows up with an icon, but more than zero.
Many times we've used a hunter pet to pull a boss, and when the boss is running towards the raid -- that is, before anybody has any threat -- we've seen a priest cast Inner Fire, or a mage cast Ice Armor, etc, and the boss will turn and go right for that person.
This might have changed in the last few months, we haven't needed to do that kind of pull in a while. Any other method of pull causes more threat than that, so we wouldn't have noticed.
0
Seems to be fixed in the one chance I got to test it so far. I'll try and do some pugs on that char today and keep an eye out.
0
If it helps any, I see it all the time on my warrior without using demo shout.
I join a party. Other party members don't need to be anywhere close; assume I'm soloing something. First attack on a mob will cause the error.
0
(replied in private message)
0
I see it nearly always on my warrior, almost never on other classes. It happens as soon as I enter combat for the first time after joining a group.
0
0
I don't know anybody who treats trolling through these forums (I see seven WAU threads) as documentation. That's the sort of thing we'd expect to find on the addon's wiki page, since almost everything else is on that page.
Heh, that wasn't there the last time I looked. Good to see more docs.
I have. More than once. back to KTM, I guess.
thanks anyhow.
0
What Omen revision do you have? If you open the AceComm-2.0.lua file in a text editor, what revision is listed at the top?
I've re-downloaded Omen and Recap (the only other Ace2 mod that uses acecomm) multiple times from various places (SVN, "files", etc), and the latest acecomm I can find is 57236. I've looked over the code briefly, and it's all local to that file, none of that part is using other Ace libs. It's also uncommented and undocumented, so I'm not really keen on trying to debug it myself.
0
Yes. It never updates its index without forcing a refresh, but I can live with that.
With. (I'll mention that there is no definition of what "externals" are anywhere on the WAU wiki page, and searching doesn't turn up a definitive description. I can probably guess what they are, from experience as a mod author, but many others are just left clueless.)
No.
0
Nothing's changed since mid November, apparently, that's the last revision in files.wowace.com. Is this being updated at all?
0
Still broken as of now, r55025.
0
Is that the "Omen\Libs\AceComm-2.0\AceComm-2.0.lua:307: bad argument #1 to 'string_char' (invalid value)" bug? Because as of Thursday night, it's still happening with whatever revision is handed out by the WowAceUpdater (including a forced reload of index) and with whichever version the http://files.wowace.com/Omen/Omen.zip symlink points to.
0
This isn't just Automaton, other auto-sell mods are experiencing the same thing. There's a thread in the Blizz UI&Macros forum about it. No real explanation yet, but I'm debugging it as I have time.