UmbralRaptop changed the topic of #principia to: READ THE FAQ: http://goo.gl/gMZF9H; The current version is Διόφαντος. We currently target 1.3.1, and 1.4.x. <scott_manley> anyone that doubts the wisdom of retrograde bop needs to get the hell out | https://xkcd.com/323/ | <egg> calculating the influence of lamont on Pluto is a bit silly…
armed_troop has quit [Quit: Bye]
NolanSyKinsley has quit [Remote host closed the connection]
NolanSyKinsley has joined #principia
<Qboid>
5d 0h 0m 0s left to event #30: [at 2018-10-19 01:45:00]. Say '!kountdown 30' for details
armed_troop has joined #principia
Jesin has joined #principia
NolanSyKinsley has quit [Remote host closed the connection]
NolanSyKinsley has joined #principia
NolanSyKinsley has quit [Remote host closed the connection]
NolanSyKinsley has joined #principia
NolanSyKinsley has quit [Remote host closed the connection]
NolanSyKinsley has joined #principia
NolanSyKinsley has quit [Remote host closed the connection]
NolanSyKinsley has joined #principia
NolanSyKinsley has quit [Remote host closed the connection]
NolanSyKinsley has joined #principia
NolanSyKinsley has quit [Remote host closed the connection]
NolanSyKinsley has joined #principia
_whitelogger has joined #principia
_whitelogger has joined #principia
Mike` has quit [Ping timeout: 180 seconds]
Mike` has joined #principia
_whitelogger has joined #principia
_whitelogger has joined #principia
NolanSyKinsley has quit [Remote host closed the connection]
ferram4 has quit [Read error: Connection reset by peer]
ferram4_ has quit [Read error: Connection reset by peer]
_whitelogger has joined #principia
_whitelogger has joined #principia
_whitelogger has joined #principia
NolanSyKinsley has joined #principia
_whitelogger has joined #principia
ferram4 has joined #principia
NolanSyKinsley has quit [Remote host closed the connection]
NolanSyKinsley has joined #principia
uj8efdjkfdshf has joined #principia
Jesin has quit [Quit: Leaving]
Jesin has joined #principia
<Mike`>
So i kept doing moon transfer, but always was burning too long, even though i let RT burn the exact time the principia flight planner calculated. I doubted RT, burned myself, same result - until i figured out LOX boiloff in the hour between plan creation and ignition was enough to cause it, a burn time difference of a whole second. -.-
<Mike`>
need to remember to redo the plan just before ignition :S - and maybe insulate that tank a little.
<egg>
Mike`: tbh I recommend doing your burns while looking at map view and cutting manually
<egg>
Mike`: any real-life thing will have closed-loop guidance
<egg>
and the best way you can approximate that is by closing the loop by hand, at least until lamont comes with shiny principia-compatible guidance methods and functional analysis
<Mike`>
hm, well, i think using the RT computer is more precise, as it can do the burn duration timing more precise than i could by hand, that way i only need to get the start timing right
<awang>
Mike`: That depends on the burn duration actually being accurate though
<Mike`>
which does work quite well to be honest, since i figured out ignition delays of the engine i use and don't neglect this boiloff issue :D
<Mike`>
awang, it is, at least if cou create the flight plan before the burn or don't have boiloff
<awang>
Mike`: Maybe? I've found that sometimes I need to burn longer to get a orbit matching the predicted orbit
<awang>
idk if I was screwing something up though
<Mike`>
awang, have you factored in ignition delays?
<Mike`>
engines have ignition delays which you have to account for when timing the burn
<egg>
<Mike`> hm, well, i think using the RT computer is more precise, as it can do the burn duration timing more precise than i could by hand, that way i only need to get the start timing right <<< open loop is never accurate
<egg>
Mike`: the model is never accurate enough
<egg>
you have perturbations from guidance, engine response curves, etc.
<egg>
Mike`: any burn will be done with closed-loop guidance, and generally followed by a TCM with lower-thrust engines (RCS and the like)
<egg>
Mike`: it's not just ignition delay, it's a startup curve, you can't just factor that in as a fixed delay
<egg>
Mike`: just doing it with a stopwatch without controlling in map view is a bad idea, and a poor rendition of real-life behaviour
<awang>
Mike`: That's a good question that I don't have an answer for
<awang>
It's been quite a while
<awang>
I want to say yes, but I'm not sure
<egg>
awang: they're not just delays
<egg>
you can maybe get a slightly better approximation by counting them as delays, but at the end of the day it's still a bad model, and ляпунов will screw with you
<Mike`>
well, you kind of can - of course accuracy will drop, true - but all i'm saying is that RT can time a burn better than me doing it by hand - now you could argue i should not look at principias timer but the map instead and this might be more accurate - well, maybe, but it's also more work
<egg>
Mike`: RT can time better than you can time
<egg>
but you shouldn't time
<egg>
timing is open-loop guidance
<Mike`>
i'm not arguing that closed loop guidance isn't needed or anything, i'm just saying RT doing the burns works well enough (unless you don't factor in delays or boiloff)
<egg>
Mike`: and at the end of the day, if you do it by timing, you'll just get a less accurate burn, and so you'll have more manual work to do on the subsequent TCM :-p
<Mike`>
so yeah i could look at map view and try that, but for longer burns i like to tab out of the gamje etc so i might miss the cutoff aswell. ;)
<egg>
hah
<Mike`>
i hope some day MJ will get good principa support. :)
<egg>
well, poke lamont
<lamont>
eh?
<egg>
lamont is working on actual good closed-loop guidance methods
<Mike`>
but i think having to do some small correction with RCS isn't too unrealistc, at least for the 1950s? so i don't midn them if they aren't huge :)
<lamont>
sarbian gave me dev access to MJ now
<egg>
Mike`: as I said, you *always* do a subsequent TCMs
<egg>
Mike`: even nowadays
<lamont>
i think i’ve closed and triaged like 150 issues in github
<egg>
it's just that you want it to be small ideally :-)
<Mike`>
egg, yeah i know, i'm somewhat following and happily use PEG for ascents.
<awang>
egg: Ah. I was about to say "general thing about differential equations? Probably beyond my understanding then" but the Wikipedia summary is a lot more approachable than I initially expected
<Mike`>
(oh, another reason of me using RT is that you might not actually have a comm link when you need to start/stop the burn :S)
<lamont>
so its actually reasonably simple. you already have r’’ = g(r) + F/m u which is what you’re used to integrating — only F in your case is zero and u doesn’t matter, so g(r) is just the gravitational potential
<lamont>
so r’’ = g(r) is your world
<lamont>
you break that up into r’ = v; v’ = g(r);
<egg>
what is F and u?
<lamont>
phrasing!
<egg>
!u ’
<Qboid>
U+2019 RIGHT SINGLE QUOTATION MARK (’)
<lamont>
F = thrust, and u = unit vector in the thrust direction
<egg>
lamont: but surely we do have thrust?
<egg>
else what is there to prime
<lamont>
heh okay
<lamont>
yeah so anyway lets loop back
<lamont>
10.44 in that pdf is the primer vector equation
* egg
stares at the red annotations
<lamont>
p’’ = G(r)p
<lamont>
G(r) is 10.33 which is the gravety gradient matrix
<lamont>
*gravity even
<lamont>
breaking that up into first order equations: pv’ = pr; pr’ = G(r) p
<lamont>
pv’ = pr; pr’ = G(r) pv
<lamont>
so pv is the primer vector, pv is the primer rate vector which has been introduced to convert a second order diff eq to first order diff eq for integration
<egg>
right, the classical order-reducing dimension-increasing trick
<lamont>
if g(r) = - mu * r / r^3
<egg>
although if it is in second-ordre form directly it is actually better for us
<egg>
because there are integrators that can integrate 2nd order and not 1st (and are better at 2nd order than the 1st order ones on the split system)
<lamont>
huh, ‘k, well that’s fine then anyway
<egg>
lamont: and I suppose pv then feeds into r'' in some fashion, by guiding thrust?
<lamont>
yeah
<lamont>
u == pv / | pv |
<egg>
so then at the logic level: thrust(t) is something handled by the Principia manoeuvre, and the MJ layer performs an optimization on shooting with an API referring to the Principia manoeuvre
<egg>
i.e. in some fashion you shoot(Principia burn 3, {guidance initial conditions}), get some residual as a result (we need to define the residual), and optimize said residual
<lamont>
yeah, so for that g(r) for central force motion the primer vector equation is just pr’ = pv / r3 - 3 / r5 dot(r, pv) r
<lamont>
except that is missing mu because i normalize mu = 1
<egg>
I suppose the residual is some sort of norm of the difference between target and actual trajectory, in the manoeuvre reference frame?
<lamont>
so what you want is pr’’ = - mu * ( pv / r^3 - 3 / r^5 * dot(r, pv) * r
<lamont>
pr’’ = - mu * ( pv / r^3 - 3 / r^5 * dot(r, pv) * r )
<lamont>
you also need m’ = - mdot (which feeds back into F/m)
<egg>
yeah
<egg>
that's part of the manoeuvre logic
<egg>
(it means we need a fuel flow model :D)
<lamont>
so now you should have a system of 13 coupled first order differential equations
<egg>
:D
<lamont>
BUT
<lamont>
you are n-body
<lamont>
so g(r) is n-body
<lamont>
and you have J^2
<egg>
and higher harmonincs soon!
<lamont>
hateful
<egg>
lamont: the thrust curves are demented btw, they are thrust(remaining mass), meaning that acceleration(t) requires an ODE for no good reason
<egg>
(MJ doesn't know about the thrust curves, so its SRB Δv analysis might be shoddy)
<lamont>
yep, although that’s getting into the weeds. the nice thing about closed loop guidance is that its designed to compensate for unknowns in vehicle performance
<egg>
true
<lamont>
and yeah so its all a matter of guessing the IVP (13 variables), shooting, and then computing a miss against 13 constraints (7 initial constraints on r, v, and m and 6 target constraints)
<egg>
lamont: hmm that gravity gradient matrix is basically a hessian?
<egg>
if we need the hessian of our gravity this is getting into Fun territory,
<lamont>
jacobian?
<lamont>
hessian is like the 3-dimensional second derivative isn’t it?
<egg>
lamont: well it's the Jacobian of the force, or the Hessian of the potential
<egg>
since the force is the gradient of the potential
<lamont>
ah
<lamont>
yeah
<egg>
yeah that sounds Fun
<lamont>
so i have a book with the G(r) formula for n-body
<egg>
especially since we are planning to have limited-range higher harmonics (and J2)
<egg>
so the range-limiting sigmoid needs te be derived and come into the Hessian
<lamont>
yeah i don’t know if you want to numerically compute that or analytically compute that
<egg>
numerical differentiation is hell
<egg>
no, we just need to do it
<egg>
lamont: but as you said, closed-loop means we can do it gradually
<egg>
lamont: when not under thrust, to compute the residual on the trajectory, we can use the ordinary integration
<egg>
lamont: when under thrust, we can first try just central potentials and see where that leads us, and then add J2, and then do it right
<egg>
and fall back on our feet thanks to closed-loop correction
<egg>
(and debug the actual logic errors in the process, because there will be a bunch of those at the intersection of two mods :-p)
<egg>
lamont: how do we want to compute the residual though
<lamont>
i can compute the residual
<egg>
!u
<Qboid>
U+0010 (␐)
<Qboid>
U+0010 (␐)
<lamont>
i just need you to shoot the IVP for me
<egg>
there are two issues there
<egg>
interchanging a trajectory is way messier than a residual
<egg>
and the target trajectory is also a Principiaish thing
<egg>
in particular because it is equipped with a target reference frame
<lamont>
the residuals are stupid because they’re not just misses in r - r0, v - v0 kind of sense — although that is one special kind of residual
<egg>
if you want to go to L4, getting an orbit that looks the same in ECI is a bad idea
<egg>
you want an orbit that looks the same in EMB
<egg>
and the target trajectory will be known by Principia too anyway
<lamont>
you wind up with 6 equations but they’re very messy and if some variables are unconstrained you need to substitute transfersality conditions (like optimizing the LAN of a launch — leaving it free for the optimizer)
<egg>
lamont: the thing is you can't really compute meaningful residuals for things that aren't supposed to be 2-body orbits
<lamont>
hrm
<egg>
how would you compute residuals on WSB transfers, tomfoolery around Lagrange points, etc.
<egg>
lamont: we can, because we have the reference frames
<egg>
lamont: basically Principia's flight planner knows 1. some trajectory you want to get to (and can) 2. the engine/mass setup with which you intend to get there (kinda flimsy right now but I'll improve it) 3. which reference frame you use to look at this trajectory
<lamont>
it has one chapter which is basically a duplicate of prussing’s PDF
<egg>
to guide to that meaningfully you need all three
<egg>
lamont: hm, i should buy that
<lamont>
but chapter 4 page 4.37 has the n-body G(r)
<lamont>
yeah lots of that book are still over my head
<egg>
shiny cover :-p
<egg>
lamont: meanwhile, users #1963
<Qboid>
[#1963] title: Supporting preplanned flights (eg RemoteTech) | I had my first attempt at launching a satellite with Principia. Unfortunately I had communications blackout at apoapsis. Planning a manouver into the flight computer was really awkward because the manouver nodes don’t allow remotetech to do a burn that is even remotely large enough. I ended up having to type time offsets manually i
<egg>
"What I expected was a single button to transfer the best estimate of the burn into the flight computer.
<egg>
"
<egg>
welp
<egg>
duplicate of #1894, #1894 I suppose :-p
<Qboid>
[#1894] title: Is there a way to auto execute maneuvers? | As the title said, is there a way i can either auto execute a node OR make the navball deltav work properly? | https://github.com/mockingbirdnest/Principia/issues/1894
<Qboid>
[#1894] title: Is there a way to auto execute maneuvers? | As the title said, is there a way i can either auto execute a node OR make the navball deltav work properly? | https://github.com/mockingbirdnest/Principia/issues/1894
<egg>
s/94/71/
<Qboid>
egg meant to say: duplicate of #1871, #1894 I suppose :-p
<lamont>
so we still need a way to integrate mechjeb maneuver planning with principia
<lamont>
“circularize at apoapsis” should still be a thing, even if its an inexact thing
<lamont>
and if you’re at a lagrange point and its nonsense it can just throw back yellow “i’m sorry dave, i can’t do that” exceptions at you
<egg>
lamont: a lot of those manoeuvres *are* meaningful, but only in a body-centred-inertial environment
<lamont>
right
<egg>
e.g. "circularize at apoapsis" is "burn at apoapsis such that the global distance minimum is close to the current altitude"
<lamont>
MJ’s maneuver planner already has a lot of “if ( situation is nonsense ) { throw new Exception(“nope”) }” stuff
<egg>
so I suppose "circularize at apoapsis" in MJ/Principia mode would set the manoeuvre to ECI, and then optimize the plan til the final orbit is roundish (or fail if the optimizer doesn't converge because there's a moon in the way)
<egg>
that means there needs to be a direct API for MJ to *make Principia manoeuvres*
<egg>
(and probably read off things like "lowest altitude over the prediction" etc.)
<lamont>
yeah
<egg>
sounds like lots of API fun
<lamont>
i really still think you should wire up maneuver nodes to principia orbits
<egg>
that really doesn't work nicely
<egg>
they just have too little information
<egg>
and also their data model is all tied into the patched conics which makes logic hellish if the patched conics are full of lies
<lamont>
can you have a PrincipiaManeuverNode that wraps a ManeuverNode that is place on an orbit that carries the rest of the info?
<egg>
here's the thing, the API can't be the same without being full of lies
<lamont>
actually forget KSP’s ManeuverNodes
<lamont>
design a PrincipiaManeuverNode
<lamont>
it can be dropped at a UT, with a dV and a reference frame the dV is in and whatever other information you need
<lamont>
the location of the maneuver node is drawn at that UT time in the principia orbit curve on the display
<egg>
well, our nodes aren't instant-impulse, so that's a bit more involved than just a Δv
<lamont>
yeah, you should just do instant-impulse for plannings sake
<egg>
(the "instant impulse" one is a hack, it's really just a very fast burn fed to the integrator :D)
<egg>
lamont: well, I like the idea of being able to plan only possible things
<egg>
better chance of the guidance converging
<lamont>
yeah but this is how missions are often actually planned though
<lamont>
because maneuvers are usually very impulsive compared to the long coasts between them
<egg>
something something ion engines something
<egg>
lamont: however given a burn configuration, there is such a thing as a thing that takes time, Δv, direction specification
<egg>
and it exists, in the C++ (not a stable API, but it exists)
<egg>
so given an API, MJ could conceptually create those
<lamont>
yeah and then reuse roughly the same widget from the KSP maneuver node. maybe make it purpleish
<egg>
that part is tricky
<egg>
because I cannot into KSP UI logic
<lamont>
hrm
<lamont>
KAC does stuff to drop widgets on the orbit?
<egg>
but tbh the widget isn't really relevant to the MJ/Principia interactions
<lamont>
yeah i mean its not, i was just thinking from UX perspective
<egg>
if MJ wants to create a Principia manoeuvre, it needs an API, not a widget
<egg>
lamont: yeah
<lamont>
okay, just made it editable from the MJ node editor then
<egg>
I'm bad at UX
<egg>
formicant tried looking into it and vanished into the air
<egg>
Hover through the fogge and filthie ayre
<lamont>
the thing i like about resuing the KSP ManeuverNode itself (maybe either assuming body-centered-inertial always, or else having some UX on the side to tweak the reference frame) is that then everyone’s favorite maneuver node edtor would Just Work
<lamont>
*reusing
<lamont>
but then principia would draw the maneuver node in the correct place, and would draw an orbit out of the maneuver node that was the correct N-body orbit
<egg>
"assuming body-centered-inertial" << this part really isn't good enough
<lamont>
‘k, then have some way to tweak it in principia’s UX
<egg>
hm
<lamont>
but if you have a plain maneuver node object, vanilla KSP tools can grab it
<egg>
lamont: okay so just using ManeuverNode as an API... hmm.
<lamont>
then you could have some extended API to grab the *REAL* principia maneuver object
<egg>
(otoh I need to supress the widget and draw my stuff obviously, but that might make sense)
<lamont>
so then MJ could grab that, and then could extend the node editor to be able to manipulate the reference frame and whatnot
<egg>
I'll have to poke at it
<egg>
yeah, and the engine set (which MJ knows about anyway, in parallel), etc.
<lamont>
yeah and then you don’t necessarily need to draw the maneuver node widget
<egg>
good because I don't know how to draw it :-p
<lamont>
yeah
<egg>
but I'm unsure how to encode non-ECI burns in there
<lamont>
lemme write up an issue
<egg>
non-ECI burns will be utterly mangled by something that assumes it's a realy KSP ManeuverNode
<egg>
s/realy/real/
<Qboid>
egg meant to say: non-ECI burns will be utterly mangled by something that assumes it's a real KSP ManeuverNode
<egg>
but yeah, I see the point of keeping the stock data model
<lamont>
let me write it up
<egg>
lamont: it does mean that you *must not* interpret the ManeuverNode yourself, its Δv will be a lie (potentially a really bad one if the reference frame is different), its time will be only time of ignition, etc., but at least it allows editors to work in a write-only fashion
<lamont>
yeah, lemme write up
<egg>
[note: it will take me a while to get to that, we're very much entangled in the higher-order harmonics stuff right now]
<egg>
[also there's the mac mutex that will need poking because it's too damned slow]
<lamont>
isn’t there a bot for every new opened issue?
<Qboid>
[#1964] title: Support KSP ManeuverNodes as an API in Principia | The idea here is to allow vanilla node editors to work with Principia out of the box. So the idea is that a Node Editor could grab `vessel.patchedConicSolver.maneuverNodes` and be able to edit the UT and dV of future maneuver node(s). Prograde/Radial/Normal will be translated into Tangent/Normal/Binormal by Principia. There
<Qboid>
needs to be another Principia object which will track what the reference frame and other principia state information is. The `vessel.patchedConicSolver.maneuverNodes` API will be a simple [Facade](https://en.wikipedia.org/wiki/Facade_pattern) over the real thing. Principia will turn off that patched conics and the display of the maneuver node widget itself (it won't be editable from the screen).
<Qboid>
Principia will draw the current orbit out to the point of the node, then draw the outgoing orbit. The result will be that a user can install something like PreciseNode and then tweak the three components and the time of the burn.... | https://github.com/mockingbirdnest/Principia/issues/1964
<egg>
lamont: "This would require making the information two-way.
<egg>
" << this part is tricky, because we try to make the manoeuvre that we show with "show on navball" somewhat consistent with reality rather than a pile of lies, but it means that in the data model (prog. rad. norm.) it doesn't correspond to the TNB components
<lamont>
maybe that was a mistake?
<egg>
lamont: well, if it's shown on the navball it better align with where you want to burn :D
<lamont>
hrm
<egg>
lamont: might be feasible by somehow injecting crap into the patched conics
<egg>
so that the conic patch is has the right frenet frame at the right time
<lamont>
yeah i don’t know how to resolve the tension between drawing shit on the navball and having the number be the same for UX for node editing
<egg>
but that seems fairly tricky, in particular because you can't make arbitrary conic patches: the radial in thing will have to point in, rather than out, and the normal may point wherever on a silly trajectory in a silly frame
<lamont>
so....
<lamont>
maybe what you do is you stop using the ManeuverNode to draw on the navball
<egg>
yes, that could work, but then we're back to the problem of interfacing
<egg>
lamont: we already move the navball vectors around, and override the ASAS behaviour
<egg>
lamont: and I seem to recall that those bits of mechjeb now call the ASAS stuff somehow
<egg>
so if we can override ASAS for the node too we're good
<lamont>
MJ does its own stuff
<egg>
argh
<egg>
yeah then we're screwed
<lamont>
ja
<lamont>
but see my comment
<egg>
lamont: hm, if we have an API it might as well talk directly to the Principia C++ flight plan
<egg>
though I suppose that requires more work on your side than the existing interchange format
<lamont>
yeah, if you keep it simple it will be easier for other people to integrate with other UXes
<egg>
good point
<egg>
and I suppose one could even figure out how to conjure a stock widget out of that thing to placate those who like that widget (though that's more work than I'm willing to put in widgets)
<lamont>
can you implement a PrincipiaNBodySolver? that has a List<ManeuverNode> maneuverNodes hanging off of it that are all in tangent/normal/binormal?
<lamont>
or something like that
<egg>
and make all the orbits null or something i suppose
<lamont>
a lot of that makes no sense, but AddManeuverNode and RemoveManeuverNode would
<lamont>
yeah
<lamont>
null or nonsense your choice
<egg>
null, I abhor nonsense
<lamont>
null it is then
<egg>
no nasal demons in my orbits
<egg>
lamont: is everything there virtual?
<lamont>
i was not thinking of using inheritance
<egg>
how are you going to make it work with existing tooling then
<lamont>
it wouldn't
<lamont>
it would just be easily modifiable rather than plugin-in
<lamont>
*plugin
<egg>
hmm
<egg>
lamont: at this point then it might as well not be a ManeuverNode, merely some thing that contains a vector of the burn components
<egg>
at which point we're just defining an API for the Principia flight plan
<lamont>
yeah but if you pass back ManeuverNodes, or something that inherits from ManeuverNodes then a lot more existing code works unmodified
<egg>
lamont: hmm there's a nodeRotation
<egg>
what does nodeRotation do
<lamont>
you don’t necessarily need to make it all make sense
<egg>
lamont: no, what I mean is can we use nodeRotation to make the original idea work
<lamont>
oh that’d be cool
<egg>
in nodeRotation there's enough to convey the reference frame
<egg>
is it actually used
<lamont>
uh no though?
<egg>
it's not used by KSP guidance, but is it used by MJ guidance
<lamont>
because MJ just reads the dV and points that way
<egg>
wot
<egg>
but the Δv is in the prograde/radial/normal frame
<egg>
... oh. and that's based on the patchy conics.
<egg>
welp.
<egg>
hm
<egg>
GetBurnVector isn't virtual either
<lamont>
so it calls node.UpdateNode(new Vector3d(radialPlus, normalPlus, prograde), node.UT); to update
<lamont>
oh it just calls node.DeltaV.z to get the values
<lamont>
what is the difference between GetBurnVector and DeltaV
<lamont>
ohhhhh
<lamont>
yeah KSP already does this
<egg>
DeltaV is in the Frenet frame iirc?
<lamont>
frenet is prograde/normal/radial?
<egg>
yeah
<lamont>
yeah that’s frenet, while GetBurnVector is worldspace
<egg>
yeah
<egg>
so we would need GetBurnVector to return the actual worldspace direction
<egg>
affected by the principia frame
<egg>
with DeltaV being the data interchange
<egg>
this could be done by forcefully shoving things into nextPatch
<egg>
"the orbit wot has the right velocity difference at the right time"
<egg>
(then there's the problem of the non-inertially-fixed burns)
<egg>
so really we want "the orbit wot has the right velocity difference at the right time", where "the right velocity difference" depends on current time
<lamont>
yeah i got nothing on the implementation details
<egg>
that actually seems feasible though
<egg>
inject nextPatch and it should come out right
<egg>
sure the ManeuverNode will be internally inconsistent, but it's KSP, it's like that out of the box
<lamont>
yep
<egg>
lamont: so the important thing is that we need to do that after PatchedConicSolver.Update
<egg>
more fun scheduling I suppose
<lamont>
details...
<egg>
betterlatethannever, etc.
<lamont>
just consider that if you allow peopel to use PreciseNode, MJ Node Executor, whatever, then you dodge all the UX complaints…
<egg>
yeah
<egg>
where the hell is node.UpdateNode
<egg>
I can't find anything called UpdateNode
<lamont>
i bet that’s a mechjeb extension
<egg>
lɒl
<egg>
lamont: so it probably updates the nextPatch too
<egg>
probably by making the solver update itself
<egg>
lamont: which means that while you're tweaking the node, the navball may look wonky because if it picks that up
<egg>
I guess I can remedy to that by running just after MechJeb to clean up
<lamont>
so MJ has its own WorldDeltaV calculator
<lamont>
that is used only in the Merge functionality of the NodeEditor
<egg>
MJ is like Principia, it seems to have its own everything :D
<lamont>
i would say you ignore that as a bug in MJ where we should be calling GetBurnVector()
<egg>
I don't know what Merge does so yup, I'll ignore it :-p
<egg>
as long as guide-to-burn etc. work I'll be happy
<egg>
lamont: right, UpdateNode does UpdateFlightPlan
<egg>
that's the important part, that resets nextPatch
<egg>
so I need to come after that and clean up
<lamont>
ja, i forgot about the tapdance that was necessary to update a maneuvernode
<egg>
lamont: is that in MechJeb's Update or FixedUpdate