Thoughts on the Interpreter's Script Command

[Zeriab]

The conditional branch script command requires the result to specifically be either true or false. Try putting in a number like 12 and you'll see the conditional branch being skipped as well.
Expanding it to work with truthy and falsey values is a good idea ^^

Not a fan of your command_355 fix. Being able to run a script call every frame while it returns a special value can be useful.
Here's a version I did where you can let your script call return :wait to run it again. 

Code:

class Interpreter
  SCRIPT_WAIT_RESULTS = [:wait, FalseClass]
  #--------------------------------------------------------------------------
  # * Script
  #--------------------------------------------------------------------------
  def command_355
    # Set first line to script
    script = @list[@index].parameters[0] + "\n"
    # Store index in case we need to wait.
    current_index = @index
    # 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
    # Evaluation
    result = eval(script)
    # If return value is false
    if SCRIPT_WAIT_RESULTS.include?(result)
      # Set index back (If multi-line script call)
      @index = current_index
      # End and wait
      return false
    end
    # Continue
    return true
  end
end

*hugs*
 - Zeriab

[kyonides]

The conditional branch script command requires the result to specifically be either true or false. Try putting in a number like 12 and you'll see the conditional branch being skipped as well.
Expanding it to work with truthy and falsey values is a good idea ^^

Well, I run a test to see what happens if you simply pass a number to a custom method like the following:

Code:

class Interpreter
  def is_true?(var)
    var
  end
end

It doesn't alter the value by default but just returns the argument immediately as you can see above.

Result: true
As people might already know, numbers and many other objects are treated as true by default.

My fix takes anything you might have put as a script condition and negates it twice. Thus, if it was a number, any non NilClass object or a TrueClass one, it will always be true. This means it does respect the need to evaluate to true or false. All nil's would become false and stop being ignored by the conditional branch. Great, don't you think?

Regarding the command_355 stuff, I do understand your desire to add the waiting time but I don't share it. My variant is inspired by VX ACE where any result of the script event command evaluation does NOT become an integral part of the interpretation mechanism. Meaning that it won't stop executing it just because it returned a falsey value like it does in XP.

Anyway, I'd need to get access to a few edge cases where I can clearly see the need to use another version or fix it some other way before I would dare to modify it or replace it.

[Zeriab]

The conditional branch script command requires the result to specifically be either true or false. Try putting in a number like 12 and you'll see the conditional branch being skipped as well.
Expanding it to work with truthy and falsey values is a good idea ^^

Well, I run a test to see what happens if you simply pass a number to a custom method like the following:

Code:

class Interpreter
  def is_true?(var)
    var
  end
end

It doesn't alter the value by default but just returns the argument immediately as you can see above.

Result: true
As people might already know, numbers and many other objects are treated as true by default.

My fix takes anything you might have put as a script condition and negates it twice. Thus, if it was a number, any non NilClass object or a TrueClass one, it will always be true. This means it does respect the need to evaluate to true or false. All nil's would become false and stop being ignored by the conditional branch. Great, don't you think?

That code's all fine and dandy, but that's doesn't represent what the default code does. For that the code got to look something like this:

Code:

class Interpreter
  def is_true?(var)
    var == true
  end
  def is_false?(var)
    var == false
  end
end

I agree that your change is a good one. Skipping the branch completely when the script call returns something other than true or false is weird.
As you said, double negation will turn a truthy value into true and a falsey value into false. It's a fine way of doing things ^^

Regarding the command_355 stuff, I do understand your desire to add the waiting time but I don't share it. My variant is inspired by VX ACE where any result of the script event command evaluation does NOT become an integral part of the interpretation mechanism. Meaning that it won't stop executing it just because it returned a falsey value like it does in XP.

Anyway, I'd need to get access to a few edge cases where I can clearly see the need to use another version or fix it some other way before I would dare to modify it or replace it.

Looks like I did it to get a less risky version of waiting for movements completion: https://save-point.org/thread-874.html
Having a new dedicated command would be better, but only Unite supports editing the editor

