Authors CurseForge

Quote from Myrroddin >>

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.

Quote from Myrroddin >>

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.

Quote from Myrroddin >>

Go with the all-new URLs for dependencies in your pkgmeta.

Quote from Myrroddin >>

Yes, you need to update your pkgmeta with all new URLs.

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

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.

Quote from Dridzt

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.

Quote from endx7

*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.

Quote from Shadowed

Nevermind, it was my fault. It's fixed.

Fixed for Affliction and Demonology, but not working with Destruction. The space for them is there, unlike before, but its always empty. Its not showing the embers I have.