Creating and Destroying Objects

There seems to be an issue with Construct that I'm not sure if it can be worked around or if it's an oversight or if it's some kind of standard procedure I don't understand, but when I create an object (or destroy it, but I haven't tested that recently) any sort of event following the creation will be ignored. It seems to me any creation event is queued until all the code has finished, then the object is created.

The problem with this is for instance if I have several animation frames in a sprite but I want it to start on a particular one upon creation. The sprite will appear, though it will flash in its initial frame for a single tick. This is the visual indicator, any event such as setting its position or size following that event, but not within that event, won't affect the object until the next tick.

My great issue with this is the removal of being able to create several objects and have several conditions in the same event affect all the newly created objects. I have an event that follows now that if it's not 1 it will set all the values I want right after creation, then it sets the value to 1, and this event immediately follows the creation event, but is ignored until the following tick.

Now I might have several of these events through the code that have an identical condition, but as it sets the value to 1 it should only affect the ones I want, but if it doesn't work for the same tick it will always pick the topmost event for all the created objects of the same sprite. I used this approach of value-setting back with Multimedia Fusion as well, and that program created objects at the same line of code as the event that asks it.

It would be really nice and comfortable if objects were created and destroyed at their actual line of code rather than before each tick renders a picture, and I don't quite understand how this approach was chosen to begin with.

Thanks!

EDIT: A way around it is probably to make a single creation run several times over, but I think it still messes up the animation frames. And it just makes more sense for objects to create and have values set at the line of code where the event is.

The problem with this is for instance if I have several animation frames in a sprite but I want it to start on a particular one upon creation. The sprite will appear, though it will flash in its initial frame for a single tick. This is the visual indicator, any event such as setting its position or size following that event, but not within that event, won't affect the object until the next tick.

I'm pretty sure I never experienced that. When I create a sprite, all the following events will be run in the very same tick as well. Wouldn't what you describe also mean when you created a sprite and destroyed it in the next event, it still appeared for one tick (which obviously doesn't happen). Or I'm not sure what you're getting at.

(Btw you can set the initial animation and frame in the properties. But I guess you knew that and need to change it dynamically.)

It would be really nice and comfortable if objects were created and destroyed at their actual line of code rather than before each tick renders a picture, and I don't quite understand how this approach was chosen to begin with.

Actually I'm pretty positive that's how Construct works: creating/destroying objects at their actual line of code. Otherwise many things I had tried in Construct would have failed horribly.

Then again I dunno I might want to see an example cap demonstrating the problem you described. Since I might just not get it after all...

It's always much easier if you have an issue (or think there's a bug) to post screenshots of events, or a .cap file, so others can suggest solutions. I'd be willing to take a look at your .cap file if you want.

Konjak, just set everything you want for the created objects on the action line right after the create/spawn action. Actions directly after a create/spawn action will pick the newly created one, and perform the actions on it.

eg.

create bloodpixels at kid.x, kid.y

.bloodpixels set height to 2

.bloodpixels set width to .height

.bloodpixels set value 'speed' to 2

.bloodpixels set animation frame to 3

any actions after the spawn/create event will affect the newly created object.

And what about destroying? I don't get what you mean about that.

I get what he's saying, and I've recreated the problem:

http://files.getdropbox.com/u/529356/creationism.cap

Click on one of the two buttons to create a box. The box should appear blue, without any flash of red.

The box on the left has the frame set to 2 (blue) within the create event, and it works normally.

The box on the right has an Always event after the create event that always sets it's frame to 2, but there is a flash of red when it's created.

Logically one would expect the box on the right to respect the order of events and change it's frame to blue in the same tick because of the Always event.

[quote:34dudx44]http://files.getdropbox.com/u/529356/creationism.cap

I was going to call it "intelligent design.cap" but I thought that was a bit too snarky

Click on one of the two buttons to create a box. The box should appear blue, without any flash of red.

The box on the left has the frame set to 2 (blue) within the create event, and it works normally.

The box on the right has an Always event after the create event that always sets it's frame to 2, but there is a flash of red when it's created.

I just was like "wth I tried smt like this and it didn't happen for me".

After reflecting one second (not necessarily about the problem at hand ) I remembered that in my example the object was created with key presses and not button clicks.

So I copied the creation-event of the right box, but with a "On key pressed" condition instead of the "On button clicked". I can see no flash of red!

Now has this problem something to do with how buttons work or am I going insane here?

Can anyone confirm it?

Konjak, just set everything you want for the created objects on the action line right after the create/spawn action. Actions directly after a create/spawn action will pick the newly created one, and perform the actions on it.

I explained this approach is the exact one I use, and it doesn't work with this approach. It will start reading the code anew and look for the topmost of these events and execute it for all the created objects instead of just the one I want.

Maybe the "spawn" action works differently?

And as someone suggested that creating then immediately destroying works, of course it does, my point was they both execute at the end of the code, and that would mean it creates and destroys at the end of the code.

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.

I just was like "wth I tried smt like this and it didn't happen for me".

After reflecting one second (not necessarily about the problem at hand ) I remembered that in my example the object was created with key presses and not button clicks.

So I copied the creation-event of the right box, but with a "On key pressed" condition instead of the "On button clicked". I can see no flash of red!

Huh. You're right, it does work fine with key presses.

Looks like there are TWO problems to solve in this thread now

And konjak, I guess you're going to have to upload an example of the problem because apparently I haven't recreated it at all.

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.

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?

Huh. You're right, it does work fine with key presses.

Looks like there are TWO problems to solve in this thread now

I hate it when that happens...

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

spawning objects work differently.

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.

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.