what is the point of self switches?

[KonKossKang]

Conditional branches, switches that you open up in the event, everything makes sense except self switches.

What's the point of those at all?

 

[Yato]

They're for changes in the event that don't need to affect anything else around them. For example, they are perfect for chests. Really, they're identical to switches except they are only usable by that event. If you had to use a switch for every chest in a game, you would go through a lot.

 

[McTricky]

Think of the normal switches being a "global" thing. It can be referenced and be called from anywhere in the game/project. Self Switches only pertain to that particular event that the self switch is in (hence the "self" part of the name). Each event has their own set of Self Switches (four in fact, A, B, C and D) and only affect things within that event.

 

[estriole]

it's useful in lots of things. one of them is farming system for example.

if using normal switch...

4 switch for EACH event:

no switch for soil state

1) for seed state

2) for plant state

3) for plant state 2 state

4) for harvestable crop state

means if you have 10 Turnip. you will need 10 * 4 switch = 40 switch.

with self switch. you only need 4 self switch each. and it would easier to event too. since the event CAN be COPIED!!!.

with normal switch it won't be possible since you need to modify the switch OR all your turnip will ALWAYS have the same STATE.

of course farming system is more complicated than that. since you also have different type of crops. so if you use normal switch... it will be HELL to event.

edit: just read racheal post above and want to add some.

if you use self switch for chest. you CAN copy the event easily. and just change the item given if necessary.

if you use normal switch. AFTER you copy it. you must change the switch reference too.

maybe it's like only reducing 1 step. but if you create 1000 chest. then it reduce 1000 steps total. .

 

[KonKossKang]

Hm...So if i decided to create a dragonball event and made a switch name called "1 star dragonball"it would affect every 1 star dragonball if i copy pasted the same 1 star dragonballs everywhere?because if thats the case i could just make different dragonballs lol im ok with making switches the "hard way" individually with different switch names that's not an issue for me.

 

[Shaz]

And you don't have to use heaps of global switches, which all need to be named (unless you want to risk using the same one for different things then wonder why your game doesn't do what it should), and scrolled through when you want to select switches. THAT'S a pain when you have a lot of them.

 

[Andar]

Hm...So if i decided to create a dragonball event and made a switch name called "1 star dragonball"it would affect every 1 star dragonball if i copy pasted the same 1 star dragonballs everywhere?

Yes, if you copy an event that is controlled by a general switch then that switch forces all copies of the event into the same configuration. That is not something that you want with objects like chests, because then opening the first chest would force every chest in the game into the "opened" condition. In such cases it's easier to use self-switches as those are automatically different when copied.

Making new switches "the hard way" to prevent the use of self-switches (that is changing the switch and renaming it after each copied event) has two big drawbacks/problems:

1) This only works if you copy the event in the editor. But there are script commands that allow you to copy events ingame during play (for example to spawn evented enemies), and in those cases it's impossible to edit the copied event during play.

2) There's a limit to general switches - you can't create more than 5000 in the editor. And if you're using general switches for chests, enemies or similiar multiple-event-cases, then this limit will become a problem in larger games...

Edit:

FYI - there is a script group "self data suite" from PK8 that will create more self-switches and even self-variables not only for events, but also for other game objects like maps, actors and so on. That was made because this distinction of using variables and switches that are bound to objects rather than general is very helpful with several advanced eventing and scripting concepts.

Those scripts aren't in wide usage because not everyone needs them, but several advanced game concepts are very difficult to implement without them...

 

[Shaz]

I think it's called "self data suite"