Forums » Suggestions

Do not load plugins that start with an _

Jan 16, 2017 yodaofborg link
Sometimes I like to disable a plugin or two, just for 1 session; and although it is simple enough to move them out of the plugin folder it would be also nice to be able to disable them by just renaming them, but leaving them in place.

So is it possible to get the plugin loader to ignore plugins that start with an _ ? Would also easily enable things like 3rd party plugin managers to enable/disable stuff without too much work on any platform.

Low priority of course, just throwing it out there.
Jan 16, 2017 Darth Nihilus link
Plugin won't load without a "main.lua" inside the first directory.

So, create a "not in use" directory inside of the "plugins" directory and stuff any unused plugins inside of this directory. Even easier than your solution and they won't get loaded as there will be no "main.lua" file.

You're welcome.
Jan 16, 2017 PaKettle link
Work has been done on selectively loading plugins but due to how they are handled in VO so far it has proven impossible to do reliably. One of the biggest problems is you can't read in a config file and load based on it. Once lua gets control you can no longer load a plugin and you cant read your config data until after loading is finished. It is possible to load in programming afterwards but it has to be stored as data and not code...

All of this is in the name of preventing abuse (I assume) so I have no idea as to how fix the situation.
Jan 16, 2017 draugath link
That's not entirely true PaKettle. You can load plugins after the fact with a simple dofile() or loadfile(). The problem is that there are certain conditions that are no longer the same as when the original loading process is taking place that can cause problems for plugins with multiple files.

I've also written and submitted a plugin loader and management GUI that supports disabling plugins from inside the game, amongst other things. Unfortunately due to the ever busy schedule of the developers, they haven't had the time to evaluate it for possible inclusion.

Manager Window

What yodaofborg is requesting is certainly far simpler than reviewing lots of new code. It's also far simpler than monkeying around with renaming files or moving folders around. I have around six different plugins folders for working in isolated plugin environments for different projects.

EDIT:
I, however, would recommend a different character. The underscore sits right in the middle of the capital and lowercase letters on the ASCII table. If you weren't aware, plugins are loaded in ASCIIbetical order. If there was some reason to need an intermediate plugin load point between the two sets of letters, the underscore is a prime option. A possibly better option might be the tilde (~), which sits at the end of the basic ASCII table.
Jan 16, 2017 meridian link
Tilde is probably not a good character to use because on windows, files beginning with ~ are temporary files, and there may be unintended consequences.

One such example is that dropbox does not sync files that begin with the ~ character:
https://www.dropbox.com/help/145
Jan 17, 2017 yodaofborg link
~ can actually be used by shells under unix-like systems to refer to home directory too, . is hidden files and a lot of other chars are also reserved by Windows/*nix ($%& etc), I thought about _ because I cannot think of a single OS that uses this character for anything other than names (but any character would work). I doubt it would cause a problem with the Lua load order if it simply ignores the folders that start with an _, you could always use ^ for helping with load order.

Darth, I know this, and if you read my post it actually says "but leaving them in place" that means not moving them. It is a simple solution to a simple problem I know, but your suggestion actually takes more time than just renaming a folder to _whatever. My reasoning behind this was not to just disable plugins manually, but also make plugin managers and the likes easier to code. Sure, an in-game plugin manager might be nice at some point, but people are already making 3rd party apps that try to do this, and my thought process would be letting these apps simply rename a folder would be easier than moving stuff about.
Jan 18, 2017 PaKettle link
@ draugath
I am aware of the work thats been done - and yes reliability has been a big issue.
As we both mentioned conditions and allowed operations both change and I have also run into differences between loading at start up and reloading via /lua ReloadInterface().

At the heart of the matter we need VO to behave in a much more consistent fashion if a plug in is going to work unless you care to detect what the current situation is and provide roughly 4 to 6 different loading methods to handle each of the possible environments. Up to now I have not been able to think of a decent way to characterize the different loading states that actually makes sense...

I gave up on the matter for the time being to work on projects that are more to my taste...
Jan 18, 2017 draugath link
There are actually only two major differences in the load conditions.

Global variables can be implicitly created during normal plugin loading. When loaded after the fact, you must use declare() to explicitly create globals.

myvar =1
declare("myvar", 1)

During normal load the current path is set to the current plugin directory. After the fact the path is set to the vendetta directory, so when loading other files you need to specify the relative path to the files you want to load.

dofile("file2.lua")
dofile("plugins/myproject/file2.lua")