Essentials Docs Wiki
Advertisement

This page describes how to set up obstacles, which can be a (temporary) physical barrier or a special kind of path (such as sliding ice). It also describes how to set up Headbutt trees. Most obstacles described here can be overcome or traversed by using a move outside battle.

Event obstacles

These, quite simply, are events that cannot be passed. Most of them can, however, be moved or destroyed. Such events include:

  • Trees that can be cut down (Cut).
  • Cracked rocks that can be smashed (Rock Smash).
  • Boulders that can be moved (Strength).
  • NPCs that block paths/doors.

Cut trees

A tree that can be cut down with the move Cut should contain the following commands:

@>Set Move Route: This event
 :              : $>Turn Down
@>Conditional Branch: Script: pbCut
  @>Script: pbSmashThisEvent
  @>
 : Branch End
@>

It should also have a name that includes "CutTree" (without a space), as when the player chooses to use Cut from the party screen, one of the checks performed to see if it can be used is whether there is an event immediately in front of the player with this in its name (and if so, to use Cut).

The script called in the Conditional Branch includes messages such as "This tree looks like it can be cut down." and asks whether the player wants to do so (if they can). Therefore there is no need to include these messages in the event.

When cut down, a Cut tree will only disappear until the player leaves the map; at which point, it will reappear. To cut the tree down permanently, after the pbSmashThisEvent script line, add a command that sets the event's Self Switch A to ON, and give the event a second (blank) page which depends on Self Switch A being ON.

Cracked rocks

A cracked rock that can be smashed with the move Rock Smash should contain the following commands:

@>Set Move Route: This event
 :              : $>Turn Down
@>Conditional Branch: Script: pbRockSmash
  @>Script: pbSmashThisEvent
  @>Script: pbRockSmashRandomEncounter
  @>
 : Branch End
@>

It should also have a name that includes "SmashRock" (without a space), as when the player chooses to use Rock Smash from the party screen, one of the checks performed to see if it can be used is whether there is an event immediately in front of the player with this in its name (and if so, to use Rock Smash).

The script called in the Conditional Branch includes messages such as "It's a rugged rock, but a Pokémon may be able to smash it." and asks whether the player wants to do so (if they can). Therefore there is no need to include these messages in the event.

When a cracked rock has been smashed, there is a chance that there will be a wild Pokémon encounter (if there are "RockSmash" encounters defined for the map). The chance is defined in the PBS file "encounters.txt" just like the chances for Land, Cave and Water encounters.

When smashed, a cracked rock will only disappear until the player leaves the map; at which point, it will reappear. To smash the rock permanently, after the pbSmashThisEvent script line, add a command that sets the event's Self Switch A to ON, and give the event a second (blank) page which depends on Self Switch A being ON.

Boulders

A boulder that can be pushed with the move Strength should trigger not by pressing the Use button like above, but instead when the player walks into it (Player Touch). It should contain the following command:

@>Script: pbPushThisBoulder

It should also have a name that includes "StrengthBoulder" (without a space), as when the player chooses to use Strength from the party screen, one of the checks performed to see if it can be used is whether there is an event immediately in front of the player with this in its name (and if so, to use Strength).

The script called simply checks whether Strength has been used already, and if so, to move the boulder away from the player. The script that asks the player whether they want to use Strength in the first place is a procedure that checks whether there is an event immediately in front of the player with a name that includes "StrengthBoulder", and if so, to call a method that asks whether the player wants to use Strength. See the page Using moves outside battle for more information about this procedure.

A moved boulder will return to its original position once the player leaves the map. Some puzzles require the boulder to remain in its new place (e.g. on a pressure switch), or to disappear (e.g. pushed down a hole). To do this, you should create a "control event" which constantly checks the boulder's position via Parallel Process, and which makes it become inert/disappear if it is in a particular location (by switching to a new page of the boulder's event via manipulating its Self Switches).

Headbutt trees

Headbutt trees are, strictly speaking, not an obstacle because they can never be overcome. However, they are included here because they work similarly to the above obstacles.

A tree that can be headbutted with the move Headbutt should contain the following command:

@>Script: pbHeadbutt

It should also have a name that includes "HeadbuttTree" (without a space), as when the player chooses to use Headbutt from the party screen, one of the checks performed to see if it can be used is whether there is an event immediately in front of the player with this in its name (and if so, to use Headbutt).

The script called includes messages such as "A Pokémon could be in this tree. Maybe a Pokémon could shake it." and asks whether the player wants to do so (if they can). Therefore there is no need to include these messages in the event.

When a tree has been headbutted, there is a chance that there will be a wild Pokémon encounter (if "HeadbuttLow" and/or "HeadbuttHigh" encounters have been defined for the map). The method that decides this is pbHeadbuttEffect in the script section Overworld_FieldMoves. The calculation of the encounter chance, and which type of Headbutt encounter is used, is a little complicated and involves the tree's coordinates and the player's trainer ID number. The chance is either 10%, 50% or 80% depending on the calculation, and if it is 10% the "HeadbuttLow" encounter type is used ("HeadbuttHigh" is used otherwise).

Terrain tag obstacles

These are tiles with particular terrain tags that prevent or limit the player's movement. Such terrain tags are:

  • 1 - Ledge
  • 5, 6, 7, 8, 9 - Water tiles (for surfing)
  • 5 - Deep water (for diving)
  • 8 - Waterfalls (for ascending waterfalls)
  • 12 - Ice

The movement restrictions of these tiles (except Ice tiles) are actually defined by their passabilities rather than because of a special property of the terrain tags themselves. The terrain tags mentioned are only noteworthy because they affect how the player moves over these tiles (see also the page Tilesets):

  • 1 - The player jumps over this tile rather than walking over it.
  • 5, 6, 7, 8, 9 - Can be traversed by using the move Surf.
  • 5 - Can cause a map transfer by using the move Dive while on this tile (see below).
  • 8 - The player automatically passes over these tiles, either by surfing down it or using the move Waterfall to climb it.
  • 12 - The player slides in the same direction until they hit something.

For the most part, setting up obstacles using these tiles is as simple as creating the map using these tiles.

Waterfalls

Waterfalls involve two different terrain tags: 8 (the main part) and 9 (the crest/top).

The main part of a waterfall cannot be surfed over, and it must be interacted with in order to ascend it (with the move Waterfall). When the player ascends a waterfall, they will keep moving up until they are no longer on a tile with either of the waterfall terrain tags.

The crest of a waterfall is the top row of tiles of a waterfall. When the player surfs onto a waterfall crest, they will automatically fall down the waterfall until they are no longer on a tile with either of the waterfall terrain tags.

While moving up or down a waterfall, the player will not encounter any wild Pokémon.

Underwater areas

There is a terrain tag for deep water (5). When the player uses the move Dive while surfing on a tile with this terrain tag, they will be transferred to a different map. The map they will transfer to is defined by that map's "DiveMap" map metadata. All maps with reachable deep water must have this map metadata set. Multiple maps cannot have the same "DiveMap" map metadata.

The underwater map must be the same size as the surface map. This is because when the move Dive is used, the player is transferred to the same coordinates on the underwater map as they were at on the surface map (and vice versa). Because of this, it is vital that wherever Dive can be used on the surface, there is a corresponding open area where the player can dive to in the underwater map (i.e. there are no rocks or NPCs or anything there which they could land on).

While underwater, the player can only surface by using the move Dive at coordinates where there is deep water on the surface map.

Advertisement