How events work / destroying / SOL

Just recently I encountered a strange situation. Although I think there is no bug here, I thought I'd share this so perhaps others can get a better understanding of this event system.

Have a look at this simple capx

On the event sheet there is a disabled action (system wait 0 seconds) which makes a big difference on the outcome, even if on a quick look, it shouldn't matter.

<img src="http://img515.imageshack.us/img515/2079/eventsol.jpg" border="0">

First of all, all "enemies" are destroyed. Then, in a subevent, the enemies are counted.

Turns out that if you leave the wait enabled, the subevent won't find any enemies.

But if you disable the wait, the subevent will actually find the enemies, even though the parent event destroyed them.

This SOL thing is starting to make sense now, even though it can get funny in situations like the above.

The Wait tutorial says:

"The Wait action saves the state of the entire SOL and cancels the current event. When the wait time has expired, the entire SOL as it was is restored (minus any objects that got destroyed), and the event is resumed from the action following the wait action."

So it mentions explicitly that the SOL minus the destroyed objects gets restored. But I wonder, should the SOL be updated on the fly when the destroy occurs? Because it gets weird in situations like the above.

As I said, I think there is no bug here, i.e. things work as they were designed to. But I'm wondering, wouldn't it be more intuitive to update the SOL on the fly when the objects get destroyed, so that the wait action in the example wouldn't make any difference?

Well, first of all this is a pretty convoluted way of re-creating the sprEnemy.Count expression! :)

However, note you 'Destroy' the instances then try to count them. You're taking advantage of a quirk where Construct 2 does not really destroy objects until the end of the tick, so without the 'Wait' action it can count them correctly.

Also note from the Wait tutorial:

ne more trick: "Wait 0 seconds" postpones the following actions until the end of the event sheet.

So if you add "Wait 0 seconds", it does not ignore the condition - it will postpone the subevents to run at the end of the tick... after Construct 2 has done it's end-of-tick actual destroy of objects. So there are no objects left.

Yeah, works as expected, the sol gets updated on the next tick. However, wait set to zero is a bit conspicuous, as in theory, it should be the same as no wait action at all. That part may actually be a bug. The question is should it be changed, as it's a "feature" that's somewhat exploitable.

Also as to updating the sol, I find it more advantageous to have to sol updated with another event, especially since you can place the destroy anywhere in the event.

BTW If all that is still too confusing, try using the on destroy condition. Picked is remembered, including variables, and state.

Thanks Ashley and newt for the comments.

I knew about the wait 0 trick, i.e. that it postpones until the end of event sheet. That's how I got my game to work. I didn't know about the .Count though <img src="smileys/smiley23.gif" border="0" align="middle" />, it will make my job easier, thanks.

HOWEVER: you say that the wait 0 will postpone until the end of the event sheet, and that the destroy gets the sprites destroyed at the end of the tick.

Does this mean that the triggered actions (touch->on touched object) are run "on their own tick"?

Is this sequence correct, or does #5 occur before #4? (in practice it does)

0. First, Touch->Touched object is fired

1. Then "Destroy" marks all sprites for destruction.

2. Then comes wait(0) which postpones further actions until end of event sheet (according to manual)

3. Then comes end of event sheet

4. Then action continues after the wait (sprite counting)(as per the manual action continues here)

5. Then comes end of tick (sprite destruction)

#5 must come before #4 because otherwise your example would work!

'Wait 0 seconds' postponing to the end of the tick is by design, I thought if you wanted to wait no time at all you'd just delete the action! :) Sometimes it's handy to have an action in the same event postponed to the end of the tick so the other events get to run - I thought it would be useful for that.

I seem to recall it was changed in construct classic from fully creating and destroying objects at the end of the tick to at the beginning of the next base event. If I'm remembering that correctly, why did you go back to the end of tick method for C2? I think fully creating or destroying them at the next base event is preferable.

Ashley, exactly <img src="smileys/smiley1.gif" border="0" align="middle" />, then it means there's a "bug" in the documentation. The documentation says:

• Wait(0) postpones until the end of the event sheet
• Sprites get destroyed at the end of the tick

In practice:

• Sprites get destroyed before the Wait(0) resumes

Conclusion:

• The end of the tick occurs before the end of the event sheet.

The conclusion seems weird <img src="smileys/smiley1.gif" border="0" align="middle" />, I think the documentation is at least unclear (borderline wrong).

You are right, the Wait(0) trick (which I have a feeling is more of a side effect of the design, not something implemented on purpose <img src="smileys/smiley4.gif" border="0" align="middle" />) is useful and I hope you won't change it.

I agree there should have a clear document to explain SOL.

Geo

You might try Instance Group, maintain SOL manually.

<img src="smileys/smiley4.gif" border="0" align="middle" /> Thanks rexrainbow, for now everything is working as I want it to in my game, perhaps for the next I'll check it out, as I have a few ideas where it might be useful.