Pick All / Create Bug

Bugs will be moved here once resolved.

Post » Mon Jun 27, 2016 10:06 pm

@tunepunk. 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.
B
33
S
18
G
28
Posts: 2,493
Reputation: 20,950

Post » Mon Jun 27, 2016 10:46 pm

@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.
Follow my progress on Twitter
or in this thread Archer Devlog
B
40
S
17
G
17
Posts: 981
Reputation: 12,634

Post » Mon Jun 27, 2016 11:12 pm

tunepunk wrote: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.
B
45
S
21
G
65
Posts: 1,115
Reputation: 38,221

Post » Mon Jun 27, 2016 11:32 pm

tunepunk wrote:@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.
B
33
S
18
G
28
Posts: 2,493
Reputation: 20,950

Post » Mon Jun 27, 2016 11:43 pm

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

Image

Now i just need to figure out how to use them both in the same subevent, so they can share the same actions.
Follow my progress on Twitter
or in this thread Archer Devlog
B
40
S
17
G
17
Posts: 981
Reputation: 12,634

Post » Mon Jun 27, 2016 11:47 pm

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:
Code: Select all
+-------------------+
| 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"
+-------------------+
is the same as this:
Code: Select all
+----------------------+
| start of layout      | create sprite at (0,0)
+----------------------+
   +-------------------+
   | pick all sprite   | sprite: set opacity to 50
   |                   | sprite: set x to self.x+32
   +-------------------+


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
B
92
S
32
G
109
Posts: 5,290
Reputation: 70,991

Post » Tue Jun 28, 2016 12:37 am

@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.
Follow my progress on Twitter
or in this thread Archer Devlog
B
40
S
17
G
17
Posts: 981
Reputation: 12,634

Post » Tue Jun 28, 2016 11:20 am

@ 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.
B
33
S
18
G
28
Posts: 2,493
Reputation: 20,950

Post » Tue Jun 28, 2016 11:41 am

R0J0hound wrote: ..... "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'.
B
33
S
18
G
28
Posts: 2,493
Reputation: 20,950

Post » Tue Jun 28, 2016 12:14 pm

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.
Scirra Founder
B
397
S
236
G
88
Posts: 24,422
Reputation: 194,558

PreviousNext

Return to Closed bugs

Who is online

Users browsing this forum: NN81 and 2 guests