Project FOSSIL (v1.0): Use MV plugins in MZ! 300+ plugins Fossilized!

Okay, I think I have it working (check github). There's a little weirdness in how it draws the header and the mail text in two passes, so I'm not 100% sure I have the mail length calculated right, but it works on all the letters in the test project and people can always yell in the thread if it ends up cutting off their messages.

Yay! Thank you. Works a treat. Added mail, had a battle, checked mail, no crashes. Hopefully fixing Utils.generateRuntimeId is handy for some other plugins too ^^;;

FOSSIL 0.4 is out.
What are the changes?

*FOSSIL is now only one plugin. All the sub plugins have been incorporated into the main branch. You put FOSSIL first, and that's it, you're done. This is because:

*FOSSIL can now apply plugin tweaks directly before or after the plugin in question. Before, it was possible that changes could be 'intercepted' by other plugins. Now that changes can be applied between existing plugins, interception is impossible, which should help compatibility overall, even when mixing MV and MZ plugins.

I've done a couple of hours of testing on this, and it SHOULD be stable at this point, but I'd appreciate it if people test to see if v0.4 works with their setups.


Big thanks to @Aesica and Moki for talking about this update with me, getting this to work required some very weird code.

Using that little test project I sent you for DreamX_ChoiceHelp, Choice Help works fine. Put just the JK_MailSystem in though and got this error upon trying to open the mail scene:

EDIT: WAY_Core and other WAY plugins also cause a crash on boot up

Okay, should be fixed. Thanks for the test :)

Looks like the bugs in 0.4 are fully ironed out.


@Pivoo is one of the plugin makers that I think deserves to get a lot more recognition. Pv_ParticleCore is a fun, easy-to-use plugin that lets you add on-map particle effects in a simple controllable way. It runs on the pixi-particles library. While the import instructions on the site don't work in MZ anymore, if you put the library file in the right directory FOSSIL will import it for you (something I couldn't do before version 0.4).



Click here to download Pv_ParticleCore (as well as pivoo's core plugin and the pixi-particles library - note that the direct library link is dead, but the demo project still has it.)

The other two Pivoo plugins are Skill Categories and Battle Command Customizer. These are very robust and powerful battle interface plugins.

Pv_BattleCommandCustomizer: With BCC you can change the entire default battle command list for all actors, or configure lists for individual characters, classes, states, or equipment.

Pv_SkillCategories: With skill categories, you can turn a skill into a menu option instead - so instead of having fire1, fire2, fire3, inferno, and fire4 all mixed in your skill list, you can just pick the 'fire skills' box and bring up a list of only the hottest skills. Super handy in any game that has a lot of skills.

Hey restart! Thanks for your effort at this.

I just started using this. I'm getting an error when on YEP_victory aftermath.

Want to take a look?

Thanks if you could.

Hey. Couldn't help but wonder something... do I need to put the MZ plugins on top, as in above FOSSIL, or should those be under FOSSIL as well? I'm working on a game right now with the FOSSIL capabilities included, but I don't know if I'm doing it right. Please assist, restart.

With the new version you just put FOSSIL.js in first and put the rest of plugins in normal order. Since version 0.4 it now takes over the plugin manager and inserts 'virtual' plugins whenever it needs to apply a fix to a particular MV plugin.


Can you give me the full stacktrace from the console (f12 or f8 to bring it up)?
Are you using any other plugins? Visustella tends to break yanfly plugins.

Hey Restart.

I don't have any visustella plugins turned on.

Here's a pic of my plugins:



Here is the picture of the stack after the error with victory aftermath:



Thanks for any help you can give.

So, to be sure, you're saying that I can just put the new version of the plugin at the top above the other plugins, including the MZ plugins? What order would I need to put the whole plugin list in, then? FOSSIL.js before the rest of the plugins, true, but what about other MZ plugins?

Okay, I think I found the issue - your project probably has an older version of MZ which lacks a few functions. Update to 1.2.1

Mixing mv and mz is essentially like using just MV or just MZ at this point - it depends entirely upon the plugins, so I can't give a good general answer, beyond the standard 'keep things from the same author together except when you don't'.

In other news, version 1.0 is up!

Thanks for the heads up. :) I appreciate it.

Any possibility that you'll add 'YEP_X_VisualStateFX' to the list?

have you tried it?

Yes I did, the animation isn't shown (overlays like poison, paralyse works).
When the actor gots a state the game gots error.

I spent a while looking at it, and the main issue is that the yanfly code defines a new Sprite_StateAnimation object, and bases it off the existing Sprite_Animation, then adds custom bits to that.

However, MZ's animations are very different than MV's (for instance, unlike MV, the MZ engine doesn't actually know how long an animation will take to run). Worse than that, MZ animations are the "Sprite_Animation" object, and MV animations are the "Sprite_AnimationMV" object - so Sprite_StateAnimation will try to treat all animations as MZ animations and produce the MV/MZ frankenanimation even if you give it something it used to work with.

I think this is more of a candidate for an edit or a replacement, since basic things like 'how often does this need to repeat' would need to be passed in on a per-animation basis, and it'd be more of a pain to work around the existing code for that than to do this relatively simple effect from scratch.

What's the impact on the performance of the plugin that's being fossilized?

I have some compatibility issue with FOSSIL plugin and MV imported animation with NRP_DynamicAnimationMV2MZ and NRP_DynamicAnimationMZ.
When they are used with FOSSIL base I get error 'Cannot find property of 'concat' of undefined'.
Without FOSSIL everything works fine.

odd, I'll look at it. One of the things I've been trying to do is get the animation.frames.length shortcut used by MV plugins to assess the duration of an animation to work on MZ-native animations (which don't have any frames), so it's possible that this has messed up something somewhere. I've been futzing with that recently - do you have the latest version of FOSSIL?

EDIT: figured out the issue. The plugin creates its own $dataAnimationsMV object to store MV animations. I've altered my code to include a fallback to the original behavior so this (and other similar plugins) should work. Fixed in 1.0.03

In principle shouldn't be noticeable; you do end up having more code executing but I don't think there's anything that's slow enough to matter.

For instance, if you create a window, normally the call is something like MyCustomWindow->WindowSelectable->WindowScrollable->Window_Base->Window. Fossil will end up checking that a rect is being passed in to define the size between each step, which is a little bit of extra overhead, but checking if it's being passed a rectangle is pretty quick.

There are definitely places where you could make it more complex and more efficient, but to a large extent Fossil is not much different than existing accepted inefficiencies using plugins instead of altering core scripts. (For instance, it's always going to be a little faster to just alter a function by changing the original file instead of aliasing it and injecting code, but ease of use is really important). In theory I could avoid a few evals at startup by turning plugin-specific fixes into dataurls, (or into actual on-disk files), but the current method hasn't shown any issues so far (aside from making it a little harder to set breakpoints before running code), and I believe eval is going to be faster than accessing the hard disk or modifying the DOM.