How to get plugin parameters without knowing your filename

Description

Allows scripts to retrieve their parameters without having to know their current filename.

How to Use

If your plugin is using parameters, it might very well crash if a user renames the file. To prevent this, add an arbitrary string to your @plugindesc, like this:

/*: * @plugindesc My amazing plugin * <Iavra AmazingPlugin> */By putting "<Iavra AmazingPlugin>" in a new line, we effectively hide it from the Maker. You can use any string you want, but make it distinct enough that it wouldn't just randomly appear in some other plugin's description.Now go on to replace this call

var params = PluginManager.parameters('Awesome Plugin'); // File is named Awesome Plugin.jswith this
This will iterate over all plugins (really just a JavaScript object containing the filename, description and parameters of all plugins) and see if their description contains your id. We take the first one (make sure your id is unique by prefixing it with your own name or namespace) and retrieve it's parameters.Tada, you get your parameters and your users are able to freely rename all your files.

If you don't need to worry about being compatible with Internet Explorer (which might cause a whole lot of other issues, anyway), you can also use this solution, which is completely independent from your plugin name and can simply be copy-pasted:

var params = PluginManager.parameters(/([^\/]+)\.js$/.exec(document.currentScript.src)[1]);This will get the path of the currently executing script (which has to be your plugin) and match everything after the last slash, but before ".js" and the end of the path, or in other words: The file name. This is then given to PluginManager.parameters() and used as normal.Terms of Use

Free to use for both commercial and non-commercial games.

Credits

No credits needed, since this doesn't add any actual functionality to the game.

I preferred the other way you did it - keeping it entirely within the script, so it's not dependent on other plugins.  And with your okay I think I'll use that method.

But if this becomes popular and a lot of scripters use it, I'll go with this version too.  The method above would probably be better than parsing the script file.

For those who don't know, this is the other way:

var params = $plugins.filter(function(plugin) { return plugin.description.indexOf('<pluginid>') != -1;})[0].parameters;It's completely independent from other scripts, but has the added drawback that it iterates over every plugin, for every plugin that uses this method.But I think you're right that it's cleaner and the performance cost wouldn't be really noticable (usually you are retrieving parameters only once, anyway).

/edit: Changed the regex call to String.indexOf, which is faster.

I liked this approach and made a one liner out of it that looks like this, using the contains function MV adds to the string object:

var parameters = $plugins.filter( function(p) { return p.description.contains("id:TDDP_MouseSystemEx") } )[0].parameters;The performance issue here shouldn't be a problem at all. If someone has a lot of plugins and they all do this, it might add a few hundred ms tops to the startup time, but I honestly think that's a valid trade off for the user friendliness this adds :)

I'll delete the plugin linked in OP, since it's overall better to put the small snippet in your plugin then to tell your users they have to install yet another plugin to be able to rename yours.


@Galenmereth: I went with your version, since it's a bit less to write.

I haven't retrieved parameters from the plugin manager so that might be why, but what is the purpose of knowing what the filename is and what problem does this approach solve?

The PluginManager stores your parameters under the "name" of your script, which is just the filename without the ".js" at the end. Now, when the file isn't named exactly how you want it to (because the user wants to keep a unified naming convention or they just copied it from somewhere), the plugin will break. This has been a pretty common issue those fast few days.


By using the plugin description, we are independent from the filename and the users are free to name the files however they want.

As I said, I prefer to just throw an error reporting you name it wrong and stop my plugin entirely, so the rest of the game works as expected

But this could be usefull anyway.

Okay, I've got an atrocity of a code right here that should do the ultimate trick or treat.
 
Essentially, what it does is, it will go through each method until it either finds the plugin parameters or it just gives up and uses the fallback.

_pluginName is the name of the plugin, or the standard plugin name. _propNames is an array containing all essential parameters (properties of the parameters object), and _defaultParams is an object containing the default values.

First, it just uses PluginManager. Next, it uses document.currentScript, only available on Webkit and Gecko based browsers, as well as Safari and Opera. Then, it uses the description of the plugins. If during that same loop there's nothing in the description for some reason, it checks all properties if they exist. That step could possibly be skipped, though, but still. Added the possibility. Finally, if all fails, it just says, meh, screw that, and uses _defaultParams.

