RETROACTIVE BATTLE EVENTS AND DATA-EXECUTING SUBSET SKILLS

Somebody asked me recently how to create a subset skill that is able to target monsters and run event code. In response I've written this tutorial earlier than planned, but I'm sure anybody who is using RPG Maker 2003's default battle system will find this useful.

* * * * * *

One of the largest issues with the default battle system is that skills targeting monsters cannot execute event code. For those willing to do a little extra work however, we can actually create a skill that targets a monster and then run a certain event right after it executes. The basis for the entire technique is to get the engine to recognize which skill is being used. Since we can't turn on any switches like a monster using a skill can, we have to look for something else that every skill has in common which RPG Maker can store as a value. The first thing that comes to mind is MP.

PROBLEM: Subset skills cannot be operated by a switch or execute event code.
GOAL: Exploit the order in which the default battle system receives commands to force a reaction from an action.

Lets say one of the party members has a skill called Fire 1 and we need to determine if it is used. If Fire 1 costs 5 MP then we can check to see if the player loses 5MP while taking their turn. This requires another workaround altogether that I call creating a retroactive battle event. The idea behind this is that we can exploit the order in which RPG Maker interprets information to find out the input of the player before and after one party member takes their turn. For the sake of checking if Fire 1 was used we would create something like this:

The event checks if a certain party member uses something from the skill command, then activates a switch. The way RPG Maker works however is that it assesses this information right before it actually executes the skill, which will mean we will be given the player's current MP right before Fire 1 was used. Immediately after this battle event runs, the game will execute the player's turn.

Here is where things get interesting: If Switch 1: Retroactive Event is the trigger condition for a battle event on a following page, it will execute whatever is on the next page before the player uses Fire 1. What if instead we have Switch 1 activate a battle event on a page before our current one? Interesting, because the game is looking for information on the following page it won't immediately realize that there is data waiting to be read in an earlier battle event. Create a new battle event page, but make sure it is a lower page number than our current battle event:


This battle event will be page 1 while the event we created before will be page 2. There is a reason for this. RPG Maker executes any battle event with a switch trigger immediately. So after the player uses Fire 1, the engine will realize it has a switch in a battle event that is waiting to be executed and through this exploit we can force a second page to be read immediately after the player uses fire 1. When the information in this new event is assessed, we can decisively determine what skill was used by comparing current data with older data that we recorded earlier.

First, we check the MP of the hero again, then we subtract the current MP from the MP in variable 1, which will return 5. 5 MP is the amount that it costs to use Fire 1, which allows us to conclude that the player used that exact spell. Now with this known, we can do whatever we want inside the fork, including getting a reaction out of certain monsters for using it. If you have a skill that requires the player not to attack however, you can actually add a high priority status condition that prohibits their movement for exactly one turn and then execute the information in the fork condition. This will allow you to have a skill that can target monsters and still act like a switch, all the while preventing the player from attacking.

Limitations:
-No skill in the same subset can cost the same amount of MP, or else you will be unable to conclusively determine which skill was used.
-If the player is affected by an MP draining status condition it can interfere with the calculations and return a bad result.

If you are able to work around these, then I think you will find retroactive battle events to be one of the greatest tools to assist you in transforming the default battle system into something more complex.





Battle events.

Without this, only commands(like Attack, Skill, etc) were able to trigger battle events. With this, every skill within every subset can have it's own unique code. So instead of having the "Scan" command take up a whole battle command, you can now just have it within a subset of other skills, allowing for tons more flexibility.

The possibilities are endless. Now you can have a whole subset of skills similar to say, Sabin's Blitz. Each skill could then have it's own key inputs.