Plugin load/install order

I recall that a while back we were discussing plugin dependencies, and hacks like my LoadPPI script to circumvent that. I have a small suggestion to make it much easier to deal with plugin dependencies.

Currently, each plugin is loaded, and OnPluginInstall called, at the same time. Changing it so that all plugins are loaded, then OnPluginInstall is called on all of them, would guarantee that any code in OnPluginInstall is executed after the plugin files have been loaded (including variables). Checking for a dependency would be reduced to checking IsPluginInstalled().

I (was|still am) trying to patch this into my custom build, but it's a little more difficult than I expected - perhaps because I'm not completely familiar with the source.

Nick said that Plugins load in alphabetical order. Give dependencies an early name in the sort order. 'aaDependof_LoadPPI.xml" It'll look like crap in the plugin dialog's list, but who looks at the list? Just give a good description in the xml for the purpose column...

Sorry - what? That seems... a bit overhanded. The situation currently is that the order is:

p1 parse/run, p1 OnPluginInstall,
p2 parse/run, p2 OnPluginInstall,
p3 parse/run, p3 OnPluginInstall.

What I'm suggesting is changing it to:

p1 parse/run, p2 parse/run, p3 parse/run,
p1 OnPluginInstall, p2 OnPluginInstall, p3 OnPluginInstall.

Also, I just stepped through the plugin load order, and I can pretty much guarantee that it doesn't load in alphabetical order. In fact, if anything, it loads in the order that the <include> XML tags in the world file are in.

I think it is the order in the world file, which is probably the order they were loaded. As this is not easily defined, I would not rely on the load order.

As I previously suggested, I would resolve dependencies at world connect time, when all the plugins will have been loaded already.

I'm not sure there needs to be a hard-coded dependency feature, personally. A script might have hard dependencies, where they'll fail if they don't see their prerequisite loaded, or soft dependencies, where it degrades gracefully. Both could easily be controlled from within the script itself; a dependency feature (at least in the way I see it; you might have a better idea) would either control only hard dependencies, leaving the script to manage soft dependencies under the same iffy conditions as now, or be complex/unwieldy, which speaks for itself.

All that said, I'm not exactly having much luck myself, so if it would be too hard to implement, it's not a big deal.

Nick: Rereading your post for the tenth time, I finally understood "I would resolve dependencies at world connect time" the way you meant it. *laughs* To respond to that: it's hardly going to be a steadfast rule that plugins will only need to communicate after the world has connected. I can think of plenty of cases where they would need to acknowledge each-other before the MUD has connected, and it's hardly fair to limit plugins that much.

I'm halfway finished writing an IRC plugin, for example, and I want it to be possible to communicate with it, such as allowing other plugins to respond to IRC data (likely sent by BroadcastPlugin), and do other kinds of things. The world need never actually connect to the MUD, so using OnPluginConnect does no good at all.

Well, perhaps. But after all, the client is basically communicating with a MUD, it isn't doing much before that.




This is probably a sensible suggestion, I'm not sure if it will break existing plugins, but I can see the use for it. Then, in OnPluginInstall, you can assume all plugins are loaded (except those that get loaded manually later on, of course).

Precisely! :)

I've made the appropriate changes to my local source to implement this; would you like the diffs? I'm moderately less sure of my technique for this one, but testing seems to be working.

Oh, and I may have fixed an obscure bug: when using 'Add' in the Plugins dialog to load multiple files at once, if one of the files doesn't load properly, it skips all the rest. 'Reinstall' doesn't have this problem. I didn't test this fix - I really only noticed it because I was working in that function - but it seems like it was just a matter of putting the try-catch within the loop instead of outside it, as OnReinstall() already was doing.

EDIT: Oh, and about it potentially breaking current plugins, I've given it some thought, and I don't see any obvious way it could do harm. OnPluginInstall currently is no more useful than putting code outside the function altogether; changing the load/install process wouldn't change its mechanics, only guarantee something that wasn't guaranteed before. If something happens to use, for example, the LoadPPI proxy script I wrote, it would still be fully compatible.

Yes, send it to me please.

After thinking about this at some length, it seems to me that we need more than re-ordering when the OnPluginInstall function is called.

I have added a new callback to version 4.45, namely OnPluginListChanged. This will be called when:

• All plugins have been loaded at world load time (called once, after all the plugins are loaded)
  
• The list of plugins changes (because of adding or removing plugins from the Plugins dialog box) - called once if multiple plugins are loaded or removed at the same time.
  
• A plugin is reloaded via the Plugins dialog box, or the ReloadPlugin script function is called.
  
• A plugin is added via the LoadPlugin script function.

Making a new function resolves any issues that calling an existing function (like OnPluginInstall) at a different time, or more times than expected, may break existing plugins.

It also is a bit clearer - the plugin receiving the OnPluginListChanged function call, is not necessarily the one that has changed. It really notifies *all* plugins that *something* has changed. The something might be that the list of plugins has grown smaller, for example.

A logical test to put into OnPluginListChanged would be to see if a required plugin (that is, one that this plugin has a dependency on) is there. Since it is called at world load time, after all plugins are loaded, then the plugin will not just magically appear without user intervention. A warning could then be displayed to the player that they need to fetch the required extra plugin. This warning would also be displayed if the player removed the required plugin for some reason.

Sounds good! ^_^