m
Move page script moved page Creating defaults to WoW:Creating defaults without leaving a redirect
m (→The Next Step) |
m (Move page script moved page Creating defaults to WoW:Creating defaults without leaving a redirect) |
||
| (4 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
This is a basic HOWTO to help you create defaults for your addon. First, I'm going to assume you are at least familiar with how to start an addon, and make it save variables. If not, please check out [[AddOns|this page on how to start an addon]] and [[ | This is a basic HOWTO to help you create defaults for your addon. First, I'm going to assume you are at least familiar with how to start an addon, and make it save variables. If not, please check out [[AddOns|this page on how to start an addon]] and [[Saving variables between game sessions]]. This is required knowledge for our defaults. | ||
== The Basics == | == The Basics == | ||
| Line 14: | Line 14: | ||
}; | }; | ||
Now for an | Now for an explanation... | ||
* local ThisAddon_Defaults - This one is easy enough. First, we declare that our defaults are local to this LUA file only. If you choose not to use local, then any addon can use your defaults. Removing the "local" may be needed if you expand your addon's need for defaults beyond a single file. Second, we give the library of defaults a name. In this case, I choose to use the Addon's Name, then _Defaults. This naming convention is a good idea even if you keep the "local". | * local ThisAddon_Defaults - This one is easy enough. First, we declare that our defaults are local to this LUA file only. If you choose not to use local, then any addon can use your defaults. Removing the "local" may be needed if you expand your addon's need for defaults beyond a single file. Second, we give the library of defaults a name. In this case, I choose to use the Addon's Name, then _Defaults. This naming convention is a good idea even if you keep the "local". | ||
** ["Options"] - The name of the table our Options defaults are in. I recommend this in case you need to add more defaults and don't want them intermingling. For example, a list of defaults for items should be | ** ["Options"] - The name of the table our Options defaults are in. I recommend this in case you need to add more defaults and don't want them intermingling. For example, a list of defaults for items should be separate from your options. | ||
*** Your variables - These are how your variables should be set when installing a fresh copy of your addon. | *** Your variables - These are how your variables should be set when installing a fresh copy of your addon. | ||
** End our list of option variables. | ** End our list of option variables. | ||
| Line 33: | Line 33: | ||
==== The XML ==== | ==== The XML ==== | ||
First off, we need to make a function that we call when our addon has finished loading... To do that, first we need to add a line to the OnLoad section of our XML file. | First off, we need to make a function that we call when our addon has finished loading... To do that, first we need to add a line to the OnLoad section of our XML file. | ||
| Line 79: | Line 77: | ||
== The Future... == | == The Future... == | ||
=== The | === The Possibilities === | ||
There's even more we can do with Defaults. You'll noticed that I added ["version"] to the list of defaults at the top. There is an excellent reason for this. | There's even more we can do with Defaults. You'll noticed that I added ["version"] to the list of defaults at the top. There is an excellent reason for this. | ||
| Line 119: | Line 117: | ||
* End this action. | * End this action. | ||
== Advanced Default Setting Updating == | |||
Having worked with this for so long now, I've developed even more advanced methods for using these defaults. | |||
The first thing I've done is seperated the update code from the loading code, so it is it's own function. Another change I've made is that it can now work with tables within tables. The following can work with up to 3 levels of tables within your defaults. (Main level, 1 subtable, and a subtable within that.) | |||
You will also notice that if the version you are upgrading from is below or equal to version 1.2, then an error message will be displayed using a custom message display function. (Which I won't get into here.) This is useful if you've made major database changes and don't feel like making an adaptor for the settings. A common use of this would be if you had a lot of settings, but decided to move them into a subtable. This would ensure the old settings were erased. This functionality should be used sparingly. | |||
function ThisAddon_OptionUpdate() | |||
local temp = ThisAddon_Defaults["Options"]; | |||
if (ThisAddon_Settings["Version"]) and (ThisAddon_Settings["Version"] <= "1.2") then | |||
ThisAddon_Error_Msg("Your Database is Severely out of date. Some settings may not have carried over."); | |||
else | |||
for k,v in pairs(ThisAddon_Settings) do | |||
if (type(ThisAddon_Settings[k]) == "table") then | |||
for k2,v2 in pairs(ThisAddon_Settings[k]) do | |||
if (type(ThisAddon_Settings[k][k2]) == "table") then | |||
for k3,v3 in pairs(ThisAddon_Settings[k][k2]) do | |||
if (ThisAddon_Settings[k][k2][k3]) then | |||
temp[k][k2][k3] = v3; | |||
end | |||
end | |||
else | |||
if (ThisAddon_Settings[k][k2]) then | |||
temp[k][k2] = v2; | |||
end | |||
end | |||
end | |||
else | |||
if (ThisAddon_Settings[k]) then | |||
temp[k] = v; | |||
end | |||
end | |||
end | |||
end | |||
temp["Version"] = ThisAddon_Version; | |||
ThisAddon_Settings = {}; | |||
ThisAddon_Settings = temp; | |||
end | |||
Now let's go through this; | |||
*The function's name. | |||
** Copy the new defaults into a temp variable. | |||
** Here is the detection of an out-of-date database that can't be updated like normal. Will only fire if it detects an old version. | |||
*** What to do if it's out of date. (Send an error message so they know!) | |||
** Otherwise... | |||
*** For every variable in your current settings... | |||
**** If it's a table... | |||
***** Now we run through the subtable. | |||
****** If it's a table... | |||
******* You get the idea. (This function is repeated for the 2nd subtable.) | |||
****** If it's not a table... | |||
******* If the setting exists... | |||
******** Update it! | |||
***** End subtable. | |||
**** If it's not a table... | |||
***** If the setting exists... | |||
****** Update it! | |||
** Update the temp var's Version number. | |||
** Delete all the old settings. Technically, we shouldn't have to do with our next command, but this ensures that the old settings are deleted first. | |||
** Copy the temp variable into our settings. | |||
* End function | |||
That's the basics of this new setting. The best thing is, now in our Post-Load function, instead of writing all that out, we just call: | |||
if (not ThisAddon_Settings["Version"]) or (ThisAddon_Settings["Version"] < ThisAddon_Version) then | |||
ThisAddon_OptionUpdate(); | |||
end | |||
Now you can do even more with defaults! If you come up with something new and original, put it on this HowTo's Discussion page! I'd love to see how people use this! | |||
[[Category:HOWTOs|Create Defaults]] | [[Category:HOWTOs|Create Defaults]] | ||