Creating and Destroying Objects

New releases and general discussions.

Post » Mon Jul 20, 2009 5:25 pm

[quote="konjak":3sppj4ty]
Destruction has done the same for me in the past, meaning I can have an event that says "destroy" then anywhere below have one that says "always + if object exists ---> play a sound" and even if the event is after it will play that sound one more time.[/quote:3sppj4ty]

I had a somewhat similar problem, but then I realized that the object.count doesn't seem to update within a tick so to speak. So if you are using something like object.count > 0 to test if the object exists, you don't want to put it below the destruction event but above it.

But I'm just assuming different things here. A cap pretty please?

[quote="deadeye":3sppj4ty]Huh. You're right, it does work fine with key presses.

Looks like there are TWO problems to solve in this thread now :P[/quote:3sppj4ty]

I hate it when that happens... 8)
B
21
S
6
G
10
Posts: 1,024
Reputation: 7,445

Post » Mon Jul 20, 2009 6:42 pm

I actually can't seem to recreate it in a different .cap-file...

Which is strange since I'm using the same approach.

I have a work-around but it still doesn't solve the inexplicable mystery of my old approach. It did indeed set any of the objects created after the first "set values" to the values of that very event, though, I'm not imagining that part.

EDIT: I created a CAP out of the game I have and it retained the strange error. I'd still like to know what causes it, even if my workaround is mostly better and tidier. Hopefully you can comprehend my code:

http://www.konjak.org/creation.cap
B
5
S
2
G
3
Posts: 234
Reputation: 1,818

Post » Mon Jul 20, 2009 7:56 pm

spawning objects work differently.
B
2
S
2
G
4
Posts: 259
Reputation: 1,968

Post » Mon Jul 20, 2009 8:15 pm

This is a fairly complex and subtle part of the runtime - and as far as I know, it'd be very difficult to change, so it'll most likely stay the way it is.

The way it is, though, is that when you create an object, it doesn't really exist until the end of the next top level event or trigger. If you create an object in an event, as everyone knows the actions following it apply to the newly created object - but other actions won't apply to it until the current top-level tree of events or the current trigger finishes. (A top level event is anything which is not a subevent of anything else - I can't remember if events in groups of events count)

So a potential problem would be creating an object in a subevent, then trying to use it in another following subevent. However, it's still picked in subevents to the event it was created in! Confused yet?

Then triggers make it a bit more complicated - triggers are allowed to trigger any time they want, at any stage in the runtime. So what I suppose is happening, is the trigger is firing between running events and drawing the screen, so it goes:

Run events (no objects exist so the action to make it change colour)
-> 'on button clicked' fires: creates an object with default colour
Display rendered, showing the default colour
Run events again - this time changes its colour
Nothing triggers this time around
Display rendered, showing the changed colour

That's why you see it a different colour for one tick - you're assuming the trigger fires before the events. They're allowed to trigger any time, so you shouldn't rely on this kind of behavior. You should set up your object in its initial state in the event that creates it.

If you've made it this far, the collisions and key press events (and a rare few others) aren't real triggers. Real triggers show with the green arrow icon; the fake triggers like 'on key pressed' actually just have a built-in 'trigger once' to a 'is key down' test. So they run where you expect them to in the event list - and you can guarantee events after them will run after it. You can't guarantee that with real triggers - their position in the event sheet has no meaning except in relation to other triggers.
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,580

Post » Mon Jul 20, 2009 8:41 pm

and here all this time i thought press was working like a real trigger and for whatever reason the green arrow just wasnt there. but that would be stupid wouldnt it. that clears shit up.
B
2
S
2
G
4
Posts: 259
Reputation: 1,968

Post » Mon Jul 20, 2009 8:49 pm

Well, since triggers are allowed to trigger at any time, that could include their current position in the event sheet :P so they dont break any triggering rules...
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,580

Post » Mon Jul 20, 2009 11:06 pm

[quote="konjak":3gwydh5s]EDIT: I created a CAP out of the game I have and it retained the strange error. I'd still like to know what causes it, even if my workaround is mostly better and tidier. Hopefully you can comprehend my code:

http://www.konjak.org/creation.cap[/quote:3gwydh5s]

I've isolated the problem, and I think it has to do with this:

[quote="Ashley":3gwydh5s]The way it is, though, is that when you create an object, it doesn't really exist until the end of the next top level event or trigger....

(A top level event is anything which is not a subevent of anything else - I can't remember if events in groups of events count)[/quote:3gwydh5s]

I guess groups do count after all, because I moved all of the necessary events outside of the group into the top level of events and it works fine. Check it out:

http://files.getdropbox.com/u/529356/creation2.cap (0.99.3)
Moderator
B
5
S
2
G
6
Posts: 4,348
Reputation: 10,971

Post » Tue Jul 21, 2009 2:50 am

you guys are awesome
B
134
S
65
G
16
Posts: 1,766
Reputation: 19,190

Post » Tue Jul 21, 2009 9:00 am

Okay. I've solved it anyway with the repeating of the creation event several times over, but how did this current approach come to be? Just wondering. :o
B
5
S
2
G
3
Posts: 234
Reputation: 1,818

Post » Tue Jul 21, 2009 7:25 pm

Limitations in the way the runtime is coded; the way it's written means that the SOL cannot be modified while actions are running, because actions run on the content of the SOL. I might be able to tweak this to make it less confusing for 2.0, but it's hard before then since I never anticipated the problem.
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,580

PreviousNext

Return to Construct Classic Discussion

Who is online

Users browsing this forum: No registered users and 3 guests