This is off-topic: I have created a scenario and, although it should work, a certain part of it fails. I have checked it again and again and I am sure nothing is wrong. I Then tried to upload it here to get help, but whenever I try it says 'No world class found', and tells me I must make a subclass to world, even though I have one. I am using windows 7 beta and greenfoot V1.5.5. I have tried re-installing. Please help. I didn't know where else to post.

Hi - the best course of action would probably be for you to head over to the discuss group (http://groups.google.com/group/greenfoot-discuss) and post it there as a file along with an explanation of your problem, then we can have a look at it. I guess there's a chance this might be windows 7 specific, especially since you're using a beta and not the final release which has been out a while now... :-) Have you tried it on another OS just to be sure?

Hmm, whilst dragging the dice around every so often it freezes up and I get the following message in the console: overload!! overload!! overload!! overload!! overload!! overload!! overload!! overload!! overload!! overload!! ...never seen that before! Is that something you've put in your code or is Java doing something rather special?

Hi Mjrb, and Sorry BlackholeGF, I don't check my email that often so i didn't get to your question in time. Mjrb gave the right advice! :) As for the Overload message, it was something I programmed in to output under special circumstances of the simulation. It occurs when there is an error calculating the Surface Normals, and they become much larger than suposed to, so until I figure out how to fix it, I outpul Overload!!! And reset the normal to zero, hence the weird movement. It seems to happen when corners colide.

Ahh sure that makes more sense. Just wanted to check it was that and not the JDK being weird (I was giving the early version of 7 a stab for a number of unrelated reasons.) I haven't looked at the code so this might be way off, but would it be to do with the corners overlapping too much before the collision is detected? If so then one methodology might be (if you're modelling it in a time based way) to step back and forth until you calculate the exact collision point then calculate the normal sizes from there. So say you've advanced t time between the last frame, computationally step back to t/2, check if that's the collision point, if it hasn't collided yet step to 3t/4, if it has step to t/4 - and then work that way. That may be completely irrelevant so apologies if that's the case but I thought I'd throw it in there in case it helps! Great work as always though, I always get a bit excited when you post something new :-)

Because friction is not fully implemented during collisions. It IS implemented however wrong, which is why the blocks don't slide around a lot though.

Yeah, most likely the best thing to do would be to rewrite the engine completely using momentum and torque rather than deformation and springs. The way the physics is calculated right now is very hacky x.x

How do you differ if a box hits another from above or right if one box hits the other at it's corner? Like this: |=====| |=====| |=====| |=====| |=====| |=====|