FEATURES
Can use battleback graphics that contain multiple frames to cycle through for animation. I advise using sparingly as the files can become quite large and add a lot to loading times if too many frames are used (a precaching plugin might be worth looking into if that is the case).
The upper battleback and lower battleback can be mixed together with animated or not animated backgrounds.
VERSION 1.0 – RPG Maker MV
Download Plugin file
Download Demo
The plugin when i use it gives me an error “Cannot read property x of undefined”. I post here all the details from the console:
I use YEP_CoreEngine and some other YEP and SRD plugins and i already tried to:
-Disable all the plugins
-Save and reopen RM
-Change filename (like “Desert(3,10)” without spaces)
I looked up the code but i cannot find the error.
My version of RM is 1.6.1.
I really need this plugin to make an Earthbound style battle backgrounds for my game.
Thanks for your time.
Here’s a list of things to try to error trap: https://galvs-scripts.com/errors-using-plugins/
My first thought is – did you start a new game after adding the plugin?
I’ve made some test and it seems that YEP_CoreEngine is the problem, since when I have it disabled it works.
Is the core engine at the top of the plugin list above other plugins?
Yes is the first.
I’m going to get in touch with Yanfly to solve this problem.
Yes is the first.
Were you able to figure out a solution? I am having the same issue
No, unfortunately, I’ve tried to contact Yanfly but I got no response. Since then i decided to give up on this… I’ve made my custom script to make pseudo-earthbound animated backgrounds in GameMaker. I’ve noticed that RPG Maker MV was not the perfect solution to do what I was planning. You can try to contact Yanfly yourself and see if you can get a response.
The problem is caused by Yanfly’s CoreEngine. It’s related to the scaling of battle backs. The core changes a lot about how battle backs work to solve other issues so I wouldn’t expect a fix from Yanfly. Breaking compatibility with this plugin has to be a pretty low priority if this change was warranted. I’m not really sure that it is, at this point, but I didn’t dig around in their long enough to figure out exactly what’s causing the conflict.
Anyway, you have a couple of options. First, you can turn off battle back scaling in Yanfly’s CoreEngine and that’ll resolve the error. Alternatively, you can probably just download an earlier version of the core. It seems like this conflict was introduced in version 1.2.3 at the earliest. I’m not sure and am just making a barely educated guess based on skimming the release notes, but that might be worth a try. Of course, that could break compatibility with any plugins that rely on changes in the latest version but if you can find an older version of the entire set you can just replace them all with the earlier version. But turning off battle back scaling is probably an easier alternative. You can just scale those in an image editor if you need to.
So, never mind what I just said. :-P I mean, it still holds but I fixed the problem. I was planning on just letting it go, but when I was about to close the file for Yanfly’s core I realized what needed to be done…and I can’t ignore stuff like that.
Basically, Yanfly changed battle backs to display through the standard Sprite class instead of the TileSetter class because TileSetter is unreliable (apparently). Galv’s animated battle backs plugin works around the use of TileSetter so it ignores anything Galv’s plugin does if it appears before the core in the plugin list and breaks the plugin if it appears after because the battle backs aren’t getting set by TileSetter. That’s why x is undefined. It would be defined if Galv’s plug-in referenced the new class.
So, I changed it to reference the new class. I also had to recalculate the x because Yanfly centers the battle backs for scaling purposes so only (less than) half the animation would run (replaced by empty black frames for the other half+ frames), otherwise Galv’s plugin would start from x=0. That makes sense if 0 is the leftmost corner of the image but it’s now the center of the frame that holds the battle backs. So, x can’t equal 0 but, rather, needs to equal -1/2 of the total width of the background image + the width of one frame. This fixes the offset issue.
The right way to add this code would be to add a check to see if Yanfly’s CoreEngine plugin is loaded first and then only run these changes if it is. But I was lazy and didn’t do that. :) So, if you want to use the fix I made, you can only use it if Yanfly’s CoreEngine is installed and above Galv’s plugin and has its scale battle backs setting set to true. (Maybe it doesn’t need to be set to true—I’m just guessing—but I’m pretty sure you’ll have issues if you disable it just based on what I saw in Yanfly’s core.) Here’s a link if you want to download it:
https://www.dropbox.com/s/4mls2d6nhp70uuf/galv_animatedbattleback_yanflycorefix.js?dl=0
Hope that helps! :)
So I have a question! Would this be able to work in a way where, the background will animate before a battle starts, and then animated after a battle ends? I am trying to figure out how to do a fade out and fade in, but by changing the image, kind of like how an NES game does it, not having the built in fade that comes in with RPG Maker
This plugin doesn’t do that, no.