Why Certain Plugins Wont Be Ported

Welcome to the wiki! This is where you can find resources from Yanfly.moe, Ækashics.moe,
VisuStella, Caz Wolf, Fallen Angel Olivia, Atelier Irina, and other affiliated content creators.

This is an article written by Yanfly. Introduction Ever since I've started the VisuStella MZ team to port over the Yanfly Engine Plugins library from RPG Maker MV to RPG Maker MZ, I've been getting lots of questions about porting over some very specific plugins. And for some of those plugins, there are no plans in the making for porting them over. The ones I'll be talking about are the following: Selection Control (YEP) Row Formation (YEP) Area of Effect (YEP) Item Core (YEP)'s Independent Items Instant Cast (YEP) as a Standalone Plugin There are some more, but let's talk about the ones listed above specifically. The Answer Short Answer Because of three main reasons. They can be at least any of the two (but usually all three) of the reasons listed below: They have incredibly low usage rates based off analytics. These are plugins/features with high levels of incompatibility. Even within the same library. We are on a budget. The money is better spent elsewhere on plugins/features to port over to maintain with higher traction. Long Answer Low Usage The plugins that won't be ported over have incredibly low usage rates compared to the rest of the library based off analytics. For those wondering where I am getting these analytics from, it's based off individual download quantities per unique user from my webhost's terminal powered by Google Analytics. These are also counted in tandem with the individual plugins' download quantities from [itch.io] when the YEP plugins were still up for download individually. Furthermore, these are also tallied up based on the amount of plugins I've seen in RPG Maker MV projects that I've downloaded (over 400 of them) from the community and mainly, from Patreon members that shared their projects with me during development. Yes, I kept track of each project I've downloaded and saw. Why? Because data is important to me to know what you guys are using so I know where to put my focus and improve things. There's a potential argument that this isn't a large enough sample size to determine what actually gets used and that the numbers can be flubbed and tilted compared to outside numbers that weren't recorded. Yes, this is true. However, I'm narrowing the focus to the projects I've downloaded from the past and putting more weight on those from Patrons for a reason. It's because those members have willingly came up to me and showed me what their projects are like. This tells me that they cared enough to stand up, amongst the crowd, to show me that they are the consumer-base my RPG Maker MV plugins helped service and that they treat this as seriously as I do. And, yes, some plugins are going to have higher or lower usage rates depending on when they were released, but all of the listed plugins have been created within the first year of RPG Maker MV so by then, they should have a larger advantage compared to the "newer" plugins released at a later date. However, they don't. These are plugins/features that still lagged behind despite everything else. Some people argue that they hear so-and-so plugin being talked about all the time in the community (aka their local Discords). However, those members are often the minority. The numbers from the analytics are a far better reference point and reliable metric than how often something is talked about in a community and far more measurable. I'm sorry, vocal fans, but I'll be trusting the numbers. Incompatibility Part of the reason why some plugins are more "popular" than others is because of how mechanically driving they are in the first place. However, because they're so mechanically-driven, they often come with lots of incompatibility due to how the RPG Maker core scripts work at base level. These include things like needing to completely rewrite functions, override game flow, and even change up how the game's database works as a whole. I don't know how much that means to non-programmers, but you can think of it like turning a car into a boat. Yes, it can be done, but is it practical? The answer is "no". Plugins like that would require so much maintenance time just to be made compatible with an ever-increasing library size that it is simply not worth the trouble. This is not a matter of being lazy. This is a matter of playing smart. How so? Because those plugins reduce the amount of time that could be spent on the production of new plugins that benefit larger groups of people as a whole. The argument I'm often given is, can't I just expand the team size to have more maintenance done for an ever increasing library? No, it doesn't work like that. Each time a new plugin gets made, it doesn't expand the number of potential conflicts for all related features by 1. No, it doesn't do that. It expands that number by an exponential amount for related features due to all the possible combinations. That's why, whenever we are going to create a new plugin, we need to consider the potential conflicts first and create around them, or else, it creates spaghetti code that will hold everything back. Is any of that worth it? Especially for plugins that have low usage rates? The answer our team unanimously gave is a resounding "no". Budget For those unaware, VisuStella MZ's team is made up of plugin developers who get paid. These developers port over plugins, refine them, ensure they're compatible with the rest of the RPG Maker MZ library, and then maintain the plugins whenever bug reports are made or upgrades are needed. Naturally, individuals who do all of that aren't going to sell their services for cheap and are given a salary to keep the library growing and thriving. There are also some who seem to be under the impression that since we're selling the plugins, we have unlimited money coming in. This is not true. Far from it. A "business" that runs off selling RPG Maker plugins of all things have an incredibly specific niche and that niche is small. To the point where need to budget ourselves in order to make sure we last the next month. Therefore, we need to put focus on plugins that actually have a track record of being used and by those willing to pay. This is where the analytic data comes in and why there is extra weight on the games made by Patreon members. Furthermore, these plugins need to be sensible in their maintenance costs, too. Yes, maintenance has a cost because it requires time spent on them that could be allocated elsewhere. A poorly maintained plugin will result in bugs. Bugs result in more bug reports. Bug reports are sent and then fixed by the same team members that could be developing the library elsewhere. In other words, a plugin that is not worth the budget will not only not generate capital to build the library, but instead drain finances. These plugins offer negative value to the team.