Nice. Thanks.

I have managed to do this - but it's very laborious.

If 2 objects of the same type collide, I want them to swap their angles - simple enough. (Obviously I have to use a holding variable when I swap them.)

The problem is getting the data out of the appropriate picked object - you can't do it without picking them specifically. I ended up with something like this:

<img src="https://dl.dropbox.com/u/104684620/Capture.JPG" border="0" />

Maybe that doesn't look so bad, but if I want to scale it to be a little more complex than that then it quickly becomes and unreadable mess with everything copied into unreadable variables.

Ideally I would be able to do:

tempAngle = ant[0].angle

ant[0].angle = ant[1].angle

ant[1].angle = tempAngle

Is there any way with the picking to get more elegant code like this?

Hmm. Never had to do that. Ultimately it's just about deleting or making invisible those HUD objects.

I'd just do it all in a function - make them all invisible.

I have a work around for this that I am pretty proud of. Steps are as follows.

Make sure all your layouts have the same number of layers. Good practice anyway. Including a blank HUD layer.

Create a specific HUD layout, with the same number of layers.

Put the HUD elements on the HUD layer in the HUD layout.

Make them global.

I organise my game events in a single event sheet - so this is how i do the next step.

On load layout, I store the name of the current layout in a global variable.

Load the HUD layout.

In the HUD's event sheet (not the main event sheet), you have an On Level Loaded event which then loads the layout whose name you stashed in the global variable.

So basically, whichever layout you load, it immediately loads the HUD layout, which is all globals. And the HUD layout loads the original level back in. The global HUD is preserved. It works perfectly. :)

Possibly. You need to specify exactly what you want to happen, and then we can try to work out together if it's possible.

Eg. the crane example. I think I know what you mean by this - and I think it would be possible to achieve it using forces. But you need to specify it, preferably with a diagram or capx.

Anyone tested the accelerometer and confirmed it working. Think I'll be giving it a spin later.

Jase00 - Cool - well that's definitely working better. Though I'm not quite sure why.

You would have thought the velocity would override the Force or vice versa. But it just seems to be providing some extra damping - any idea why?

And thanks.

In fact, setting linear damping to 1 gives much more stability.

OK. I have kind of done it. Not quite as clamped as I would like but still not bad.

dl.dropbox.com/u/104684620/force%20test.capx

Pick up the pink blocks and use them to play around with the blue platform. There is some physics wonkiness - but part of it is to do with combining physics with drag 'n' drop which is never a good idea.

Basically this is achieved in a single line of code! Every tick, a force is applied proportional to the distance away from the target Y. This creates a spring effect and if you make the force large then the spring is pretty strong. Note that the spring is easily able to cope with gravity.

Better results could be achieved by balancing density, force strength, linear damping.

So the first rule of game physics applies: do everything with forces.

Well, I gave some examples earlier. It's a pretty standard part of any physics system.

And in fact Box2D supports this type of constraint - it's called a Prismatic Joint. And it's section 8.7 of the manual

box2d.org/manual.html

ASHLEY. Any chance we could get these added to the physics? And the other joints? Moar physics!

I don't quite understand what you mean

...are very difficult to get your head round in C2, compared to conventional programing.

Just to iterate through an array, which is trivial in normal programming, is giving me a headache. Nested loops, odd For syntax, arrays being accessed by axis names = head is hurting!