Collision Detection/Resolution

[Multihunter]

EDIT3: Yeah, read this part first. What you are going to eventually have to do is put all of the circles into an array and then check each circle against each other. I'm too tired to explain how to explain it. Hell I don't even know properly myself, all I've got is the

for (i>/*something or other and other stuff*/) { /*variable "i" is now every different object in the array, changing each time it runs, it runs once for each different thing in the array per frame, so you add circle1 to the array, and then since that's the only thing in it, yourArray[i] will refer to circle1. Next time it runs, it will refer to whatever it was that was also in the array. Look it up if you don't get it.*/
} 

I have been thinking about that too. I have a fix... but it's probably gonna be messy... and not so great. I'm just sharing my thoughts on it here, atm.
Ok, I don't know about you, but I've used the global variable "time" as an exact modifier for the Velocity to determine how far the it is until the actual collision. So, once you have recalculated the Velocities of the using whatever code you have for that. Run ANOTHER check on all of the objects in the array using a different variable. Re-run the "ResOverlap" function between each of the two collided circles and the "rest" of them and using the remaining time modifier to the velocities added to the positions. So what I'm thinking is instead of what you did in the beginning, of:

var xdif:Number = circ2.orig.x - circ1.orig.x; 

Have:

var xdif:Number = (circ2.orig.x+(circ2.vel.x*(1-time))) - (circ1.orig.x+(circ1.vel.x*(1-time))) 

EDIT2: OH! And you should also use the (1-time) modifier on the xSpdDif variable calculations. And, it's (1-time) because they've already moved the length of time, and 1 = one frame, so the difference is how far they have yet to move. Also. I am using a model where they currently bounce around to build mine, instead your "one-step-projection" thing that is probably better, but I notice that you haven't put in the final positions, so all of this is probably irrelevant... Oh, I see... you just stop them based on where they are GOING to be. So the reason it looks like they are going into each other is because it's only taking into account where they are going to be.

And that SHOULD detect 1 more subsequent collision. If it were to collide twice this would also fall down... hmmm... Thinking on the spot now; we need some function that works out when two circles will collide, what the subsequent velocities would be, and whether there would be another collision, and if there was start again, so it's kind of using the last collision as a reference point. I'm thinking maybe have global variables that can act as temporary velocity holders for any of the circles, so that you can plug in the velocities during several collisions without modifying the actual velocities. I will figure out how to do that this weekend. (w00 4-day weekend! Making next week a 3-day week!) So hopefully I won't be almost unconscious while trying to do it!

EDIT: The good thing about having the time variable is that you can work out exactly which one will collide first, even if it's a minute difference.

EDIT4: Yeah, I'm tired. Sorry if I've confused...