Pick All / Create Bug

— Sorry i did not believe you. **Bows** . You stand correct. Although i did't get that there is a function involved.

But it is even weirder then i expected when testing this. The newly created object is in fact in the family.

Pick by UID can find it.

Any other pick condition can not find it. Look:

https://www.dropbox.com/s/mnwajr51uje7y ... .capx?dl=0

Luckily the solution is easy.

https://www.dropbox.com/s/znyj6ajfyprjf ... .capx?dl=0

I never noticed this before. So, now i have a new rule, but i dont know how to formulate it.

Newly created members of a family are pickable in the next top-event, but not in a function. Kinda.

You have to rewrite this though. The formulating of this report is wrong. It only happens in a function call.

99Instances2Go Yes, and also if the next top event is 'on created' picking doesn't work either. It's very weird. Seems like 'On Created' doesn't count as a top event either.

Since 'pick instance by UID' works, I wonder if it can handle a string of multiple UID's? I never tried that.

Since 'pick instance by UID' works, I wonder if it can handle a string of multiple UID's? I never tried that.

That would allow you to pick each individually, but you won't be able to use any actions that work on groups of picked objects, like z sorting. Z sorting requires more than one object to be picked if I understand correctly.

Also, Pick Nth Instance doesn't include new objects, even though you can Pick by UID.

There really ought to be a way to include new objects in picking so that there aren't these inconsistencies in the design of events, and also to reduce a need for extra variables and breaks in the flow of the events.

99Instances2Go Yes, and also if the next top event is 'on created' picking doesn't work either. It's very weird. Seems like 'On Created' doesn't count as a top event either.

Since 'pick instance by UID' works, I wonder if it can handle a string of multiple UID's? I never tried that.

If you use the family as target in the 'on created' finds both members in the family. It should only find 1, the newly created one.

https://www.dropbox.com/s/sj7m3p9s7940r ... .capx?dl=0

If you use sprite as the target, the family is unreferenced. So it should address all members, but it does not find the new one.

Makes, at this moment, no sense to me. But i gave you a good and pretty easy solution.

You can also make 2 function calls, i think.

1 with the UID of the new created one as param to pick it.

1 for all the others.

99Instances2Go I just figured out this workaround for functions. Might be useful in some cases.

Since pick instance by UID work in functions. This picks the newly created one, and by inverting also picks all other instances that does not have the UID.

Now i just need to figure out how to use them both in the same subevent, so they can share the same actions.

pick by uid can pick the new objects at any time. It is the exception to the rule.

Functions and "on created" are run as if they were placed where the object was created or where the function was called. So no, they are not top level. For example:

this:

+-------------------+
| on function "move"| sprite: set x to self.x+32
+-------------------+
+-------------------+
| on sprite created | sprite: set opacity to 50
| pick all sprite   |
+-------------------+
+-------------------+
| start of layout   | create sprite at (0,0)
|                   | call function "move"
+-------------------+[/code:rahmbimr] is the same as this:
[code:rahmbimr]+----------------------+
| start of layout      | create sprite at (0,0)
+----------------------+
   +-------------------+
   | pick all sprite   | sprite: set opacity to 50
   |                   | sprite: set x to self.x+32
   +-------------------+[/code:rahmbimr]

For the case of needing to do something to all the instances right after a new instance is created I usually use a   variable or a group that i set or enable when i need to do something.

global number zsort=0

sprite: on created
--- set zsort to 1

start of layout
--- create sprite at (10,10)

zsort=1
--- sprite: sort
--- set zsort to 0

R0J0hound Got it. It just doesn't seem like a natural way of doing things. Maybe a new condition like "After created" or revise the 'On created' would make some sense. For me at least, the natural thing would be to have On created to trigger after merge of lists as a proper top level event.

tunepunk

In my second example, i used a wait 0 before calling the function. This wil force the function 'out of place', but stil in the same tick. (at the end of the tick). For me, this is the solution.

..... "on created" are run as if they were placed where the object was created ...

There are 2 sides of a story here.

Story 1: The question is usaly: How/When do i pick my newly created object?

Answher: Use 'On Create".

I follow the explination given. And it seems very logical to me (now). But 'on create' is still an exeption on that explination. Even when it seems to run as 'in place', even if it therefor does not count as a new top level event, it picks its new created objece just fine. As i hope it is intend to do.

https://drive.google.com/open?id=0B1SSu ... m9zejd1VlE

It keeps working flawless when using a familie. I think it is safe to state that 'on creation' works perfectly to pick a newly created object. Althaught it does not meet the explination.

https://drive.google.com/open?id=0B1SSu ... jJwdGhEZWc

Story 2: The Question in this topic: How/When do i pick all objects, including that newly created object (all other picks are just filters starting from here) was completely new to me. And the explination fits for 100 %.

The reason why i write this, is because the explination seems to discourage the use of 'on creation'.

Closing as by design. This has come up a few times in the past and it's not feasible to change it.

The problem is the event system is nested, and internally the engine will be half-way through iterating the instances list while running various aspects of an event. Creating a new instance adds a new instance to the instances list, and destroying an instance removes it from the instances list. Modifying these lists while they are being iterated for running events causes bugs and crashes, because it's unpredictable to modify a list while you're simultaneously using it. A long while ago user's projects were crashing because of this problem, so we made this change intentionally to fix it. The end of top-level events are the only safe place to actually update the instances lists, because they are guaranteed to not be in use at that point. After top-level triggers also counts, but not functions (or other triggers fired from inside conditions/actions/expressions), because then you're still nested inside another event.

Note that creating works the same as destroying, i.e. a destroyed instance does not really stop existing until the next top-level event, although this tends to be less of a problem.

Working around this from within the engine would degrade performance for all projects, because it would mean every loop inside the engine that deals with instance lists has to have a per-iteration check to see if the instance list was changed while it was looping, and then do extra work to mitigate that. Not only does this slow down everything (particularly tight loops which do little work), it is also a very complex engineering project that would probably take months and involve a whole load of follow-on bugs and further corner cases that need fixing. I really don't see that as a reasonable thing to do when it will also degrade performance everywhere, just to fix a slightly weird corner case which is possible to work around, so this is not something I think we will ever change.

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?

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?

"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.