It's not fool proof, but it's as close as it can get without having to resort to using AJAX to get the contents of the script.
 

var _pluginName = 'CXJ_Exit'; var _propNames = ['Text - Exit', 'Text - To Desktop', 'Add to title', 'Add to Game End']; var _defaultParams = { 'Text - Exit' : 'Exit', 'Text - To Desktop' : 'To Desktop', 'Add to title' : 'true', 'Add to Game End' : 'true' }; var _getParameters = function(pluginName, propNames, defaultParams) { /* Private function that checks plugin content */ var _checkPluginContent = function(parameters) { for(var prop in parameters) { if(parameters.hasOwnProperty(prop)) { return true; } } return false; } var parameters = PluginManager.parameters(pluginName); if(_checkPluginContent(parameters)) { return parameters; } var currentScript = document.currentScript; if(currentScript) { var scriptName = document.currentScript.src; scriptName = scriptName.substr(scriptName.indexOf('js/plugins/') + 11); scriptName = scriptName.substr(0, scriptName.lastIndexOf('.js')); parameters = PluginManager.parameters(scriptName); } if(_checkPluginContent(parameters)) { return parameters; } for(var idx = 0; idx < $plugins.length; idx++) { var plugin = $plugins[idx]; var params = plugin.parameters; if(plugin.description.indexOf('<' + pluginName + '>') > -1) { return params; } var hasFound = true; for(var idx = 0; idx < _propNames.length; idx++) { if(!params.hasOwnProperty(propNames[idx])) { hasFound = false; break; } } if(hasFound) { return params; } } return _defaultParams; } var parameters = _getParameters(_pluginName, _propNames, _defaultParams);By the way, code's CC0.

This is probably longer than some of the simpler plugins you might want to use with it :D

This is a good and practical solution. Thank you!

Also - a lot of plugins are being shared as text - pastebin, git, etc.  There is no indication to the user what the file name should be called when they save it.  So the name they give it is often not the name used in the script itself when searching for the parameters - it makes it act as if the plugin isn't even turned on.

Isn't there a built in method somewhere to get the name of the file executing the command? I know the console is more than willing to tell you every time....

That way we can keep it modular like

var someRandomName = PluginManager.parameters('current-file-here');But hey...if this method works perfectly fine as is it'll save some confusion for users.

Edit:  This works perfectly fine and is an awesome resource!  Thanks again.

For the most part, I didn't realize the plugin manager actually used the name of the script file.

I thought plugins registered themselves and the plugin manager takes that and adds it to its list, giving the plugin writer full control over things even if end-users change their name.

Seems to make so much more sense to say

PluginManager.register("my arbitrary plugin name with extra spaces")And then go from there.That kind of plugin registration would even solve the import issue.

It just makes more sense than

Imported.MyModule = trueor something, but that's a separate issue.Now, I don't know if such functionality already exists; I'm just looking at the community core plugin and how other early-access plugin writers are doing it.

I found another solution. It's probably not supported in IE and abuses the stack trace, so i wouldn't advise anybody to use it, though ^^

var params = PluginManager.parameters(decodeURI(/\/(?!.*\/)(.+?)\.js.+\n/.exec(new Error().stack)[1]));On a positive note: This works for any plugin and doesn't need to know anything about it :D /edit: Note that i only tested this by opening my game's index.html in Chrome, so there's a good possibility this doesn't even work in normal testplay.

Your filter to search through the description of all installed plugins has been working perfectly for me, so far. Thanks a lot for such a practical work-around.

THANK YOU.... i will use this for my plugins parameter for sure :D .

Another interesting use-case of this solution i found out, recently. You can design your plugin to be activated multiple times (in my example, to be able to draw a gauge onto the screen). MV will only load the script once, but $plugins can contain multiple entries under the same name and you can get them like this:

"params" will be an array of parameter objects and you can use them however you want. You might also want to check for "p.status", since one or more of your entries could be deactivated.

As I described in the first edited post here:

http://forums.rpgmakerweb.com/index.php?/topic/49880-use-stacktrace-to-get-the-plugin-file-name/

Another crossbrowser solution that doesn't require any configuration:

Remember that currentScript isn't supported in Internet Explorer, so if you're creating a web-based game, this might not be what you want: https://developer.mozilla.org/de/docs/Web/API/document/currentScript