Sending UID makes the function work, otherwise, no -- why?

I'm trying to understand some complex (and to me, kinda random) issues I constantly run into.

For example in this code, I was aware that sending the UID, on a sprite creation, can avoid using Wait 0.

But WHY?

It's like sending the UID makes the function wait, until that UID is available or something.

Any clues?

If you are referring to sprite creation why have you blurred out the important events? When you create an instance yes you need to wait until next tick for it to be available.

If you are referring to sprite creation why have you blurred out the important events? When you create an instance yes you need to wait until next tick for it to be available.

The blurred events aren't important. Wait 0 is not needed, as I explained in my post.

The why has to do with when new objects are pickable. Basically new objects aren’t added to the list of objects till an event ends and the next event is a top level event. A top level event just means it’s not a sub event of another event, but it can be in a group. Search for “top level event” for other attempts to describe this behavior.

Wait 0 will delay things being run till the end of the event sheet so the new objects will be added to the object list by then.

Now pick by uid is a special case. If you created an object you can pick it at any point.

EDIT: wait sorry, I may have misunderstood your original issue. I tend to use "wait 0" often and tends to behave correctly. I never risk a newly created object without using "wait 0", but perhaps there are specific times where this is OK. When is the 2nd function without a UID parameter called? If there's multiple of that one object, and no UID is specified, perhaps C3 is picking whatever first instance of that object that exists, then picking it's children and such.

EDIT 2: oh wait, I just understood the colour-coded purple shows the 2nd function being called. From what I understand, if the 2nd function doesn't have "copy picked" or a UID to pass, then the 2nd function effectively "doesn't know" which instance to pick, so I guess unexpected behaviour happens. I'd always pass a UID just to be crystal clear for C3 to know which instance to pick (or copy picked if that works after a "wait 0").

I always use "wait 0" on a "on created" event. Like every object that gets created, I have an "initialise" function or custom action for that object, but it seems that "wait 0" is always needed before calling the function.

I think it's related to the whole "objects don't necessarily exist until the bottom of the event sheet/next tick" or something similar to this, so a "wait 0" solves this.

Doesn't seem to cause issues as far as I am aware, even if multiple objects are created on the same tick and such. But yeah, hmm.

Yes, sorry about the coloring, Photoshop tricked me to add the same color to the text in both places, making it a bit more confusing.

Thank you for your reply. I run into this issue a lot, and I try to avoid using Wait 0 because it causes assets to flicker (eg.: i create the body, and then wait 0, and then the eyes—you will notice how the eyes get created slightly later; or if I need to replace something, again using Wait 0 will cause a flicker.)

I think it's related to the whole "objects don't necessarily exist until the bottom of the event sheet/next tick" or something similar to this, so a "wait 0" solves this.

Yes but you see, one function picks it in the same tick, the other doesn't.

The why has to do with when new objects are pickable. Basically new objects aren’t added to the list of objects till an event ends and the next event is a top level event. A top level event just means it’s not a sub event of another event, but it can be in a group. Search for “top level event” for other attempts to describe this behavior.

Wait 0 will delay things being run till the end of the event sheet so the new objects will be added to the object list by then.

Now pick by uid is a special case. If you created an object you can pick it at any point.

Thank you for the detailed explanation.

The top level event doesn't seem to apply here, unless I misunderstand it, in which case please correct me.

I just use the same blocks:

1. one in a function where I pass the UID beforehand by going through all the children of type Tattoo, and that works.

2. one in a function where inside the function I go through all the children of type Tattoo, missing out on the UID, and that doesn't work.

So when the UID is passed, somehow... it works, and the object is picked beforehand in the loop of that function call.

Sorry if I don't understand still, it seems like code in one place works, but in another, it doesn't.

As — kindly answered:

"I cannot reproduce it, works for me either way

wait, no it's weird for me as well

seems like pick children only works for newly created instances if that instance is specifically picked in that event

so it doesn't seem to be part of the picked instance if you don't reference any instance of that object type

for example this event works with copy picked or as a custom action as well without a wait 0"

Related to this bug I've reported, which is shows much simpler code: github.com/Scirra/Construct-bugs/issues/7184

The pick children could have a different behavior. I haven’t tried using that yet though. Anytime there’s events surrounding creating objects this sort of thing comes up one way or another. A bug report could be valid since there was more complexity added for the children feature.

Most of the events I write work around when new objects can be picked. It is a rough aspect of the system. The picking system works great when all the objects already are created. It also works well when all you’re doing is modifying some object just created. Beyond that I tend to try a two pass method like create all the objects I need in one event then in a second event pick things again. The wait 0 can work but it makes it harder for me since I often require things to be done in a certain order.

At one brief point the new objects were added to the object list once created. However that was changed to fix cases where infinite loops were being caused with some events. It’s an interesting design process to try to come up with a different way to handle the picking in a robust reliable way, but I know I haven’t come up with anything I’ve liked. Overall I’ve found the event system to be more complex and nuanced over time so I try to use a simple subset of it that I know the precise behavior of.

The pick children could have a different behavior. I haven’t tried using that yet though. Anytime there’s events surrounding creating objects this sort of thing comes up one way or another. A bug report could be valid since there was more complexity added for the children feature.

Most of the events I write work around when new objects can be picked. It is a rough aspect of the system. The picking system works great when all the objects already are created. It also works well when all you’re doing is modifying some object just created. Beyond that I tend to try a two pass method like create all the objects I need in one event then in a second event pick things again. The wait 0 can work but it makes it harder for me since I often require things to be done in a certain order.

At one brief point the new objects were added to the object list once created. However that was changed to fix cases where infinite loops were being caused with some events. It’s an interesting design process to try to come up with a different way to handle the picking in a robust reliable way, but I know I haven’t come up with anything I’ve liked. Overall I’ve found the event system to be more complex and nuanced over time so I try to use a simple subset of it that I know the precise behavior of.

Thank you very much for the detailed reply. Very interesting to hear your take on this. Sounds similar to coding nodejs apps actually, where newer js "eye candy" can cause performance issues.

Regarding Construct, at some point I started creating my objects outside the layout, very far -10000, -10000. I added the Waits required, or used very short timers, and then once everything was initialized I moved them to the proper position.

It was quite a hassle however to take care that everything finished initializing and there was a lot of back and forth checking and assigning "IsInitialized" variables.

This was the most stable way for me for a while to do things.

Whatever works I guess. I don’t use waits. Most I’ve done is wait till the next frame to work around a physics behavior quirk.

Typically the way picking works with newly created objects is fine, although you may need to approach the problem from another angle.

Even in complex picking involving newly created objects you can do it in the same tick, with two events, one to create, and one to pick.

Also in the interest to make things simpler I’ve also tried keeping track of the uids somewhere to be able to use the pick by uid condition.

Sounds like the there’s a bug/quirk/oversight or nuance involved with hierarchy in your case though.

Keep track of the UIDS? Interesting... as in an array or a dictionary?

Before the hierarchy I was adding all the attached "child" sprites of a main sprite as instance vars

UID_Hand_Left

UID_Hand_Right

etc...

Now i'm checking the hierarchy for children, which is more intense performance-wise but less hassle in order to code faster :/