wait next tick

Hey there,

I just had this simple idea.

It's ver well know, now that when we have a newly created or destroyed object, we need to wait for the next tick to access them.

For instance when we use functions a lot even when the function is called in the created block, the newly created object won't be visible.

My usual work around is to put a wait 0 seconds

But it's not really intuitive. And at some point, nothing insure that this behavior will be kept in future versions (since it's more like a hack). Maybe in the future, the implementation of wait will be changed and wait 0 seconds will trigger instantly... who knows?... and why should we care about internal implementation? (:

So maybe an action dedicated for just that situation, like a "Wait next tick" OR "trigger next tick" action would be better (although "triger next tick" looks more like a condition)

What do you think Ashley ? (:

Created objects are accessible after the next top-level event - you don't really need to wait a full tick. But I guess the easiest workaround is to wait a tick.

Wait 0 seconds is actually deliberately designed to postpone until the end of the current run of events (not even the next tick - the same tick, but after all other events). This is intentional and I won't change it since it will break useful things such as this! So I think it's fine to keep using "Wait 0 seconds" like that.

oh , good ! I was lookin' for this one for a long time ... Meaning , no wait 1 tick Ashley ?

Ashley

Yeah I know about the next top level thingy, but that makes a capx look a bit harder to read when you do that:

on left click
  -> create object
on left click
  -> function call "checkThings"

on right click on object
  -> destroy object
on right click on object // should that trigger by the way?
  -> function call "checkThings"

on left click
  -> create object
  -> next tick
  -> function call "checkThings"

on right click on object
  -> destroy object
  -> next tick
  -> function call "checkThings"

I've been thinking about this "top level delayed picking" for some time and I like the idea Yann is proposing. If calling it Pick Created Instances (or similar) it would be clear in the code what's going on: 'I now discard any previous pickings and continue to configure the newly created'

Created objects are accessible after the next top-level event

Mother. Of. God. Is this documented anywhere?

I've been trying to figure out what's wrong for, like, days. I accidentally figured that "Wait 0 seconds" solves the problem but I didn't know why.

Thanks. I guess.

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?

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 pining 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?

I use it when I need to evaluate all objects with a function after they are created.

For example I have a radar minimap made with a tilemap. In order to drawn enemy positions on the minimap I have a function, the function uses for each enemy set tile at x = radar.positiontotilex(enemy.x) and y = radar.positiontotilex(enemy.y) to a tile representing an enemy. Since it is not necessary to refresh the radar map every tick (for each is fairly expensive CPU utilization-wise), I only call the radar refreshing function when needed.

That is to say it the bare minimum when it needs to be called is when an entity that can move changes its current location to another tile or when new enemies are created. But if I call it without wait 0 after creating new enemies those new enemies will not show up on the map.

Of course there are workarounds which would achieve the same thing for this example, but they all would require adding more new actions than just "wait 0, call function". Less events is better if the performance penalty is not material (less to change/debug if you decide to revise something). Sometimes it is a matter of convenience, there are probably a few cases where it is absolutely necessary and cannot be achieved otherwise. But to be honest nothing comes to my mind at the moment.

Another use is if you want to make buttons with sprites that have different frames/animation when they are pressed. You can do the pressed/unpressed change in one event:

conditions

mouse over object, left mouse button down

actions

set frame 1 (pressed)

wait 0

set frame 0 (unpressed)

The effect is that once the mouse stops being over the button sprite it will revert to the previous state by itself. However if the mouse is still over the button, the frame 0 will be changed to frame 1 anyway and the user will not see it has changed. No need to check if it was pressed but the mouse is no longer over it.

Ok, good explanation, I get it.

Thanks for taking the time.

Sure shows the flexibility of C2/3.

That second example is very interesting and seemingly efficient.

I tend towards dividing code into small chunks and using functions where possible, which is probably why I haven't had the need to use wait 0.

Cheers.

The Timer behavior also works well, and can be used instead of functions.

However, just like functions it's not great for multiple instances being triggered at the same time with the same call/ tag.

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.

As long as I understood and figured from numerous experiments, you sure can change instance variables, positions and pin stuff to Objects you've just created. Even in subsequent events or sub events. What you can NOT do in subsequent events or sub events is pick form those objects you've just created. Not by «Pick...» actions, nor by conditions, like, "If Object is visible...".