Error: Common event calls exceeded the limit

[FleshToDust]

When I move the arrow key it selects a zone which loads a common event. When I move the arrow key back it loads another one in a menu. There is a limit to how many common events you can load in a row. Is there any way to get passed this limit?
Ex: exiting all common events and then restarting the limit somehow?

 

[Andar]

exceeding the limit means that you made a wrong logic iteration. You cannot increase the limit but it is high enough that no intelligent logic structure should ever approach it.

please show us the event code that you created, and tell us what it is supposed to do, then we can tell you how to improve your logic structure.

 

[FleshToDust]

This thread by @Zeriab says there's a 100 common event limit.
https://forums.rpgmakerweb.com/index.php?threads/common-events.5129/
That would mean if you make a menu with two options you can only choose between them 100 times before you get an error.

 

[TheoAllen]

Right. Based on these codes

Game_Interpreter.prototype.command117 = function() {
  var commonEvent = $dataCommonEvents[this._params[0]];
  if (commonEvent) {
    var eventId = this.isOnCurrentMap() ? this._eventId : 0;
    this.setupChild(commonEvent.list, eventId);
  }
  return true;
};

Game_Interpreter.prototype.setupChild = function(list, eventId) {
  this._childInterpreter = new Game_Interpreter(this._depth + 1);
  this._childInterpreter.setup(list, eventId);
};

Every time you call a common event, it adds stacking events. A common event is not like a goto label. It's actually stacking a different instance of interpreter whenever you call a common event. Even worse if the common event itself is never terminated.

 

[FleshToDust]

After switching from common event 1 to common event 2 it doesn't exit the first common event? Is there a way I can exit it so it doesn't keep increasing the size of the stack? In the article I referenced it mentions this:

-------------------------------
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)
-------------------------------
What exactly does the bolded part mean? It suggests another way of designing it but I don't understand what it means.

 

[TheoAllen]

After switching from common event 1 to common event two it doesn't exit the first common event? Is there a way I can exit it so it doesn't keep increasing the size of the stack?

You've been asked to show how you did your eventing, so everyone can take a look.

I'm not fond of making menu through a common event, so I can't help you with that part.

 

[FleshToDust]

I can't go through the whole thing as it's far too long but I can give an example of how it's structured.
The first event is "MainPhase" and the second event is "MainPhaseHandZone5".

 

[gstv87]

can you sketch out how the thing should flow, schematically, in generic terms?



if you can't, find a way.
if you can,..... just follow your design!

 

[Aloe Guvner]

Your event "MainPhase" calls the event "MainPhaseHandZone5"
Your event "MainPhaseHandZone5" calls the event "MainPhase"

You have an infinite loop, so it will definitely exceed the limit of calls.

 

[FleshToDust]

@gstv87
It basically goes
CommonEventDrawPhase>CommonEventMainPhase

During the main phase there's a pointer on the screen. If you move the pointer between the cards in your hand it loads a different common event depending which zone you moved to.

RightArrowKeyPressed>HandZone1

HandZone1 will then use if statements to check what the zone contains and then if there's a card there it'll give you a choice to either
Play or Back.

Clicking Play will change some variables and put a card on screen and then move to CommonEventMainPhase.
From there you can push ArrowKeyUp and if you do it will load CommonEventSkillZone and give you and option to Activate or Back.
Clicking Activate will change some variables and then go back to CommonEventMainPhase. Clicking Back will do the same.
You can then play another card and do the same thing until you're finished. Once you're finished you can enter the Battle Phase or the End Phase. They each have their own common event also. Then it's the opponents turn and the opponent has similar common events they go through before it is your turn again. This continues until the battle is over or you reach the 100 event limit.

@Aloe Guvner Is there any way to switch between the common events without exceeding the limit?

Going to bed now but will check back in the morning.

 

[Aloe Guvner]

If you're absolutely sure that you're not causing an infinite loop, then you could just increase the limit of the depth of common events.

Game_Interpreter.prototype.checkOverflow = function() {
    if (this._depth >= 100) {
        throw new Error('Common event calls exceeded the limit');
    }
};

But the best solution is definitely what @gstv87 recommended, create a diagram to understand your normal flow. If a common event calls another common event, the depth is 2. If that common event then calls another common event, the depth is 3. Based on your flow diagram is it normal for your depth to be 100? Using your flow diagram, is there any way to adjust your flow to reduce the depth?

 

[gstv87]

If you move the pointer between the cards in your hand it loads a different common event depending which zone you moved to.

if you're processing the event of entering a zone where an event processing is required, then you're not processing the event of being not-in-a-zone-where-an-event-processing-is-required.

 

[Parallax Panda]

Is this only a problem with common events? What about normal events placed on a specific map, would that work instead?

Obviously it is an "infinite loop" since it's an evented card game where everything needs to go on until someone looses the game. Unless there's a way to restart the stack without breaking the flow of the card game isn't it unavoidable to have an infinite loop of common events?

...unless everything is evented in one single parallel event but I imagine that would be problematic for other reasons.

 

[Andar]

Clicking Activate will change some variables and then go back to CommonEventMainPhase. Clicking Back will do the same.

That is where you are wrong and where you created the infinite loop that needs to be removed.

