Commonly Accepted Plugin "Stacks"?

[Derjyn]

As a foreword, let me state that I am well aware of the "whatever works for you" or "whatever the project demands" school of thought. I exercise it religiously, in fact! That being said...

I'm curious and would like some input from established designers and developers, of what the "standard" of plugin stacks are nowadays. I've just recently gotten back into the scene and am amazed at how many plugins are available. The choice to utilize JavaScript was a good one.

I've been pouring over, and testing, the offerings of Yanfly, Galv, SumRndmDde, Khas, Estriole, EIS, the list goes on... Carefully following load orders and dependencies, I still manage to run into random issues or broken functionality. It's to be expected, I suppose. Some of these "stacks" don't seem to be maintained anymore, also to be expected.

I'm now looking at MVCommons, Plugin Dependency Manager, and another dependency manager I can't find at the moment. However, those seem to be a year or more old now. They didn't seem to get much attention either, which blows me away, considering how useful and powerful they would be.

I myself am starting work on plugin development. Not out of need, but because I'm a nerd through-and-through. I've touched (ie, learned the basics, at the very least) hundreds of different compiled or interpreted languages, and I simply can't
resist. Also, it's important for me to have my finger on the pulse of bloat in my projects. I'd rather implement my own little feature, than have to load 4 plugins to get that one system implemented.

So, please share what plugin setups you commonly use. I'm curious to see how everyone else rolls! Thanks, and have a great one

 

[Starbird]

This is an interesting thread imo. Derjyn makes an excellent call for an effort at coordination and documentation in this area.

Also, at the simplest level, a list of the most active/responsive plugin developers would be useful to hundreds of people on this forum. And now I'm just rubbing the Aladdin's lamp and wishing, but if we could manage to create a volunteer filter team that reviewed messages from the forum directed to the most active plugin developers, maybe we could save the developers time and help them better understand what designers would most broadly find useful.

I've done some plugin development (a simple one published here, another more complicated one php-reliant and therefor not up to spec) and am seconding derjyn. This sounds like a gigantic but incredibly important, helpful project. Maybe we can roll out this thread and then pack it up in a google doc for posterity

 

[Derjyn]

In hunting down and organizing current plugins, I've come across a few threads on various forums and we aren't the only ones who see the value in this. For example, Hudell, author of the popular "Orange" suite of plugins started this thread. I really like the idea of a community maintained "core" script, that introduces bug fixes and common utilities, enhancements, etc... MVCommons seemed to gather a little bit of steam, but checking it out on GitHub, it hasn't been updated in a couple years.

So on top of an actively maintained MVC resource, I can think of another resource: a compatibility reference, and as StarBird presented- a documented compilation of plugins in a central location. I notice that some communities are a little closed off from each other, but that's no reason that we all couldn't contribute to, and reference those 3 powerful assets:

1) an up-to-date MVC (or similar)
2) Plugin compatibility (and perhaps performance metrics?) reference
3) Plugin master-list

While developing those things initially would take some effort, maintaining it wouldn't be so rough. We have the technology.

* On a side note- translation of some of the awesome plugins developed in other languages wouldn't be such a bad idea either, but that's another topic...

* Another note/PSA: Stay away from the second link referenced in the MVCommons stuff, as it leads to spam and such: http://dekyde.com/mvcommons

[doublepost=1511978428,1511938132][/doublepost]I'm not able to edit my last post for some reason... Something about being too "spam like" or some such. Maybe because I accidentally linked to the very thing I warned was spam/malware, hahaha!

Anyway, I wanted to revise and reduce those 3 "powerful assets" I suggested, down to 2:

1) Up-to-date MVC or similar
2) Plugin master list, with compatibility and dependency notes

Currently, I have ~365 plugins downloaded, and while I haven't meticulously poured over them and tested... I'd throw a random and non-dependable statistic out there: about 50% of them work flawlessly, 10% work well together, and 40% simply don't work out-of-the-box. I'm seriously tempted to identify the MVP (minimum viable product) functionality of each one, and catalog/organize them all based on that. Then compare the base of each category, and merge and reduce it all into one plugin for each one, based on performance and feature set. Basically, combining the best of them all into one plugin. Then, make that plugin follow the rules of MVC or similar.

I know there are hundreds more plugins out there, and this would be a daunting task, to be sure. A chunk of it could certainly be automated. Then there is the big issue of permissions from plugin authors, and not stepping on toes. I really don't want to do that, heh. Alas, this is all nerdy food-for-thought. It'd be awesome to get a repository going, with the major (and minor!) plugin authors and the community contributing, to make a best-of-the-best plugins library.

 

[Derjyn]

