egg changed the topic of #principia to: Logs: https://esper.irclog.whitequark.org/principia | <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…
_whitelogger has joined #principia
_whitelogger has joined #principia
_whitelogger has joined #principia
_whitelogger has joined #principia
<queqiao->
⟨pound_of_cheese⟩ am i weird for preferring the way ksps regular maneuver node worked?
<queqiao->
⟨pound_of_cheese⟩ specifically the way regular maneuver did maneuver time
<queqiao->
⟨pound_of_cheese⟩ because with it you know that the midpoint of your burn is at that specific spot
<queqiao->
⟨pound_of_cheese⟩ whereas with princip if im launching to the moon i have to fiddle with time to hope to get close
<queqiao->
⟨pound_of_cheese⟩ to be clear, a actual burn timer is very much apreciated
<queqiao->
⟨pound_of_cheese⟩ i just sorta wish principias maneuver node was located where the midpoint of your burn is, not the start
<queqiao->
⟨thebigdoi⟩ You can just use Mechjeb to do the burn for you
<queqiao->
⟨GoForPDI (less drag=more faster)⟩ That was actually the one gripe with KSP2 maneuver nodes, that they weren’t centered on the middle of the burn, making finding the right time to burn for circularizations or whatever that much more difficult
<queqiao->
⟨GoForPDI (less drag=more faster)⟩ * my
<queqiao->
⟨skyphoenix999⟩ Actually I like that
<queqiao->
Never have to do mental math or anything like that, just start the burn at the node
<queqiao->
⟨skyphoenix999⟩ You don't have to mess around much to figure out where you need to burn for a circular orbit, especially since the old way of doing things wouldn't get you into a circular orbit anyway
<queqiao->
⟨GoForPDI (less drag=more faster)⟩ But to actually _plan_ it, you had to fiddle with it instead of just placing the burn at apoapsis
<queqiao->
⟨GoForPDI (less drag=more faster)⟩ Since it was where the burn started, not the midpoint
<queqiao->
⟨egg⟩ The midpoint in time isn’t a particularly good approximation of an equivalent instant burn though. The time of half-Δv might be more relevant (but then obviously the relations between time and true anomaly and between time and Δv expended are different so it is all a mess anyway).
<queqiao->
⟨egg⟩ In any case, the answer is to look at the noodle. Use the noodle. The noodle will be with you, always.
<queqiao->
⟨test_account9540⟩ Time of half-Δv kind of works for very short burns, such as an unguided TLI with baby sergeants. It's possible to hit the moon this way. But burns that last even dozens of seconds already suffer from the shape of orbit changing during the burn and using time of half dV results in missing the moon.
_whitelogger has joined #principia
<queqiao->
⟨pound_of_cheese⟩ I’m not saying to change how the actual manuever is calculated
<queqiao->
⟨pound_of_cheese⟩ What I’m saying is if it’s using an engine, it offsets the manever node time by half the burn ev
<queqiao->
⟨pound_of_cheese⟩ * the time needed to burn half the dv
<queqiao->
⟨egg⟩ Yes, we understand what you mean
<queqiao->
⟨pound_of_cheese⟩ Oop sorry ping
<queqiao->
⟨pound_of_cheese⟩ See the reason I suggest it is you’ll need a lot less faffing about with time to deliver moonsmacj
<queqiao->
⟨pound_of_cheese⟩ You’ll still need some, I don’t think you can hit the moon by eye
<queqiao->
⟨pound_of_cheese⟩ But you’ll be far closer
<queqiao->
⟨egg⟩ Again, I get it. What you are ultimately want here is to have a marker at a position that is close to where an instant burn that achieves the same thing would be. But mostly this is not an intuition that usefully generalizes to more interesting things, so we don’t really care for it. And the noodling is very quick nowadays, especially with Al₂Me₆’s draggable markers.
raptop has quit [Ping timeout: 183 seconds]
raptop has joined #principia
<queqiao->
⟨lamont⟩ (i still think planning should be all true instant impulse with the markers at that point, and it should be up to a finite burn planner/executor/optimizer to figure out the optimal ignition point and to drive the vessel towards the target orbital conditions--but this is still something that doesn't yet exist in the KSP universe and the stock maneuver node updates are some kind of jank that i don't understand and certainly aren't...
<queqiao->
⟨Al₂Me₆⟩ 🔮 says: please read the FAQ, in particular the section on Parallax. You'll need to start a new save after installing the retrobop cfg.
<queqiao->
⟨champ0220⟩ ah alright
<queqiao->
⟨clayel⟩ "an apocalypse occured" is a hilarious error message
<queqiao->
⟨Al₂Me₆⟩ ^ I believe that to be the reference
<queqiao->
⟨egg⟩ Indeed. The backstory here is amusing.
<queqiao->
As the error message says, the actual issue here is that we are unable to fit a smooth polynomial to the trajectory, that is, the celestial moves very suddenly—or even jumps. We first ran into this issue not because of celestials being flung around because of an unstable system, but because of a bug that caused the celestials to be permuted—so that one celestial would suddenly end up in another’s place, leading to such a jump in the...
<queqiao->
... trajectory. We ran into it in game and saw the celestials in the wrong places, so we added a check that would have caught that kind of bug.
<queqiao->
Of course, permuting the celestials is exactly what happens in that « apocalypse » diagram…
<queqiao->
⟨egg⟩ (And then this turned out to catch systems that were so unstable that we could not approximate them, so eventually we turned the check into a modal window, partly to get fewer bug reports, but also so that solar system administrators could inspect the issue in-game.)