The loading order is such that the plugin "saved state" file is loaded fairly early on. Then any <variable> lines are processed, so any variables in the saved state file which are also in the <variable> section are overwritten.
I certainly wouldn't expect users to have to edit plugins after the first time, that would be a pain, and in any case wouldn't work if they wanted to use them for more than one world.
The method I would use is to have a method for initializing variables (the first time), other than actually using the <variable> concept. For example, in the ATCP mapper, I do this:
default_config = {
-- various stuff ...
foo = 22,
bar = 42,
font = "Courier",
delay = 100,
}
function OnPluginInstall ()
config = {} -- in case not found
-- get saved configuration
assert (loadstring (GetVariable ("config") or "")) ()
-- allow for additions to config
for k, v in pairs (default_config) do
config [k] = config [k] or v
end -- for
-- other initialization
end -- OnPluginInstall
require "serialize"
-- save config next time
function OnPluginSaveState ()
SetVariable ("config", "config = " .. serialize.save_simple (config))
end -- OnPluginSaveState
The lines in bold above will convert any nil values (ie. not present in the "config" table to be the same values in the "default_config" table. In other words, they are initialized the first time through.
So this example demonstrates how "foo" and "bar" have initial default values, which are added to the config table (from default_config) the first time around. After that if you change them, the changed values are saved. Next time through they won't be nil, and won't be changed back to the defaults.
Quote:
How does one use "OnPluginInstall", and does that take effect only when the plugin is actually installed or each time it's opened?
Each time it's opened. Installing really puts it into a list of plugins saved in the world file. It means "installed for this session" when you run OnPluginInstall.
Actually any statements in global scope will be executed anyway, before OnPluginInstall, because that is part of loading up the script.
eg.
function foo ()
print "x"
end -- foo
function OnPluginInstall ()
print "Plugin being loaded"
end -- OnPluginInstall
print "Loading plugin now"
The words "Loading plugin now" will appear first, as that will be executed as the script is loaded. Then if MUSHclient finds the function OnPluginInstall now exists in the script space, it calls that (so you would then see "Plugin being loaded"). And in this example function foo would only be called when something in the plugin made it be called.