Don't DO This:

Hey everyone,

I have a story and something you should avoid.

When writing events in construct, you can refer to an object that has no instances. This is fine if you want to read some default instance variable or behavior value off it - such as max speed or gravity power. But what you can't do is change something that doesn't exist. For example:

On start of layout -> set playerObject physics stepping mode to framerate independent...

more events, more events, more events... blah blah blah...

Create playerObject at playerSpawnpoint.

The result of this is that you do not have framerate independent physics because you couldn't change the physics behavior from an object that doesn't exist. In a large project with thousands of events, errors such as these can be easy to create, nearly impossible to find and worse may remain hidden for weeks.

Don't spend hours of debug time trying to figure out why something doesn't work only to find a mistake like this. The worst part is construct is happy to go along with bad events like this... same thing for calling functions that don't exist. Its like if you told an employee to bring the client in the waiting room some coffee. The employee goes to the coffee room and finds no coffee. Instead of telling you, he just abandons all other subsequent instructions and asks for the next set of directives... Well, he thinks to himself, you are the boss and you must know there is no coffee. What a bizarre instruction. Oh well, best to carry on.

I do not see exactly the problem, of course you cannot reference a non yet existing instance (could you get me a kfvoenxlexkov at the coffee?... a what?)

However if you can reference values out of it, this is something I would consider as a bug.

I think he's implying that you can accidentally try to set values to non-existent items and nothing happens... I presume. I've done this and it's a pain trying to chase down exactly what went wrong. I find it happens a lot for me in sequenced statements with conditionals.. you spawned in one sub-event but set parameters in another, etc.

C2 does not handle non-fatal errors well.

Aphrodite - but that's just it - you can reference a non existing item in construct. You shouldn't, but you can... and construct 2 doesn't tell you when you do... I nice log file in debug mode might be nice... Like "Hey, I called this function, but it doesn't exist, just so you know".

rho - that's it in a nut shell.

Try removing those objects from the layout.

Aphrodite and newt: I don't think you guys get the issue:

He is accessing properties of an object that exists, but has no instances at the time of the referencing.

think of it like this:

• <There are zero balls>
• Make all balls be blue
• Create a ball
• Ball unexpectedly comes out white

He was writing to the phantom "default instance" and expecting newly spawned instances to be created with whatever properties he set to be the default. This behavior would make sense, think of it as changing the defaults of an object.

However, construct doesn't work that way. You cannot "write" default properties at runtime. Thus, you get a logic error that is hard to spot.

I don't consider this a "bug" per se, but Ashley might want to do something about this. Either make it so that you can write defaults, or make construct give an error if the object you're writing to has no instances (I think this last approach would be very hard to implement).

I do not think writing default values would be good... and that would be a breaking change.

Also, that implies that C2 does something to an object when no instances are picked, which I think would be pretty hard to implement correctly, since that goes against the basic way C2 actually works, nobody wants actions to occur to all newly created objects if none are picked or exists I think, they would rather skip that.

The on created event exists for this purpose already. As well as the .count value.

Fimbul

This sounds like in a normal computer language where you are using a ForEach and then wondering why the code inside the ForEach loop didn't run when the list of objects in the ForEach had a count of zero ... the loop never runs if the count is zero because it only runs For Each Object.

Each object type in C2 has a Count property... you can do something called "assert" which is what software developers do to check to see if things are in the state that their code will expect them to be.

For example you can add an event that checks the Sprite.Count before setting values to Sprites and if it is zero then do a Browser.Log to alert yourself that the code you thought would make some change to a list of Sprites has no Sprites to act on.

This is all just normal coding practices done all the time.

It has to be open ended, otherwise you would not be able to make events that reference an object which may not exist yet.

If I were to make an event that said every x seconds sprite set y to self.y+1, as it is now it wouldn't do anything until one existed.

Error reporting really wouldn't add to ease of use in the long run, as you would have to have some silly event that asks, hey sprite do you exist?

But the kicker is you couldn't do that either because you want to make it so that you can't reference a nonexistent object.

I don't think anyone should be surprised that trying to modify an object that doesn't exist does nothing. However the Physics example in the OP is slightly different because it modifies a global state that affects everything, but still needs an instance to exist in order to do anything. This is a shortcoming of the event system, and currently there's no architecture in place that could make that work, so I don't think we could fix it easily.

Aphrodite and newt: I don't think you guys get the issue:

He is accessing properties of an object that exists, but has no instances at the time of the referencing.

think of it like this:

• <There are zero balls>
• Make all balls be blue
• Create a ball
• Ball unexpectedly comes out white

I don't consider this a "bug" per se, but Ashley might want to do something about this. Either make it so that you can write defaults, or make construct give an error if the object you're writing to has no instances (I think this last approach would be very hard to implement).

For a situation like this it would be nice if the debugger could provide you with a list of warnings when a situation like this arose. For example "Warning: this operation has no object instance". However as Fimbul said, I'm not sure how you'd do it.

As Ashley said, the behaviour is not surprising, but it is hard to debug when it accidently arises.

PS: didn't know about the physics object behaviour.

I don't think changing the defaults is a good idea

For a situation like this it would be nice if the debugger could provide you with a list of warnings when a situation like this arose. For example "Warning: this operation has no object instance".

I think the Construct Classic debugger did something like this, but it wasn't especially useful. In a long event sheet the "zero instances action" can happen several times per tick for innocuous reasons, and that ends up spamming the log with huge amounts of irrelevant data, making it hard to pick out the cases where it really is a problem.

Fimbul Aphrodite - Yes, that is indeed true. You have to reference objects that don't necessarily exist. And I don't think that changing default values at runtime would be wise... but I was original only thinking of changing global states (such as physics or pltformer gravity direction; something you really don't need an object to do, but do.

Aphrodite - On create is a lovely event trigger, but there are some problems with it that I can't get around. For example: I can't send on create any parameters so I don't know what object spawned the object if I am dealing with compound objects. Thus, if I just run on create logic, I lose the the ability to have the creator in my list of objects.

I am not saying it should be different, I 'm just giving a shout out to help others not make the mistake I did. I literally had a problem for several months, and instead of realizing I made a call in the wrong place, I spent hours trying to figure out why physics wasn't working as expected. I found problems that weren't the problem and changed things that didn't need changed.

Ashley - Thanks, that makes sense. High five for all your hard work. Construct 2 is the bomb.