Tbh, Dan should rip the atom-atom MO-MO collision system out of CC and simply implement Box2D (or something with equivalent functionality) for collisions between MOs. octagons interpolated from N atoms (each N/8 atoms = vertex) would work well enough for most shapes (most MOs are near-circular, or else boxes), but maybe there could be other interpolation modes as well. Shock horror, just about any physics engine can assign masses to objects and detect impulses (what every freaking collision in CC is based on) for said reaction HOWEVER that would allow MO-MO collision in real time with likely less overhead than ♥♥♥♥ he's using to collide them now (Box2D runs realtime in flash ffs, the C++ implementation is damn quick) and then suddenly we get dropship surfing. Bonus, huh?

It'll never happen.

I had actually heard somewhere before what it stands for, just can't remember where...
Might have been the Interactive CC History.

geti, the problem with using a traditional rigid body solver for CC is that the terrain is deformable and of arbitrary hardnesses.. i can't think of a way for box2d to deal with having an object fly and sink into pixel-based terrain, with each pixel being of a different hardness etc.. it's a tricky problem that needed a custom solution.

My custom solution isn't very optimized; it was my first physics engine. CVE's engine is shaping up to a lot more speedy (perhaps because i'm not programming it

Retro Terrain Engine. I think it was mentioned in this thread, no?

That's all well and good, but it's not the collisions between objects and the terrain that's bugged - that's completely fine. What I'm suggesting is applying standard rigid body physics to MO-MO collisions (or more specifically, MOSR-MOSR collisions) and leaving the terrain collision code the way it is.

Here's a visual example:


This should prevent random explosions in MO-MO collisions and allow the riding of dropships, theoretically.
Rigid-body 2D physics engines are good for use here because they usually

• Support friction
• Support stacks of objects
• already contain joining code (for attachables and the like)
• Can calculate implulses from a collision (which is how collisions in CC seem to function)
• Are well optimised because they're FOSS

I'm dubious as to whether it'll ever get implemented, but I think it'd be a better solution than the current solution for MO-MO collisions, which more often than not just gibs one or both parties.

I'd probably be happy to write the vertex-determining code for you with some knowledge about the atomgroup datatype

One vote here for Geti as a developer.

Add one to that.

Hitboxes would still be able to use the current system, so far as I can tell. Additionally, it seems the rigid body would remain inside the atom group, making it more difficult to hit things if anything.

Another vote here for Geti as dev. Do it Dan!

These aren't hitboxes, they're MO-MO collision boxes. So they'd only come into effect when you're trying to stand on a dropship.
An elegant if not quite perfect solution to the problem.

Perhaps better angle detection, so there aren't any corners being cut off.

Well, duh summed the main problem with your problem with it up, except it's likely even as limited as MOSR-MOSR collision boxes, as MOSPs and MOPixels both collide more or less fine with MOSRS. The way I'd do it would be to look at the AtomGroup for an object, check if it has >1 atom in it, and create a polygon out of those atoms if it does.

The other issue ("Yeah, but you'd still have corners cut off.") only applies if you stick to 1 shape per MOSR and there's a low cap.

Just reading over the Box2D documentation now it looks like you can expand the hard limit on vertexes per shape, to say, 32 (as we can't have >255 GetsHitByMOs MOSRs at the moment due to the MOID cap so 32*255 2D float vectors in memory - that isn't expensive at all, ~63.75kb in raw floats + vec2Dfloat class methods, hardly unworkable) and avoid that whole issue - a 32-gon should certainly be enough to describe almost any wacky shape, for example:

That's a 20-gon. Fits the surface like a glove.

Also, even if you did want a huge shape with holes in the middle (something Box2D at least, won't allow) this kind of solution would still address the problem better than the current MOSR-MOSR collision behaviour - 90% of the time, the smaller MOSR (like your actor's leg) gibs everywhere, otherwise you slide over each other.

Furthermore, it's not a hitbox system, it's a rigid body collision system. AFAIK it's what the current system is trying to emulate.

Also, most of the time in CC (>90% afaik) objects are using very very very simple atomgroup structures. The craziest shape in vanilla CC would probably be a dreadnought leg or a gun. Think: Body, more or less elliptical; Rocket, more or less smoothed rectangular; Dropship, more or less elliptical; Head, pretty much circular; Arm, two overlapping ellipses (though could be done with an irregular quad if you wanted low atom/poly count); Gun, series of overlapping squares; Grenade, more or less rectangular.

My conclusion from that - we don't have that many crazy shapes.

The only real issue I can see is potentially some memory overhead from storing the poly data and collision systems. tl;dr using this CC might need another hundred meg ram or so, worst case. Not sure of CPU overhead, this solution could actually use less juice if the RTE MOSR-MOSR collision code is very slow.

Also: Me working on the CC code for this raises issues - I'm not excellent at C++ and haven't worked with a direct C++ implementation of Box2D before. I'm uh, willing to give it a go I guess, but Dan knows his code better than anyone and would be able to put it together a lot sooner if it's possible.

Regardless, implementation possibilities:

all MOSRS (or maybe only GetsHitByMOS MOSRS) have an associated body (which stores their central position, orientation and velocity, so sits at the spriteoffset and is fed pos, vel and rotation (and rotational velocity), as well as any impulses /torques from the other collision phase) and shape (which is interpolated from their atomgroup), which is associated with a box2D world of equal size to the cortex command world and fed the same deltaTimes on its update. When the Box2D physics calcs are done between all the objects, the outcomes are fed back to the RTE physics.

That last step could be tricky or simple, depending on the RTE functional equivalents of the box2D side of things.

Also, the Box2D world wouldn't need gravity, as that'd be taken care of by the RTE side of things too.

This is still all conjecture though. I kind of need Dan's input to know how truly viable it is.

@CC48 - that'd help too, interpolation can be costly though.

+1 for Geti as developer. Or think-tank guy. Course, this is really up to DaTa.

Sounds good, just needs to get implemented, and there's no predicting what kind of crazy unforeseen things could happen during that.

The atoms are already defined to make the objects work in the game currently, so it'd generate these off of those.

It'd also be nice if assigning custom atomgroups actually worked (last tested a few builds ago - afaik it just autogenned anyway). You could then use that to define custom poly shapes if you were a good modder.

Whoa, I hope Darth Data sees this and let Geti touch he's code...