Script Commands Bug Fixes

[kyonides]

Why I Had to Update The Script Once Again

After receiving some  bug reports by someone  I won't mention here, I noticed something ELSE. Yes, that was NOT the end of the story, guys.
Fine, Melana.  Start complaining now  because you gotta keep  reading to find out what else has transpired in the maker world since my previous post.

What I told you before was half the truth of what had occurred to RMXP's Interpreter class.

SUMMARY

• The issue that made the RMXP engine get stuck after a script call event command was a real pain you know where.
  Both false and nil results, both considered falsey values, were the worst nightmare RMXP Interpreter class had ever experienced.
  
• if result == false conditional statement was not the true culprit.
  That was nothing but a goon, but the actual mastermind was in another castle, Mario!
  It just was a symptom of a bigger issue we had not detected before or preferred to ignore it altogether for undisclosed reasons.
  
• @index += 1 addition was mandatory for sure.
  Yet, the condition that made it relevant according to my previous post was WRONG. Thus, it had to be replaced by another one.
  
• The need for preparing the event for processing the next event command was real.
  Again, what was terribly wrong was the condition that would apply the fix where it was relevant.
  
• I had introduced another  bug because of ignoring the second point indeed.
  

THE ROOT CAUSE

It was located in the Interpreter class for sure but it was in the script section known as Interpreter 1. There you can find a method called update which is very important, especially true if you're an eventer. Yes, eventers depend on it 100% or else they'd lose control of the map forever and ever or till they finally kill the application.
There returning a false or nil value as the end result of execute_command event command became a terrible issue!
Yes, I know that this part of the explanation sounds rather old, yet, that's on purpose even if that's not the end of the story.

Why is it important?

You would understand the issue if you focus on this section of the update method:

Code:

if execute_command == false
  return
end

What you can read there created the issue, even if it was not supposed to. You see, there are other methods that return a false value on purpose!  What a mess!

After analyzing those other methods, I came up with 1 out of 2 simple conclusions.

1. They had something in common: they were disruptive by nature!

If you called another type of scene or a gameover or anything the like, the engine was supposed to halt the execution of the update command ASAP.

2. Script Call event command was ALSO supposed to be just as disruptive as the calls to other scenes if the end result was false.

Here I guess that the Script Call command was intended to be used as some sort of multi-line condition and not really as an evaluation of a whole script or an internal or external method call. The only "official" way to prevent this from ever happening was to return true at the end of our call.

Where did I get that?

If I had only purchased RMXP, I'd probably still ignore the real issue. Nonetheless, having legal access to RMVX and RMVX ACE widened my perspective quite a bit. IIRC, you won't find the exact same issue there, especially in VX ACE. For some reason I haven't studied so far, VX does have a problem with either false or nil values, but only one of them is a pain...

VX ACE actually changed the way the methods are executed, by not testing the result of evaluating the script, to prevent it from changing the event processing based on its interpretation of that old event command over and over again, freezing the maker permanently. OR ignoring the event commands that come after a script call with false or nil as its return values.

The Real Fix

This is the most excentric part of the whole story. It's a mix of the good old "change the value of the result local variable" approach PLUS my @index += 1 increase without ignoring the issues caused by nil. The thing is that I had to properly find the best place to change the @index without altering any other event commands. That perfect place is inside the very same condition that started it all: if result == false itself!