Transfers and battlebacks

[Kes]

My battlebacks are specified in Map Properties in the normal way, and when I enter a map through the usual transfer, everything is as it should be.


However, in play testing just now, I used the Egress skill to transfer back to the beginning of the dungeon, and decided to fight one more battle just to get to level up.  That's when I saw that the battleback was not showing.  It wasn't the whirly thing you get when you haven't set a battleback, it was just pure black.  Thinking that maybe it was something to do with the common event I use to do the Egress skill, I set up an event which transferred me back in the normal way.  Same thing, just pure black.


Does anyone have any ideas about what might cause this?


Thanks

 

[Rinobi]

I wasn't able to replicate the error, but I think these are the most likely suspects. 

Spoiler

class RPG::Map
def initialize(width, height)
@display_name = ''
@tileset_id = 1
@width = width
@height = height
@scroll_type = 0
@specify_battleback = false
@battleback_floor_name = ''
@battleback_wall_name = ''
@autoplay_bgm = false
@bgm = RPG::BGM.new
@autoplay_bgs = false
@bgs = RPG::BGS.new('', 80)
@disable_dashing = false
@encounter_list = []
@encounter_step = 30
@parallax_name = ''
@parallax_loop_x = false
@parallax_loop_y = false
@parallax_sx = 0
@parallax_sy = 0
@parallax_show = false
@note = ''
@data = Table.new(width, height, 4)
@events = {}
end
end

Spoiler

  #--------------------------------------------------------------------------
  # * Set Up Battle Background
  #--------------------------------------------------------------------------
  def setup_battleback
    if @map.specify_battleback
      @battleback1_name = @map.battleback1_name
      @battleback2_name = @map.battleback2_name
    else
      @battleback1_name = nil
      @battleback2_name = nil
    end
  end

Spoiler

  #--------------------------------------------------------------------------
  # * Change Battle Background
  #--------------------------------------------------------------------------
  def change_battleback(battleback1_name, battleback2_name)
    @battleback1_name = battleback1_name
    @battleback2_name = battleback2_name
  end

If you have any scripts installed that alias or overwrite these methods, it could be the cause.


If you use Ctrl + Shift + F search with your script editor open and type in these method names, you may find a custom script listed somewhere.


Trying searching for RPG::Map, setup_battleback, change_battleback, and battleback1_name and/or battleback2_name.


I think @battleback1_name and @battleback2_name are being set to nil, either by script or the event command on the third tab.


If @map.specify_battleback returns false, I can see this happening. Since I think the setup_battleback method runs every time you change maps.

 

[Kes]

The only times custom scripts came up with those searches was these:


RPG::Map     3 instances, all in Yanfly Parallax Lock script  (lines 73, 76, 116)


setup_battleback    1 instance in Effectus script  (line 780)


I have no problem when I try this with a New Game, nor (at least up till now) when I've transferred onto maps in the ordinary way.  I used both of those scripts in my last game, and no player has reported an issue with battlebacks so far.

 

[Shaz]

So your battleback is set on entering the map and shows during battle on that map, your event transfers the player to a different location on the same map, and after that the battleback doesn't show anymore?


I would probably put some debug statements in the 4 instances you found in that search, so it shows you when each one is called, and what battleback it's trying to set up.  Once you know what IS happening, it might give you a clue how to fix it.


You're not using a script that clears the image cache are you?

 

[Kes]

How do I do the debug thing?


I have no idea about the clear image cache 

 

[Shaz]

go into each of those methods and as the first line after the def statement, add the following:


p 'script_name_and_line_here'


Just make sure each of them say something different, so you can track the output to the script and line that made it.


Also go into your event that does the transfer, and immediately before the transfer, add a script call with this:


p 'transferring now'


then play with the console turned on.


When you transfer, 'transferring now' should be printed out to the console, followed by any of those four methods.  It might even print out all of them, which is still useful to know, though it doesn't get you much closer to the result.


Also keep in mind that it might not be the transfer command.  There could have been something that happened between your last battle and the moment you used the skill, that changed the battleback.  It might be good to test this first.  If you add something like this to your event that does the transfer (common event for skill?) it will confirm that the battleback actually IS being messed up as part of the transfer and not at some other point:


Battle Processing


Wait 60 Frames


Transfer as normal


Wait 60 Frames


Battle Processing


