- For how to define a trainer, see Defining a trainer.
This page describes partner trainers. It details both registering/deregistering a partner trainer (for battles) and making an event dependent (for having them follow the player around).
Setting a partner trainer up
Partner trainers are identical to any other trainer, so you should create them in exactly the same way as you would any other trainer. The only difference is in how they are used (they are an ally in battle rather than an opponent).
Partner trainers also require a back sprite, just like the player characters have back sprites. Back sprites are specific to trainer types, and are placed in the folder "Graphics/Characters" with the name "trbackXXX.png", where "XXX" is the trainer type's ID.
Typically, partner trainers will have a trainer type unique to themselves (i.e. there are no other trainers in the game that share their trainer type). This is only a rule, though; you can have the player team up with a Bug Catcher if you want.
Teaming up with a partner
Having a registered partner trainer will cause all wild battles to be double battles, and these plus any double trainer battles (either defined as a double battle or a case of two trainers spotting the player at the same time) will involve both the player and their partner against the opponent(s). 1v1 battles against a single trainer are unaffected, and the partner will not participate in those battles.
After every battle (even single ones which the partner didn't participate in), the player's party will be fully healed (ostensibly by the partner).
The player can only team up with (i.e. register) one partner at a time.
Registering a partner
Partner trainers must be registered and deregistered. This is done with the following code:
The parameters for
def pbRegisterPartner are as follows:
- The partner's trainer type. Note the colon at the beginning.
- The partner's name, in quote marks.
- Optional. A number used to distinguish between different versions of the same trainer. Default is 0.
This is the same way you define an enemy trainer when you set up a trainer battle (trainer class plus name plus optional number).
To deregister the partner trainer, use the following line of code:
As there can only be one registered partner at any one time,
def pbDeregisterPartner doesn't have any parameters.
This section explains how to have the partner trainer's event follow the player as they walk around the map. More generally, it explains how to make any event follow the player - event dependency is not solely for partner trainers (it just makes sense to use a dependent event for a registered partner).
While the player has any dependent events, the player cannot use the moves Surf, Fly, Teleport or Dig outside battle, nor use an Escape Rope. The player can talk to the dependent event, but the contents of that interaction must be in a Common Event rather than in a page in that dependent event.
Making an event dependent
When registering a partner trainer, you will typically also want to make that trainer's event dependent (i.e. follow the player around). To do this, use the following line of code:
pbAddDependency2(@event_id, "Dave", 42)
The first argument is the ID number of the event that will follow the player (
@event_id means the event that this script is used in). The second argument is a name or phrase used to identify the dependent event. The third argument is the ID number of the Common Event to call when the player talks to the dependent event.
Common Events are listed in the Database (F9). They are similar to events, except they only have one page and limited triggers (you should use the trigger "None", which means you need to interact with it in order to talk with it). The Common Event dealing with the partner may include the option to deregister the partner (i.e. you can make them stop following the player by talking to them).
To remove a dependent event, use the following script command:
This uses the name or phrase which identifies that dependent event. Remember that you should both remove the event's dependency AND deregister the partner at the same time.
Dependent events across multiple maps
Where possible, you should restrict a dependent event to one map. There is a slight graphical error when crossing between two connecting maps which you may want to avoid. In addition, the animation for entering through doors wouldn't look right (only the player would do so, as normal, shutting the door in the dependent event's face).
If you do take a dependent event to a different map, you should have an event on that new map whose ID is the same as the event which became dependent. If you don't, ending a battle will cause the game to crash. This event can be blank or be used for anything else - it just needs to exist.
When a dependent event is removed and stops following the player, it is immediately erased. You will likely want them to remain where they are instead, which means you will need to add some commands to the Common Event which will place an event in the same place and facing the same direction.
- You can use dependent events for things other than partner trainers. For example, a famous feature of Pokémon Yellow was that the player's Pikachu followed them around.
- Dependent events can be quite tricky to get to work properly, though.