How do script switches work?

[kvagram]

There seems to be something wrong with the timed switches (14 to 20).
I am working with TBC on Generation 0, and after updating to the new version of pokemon essentials, none of the time-sensitive events were working as expected.

Checking with a fresh unedited version of Pokemon Essentials v14, the problem is visible when starting a new game - all switches from 14 to 20 are off, when at least some is expected to be on.

 

[Maruno]

You'd know there's nothing wrong with those switches if you actually used them. Their code is evaluated when they're checked and the result returned, rather than returning the value stored in that switch. The Debug menu doesn't evaluate the switches, and instead shows the (unused) values of those switches, which is OFF by default.

 

[kvagram]

You'd know there's nothing wrong with those switches if you actually used them. Their code is evaluated when they're checked and the result returned, rather than returning the value stored in that switch. The Debug menu doesn't evaluate the switches, and instead shows the (unused) values of those switches, which is OFF by default.

Wait wait wait... Are you telling me that the debugger is not actually informing me as a developer what the state the switch is in?
Or are you telling me that Essentials is not actually updating those switches automatically, as I expect them to?

Either way, the switches are off, and if you claim the debugger is lying, here is proof

If I have misunderstood how this feature works, please explain.


--edit
After some reading, those switches seem to be "Script Switches", according to the wikia, however I find no explanations or documentation of how those work (if you know, please explain).
If I understood those correctly, script-switches are supposed to test their script whenever they are used?
In that case, the bug might be in how essentials v14 handles those "Script Switches", for they do not update as expected.

 

[Maruno]

Wait wait wait... Are you telling me that the debugger is not actually informing me as a developer what the state the switch is in?
Or are you telling me that Essentials is not actually updating those switches automatically, as I expect them to?

Either way, the switches are off, and if you claim the debugger is lying, here is proof


If I have misunderstood how this feature works, please explain.


--edit
After some reading, those switches seem to be "Script Switches", according to the wikia, however I find no explanations or documentation of how those work (if you know, please explain).
If I understood those correctly, script-switches are supposed to test their script whenever they are used?
In that case, the bug might be in how essentials v14 handles those "Script Switches", for they do not update as expected.

Script switches are ones whose name begins s: followed by some code. The state the switch is in is whatever that code returns. They are evaluated when they are checked by an event. It is impossible to change them manually, because even if you did, when they're next checked they'd just evaluate their code again and return that, not the value you set it to.

Game switches usually store their values in an array. They're also usually changed manually. However, script switches is something Essentials has, and are automatic. The values they return are NOT stored in an array, they are determined by their code. They really do work when they need to; it's just that looking at a list of switches in the Debug menu won't show what they would return, because that Debug option doesn't evaluate those switches. They just work automatically, and you don't need to worry about them at all (and you certainly can't override them). Just ignore them when you're looking at them in the Debug option. I see no need to make it evaluate the switches then as well.

 

[kvagram]

Script switches are ones whose name begins s: followed by some code. The state the switch is in is whatever that code returns. They are evaluated when they are checked by an event. It is impossible to change them manually, because even if you did, when they're next checked they'd just evaluate their code again and return that, not the value you set it to.

Game switches usually store their values in an array. They're also usually changed manually. However, script switches is something Essentials has, and are automatic. The values they return are NOT stored in an array, they are determined by their code. They really do work when they need to; it's just that looking at a list of switches in the Debug menu won't show what they would return, because that Debug option doesn't evaluate those switches. They just work automatically, and you don't need to worry about them at all (and you certainly can't override them). Just ignore them when you're looking at them in the Debug option. I see no need to make it evaluate the switches then as well.

Thank you, I did some testing, and something still seems wrong.
* When testing with those switches as conditional branches, they fail.
* When testing them as condition for an event-page, they work.

Are they not supposed to work in a conditional branch?
Also, where and in what script-section can I find this "script switch"-feature?

 

[Maruno]

The s: should only appear in switch names. This is what tells the switch that it needs to evaluate the code rather than grab a value from the array of switches. If you're using the code in a Conditional Branch, get rid of the s:.

 

[kvagram]

So this script-switch feature does not run in a conditional Branch, that is what you are saying, correct?
To get the expected result, I have to test with the script itself, correct?

I can't remember reading about that in the wiki.

 

[Maruno]

Conditional branches are SUPPOSED to have code in them. Switch names are just expected to be names and not code. The idea of a script switch is to add in some functionality to let certain switch names (those beginning with s:) to be able to run code instead of just be names. s: is exclusive to switch names, and solely serve to indicate that a switch's name should be evaluated as code.

Script switches have nothing to do with conditional branches. Don't put s: in a conditional branch, because it's meaningless. Just put PBDayNight.isMorning?(pbGetTimeNow) or whatever in a conditional branch. The code is valid code which can be used anywhere, but s: should never appear anywhere outside of a switch name.

I can't get any clearer than that.

 

[Nickalooose]

