I've been posting that it is both
$game_system.bbg_type = 1 and
$bbg_type = 1 because there are two different versions, the @instance and $global versions. You said you're using the $global version, so your code would need
$bbg_type.
(08-30-2014, 03:35 AM)DerVVulfman Wrote: @bswi13:
Do not edit the actual codework of the script itself. Changing the if...end blocks and so forth would prevent other features such as map-for-battleback systems and others from functioning. You should only change the $game_system.bbg_type (or $bbg_type in your global script case) should be performed.
So you'd be using $bbg_type = 1.
The script itself noted this:
Code:
# USAGE:
#
# This version uses global values used throughout the system. As such, it has
# two bonuses: An easier to find config system at the top of the script, and
# a slightly easier method to change the 'cries' in-game:
#
# This script uses two global values: $bbg_type and $bbg_event
#
# $bbg_type This value determines whether the backgound shown during combat
# will be based on the default systems, based on the terrain tags
# of your tileset, or based on the current events of your story.
#
# $bbg_event This value merely determines what background is used IF you're
# scripting out your game to show the battle background based on
# the events your hero encounters.
#
Now as to making it automatic so it occurs for EVERY battle rather than just events... EASY.
Make an event. Make it a parallel process event. Set up two commands to run in the event commands page on the right in the event window.
The first command is the script call of "$bbg_type = 1"
The second command is the 'Erase Event' command.
This version would re-run this event and re-enforce the bbg_type each time you return to this map. Preferably, I would use a switch after setting the bbg type and making a second page.... but this is the easiest manner.
EDIT:
I am now correcting myself as it has been a long time since I really revisited Mimi. And this is the part that is going to turn your stomach. And yeah, I did test this by merely disabling the instance version and re-enabling the global version in my demo. AND my RTAB demo which has Mimi also performs fine.
Animated battlebacks are an automatic system. That means, unless you set up your battleback system to use the field map or use a custom camera drive and pan system, you should have animated battlebacks automatically.
IF you set a battle to use the current map as the battle back (ie, you see the houses and trees and all that in the background) by setting the bbg_type to 3 ... the map will be the background and not a battleback, animated or otherwise.
IF you turned on the camera drive switch (setting either
$game_system.camera_drive or
$camera_drive to true), you should have a battleback that can be animated. Camera Drive is a cool setting so the backgrounds can zoom in and out, or pan around to make the battle appear to be on a 3Dish camera controlled environment... but it won't work with the animated battleback system.
Code:
# Setting this switch to 'true' disables the battleback animation system and
# prevents it from crashing when regular battlebacks are called. However,
# camera zoom systems cannot be used in tandem with the Map-For-Battleback
# option. To use Field Map Battlebacks, you just can't use Camera Zooms and
# have to keep it set to 'false'.
If you have either the bbg_type set to 3 or turned the camera drive on, you won't have an animated battleback.