Best Event Practices

I'm not sure if support is the right place for this question since I got the event working the way I want it to, but I'm curious about the best way to handle this event.

Basically, I have an NPC event blocking the opening of a cave. When the PC talks to the NPC and asks her to move she steps aside and lets the PC past. The goal is to keep the NPC in its new location after she has moved and allow her to give a small message to the PC if they talk to her again afterwords. 

As I mentioned, I did get this working (I'm trying to avoid scripts at this point since I'm still very new to the program) by flipping a global switch to indicate the movement and using a second parallel processing event as a sort of controller that looks for the movement switch and if its turned on uses the Set Event Location command to move the NPC. Then the controller event erases itself to stop it from continuing to run.

My question here is can this be handled by a single event without using scripts?

Since this event is really a local thing and has no larger consequences on the game world I'd prefer to keep everything internal to a single event, but when I tried setting a local switch and using a second event page to do this, I noticed I can't end the parallel process without erasing the entire event (making the NPC vanish). So I'm concerned doing similar events with more NPCs would start to lag the game because of the number of parallel processes running.

I know about Shaz's script to handle exactly this problem and I'm going to implement that in the future, but I'm asking because I'm curious about best practice. Is it better to use global switches and a controller to handle local events every time the map loads, or should I contain those events and leave the parallel process running?

Thanks for any advice!

I don't know about "best practice" but if I was attempting it and using the full version RM instead of the Lite(so no pesky 10 event per map limit) I would use 2 events rather than 1. Both with a second "Event Page" activated by the same switch. The first one(the NPC you talk to) would have the NPC sprite on the first page and the second page would be blank, the other would have the first page blank and the NPC sprite on the second page. The blank pages would have "Through" checked in the options.

The page 1 NPC would step aside onto the other event then trigger the switch making itself disappear while at the same time the page 2 NPC would appear. Effectively that would have it step aside and stay stepped aside even after the map was reloaded. As long as nothing turned that switch off anyway.

Not really by a single event.


The way I'd do it without scripts is to have two events - one in the original location, and one in the new location.


The one in the original location would have the NPC on the first page, the dialogue, the move route to step aside, and then turn on a switch. Then there'd be a second page conditioned by that switch with no other changes to the event page.


The second one would be in the new location and would have a single page, with the NPC (in the direction it should be facing after the other event's move route), any dialogue you want to have if you interact with the NPC again after it moves, and have that same switch as the condition.


What the player sees is talking to the NPC will cause them to say something and move to the side. Whenever they talk to them again they'll get different dialogue, and if they leave the map and come back they'll be standing where they were after moving. What's really happening is that the first event moves out of the way then deactivates itself and activates the second event at the same time.

If I didn't have a specific way of doing everything I would go with Shaz's suggestion.

Since I do have a specific way of doing everything, I'll just explain it here.

For every map in my game, I have a single autorun (or parallel process depending on the situation) event that begins whenever the player enters the map. Depending on the progress of the game so far, the event does different things.

Essentially this is what this single event normally does for my maps:

• Start a cutscene if necessary
• Change the BGM, BGS, tint the map if necessary.
• Depending on the progress of the game:place events where they should be
• Delete events that shouldn't be there
• Set transparencies, passabilities and graphic/sprite of events if applicable
• other advanced event changes

Other than the first point, the rest are done immediately upon entering the map. This works with an autorun because I transfer players without the fade. Instead, I use the "tint screen" command to tint the screen to black. Once I enter the map, this autorun tints the screen to white or whatever tint is necessary to achieve the fade-out and fade-in effect.

That allows me to run specific processes in between the fade effect, which go unnoticed by the player.

For your situation, I would do it as such:

The autorun event will have a specific command for your situation:

If Switch ## is ON, Set Event Location to (next to the door so they don't block it).

Talking to the NPC = Switch ## activates, the NPC moves out of the way.

So in this case: When you first enter the map, the NPC is blocking the door as normal. When you talk to the NPC, the NPC moves and turns on Switch ##. When you re-enter the map, the autorun (or parallel process) moves the NPC next to the door, along with anything else that may need to be moved/altered.

It sounds a little convoluted, but it gives me a very consistent workflow and I find it much more efficient to handle all of the pre-map work in-between the 'fade' effects with a single autorun/parallel process event.

PS: You can achieve the same thing without using the Tint Screen to replace the fade effect of the map transfer if you use Parallel Process instead of Autorun. Just remember that starting a cutscene with Parallel Process allows the player to move around, so you'd need to change the page to an autorun after all of the commands in the PP are finished.

Yes. LOVE parallel process events that "set up" the map then erase themselves. Just one per map.

That's pretty much the solution I had worked out when I was trying to figure out how to handle the event. I created a parallel process event that checks for the switch and uses Set Event Location if it is on. Everything else about that event is being handled by the NPC event. I tried autorun initially but I haven't looked into Tint Screen or other transition effects yet, so I was able to see her teleport after loading the map; that's when I switched it to parallel process. I haven't worked with cutscenes yet either (only so much you can learn in 3 days lol), so I'll make sure to remember about using autorun.

Since it doesn't sound like it can effectively be contained into a single event without scripting, I'm probably going to stick with this method for consistency and to keep from cluttering the map with extra events. My biggest concern was that parallel process or autorun event would get bogged down if it handled too many events and cause some difficulties with loading up the map, but based on your post that doesn't seem to be a problem or else it's covered during the Tint Screen.

I hope you don't mind if I follow in your footsteps with pre-map work seita... I was headed in that direction already, but you've clarified some of the other events that "controller" would handle.

I'm sure the process is more commonly used than it seems. I know Shaz uses it herself.

There is a way to keep everything into one event, but at that point it gets messy because you'd have to keep track of everything within different events. In most cases, having that extra single autorun/parallel process to run map-loading procedures is much cleaner and easier to work with.

In fact, I used it so much, that I wrote a script that would run the same parallel process common event on EVERY map, which had labels and jump to labels for the map id, so I didn't have to remember if I'd set up an event on each map, and didn't have to search around to find it (usually I put them all in the same place so I know where to look, but sometimes I don't)