The other thing is, playing with the console on might give you some errors that indicate why the battleback isn't showing, but the game doesn't crash.  This would only happen if the scripters actually wrote their scripts to cater for that - I'd be surprised.  But it's worth checking.

 

[Kes]

This is what the console showed

 

[Shaz]

Did you do the event changes to prove that the battleback was okay immediately before the change, but not after?


Next thing to do would be to disable those scripts one at a time if possible, testing after each one, to see if you can identify which one causes it.  Try effectus first, as there's no chance disabling it could cause problems with the Yanfly scripts.


If disabling them is going to cause other things (like script calls) to fail, you could just comment out the individual methods - again, one at a time.

 

[Kes]

I tried disabling Effectus and all its related scripts (e.g. the compatibility patch for your mouse script) and it is still the same.


Just for the sake of clarity, in your first reply you referred to transferring within the same map - in fact this is from another map.  I tried it with transfering on the same map and still had the problem.


In your subsequent post you suggested the following insert into the transfer event:


Battle Processing


Wait 60 Frames


Transfer as normal


Wait 60 Frames


Battle Processing


I don't quite follow this, because the Battle Processing command requires me to state a troop, and so when I activate the transfer event it will initiate that battle where I am.  I assume, therefore, that you mean something other than the command from tab 3 of the event menu, but if so, I don't know what.

 

[Shaz]

I just want you to call a battle immediately before the transfer, and again immediately after, to confirm that it IS the transfer command that's messing things up (the first battle has the correct battleback, and the second one doesn't).  Just put in an easy troop so you can be done with the battle quickly.


When you said "transfer back to the beginning of the dungeon" I assumed you meant the same map.  

 

[Kes]

My internet crashed for a while, but I'm back now.


I did the extra battles and they were fine, though the battle back inside the dungeon was significantly darker than normal.  The 'proper' battle had no battleback, though given how dark the test one was, I'm wondering if it was there, but simply not discernible. I left that map and returned, and everything was back to normal.  I also tried transferring to the other map in that dungeon, just in case it was something specifically about that original map, but that made no difference, except even the 2nd test battle had no discernible battleback.


As an experiment, I repeated the whole thing, but going to a different dungeon altogether, no problems at all.  I don't yet have a third to try out.  I am utterly perplexed.

 

[bgillisp]

Check and see if you have an event somewhere that sets the battleback to none. I've seen this happen where I checked the battleback box on the map properties, but forgot to set the battleback. Also a really dark tint can make it so that no battleback shows up (an effect I used once to create a battle in total darkness).

 

[Kes]

I've never used an event to set the battleback to none, so that's out.  Also, as I said in my last post, if I exit that map and return to it, everything is back to normal.


I am wondering about the darkness, though.  As I mentioned, the test battle (i.e. the one as part of the transfer event) does show the battleback, although very dark.

 

[Rinobi]

The Tint Screen event command also affects battlebacks in my experience,


it can make battlebacks appear nonexistent if set dark enough, but that usually also


affects any battlers on screen and you'd notice a tint that dark on the map anyway.


Try running a Tint Screen command on the second tab with the default settings either inside


of the troop that appears in your tests, or just before the problematic battle begins.


For the second test, use the Change Battle Back event command on the third tab just before


the start of the problematic battle. Set it to anything...


It's strange that you've been able to replicate it on one map, there must be something we're missing...


Are you using a script for lighting effects?

 

[Kes]

I've done the tint screen to normal suggestion.  It means that the test battle on the map I transfer to has a battleback that is the correct colour.  However, an ordinary battle there is still totally black.


However, your question about a lighting script reminded me of something.  I don't have a lighting script, but I do have a script which lets me choose whether I have the map screen tint for the battle screen or not.  So far I have always had it on, without any issues, including on this problematic map.  However, by incorporating a command to turn that switch off, the battleback showed up.  That seems to be the issue.


Thank you for that prompt, I had forgotten about that.  I shall play around with it now and see what happens when it is permanently off for that particular dungeon.


Your help is much appreciated.


EDIT


Haha!!!  I did these maps a long time ago, before I was off for 6 months following an accident.  I had forgotten that on all the transfer events into that particular dungeon I had that switch set to OFF as the battle screen was too dark.  Now, with this transfer in, I was bypassing that particular command, so the game didn't know that it should be de-activated, and so I had the problem.  I've put the command into the parallel process that I have there which does other things, so now, problem solved.


@Shaz and @Rinobi  without your help I'd never have found this.  Thank you both very much.


Closing