Updating Compilations

[Killariel]

So I am in the process of udating my compilation and a big part of it was the savedvariables.lua file. Has anyone tried uploading a compiled lua post 1.7 patch yet? I think it would be a huge problem for most UI users to modify the savedvariable files for each addon individually. It is my hope that I can compile them all in pre-patch fashion and the client will divide them up at startup.

If this is not possible, how are some of you other compilation providers dealing with this?


Thanks


Killariel

[Cairenn]

I've dropped a note to Iriel, asking him to pop over and try to help out when he gets the opportunity.

[Kaelten]

on load if a old time saved variables file is present it will divide them up.

However, why, if you don't mind me asking, are you distrubting a savedvariables file?

[Iriel]

During normal startup I believe this is what happens

1) FrameXML code is executed
2) For each enabled addon:
2.1) Addon code is executed (as directed by .toc)
2.2) SavedVariables/AddonName.lua is executed
2.2) ADDON_LOADED is fired (arg1 = addon name)
3) After all of that, the common SavedVariables.lua is executed
3) VARIABLES_LOADED is fired
4) PLAYER_ENTERING_WORLD etc..

So, when going in the first time (or the first time after replacing RegisterForSave with ## SavedVariables) the data does still get loaded. As soon as you log out it gets saved in the right place. Users shouldn't be trying to split the file(s) themselves.

Now, I didn't quite think ahead enough when I updated all my addons, and I changed VARIABLES_LOADED to ADDON_LOADED in a few places and that meant you had to log in, and out again, and back in before things worked.. In hindsight I probably should have left some VARIABLES_LOADED code in for initial transition, BUT, the direction to log in, and log back out once, per ACCOUNT, when transitioning to 1.7 simplifies things so maybe i'm just being too pefectionistic there. As it is I didn't go back and change it 8-)

EDIT: Now, for YOUR purposes, you CANNOT reliably get away with what you're trying to do.. Now we're in 1.7 land addons wont expect their data to be missing at ADDON_LOADED, they expect it to be there.. Having said that, you shouldn't really ever provide a SavedVariables.lua file, that's kind of rude, maybe you should create a simple addon and make it a dependency of all of the parts of your compilation, and have it contain the saved variables you want to distribute... If users override it, then they get their own, if they dont, they get yours, AND they load right.

Hopefully that answers your question?

[Cladhaire]

An easy way to test this is the following:

Install a mod, and have it startup as normal. Make it somethign simple, but ensure it has a SavedVariable. Then grab the lua from that add-on specific modvariables.lua file, and toss those in a SavedVariables.lua file.

I _suspect_ (but can't test at work) that the game is loading the add-on specific variables and then the SavedVariables.lua file. We have the ADDON_LOADED firing multiple times before the VARIABLES_LOADED fires, so it makes sense to me that the global SavedVariables.lua file would load after all the add-on specific variables.

It would then save out the new variables you replace in the SavedVariables.lua.

This is likely only a solution for right now-- and I can't be sure it will work in future patches. With them segmenting the SavedVariables out so much, they may soon deprecate that file (if not disable it completely).

Sorry I don't have a ton more detail (my lack of WoW at work saddens us both)

[Cladhaire]

Originally Posted by Kaelten on load if a old time saved variables file is present it will divide them up. However, why, if you don't mind me asking, are you distrubting a savedvariables file?

He's distributing a pre-set compilation.

[Kaelten]

as in preset options?

hmm it may be prefereable to attempt to write a script that executes once on load of a new version and sets all those options.

You can actually put the code from the SV file into a function.

i.e.

 function LoadDefaults() 

loothog_settings = {
	 x = "5",
	 y = "15", 
}

message("All Default Settings have been loaded");
end

something like that could take care of it for you and prevent you from having to distrubte the actual sv files.

You can instruct the users to delete the mod once they've ran it to save on memory


just a thought. and cheesy example.

[Iriel]

Originally Posted by Kaelten as in preset options? hmm it may be prefereable to attempt to write a script that executes once on load of a new version and sets all those options. You can actually put the code from the SV file into a function.

The 'cleanest' solution I can think of, which is possibly semi-nasty 8-) is to create your own addon, i'll call it XYZInit, with the following:

1) A saved variable of its own called ''XYZInit_Applied"
1) A frame which registers for ADDON_LOADED and VARIABLES_LOADED
2) A lua file containing code that does the following..

