Patched Conics accuracy

[Kerbart]

7 minutes ago, regex said:

Minor nitpick:

So wait, what you're saying is that KSP's patched conics simulation is more accurate than one potentially written by actual scientists who would potentially use it for planning actual space missions?    How about just saying that the system can't get more accurate than those that are used in real life?  Especially since it is a demonstrably false statement if we take into account the 32/64 bit conversions KSP has to deal with because of the underlying engine; I can almost 100% guarantee you an actual space agency wouldn't stand for that were they relying on patched conics as much as we do.

The way I read it was: in real life, patched conics are an approximation (of n-body physics which in itself are an approximation of Einsteinian space-time bambalooza) where patched conics in KSP are “reality” and not an approximation of the physics that are in place.

Claw ninja'd me.

[taniwha]

3 hours ago, Kobymaru said:

for no reason

There is always a reason. You may not understand the reason, but it is there.

3 hours ago, Kobymaru said:

There are even cases where people were pinballing around in the Jool system and got Tylo surprise-encounters. Gravity-Assist pinball is hard enough if the patched conics trajectories are correct, but if they don't even show encounters in the path, now that's just mean.

This is yet another completely separate issue and has nothing to do with the precision of the math. Rather, it is search algorithms. In the general case, conic section intersections have up to four solutions, two when constrained by a shared focus. Solvers run into the problem of local minima, and as there are more than one, the found minimum can be the wrong one. Getting out of that minimum's influence to find the next can be difficult.

[Hannu2]

21 hours ago, taniwha said:

However, SoI crossing is another problem that has nothing to do with the precision of the calculations. Instead, it is all about sampling. Differences between projected and actual orbits after an SoI change are caused by differences in when you cross the SoI boundary. The projected orbit results from a calculated SoI boundary crossing time, but the actual orbit results from recalculating the orbit after "oops, we crossed the SoI boundary between last frame and this frame". This means there will be variations based on how much you were warping when you crossed the boundary, your velocity when you crossed, your exact positions on either side of the boundary, and even how far into the save you are (UT's precision will slowly drop off as the game progresses, but you will have to warp for something like 10000 game-years for it to become much of an issue).

Could KSP do something about it? Maybe. Is it worth the effort? Less likely. So long as you cross the boundary at a low enough warp (5x-50x (personally, I recommend 5x)), you should rarely lose an encounter to any planet with a largish SoI, and regaining should be cheap for smaller planets. Similar for aerobraking: have your periapsis about where you want it, cross the SoI "slowly" (warp), any adjustments should be trivial (if even necessary). I used to not warp at all when crossing SoI boundaries, but that can be a tad slow (real-time) and you then do get the fun of 32-bit/64-bit floating-point math.

If we know nearby points from outside and inside and trajectories of planet and craft, determining the time of the accurate SOI change needs only very basic equation solving techniques. It is certainly possible to do. Prediction over longer time periods during mapping can be little more difficult due to several mimima but it is also very doable and also computationally cheap in one dimensional problem like this. We can do many assumptions based on known things about solar system. In my opinion such inaccuracies are totally intolerable in spaceflight game but unfortunately Squad have different opinion. It is true, that fixing errors does not benefit in mathless eyeballing playstyle which most players probably use and Squas has made much work to make it possible. But KSP should be also able to use for more engineering like playstyle. Even if Squad does not do it, they should make the game moddable to accurate gaming.

I do not criticize patched conics model as a choice for game (here), but I criticize the fact that results of KSP's own trajectory predictions are different than actual trajectories it calculates. And these are not minor errors which can be compensated by burning couple of m/s. It is common (especially around Jool) that map view can not predict clear encounter with moons before couple of hours before encounter. Such an error typically ruins that mission completely in my style of play and it is very annoying. If there was even a simulation mode which would show positions of crafts and planets as a function of time (for example I could change time by rolling mousewheel) I could detect these encounters by myself and avoid them.

[*Aqua*]

13 hours ago, taniwha said:

This is yet another completely separate issue and has nothing to do with the precision of the math. Rather, it is search algorithms. In the general case, conic section intersections have up to four solutions, two when constrained by a shared focus. Solvers run into the problem of local minima, and as there are more than one, the found minimum can be the wrong one. Getting out of that minimum's influence to find the next can be difficult.

Is that the reason why it flickers between intercept and non-intercept in my game? Even in a simple transfer orbit from Kerbin to Minmus the orbit lines flicker so much between intercept and non-intercept that I don't know if I get caught by Minmus' influence or not until I actually cross the SoI boundary. This also happens when I'm on a collision course with Minmus.

I remember I could 'calm down' the orbit lines by timewarping a bit and then finetune the orbit but now it feels like that doesn't work anymore.

[Starwaster]

On 2/29/2016 at 2:09 AM, Spheniscine said:

For now there is the RealChutes mod, which is quite a bit more lenient on safe deployment speed (450 m/s is safe, vs the 250 m/s of stock IIRC). Also try shallower aerobraking altitudes.

Well, what it is is that RealChutes now scales part of its safe calculation (supersonic component) by atmospheric density so that less dense atmosphere are safer to deploy in, for a given speed.

[taniwha]

10 hours ago, Hannu2 said:

I do not criticize patched conics model as a choice for game (here), but I criticize the fact that results of KSP's own trajectory predictions are different than actual trajectories it calculates.

I have no problems with such criticism. It's the cargo-cult style accusations with which I have a problem, and thus I try to dispel them.

SoI crossings: I have had very little (I can't say "no") trouble with them so long as I keep warp low. I think something can be done, but it may be a lot of work and cause all sorts of other trouble in the process (if not done right).

Flickering orbits: the flickering is correct for the info KSP has. That doesn't mean there isn't a bug in there somewhere, though (heck, I still see my target vessel jump when either entering or leaving warp (don't remember which)).

Encounters: no argument at all. Tricky stuff. Again, my point is to dispel the myths, not to claim that everything is perfect. The math is accurate, but the algorithms miss sometimes (though sometimes can be all too often).

[Nich]

I have seen it where you burning prograde and your PE is moving lower and lower until BAM it just disappears and you no longer have an intercept.  this never happened in 1.0.4 for me but now adays it is quite regular when doing a perfect Mun transfer (with no overshoot)