How To Make AddOn Options?

laukond · 02-03-12, 01:38 PM

Could someone show this through an example please?
Simply write two addons:
One that on /minimap show/hide - shows or hides the minimap.
A second one that does the same thing, but can be toggled on/off through ESC -> Interface -> AddOns.

Thank you very much

VagrantEsha · 02-03-12, 02:25 PM

Your best bet is to use AceConfig, really. It's the least painful way of doing it. I've looked at a lot of libraries but many of them are so obfuscated or assume so much knowledge on part of the coder (because coders can read minds!) that attempting to use them is like pulling teeth.

So, yeah. There are a lot of libraries out there, but the only one that's not going to put you into some sort of exasperation induced coma is AceConfig. I did a lot of this research when I was looking to create a BlizzOptions panel for my mod Vault.

I don't really like how AceConfig is so tables and table recursion obsessed because lua is horrible (horrible!) with tables, so it could use a rewrite, if I'm being honest. That said, however, it's stil the best option out there right now and the easiest one for people to use.

So here are some links!

http://www.wowinterface.com/download...700-Vault.html - You can take a look at my BlizzOptionsModule.lua file to see how it all works, it tends to be very self explanatory. You can compare what you see in game with the code. I'm pointing out this since it's a nice, simple options module, and self-contained.

http://www.curse.com/addons/wow/ace3 - You can get all Ace3 related gubbins here, but the only parts you need are LibStub, CallbackHandler, AceConfig, and AceConfigRegistry.

http://www.wowace.com/addons/ace3/pa...ce-config-3-0/ - This the AceOptions API.

http://www.wowace.com/addons/ace3/pa...ptions-tables/ - This is the options tables API.

That should get you on the right path!

Happy modding! And don't let it stress you out too much, eh?

laukond · 02-03-12, 02:28 PM

Originally Posted by VagrantEsha

Your best bet is to use AceConfig, really.

I really, really do NOT want to use libaries.

Waky · 02-03-12, 03:02 PM

You could take a look at this page it should have everything you need to know about integrating options into WoW's default AddOn options.

**Seerah** · 02-03-12, 03:30 PM

Originally Posted by VagrantEsha

Your best bet is to use AceConfig, really.

Honestly, using AceConfig is overkill for one option.

Phanx · 02-04-12, 06:53 AM

Originally Posted by laukond

I really, really do NOT want to use libaries.

If you're objecting to libraries because you want to learn how to do things by hand first, that's fine. Otherwise, you just sound like the masses of uninformed people crowing about their "low memory" addons/UIs.

Using libraries does not automatically make an addon less efficient, and not using libraries does not automatically make an addon more efficient. In most cases, using a library improves overall efficiency because users will have multiple addons using the same library (code is only loaded in memory once, and shared between all addons), and it certainly saves time for you as a developer. The only thing that matters is how well you write your addon. If you write bloated code, avoiding libraries is probably counterproductive; if you write clean code, using libraries properly will not magically turn your addon into a bloated mess.

laukond · 02-04-12, 07:50 AM

Originally Posted by Phanx

Otherwise, you just sound like the masses of uninformed people crowing about their "low memory" addons/UIs.

Thank you for your reply. You're very right I am very much uninformed when it comes to libaries, and I do have the belief that libaries are bad (just because I don't know better).

Would you mind telling me what libaries do and how to use them wisely?

**Seerah** · 02-04-12, 01:38 PM

She already touched on this point.

Using libraries does not automatically make an addon less efficient, and not using libraries does not automatically make an addon more efficient. In most cases, using a library improves overall efficiency because users will have multiple addons using the same library (code is only loaded in memory once, and shared between all addons), and it certainly saves time for you as a developer.

Think of libraries as an extra layer of API you can use. Any addon that wants to can use this API, you just need to have the library that includes the code installed as well. Most addons come with the libraries they wish to use in order to make sure that you will have them installed. If you have more than one addon installed that includes the same library, only one will be used to save on memory.

Xuerian · 02-04-12, 06:41 PM

Honestly, for your need of a button to toggle it in interface options, here is a basic reference.

lua Code:

