|
|
|
|
|
by teraflop
1884 days ago
|
|
If I'm correctly understanding what you mean, I'm fairly sure that's a deliberate optimization/design choice. In the real world, a spacecraft or other object in orbit around Earth is also being constantly influenced by other celestial bodies, especially the sun and moon. Over short timescales this causes the spacecraft's orbital parameters to slowly drift; over longer timescales, it means the long-term position and fate of an object is chaotic and unpredictable. The behavior near the "boundary" between two spheres of influence is just a situation where these perturbations are more noticeable. KSP only implements two-body physics, so a spacecraft is only affected by the gravity of one celestial body at any given time. This allows you to put something in orbit and know that it will stay there without you needing to constantly check on it and perform stationkeeping. It's also the key simplification that makes "time warp" possible, since two-body orbits have closed-form solutions. To implement time warp with many-body physics, you would need to either keep the integration step size the same and drastically increase the amount of computation, or increase the step size and suffer from extreme inaccuracy, causing objects to crash or fly off into space. |
|
It makes things nicer at extremely high time warps, but it's not necessary. It's not like you need to update orbits nearly as often as part physics. The max time warp is 100000x, and at that speed if you updated orbits every 10 game seconds that would only be 400 calculations per tick, per craft. So without that simplification you might need a smaller cap on satellite swarms, or a max speed of 10000x, but time warp would still be well inside the realm of "possible".
Edit: You could probably get processor use really low by using an exact curve for the most influential object and a very slowly updated offset for other influences.