Extending the PluginManager functions

[niokasgami]

So since MV got out it's offered a lots with the PluginManager Although the way it's approach kinda make it Messy? and sometime it's cluther the plugin with TONS of codes peoples might not always understand. on a more precise point it's lacks some functions who would shorten the plugin dev (e.g Boolean or array in plugin parameters) or sometime they aren't really clear in what they do.

So I worked on a pluginManager extender plugin who extends the current PluginManager for offers "shortening" methods who make the code more clear and simplify the plugin dev job in my opinion

I would like to offers that the functions I created would be merged with the original PluginManager so people can use them for shortening their workload and make them more clear.

OBVIOUSLY I wouldn't ask credit for it and you guys are REALLY up to edit the codes for make them more performant. I want to contribute for make MV betters!

then here the link of my original plugin : https://github.com/niokasgami/EmojiEngine/blob/master/Emoji_Dev/Emoji_Dev/bin/Tool%20Plugin/PluginManagerExtender.js

thanks for your further answer!

[molingyu]

Good job!

I think we can add alias/unAlias function for PluginManager.

Example: PluginManager.alias(obj, funcName, oldName, ()=>{ //do something })

PluginManager.unAlias(obj, funcName)

[krmbn0576]

It's a very good proposal! The only thing to worry about is that we can't use these extended functions with older versions of RMMV. The authors of the plugin don't know which version it is used in new and old, so they have to rewrite the same code into plugin to correspond to the old one. It's very inconvenient. 😭

Therefore, my alternative proposal is to make a base plugin and define these useful functions there. I'll write issue soon! 😇

[molingyu]

alias/unAlias

PluginManager.alias = function (obj, functionName, aliasName, newFunction) {
  if(arguments.length < 4) aliasName = `${Date.now()+ functionName}`;
  obj[aliasName] = obj[functionName];
  newFunction.__aliasName__ = aliasName;
  obj[functionName] = newFunction
};

PluginManager.unAlias = function (obj, functionName) {
  obj[functionName] = obj[obj[functionName].__aliasName__];
  obj[functionName].__aliasName__ = null;
  obj[obj[functionName].__aliasName__] = null
};

[niokasgami]

as said in the other thread my pull is not to Break other plugins and it shouldn't break it anyway?

Those aren't Standard ways of making plugin but more 'macro' code who shorten your code for avoid either to rely on Core for basic Param Splitting (such Boolean or Array splitting) or have to repeat the same and same function or code.

Take it as a Optional Tool who sweet your work flow so no need to make it split nor I find the use of making it a core plugin for it who will repeat the same errors forcings peoples to haves TONS of core plugin.

for other peoples wanting to use it in the previous version they can always access my current plugin and use it if they doesn't want to update their core files (e.g : plugin who would break with a update) the plugin I made is totally portable and could heck even be implemented in the 1.00 rpg maker MV version lol

[krmbn0576]

Hmm, what is your proposal? What would you like us to do?

[niokasgami]

(just read my comment and realise it's sound rude and I'm sorry for that >_>)

Hum as I spoke with Quasi having the plugin itself he explained me if it's optionnal it's should stay a plugin. but I would kinda like to find a way to make the way of making plugin a little more I don't know less "raw" and more intuitive for beginner since well the Motto of rpg maker MV is "Simple enough for a child and yet still powerfull" or something like that.

Although the Plugin Making in is actual states is untuitive and often messy wich often make it hard to obtain decent configurations.

my first proposal was to offers the Functions I made although it's seem the idea wouldn't get approved because it's could make it difficult to get for other peoples etc

my idea though was to using the same concept of the functions but instead to permit to implement a more universal ways for the plugin to recognize type. var param = Plugin("parameters", "type"); <- or a way to optionnally telling the type if it's ommited the type is free to be convert after.

I know it's maybe me who are just picky I am used to program who tell explicitly what it does or their type.

[Nelderson]

Slightly off topic, but I made a PluginManager function to help with the naming issue (If you don't name it the same as you reference in PluginManager.parameters call it won't work). I put the helper in a global namespace for ease of use, but if you find it worthy I can throw it into a Util namespace or something and submit a PR:

PluginManager.autoGetParameters = function() {
    var name = findPluginName();
    return this._parameters[name.toLowerCase()] || {};
};

var findPluginName = function(){
  var path = require('path');
  var file = document.currentScript.src;
  var filename = path.parse(file).base;
  return filename;
};