You could make the code a little cleaner by putting a 'local' in front of the ArdentDefender declaration. Nothing buggy jumps out at me, however.
If you don't already have something like BugGrabber/BugSack installed, I recommend dropping those in place. Errors before the player is in the game world can be hard to track down.
I'm a bit confused how WoW determines if an item can go into the reagent bank or not, or how it creates the tooltip entry for 'crafting reagent'. It seems this information is hidden from the LUA accessible API?
The core tooltips aren't built by Lua routines, they're implemented in C and handed back as a finished object. Sometimes the easiest way to get this kind of information in an addon is, not to try and figure out where the information would have come from (since "how WoW determines if such-and-such" is going to be "the game client, like, *knows things*, man"), but rather to just get the resulting tooltip and pull data out of it textually.
Yes, this always feels like a kludge, but it has the distinct advantage of *working*. And you can always cache the information yourself, so that you're not constantly fiddling with invisible tooltips.
(You may be doing this already, I have not looked at your code.)
I'm trying to work out what, if anything, is causing an error. By "if anything" I mean anything that we can possibly fix as players, rather than hoping that somebody at Blizzard happens to see the error and acts on it.
Ever since WoD came out, I've been seeing this error between a dozen and several thousand times a day. The expression complained about on line 1860 is "absorbed and absorbed > 0", but as you can see from the Locals dump further down, 'absorbed' is nil. From other locals (event, originalEvent, missType, etc), you can see that the problematic argument is being passed as the result of the select() call on 2270.
And yes, this error did indeed happen 1084 times on the occasion shown here. Which just goes to show that it's not a corner case; googling finds a few other people reporting the same message.
While there is a global reference assigned to the nominally buggy function (1935), all the call sites are already bound to the local reference by the time any player addon could replace it with a fixed version.
This may or may not be related to cowlevel's error. Using 4.0.7, I've got a rogue with Anticipation and am trying to display both normal combo points and Anticipation points.
I just noticed that the latest alpha, v4.0.7-5-g77c3a79, has a line in its changelog about fixing combo point bars. (Actually the same line is in a few changelogs, something about how Git+Wowace accumulates entries? Dunno.)
With this version, the same behavior persists, including the incorrect colors and reuse of the same bar for both normal and anticipation points.
...except that Broker_Currency keeps track of what you have, not what you might have if you perform a certain action in game.
That's a good point; I suspect that no matter how many disclaimers and caveats were displayed, B_C would still be getting tickets about how the Predicted Approximate Garrison Cache, Maybe column was "buggy".
The resource cache itself can't be queried for other toons; I don't even think you can query it for the toon you're logged into, only open it.
But capping is not hard to avoid. Garrisons generate 1 resource every 10 minutes, so that's about 3 and a half days of not clicking the cache before it fills up. Presumably you're logging on at least twice a week in order to juggle missions and whatnot.
If you want an actual resource count, you'd have to just estimate it. A "data broker"-type plugin could take note of when a given toon clicks the cache, and store the current time. After that, the toon's approximate resources can be queried by taking the difference between the current time versus the stored last-clicked time, and doing some basic math. Might even be able to build that into Broker_Currency or something similar.
Sure ok, but still, this might be usefull for something else later.
So, yeah, is it possible to replace \enUS\ by some kind of wildcard ?
If you're going to be doing That Kind Of Thing, just delete the cache subdir entirely. Honestly, the time spent figuring out details and typing/pasting in the line for each particular cached file is more than the time it takes to rebuild the entire cache tree.
If you absolutely must snipe individual files while leaving the rest of the cache tree alone, try replacing the locale name with "*", I honestly don't know if CMD.EXE's "IF EXIST" conditional works on wildcards at all. Maybe prepend an 'echo' in front of the action command so you can see what it would have done before trying it for realsies.
If you still need it done and CMD.EXE can't do it, then I'd advise either learning PowerShell (and God have mercy on your brain), or installing a copy of Cygwin and just scripting in whatever language you prefer using (Bourne variant, Perl, Ruby, Lua, etc).
Good call on looking for running processes first. Most people wouldn't think of that.
This may or may not be related to cowlevel's error. Using 4.0.7, I've got a rogue with Anticipation and am trying to display both normal combo points and Anticipation points.
Unit Config -> Player -> General -> Combo Points is enabled. Growth is "left" and "don't hide when empty" is checked to avoid the vertical stretch/shrink spazz on the bars.
Unit Config -> Player -> General -> Aura Combo Points is enabled with all the same settings.
I can see both empty bars at the bottom of my player's unitframe (that is, there's a double-height empty space). However:
1) Nothing is ever drawn in the aura/anticipation bar, only in the main combo points bar. If all 5 combo points are present and an extra one gets generated, the same bar starts filling up again.
2) I changed the aura points color and left the combo points color alone. But the aura points color is used for the combo points also, instead of each using its own.
Looking through the savedvariables file, nothing seems out of place. Looking through modules/combopoints.lua and modules/aurapoints.lua, I can see what they're trying to do but have no immediate ideas as to what's causing either of these bugs. I added some print() statements to dump return values from both versions of :GetPoints and those numbers are being fetched correctly; it's just the visuals that go wrong.
Fiddling with the settings above hasn't yet fixed anything or yielded any insight yet as to what's colliding. I'll keep messing with it but would love to hear what settings are successfully being used by other Anticipation rogues.
The problem of "latest tag is not the latest/default download" seems to have reared its ugly head again.
It might even be fallout from the "rebuild ALL THE THING" problem; if each tag is being rebuilt in parallel, then whatever tag happens to be the last one to finish would have the most recent timestamp on its file.
At the moment, CC 5.1.1.820 keeps trying to offer a very old version as the latest.
edit: Ooooh, I wonder if shifting all the tags to be local tags, and only pushing a single "latest" tag would inhibit this problem? Imma try that once apt-get finishes molesting my bandwidth.
Seems to be having issues again. I just tagged a new release ("v1.9.6") of Rundown, and it's responding with:
Joining all threads
ERROR 255 with ('/home/curseforge/env/bin/hg', 'update', '-C', 'v1.9.6'): }}} {{{abort: No such file or directory: '/media/cf-repositories/packager/hg-local-checkout/wow/rundowniv/mainline/.hg/updatestate'
ERROR 255 with ('/home/curseforge/env/bin/hg', 'update', '-C', 'v1.9.0'): }}} {{{abort: No such file or directory: '/media/cf-repositories/packager/hg-local-checkout/wow/rundowniv/mainline/.hg/updatestate'
ERROR 255 with ('/home/curseforge/env/bin/hg', 'update', '-C', 'v1.6.1'): }}} {{{abort: No such file or directory: '/media/cf-repositories/packager/hg-local-checkout/wow/rundowniv/mainline/.hg/updatestate'
There's more, but it gets aged off the webpage before I can capture the text. It then proceeds to repackage every tag and every commit in the project.
That reminds me, I need to stop putting a redundant 'v' in front of the version string.
If you've already configured it from scratch and something else is still broken, then we can't help you. Clearly some part of your setup, your WoW installation, or your computer is wrong, but since we can't magically see inside your hard drive, we can't guess what it is. Make sure you're using the special WoD beta version of XPerl from http://www.curse.com/addons/wow/xperl and follow all tips from its author.
0
If you don't already have something like BugGrabber/BugSack installed, I recommend dropping those in place. Errors before the player is in the game world can be hard to track down.
0
The core tooltips aren't built by Lua routines, they're implemented in C and handed back as a finished object. Sometimes the easiest way to get this kind of information in an addon is, not to try and figure out where the information would have come from (since "how WoW determines if such-and-such" is going to be "the game client, like, *knows things*, man"), but rather to just get the resulting tooltip and pull data out of it textually.
Yes, this always feels like a kludge, but it has the distinct advantage of *working*. And you can always cache the information yourself, so that you're not constantly fiddling with invisible tooltips.
(You may be doing this already, I have not looked at your code.)
0
Only managed to do that once, since trying to do an instance with no addons is tedious.
0
Ever since WoD came out, I've been seeing this error between a dozen and several thousand times a day. The expression complained about on line 1860 is "absorbed and absorbed > 0", but as you can see from the Locals dump further down, 'absorbed' is nil. From other locals (event, originalEvent, missType, etc), you can see that the problematic argument is being passed as the result of the select() call on 2270.
And yes, this error did indeed happen 1084 times on the occasion shown here. Which just goes to show that it's not a corner case; googling finds a few other people reporting the same message.
While there is a global reference assigned to the nominally buggy function (1935), all the call sites are already bound to the local reference by the time any player addon could replace it with a fixed version.
=====================================================
1084x ...Blizzard_CombatLog\Blizzard_CombatLog.lua:1860: attempt to compare number with boolean ...Blizzard_CombatLog\Blizzard_CombatLog.lua:1860: in function <...Blizzard_CombatLog\Blizzard_CombatLog.lua:1855> ...Blizzard_CombatLog\Blizzard_CombatLog.lua:2270: in function <...Blizzard_CombatLog\Blizzard_CombatLog.lua:2037> ...Blizzard_CombatLog\Blizzard_CombatLog.lua:681: in function <...Blizzard_CombatLog\Blizzard_CombatLog.lua:674> Locals: filterSettings = <table> { quickButtonDisplay = <table> { } onQuickBar = true settings = <table> { } hasQuickButton = true name = "All me" tooltip = "" colors = <table> { } filters = <table> { } } timestamp = 1416711588.026 event = "SPELL_PERIODIC_MISSED" hideCaster = false sourceGUID = "Player-3684-071B55FF" sourceName = "Pïp-Mal'Ganis" sourceFlags = 132370 sourceRaidFlags = 0 destGUID = "Player-4-00004628" destName = "Farmbuyer" destFlags = 1297 destRaidFlags = 0 settings = <table> { abilityHighlighting = true lineColoring = true spellBraces = true sourceColoring = true showHistory = false destColoring = true amountHighlighting = true schoolNameColoring = true abilitySchoolColoring = false sourceBraces = true missColoring = true itemBraces = true abilityColoring = true amountActorColoring = false textMode = "A" destBraces = true timestamp = true actionColoring = false fullText = false lineColorPriority = 1 lineHighlighting = true abilityActorColoring = false actionHighlighting = false schoolNameActorColoring = false schoolNameHighlighting = true unitBraces = true noMeleeSwingColoring = false unitIcons = true hideDebuffs = false amountSchoolColoring = false amountColoring = true unitColoring = true hideBuffs = false timestampFormat = "%H:%M:%S" braces = true actionActorColoring = false } lineColor = <table> { a = 1 b = 1 g = 1 r = 1 } sourceColor = nil destColor = nil braceColor = "FFFFFFFF" abilityColor = "FFFFFF00" textMode = "A" timestampEnabled = true hideBuffs = false hideDebuffs = false sourceEnabled = true falseSource = false destEnabled = true spellEnabled = true actionEnabled = true valueEnabled = true valueTypeEnabled = true resultEnabled = true powerTypeEnabled = true itemEnabled = false extraSpellEnabled = false valueIsItem = false schoolEnabled = true withPoints = false forceDestPossessive = false schoolString = nil resultStr = nil formatString = "%s %s %s %s %s. %s %11$s" spellId = 55095 spellName = "Frost Fever" spellSchool = 16 extraSpellId = nil extraSpellName = nil extraSpellSchool = nil nameIsNotSpell = nil extraNameIsNotSpell = nil amount = nil overkill = nil school = nil resisted = nil blocked = nil absorbed = nil critical = nil glancing = nil crushing = nil overhealing = nil multistrike = nil missType = "ABSORB" isOffHand = nil amountMissed = nil auraType = nil itemId = nil itemName = nil valueType = 1 extraAmount = nil powerType = nil alternatePowerType = nil environmentalType = nil message = nil originalEvent = "SPELL_PERIODIC_MISSED" remainingPoints = nil unconsciousOnDeath = 0 subVal = "SPELL" defaultCombatLogLineColor = <table> { a = 1 b = 1 g = 1 r = 1 } CombatLog_Object_IsA = <function> defined =[C]:-1 COMBATLOG_OBJECT_NONE = 2147483648 strsub = <function> defined =[C]:-1 CombatLog_String_DamageResultString = <function> defined @Blizzard_CombatLog\Blizzard_CombatLog.lua:1855 format = <function> defined =[C]:-10
No, because battle.net is not "in-game".
Take up rules lawyering with Blizzard, not here.
0
I just noticed that the latest alpha, v4.0.7-5-g77c3a79, has a line in its changelog about fixing combo point bars. (Actually the same line is in a few changelogs, something about how Git+Wowace accumulates entries? Dunno.)
With this version, the same behavior persists, including the incorrect colors and reuse of the same bar for both normal and anticipation points.
0
That's a good point; I suspect that no matter how many disclaimers and caveats were displayed, B_C would still be getting tickets about how the Predicted Approximate Garrison Cache, Maybe column was "buggy".
0
But capping is not hard to avoid. Garrisons generate 1 resource every 10 minutes, so that's about 3 and a half days of not clicking the cache before it fills up. Presumably you're logging on at least twice a week in order to juggle missions and whatnot.
If you want an actual resource count, you'd have to just estimate it. A "data broker"-type plugin could take note of when a given toon clicks the cache, and store the current time. After that, the toon's approximate resources can be queried by taking the difference between the current time versus the stored last-clicked time, and doing some basic math. Might even be able to build that into Broker_Currency or something similar.
0
If you're going to be doing That Kind Of Thing, just delete the cache subdir entirely. Honestly, the time spent figuring out details and typing/pasting in the line for each particular cached file is more than the time it takes to rebuild the entire cache tree.
If you absolutely must snipe individual files while leaving the rest of the cache tree alone, try replacing the locale name with "*", I honestly don't know if CMD.EXE's "IF EXIST" conditional works on wildcards at all. Maybe prepend an 'echo' in front of the action command so you can see what it would have done before trying it for realsies.
If you still need it done and CMD.EXE can't do it, then I'd advise either learning PowerShell (and God have mercy on your brain), or installing a copy of Cygwin and just scripting in whatever language you prefer using (Bourne variant, Perl, Ruby, Lua, etc).
Good call on looking for running processes first. Most people wouldn't think of that.
0
Unit Config -> Player -> General -> Combo Points is enabled. Growth is "left" and "don't hide when empty" is checked to avoid the vertical stretch/shrink spazz on the bars.
Unit Config -> Player -> General -> Aura Combo Points is enabled with all the same settings.
I can see both empty bars at the bottom of my player's unitframe (that is, there's a double-height empty space). However:
1) Nothing is ever drawn in the aura/anticipation bar, only in the main combo points bar. If all 5 combo points are present and an extra one gets generated, the same bar starts filling up again.
2) I changed the aura points color and left the combo points color alone. But the aura points color is used for the combo points also, instead of each using its own.
Looking through the savedvariables file, nothing seems out of place. Looking through modules/combopoints.lua and modules/aurapoints.lua, I can see what they're trying to do but have no immediate ideas as to what's causing either of these bugs. I added some print() statements to dump return values from both versions of :GetPoints and those numbers are being fetched correctly; it's just the visuals that go wrong.
Fiddling with the settings above hasn't yet fixed anything or yielded any insight yet as to what's colliding. I'll keep messing with it but would love to hear what settings are successfully being used by other Anticipation rogues.
0
It might even be fallout from the "rebuild ALL THE THING" problem; if each tag is being rebuilt in parallel, then whatever tag happens to be the last one to finish would have the most recent timestamp on its file.
At the moment, CC 5.1.1.820 keeps trying to offer a very old version as the latest.
edit: Ooooh, I wonder if shifting all the tags to be local tags, and only pushing a single "latest" tag would inhibit this problem? Imma try that once apt-get finishes molesting my bandwidth.
0
At what line? In what file? Which line of code corresponds to that error?
Also, you need to enclose your code in code.../code blocks when posting to the forum, else it loses all indentation and becomes a pain to read.
0
Joining all threads ERROR 255 with ('/home/curseforge/env/bin/hg', 'update', '-C', 'v1.9.6'): }}} {{{abort: No such file or directory: '/media/cf-repositories/packager/hg-local-checkout/wow/rundowniv/mainline/.hg/updatestate' ERROR 255 with ('/home/curseforge/env/bin/hg', 'update', '-C', 'v1.9.0'): }}} {{{abort: No such file or directory: '/media/cf-repositories/packager/hg-local-checkout/wow/rundowniv/mainline/.hg/updatestate' ERROR 255 with ('/home/curseforge/env/bin/hg', 'update', '-C', 'v1.6.1'): }}} {{{abort: No such file or directory: '/media/cf-repositories/packager/hg-local-checkout/wow/rundowniv/mainline/.hg/updatestate'There's more, but it gets aged off the webpage before I can capture the text. It then proceeds to repackage every tag and every commit in the project.
That reminds me, I need to stop putting a redundant 'v' in front of the version string.
0
ooo? Tell us moar!
It's not github, is it? Please don't let it be github. That would suck crocolisk nuts.
0