[r100] Interesting subevent problem

Bugs will be moved here once resolved.

Post » Fri Aug 24, 2012 11:22 pm

@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.newt2012-08-24 23:35:44
Image Image
B
161
S
48
G
90
Posts: 7,347
Reputation: 66,749

Post » Sat Aug 25, 2012 9:07 pm

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.
B
4
Posts: 10
Reputation: 320

Post » Sat Aug 25, 2012 9:37 pm

Exactly, that's what worries me. This may break a large amount of existing projects, and it is very subtle.
B
90
S
30
G
24
Posts: 3,189
Reputation: 32,400

Post » Sat Aug 25, 2012 10:59 pm

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.
B
3
Posts: 1
Reputation: 352

Post » Sun Aug 26, 2012 1:50 am

Hopefully this is a mistake. If not, I can live with it but I'd like to hear from @Ashley ;)
B
90
S
30
G
24
Posts: 3,189
Reputation: 32,400

Post » Tue Aug 28, 2012 3:54 pm

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.
Scirra Founder
B
359
S
214
G
72
Posts: 22,946
Reputation: 178,498

Post » Tue Aug 28, 2012 8:16 pm

OK Ashley, if it has to be like this, that's fine. I can try the 'wait 0 seconds' approach, it could work as a quick fix.

I'd put this as a 'breaking change' in the changelog however as it could cause unpredictable behavior in many games.
B
90
S
30
G
24
Posts: 3,189
Reputation: 32,400

Previous

Return to Closed bugs

Who is online

Users browsing this forum: No registered users and 0 guests