@Ashley Would it be possible to request a new type of top level event related to creation of objects that allows for picking? It would just be neat and allow an easy pedagogical way instead of figuring out workarounds or filing bugs. For a layman without any deeper understanding of the current event design it just doesn't make sense, and I bet not only me wasted countless of hours trying to figure out why it doesn't pick as 'In my mind' the objects should have been picked. I think people stumbling across this odd behaviour will continue to file this as a bug in the future as well.

First time I encountered this problem I instinctively went directly for the "on created" condition, and then functions as my first try to find a solution but this didn't help, so it had me scratching my head why, and joining the discussion here. Would there be any drawbacks to changing the "On created" condition to be a pure top level event?

tunepunk wrote:Would it be possible to request a new type of top level event related to creation of objects that allows for picking? Would there be any drawbacks to changing the "On created" condition to be a pure top level event?

No, this does not solve the underlying problem. The engine cannot support potentially modifying the instance lists while it is using them, and so there can neither be a new kind of event, nor a special kind of trigger, that works around this.

@Ashley , if I understand correctly, the reason we can't pick newly created objects within nested subevents is because loops would attempt to reference indices that don't exist within the instance list (because the new objects aren't merged with it until top-level event)?And if you wanted to reference an instance that isn't in the instance list, there'd need to be a way to know that it is in the new object list instead- and this is an engineering issue that would require a lot of work?

Edit: couldn't you give new objects a "would-be" index number, that corresponds to what their index would be when they get added to the instance list. And then when checking instance list, cycle through the would-be indices- if they are greater than the instance list length, then check the new object list instead?

"When you develop intricate processes that aren't just simple events like these examples, the order of every single step through the process matters- you can't afford to break away and assume it will work with everything else."

What if a user destroys that object in the same event? What if a user destroys some other instance in the same event?What if it's created from a family? What if a user creates yet another instance in a subevent?

newt wrote:"When you develop intricate processes that aren't just simple events like these examples, the order of every single step through the process matters- you can't afford to break away and assume it will work with everything else."

What if a user destroys that object in the same event? What if a user destroys some other instance in the same event?What if it's created from a family? What if a user creates yet another instance in a subevent?

If everything was accounted for, and objects that should be considered created are created and objects considered to be destroyed are destroyed, then that would be no problem. The logic would follow a consistent pattern and you would easily make sense of the events.

They do.The logic is pick something, or somethings, and do something, or things to those objects.Not and some other objects that weren't picked.Picking at creation is a special case meant to make things easier, trying to exploit that even more is the issue.