*hugs*

[kyonides]

Curiously, I can't stop wondering why are you so fixated on this topic.  Not intending to sound harsh at all.
At the same time, I'm not saying this can't be a good topic for further discussion somewhere else.  (Like a development discussion thread.)

And honestly, I don't think I'll change it in the near or distant future as far as I can see now.

YET, I want to add one final thing that I've missed so far. In Ruby simply returning a variable's or constant's value is also a valid test, just as good as var == true or var == false or even !var .

Let's say I created an array like @triggered and it should return a given value based on the index we're providing.
Even if that specific position holds no value as of now, like index #100, nil as a default value should be treated as a falsey value based on Ruby's treatment of NilClass objects. Nonetheless, that's NOT what happens normally.

Yeah, people can add a bang! or two or use the equality operator, but that should not be mandatory in Ruby.

If you already have access to the array or variable, you shouldn't be in need of an additional method just for testing purposes. Not for a single value. I think it's different if that method would test other values one after another via operators like and, or, && and ||, of course.

EDIT

Now that this is being discussed on the Development Discussion subforum, let's beat up each other's muzzles!  Let's get ready for rumble!  
 OK, I'm speaking figuratively here. Nobody would like to find some flame war-like posts here.

[Zeriab]

Curiously, I can't stop wondering why are you so fixated on this topic.  Not intending to sound harsh at all.

DerVVulfman sent me a PM on this subject which I just discovered today. That + it being a fun excuse to dig into the Ruby interpreter code 

Also,

Q: Has anybody else posted anything like this before?

Me finding a post I made here 15 years ago about this topic answers this 

As per definition and implementations a falsey object in Ruby is either false or nil. A truthy value is any value that is neither false nor nil.
Note: false is a falsey value. false is equal to false. nil is a falsey value. nil is not equal to false.

(...)
Regarding the command_355 stuff, I do understand your desire to add the waiting time but I don't share it. My variant is inspired by VX ACE where any result of the script event command evaluation does NOT become an integral part of the interpretation mechanism. Meaning that it won't stop executing it just because it returned a falsey value like it does in XP.

Incorrect. It must specifically be false and the script call must not contain multiple lines.
You can verify this theory by starting a fresh new RMXP project and running these event commands and see both will show Hello followed by World!
         

Try running a single script line with false and the World! text will never be displayed.
   

YET, I want to add one final thing that I've missed so far. In Ruby simply returning a variable's or constant's value is also a valid test, just as good as var == true or var == false or even !var .

var == true, var == false and !var all evaluates to either true or false.
Returning the value returns the value. Maybe it's used later in a test, maybe not. Doesn't matter from the perspective of statement

RMXP Devs having multiple bugfix options doesn't sounds like a bad deal ^^
*hugs*
 - Zeriab

[kyonides]

 It sounds curious that  Wulfo wanted you to learn about that thread of mine or remind you of your 15-year-old thread.

Note: false is a falsey value. false is equal to false. nil is a falsey value. nil is not equal to false.

 Yeah, I know that. I hope other people do as well.

Yet, I'd call nil something more complex than a non existing object (actually an uninitialized object) or a falsey value. It also means it's not truly undefined. You see, internally nil or better known there as RUBY_Qnil is a runtime replacement for undefined value, usually only true if there's a zombie CRuby object still floating around, IIRC. Yet, it seems that there are times where a bug could rise because the object is undefined already, and there are some internal checks to prevent that from taking place in most cases.

And for people interested in the C part of the Ruby engine, you gotta know that RUBY_Qtrue and RUBY_Qfalse not only exist but are NOT equal to C and C++ true and false values. Not even to 1 and 0, respectively!

That's why Ruby tests that take 0 as a truthy value might easily enrage the C and C++ fans.

In regard to returning the same value, it could be used as a replacement for an actual test for a given child class that doesn't care about testing a value as long as it has been set to anything other than a falsey value. But yeah, defining a true as return value for a question? method is the preferred way to solve it in RMVX ACE, for instance.

