Script Commands Bug Fixes

[kyonides]

Why I Had to Update The Script

Ever since RMXP came out, scripters had to deal with the dreadful Interpreter#command_355 aka script call method bug that made the maker get frozen if there was a single line call that ever returned a false value, not a falsey value like nil as Zeriab reminded us in another thread, but a pure false value (FalseClass object).

For about 2 decades all scripters including your servitor had been dealing with the symptoms but NEVER the actual illness this bug was causing. To better understand the issue, I'll explain it here from the very beginning.

Several bug fixes dealt with the result variable's false value that would freeze the script call event command by changing the if statement or by making it irrelevant aka non existing at all like it was the case in my now old solution. And there was Zeriab's own answer to the issue that relied on a wait command of sorts to get out of that horrible loop.

So far they seemed to work as intended, even if some people claimed that some solutions didn't consider all possible caveats for any given reason.

You see guys, THAT was the ACTUAL PROBLEM!  Nobody was truly reading that piece of code properly! And when I say nobody, I truly mean it and I'm 100% certain that was the case here. Yeap, that nobody also included me, yours truly... until NOW!

This new version released on February 26th, 2025 finally dealt with the issue the way it should have been from the very beginning!

The problem was NEVER the if result == false conditional statement itself whenever you let it evaluate a single line of code.
Nope guys, that was the distraction that pesky  bug had prepared for us to survive another year!  Nasty little insect!

The actual issue was a lot simpler than that!

The command_355 method interrupted the @indes += 1 update the loop included if there was no other line of code included after the first one, that curiously has a different event command code that additional script call commands. THIS WAS THE REAL ISSUE!


Now my bug fix adds a @index += 1 fix under 1 single condition: to never find a secondary script call command right after the initial one (with a different event command code).

This means the following: RMXP no longer gets stuck there interpreting the same old script call event command forever and ever!  

"Why not?", people like Melana might ask at this point.

It's very simple indeed!  Now it can properly read the next event command, whatever that might be, because it successfully stopped testing the previous script call AS IT SHOULD HAVE BEEN the case from the very beginning.  It can't read a command that's already behind the current position due to the way the Interpreter was designed by the RM developers.

SPECIAL THANKS

I want to thank Zeriab  not for giving us just an old way to "fix" the bug (that also worked fine), because ALL of OUR OLD solutions were nothing but WORKAROUNDS as I have exposed that here, but mainly because of his persistance in dealing with the Ruby interpreter, not to be confused with RGSS Interpreter at all. Well yeah, we have extensively talked about the Interpreter class here for sure.

EDIT

I had to update the latest version of my bug fixes because the command_355 fix actually introduced a new bug. This means that I didn't notice that I misnamed the old_pos variable as old_post... I guess I got pranked by the fact I was talking about old posts or the autocorrection feature did it again and I failed to realize it in time. Yet, Wulfo already let me know about that bug and I gladly smashed it to smithereens already.