Imagine if we could insert an OR condition!

Does anyone use the current "Or blocks"? They feel limiting and against the design of Construct, since events are all about using multiple conditions per event, but the or block goes against that design by only allowing a single condition to be used.

Wouldn't it be awesome if we could insert an "or" system condition wherever we want and do more advanced efficient useful things?

A current example of code that could be more efficient with an "or condition":

Imagine if we had the power to just quickly insert an OR there and save time and duplicate events! Mockup:

From 8 events to 4, and it was quick and simple, awesome!

Yep, I'm with you on that.

I currently stick all the duplicated events in a function and call the function on each occasion.

A work around that shouldn't be needed.

+1

Post a suggestion for it!

I would love this

Absolutely, basically just have it like the "Else" I think this has already been suggested on several occations, but the more the merrier

Imagine if we had the power to just quickly insert an OR there and save time and duplicate events! Mockup:

From 8 events to 4, and it was quick and simple, awesome!

while OR wont work like that cause is impossible of its current state as category of expression you can lower your events and remove duplicated events by doing the following:

Image

the first its not half of 8 but still saves 25% / while the second is as powerful as your suggestion... therefore wont be changed... because is already possible what i love about C2/C3 is that you can use it as you want, as long as your using your imagination. (i do think the suggestion ur making would make life easier for majority of people though since the math thingy will confuse most of them +1 from me also, but i doubt would be something that would be taken in consideration as important)

Edit: i modified a bit the post so if you seen the (a+b)=5 just refresh the page... was some stupid thing i did ... however tunepunk & dop2000 solution is better, since uses C2/C3 system expressions as are intended to be used in this type of cases.

This can be done easily with expression? Expressions support "or" using the "|" sign.

You can use this kind of expression in a compare two values system condition.

(a = 1 & b = 5) | (a = 1 & b = 3)

= 1 returns true.

Here's an example:

https://www.dropbox.com/s/0bq7jkr98pvig ... t.c3p?dl=1

From 8 events to 4, and it was quick and simple, awesome!

Here is the same in just one event and one action:

>

>

> From 8 events to 4, and it was quick and simple, awesome!

>

Here is the same in just one event and one action:

Yeah. I don't think a lot of people know they can use expressions that way. It's a bit of a learning curve, but once you get used to it. You will reduce the amount of events a lot.

There should be some good tutorials on that, because you don't really stumble across it by chance unless you study the manual, and read up on expressions.

Here is the same in just one event and one action:

Dope!

Thanks for the replies, great thoughts!

An OR condition is much more basic and faster than creating complicated equations and functions, especially for newer users. Sometimes spending a lot of time on functions, and optimizing things to a single event is tedious.

If it helps, here is another example to illustrate.

Before:

After:

Simply half the events!

In a real game you can end up with dozens of duplicated subevents. Just quickly putting in an OR would be quite nice!

Looks like a nice idea but when picking is involved the “or” version would work differently than the duplicated events version.

Events a

Or

Events b

—- actions c

Is the same as

Events a

—- actions c

Else

Events b

—- actions c

What you probably expect is:

Every tick

— sprite: set bool picked to false

Events a

—- sprite: set bool picked to true

Events b

—- sprite: set bool picked to true

Sprite: is picked

—- actions c

But or doesn’t work like that. Plus even that works different than duplicating events. I actually only use or in simple cases.

Yeah. R0j0 is right.

If you the only problem is duplicated subevents and you want to save some events you can put duplicated subevents in a function and call that instead.

Functions are very useful for this purpose and very flexible since you can pass variables through the function parameters.

I think R0J0 alluded to some interesting difficulties. FWIW OR blocks are extremely complicated internally which makes them difficult to begin with. But when you add picking, things start to get less intuitive. For example take this gotcha with the existing OR blocks:

+ Sprite instance variable 'health' < 0

OR

+ Spacebar is down

-> Add 10 to score

-> Sprite: spawn 'Explosion'

People run in to this counterintuitive issue where the event can run with no instances picked. Suppose you press space and no sprite instances have health < 0. The event runs because the space bar condition was true and the score increments - but zero instances of Sprite are picked because they all failed the condition - and no explosions are spawned. So it looks like the "Spawn" action is broken, when actually everything's working as designed. There is nowhere else in the event system events can run with zero instances picked, and this kind of quirk occasionally trips up users. In other words, once picking gets involved, it's not as simple as boolean algebra any more. I am sure this suggestion would uncover similar confusing and difficult cases.

I think the bigger problem is that even with this feature, it's still limited. Currently you can do events of the form A AND B AND C, and if you use an OR block, you can do A OR B OR C. If you add a sub-event that is also an OR block, you can make events of the form (A OR B) AND (C OR D). This suggestion allows for (A AND B) OR (C AND D). The next logical step is to allow more complex forms, for example (A OR (B AND C)) OR D, etc. To do that you'd really need "open parenthesis" and "close parenthesis" conditions, which I really think is a step too far. I think expressions are better suited to that, especially the "pick by evaluate" condition which also allows for picking instances by arbitrary expressions.

Basically given the complexity of this, the weird edge cases, and the unsuitability of taking it further, I think we have an OK tradeoff as it is.

Shouldn't it be more like how the Else works?

This condition block, Or this other block condition.