There are none. As a result people trying to create a simple switch in gdevelop get in a cyclic trap.
This is repeatedly asked and answered in the forum:
The workaround is dirty and also forces the need to create more variables that overcomplicate the project 
The lack of else and elseif statements in gdevelop is my second biggest missing feature in html5 games after the lack of functions.
Honestly these are basic programming tools and they are still missing.
We already talked about it. How to we manage selected object’s instances ?
How did they implement it in construct2?
scirra.com/tutorials/292/gu … t-features
Maybe the way its designed there could be a way to go?
The else conditional event could check the event that was before it for the required information.
Having an “else” as a condition is strange. Maybe an event If/ElseIf/Else (with the possibility to add multiple ElseIf).
yes! That would be better than not having it at all 
I mean come on, it is a pretty basic thing and it’s still missing.
This will make life so much easier in so many cases.
when will we be able to do this in GD?
You can actually already do this:
Variable x = 1 :: Do something
Variable x = 2:: Do something
&& event
Variable x != 1 :: Do something
Variable x ! = 2 ::
||
No conditions :: Do = 0 to variable done
Variable x = 1 :: Do = 1 to variable done //if
... //else if
Variable x = 9 :: Do = 1 variable done //else if
Variable done = 0 :: Do something //Else event
I’m not saying that else/else if would be not useful at all but the C2 screenshot you have shown can be done in GD by using the same (3) number of events:
In my opinion it would make more sense if we would have an else option in every condition to toggle on/off similar to inversion.
For example:
we can check if an object is in collision with a specified object
we can also inverse this condition and check if an object is not in collision with the specified object
How about a third option (else) if we could check if an object is in collision with anything else but not the specified object or even combine with inversion and check if the object is not in collision with anything else but the specified object?
4 different things to achieve using a single condition, it would be the better way to do it in my opinion.
try doing the example from here
it gets stuck because it doesnt have an elseif 
You are talking about the first two events, right ? Just need an extra variable to get it working.
That is exactly the point. If we had an ELSE case, we wouldnt need to create an extra variable every time we need to do this. 
creating extra variable, setting it… just overcomplicates the event sheet needlessly.
You don’t need to create a variable to use it. You can directly use it through the variables conditions/actions.
The event sheet would also have to display the if/else block, complicating the event sheet similarly.
(If your don’t need an “else” in a sub-event of another “else” you can reuse the same variable along all the scene, so you need only one extra variable).
It goes nowhere, I think the point is not about creating a needless extra variable, but making the Event’s Editor to look better for reading, and need less “mental effort” to create this if/elseif/else structure. The first time this “loop” happened to me, I get stuck a pair of minutes to get it working, and some more time to understand that I just need one variable 
In programming, you could create temporary variables to get the if/elseif/else code working, but surely you all love the built-in system, so I go with:
Is not totally needed, but would be nice and clean!
PS 1: About selected instances, not sure at all as really I’m not sure how it works now (there is a temporary list/array/vector with all the instances that gets “clipped” by the event conditions? or GD runs the conditions for every instance on the fly?).
Basically, you have some objects that meets and run in the “if”, then you have to run the “else if” over the instances that didn’t meet the “if” and didn’t fulfills the previous "else if"s extra conditions too, finally launch the “else” over the instances that didn’t satisfy the “if” and any “else if” extra condition. But surely you know how to handle it, so I don’t understand the depth of the problem, is it related to way GD handles instances or the code generator?
PS2: If there is a possibility to make it, I think a special event If/ElseIf/Else is a good option, the C2 system is just ugly, I mean, you have a good event > yeah, another one > nice event!, then this guy “Else” appears and you > What!? Where are you from?
If we do it that way, the else/elseif would be totally equivalent to the inverted conditions.
Maybe I’m wrong, but that is be the behavior I would expect… I think. Do you have you something in mind?
Maybe some “graphics” can help us, what do you think about a generic vector?:
<CarRedSmall, TankGreenMedium, BoatWhiteMedium, AirplaneWhiteBig, CarGreenMedium, AirplaneRedSmall, CarRedBig>I would expect this:
[code]//Conditions over
If NOT Red:
// Actions over <TankGreenMedium, BoatWhiteMedium, AirplaneWhiteBig, CarGreenMedium>
//Conditions over <CarRedSmall, AirplaneRedSmall, CarRedBig>
Else if Car:
// Actions over <CarRedSmall, CarRedBig>
//Conditions over (but no conditions, of course)
Else:
//Actions over [/code]
wouldn’t it take two variable blocks to replace the single “else” block? can you share an example where you want an action to execute only if the one above it is false. Also share another example where you want an action to execute if the one above it is false and also another condition is met. This is common case when you have input.
Give me a chain of actions that only one of them can execute.
It’s just much easier to read with an “else” block. The variable way works too, but you need to use two blocks and looks like a workaround to something that all other engines have.
That would be equivalent to what you can do by inverting conditions.
In Construct 2, else just execute the event without selected object instance itself if the previous event is not valid (no instances fulfills the conditions).
Actually, The main problem when we trying to make a switch is that, all the events are triggered every frame but it should stop once it switched.
Normally when I want to make a switch sort of thing, I’m always doing something like this to make the event stop:
If Space key is pressed : key_pressed = 1
sub event - switch = 0 and key_pressed = 1 : switch = 1 and key_pressed = 0
sub event - switch = 1 and key_pressed = 1 : switch = 0 and key_pressed = 0
I agree on that this kind of solution can look over complicated but really we need something like this.
So instead of forcing the ELSE way, how about the have a special event dedicated to make switches?
The event would require to have at least one condition and we would required to use sub events to add actions. The event would have no space for actions only for condition.
This way, GD would gently force people to use sub events to add actions, it could have two by default to help people get the idea. So, when GD trigger this event, it would trigger only one sub-event at the time that is true. When a sub event was true and it actions are triggered, it would stop similar to my “dirty” solution above and other sub-event would be not triggered until the main condition fulfill again.
The event would have no limitations really, it could have any condition and any number of “main sub events” and move from the first one to the last one and stop once any of the (main) sub-events was true and the actions are triggered. This way we could switch between any number of states but only one of them can be true at the time.
MAIN CONDITION
MAIN SUB EVENT 1
-sub event
-sub event
MAIN SUB EVENT 2
-sub event
-sub event
In my opinion this solution could be better because it would be straight forward what is it for and how to use it also looks and feels home in the editor in my opinion and unlike with ELSE, it would trigger the first sub-event that is true and stop instead of waiting for the previous event to be fail.
Only to see the different, my above over complicated example could looks like this using such event:
Space key is pressed
sub event - switch = 0 : switch = 1
sub event - switch = 1 : switch = 0
EDIT?//
I was just thinking about it and I have realised what I have described above would still require us to make sure the sub-events are actually switched. So how about that if it would be automated? Always the first sub event would be triggered first and then stop, after the second, and then stop and after the third and so son. Of course the condition still need to be true in case a condition is fail, it would jump to the next one in the row. but in case the condition is true or we don’t use condition it would be triggered in order first to last.
So, by doing this way my above example could be like this:
Space key is pressed
sub event - no condition : switch = 0
sub event - no condition : switch = 1
sub event - no condition : switch = 3
So yeah, there is basically to way of doing this in my head:
One way of doing is the event would check each sub-event from top to bottom and trigger the first one that is true and then stop but next time start all over again from the top.
The other way of doing is, the event would go in order from first to last and trigger the event if it true and then stop but next time it always start from the last triggered sub event and continue the row to the last.
Maybe we could choose when we add the event if want it to move from first to last sub event each time or we want it to start each time from the last triggered sub event and continue the row to the last.
It could be also two separated event just to keep it simple…
so if most programming languages have an “else” function and most game engines (visual or not) also have an “else” function, then surely it must be useful enough to keep. Not only construct2, but also clickteam fusion has it. Game maker has it. After using it in game maker then going back to the event sheet in gdevelop, i see it’s merit and gdevelop’s way seems like an ugly workaround in situations where “else” would have nailed it right away.
Just for link two same topic.