I'm still getting used to how the forum functions here... I couldn't edit my last post, but it merged my follow-up post (and I'm prepared for it to happen again, haha). Anyway, I've identified a few more elements here...

First off (and this may already exist, and I haven't found it yet), a style guide would be handy. This is an excellent example, even though it applies to Unreal Engine. The UE4 community (generally) accepts it, following the patterns and semantics presented. Something like that for RMMV, and not just plugins- would be pretty slick.

Shouldn't be too hard to prime a GitHub repo for all this. That is, the plugin stuff, the style guide, and another idea I had. Pretty sure this has been done, as well. Just not sure how up-to-date anything is currently: a clean, optimized base project. I have one I'm working on right now. I've gone through and compressed JavaScript files, stripped out a good majority of base assets, and created a new directory, "workfiles", that contains Photoshop and other DCC stuff, as well as other bits and bobs that might be commonly done in a project (such as templates for battlebacks, titles, etc).

I've also updated to PixiJS 4.6.1. With all that, my current project size weighs in at 79.2 MB. Not too shabby. I'm walking a fine line of adding in enough assets to tinker around, but not have a full library of stuff bloating project size. I'm aware there is a tool that strips stuff out, and it works somewhat... I just don't like not having my finger on the pulse in this area.

Thoughts?

 

[Xilefian]

I am a very experienced programmer, I'm not quite sure what you're asking for here.

"Commonly accepted Plugin stacks" - what does this mean? Do you mean like a common software stack that Plugins use? Like a standard library and a set of helpers for constructing objects and organising code? Something like the old RGSS SDK community project?

Check out the SDK here: http://save-point.org/thread-2361.html looks great, doesn't it?

If this is what you mean, then my answer is; Plugins need to be simple - we had many, many problems with the RGSS SDK in the past; these problems weren't developer problems, they were user problems, scripts that used the SDK always depended on a specific SDK version that the user had to seek out, they then had to order their scripts in a specific way, and in some cases they had to abandon scripts entirely that cause incompatibilities with the SDK.

I do not want to return to those days.

At the moment we have the problem of "MyName_Core" - where every kid on the block wants to make a "Core" Plugin because Yanfly has one. This Core Plugin is basically some shared library functions for the base Plugin, it's a mini-version of the SDK issue dragged into MV for the sake of "Yanfly did it".

We also have the issue of some people using Javascript compilers but not writing proper headers to explain what's going on or encapsulating the generated code; we end up with MV Plugins that are very difficult to debug and even harder to write compatibility fixes for.

MV uses Javascript, there's the Javascript library available, PIXI.js and the MV library. If you're writing a Plugin you should stay within this group of APIs to remain as compatible and simple for the end user as possible, even if that means your Plugins are over 3000+ lines.

I agree that there must be a better way to organise all this and try to save compatibility, but I don't think anyone has found that yet - the issue is partly with Javascript itself.


My advice is; stick to one syntax, do what MV does, don't ask the end user to drag a tree of dependencies down their rabbit hole.

I would love to find a better way of doing MV Plugins because it frustrates me just how unruly it is to manage Javascript code, but at the moment we just need to deal with it in our own way for our own Plugins.

 

[Derjyn]

Hi Xilefian, thanks for your insight!

However, I wasn't really referring to external libraries. By "plugin stack", I meant the plugins people commonly use in their project. I agree 100% that plugins should be simple. Beyond that, I also would like to see plugins be more modular, so instead of having one giant plugin that does A, B, and C... We can create our own systems by pulling in smaller plugins that handle specific tasks efficiently.

I've dabbled in dozens of other engines, and I really prefer the ones that have this modular approach. I prefer only using what I need. While there is a certain allure to having a massive plugin that offers tons of features, and creators can just fire and forget... I personally would rather have my finger on the pulse of every little bit that goes on in my projects.

That said... I also got the "because Yanfly did it" bug, and started to create a core plugin. That lasted all of 1 day, after I realized it wasn't really needed. The idea seemed good at first- I have several plugins I plan on developing, why not have a master plugin that exposed some commonly used stuffs? After getting 2 plugins off the ground, I realized I wasn't using the core plugin, at all. I'm a fan of DRY (don't repeat yourself), so maybe that has something to do with it.

I really liked the goals of MVC, but sadly it seems broken and abandoned now. So my proposal still stands. A maintained master (or core) plugin, that encourages plugin authors to code better, as well as register their plugins with dependencies and such, so end users won't have to worry so much about load orders. That's one minor (kinda) side-effect/benefit, among others, I'm sure. Performance enhancements and bug fixes should also end up in this root/core/master plugin. I guess there is nothing stopping someone from fixing up MVC, or forking it for that matter. Solutions abound here.

Oh, don't forget about NW.js Xilefian, you left that out of the band

At any rate, 1.6.0 is in beta right now, with some nice improvements and updates to PIXI.js and NW.js, among other things. I think after that drops, I might try and tackle this idea myself. I already have notes and ideas, being jotted down as I develop my base/boilerplate project. I guess what I'm looking for, is more opinion and insight like what Xilefian presented. A dialogue, if you will.