Destroy object doesn't work on OR block

[quote:g80nv72s]0 Red objects are picked because 0 Red objects are outside the layout, so 0 Red objects are destroyed.

I think you're right. That's why the red object is not destroyed. As well as we expect that only one black bar is destroyed when we click on it.

It's not a bug, it's just a feature.

Thanks a lot.

[attachment=0:2wigo1ry][/attachment:2wigo1ry]

Hmmm I'm still having a logic dilemma.

In other words, if an event doesn't reference an object in its conditions, actions apply to all the instances of that object.

My understanding is that the if ORblock is true, because one condition is met (blue circle outside layout), so all actions will run regardless, the "true" condition of blue will pick the blue met with true condition, then the red will.....mess...with...my...head.. again....

This is either still a bug or the manual needs updating. I guess using customized picking all the time should be the safe route.

DuckfaceNinja

The OR blockhas two conditions : Blue is outside layout, red is outside layout, one needs indeed to be true for the action to occur, however, when it occurs, it will pick the objects that meet the whole condition(the blue outside of the layout, and the red outside of the layout), since there are no red outside, none are destroyed, basically, everyone is picked unless a picking is done in the conditions.

If the"Red is outside of layout" was not there, red instances would not be filtered by it, and so all would be picked, and so destroyed.

If you want your code to behave as desired, just put a sub-event that picks all red and blue objects, under the 'or' block. It's also why the 'function' solution worked, because in a new event, all objects are again picked.

The example in this report is working correctly. I believe there is merely confusion about how OR blocks work.

OR blocks are unusual in that they are allowed to run with zero instances picked for an object type. In a normal event, the event would be false and not run in that case. Your event looks like this:

Red: is outside layout

• or -

Blue: is outside layout

There is a red object inside the layout, and a blue object outside the layout. The event is run as such:

Red: is outside layout? Zero instances meet this condition. However since this is an OR block, a later condition may be true, so we keep running it; however 'Red' has zero instances picked (which is unusual but perfectly allowed/correct in this case).

Blue: is outside layout? One instance meets this condition, so we have determined that the actions will indeed run.

Now we run the following actions. Remember that as per usual, actions only run on instances that were picked by the event's conditions, and that the actions only affect the specific instances meeting the event.

Red: destroy - there are zero red instances picked, so this does nothing.

Blue: destroy - destroys the blue instance picked by 'Is outside layout', since it's outside the layout

I guess it's possibly confusing, but it is in fact completely logical. No 'Red' instances are outside the layout, so no 'Red' instances are destroyed. If the Red object was actually destroyed, that would be quite a counterintuitive result: the action ran on an instance which did not meet the event condition.

Closing as not a bug!

Ashley, would be great if this example is included in the manual, I'm a go-to-manual kind of person and I'm sure there are lot of people like me especially ones with no-programming background.

Perspective from a non-coder:

Based on what I read in the OR block excerpt, the explanation sets my mind to think/assume that OR block behave like a "boolean" block which disregard false condition. As long as the block is true, all event will run. As an engineer, this is how we normally perceive the OR (things we do in CAD parametric control), which is different from programming it seems.

Ok now, the misconception is already recognized from statement above which is untrue/incorrect.

So, what is missing from manual?

An explanation for picking situation in OR block, which should be emphasized under the OR block excerpt.

Thanks for the explanation, now I know how to rebuild my conceptual understanding on it, which previously causing mayhem in my events (all repaired now), as the main reason I posted the "sad panda" link in my signature below, because I don't have a clue what is wrong at all.

Officially I have regain my sanity and cuteness, couldn't be happier than this

The statement is correct, the event run, on all selected (0) instances, but it runs

The statement is correct, the event run, on all selected (0) instances, but it runs

Oh the explanation actually is in CAD environment mindset actually, which picking feature doesn't exist. Maybe it's too general when I say perspective from non-coder? Let me think on how to rephrase that.

Edit: It's hard to rephrase, so I'll just say the actually difference is on how the OR blocks (in CAD we call it OR GroupSets) which the GroupSets is evaluated as single entity to determine true/false?true then proceed:false do nothing.

Origin of the mindset.

It's worth mentioning in the manual, yeah. I've added this paragraph to how events work:

[quote:3ku4nwdn]Note that because OR blocks run if any condition is true, it's possible the event will still run if some conditions were false and did not pick any instances. In this case the actions will still run, but possibly with zero instances picked for any objects where no instances met the condition. If any actions are run for objects with no instances picked, nothing happens.