Project FOSSIL V1.0
By: FOSSIL TEAM
Introduction
Project FOSSIL (Fixing Old Software / Script Interoperability Layer) is a single RPG Maker MZ plugin designed to expand the use and usefulness of RPG MAKER MV plugins, by allowing them to work in RPG MAKER MZ projects. FOSSIL
doesn't port plugins. FOSSIL
makes porting unnecessary!
I got a copy of RPG Maker MZ a little while ago, and I think the editor is even better than RPG Maker MV. The only problem is that it's competing with RMMV's deep library of plugins. MV had such a huge number of great plugins (thanks to the tireless work of Yanfly, Moghunter, SRD, Galv, and too many other authors to list here) that it will be a long time before they all get rewritten to work with the new engine.
I decided to try to figure out a way to speed things up. Instead of having to change every single MV plugin to work with MZ, I'm going to see if we can change MZ so it can work with the old plugins, and still keep all the engine upgrades. That way, we'll have the best of both worlds.
What I came up with was FOSSIL. FOSSIL does basic interoperability things - it makes MZ able to understand commands from old MV plugins. For instance, when you make a window in MZ, the engine expects you to hand it a single 'rectangle' which tells it exactly where the window should go, and how big it should be. In MV, when you make a window, what you hand the engine can be very different - it might just be 'how many lines of text there are in this window', or it could be 'the x coordinate, y coordinate, width, and height'.
Before any of those commands get to the core engine, FOSSIL converts them into the rectangle that MZ expects. That way, you don't have to actually change how the plugin tries to create a window - FOSSIL just translates it into terms MZ can understand, and then it's fixed everywhere.
Plus, this way, we can make old MV plugins work in MZ while still respecting any licensing they have. Instead of having to track down people who might have left the community, and asking them if we can copy their plugin and make a changed version, we can just use FOSSIL and make MZ understand what the plugin is trying to do.
I have tried my best to minimize any side-effects from FOSSIL's existence. In my test projects there weren't any noticeable changes, but it's entirely possible I accidentally broke something. If that's the case, please post about it in this thread.
I'm super excited about the possibilities with FOSSIL, and I hope a lot of people join in (hence why I'm crediting FOSSIL TEAM). I don't want this to be 'my' plugin, I want the whole community to be able to use all the MV and MZ plugins with the newest engine, and I think everyone here who makes MV plugins knows enough to help improve it.
How to Use
FOSSIL is a single plugin that must go at the beginning of your plugin list. There are no settings to tweak. Since FOSSIL isn't a port, you still need to have the original, unaltered MV plugins, and put them into your game as usual.
So far I have tested over three hundred working plugins (see list), and there's a good chance that even if they aren't listed, most simple plugins will just work 'out of the box' with no tweaks.
How to Write a Fix for Fossil
FOSSIL now automatically detects where plugins are in the list, and applies patches directly before or after the appropriate plugin.
For example, WAY_Core needs us to back up the plugin manager commands before WAY_Core actually runs and changes them. Since we need to run the code before WAY_Core executes, this requires a
PreFix. Here's the code in FOSSIL that makes that happen:
Code: Fossil.loadPreFix('WAY_Core',function()
{
Fossil.backupPluginManagerCommands=PluginManager._commands;
})
//^ see that closing bracket and parenthesis?
//That's important not to forget.
The 'WAY_Core' parameter in loadPreFix tells FOSSIL which plugin it should be looking at.
The code for the fix itself is within the function:
Code:function()
{
Fossil.backupPluginManagerCommands=PluginManager._commands;
}
Because this is load
PreFix, the code will be run just before WAY_Core is executed.
If you need to be before multiple plugins, you can list all of them in an array ['pluginA','pluginB','pluginC'], and it will run immediately before the first one in plugin order (ignoring plugins that aren't in your project).
If we use loadPostFix instead, the code would be run immediately
after WAY_Core. (And listing multiple plugins in loadPostFix will result in applying the fix immediately after the last one in the list).
Plugin Order
There is only one order possible:
1) FOSSIL.js (First plugin)
2) All other plugins.
Other than that, put the plugins ordered the same way you'd put them in MZ or MV. Put plugins that extend each other together like usual. I can't really give more specific instructions than that, it'll all be on a case-by-case basis as normal.
Using Old Plugin Commands
You have three ways of using plugin commands for MV projects
A: use the built in plugin command from FOSSIL
B: Use a script box, with
Code:oldCommand('your old plugin command')
C Copy and paste a MV map into MZ that has an MV plugin command. That command will keep working in the MZ editor, and you can copy and paste it around wherever you want. On some versions of MV and MZ you can just copy-paste the event between editors. It is a mystery why this works for some people and not others.
Screenshot
Download
Backup Link Apparently? -
https://github.com/Arthran2/fossil-MV-MZ
Project FOSSIL (v1.0): Use MV plugins in MZ! 300+ plugins Fossilized!
Tested Plugins
These is the list of over three hundred MV plugins I have tested in MZ which seem to work at a high level of compatibility when using FOSSIL (ie: I went through the major plugin features and they worked, no crashes observed). I tried the latest versions of each, so if you have an older version I can't guarantee anything, and it is entirely possible I missed some feature that I don't normally use, or that FOSSIL updates ended up breaking something after I tested them. It's a lot of plugins and I'm sure I've missed something. (Sadly, several popular plugins, like ultramode7, use a lot of deep function calls, and the MV vs MZ code differences were just too hard for me to disentangle).
As FOSSIL does not contain any plugins, I have also included links to where you can get the ones I've tested.
If there is ANY problem or bug with plugins using FOSSIL, ask in this thread. Don't ask the author for help. The obvious cause of the bug is that you're using a MV plugin in MZ. (And ideally, have a demo that works in MV, and a stacktrace from the console)
Note: Some authors have made ports of their own plugins to MZ. If you aren't trying to port over an existing project, or have extension plugins, I recommend you use a plugin that was actually ported to be MZ native. It's a lot less likely to be buggy
:)
However, since there is a chance that a port to MZ can break extension plugins, (for instance, if a function gets renamed for the MZ version, plugins that patch into the MV function will no longer work), in some cases MV plugins in FOSSIL will have better compatibility than their MZ ports.
CONFIRMED: Fully Functional
This is not an exhaustive list, this is just the ones that have been tested. If a plugin isn't listed here, it could still work!
‡ Indicates that a MV plugin will likely work in MZ without FOSSIL as well as with it.
Mostly Functional (Missing important feature(s), UI is fine)
Functional Mechanics, UI problems (I'd appreciate help with these)
- YEP_X_ItemDurabilityIt works fine, but there isn't an obvious place to put the 'current durability' information in the MZ window layout. If you use this plugin, what would be a good place to put it?
WIP
- Mog's LMBS (if you have worked with MZ battlebacks I'd appreciate the help on this one)
Mobile and Web Deployment Note
FOSSIL creates a 'FOSSILindex.html' file at runtime, and switches to use it instead of the original 'index.html'. This works seamlessly in both playtest and deploy on my computer. However, it is possible this might not be possible in web or mobile environments (I can't test them). However, if you just rename an existing FOSSILindex.html to index.html, you will bypass the html creation step, and proceed with the rest of the plugin. (Basically I need to replace 'main.js' in index.html with 'FOSSIL.js' so I can control when plugins are added).
Terms and Credits
All unique code in FOSSIL is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. The remainder is taken from RPG Maker MV and RPG Maker MZ, and is covered under the appropriate licenses. No code from any existing plugin was used. Credit Restart, 'FOSSIL' or 'FOSSIL Team', and link back to the github or this forum thread.
In order to improve clarity, I am officially stating that the 'CC-BY-SA' only requires that code derived from FOSSIL be also put under a 'CC-BY-SA' license. Other assets in your game, (such as code, art, plugins, et cetera) as well as your game as a whole are
not considered to be 'derivative works' for this purpose - they're just a 'collection of materials'.
Of course this is FOSS, the plugin is named
FOSSIL
:p
Submitting Patches
If you want to submit a patch to add to the FOSSIL main branch, please ask. You will need to agree to license your patch under the same CC-BY-SA terms as the rest of FOSSIL, and that if I ever add an additional open-source license to FOSSIL that your contributions can have that license applied in addition to CC-BY-SA (that way, if we need to add a less restrictive license in the future, it will be possible without tracking down every contributor or turning FOSSIL into a legal patchwork).
If you just want to make your own version from the code, go ahead: it's licensed under CC-BY-SA, I can't stop you. I'd appreciate a mention in the thread, though.