"else" and "elseif" conditions in Gdevelop

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 :smiley:

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:


C2 over complicating things for no reason, and the C2 screenshot is a perfect example of that (I would call this dirty and over complicated)ā€¦ :stuck_out_tongue:
What is the point of having else/else if in C2 or GD if you are using the same number of conditions by end of the day in the same order?

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.

1 Like

try doing the example from here

it gets stuck because it doesnt have an elseif :frowning:

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. :slight_smile:
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 :blush:

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! :slight_smile:

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? :smiley:

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.