This article describes map transfers. It details all the ways in which the player can instantly move from one map to another.
Doors are essentially events that transfer the player to another place. The complexity seen in door events is due to animating the door, moving the player, playing sound effects and fading the screen out and in.
Door events have two pages. The first page is for entering through the door, and the second page is for when the player is coming out through it.
Although an event only takes up one tile, you can have large doors that are more than one tile in size. You just need to manage your events properly.
The door images should come from a character image file (in the folder "Graphics/Characters"). See the example door graphics that come with Essentials for an idea of how to arrange these graphics.
Door event, page 1
This page has no conditions, and is triggered by the player's touch. Its graphic is of a closed door. Typically, this page's event commands are as follows:
@>Set Move Route: This event (Ignore If Can't Move) : : $>SE: 'Entering Door', 100, 100 : : $>Wait: 2 frame(s) : : $>Turn Left : : $>Wait: 2 frame(s) : : $>Turn Right : : $>Wait: 2 frame(s) : : $>Turn Up : : $>Wait: 2 frame(s) @>Wait for Move's Completion @>Set Move Route: Player (Ignore If Can't Move) : : $>Through ON : : $>Move Up : : $>Through OFF @>Wait for Move's Completion @>Change Transparent Flag: Transparency @>Set Move Route: This event (Ignore If Can't Move) : : $>Wait: 2 frame(s) : : $>Turn Right : : $>Wait: 2 frame(s) : : $>Turn Left : : $>Wait: 2 frame(s) : : $>Turn Down : : $>Wait: 2 frame(s) @>Wait for Move's Completion @>Change Screen Color Tone: (-255,-255,-255,0), @6 @>Wait: 8 frame(s) @>Change Transparent Flag: Normal @>Transfer Player:[003: \PN's house], (003,008), Up, No Fade @>Change Screen Color Tone: (0,0,0,0), @6 @>
Note that the "Change Screen Color Tone" commands and the "Transfer Player" command are useful for other kinds of player transfer too.
Door event, page 2
This page has the condition that Global Switch 22 should be ON, and it is set to Autorun. Its graphic is the same as the first page. Typically, this page's event commands are as follows:
@>Conditional Branch: Script: get_character(0).onEvent? @>Change Transparent Flag: Transparency @>Set Move Route: This event (Ignore If Can't Move) : : $>SE: 'Entering Door', 100, 100 : : $>Wait: 2 frame(s) : : $>Turn Left : : $>Wait: 2 frame(s) : : $>Turn Right : : $>Wait: 2 frame(s) : : $>Turn Up : : $>Wait: 2 frame(s) @>Wait for Move's Completion @>Change Transparent Flag: Normal @>Set Move Route: Player (Ignore If Can't Move) : : $>Move Down @>Wait for Move's Completion @>Set Move Route: This event (Ignore If Can't Move) : : $>Turn Right : : $>Wait: 2 frame(s) : : $>Turn Left : : $>Wait: 2 frame(s) : : $>Turn Down : : $>Wait: 2 frame(s) @>Wait for Move's Completion @> : Branch End @>Script: setTempSwitchOn("A") @>
This page checks whether a player is standing on the door, and if so, shows the player coming out of it. This means that when choosing where a door should lead to, you should choose the tile with the door event on it (i.e. the door itself, not below it).
Stairs behave much like doors, except they do not (usually) animate while the player steps onto them.
Sideways-facing stairs are a problem when making the player walk up them, as due to the game's perspective the player should only go up/down by half a tile for every tile they go across. Such a movement cannot easily be done in RPG Maker XP, and unless you spend a lot of time learning how to do this, you will need to suffice with having the player move diagonally (1 tile across and 1 tile up/down), but fading out for the transfer before it becomes obvious that the player isn't moving properly.
On the right is an example of an event for side-facing stairs that go up and to the left. To adapt this for other directions, simply change the direction the player is made to turn, and the diagonal direction the player is made to step in. If the stairs go downstairs, it is recommended that the player simply move left/right rather than diagonally.
Warp tiles are simply tiles that, when the player steps on them, will transfer the player to another place. They work in exactly the same way as doors and stairs do, in that they all use the "Transfer Player" event command.
You could also have animations, such as making the player spin around before transferring, or having the screen flash or the warp tile itself animate.
Cave entrances and exits
There are special animations that can/should be used for when the player enters or exits a cave. These animations are played by the two methods
pbCaveExit respectively. There are examples of how to use these methods in the example maps.
As mentioned below, these animations are connected to the use of Dig and the Escape Rope (i.e. they can be used in caves).
The normal method of transferring the player to a different map (i.e. the event command "Transfer Player") will automatically cancel surfing when it is used. To allow map transfers while remaining surfing, an alternate method must be used instead:
This script will transfer the player to a different map while ensuring that they remain surfing. In the example given, the destination is map 42, at coordinates (10,14). The fourth parameter is optional, and is the direction the player will end up facing (by default, it is the player's current facing direction).
This allows the player to surf directly into a cave or other structure.
The normal method of transferring the player to a different map (i.e. the event command "Transfer Player") will automatically cancel diving when it is used. To allow map transfers while remaining diving, an alternate method must be used instead:
This script will transfer the player to a different map while ensuring that they remain diving. In the example given, the destination is map 42, at coordinates (10,14). The fourth parameter is optional, and is the direction the player will end up facing (by default, it is the player's current facing direction).
This allows the player to dive underwater and then pass through into an underwater cave.
Fly, Teleport and Dig
- Main article: Using moves outside battle
The moves Fly, Teleport and Dig all instantly change the player's location.
For more information about how Dig chooses where to send the player (and when it can be used), see the "Escape Rope" section below, as they both use the same system.
The Escape Rope is an item that will change the player's location, and is the item equivalent of the move Dig. It can only be used while there is an escape point set, and only if the player has no dependent events (e.g. a partner trainer).
In most cases, the location where the player is able to use an Escape Rope/Dig will be a cave interior, in which case you will be using the methods
pbCaveExit to enter/exit those areas (see above). These methods automatically set/erase the escape point at the same time, so if you are using them, you do not need to worry about the escape point. In the rare situations where you want to set/erase the escape point without using the cave transition animation, see below.
When a cave or other Escape Rope-able location is entered, the escape point needs to be set (
$PokemonGlobal.escapePoint). To do this, put a call to the method
pbSetEscapePoint immediately before the map transfer (which should be a doorway or entrance of some kind). This method will set the escape point to the spot behind the player (who will currently be standing on the entrance when this method is called), i.e. the spot in front of the entrance.
When leaving an Escape Rope-able location, the escape point needs to be erased. To do this, put a call to the method
pbEraseEscapePoint in any map transfer event which leads out of that location. The escape point is erased automatically when using Fly/Teleport/Dig/Escape Rope/blacking out.
The Escape Rope's effect is located in the script section PokemonItemEffects.
If the player has no able Pokémon left, they will black out and return to the last Poké Center they talked to the nurse in. This usually occurs in the field when the player's last Pokémon faints because of poisoning, and at the end of a battle if the player lost that battle.
The scripts that transfer the player when they black out are located in the script section PokemonField.
pbCheckAllFainted checks whether the player has no usable Pokémon left and displays the messages, and
Kernel.pbStartOver handles the actual transfer. If the player blacked out because of losing a battle, only the latter of these scripts will be used.
The location the player is transferred to is set by the script
Kernel.pbSetPokemonCenter, which should appear at the start of every Poké Center nurse's event. This location is the player's current position when they talked to the nurse. If this hasn't been set (i.e. the player has not yet talked to a Poké Center nurse), then the coordinates used will be those in the global metadata "Home" instead.
When the player blacks out, the Global Switch with the number given by
STARTING_OVER_SWITCH (in the script section Settings; Global Switch 1 by default) is set to TRUE. This lets you do special things after returning to the last healing spot, such as having a nearby NPC say something about not pushing your Pokémon too hard. To take advantage of this, simply have an Autorun event on the map the player will return to check whether this Global Switch is TRUE. This is usually the nurse or the player's mother.
The player's party will also be fully healed.
The location signpost
When entering some maps, a message window will appear in the upper left of the screen announcing the name of that map. This is the location signpost.
Only maps which have the "ShowArea" metadata set to TRUE will show the location signpost. Typically, these will be outdoor maps and some important indoor locations.
The scripts that handle what the location signpost looks like are in the script section PokemonField, in the class
LocationWindow. These scripts are called from the procedure
Events.onMapSceneChange in the same script section.
If the location signpost should appear when stepping onto a particular map, but the player has just come from another map with the same name, then the location signpost will not be shown instead. This is useful for splitting up large routes/towns into multiple maps, and means that the location signpost won't be shown in the middle of traversing those routes/towns (it will only appear when the player enters that route/town in the first place).
You can also stop the location signpost from appearing for certain other map transfers that would ordinarily show it. To do this, in the script section Settings is an array called
NOSIGNPOSTS. Enter the map ID numbers of the two maps where you don't want the location signpost to appear when moving from one to the other (or vice versa). The order in which you put these numbers doesn't matter, and you can add as many map pairs as you like. For example:
This example will stop the location signpost from appearing if the player moves from map 4 to map 5 (and vice versa), from map 16 to map 17 (and vice versa), and from map 42 to map 43 (and vice versa).
Recording where the player has been
There is an array which records the player's most recent movement between maps:
This array stores the ID numbers of the last 4 maps the player has been on, including the map they are currently on. They are stored in order from newest to oldest, i.e.
$PokemonGlobal.mapTrail is the current map,
$PokemonGlobal.mapTrail is the map just before the current one,
$PokemonGlobal.mapTrail is the map before that, etc.
It is updated in the same place in the scripts that the location signpost is dealt with.
- Don't forget that you can lock/unlock doors and enable/disable warp tiles by various methods, such as checking whether the player has a certain Key Item or by changing a Global Switch when a certain thing happens.