Or statement is boned (a rant)

This is a venting post, because I just can't be bothered jumping through the hoops of the bugs forum when it's their error, not mine.

The 'or' statement can't handle using an objects variables and a global variable - it screws up!

And just now I find the damn or statement was only executing global number manipulations and not object variable changes.

It's not hard to test this yourself. But this is primarily a rant - because it's hard enough finding the bugs you made yourself, but when the bug is in the programming language and not your own fault at all, it's infuriating!

WTF! It's an 'or' statement - it should just work! It's that simple! Now I'm forever evading using it and instead making it up manually (if 'sausages'>0 then FAKEOR=true. If 'mash'>0 then FAKEOR=true. Is boolean 'FAKEOR' true?)

GAH!!!!

Rant done.

Im guessing you're talking about inline comparisons, In which case I agree that it's frustrating.

That's probably why or only works one way when making multiple conditions.

A common misunderstanding that often comes up when people do file bugs with OR blocks is that OR events can run with zero instances picked. E.g.:

+ Sprite X < 500

• or -

+ Global variable "foo" = 0

-> Set Sprite X to 500

-> Play sound

Suppose all the Sprite objects are on the right (none are < 500) but "foo" equals zero. The event runs, because OR blocks run if any condition is true. But no Sprite objects met the first condition, so there are zero sprite instances picked. So no Sprite instances are changed, but a sound is played. Usually this materialises as a bug report along the lines of "the Sprite action is not running even though a sound is played".

This is by design. If it worked differently, it would mean running actions on instances that did *not* meet the conditions, which contradicts the fundamental way events work.

But in a regular IF statement I can test if catsprite is less than 500 x position and if it ISN'T I can still use ELSE to affect that catsprite. I'm not stuck being unable to affect it because it failed the first IF statement. But in an OR statement, if the object fails the OR statment I can't affect the object??

I mean there's a difference between the intent of

'Hey, check if catsprite.x<500 OR tacos>0 - if either, change THAT PARTICULAR catsprite!'

and

'Hey, check if catsprite.x<500 OR tacos>0 - if either, change the catsprite on the screen. The ONE catsprite that is there! One might even say change ANY OLD catsprite, though that's a bit odd to say when there is only one pre existing catsprite! But this is all to say I am not aiming at a particular catsprite, just any old one that is around. It doesn't matter if it's <500!'

Sure it makes sense for the first example to reference only that catsprite. If I'm talking about a 'pat the cat that is sitting in the box' it makes sense only to pat a cat that is in a box.

What doesn't make sense is that 'if there is a cat in the box or tacos>0 then pat A cat' results in NO cats being patted at all!!

There isn't a contradiction there, you're just forcing the same semantics to both examples. When in a regular IF statement, if the cat isn't in the box but I use an ELSE statement, I can still pat that cat! I'm not stopped from affecting it because the IF statement failed - quite the contrary! That's the contradiction - where in a failed IF statement I can affect an object with an ELSE but in a partly failed OR statement I'm not allowed to affect the object at all!

If I'm totally wrong I'll blame it on rant! But currently I'd say the ideology of OR statements contradicts the ideology of IF statements. IF statements let you test a value of an object, but still affect that object (with ELSE) even if the IF statement about the object failed.

TL:DR; Really OR needs a way to distinguish between 'Hey, remember that objects value I tested in the OR statement - I want to affect that particular object!' and 'Hey, remember that object value I tested in the OR statement - well don't worry about it failing. I just want to affect that type of object, not just the one that failed the OR test, mmmm'k! Just like even if an objects value fails an IF statement, I can still affect that object with ELSE'

I think the source of confusion is events aren't really exactly like IF statements. The event "Sprite X < 500" does not work like "IF Sprite X < 500 THEN run actions", because that only tests a single Sprite instance. Conditions filter down instances. So it's more accurate to describe it as working like "FOR EACH Sprite IF Sprite X < 500 THEN run action (on that sprite)". The "for each" iterative aspect of conditions is essential to the way events work, but means it does not act like a normal single IF statement, so it's not always correct to compare it to that.