What Maruno is saying is, the switches are switched on and off automatically, but use PBDayNight.isNight?(pbGetTimeNow), in a conditional branch... As Maruno already stated, those switches are almost useless to you or me or anyone that uses Essentials, so don't worry yourself about them.

EDIT: Maruno you ninja lmao

 

[kvagram]

Oh man... you completely misunderstand me here...
Yes, I know coding, yes I know how to let a conditional branch run a script rather than a global variable or global switch.

What I was asking, was if the conditional branch checks the name and runs the script-switch in the same manner as is apparently done for the conditions of an event-page.

And yes, I got WHAT script I need to use in order to use them that way long ago.

However, I am still curius about where in the Essentials script I can find the script switch feature. I may want to see if I can make it work in conditional branches myself.

 

[Nickalooose]

Do you mean by removing the day night scripts and making your own? Because you could probably just take a look at FL.'s fake time script... And just call PBDayNight.isNight?(pbGetTimeNow) etc. in your new scripts... That's all those switches are doing, calling the scripts, so they return yes or no, but won't be on or off like a normal switch... So they can be a condition on an event page, but useless as a script itself.

 

[Maruno]

No, you cannot check whether a script switch is ON or OFF in a conditional branch (by choosing the "Switch" option at the top of tab 1 when making a conditional branch). This will not evaluate the script switch.

In this case, you will need to go to tab 4 and choose "Script", and put in the code you want there, even if it happens to be the same code as is used in a script switch. This isn't difficult, though, and I see no need to try to make it work when you can easily work around it.

Search the game's scripts for def switchIsOn? to find out how script switches work.

 

[kvagram]

Ahh, found it.
Looks simple enough.
It might not be impossible to patch it for conditional branches.

  def switchIsOn?(id)
    switchname=$data_system.switches[id]
    return false if !switchname
    if switchname[/^s\:/]
      return eval($~.post_match)
    else
      return $game_switches[id]
    end
  end


def refresh
    new_page = nil
    unless @erased
      for page in @event.pages.reverse
        c = page.condition
        if c.switch1_valid
          if !switchIsOn?(c.switch1_id)
            next
          end
        end
        if c.switch2_valid
          if !switchIsOn?(c.switch2_id)
            next
          end
        end
(...)

 

[kvagram]

I guess there might be more then just me that want the scriptswitches to work in conditional branches.
To those of you who might want that:
Here, just add this is a new script. It was a laughably simple fix.

class Interpreter
	def command_111
    # Initialize local variable: result
		#print(@parameters.join(","))
    result = false
    case @parameters[0]
      when 0  # switch
        result = (switchIsOn?(@parameters[1]) == (@parameters[2] == 0))
      when 1  # variable
        value1 = $game_variables[@parameters[1]]
        if @parameters[2] == 0
          value2 = @parameters[3]
        else
          value2 = $game_variables[@parameters[3]]
        end
        case @parameters[4]
          when 0  # value1 is equal to value2
            result = (value1 == value2)
          when 1  # value1 is greater than or equal to value2
            result = (value1 >= value2)
          when 2  # value1 is less than or equal to value2
            result = (value1 <= value2)
          when 3  # value1 is greater than value2
            result = (value1 > value2)
          when 4  # value1 is less than value2
            result = (value1 < value2)
          when 5  # value1 is not equal to value2
            result = (value1 != value2)
        end
      when 2  # self switch
        if @event_id > 0
          key = [$game_map.map_id, @event_id, @parameters[1]]
          if @parameters[2] == 0
            result = ($game_self_switches[key] == true)
          else
            result = ($game_self_switches[key] != true)
          end
        end
      when 3  # timer
        if $game_system.timer_working
          sec = $game_system.timer / Graphics.frame_rate
          if @parameters[2] == 0
            result = (sec >= @parameters[1])
          else
            result = (sec <= @parameters[1])
          end
        end
      when 4, 5 # actor, enemy
      when 6  # character
        character = get_character(@parameters[1])
        if character != nil
          result = (character.direction == @parameters[2])
        end
      when 7
        if @parameters[2] == 0
          result = $Trainer && ($Trainer.money >= @parameters[1])
        else
          result = $Trainer && ($Trainer.money <= @parameters[1])
        end
      when 8, 9, 10  # item, weapon, armor
      when 11  # button
        result = (Input.press?(@parameters[1]))
      when 12  # script
        result = pbExecuteScript(@parameters[1])
    end
    # Store determinant results in hash
    @branch[@list[@index].indent] = result
    # If determinant results are true
    if @branch[@list[@index].indent] == true
      # Delete branch data
      @branch.delete(@list[@index].indent)
      # Continue
      return true
    end
    # If it doesn't meet the conditions: command skip
    return command_skip
  end
	def switchIsOn?(id)
    switchname=$data_system.switches[id]
    return false if !switchname
    if switchname[/^s\:/]
      return eval($~.post_match)
    else
      return $game_switches[id]
    end
  end
end

This will override the code that handles how conditional switches work in events.
It MOST be placed below "Interpreter", best at the bottom of the list of scripts.