1) Initialize a big table, more or less derived from your saved variables, something like:

local compilationInit = {
  ["FirstAddon"] = {
    ["FirstAddonVariable"] = 123,
    ["FirstAddonOtherVariable"] = "Hello",
  }
}

(Essentially those sub-tables are the data from your saved variables file(s), in table form)

Now in your event handler you need something like:

if (event == "ADDON_LOADED") then
  if (arg1 = "XYZInit") then
    if (not XYZInit_Applied) then
      XYZInit_Applied = {};
    end
    return;
  end
  -- Skip those that are already initialized
  if (XYZInit_Applied[arg1]) then
    return; 
  end
  -- Skip those which are not in the compilation
  local data = compilationInit[arg1];
  if (not data) then
    return;
  end
  -- Apply variables before addon gets to see them
  for k,v in pairs(data) do
    setglobal(k, v);
  end
  XYZInit_Applied[arg1] = 1;
  return;
end

if (event == "VARIABLES_LOADED") then
  -- Loading is done, clear the array so it can be cleaned up
  compilationInit = {};
end

Finally, and this is very important, you need to make XYZInit an optional dependency of all of the addons for whihc it has defaults.. That ensures it gets loaded first, and thus gets ADDON_LOADED before the addon does, giving it time to put the saved variables into place.

[Kaelten]

well if they are used to getting their options overwritten wouldn't it be easier to just set the whole tables at once.

of course thats ease versus finesse.

[Killariel]

Yes I was sending my saved variables so that the user could obtain the same look/feel for what I'm running. In the past I simply had them do a find/replace to change their name and server in the lua file.

I would definitely prefer to run a script that loads the settings independently, however I know nothing about modding, haven't really delved into lua, and know just enough about code in general to be dangerous. How difficult of an endeavor would it be to write this script? Also, would it be possible to write the script so that it only writes variables for the addons I provide and doesn't over-write their other variables?

[Kaelten]

it would be possible and all in all fairly smiple.

The hard part is going to be compiling the parts of the ui you want to offer presettings for.

[Atrophical]

I'm also looking for this sort of feature. Can you do it or show us how, Kaelten?! I would love you so much.

If there's any way we could limit it to something like JUST the DiscordActionBars and DiscordUnitFrames preset variables (the things that actually took a bit of time setting up), that'd be incredibly helpful.

[Kaelten]

I could help

I'll be honest, I barely remember how to code anymore with the exception of within ACe, lol, but I think I can do some small examples of what can be done.

Yes it can be done on a per char basis.

Now question, will you guys mind if I set it up to be an ace adodn, as I can do alot more jazz on this type of addon in shorter time if I use it.

[Atrophical]

SCORE.

By all means, go for it. My compilation has Ace in it, as it is!

<33<#<#<3#<3

[Devla]

Sounds interesting

Why not just go through each mod's code and change the default options? Most mods have default settings that can be changed this way.

I think if time is going to be spent on a 'mod management' style addon, it should include some sort of on-demand class/character loading features. When I get inspired I plan on working on this concept.

GL with the SV/Settings idea though

[Kaelten]

cool. I'll see what I can throw togather tonight I'm dealing with class work but after that I might throw togather a KC_DefaultSetter or something.

[Atrophical]

Sounds awesome. I can't wait.

[Killariel]

Much appreciated!!!!

[Killariel]

Just checking in - any progress on this? Is there any thing I can do to help? If I wanted to compile code for the individual addons where would I start?


Thanks,


Killariel

[Kaelten]

well I'm trying to decided on exact setup. Basically your going to need to have a file with a big table declaration in it that mirrors what you'd normally be passing out in the sv file you where distroing.