Thoughts on the Interpreter's Script Command

[DerVVulfman]

What are you talking about now? I mean, be specific because it sounds strange. PM or discord preferred here.

EDIT 1

I don't seen any custom variable misnamed nor misspelled at all in both Version 4 and 5.

EDIT 2

At this point it seems clear to me that you failed to mention that you were talking about OLD errors the published script had. That I can easily understand.

That error spoken of was the three hour repeat-fest on the 26th (Wednesday) whereby I was asked to test this version of the 'command_355' method in Kyonides' Interpreter Fix:

  def command_355
    old_pos = @index
    # Set first line to script
    script = @list[@index].parameters[0] + "\n"
    # Loop
    loop do
      # If next event command is second line of script or after
      if @list[@index+1].code == 655
        # Add second line or after to script
        script += @list[@index+1].parameters[0] + "\n"
      # If event command is not second line or after
      else
        # Abort loop
        break
      end
      # Advance index
      @index += 1
    end
    # NEW: Single Line Script Call Bug Fix
    # That call failed because devs forgot to increase the @index variable
    @index += 1 if @index == old_post
    # Evaluation
    result = eval(script)
    # Removed Several Lines Here Before Continue
    return true
  end

Highlighted in yellow, there is the offending variable that was incorrectly entered, meant to be old_pos instead.  And the error I kept sending and mentioning was this:

There was no way it could have succeeded in any betatest as it was.

[kyonides]

At least you now mentioned it was on February 26th. Now I'm in need to add something here to make things clear.
The last 2 versions of the bug fixes where added to the post a day later, the 27th, after I read another of Zeriab's replies.

I dunno why you had to post the old snippet, but oh well, it's you being the same old  Wulfo.

Something I must emphasize about Version #4 and #5 is that #5 is pretty much a relaunch of #1, and that would not have happened if #4 had no visual glitch. What glitch am I talking about here? Well, when there's a message window and then comes a script that returns a false value and it's followed by another message window, you can easily notice how the window disappears before reappearing in no time. Version #5 doesn't go through that at all.

The reason why I started working on Version #2, IIRC, and beyond was that several comments posted on this thread made me think that I might consider keeping the command_355's result value check and returning that no matter what kind of value that might be. By the time it hit the #4 it seemed to be working until the report came telling me about the visual glitch.

Curiously, the end result of all these test is that RMXP works in a extremely disruptive way that its game devs preferred to ditch starting from VX or VX ACE. Version #5 reflects the behavior present in VX ACE, where the result simply gets ignored because it just keeps processing the event commands without hesitation. Version #5 evaluates the script data but always returns a true value. That HAS to happen this way because it won't interrupt the processing by returning either false or nil as in past iterations.

Sometimes what looks like the most promising response to a certain event is not the best answer at all.

Should people use that version? Or anybody else's solution?
That's for you as the user to find out.