"Call common event main phase" does NOT go back to the main phase, it calls a new subevent with a new main phase, stacking the main phase against the limit again and again.

Whereever you are in a submenu and have a call to the main phase there, you need to replace that call with an "exit event processing" to go back to the previously called main phase instead of calling a new subroutine.
However, in that case the main phase needs to be able to reclaim logic when the focus returns to it - so far you only restart the mainphase from the top by calling it again and again. It needs to loop instead.

If your logic is correct, the "call common event main phase" is used exactly once in your entire game project - at the moment when you want to start the menu and then never again.
EDIT: To clarify the sentence above, I just realised that it could be read wrong:
Your current logic is wrong. If you correct the logic into what it should be, then the command to call the main phase common event should only be used once in the entire game project, at the place where the menu is started. It should never be used inside any event of the menu itself, especially never be used in any subevent.

 

[FleshToDust]

I tested out the exit event processing on a test event to see what happened.

Event:
Text: Common Event Call Test.
Common Event: Test1

Test1:
ShowChoices: Move to Test2.
When Move to Test2.
Common Event: Test2

Test2:
ShowChoices: Move to Test1.
When Move to Test1.
Common Event: Test1
----------------------------------------
Testing that event and clicking 100 times gives the error.
After changing the common events to include exit event processing it then looks like this:

Event:
Text: Common Event Call Test.
Common Event: Test1

Test1:
ShowChoices: Move to Test2.
When Move to Test2.
Common Event: Test2

Test2:
ShowChoices: Move to Test1.
When Move to Test1.
Exit Event Processing
----------------------------------------
The problem I have is it exits all events and I'm returned to the map screen when I'd like to just return to the common event Test1.
How do I use Exit Event Processing so that it doesn't exit all events but returns me to Test1?

 

[Andar]

The problem I have is it exits all events and I'm returned to the map screen when I'd like to just return to the common event Test1.
How do I use Exit Event Processing so that it doesn't exit all events but returns me to Test1?

I already told you in the previous post that exit event processing only works if the event that it goes back to is written in a way that it can handle an event coming back.
And that is another reason why we ask for screenshots instead of a writing of the contents of an event like you did here.
The contents are only half of the event, the properties are the other half.
And it is the properties and more specifically the trigger that handles this - so what triggers do you have on your events?
You need a parallel process for a menu - no way around that. but the parallel process needs to be at the correct logic point or you get everything either lagging or crashing.

 

[FleshToDust]

@Andar
I couldn't put photos up as it's too long but I've made a video. The first half is the event running and the second half are the common events themselves showing how it goes from one to another. Hopefully this is adequate.

[Video removed as problem seems to be fixed]

 

[Andar]

that video is absolutely useless.

OK, let's try the other way around.

You need one main selection event. That event needs to show all the options where to go to, where the player make its choice.
That menu needs to be on parallel process, and it can call the other options like test1, test2, test3 and so on.
The single events that handle those choices can do whatever they want, but they need to go back to the main parallel.
You must NEVER call test2 from test1, the logic always has to go back to main first.

Because if you call test1 from test2 and back, then you get the buffer overflow that causes your problem.

Every post above is to get you to show what the logic is from your main loop, the loop that you have to get to in order to prevent the overflow - and all you give us is the logic that simply calls deeper and deeper without going back.
That you get back to the map as soon as you place the first exist event processing is proof that your main event is not a parallel process and can't handle the return - because the exit event processing only takes you back one step, and if you're get back to the top immediately after that one step back means that your main event is not a parallel but terminates itself whenever you go back.

Showing us the deeper levels of your events does nothing - we need to see your top level event, and that should be only a single screenshot.

 

[FleshToDust]

I did show the top event. I showed every event that it goes through. First was the npc deck selection event where you choose who to fight against. That was the first one. Next is the npc setup phase where their cards are drawn. Then the player setup phase where the players side of the field is drawn. Then is the standby phase, the draw phase, main phase setup, main phase, battle phase and finally the end phase. I also showed the parallel event that shows the images on screen. What left is there to show?

Going back to the simple example if I make Test1 a parallel process and then call Test2 and from Test2 Exit Event Processing will Test1 still show?
What I'm getting from your comment is that I have to make a parallel event that controls the phases and loads the other common events and when they exit the parallel event should detect which phase is next and load that one and when it finishes it goes back to the parallel.

EDIT
------------------------------------------------------------------------------------------------
Alright I think I've got it. Here is my event process:

Event:
Text: Common Event Call Test.
Control Switches: ParallelEventTest = ON

Parallel Event:
Page1: Empty
Page2: Conditions: ParallelEventTest = ON | Show Choices: Main Phase | End Phase
When Main Phase: Common Event: MainPhaseTest
When End Phase: Common Event: EndPhaseTest

MainPhaseTest:
Show Choices: Main Phase Select
When Main Phase Select
Exit Event Processing

EndPhaseTest:
Show Choices: End Phase Select
When End Phase Select
Exit Event Processing
------------------------------------------------------------------------------------------------
I clicked it about 300 times and haven't gotten the error.
If anyone knows if this is the correct way of doing it, please let me know.

 

[Andar]

basically yes, but there might be modifications depending on what you actually want to do with it.