Compaions API broken ?
Hi,
I am trying to make an addon about companions / pets but I always get an error when I use the function: Lua Code:
where index <= GetNumCompanions("CRITTER") The error is something like in English "You don't have any pets" (in italian is "Non hai un famiglio"). But a simple for loop print the name of all my pets: Lua Code:
Also the other summon function Lua Code:
gives to me the same error. Probably the new pet combat system broken the api. Am I looking in a wrong place for outdated documentation ? (http://wowprogramming.com and http://www.wowwiki.com/API_CallCompanion) Should I use an external library like LibPetJournal ? Or simply I missing something ? :-) Thanks in advance for any help. |
The code you posted will only work for old-style (pre 5.x) pets. You'll need to use the C_PetJournal functions for them now to access both old and new-style. Take a look at some of the newer Pet-centric AddOns (such as Pet Theory) for some code examples.
I'd use WoWPedia over WoWWiki, as it's much better maintained. |
To clarify, the old API functions will still work for any companion pets your character had before Patch 5.0.4, but they will not work for any companion pets that were originally learned by one of your other characters before Patch 5.0.4 (even though they are now "known" by all of your characters), and they will not work for any companion pets learned by any character after the release of Patch 5.0.4.
|
1 Attachment(s)
Ok I made a little addon to summon a random companion fom the full collection or from a custom category is defined.
Like mine first addon you can define some samples category like: Lua Code:
and then use the magic way "Phanx" macro :-) to use the program: Quote:
There is a little "help" switch to show the available options. I post it here so I hope that someone can give it a try to check it before I commit to the public :-) Thanks again to you for all the help and suggestions. |
- first little bug I have found: /gimb remove could not be launched in a macro.
"gimbolino unable to find category remove" Uhm ... I think I should check the args parsing ... this unknown thing ! :-) Any tips are welcome :-) |
I'm trying to find the problem too, but I'm not seeing it. I'm at work now, I'll have to run the code later and poke around in it.
|
Could it be due the fact that only category is parsed in the "SecureCmdOptionParse" function ? If I add the call also for args ...
Quote:
In this way it seems to work... but is it fine ? macro like: /gimb [btn:2] rare; [mod:alt] funny; [mod:shift] remove; |
1 Attachment(s)
I also added a declaration of :
-- if categories.lua is not found pets = {}; otherwhise it triggers an error if trying to summon from a category when the category.lua is missing. Now it returns with "category not found message" much more friendly :-) and modified the toc files in this way: core.lua categories.lua if the order of definitions is important. I think now it should be ready to be committed ... |
1 Attachment(s)
If you do this:
Code:
local category=SecureCmdOptionParse(args); After looking through your code, I see that you're currently creating a global named pets. This is a really bad idea, since pets is a very generic name, and any other addon that creates a global variable with the same name (even by accident) will overwrite it, breaking your addon (or theirs). I'd suggest using the "private namespace table" that all addons get nowadays. Put this at the top of each of your Lua files: Code:
local _, pets = ... Also, your example macro in the comments in the addon file: Code:
/gimb [btn:2] rare [mod:alt] funny [mod:shift] remove Code:
/gimb [btn:2] rare; [mod:alt] funny; [mod:shift] remove See attached file for these modifications, plus some general cleanup. |
I removed the LibPetJournal-2.0 library and converted the code to use the C_PetJournal API directly. I also made the code a bit more verbose as well as added the ability for the user to modify the categories in-game through the chat command system. Categories should now be saved across sessions too. The new code also uses an experimental method of unregistering the filter update event before setting them to what it needs, then resetting them to the previous settings before restoring the event. This should improve performance slightly since it'll prevent the filter update from running unnecessary code while Gambolino is trying to work.
Code:
Gimbolino usage |
All times are GMT -6. The time now is 05:55 PM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI