PARALLEL + ACTION KEY EVENTS
A simple way to make a parallel map event act like a normal event.
- Wolfe
- 05/11/2012 01:14 AM
- 5067 views
As far as I can tell, RPG Maker 2000 doesn't have a built-in way to recognize when you attempt to "talk" to a parallel event. If you create two pages with the same conditions, one as a parallel process and the other triggered by the action key, the engine will only pick one or the other and stick with it.
But with a few variables and a switch, you can create an event that runs any parallel event code you like and still responds when the player "talks" to it.
You need two variables for the hero's XY position, two variables (per event) for the event's XY position, a variable for key input, and a switch. Start by recording the hero's position to variables (if you want you can have a different parallel event do this constantly), and record the event's position to a separate set of variables. Subtract the hero's variables from the corresponding event variables, and insert a key input check that only looks for the action key (5) and doesn't wait for the key to be pressed.
Then create a series of branch conditions that checks to see if the hero is near the event (see below). If so, activate your switch. Here's how it looks. I've included a little something as an example. We'll get to it later:
On the second page, set the event display conditions to "Switch 0001:NPC Action Key is ON," and set the trigger to "Action Key." Put in the message you want to appear when the player talks to the event, or whatever else you want to happen. For movement, set the frequency to eight, and have the event wait, then turn off your "action key" switch.
If you copy this exactly, you can have an NPC that walks around, counting up every time the parallel event cycles. Each time you talk to him, you can see how many times he's cycled, proving the parallel process is running.
If you want your parallel process code to take priority over the ability to "talk," place it above the stuff on the first page. If you want the ability to "talk" to take priority, place it below.
Now you can have a fancy NPC that does whatever you want while still responding to the player! Or anything else you can come up with...
NOTE: If your "display message" settings include "allow events to move freely," a message window won't stop the event from resuming its parallel process behavior. You'll need to give each event its own "action key" switch.
This should work in RPG Maker 2003 also, but I don't have the program handy to test it.
But with a few variables and a switch, you can create an event that runs any parallel event code you like and still responds when the player "talks" to it.
You need two variables for the hero's XY position, two variables (per event) for the event's XY position, a variable for key input, and a switch. Start by recording the hero's position to variables (if you want you can have a different parallel event do this constantly), and record the event's position to a separate set of variables. Subtract the hero's variables from the corresponding event variables, and insert a key input check that only looks for the action key (5) and doesn't wait for the key to be pressed.
Then create a series of branch conditions that checks to see if the hero is near the event (see below). If so, activate your switch. Here's how it looks. I've included a little something as an example. We'll get to it later:
PAGE 1 -- Parallel Process
--------------------------
<>Change Var.: [0001:Hero X] = Hero, X-Pos.
<>Change Var.: [0002:Hero Y] = Hero, Y-Pos.
<>Change Var.: [0003:NPC X] = This Event, X-Pos.
<>Change Var.: [0004:NPC Y] = This Event, Y-Pos.
<>Change Var.: [0003:NPC X] - Variable [0001]
<>Change Var.: [0004:NPC Y] - Variable [0002]
<>Check Key Input: [0005:Key Input]
<>Branch: IF Var.[0005:Key Input] is 5 =
<>Branch: IF Var.[0003:NPC X] is -1 >=
<>Branch: IF Var.[0003:NPC X] is 1 <=
<>Branch: IF Var.[0004:NPC Y] is -1 >=
<>Branch: IF Var.[0004:NPC Y] is 1 <=
<>Change Switch: [0001:NPC Action Key] = ON
<>
END
<>
END
<>
END
<>
END
<>
END
<>Branch: IF Var.[0099:Example] is 999999 !=
<>Change Var.: [0099:Example] + 1
<>
END
<>
On the second page, set the event display conditions to "Switch 0001:NPC Action Key is ON," and set the trigger to "Action Key." Put in the message you want to appear when the player talks to the event, or whatever else you want to happen. For movement, set the frequency to eight, and have the event wait, then turn off your "action key" switch.
PAGE 2 -- Action Key, if Switch [0001:NPC Action Key] is ON
----------------------------------------------------------------
<>Branch: IF Var.[0099] is 999999 !=
<>Message: Hello! I'm counting to one million!
: : So far I've gotten to \v[99].
<>
: ELSE Case
<>Message: Hello! I just counted to one million!
<>
END
<>
----------------------------
Custom Movement, Frequency 8
<>Wait
<>Switch [0001] OFF
----------------------------
If you copy this exactly, you can have an NPC that walks around, counting up every time the parallel event cycles. Each time you talk to him, you can see how many times he's cycled, proving the parallel process is running.
If you want your parallel process code to take priority over the ability to "talk," place it above the stuff on the first page. If you want the ability to "talk" to take priority, place it below.
Now you can have a fancy NPC that does whatever you want while still responding to the player! Or anything else you can come up with...
NOTE: If your "display message" settings include "allow events to move freely," a message window won't stop the event from resuming its parallel process behavior. You'll need to give each event its own "action key" switch.
This should work in RPG Maker 2003 also, but I don't have the program handy to test it.
Posts
Pages:
1
seems like a lot of work to not just create two separate events.
EVENT 1 The event you can talk to
EVENT 2 an invisible event off in the corner somewhere that controls the parallel process.
EVENT 1 The event you can talk to
EVENT 2 an invisible event off in the corner somewhere that controls the parallel process.
It can be more difficult to control the movement of a particular event from another event, though. If movement commands are localized then you can duplicate the event without much modification. I designed this while working with a parallel event that already tracks its own XY position and has a bit of pathfinding code to decide where to walk.
For other cases, a master parallel event is often the way to go, yeah.
For other cases, a master parallel event is often the way to go, yeah.
Pages:
1