[r100] Interesting subevent problem

Take a look at this capx.

CAPX HERE.

The logic is very, very simple. The 'nodes' are created, then instantly destroyed.

Run the project, and they are not destroyed.

Same thing happens with a 'for each node - destroy' event.

I think it has something to do with the blank sub-events, as when you make the actions actions of the parent event, the behavior is different.

This impacts my current game significantly, I found this after a project working in r99 failed in r100.

Might have something to do with this:

Quote from the r 100 release notes

"Bug Fix

Sprite's 'Spawn an object' spawning the same kind of object could crash the runtime. To work around this, in this case the spawned object is no longer picked if the same type. (Behavior is unaffected if spawning a different kind of object.)"

Still, this seems like a nasty issue to leave in the program. Ashley, anything to say?

You just need to change your picking. If you move the destroy event underneath the spawn event in the top tier, it works.

Also, we do have an on create event.

That might be a little tricky to use if you need to spawn objects that don't need to be destroyed, but you can filter that via variables.

Is it a bug? The behavior was by design in CC:

http://www.scirra.com/forum/picking-problem_topic41776_post257714.html?KW=picking#257714

So is it a bug now or was it in r99, I happy either way as long as it is consistent.

The inconsistency is the real issue, I have to change a lot of my code now.

Also, the fact that it doesn't work even if there's a 'for each node - destroy' is strange to me.

—

Well it's go to be in the sol in order for "for each" to work.

So if those objects aren't picked in the initial condition, or referenced in a sub event to the event that created them then, they don't exist in the sol.

Remember you can filter "for each" to work with only the objects you want.

sprite.value picked = 1

for each sprite... do stuff.

There any sprite that didn't match the value in the variable, would not be iterated.

As far as I can tell picking is still consistent, as long as you don't use a sub event, or event that's not a sub event to the event that created it.

I think it can help: http://www.scirra.com/tutorials/361/understanding-uid-iid-health-of-enemies-and-rocket-smoke-trail

sqiddster

That's indeed really weird, I even try to reset all pick and it still won't destroy all the Nodes:

<img src="http://i46.tinypic.com/5egyzr.jpg" border="0">

capx

https://dl.dropbox.com/u/39382262/BUG/DestroyBugPickReset.capx

Potato

See that's what you call Pavlov's Sprite. heh

Another "feature" where the objects don't actually exist till the next top level event happens... unless you use on created.

Edit, ok never mind on the on created, blah, blah, blah, one trigger per event branch.

I think one problem is that when code consistency changes, because of the inherent design system in place, there is no easy way to go back and change things quickly. There is no concept of "search & replace"/"refactoring" or anything that you could do easily in a scripting programming environment.

Exactly, that's what worries me. This may break a large amount of existing projects, and it is very subtle.

I can confirm that this change breaks the "Asteroid Clone in 100 steps" tutorial and the downloadable capx from the arcade(at event #20).

I'm pretty new with Construct 2 and the only way I can see to fix this is a mess of global variables. That seems unfortunate, although I'd really love for someone to tell me I'm wrong.

Hopefully this is a mistake. If not, I can live with it but I'd like to hear from Ashley ;)

It's a quirk of Construct 2, and could be difficult to fix. It works the same as it did in Classic and for the same reason: objects are not truly created until the next top level event. Although spawned/created instances are picked in the event they are created in, it does not actually exist at all in subsequent subevents, until the entire top-level event finishes.

The reason for this is quite technical. If a condition picks from instances of "Sprite1", then the actions are running on a subset of all "Sprite1" instances. If one of the actions spawns a new "Sprite1" instance, then the subset of all "Sprite1" instances has changed. Since the actions were already running on these instances, and it changed halfway through, due to the design of the runtime it would then crash. The most obvious way to fix it would reduce the performance of all games, rather than just games which do this, and other solutions are hideously complicated, so it has been deliberately left like this.

Note you can still destroy an object in the same event - try moving the second subevent nested under the first. That might be a good workaround. Apart from that you can work around it by adding a 'Wait 0 seconds' event before the Destroy action, which postpones the action to the end of the event sheet, by which time all created objects will "really" exist.

I think this has to be closed as won't fix - I can't think of a good way to build in a workaround to this in the engine itself.