Ok, I had a plugin some time ago where I would set a count variable to 0 in the variable section, and increment it as I use it to count added variable lists. Well, it had save state enabled and would judiciously save the variables in the state file. However, when I reload the plugin or open the world (thus loading the plugin), the hardcoded counter value overwrites the saved value from the state file, thus making it appear as if I had no lists in there.

I ended up ganking the variable section and added variable existance checking in the Install hook, setting variables where needed if they weren't loaded from the saved state. But, that seems to be a bad hack to me. Appears to be that the state file is being loaded prior to the variables are set. Perhaps reverse the order?

Yes, that would be handy... Well, unless someone uses the variables section to reset the variables every time it loads... In that case they could use the onPluginInstall section... It's just a matter of what is used the most, really...

Notice the 0 instead of the 1? All I did was save state, didn't do anything else to the variable. So, mushclient is overriding what is in the state file with hardcoded variables. Instead of blanket writing, how about just filling in the variables that aren't there?

As you say, the keyword is hardcoded, and clearly you don't want that.

You don't need to initialize MUSHclient variables like you do normal script language variables... However, I can understand you wanting to make sure a MUSHclient variable exists for somebody who is performing a first run of your plugin. Here's a common technique I use in my own plugins:

Could we have some clarification on this? I had the same problem but the offered solution didn't seem to do anything for me. How does one use "OnPluginInstall", and does that take effect only when the plugin is actually installed or each time it's opened? I'd like to be able to distribute my plugin. Having people open and edit it after the first use doesn't seem so good.

I never really understood why it was done this way either. The workaround makes sense, but the actual issue was never explained. And honestly I can't remember the last time I used a <variable> section because of this.

Vincitore said:How does one use "OnPluginInstall", and does that take effect only when the plugin is actually installed or each time it's opened?

OnPluginInstall is the name of a function you can create. If it exists, MUSHclient will execute it whenever the plugin is added or reinstalled via the Plugins dialog. Here's an example of using it to load stored state.

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:

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.

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.

Nick Gammon said: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 can't totally remember why I did something in June 2002, however my guess, after looking at the code a bit, is that the plugin state file is loaded immediately after processing the <plugin> XML tag in the plugin file, since that is the part that has the save_state flag.

So it processes <plugin> ... </plugin>, checks if it has save_state active, and if so, loads the state file.

Then it processes the other tags (triggers, script, variables and so on). Now if the variables are there they overwrite the variables loaded from the state file.

The issue last came up 7 years ago. I am opposed to it, simply on the grounds that it would change existing behaviour. Like it or not, some plugins may rely on it. Also I think my suggested alternative is more readable, all the initial variables are in script part of the plugin, clearly marked as "default".