Add 'for each family1' after the 'is visible' condition. Right now they are both selected, but only first one of the picked objects is referred.

Make a function as a constructor replacement, and this is where it gets confusing to me:

<img src="http://cannedessence.com/construct2screens/constructor2.png" border="0" />

Why does this work? Notice the second action in the Create_Ball function. Shouldn't this pick all instances of Ball, since the event doesn't pick any instances of Ball? Somehow it picks the most recently created Ball, which works here. However, it doesn't seem right, so I don't want to rely on it.

I can't put an On Created trigger inside the function definition because they are both triggers.

Is there something I'm missing about this?

Thanks!

The create action picks the created instance, so you are only referring to that instance. So you could get rid both the function and on created, then do this:

create ball

set ball scale to 2

It would work just as well :) But yea, it's not really ideal to my workflow at some times either.

One alternative would be to make your own waypoint system. Here is an quick example:

Waypoint example

The general idea is that each WP is linked to next WP's UID (can be done in the editor), then the navigators just follow path formed by those WP's.

I'd do it with a container. Just don't create (in editor or in game) any sensor instances, as they will be created automagically.

Just pin the sensors to a car at 'on created' event and you should be good to go.

Something like

When all zombies are dead

.. Spawn a new wave of zombies that is 1 bigger than last one

It would translate to C2 events like this:

global variable : Zombies = 10

zombie.count = 0

trigger once while true

.. Add 1 to zombies

.. repeat Zombies times

... create zombie at random(x),random(y)

Hey Sqiddster,

I'd love to make the change, but I'm not using any physics in my game. If you notice in the .capx, it's all Solid and Platformer behavior.

Is there any other solution besides using Physics?

Josh

Collision polygon sqiddster refers to doesn't really have anything to do with physics behavior. What he means is, going to iamge editor for each object, and checking that their collision polygon (the icon at the bottom of toolbar) is what you want it to be. Your 'movingTileUpDown' has some funky going on with it's polygon.

Here is an old demonstration where you can see the exact mechanic:

Evil sprites

Set randomNumber to floor(random(charArray.width)). And do make sure your arrays size is not smaller than what you need.

I usually do it like this:

Pick all

Pick objects you want

If I need some values from the original instance, I usually save them into local variable or use a function.

You could do it like this instead:

Scale = 0.1

every tick

.. sprite.angle IS NOT 0

... sprite set angle: anglelerp(sprite.angle, 0, dt)

.. sprite.Scale IS SMALLER THAN 1

... add dt to sprite.Scale

... sprite set scale to lerp(Scale, 1, dt)

you could just take the sprite.scale IS NOT 1 condtions and add them to your example and it would work, but using lerp/dt will give you smoother effect on scale and rotation. :)

scirra.com/tutorials/354/xml-parsing

JSON works too if you are more into that kind of thing.

Few things that I noticed:

• You could use TiledBackground objects on many occasions, they give far better performance than using multiple identical sprites next to each other.

• You have lots of overlap on your objects: DarknessUpperMid, DarknessUpperLeft etc. Why not just have a single 'Darkness' object and copy, size and rotate it to fit everywhere?