Picking problem

I think this is about the first time this has been addressed, at least in this detail, and its awesome.
While we have your attention Ashley do you think C2 could be designed at least as far as the gui goes to show whats going on?
For example, conditions, and actions get muddied up a bit when we start to think of it as an event, instead of its separate parts.
If we could have a different numbering system, where all conditions, actions..."sub- conditions?", and "sub- actions" were given their own title, like:
(1) condition| (1a) action
-(1s1) sub condition| (1as1) sub action
(2) condition| (2a) action
-(2s1) sub condition| (2as1) sub action
-(2s1) sub condition| (2as1) sub action
--(2s2) sub condition| (2as2) sub action
.......ehh ok that might be a bit much, but perhaps a graduated color scheme for subevents, and at least some kind of marker for the first top level event of each new event.

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:

http://dl.dropbox.com/u/5426011/fixed/C ... icking.cap

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

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

[quote="PixelRebirth":3v5zn9nb]
I do think Ashley said what he said for a reason. Look at this overly simplistic example:

[url:3v5zn9nb]http://dl.dropbox.com/u/2306601/blinky.cap[/url:3v5zn9nb]

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! [/quote:3v5zn9nb]
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

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.

[url:1o9bv4sz]http://dl.dropbox.com/u/5426011/fixed/ex_pick2.cap[/url:1o9bv4sz]

Cheers