Our records show that you have outstanding author rewards points. Please confirm your latest payment information and redeem your points balance via the Author Reward Store.
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/.
Here's a few things I discovered or made use of updating Pokedex. I wanted to remain responsive the changes in the number of pets while trying to avoid getting entangled in PET_JOURNAL_LIST_UPDATE games of tag.
I added pets by purchasing and using a vendor item as well as capturing some wild pets via pet battle; I removed pets via cage and releasing. I did not see any COMPANION_LEARNED or COMPANION_UNLEARNED events as a result.
PET_JOURNAL_PET_DELETED is nice in that in also provides the pid of the pet removed and is received after the pet has been removed from the list. However, this event does not appear to fire if you release a pet, only when you cage one.
To catch when a pet is released you can SecureHook(C_PetJournal, "ReleasePetByID"). The pid will again be passed as a param and your hook called after removal from the list. Oddly, hooking CagePetByID is not as useful as the DELETED event because the hook gets called before the removal has actually happened.
For additions, I'm looking for CHAT_MSG_SYSTEM events and then trying to match the message to BATTLE_PET_NEW_PET minus the %s part. Of course, you can't assume that there isn't a locale where the %s is in the middle of fixed text, so I might have to break it into multiple substrings. This paste has my approach for that http://www.wowace.com/paste/6185/. This system message fires for pets bought from a vendor, readded from pets I caged or trapped in the wild; not tested against additions from achievements or any other form of acquisition. The one problem with this approach is that you will get the system message before the actual addition. So, what I do in that case is register for the list update event and then as soon as I get it I unregister again. Not really ideal, but I can't find a better method.
I also noticed some odd behavior if I try to access the C_PetJournal before the first LIST_UPDATE event has fired. If no calls have been made against any of the filtering functions, even if they would not result in the filter setting changing, then the PetJournal would actually return the correct counts from GetNumPets but every pet would return as not being summonable (like a horde balloon on an alliance character). Since the count wouldn't change, I wouldn't rebuild the list and would think the user had no summonable pets. If you call a filter function, even to set it to its current value, the PetJournal instead will return 0,0 for GetNumPets until after the first LIST_UPDATE. I touch a filter during OnInitialize now to try to make sure the pet journal is in that better state. I suppose the only reason I could even get into this state is that I wrote my filter handling code so that if the filters are already in the exact config I want then I won't make any calls; my way of trying to avoid generating unecessary LIST_UPDATE spam. So, the scenario also required the filters to be in the config I use for my list checking.
Its so lame that an addon attempting to determine whether the number of pets owned has changed, in response to a PET_JOURNAL_LIST_UPDATE event, may need to change the filtering of the PetJournal to do it triggering further PET_JOURNAL_LIST_UPDATE events ...
That's going to be fun if a user has multiple addons monitoring and reacting to that event. Even if each is written to temporarily ignore that event whenever it is twiddling the filters to make a pass at the list, which they pretty much have to be if they don't want to worry about infinite loops, you'll still have each addon triggering numerous spurious events for the others to process ...
For my addon, I don't think I'm even going to bother registering for the PET_JOURNAL_LIST_UPDATE event. I've already stuck the data behind an empty table and an __index metamethod to ensure that I always validate and update if necessary before using it. I think the only gain I get from the event is when my UI is up at the same time as a pet is added; it lets me know I need to fire off a LibStub("AceConfigRegistry-3.0"):NotifyChange.
What they really need is a PET_JOURNAL_PET_ADDED event to complement the PET_JOURNAL_PET_DELETED they already have.
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:
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?
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/.
0
I added pets by purchasing and using a vendor item as well as capturing some wild pets via pet battle; I removed pets via cage and releasing. I did not see any COMPANION_LEARNED or COMPANION_UNLEARNED events as a result.
PET_JOURNAL_PET_DELETED is nice in that in also provides the pid of the pet removed and is received after the pet has been removed from the list. However, this event does not appear to fire if you release a pet, only when you cage one.
To catch when a pet is released you can SecureHook(C_PetJournal, "ReleasePetByID"). The pid will again be passed as a param and your hook called after removal from the list. Oddly, hooking CagePetByID is not as useful as the DELETED event because the hook gets called before the removal has actually happened.
For additions, I'm looking for CHAT_MSG_SYSTEM events and then trying to match the message to BATTLE_PET_NEW_PET minus the %s part. Of course, you can't assume that there isn't a locale where the %s is in the middle of fixed text, so I might have to break it into multiple substrings. This paste has my approach for that http://www.wowace.com/paste/6185/. This system message fires for pets bought from a vendor, readded from pets I caged or trapped in the wild; not tested against additions from achievements or any other form of acquisition. The one problem with this approach is that you will get the system message before the actual addition. So, what I do in that case is register for the list update event and then as soon as I get it I unregister again. Not really ideal, but I can't find a better method.
I also noticed some odd behavior if I try to access the C_PetJournal before the first LIST_UPDATE event has fired. If no calls have been made against any of the filtering functions, even if they would not result in the filter setting changing, then the PetJournal would actually return the correct counts from GetNumPets but every pet would return as not being summonable (like a horde balloon on an alliance character). Since the count wouldn't change, I wouldn't rebuild the list and would think the user had no summonable pets. If you call a filter function, even to set it to its current value, the PetJournal instead will return 0,0 for GetNumPets until after the first LIST_UPDATE. I touch a filter during OnInitialize now to try to make sure the pet journal is in that better state. I suppose the only reason I could even get into this state is that I wrote my filter handling code so that if the filters are already in the exact config I want then I won't make any calls; my way of trying to avoid generating unecessary LIST_UPDATE spam. So, the scenario also required the filters to be in the config I use for my list checking.
0
That's going to be fun if a user has multiple addons monitoring and reacting to that event. Even if each is written to temporarily ignore that event whenever it is twiddling the filters to make a pass at the list, which they pretty much have to be if they don't want to worry about infinite loops, you'll still have each addon triggering numerous spurious events for the others to process ...
For my addon, I don't think I'm even going to bother registering for the PET_JOURNAL_LIST_UPDATE event. I've already stuck the data behind an empty table and an __index metamethod to ensure that I always validate and update if necessary before using it. I think the only gain I get from the event is when my UI is up at the same time as a pet is added; it lets me know I need to fire off a LibStub("AceConfigRegistry-3.0"):NotifyChange.
What they really need is a PET_JOURNAL_PET_ADDED event to complement the PET_JOURNAL_PET_DELETED they already have.