I tested this myself yesterday ( with index numbers not names ) and there are 2 '1' values on addons that are loadable and enabled. The values listed in wowpedia for GetAddOnInfo function are still valid from my tests and in the order listed.

On my lowbies I don't have DBM enabled and those addons only listed the name, title and notes values.

reason showed as nil for all my addons that I could see, I even tried enabling addons that had missing requirements.

security showed as INSECURE for all addons whether enabled or not. there may be values after that but when checked manually they always appeared as nil.

Not only that, but an addon can have different titles for different languages, and some authors include the version number in the title (though they really shouldn't do that). Nobody should ever use the Title field as a means of detecting particular addons. If you've seen some resource recommending this practice, or an addon doing it, please tell me what it is so I can go yell at its author. :mad:

Ugh, the change to GetAddOnInfo and related APIs (dropping support for querying by name) is so obnoxious... is there some official forum where Blizzard might actually see complaints about beta API changes? Having to loop over every single addon, query GetAddOnInfo, check the name, and then separately query GetAddOnEnableState is ridiculous. :mad:

I think every patch they flip a coin to decide if they're going to screw with people and make random changes. If it comes up heads, they do, if tails, they don't. When it comes up heads, they spin a wheel to decide what kind of random archaic changes they should do.

I joke about it all the time, but I wouldn't be surprised if I were to find out this is exactly what they do.

This also has the implication that one can't call GetAddOnInfo and the like on Blizzard addons, not that I know of a reason why one would want that. I also don't find GetAddOnEnableState particularly useful. You could get this info from GetAddOnInfo's fifth return (named "reason" in previous posts in this thread). If reason is not "DISABLED" then the addon is enabled.

Apart from that the old behavior of GetAddOnInfo is easily achieved by creating an addon_name = addon_index dictionary, isn't it? I do believe this is just like how GetSpellInfo used to return empty strings instead of nil for non-existent spells - they'll change it back.

GetAddOnEnableState is theoretically useful; while GetAddOnInfo only tells you whether the addon is enabled on the currect character, with GetAddOnEnableState you can get a bit more detail:

Addon is enabled on all characters:
GetAddOnEnableState(nil, index) => 2
GetAddOnEnableState("Charname", index) => 2

Addon is only enabled on some characters, including the current one:
GetAddOnEnableState(nil, index) => 1
GetAddOnEnableState("Charname", index) => 2

Addon is only enabled on some characters, but not on the current one:
GetAddOnEnableState(nil, index) => 1
GetAddOnEnableState("Charname", index) => 0

Addon is not enabled on any characters:
GetAddOnEnableState(nil, index) => 0
GetAddOnEnableState("Charname", index) => 0

The only real use I can think of for this information is in addon managers; the new in-game Blizzard addon manager is the same one that you can use at the character screen, including the "all/character" dropdown, though you can only choose "All" or the current character when using it in-game.

Yeah, but that's still annoying, and requires a significant increase in code clutter and complexity for no apparent reason. LoadAddOn can still handle names, so it's not like they just decided to remove the ability to identify addons by name on the C side. They just disabled the functionality for certain API functions because ... well, because.

If all they wanted was to stop people from being able to disable the Blizzard_* addons, they should have just done that instead of breaking the whole API.

Was IsAddonLoaded's usage changed as well?

Still working the same as is LoadAddOn but you never know what the next build will bring.

I don't think they can change LoadAddOn to require an index, since they use it to load their own addons, which cannot be accessed by index.

It was more to emphasize that they're not getting rid of using addon names so changing to index seems eeerr, pointless.

And what if thats the reason for this change? I mean loading those addons in the wrong order often causes trouble. What if we're no longer supposed to load system addons?

As I said in an earlier post, if their goal was to prevent third-party addons from doing anything with Blizzard addons, they could have just made third-party addons unable to do anything with Blizzard addons, rather than screwing up an entire category of API functions.

From my experience tonight with Ackis Recipe List on the latest beta build (18833) the return values for GetAddOnInfo() are actually:


Though I didn't actually check that newVersion or anything beyond existed.

Ahh... I see why AddonLoader (among others) is now broken.

I want to be able to check if an addon is enabled without having to mess my code with loops on all my addons, so I made a library for this: https://github.com/Jaliborc/AddonList-1.0 (yeah, feels stupid to have such a small lib, but crappy APIs lead to crappy solutions). Just in case someone is interested.

Since the list of addons cannot change during a session, you should just create a static name->index table, and use a simple table lookup to get the index for the requested name, instead of calling a function that loops over all addons and calls more functions every time.

Yeah, you're right. Though about it, but I never seen anyone checking an addon information on performant critical situations (just checking if it is enabled to react accordingly, for example), so I did not worry about it. But caching the indexes certainly scales better. I'll change it.

Changes in 18837:

Basically reverting their change.

Victory! \o/

Victory for common sense.

Blizz' still in desperate need of more of that...