Common Events

Common Events
Note: This is aimed at intermediate eventers

Common events are pretty much like map events with change that they are made common to all maps and don't have pages. (Or exactly one page)
I will discuss various issues of common events though first take a look at this common event and map event:

What happens when you trigger the map event?
What would happen if you change the common event's trigger to Parallel instead of Autorun and then trigger the map event?
What happens if you call the common event from a battle event?
Basically, how does self-switches work in common events with the added question about order of execution.

The call stack
Self-switches
The common events themselves do not have self-switches attached to them, but you can still use the self-switch functionality. It works in a different way.
To help understand how self-switches work in common events I will introduce the concept of a Call Stack. Whenever you use the Call Common Event... event command you place the common event on the Call Stack.
I want you to imagine the situation just as if you had a stack of papers. Each time you call a common event you place a paper on top of the stack. Whenever you have processed the top paper (top common event) you remove it from the stack and look at the paper which is now on top. (The event which called the common event).

All except the bottom event (the first called event) are common events because only common events can be called. The bottom event can be a map event, battle event or a common event.
The bottom event is the important event when considering self-switches since the Control Self Switch... command only makes any difference if the bottom event is a map event. If the bottom event is a map event then the self-switches changed will be the map event's self-switches. Likewise is the self-switches of the map event considered in conditional branches.
You can have several map events call the same common event. When each map event is interpreted it is used for considering self switches.

Here is an example of a chest (2 pages) and a common event:


Set move route
As you can see I have used a Set Move Route... command which works similarly to Control Self Switches....
If you select This Event as the event to use it will only work if the bottom event of the Call Stack is a map event.
The map event is the one moved just like how the self switches of the map event were considered in the common event.
If the Player or a specific event was chosen then it will work on the map, but not in the battle.
Note that when choosing a specific event the id is considered. If you call the event on a different map it will try to use the event with the same id on the different map.
Note also that you can only pick among the events on the map you look at (or lasted looked at). You may therefore need to choose a different map before you can pick the event you want.

Code reuse
After having made the event above you can just copy and paste the chests to get chests that you can only open once.
If you change the common event you will change the functionality of all the chests. A problem which I am sure you have realized is that all the chests currently contain the same thing, 50 gold.
You may however want the chests in the same way, so what do you do? You can place part of the functionality which is common for the chests in the common event and the item you get plus the message in the chest. If you want to alter the timing of the chest opening later then you can just change it in one place, the common event. Same if you want to change the sound.
This does NOT mean that it is necessarily a good idea to share functionality. You have to evaluate the need on a case-by-case situation and sometimes a solution which is preferable in one situation or game is not preferable in another situation or game.

Code reuse typically increases complexity initially although it may turn out later to increase the productivity. On the other hand it may turn out to decrease the productivity.
Take a look at this event demo: http://zeriab.plesk3.freepgs.com/root/events/Doors.rar
It is a door system where the player can pick the preferred functionality of the doors, or at least the standard doors.
Is it ridiculous? Has too many common events and effort been spent on the doors? Is it even worth it? Is it too little?
It is case-dependent. It most cases probably a little too much, but then again, maybe not. Maybe the player will like being able to speed up transitions after a while. It may just add an extra touch.
I do hope you see what I am getting at.
There is of course much more to be discussed about code reuse but it will leave that to another tutorial.

"Common event call has exceeded maximum limit."
You get this error when there are too many events on the call stack. There is a fixed limit of at most 100 events on top of the bottom event. If you try an additional call common event you get the error.
You can alter this limit with a simple edit to the Interpreter script. Note that the amount of calls is limited by the system stack as well. With a simple event which called itself I got to make 491 calls before getting a SystemStackError. Do not make the mistake of thinking you can use up to 491 calls since some event commands can easily need more calls and with the alias style in many scripts you can also easily use more calls there.

I can't imagine a situation where this will be a problem anyway except for badly designed events. You can consider the situation where you have one common event calling another common event which in turn calls the first common event. There, you have a cycle. This error should definitely be discovered, but you can have designs where it may not necessarily be discovered.
Consider an evented menu where you have a common event for each menu item. The menu is shown as well. If you move up or down you call the common event corresponding to the new menu item and then just prepare for that event to exit afterwards. When you have gone up and down more than 100 times you get the error. It is definitely possible that you won't test for this.

How should it have been designed instead? One solution could be to introduce a common event which launches the common events for each menu item corresponding to a variable. Each of the common events will exchange the explicit calls to other menu common events with an implicit call by changing the variable and then exiting. The launcher common event will then call the common event.
We now have a structure which should not continuously increase the size of the stack. (The amount of papers in it)

Exercises
These exercises are totally optional. You can use them to get a feeling of what I am talking about and for getting some experience.

Exercise 1
The first exercise is about answering the questions answered at the very top about the Mysterious person.
Try to guess what messages will be shown when the common event trigger is on Autorun.
Try to guess what messages will be shown when the common event trigger is on Parallel.
Try to guess what messages will be shown if a battle event calls the common event. (Common event triggers won't work in battles)

I suggest you write it down and then use RMXP to check it the answers. Be sure to enter the events exactly as shown here.

Exercise 2
This exercise revolves around making a chest system you are satisfied with.
Try to make it easy to copy while still being easy to modify. This is about making your game quicker.
You can additionally consider storing how many chests have been opened for stats fanatics. (Believe me; if you get an idea like this far into the project you will be VERY pleased if all the chests use a common event)

Exercise 3
Everybody loves puzzles.(Untrue statement)
Therefore this exercise is about making a puzzle or at least some building stones for puzzles.
The idea behind the puzzle is to get from point A to point B. There are some objects in the way with which you can interact.
Here is a list of the building blocks:

• A boulder which you can push forward
• A boulder which keeps sliding forward until it hits something or you push it another way
• A boulder which you only can pull backwards
• A boulder which you can both push and pull
• A boulder which you also can drag sideways
• Anything else you can imagine

Try to create nice scalable solutions. Hopefully boulders you can just copy and paste.
I won't promise that all of these types of boulders are feasible to create nice and scalable. It is up to you to find out.
Good luck.

Final notes
While this is very tutorial like I want discussions. Hopefully insightful discussion about beneficial common event use.
I realize that I have only scratched the surface here. I haven't talked about scalability yet. I feel that it is a bit too much in an intermediate eventing tutorial.
I will be happy to hear any suggestions on how to improve this tutorial.
I want to thank everyone who takes time off for reading my tutorial and everyone who replies.
I hope you will become wiser in your eventing decisions.

*hugs*
- Zeriab

Nice tutorial zeriab, i'm sure this helps allot of people, it also saves allot of time

Very useful. I found out some new stuff by this tutorial

I am glad you learned something from my tutorial
(That was the purpose after all >_>)

*hugs*