In the example I gave, if you want an action to run on Sprite in that event, then you can only choose a Sprite that did not meet the condition. Therefore it makes it possible to run actions on instances that did *not* meet the conditions. I think this is totally counterintuitive and nonsensical, and although the current system may be sometimes confusing, the alternative is even worse.

I think a good flow diagram with detailed examples explaining this would be very beneficial in the documentation.

But in a regular IF statement I can test if catsprite is less than 500 x position and if it ISN'T I can still use ELSE to affect that catsprite. I'm not stuck being unable to affect it because it failed the first IF statement. But in an OR statement, if the object fails the OR statment I can't affect the object??

I mean there's a difference between the intent of

'Hey, check if catsprite.x<500 OR tacos>0 - if either, change THAT PARTICULAR catsprite!'

and

'Hey, check if catsprite.x<500 OR tacos>0 - if either, change the catsprite on the screen. The ONE catsprite that is there! One might even say change ANY OLD catsprite, though that's a bit odd to say when there is only one pre existing catsprite! But this is all to say I am not aiming at a particular catsprite, just any old one that is around. It doesn't matter if it's <500!''

You are missing one key aspect. There could be multiple catsprite. If it worked as you suggested, many games would be so hard to code. Just because you know there is one, does not change there is the possibility of multiple.

Actually, what is surprising is that the action "Set Sprite X to 500" in Ashley's example does not affect all instances of Sprite, as it is the case when a condition does no picking (which ends up being the case in the stated OR event if no sprite is < 500 and that the event is only executed because of the global variable value).

Isn't it considered in the runtime as if the first condition did not exist at all ?

Caveat: I say this all as part of my rant

In the example I gave, if you want an action to run on Sprite in that event, then you can only choose a Sprite that did not meet the condition. Therefore it makes it possible to run actions on instances that did *not* meet the conditions. I think this is totally counterintuitive and nonsensical, and although the current system may be sometimes confusing, the alternative is even worse.

But with an OR statement I'm not trying to meet A condition, I'm trying to meet EITHER condition!

I mean, who wants to use an OR statement to filter their results? Sure, with an if statement, if I'm checking the cat is in the box, then I just want to deal with cats that are in the box.

But with an OR statement, I can be checking radically different things - it's not like I'm trying to filter balls that have spots OR balls that are red, I can check for balls that have spots OR whether pizza is ready! Sure with the first example I might want to only deal with the spotted balls or the red balls, whichever turns out to be true in the OR statement - but I know that OR deals with a far wider spectrum than that - I'm not going to use it to filter down to only affect spotted balls in the response to the statement if I'm interested in pizza readyness! As is it's a literal apples and oranges comparison! When I'm checking apples and oranges and the oranges >= X but apples were not >=Y, I don't want to be restricted from affecting apples because...these two things are not the same!

If I understand Kyatric correctly, he's asking much the same thing - why the 'is the sprite.x <500' is considered to exist at all when not fulfilled, in regards to picking.

[quote:31kieukt]So it's more accurate to describe it as working like "FOR EACH Sprite IF Sprite X < 500 THEN run action (on that sprite)". The "for each" iterative aspect of conditions is essential to the way events work, but means it does not act like a normal single IF statement, so it's not always correct to compare it to that.

But I'm not restricted in the ELSE statement like that.

Like I can avoid automatic filtering from the initial failed IF statement with the ELSE statement, I'd like some way to avoid automatic filtering with the OR statement - I seriously don't always want to have filtering on an OR statement that can be testing things which are radically different from each other. If there's a cat in the box OR pizza is ready, I want to pat a cat. I'm obviously not trying to filter down to a particular cat if I'm checking pizza - which is the normal way the OR statement works.

