Incorrect gravitational acceleration for multiple vessels within physics bubble

[ferram4]

Gravitational acceleration is calculated at the physics bubble CoM and applied equally to all vessels in it (by moving the bubble). If there are multiple vessels within the physics bubble, this results in the gravitational accelerations on them being incorrect due to the distance between each vessel's individual CoM and the combined CoM. In the case of a vessel (let's call it A) loading in in the vicinity of another (vessel B) for the purposes of gravity calculations B loading in shifts the combined CoM, effectively shifting A's position for gravity calculations. If mass_B >> mass_A, then on load the effective position of A for gravitational purposes will shift to be at the CoM of B, resulting in a jump of 2.5 km (assuming a default in-space load distance) and a sudden shift in the gravity vector.

This has severe implications for rendezvous in the future. In the very worst case, depending on how debris in atmosphere is handled (for the situation of a focused vessel in vacuum, but with loaded debris low enough to be in the atmo) the distance could be 22.5 km max position error. @eggrobin initially suggests adding some form of compensatory forces within the bubble to handle these effects.

[eggrobin]

This should be OBE with the work on pile-ups.

I don't think we have written down the details of the pile-up idea anywhere though, so I'll do it here.
The current issue with 1.2 is that timewarping is impossible if there is an unpacked vessel; this makes the game mostly unplayable for practical purposes.
The reason for that is that the acceleration Vessel.geeForce (in units of g₀), which is used to determine whether the vessel is under acceleration (and thus non-timewarpable), is computed by (averaged) finite difference of the velocities, from which the graviticAcceleration (sic.) is subtracted. We force graviticAcceleration to be 0, thereby preventing KSP from trying to apply gravity, and we move the universe around the bubble to apply gravity ourselves: geeForce thus ends up measuring gravity.
The idea is then to use the new "census of proper accelerations", which knows all thruster forces, to feed that to our own integrator, and to compute the actual geeForce ourselves and overwrite KSP's (in TimingPre, after VesselPrecalculate).

Since thrusts are known per vessel, but collision forces are not registered by the census, this motivates the partition of vessels into PileUps.

This would allow for free-falling unpacked vessel trajectories indistinguishable from trajectories of packed vessels (histories). It would also ensure conservation of momentum and energy (treating the PileUps as point masses).

It may be possible to later use that to also enforce conservation of angular momentum.

[pleroy]

The PhysicsBubble was removed in #1215 and all the work on the PileUps (roughly from #1213 to #1246) has taken care of the problem. Will be in Cardano.