Autostaging issue
Sinomen opened this issue · 11 comments
KSP 1.12.3, MJ#1197
Autostaging doesn't work properly anymore on several time tested rockets: radial attached LfOx booster stages with tanks and engines and fuel lines to the core stage are not separated anymore when their tanks run empty. Could reproduce this on different rockets, e.g.: https://kerbalx.com/VoidSquid/Early-Career-Mun-Lander-1P
Did some tests, last version it worked was 1155, since 1156 all version show this bug.
"Makes me wonder what I broke..." @lamont-granquist
I see a lot of new builds since 1155, what do I miss/lose staying with that version?
And what is the "Dormant Prince", I'm curious?
Nothing much, I've been writing numerical code, it is all very deep plumbing right now. Although I found one fairly horrible bug in the pooling and reuse of interpolants which might be affecting PVG. Also there's the bugfix to let PVG work with the delta-V window closed.
Dormand Prince is a runge-kutta scheme. So if you start with basic RK4 an extension of that is something like Runge-Kutta-Fielberg 4(5) with adaptive step sizes. A further adaptation of that would be the Dormand-Prince 5(4) scheme which has some nice features like FSAL (first-same-as-last) and a free interpolant (which is now properly implemented in the new code). Everything got cleaned up from the garbage I wrote first and it looks a bit more like the IVP integrators in scipy. There's also Dormand-Prince's 8(5,3) method which is higher order and I might implement that one as well. I already implemented Bogacki–Shampine 3(2) which is for stiff systems and takes small step sizes (otherwise similar though with FSAL and you can use cubic hermite interpolating polynomials as a free interpolant). One of those might work better for PVG convergence in difficult problems (the situations where it fails with "target unreachable") which might allow it to give back better information to the user. The event support that got added means that it can do things like integrate a trajectory up until an event (such as impact with the ground, or when conditions are reached to fire 'cutes or something). That should allow me to do a fully numerical simulation for integrating the suicide burn countdown timer to actually finally fix that. And then it should be able to clean up the ReentrySimulation code. Overall it makes the IVP/ODE solver code roughly as-functional to stuff like Matlab's ode45/ode23. I think there's a couple other details still left though like the initial step size guess needs to be improved, and the minimum step size needs to be based on the actual next floating point number, plus needs to be configurable to either throw or just take the step at the minimum.
Wow, that's a pretty fast and pretty deep dive (pun intended). Last time I did serious math is some 30 years ago, quantum mechanics (Hartree-Fock), and spectroscopy, this here is way over my head. But it looks very, very interesting, I definitely will have a deeper look at it, thanks for the explanation!
Hmm... been a month now, and with every new version I lag behind more and more. Any ETA for fixing this bug?
might be fixed now
It actually is!
Big thank you to @Nazfib and @lamont-granquist , much appreciated. :)
Thanks to @Nazfib who fixed the bug, I just wrote it...