> But in a regular IF statement I can test if catsprite is less than 500 x position and if it ISN'T I can still use ELSE to affect that catsprite. I'm not stuck being unable to affect it because it failed the first IF statement. But in an OR statement, if the object fails the OR statment I can't affect the object??

>

> I mean there's a difference between the intent of

> 'Hey, check if catsprite.x<500 OR tacos>0 - if either, change THAT PARTICULAR catsprite!'

> and

> 'Hey, check if catsprite.x<500 OR tacos>0 - if either, change the catsprite on the screen. The ONE catsprite that is there! One might even say change ANY OLD catsprite, though that's a bit odd to say when there is only one pre existing catsprite! But this is all to say I am not aiming at a particular catsprite, just any old one that is around. It doesn't matter if it's <500!''

>

You are missing one key aspect. There could be multiple catsprite. If it worked as you suggested, many games would be so hard to code. Just because you know there is one, does not change there is the possibility of multiple.

Yeah, but think of what the filtering is doing.

Functional filtering is if I'm trying to find all the catsprites whos X>50 and X<500. That's valid filtering.

Now why would we treat a test of catsprite.x<500 OR global.pizza>0, with catsprite failing, as filtering out out being able to affect catsprite AT ALL!? I mean this cat wants some pizza, he's not into cheeezburga, he wants pizza added to him! But when he's not <500, even though there is pizza, we can't give him anything?

Such a filter basically turns the OR into an AND statement - if catsprite.X<500 AND global.pizza>0 then the cat can have it's pizza value increased.

In fact all filtering seems to be an AND statement. Which really has no place in an OR statement.

>

> > But in a regular IF statement I can test if catsprite is less than 500 x position and if it ISN'T I can still use ELSE to affect that catsprite. I'm not stuck being unable to affect it because it failed the first IF statement. But in an OR statement, if the object fails the OR statment I can't affect the object??

> >

> > I mean there's a difference between the intent of

> > 'Hey, check if catsprite.x<500 OR tacos>0 - if either, change THAT PARTICULAR catsprite!'

> > and

> > 'Hey, check if catsprite.x<500 OR tacos>0 - if either, change the catsprite on the screen. The ONE catsprite that is there! One might even say change ANY OLD catsprite, though that's a bit odd to say when there is only one pre existing catsprite! But this is all to say I am not aiming at a particular catsprite, just any old one that is around. It doesn't matter if it's <500!''

> >

>

> You are missing one key aspect. There could be multiple catsprite. If it worked as you suggested, many games would be so hard to code. Just because you know there is one, does not change there is the possibility of multiple.

>

Yeah, but think of what the filtering is doing.

Functional filtering is if I'm trying to find all the catsprites whos X>50 and X<500. That's valid filtering.

Now why would we treat a test of catsprite.x<500 OR global.pizza>0, with catsprite failing, as filtering out out being able to affect catsprite AT ALL!? I mean this cat wants some pizza, he's not into cheeezburga, he wants pizza added to him! But when he's not <500, even though there is pizza, we can't give him anything?

Such a filter basically turns the OR into an AND statement - if catsprite.X<500 AND global.pizza>0 then the cat can have it's pizza value increased.

In fact all filtering seems to be an AND statement. Which really has no place in an OR statement.

I guess I just view sprites differently. You cannot really or something easily that can have multiple instances...that is not how an or should be used (in my opinion atleast).

Are you up for a test ? You write an event sheet for 100 sprites. (Will take you like 105 events) I rewrite the code and reduce it to 4 events, using instances and filtering the instances. Up to it ?

If you need to change all instances regardless of which instances get picked or don't get picked, you can add a Pick All after the Or condition in a sub-event.

I've been confused like you regarding how Or events work, but it is manageable once you understand them.

Are you up for a test ? You write an event sheet for 100 sprites. (Will take you like 105 events) I rewrite the code and reduce it to 4 events, using instances and filtering the instances. Up to it ?

Not sure who you are referring too, or what you are actually going on about.