Recycling Self-Switches?

[Sartro]

What I mean to say is, can you Talk once, turn on switch A, talk a second time, turn on Switch B, then later in the conversation reuse Switch A? I know you can turn off Switch self-switches, but I also know the game reads switches from right to left.

So basically what I'm asking, is there a way to hold essentially an endless conversation by creatively flipping self-switches A, B, C and D? If so help would be appreciated, my brain isn't wrapping around it. Thanks!

[Caethyril]

In a sense, yes. There are a finite number of unique states:

• 1 switch = 2 states (on or off)
  
• 2 switches = 4 states
  
• 3 switches = 8 states
  
• 4 switches = 16 states

Since you seem to mention page conditions: I would only recommend using separate event pages if you want the event's behaviour or appearance to change and remain changed even if the player leaves the map. Otherwise you can use a single page with Conditional Branch commands. One possible setup with two self-switches:

◆If：Self Switch A is ON
  ◆If：Self Switch B is ON
    ◆Text：None, Window, Bottom
    ：    ：4
    ◆Control Self Switch：A = OFF
    ◆Control Self Switch：B = OFF
    ◆
  ：Else
    ◆Text：None, Window, Bottom
    ：    ：3
    ◆Control Self Switch：B = ON
    ◆
  ：End
  ◆
：Else
  ◆If：Self Switch B is ON
    ◆Text：None, Window, Bottom
    ：    ：2
    ◆Control Self Switch：A = ON
    ◆Control Self Switch：B = OFF
    ◆
  ：Else
    ◆Text：None, Window, Bottom
    ：    ：1
    ◆Control Self Switch：B = ON
    ◆
  ：End
  ◆
：End

Represented as a table:

Text	Switch A	Switch B
1	OFF	OFF
2	OFF	ON
3	ON	OFF
4	ON	ON

[Sartro]

Phew no wonder I was having trouble wrapping my head around it.

Thanks that helps.

[JohnDoeNews]

If you want to have a schene, that changes over and over again, as if it evolves, it is much easier to use a variable instead. Every time you change the event to the next phase, simply just do +1 to the condition. You can make up to 20 different pages per event that way, and with conditional branches, you can make even more conditions per page.

[Caethyril]

Good to hear it helped! o/

A couple more notes:

Originally posted by JohnDoeNews:

If you want to have a schene, that changes over and over again, as if it evolves, it is much easier to use a variable instead. Every time you change the event to the next phase, simply just do +1 to the condition. You can make up to 20 different pages per event that way, and with conditional branches, you can make even more conditions per page.

Note that variables, unlike self-switches, are not per-event. Otherwise: yes, a variable would be ideal for a long, non-branching conversation~

Also, to emphasise what I said earlier, having multiple event pages when you could use Conditional Branch commands instead can cause unnecessary problems:

1. Every frame that a page condition changes (e.g. any switch is turned on/off) all events on the map check their page conditions and change page if appropriate.
   
   • This can cause an increase in CPU usage, particularly if you frequently change potential page conditions and the map has a lot of multi-page events.
   
   
2. Every time an event changes page, most of its properties (image, direction, move route, move speed/frequency, through, direction fix, etc) reset to those for that page (cf Game_Event#setupPageSettings).
   
   • This can interfere with event behaviour if you don't plan for it.

Multiple pages are necessary for some things but it's usually better not to use them if you have the option. ^-^'

[JohnDoeNews]

I like to stick to this rule: I only use a new page, when I want to change the event and permanently. In most cases this means: I would want to use a new sprite/animation for this event. (For example, when a character dies, or when a characters behavior changes completely after completing a quest.)

When changes after a quest are so big, that they chance multiple things on a not so large map, I find it easer to just make a copy of that map. One before, and one after. In this case the condition will not be in the event itself, but event on the previous map that brings your to this map.

Like this:

Lets say we have 1 switch, called "We did it!" which get flipped when we defeat the boss.
We have 2 tavern maps: 1 regular, which is active before the battle and 1 where everyone is celebrating your victory, active after the battle.

Then the transfer should look like this:

◆If：We did it!! is ON
  ◆Transfer Player：TEVERN AFTER WIN (3,12)
  ◆
：Else
  ◆Transfer Player：TAVERN DEFAULT (3,12)
  ◆
：End

This way I only have to make 1 condition, which affects the whole map.

NOTE: If you are already on the map where the change should take place, then you should transfer to the new map, at the moment you achieve the goal.

[Caethyril]

@JohnDoeNews sounds good!

[Sartro]

I've definitely got variables down! I mainly wanted to know about the capacity for self-switches just so I knew what tools I had available! Right now playing with the program I'm trying to do things a different way each time, or do something new each map.

Oh! One more question you made me think of!

If: Win
If: Lose

Where do I find this option? I was looking for it, but for the life of me I couldn't find it, but maybe it was labelled as something else?

[Caethyril]

That sounds like the branches offered by the Battle Processing command, e.g.

◆Battle Processing：Same as Random Encounter
：If Win
  ◆
：If Escape
  ◆
：If Lose
  ◆
：End

The branches only appear if you check the "Can Escape" and/or "Can Lose" options. Otherwise escape is blocked and losing gives a game over, meaning you have to win to continue the event. (Abort Battle immediately ends the event.)

[JohnDoeNews]

Well... If you got the basics down and you want more possibilities with self-switches, you should look into YEP_SelfSwVar.js by yanfly. I am not sure if it is free, but this gives you an almost unlimited source of self switches... And super bonus: Also self-variables.

[Sartro]

Oh! Makes sense the If: Win is only under the Battle Processing command! I haven't used that much yet, I'll have to dig into it!

Oooh, self-variables sound really nice and really just what I want for fun little side events without cluttering up the variable switch chart. (Which is originally why I was curious about recycling self-switches.)

I've been working on getting the fundamentals down so I haven't looked into plug ins yet. Sounds like the sky is the limit!

[Iguana Guy]

In the plugins that come with MV there is one called OuterSelfSwitch. I use it a lot. I t alllows you to turn off self switches outside of that event, so you could turn off a self switch for an event that is not running for example. See if you have that one and check out the simple directions for using it. It works ok alongside most of Yanfly plugins too so it is stable.

[Elriadon]

Originally posted by IguanaGuy:

In the plugins that come with MV there is one called OuterSelfSwitch. I use it a lot. I t alllows you to turn off self switches outside of that event, so you could turn off a self switch for an event that is not running for example. See if you have that one and check out the simple directions for using it. It works ok alongside most of Yanfly plugins too so it is stable.

You can just use a script call to change a self switch of a specific event, you don't need a plugin:

$gameSelfSwitches.setValue([n, e, 'A'], true)

n is map id, e is event id.