I'd still be interested to know how to fix the old Accountant just to know how to do it. To improve my understanding of things. I think I've got a good grasp of lua (fun with metatables), but wow UI is something I'm still weak on.
Is "All Characters" in Acc Classic still server specific like it was in Accountant? I've hacked up my local copy so that the totals are for all my characters.
I'd sort of hate to lose the history I have. I guess I could always go in and manually edit the accountant classic saved settings file. But making the background show right seemed like it would take less time :)
I'm using Accountant and it is not being skinned, it's transparent
If you run without skinner enabled it has the same problem; its an Accountant problem. I'm sure its related to the change made so that frames don't have backdrops by default, but I haven't figured out how to fix it. I suspect the relevant bits are in Accountant.xml here:
I tried having the frame include BackdropTemplate but I did it wrong or something else was needed because it didn't fix the issue. Anyone happen to know how to fix that?
EDIT: here is what I had tried replacing that section with. The frame inherited from BackdropTemplate and I replaced the backdrop section with a reference to a blizzard backdrop which had the same values. It didn't work; the background was still transparent.
Something changed in ace a while ago (sometime during BFA I think) that has caused the entries in my dropdowns to no longer be sorted correctly.
The table I give to the select control has key-value pairs that are table-string. The key objects all share the same metatable where I define an __lt function for the class. This allows native lua operators like < and > to work which means table.sort works when those objects are the values of the table.
In the past this meant that the table I gave to the select control displayed the values (strings formatted for display) in the same order you would get running sort on a table of the keys. Users could select a different sort type and under the covers the __lt metamethod would just return a different sort function. It all worked nicely.
Now, the display order matches that of a sort run on the keys after tostring() operation. That is to say, the value keyed by "table: 000001D66FB2EE30" appears above the one keyed by "table: 000001D67106CF50".
So, is this a bug that crept in and might be fixed or was this a deliberate change I'll have to work around or redesign for?
I quite liked that the items in the drop down list were the things themselves, my actual objects. A situation where it was an ordered table with the objects as values and we provide you the function to call on those values to generate the display name would have been good too. I'd like to avoid the situation where I have to keep two tables in sync with another.
As for that project specifically, I am not going to poke around at it, but it is possible the maintainer or project manager switched the repo from the new system back to the legacy URL in the Source settings. I don't recommend that, but it is possible.
Also, any library that is hosted on an external repo won't impact the pkgmeta and its pass/fail on creating zips. For example, anything hosted on Gitforge, Sourceforge, etc, won't require updating.
The source is listed as repos.wowace and I had to enter credentials to check in (versus the old putty and ssh thing). Bartender4 is another git project with a repos.wowace source which appears to get packaged correctly despite a pkgmeta which still has the old style urls.
Ironically, the knowledge base article is outdated and incorrect. It was a copy/paste from the version on the old Curseforge site. The article itself was not significantly edited or error-corrected after the transition.
I figured it was a copy/paste job but I was also kind of annoyed that the knowledge base didn't have better documentation to help plebs like me transition their projects over. I saw an opportunity to bitch about in a passive aggressive manner and ran with it!
Both work. The first url for LibStub has a toc file and tests directory and test files where the second gives you LibStub.lua only. I don't think there were any resultant differences between two CallbackHandler urls.
I was updating one of my projects (PounceCam, svn) and the packager kept failing until I updated the lib urls in .pkgmeta (and svn:externals which I thought shouldn't matter as far as the site is concerned). On the other side of the coin, there is a project I'm a contributor for (Am I locked out?, git) whose .pkgmeta has not been updated yet packaged up fine the last time I made a bug fix (Dec 21).
So ... I'm a little bit confused here about what's going on and what is the correct thing to do.
The thing is, I've seen that error before. It was during the Beta when they changed functions from returning icon paths to instead returning an image id and it has been fixed in Ace 3 since before the pre-patch rolled out.
So, one thing I noticed in the two stack dumps I received from users is "AceConfigDialog-3.0-63" in the path. I believe the minor version of that file in the current release of Ace3 is 61. So, my hypothesis would be that some addon is getting bundled up with a version of AceConfigDialog stamped with a higher version number than the current release, but which is missing the fix for the change to images. That version of the lib is getting loaded and my addon breaks as a result. I've asked one of the users who reported the bug if they could check every version of that file in their addons folder to see if one has a minor version number of 63.
Would I be right in interpreting things that way? Can anyone shed any light on this?
Change "PLAYER|HELPFUL" to "HELPFUL". You're filtering for helpful buffs cast by yourself and, as you heard, the weapon enchant procs aren't cast by the player.
Just as an FYI, I'm seeing a problem where if I'm using both Clique and Shadowed Unit Frames I don't get the menu (for doing things like dropping group) when I right click on my character frame.
The problem doesn't reproduce if I have Clique and the games default frames or if I run with SUF enabled but Clique disabled.
He's saying using the Mount Journal and having the game call _G.CallCompanion doesn't trigger CallCompanionHook.
Yeah, if it had just been the call in my code that wasn't triggering the callback I wouldn't have posted. It was the callback not getting triggered by the mount journal that I couldn't understand.
However, I can't seem to reproduce the problem anymore, which is very frustrating. :(
Sticking a print statement in the callback makes it simple enough to test. I've no idea how I could have screwed it up but unless I can get it reproing again we have to assume the problem was me. Sorry for wasting people's time.
I was investigating a bug last night and found that the handler for the SecureHook I had set on a blizzard function does not get called if I also set an upvalue for that function for my own calls to it.
So basically, I had:
local _G, CallCompanion = _G, CallCompanion
function Addon:OnEnable()
self:SecureHook("CallCompanion", "CallCompanionHook");
The game calls CallCompanion if you open the Mount Journal, select a mount and click the button to summon it. My handler function would only get called if I removed the upvalue for CallCompanion.
Can anyone shed some light on why I'm seeing this behavior?
FWIW, I make use of svn:externals in the same way and for (I think) the same reasons as Phanx.
If someone has synched one of my repositories and disabled all other addons but that project, it should load and run correctly. If it doesn't, then I would feel like my project wasn't properly configured. Using svn:externals seems like the best way to accomplish that.
*sigh* Okay, I fixed a bunch of bugs where I wasn't even able to follow my own example code that I posted.
Also there was strange issue where I was getting PJLU despite having unregistered it.
I hit some weird reentrance/recursion type issues with my filters as well. I thought I'd written in a way to prevent that and never did track down exactly how I got in those states. I have my suspicions, but I just rewrote a couple bits to hopefully handle the situation correctly.
For PJLU I'm using a counting scheme. Calls to Suspend reduce the count by 1 while calls to Resume increase the count by 1. We only call RegisterEvent and UnregisterEvent when the count becomes 1 or drops from 1 respectively. This way, should we find ourselves filtering inside a filter, the first Resume call won't re-register an the Event the first filter wants suspended. Here's the little class I made for that http://www.wowace.com/paste/6194/.
0
In reply to Galthariel:
0
If you run without skinner enabled it has the same problem; its an Accountant problem. I'm sure its related to the change made so that frames don't have backdrops by default, but I haven't figured out how to fix it. I suspect the relevant bits are in Accountant.xml here:
I tried having the frame include BackdropTemplate but I did it wrong or something else was needed because it didn't fix the issue. Anyone happen to know how to fix that?
EDIT: here is what I had tried replacing that section with. The frame inherited from BackdropTemplate and I replaced the backdrop section with a reference to a blizzard backdrop which had the same values. It didn't work; the background was still transparent.
0
Something changed in ace a while ago (sometime during BFA I think) that has caused the entries in my dropdowns to no longer be sorted correctly.
The table I give to the select control has key-value pairs that are table-string. The key objects all share the same metatable where I define an __lt function for the class. This allows native lua operators like < and > to work which means table.sort works when those objects are the values of the table.
In the past this meant that the table I gave to the select control displayed the values (strings formatted for display) in the same order you would get running sort on a table of the keys. Users could select a different sort type and under the covers the __lt metamethod would just return a different sort function. It all worked nicely.
Now, the display order matches that of a sort run on the keys after tostring() operation. That is to say, the value keyed by "table: 000001D66FB2EE30" appears above the one keyed by "table: 000001D67106CF50".
So, is this a bug that crept in and might be fixed or was this a deliberate change I'll have to work around or redesign for?
I quite liked that the items in the drop down list were the things themselves, my actual objects. A situation where it was an ordered table with the objects as values and we provide you the function to call on those values to generate the display name would have been good too. I'd like to avoid the situation where I have to keep two tables in sync with another.
0
thank you
0
and
Both work. The first url for LibStub has a toc file and tests directory and test files where the second gives you LibStub.lua only. I don't think there were any resultant differences between two CallbackHandler urls.
0
0
User found a version of AceConfigDialog with a minor version of 63 installed with the addon ZygorGuides.
0
I've had a couple of different users report the following error when trying to display the options UI for my addon:
106x ...nfig-3.0\AceConfigDialog-3.0\AceConfigDialog-3.0-63.lua:1818: AceConfigRegistry-3.0-18:ValidateOptionsTable(): Pokedex.args.CtrlGroupMounts.args.CastWithMount.args.MageIceBarrier.image: expected a string or funcref, got '135988'
The thing is, I've seen that error before. It was during the Beta when they changed functions from returning icon paths to instead returning an image id and it has been fixed in Ace 3 since before the pre-patch rolled out.
So, one thing I noticed in the two stack dumps I received from users is "AceConfigDialog-3.0-63" in the path. I believe the minor version of that file in the current release of Ace3 is 61. So, my hypothesis would be that some addon is getting bundled up with a version of AceConfigDialog stamped with a higher version number than the current release, but which is missing the fix for the change to images. That version of the lib is getting loaded and my addon breaks as a result. I've asked one of the users who reported the bug if they could check every version of that file in their addons folder to see if one has a minor version number of 63.
Would I be right in interpreting things that way? Can anyone shed any light on this?
thanks,
Stencil
0
In reference to Talyrius comment (#4), error #1 is fixed simply by adding a comma to the end of line 15
0
0
The problem doesn't reproduce if I have Clique and the games default frames or if I run with SUF enabled but Clique disabled.
0
Yeah, if it had just been the call in my code that wasn't triggering the callback I wouldn't have posted. It was the callback not getting triggered by the mount journal that I couldn't understand.
However, I can't seem to reproduce the problem anymore, which is very frustrating. :(
Sticking a print statement in the callback makes it simple enough to test. I've no idea how I could have screwed it up but unless I can get it reproing again we have to assume the problem was me. Sorry for wasting people's time.
0
So basically, I had:
The game calls CallCompanion if you open the Mount Journal, select a mount and click the button to summon it. My handler function would only get called if I removed the upvalue for CallCompanion.
Can anyone shed some light on why I'm seeing this behavior?
0
If someone has synched one of my repositories and disabled all other addons but that project, it should load and run correctly. If it doesn't, then I would feel like my project wasn't properly configured. Using svn:externals seems like the best way to accomplish that.
0
For PJLU I'm using a counting scheme. Calls to Suspend reduce the count by 1 while calls to Resume increase the count by 1. We only call RegisterEvent and UnregisterEvent when the count becomes 1 or drops from 1 respectively. This way, should we find ourselves filtering inside a filter, the first Resume call won't re-register an the Event the first filter wants suspended. Here's the little class I made for that http://www.wowace.com/paste/6194/.