OK, I opened the maker to check what happened to the single line and multi-line script calls, and yes, I gotta admit that false won't be an issue in multi-line scripts.

The thing is that I was fed up with the maker getting frozen because of stuff like:

@test_var = nil

And then testing it later on like in the example below:

@test_var == true

...as a single line script call.

And thanks for motivating me to keep testing the Interpreter#command_355 method because I ended up finding yet another way to fix it without even dealing with the result == false issue!  I'll post it in my bugfix thread in no time!

The New Fix, It's SO Incredibly \"Stupid\" That I Can't Believe Nobody Thought About It Till Now!

It had to be removed because there was a whole story behind the actual issue as exposed in the Script Commands Bug Fixes thread.

[Zeriab]

Good job on the new fix!

Yes, Ruby really follows through on the everything-is-an-object mentality. You can even be naughty and add methods to nil

Code:

def nil.method_missing(method, *args, &block)
  # hiding the error
end

I bet you are right about 0 being truthy is hard on poor C and C++ fans 


Wulfo did a refactor of my code which he shared with me. 
It's not mine to share, but I can share my own refactor:

Code:

class Interpreter
  # * Script Event Command * #
  # Just a small variant of a very old bug fix published by several people
  def command_355
    # Set first line to script
    script = @list[@index].parameters[0] + "\n"
    # Store index in case we need to wait
    working_index = @index
    # Loop
    loop do
      # Subsequence script call event commands have code 655
      # Stop looping once we hit a different command
      break if @list[working_index].code != 655
      # Add script line
      script += @list[working_index].parameters[0] + "\n"
      # Advance to next event command
      working_index += 1
    end
    # Evaluate
    result = eval(script)
    if result == :wait
      # Wait and repeat next frame
      return false
    else
      # Continue processing event commands
      @index = working_index
      return true
    end
  end
end

This is still a version that allows waiting. Here I prefer not modifying the @index until we are sure we need to.

I tested both your and my version with the 3 hello world examples in my previous post. The text window disappears shortly before reappearing for the versions that evalues to false. This doesn't happen otherwise.
Hmm... What do you think about this code? It preserves the same behavior of that specific example:

Code:

class Interpreter
  def command_355
    # Set first line to script
    script = @list[@index].parameters[0] + "\n"
    # Loop
    loop do
      # Subsequent script call event commands have code 655
      break if @list[@index + 1].code != 655
      # Advance index
      @index += 1
      script += @list[@index].parameters[0] + "\n"
    end
    # Evaluation
    result = eval(script)
    # Continue
    return true
  end
end

*hugs*

[kyonides]

I bet you are right about 0 being truthy is hard on poor C and C++ fans

As long as they don't hate me for telling them the saddening Ruby truth of OOP...

Yeah, now that I think about what happened with the message window, there might have been a minimal visual glitch that lasted for some split second. I guess in HiddenChest it'd have not taken place for it's able to run on 60 fps as a minimum.  But I said on my script thread, it might have been caused by taking the RM engine by surprise because it wanted to abruptly end the script execution right after returning the false value.

That last code you've posted here reminds me what I was trying in my first version of the code. Just as it happens in VX ACE, where the result doesn't matter at all because it's not supposed to ever halt the execution, you can't find any conditional statement expecting any event command to return false.

One of the practical reasons those guys have applied there, as far as I can see right now, could have been that by not knowing beforehand what command code the event command would return as its ID, it was preferable to skip the whole "return true or false" enchilada altogether.  You know, I can't blame them for that!

Believe me, I went back to my test project and tested both codes, your latest one and Version 1 of Script Command Bug Fixes and now you can pick any of them and make sure you won't get the nasty message window glitch at all.  Finally, it was about time.

How ironical it has been to revert back to the original solution.

Now the big question remains unsolved.

Why did the delevopers ever think the script calls should have been so darn disruptive in RMXP?