[r91] OR block and picking

Ok this time I think it's a real bug

After some tests, if I make a 'OR' block (Condition A or Condition B)

if Condition A is true and Condition B isn't

And if Condition B is a Sprite condition (like Sprite: [Invert] is visible)

Expression like Sprite.X and Sprite.Y returns 0.

I would expect to get the position of the first instance of the Sprite but it seems, since the condition involving the sprite is false, that c2 can't pick it so it returns nothing as if no sprite were in the layout.

But the thing that is even more weird is that if I use a trigger as Condition A like 'On Start of Layout', the Sprite is properly picked

Anyway, a capx should make more sense

or&picking.capx

I think this is by design.

'OR' blocks have to run every condition in the block to set up the SOL properly. If it didn't, events like

+ Sprite X < 300

• or -

+ Sprite Y < 300

would not pick the correct instances. So: in an OR block, every condition is run to set up the SOL.

In this case 'Text is visible' is true, so the entire OR block is true and will run. However, 'Sprite is not visible' is still run, and results in no Sprite instances being picked because none meet the conditions. When no objects are picked its expressions return 0.

I think this makes sense actually when you consider if you just used "Sprite is not visible" on its own the event would not run at all. So the fact you used an OR block to make it run anyway, means you still get no Sprite instances picked. Using 'Pick all sprite' seems like a good workaround in this case, since you want to undo the picking that a previous condition has done, which is what it's designed for.

Using a trigger makes the block run differently: when a trigger in an OR block is run, the other conditions aren't run. It makes no sense to. So in that case it runs literally as "On start of layout: set Text to Sprite.X...", in which case all Sprites are picked.

Do you think it should work differently? It just seems like a confusing case of using OR blocks.

Actually, when I wrote the post, I figured out the 'condition is false -> no picking'

And yeah the different behavior you get with a trigger was a little weird to me. But I think I get the reasonning behind it.

Should it work differently?... I don't know yet, I'll think about it while using it more often (I still have the habits to emulate or with local variables hehe)

And yeah it's a little confusing, so if I manage to come up with an idea to make it less confusing I'll let you know, although I guess you already put a lot of thinking into it

The thing that bothers me in this is: in any other case text would display the first instance, or its explicitly referenced index regardless of initial picking, so long as a trigger that allows the sub event to fire is true.

While it may not be ideal, I do see that someone might want to set things up like that. Like enemy is off screen, or timer is less than 10, set text to player .x, etc.

... However, 'Sprite is not visible' is still run, and results in no Sprite instances being picked because none meet the conditions. When no objects are picked its expressions return 0.on't know, this seems like going against a basic rule of the event system, that any action that refers to an object with no picked instances in the sol will refer to the first instance of it.

Like Yann I would expect to be returned the coordinates of the first instance instead of 0, since no instances of the object were picked. I would expect 0 if there was no instances of the object in the layout.

The rule isn't exactly that: the rule is if an object type is not referenced (no conditions even mention it) then it stays in "all picked" mode, and expressions return for the first instance.

If you add a condition in an OR block that no instances meet, it is referenced, so the rule does not apply. And it results in no instances picked, so there are 0 picked instances, and therefore nothing to get expressions from.

It is a bit confusing, but the event system is working normally here (as far as I can tell). The question is should it work differently for this case, and if so how and why?

I think the answer is what ever is more beneficial.

Returning zero has none that I can think of.

However if changing it will break something else, and if this is the only case where that kicks in, then ehh its not worth changing.

I've been running into some issues with the OR Block.

I keep going to use it like a traditional OR statement to save time from creating duplicate action events with different condition triggers.

Is it possible that the current OR Block be renamed to Conditional OR Block

and then have a traditional OR statement added to the program that functions as a normal OR statement please.