local frame = CreateFrame('Frame', 'MyConfigPanel', UIParent)
frame.name = 'MyAddon'
-- create a button and attach it to frame here
InterfaceOptions_AddCategory(frame)
 
-- Show the panel somewhere, ex slash handler
InterfaceOptionsFrame_OpenToCategory(frame)

It's really pretty simple.

Now, as far as a full-on config goes, use Ace3's AceConfig. This coming from someone who wanted to shun libraries and ended up rolling his own when he realized he needed to do the same thing for more than one addon.

As everyone else has basically stated, as soon as another addon uses the lib you used, the code is shared - only one copy of the library stays loaded in memory.

Phanx · 02-06-12, 07:59 AM

Originally Posted by laukond

Would you mind telling me what libaries do and how to use them wisely?

Let's say you want 10 checkboxes in your addon's config panel. You can either:

(1) write 50 lines of code per checkbox to define its size, position, textures, font strings, clickable regions, and script handler functions, for a total of 500 lines of code, or:

(2) write 40 lines of code inside a function, and then call that function 10 times to create 10 checkboxes, and then add 10 lines of code per checkbox to set its position, its text, and its script handlers, for a total of 150 lines of code.

Obviously #2 is more efficient, and will be much easier to maintain, since if you want to change how all the checkboxes look, you only need to change what's inside the "make a checkbox" function, instead of changing the same lines for every checkbox. #2 also makes it much easier to add new checkboxes, since you don't have to copy/paste/edit 50 lines of code every time you want to add a checkbox. You just call the function again to make another checkbox, and add a few lines to position it correctly.

A library is nothing more than doing #2 on a bigger scale.

Let's say you want to write a second addon, and add some checkboxes to its options window. Now you can:

(1) copy/paste your 40-line function into your second addon, for a total of 80 lines of code and two functions loaded in memory, or:

(2) put that 40-line function in a separate file and make it into a library, so that only 40 lines of code and one function is loaded into memory.

Again, #2 is clearly more efficient, especially when you look at libraries that are used by thousands of addons. Even if a user is running 100 addons that use the same checkbox library, they will still only have 1 copy of the "make a checkbox" function loaded in memory.

Now let's say that someone else already wrote a library to make checkboxes. Think of how much time you can save by simply using their checkbox making function(s) instead of writing your own. Plus, if there's ever a problem, or the code needs to be updated because of a game patch, it only needs to be updated in one place (the library) instead of in many places (every addon using its own checkbox code).

There can be downsides to using libraries, though.

(1) There will necessarily be some overhead by putting code into a library instead of just putting it in your addon. Mainly, this is because the library needs to have extra code to provide easy ways for addons to use it. This overhead is usually minimal (assuming the library is well written), and when the library is shared, overall efficiency is still improved.

(2a) Because a library needs to be used by many addons, it has to be very generic, and this can lead to the library becoming bloated by trying to accomodate all possible uses.

(2b) On the other hand, if a library remains very specialized, that limits what kind of addons can use it, so it becomes less efficient overall when it isn't shared. If a library is so specialized that most people will only be running one addon that uses it, then it probably shouldn't be a library in the first place.

(3) There are also some libraries that don't really do anything, yet are in widespread use anyway, for reasons I can't fathom. AceEvent-3.0 is a good example of this; it doesn't do anything that the basic frame:RegisterEvent(event) and related API does not do, and is probably less efficient since it's doing all the work in Lua code instead of letting the client handle it in much faster C code. There was probably some reason for its creation, but nobody seems to remember what it was.

Basically:

(1) If a library provides a common function, has a clear benefit over doing it yourself, and is used by many addons, it is probably a good option.

(2) If a library provides a very specialized function, has no apparent benefit over doing it yourself, or is not used by very many addons, you should think very carefully before using, or not use it at all.

(3) If a library is bigger than your entire addon, it is probably overkill for your addon, and you should probably look for a smaller library, or not use one for that function.

(4) If you only want one or two checkboxes, it's probably better to just write them yourself. If you want many checkboxes, dropdowns, sliders, and buttons, using libraries is probably a good option that will save you a lot of time and headaches, without sacrificing much (if any) efficiency. A well-written library will not impact the user's performance enough for them to notice it, if it does at all.