Picking problem

I'm having a problem with picking. I have an event in which I'm randomly generating a level. There are multiple sub-events and loops. As a final sub-event, I want to change some properties of all objects that were created in the event. Unfortunately, the Construct selection list appears to have filtered out all objects, so the last actions have no effect.

In the referenced CAP file, you can see how I'm creating some sprites and then trying to change them all at the end. The only sprite affected by the changes is the one created in the top-level event. Changing the last sub-event to a foreach loop doesn't work, either.

What can I do to fix this, aside from duplicating the last event in all the individual places where I'm creating a sprite?

http://dl.dropbox.com/u/18659416/picking%20problem.cap

When you create an object it becomes the only picked object for the remainder of that event. After that the object cannot be picked until the next tick (or frame).

A way around it is to do the actions on the next tick, or in our case tick 1.

 +  System:  TickCount  Equal  to  1  
->  Sprite:  Rotate  90  degrees  clockwise  
->  Sprite:  Set  filter  to  Red  
[/code:2zpv0m47]  
 
[url]http://dl.dropbox.com/u/5426011/fixed/ex_pick.cap[/url] 

When you create an object it becomes the only picked object for the remainder of that event. After that the object cannot be picked until the next tick (or frame).

Is this accurate? I thought it was like this:

The way it is, though, is that when you create an object, it doesn't really exist until the end of the next top level event or trigger.

When you create an object it becomes the only picked object for the remainder of that event.

In this context, does event mean the top-level event, or does it also include sub-events?

After that the object cannot be picked until the next tick (or frame).

It sounds like this makes what I want to do fundamentally impossible. You simply can't create a bunch of objects in subevents, and pick them all in another subevent later on.

A way around it is to do the actions on the next tick, or in our case tick 1.

That sounds like a reasonable solution. I'll try it out.

> When you create an object it becomes the only picked object for the remainder of that event. After that the object cannot be picked until the next tick (or frame).

>

Is this accurate? I thought it was like this:

> The way it is, though, is that when you create an object, it doesn't really exist until the end of the next top level event or trigger.

>

From my experience, it seems to be like ROJOhound says. You can't, for example, access a pv of a newly created sprite until the next tick. I still think, the object is created at the end of the tick, and all you do in the creation event is just buffered.

>

> > When you create an object it becomes the only picked object for the remainder of that event. After that the object cannot be picked until the next tick (or frame).

> >

>

> Is this accurate? I thought it was like this:

>

>

> > The way it is, though, is that when you create an object, it doesn't really exist until the end of the next top level event or trigger.

> >

>

From my experience, it seems to be like ROJOhound says. You can't, for example, access a pv of a newly created sprite until the next tick. I still think, the object is created at the end of the tick, and all you do in the creation event is just buffered.

I do think Ashley said what he said for a reason. Look at this overly simplistic example:

http://dl.dropbox.com/u/2306601/blinky.cap

When you press X, a Sprite is being created at the center of the screen. But with the current event order, you won't see anything. It's immediately being destroyed by the second event. However if you switch the event order, the sprite briefly appears before being destroyed. Which means it already existed and could be picked before the next tick - according to my very own logic. Otherwise it shouldn't have blinked when you switch the order. Unless something is going on I'm not getting, which is always a good chance. Still Ashley said what he said!

You can get around this by using a function. Functions are able to make condition checks on newly created objects if called in the same event after the object is created (using remember picked objects - that's important!). Also note if you create two instances of the same object in one event, the first created instance will be deselected upon the creation of the second instance.

Also, PR, what Ashley said is correct. It was changed from what R0J0hound described some versions ago.

Hey cool,

Thanks PixelRebirth, I was not aware that created objects could be picked in the next toplevel event. That will make my eventing easier than waiting till the next tick. My assumption came by trial and error, but obviously I didn't try everything.

So here's a better solution to the initial problem:

Instead of rotating the objects the next tick, just add another toplevel "Start of Layout" event.

http://dl.dropbox.com/u/5426011/fixed/ex_pick2.cap

Cheers

I do think Ashley said what he said for a reason. Look at this overly simplistic example:

http://dl.dropbox.com/u/2306601/blinky.cap

When you press X, a Sprite is being created at the center of the screen. But with the current event order, you won't see anything. It's immediately being destroyed by the second event. However if you switch the event order, the sprite briefly appears before being destroyed. Which means it already existed and could be picked before the next tick - according to my very own logic. Otherwise it shouldn't have blinked when you switch the order. Unless something is going on I'm not getting, which is always a good chance. Still Ashley said what he said!

Thanks for the example

I understand the logic and agree with the creation. But, well, why can't I access a pv then until the next tick? Doesn't make sense.

EDIT: All the top level and subevent explanations, they don't make sense. I was following your logic (that I feel is correct, if I can see the object it must exist) and played around. Now look at this example . The sprite is created in a subevent and immediatly exists - but the pv is not accessible. I get a headache

[quote:gkcmx6ur]But, well, why can't I access a pv then until the next tick? Doesn't make sense.

You can, if the action is associated with the object.

You can do that if its within that particular top tier event, or its subevent.

Note a top tier event doesn't necessarily have to be the first event.

A top tier event can be a condition's sub event.

Its basically the same as the first event if its not associated with a preceding event.

Does that make sense?

[quote:3258oobi]But, well, why can't I access a pv then until the next tick? Doesn't make sense.

You can, if the action is associated with the object.

You can do that if its within that particular top tier event, or its subevent.

Note a top tier event doesn't necessarily have to be the first event.

A top tier event can be a condition's sub event.

Its basically the same as the first event if its not associated with a preceding event.

Does that make sense?

newt, did you try my example? Because all you say is tested in my example and it does NOT work.

I, too, know what I am saying, although it seems to be ignored...

I know what its like to be ignored, but its worse to be misunderstood.

http://dl.dropbox.com/u/666516/pvsubsubevent.cap

In an effort to nail down the rules:

1. When an object is created it becomes the only picked object of that type for the actions below it and in sub-events of the event the object was created in.

2. The new object can't be picked in the following events with the same nesting level as the event it was created in (unless it was created in a top level event).

3. Once a new toplevel event is reached the new object can be picked like normal.

To illustrate:

https://www.dropbox.com/s/rik6uta4kuojf ... g.GIF?dl=0

Thanks for the picture R0J0, that sums it up nicely. For the record, it used to be that it wouldn't be pickable until the next tick - a fix a few versions ago made it the next top level event, but due to the design of the engine, it's very tricky to make it available in subevents (where Destroy is in your diagram).