Someone plz explain this to me.

Situation 1. This is obvious not working. I do not need an explanation about this one:

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

Situation 2. This is working:

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

I feel like it should not. So why is it working ? Because this creates possibilities and opens a world of new options. But why ? And can i trust that it will work after the next update ?

Schrodinger's Sprite.

It both exists, and does not exist inside of the box/event/tick.

Keep in mind, objects created are picked, until the next higher tier event.

99Instances2Go

like newt said, "objects created are picked, until the next higher tier event"

In your first example the destroy line is outside the scope of the event that creates the sprite (and the new sprite does not officially exist until the next top level event - as I think you know). But in your second example, the action is still within the scope because it is part of a sub event under the one that created the sprite. The new sprite will stay Picked until all sub events are finished, or something else changes the picking. like a condition that does not apply to the new sprite, or if you have a sub event that does a system --> pick All Sprite2, (then all other existing instances will be picked except the new one - because it does not officially exist yet).

another useful thing to know is that you can pass the UID of the new sprite into a function. The function can pick the object by its UID and do whatever you want to it even though the next top level event has not happened yet.

Schrodinger's Sprite.

It both exists, and does not exist inside of the box/event/tick.

Keep in mind, objects created are picked, until the next higher tier event.

Yeah, but you cant peek in the box until the next root. Unless you entangle it with UID.

Yet, that is what happens in the second version.

AllanR

I know all that. If you ever read my comments, you know i do.

It should not matter that it stays 'picked' as you call it. Or, that it stays in the current picklist.

Because it is 'repicked', and that condition should not work.

As you word it "If ... pick All Sprite2, (then all other existing instances will be picked except the new one - because it does not officially exist yet)."

The second one works because the created object is still picked in sub-events.

So each 'level' (parent-sub-sub-sub ....) has its personal 'level' picklist ?

The concrete problem is this. I was reading the events in the project in this post.

I wanted to explain that the logic for the events with parent event 99 is broken because of that "you cant pick a newly created object before the next root event ". But, then it struck me that all the key press events work with no flaws.

So, now, what i used to say "you cant pick a newly created object before the next root event" makes no sense anymore. It does not include 'situation 2' in openings post in a non brain wrecking way.

So what i need is a rephrase of "you cant pick a newly created object before the next root event" so it includes both situations.

Yes, I guess you could say that. If something is picked it stays picked for the rest of that event and following sub-events unless another event unpicks it. Do some tests that change the frame or opacity of the objects to get a visual to understand it better.

In that capx event 99 is a trigger that is called when an object is created, and that object is picked and any parent events are tested first. So it's probably some logic error rather than some quirk of the event system.

Event 99 is a 'on creation' trigger that runs 'in place' (of the creation action) and tries to pick before the next root event. The wait in there tried to fix that in a wrong way. Use opacity and kill the (wrongly placed) wait to understand that event.

You can create an instance, change any of its values, then create another instance, and change any of its values, all in the same tier.

WRT to the first "not working" one.

You are not pick/ using anything at the click trigger event

C2 goes on to process the two individual sub events of the click trigger "at the same time" so

At point of first click trigger no sprites exist atop of the blue box and at the "same time" you are creating a sprite (but there are no sub events to use it as picked)

Sprites will be destroyed over the blue box on second and subsequent clicks but there will always be a sprite that is not destroyed as it is also created at the click trigger and never pick/used for anything.

On the second "working" one, at the click-trigger, the sprite is created so picked for use in sub events and then destroyed in the sub event. I am using these sort of events all over my game.

I don't see any issues,,, and am very glad to see C2 working like this it means that it is very robust and is treating trigger events properly...

Quoted :

Just for my own understanding... (because I keep seeing this subject pop up and I never understand it)

I am quite deep into my project,

must be 600 events in total now,

In game I am creating dozens of enemies and in subsequent events or sub events I am changing their instance variables, positions and pinning stuff to them etc at the point of creation. and as far as I can see everything is working well and smoothly. I have never ever needed to use wait 0 seconds for a anything, I don't even know why or when I would need to use it, it sounds like a hack, could someone enlighten me?

99Instances2Go

it's ok man, I hold no pride in this forum, im here to learn (and help if I can)...

so please continue....

your point being...? ...that you can use wait 0 between the sub events in your first example to make it "work" ?

Hey guys,

I posted a question about this particular topic a few days ago, and got fully replied. With additional search I now understand this tricky thing.

You can read the post here :

Though Ashley's visual explanation is probably the only thing you need. Couldn't be clearer.

I hope it helps.