Wow, didn't know that Sounds VERY useful!

It IS pretty confusing... It isn't generally very good UI design to hide features EXCLUSIVELY inside context menus... There could be some kind of VISIBLE hint?

It would simplify the situation, if at least the default behaviors would "toggle" a collision if one were to happen in the processing of the behavior's movement. Wasn't that kind of system added in the physics behavior?

etc.. even 'image'

Image is basically two-dimensional array of RGB values, and I think that there is already a array data type?

Those IK chains look so useful that I'd like to see the calculations built in in math :D The calculations are just solving a triangle, right?

The next lesson is ready! It's a really short and simple one, but hopefully someone will find it useful.

• Lesson Five - Customizing Controls
  Creating two simple custom controls to enhance the default Platform behavior... super-speed, and double-jump.

Enjoy :)

Next up in Lesson Six: how to make a ladder, and how to swim.

Great tuto! The engine looks already so slick, that it would be pity if this wouldn't evolve as a full-featured game after the tutorials series is complete! Maybe the last tutorial could be "making a level editor" and then making the game would turn into a community challenge :D

Thanks David, I changed it and works well :D . Is this method faster than collision? Is posible to get the same effect but with one object type? :roll:

Quote from another topic:

The only propely working solution is to apply two families to same object type, and make conditions where "Family A" overlaps with "Family B" to distanguish the different instances. There have been discussion about this before, http://www.scirra.com/phpBB3/viewtopic.php?f=3&t=1541&st=0&sk=t&sd=a&start=20, http://www.scirra.com/phpBB3/viewtopic.php?f=16&t=1667 and http://www.scirra.com/phpBB3/viewtopic.php?f=17&t=1740&p=12449

I modified a test cap from the original, and I think that it shows pretty clearly the odd behavior.

http://drasa.nipponfever.net/muu/container_test.cap

I simplified the situation: now there is no spawning, the contained sprites are already there, and it should be clear from the events that the arrow should point to the corresponding sprites, but they doesn't...

WTF. Even having one pair WITHOUT containers trigger this bug, but for each corrects it. Strange.

Also encountered two crashes, which of one I was unable to reproduce, and one happened when cloning a layout, and then copying the all events from layout 1's event sheet editor to layout 2's. I'll post it to the tracker.

Holy sh...!!! Terminal Orbit! It was so long ago :D Ashley was still Tigerworks back then... I just stalked the site occasionally, but pretty faithfully :D

I hope that Terminal Orbit is going to become something great!

It's not a bug, it's just how Construct works.

When you say "Aim at <something in my container>", it aims at the paired instance from its container.

When you say "Aim at <any old object>", it usually just picks the first.

I know that, but isn't the enemy something in the arrow's container? According to that logic, it should work both ways around!

I think it's strange that it works without the for each when the arrows are positioned at enemies and pointed to player, but needs for each other way around. Shouldn't it be the same, whatever the actions are? The arrows are pointing to enemies, so shouldn't the action pick THE enemy the arrow is paired with, without need of for each? At least it picks THE enemy when positioning, so why not when pointing?

I think this is a bug.

Doesn't construct have to loop though objects anyway, even if the colliding objects weren't same type?

Well, it's internal loop so it's probably a lot faster...