Why only 4 Self Switches?

Why are there only four self switches available and why can I not add more like other database features can have the limits added to? At least give me 26, since there are 26 letters in the English alphabet. Does it have something to do with the original japenese version.. I know Japenese has more than 26,000 characters. So why only four self switches and no way to add or change the limit?

I find this odd as well.  The underlying scripts seem to store the switch values in a hashmap, so putting 'E' through 'Z' would make no difference.

My guess is it is an arbitrary choice.

You could do it through a Script call

$game_self_switches[[map#, event#, 'E']] = true
and you could check it through a Script call, even as part of a conditional branch:

Conditional Branch: Script: $game_self_switches[[map#, event#, 'E']](returns true or false)

But you can't add it to the conditions of an event page or use it in event commands that have lists for self switches.  You COULD use Hime's event conditions script, maybe, to condition pages by it without having to add conditional branches.

Why?  Why is the sky blue?  Why is the earth round?

LOL You just made my night.

Also, I'm pretty sure there was a reason why there were only 4 Self-Switches added instead of a flexible amount based on alphanumeric letters or, hell, a hexadecimal number.

There might be a reason, but as far as I can see, it's an arbitrary limit, as shown by Shaz's manual assignment.


I'm inclined to believe that the first RPG Maker had an arbitrary limit of 4 and they just decided to carry that forward.

A little off topic.. and possibly overly sciency, but...

the sky is blue due to  the way light enters the atmosphere and the absorption/scattering of certain wavelengths of colored light.

the earth is "roughly" round due to the gravity.

Number of Self Switches in RMVXA may however remain a mystery despite our advances in science =\

~ Dinhbat

you younger programmers forget that there was a time when RAM was really expensive - like a thousand dollars for 256 Kilobytes (yes, KB, not MB or GB) of RAM. There is even a famous quote from the IBM developers when building the first PCs - "we can limit the maximum RAM for DOS-access to 640KB, because there is no way anyone will ever need more memory than that"...


People who learned to program in those times (about 15-20 years ago) were required to use only the minimum RAM neccessary and not to allocate RAM that wasn't needed - and old habits don't die.


For regular use, four self-switches are usually enough - and I'm guessing that the lead programmers decided out of habit not to waste memory space on data that they thought wasn't needed.

Here are my completely random thoughts:

Anything you can do with a self switch you can do with a control variable. There is a difference though - a control variable has a descriptive name attached to it. "Had 2nd King Talk" is a lot more informative than "B". 

Self Switches are there for common things that you know what's going on without needing a description. For example, in my project I always use self switch D for "talked to this event once already." No matter what event I look at in the game, if I need to trace things out, I know what self switch D was set for.

If I had self-switches A-Z I'd have to comment the hell out of the event pages for me to try to keep straight which self switch was being used for what. I already have to do that a lot and there's only four of them.

Are there times I wished I had a couple more? Yeah, but I've also learned how to 'recycle' some of them as well to help in that department. Otherwise I just use control variables. If I reach ten thousand of those used, I'll have to figure something else out, although at that point I think it would be time for some serious garbage collection.

Sure, they carry THAT forward but take away our precious XP mapping.....  :|

No, that is completely wrong. The main reason for self-switches are the fact that they are event-based (stored differently for each event) while the variables are game-based (identical throughout the game).
For example, make a treasure chest that gives a number of gold or an item, and use a self-switch or a variable to mark it "looted".


Then copy a dozen of those events on one map.


In the case of the self-switch, you can loot all chests independently from each other and gain their content whenever you want.


In the case of the variable, you loot the first chest and all of them become "looted", you would need to change the variable used in every event (and use up a lot more variables, because you'll need one variable for each chest.


That is on the other hand the reason why you can't simply add an unlimited number of self-switches to the editor: it does not need the RAM for that once (as with general variables or switches), it will need to reserve the needed ram for every event (which means you need the RAM for one switch multiplied by the number of events in the game/on the map), even if only a few events really need that additional self-switch...

This issue wouldn't have occurred if they had simply designed their page conditions the same way they had done their features/effects.


In VX, where it was literally lists and lists of booleans, you've got a huge memory waster (sure, the overhead of adding a Feature object could be arguably equivalent to 20 boolean fields, but that's besides the point).


Then comes Ace with their "pay as you go" model and now suddenly you don't need to have a boolean for every possible effect/feature, for every object in the database.


Pick what you need, add them to a list. Now you can provide dozens of types of page conditions without having to worry about the end user not having enough memory to handle it.

There is nothing at all stopping you from doing this:

and

except what I said earlier about not being able to use them in page conditions (unless Hime's page conditions script can handle it and you install it), and the fact that you could end up doing this:

Interestingly, the self-switches are stored in a Ruby hashmap.  So, if a self-switch is not explicitly set to ON or OFF, it takes no extra memory to store.  I think the default is OFF unless the switch is explicitly set to something.

I agree it is trivial within a script to have as many self-switches as I'd like.  I'd just like to see a larger selection of self-switches available from the GUI, because they're easier to use that way.  And an Event page can't directly trigger off any script call, unlike the Condition Branches, etc.

As for "Why would someone need more than 4 Self-Switches", a Harvest Moon example, we might use Self-Switches A through D to represent the phases of growth of the plant.  Then we might use Self Switches E through G to represent the plant being Diseased in various phases, and Self Switch H to represent Wilted.

I never realized how handy Self-Switches were until I really started coding my first actual game.