lua plugin loading problems

This is two seperate subjects, but I figured I'd post them as one. The first issue I have is with loading a lua plugin of mine. When MC attempts to load it on starting up, it fails, but then reloading it from the plugin dialog box works without fail. The plugin is set up in multiple files somthing like this, but Main.xml is the file actually first loaded by the plugin manager:

Main.xml:


subplugin1.xml:


etc... Now the error message I get when the plugin is loaded is as follows:


Looks to me like the main Lua environment path hasn't been set or something? In anycase, loading the plugin works perfectly as long as it isn't loaded on startup.

Hmm, I just got this problem again for the first time when reloading the plugin after it had already been loaded. It caused the error, I reloaded it again, and it worked fine... I'm stumped.

What was the second issue?



The problem here is "what is the current directory?". The initial attempt, which I can reproduce by automatically opening the world at startup, defaults to the current directory being the MUSHclient executable directory, however you could change that by changing the "start in directory" setting for the Windows shortcut.

This current directory is used by the "require" line in Lua, so it doesn't find the file it needs.

However when you manually load the plugin, the current directory is switched to the directory you are browsing (the plugins directory) and now the "require" can find the file.

You should really set up LUA_PATH to point to where your required files are, using the default of "current directory" is bound to be prone to errors.

A simple way is to edit the Lua "sandbox" which is in the MUSHclient File -> Global Preferences -> Lua menu.

I made it work by adding the line:


LUA_PATH = "C:\\mushclient\\plugins\\?"


Change to whatever your MUSHclient directory is, of course. Note the double backslashes as this is a Lua string.

Ah, ignore the first/second part thing ;) Anyways, I see now how its working, since the plugin itself is in a subdirectory of the main plugins directory. Changing the Lua sandbox works, but is there anyway to do this from within the plugin, seeing as how I may want to distribute this without having to tell everyone, ok, now edit your sandbox...? I looked at the GetInfo docs and it doesn't seem that you can get a string return the path of the calling plugin perhaps? Any ideas? Thanks a bunch Nick.

Ah testing this, GetInfo(64) seems to do the job. Thanks

GetInfo(64) returns the current directory. I wouldn't have thought this would have put you much further down the track.

Try:


GetPluginInfo (GetPluginID (), 6)


This gives you the path of the plugin (however it includes the plugin file name itself). If you strip off the last part of the filename you would find where the plugin iself is.

Or, you could try:


GetInfo (60) --> Plugin files default path (directory)


However that assumes the plugin has been put into the default directory.

You are, as always, correct Nick! Thanks!

Incredibly old topic, so please pardon the necro, but I found a decently reliable workaround to this. You can just replace the problematic require() call with an <include> tag before the <script> begins, just like the world file has it. You need to wrap it in some XML unfortunately, but you can use constants.lua for reference.

I had this exact same problem, except the sandbox wasn't working for me for some reason. The <include> works like a charm - and it's simple, too! I haven't actually tested, but I assume that the 'name' attribute is relative to the plugin file.

There is an even better solution for Lua.



Put that at the top of your script prior to requiring anything. It tells Lua to also look for files to include in the directory your plugin.xml file is located.

That's pretty much exactly what Nick suggested before my post, isn't it? ;) Personally, I prefer <include>, because the hard(er) parts are left to the distributor, and client developers can just <include> the file they want, just like require(). But the more options we have the better, right? The only real difference is the extra XML I suppose.

Somehow I hadn't spotted the bit involving GetPluginInfo(), I had only seen him mention GetInfo() which wasn't nearly as specific. Oops.

Either way, with this extra bit of code it is atleast clearer for people on how to solve this 'problem'.

I think the choice on XML versus pure Lua (or some other language) should be made on the code inside the file. If it is MUSH specific and involves triggers and such, I'm all for the XML. Is it some kind of utility library, I prefer the pure scripting language variety.

You're probably right. In my case it's MUSH-specific, basically utility scripts for communicating with the companion ATCP plugin. (The .lua file could be compared to a C header file, if you will, and the plugin to a DLL)

EDIT: Actually, would it be too much to ask for MUSHclient to do the path thing on its own when it loads up?

You have the solution already. MUSHclient could perhaps make a builtin solution for Lua, but that would only complicate things with regards to older versions and such. COM languages like VBScript and PYthon couldn't benefit from it since they use their own 'import' mechanisms.

Paths are fiddly things. If you change the default directory then things like plugins don't necessarily load properly, and if you don't, people complain that they changed the directory (eg. when browsing for an image file) and it didn't remember the new directory.

I am inclined to make the require search path search for where you expect things to be.

This is a good thing relative to this discusion, right? :D

Yes.