04:45 <discord-_> C​handy. — the manuever node delta v countdown thingy isn't changing as i go along. can anyone help with that? sorry if this is basic but i'm new to using principia

04:46 <discord-_> l​pg. — that's normal

04:46 <discord-_> l​pg. — principia's flight plan's time countdown is the only indicator you get

04:47 <discord-_> C​handy. — so i should base it all on that?

04:47 <discord-_> l​pg. — base what on what

04:47 <discord-_> C​handy. — is that also why it deletes the manuever while i'm burning

04:47 <discord-_> C​handy. — the bunrs

04:47 <discord-_> C​handy. — the burns (edited)

04:48 <discord-_> l​pg. — you start burning when the flight plan tells you to, and stop when it tells you to

04:48 <discord-_> l​pg. — pay no attention to the stock indicators

04:48 <discord-_> C​handy. — Okay. thank you

04:48 <discord-_> C​handy. — that makes alot more sense haha

04:50 <discord-_> l​pg. — one caveat: the flight plan isn't aware of RO's non-instantaneous ignitions. so in reality you want to throttle up somewhat before what the flight plan says, and you'll have to figure out on a per-engine basis how much that "somewhat" is

04:50 <discord-_> C​handy. — probably like a couple seconds beforehand?

04:50 <discord-_> l​pg. — around that, yes

04:50 <discord-_> C​handy. — Okay

04:50 <discord-_> C​handy. — thank you so much

04:55 <discord-_> C​handy. — what about all the predicted future orbits? is there a way to toggle them?

04:58 <discord-_> A​nomaly. — Have you read the documentation available for Principia?

04:59 <discord-_> C​handy. — the github page? i read a little but i'll read it all now

04:59 <discord-_> C​handy. — probably should've done all of it first

06:54 <_whitenotifier-9244> [Principia] Wint3rmute starred Principia - https://git.io/JJa7H

07:16 <_whitenotifier-9244> [Principia] polemius starred Principia - https://git.io/JJa5r

08:19 <_whitenotifier-9244> [Principia] dnswd starred Principia - https://git.io/JJaFl

08:19 <discord-_> R​ipper2900. — In my opinion, the burntime calculations and also executing them is one of the biggest issues with principia.

08:19 <discord-_> R​ipper2900. — In the early stages of the game, I have the technique of using a guided stage to eg line up with a translunar burn, and then decouple and start a spinstabilized unguided stage to execute that burn. But principia can only calculate burns with the current motor, and I'm using the one from the NEXT stage. This basically invalidates the burntime calculation.

08:19 <discord-_> R​ipper2900. — Later in the career, the ignition delay is the biggest factor - specially with shorter burns.

08:19 <discord-_> R​ipper2900. — MJ can not help, as it inevitably ends up underburning.

08:19 <discord-_> R​ipper2900. — The burntime START indication of principia is a great way to indicate when to execute the burn, but when to END the burn should be governed by the dV spent, imho. Not the time.

08:26 <discord-_> R​ipper2900. — A dV countdown would really be a help to hit the fligtplan better - for me at least.

08:26 <discord-_> R​ipper2900. — The only good solution, I've found is to look at the mapview and stop the burn when the planned and the predicted trajectories line up.

10:02 <discord-_> e​gg. — yes, this is how you should do it.

10:03 <discord-_> e​gg. — you need closed-loop guidance if you want accuracy, and you have to do that by hand (looking at map view) because we are not in the business of writing an autopilot; @lamont is.

12:27 <discord-_> s​cimas. — If the future position from the prediction were exposed - respecting the prediction settings like steps and tolerance - everyone could write an autopilot 😁

12:52 <discord-_> F​arrier. — Yeah, but to stop full-throttle burn even roughly in time while looking at the map you need some superhuman reaction. 😖

13:20 <discord-_> B​utcher. — I use kos to burn for the required amount of dv.

13:40 <discord-_> e​gg. — @scimas not really, because you would need to think about what you are trying to optimize (timing/position of a specific event in some reference frame? least squares fit of the trajectory in a given frame? many many options), and most optimization techniques want to know about the equations of motion, at which point you need to be tied into Principia for gravitational computations. @lamont has been t

13:40 <discord-_> e​gg. — As usual, nothing is simple.

13:43 <discord-_> l​pg. — for more accurate hand burns, I'm told Better Burn Time <1x warp helps

13:47 <discord-_> D​amien. — *The Reach Method*

13:49 <discord-_> l​pg. — err. or is that Better Time Warp?

13:52 <discord-_> D​amien. — The second one

14:02 <discord-_> B​utcher. — Ugh, wish I thought of this sooner, I have just massively simplified my lunar missions.

14:40 <discord-_> s​cimas. — @egg Exactly, all I want is some quantity that I _can_ optimize for. Burning a specific amount of dv doesn't seem to be good enough. Either you burn full throttle the whole time to have the manoeuvre node guidance and lose some dv accuracy (because you can't start or stop the burn in the middle of physics ticks) or you throttle down towards the end and lose the guidance and keep burning past the b

14:52 <discord-_> e​gg. — > seems like the easiest

14:52 <discord-_> e​gg. — Nothing is simple, it all gets more complicated, if you build upon it it will break.

14:52 <discord-_> e​gg. — Any API has a fairly heavy maintenance cost, because we must make sure that we don’t break users that we don’t know about, because we must have clean and documented error handling (whereas within principia we simply crash if we violate our own invariants), and because unless it is carefully designed it can easily restrict future changes to our internals.

14:52 <discord-_> e​gg. — Guidance in particular is a very hard problem, and we need to think about something robust.

14:52 <discord-_> e​gg. — It is easy to say things that are ill-defined, harder to say things that are well-defined and useful (position? in what frame? how do you interchange frames through the external API? some estimated time? estimated how/why? etc.).

14:52 <discord-_> e​gg. — > I simply have no way of telling how well I executed the burn

14:52 <discord-_> e​gg. — In the meantime, looking map view tells you that (and Better time warp allows you to act on it if your acceleration is unmanageably high).

15:06 <discord-_> e​gg. — I believe @lamont has some plans for guidance that should be extensible to Principia *in close-to-Keplerian cases* while requiring only a minimal API, but I am not sure of the specifics (and this is likely a while away on both sides, there is only one lamont and two of us on Principia)

15:08 <discord-_> s​cimas. — > position? in what frame?

15:09 <discord-_> s​cimas. — I don't really care as long as it is consistent. Going with the same TLI example: I would need the position of the vessel and the Moon at some time t. As long as the returned positions are in the same frame, their relative position should be the same irrespective of the frame.

15:09 <discord-_> s​cimas. — > how do you interchange frames through the external API?

15:09 <discord-_> s​cimas. — I don't want to. That is why I said "respecting the prediction settings" in the first message in this conversation. What I meant was respecting the settings in the Principia main window, which is the plotting frame, tolerance and steps.

15:09 <discord-_> s​cimas. — > some estimated time? estimated how/why?

15:09 <discord-_> s​cimas. — That is not an estimate I'm asking Principia to make. Sorry if that wasn't clear.

15:09 <discord-_> s​cimas. — > looking map view tells you that

15:09 <discord-_> s​cimas. — Of course, but we're talking about the possibility of automating the process of node execution. The computer can't "look" at the map view.

15:09 <discord-_> s​cimas. — Anyway, I can respect that you want a more well defined API.

15:11 <discord-_> e​gg. — if you use the prediction settings, you have an API which is halfway tied to the UI, because that is how you set the prediction settings; this is a very messy coupling. Your guidance will start depending on what the player may have looked at last, even if the player is no longer looking at map view

15:13 <discord-_> s​cimas. — Are you saying that the trajectory predictions are only updated when we are in the map view?

15:14 <discord-_> e​gg. — that is true, too, though it is not necessarily tied to what you are saying

15:14 <discord-_> e​gg. — the prediction is extremely costly, so it is computed asynchronously, less than once per frame, and only if needed

15:15 <discord-_> e​gg. — (or rather it *can be* extremely costly, depending on settings)

15:15 <discord-_> s​cimas. — Okay, that makes sense, I wasn't aware that it isn't updated all the time.

15:16 <discord-_> e​gg. — but here we get into a deeper point: everything quickly ties into messy innards of Principia

15:16 <discord-_> e​gg. — it used to be computed at every frame, and making it asynchronous was a massive performance improvement

15:16 <discord-_> e​gg. — (took us a couple of months, too)

15:17 <discord-_> s​cimas. — And for the record, I'm not opposed to changing the prediction setting through an external API and so decoupling it from the UI. I was only stating that for my particular use case it wouldn't be necessary.

15:17 <discord-_> e​gg. — had we had an API that required it to be fresh, we would not have been able to do that easily

15:17 <discord-_> e​gg. — no again you are entirely misunderstanding: we do not want to expose everything through an API, because those things may cease to exist in a meaningful form tomorrow

15:18 <discord-_> e​gg. — "where was this vessel yesterday" (+ technicalities re. frames and error handling) is an API we have, because that is something that we are reasonably confident will remain meaningful, and we have a very concrete, certain, and stable use case for it

15:22 <discord-_> s​cimas. — > no again you are entirely misunderstanding: we do not want to expose everything through an API

15:22 <discord-_> s​cimas. — I didn't ask for everything to be exposed..? I only talked about it because you brought up changing the frame through the external API.

15:23 <discord-_> e​gg. — You mentioned the prediction setting; that is a coupling to the prediction, which is a UI/visual thing

15:23 <discord-_> e​gg. — perhaps this whole "future position" thing should instead involve a separate trajectory which is not the prediction, and is computed with different settings

15:24 <discord-_> e​gg. — in which case an API for all of its settings needs to be defined, and the computational cost must be taken into account

15:24 <discord-_> e​gg. — but quickly we are talking about weeks of work

15:24 <discord-_> e​gg. — work that I am unlikely to find interesting, too

15:30 <discord-_> s​cimas. — > You mentioned the prediction setting; that is a coupling to the prediction, which is a UI/visual thing

15:30 <discord-_> s​cimas. — Okay.

15:30 <discord-_> s​cimas. — > but quickly we are talking about weeks of work

15:30 <discord-_> s​cimas. — I was hoping to avoid just that with my proposal of using the existing prediction things, but you have already clarified that it wouldn't work. So I'm not going to ask you implement an entirely new thing on the very priliminary proposal I gave.

15:31 <discord-_> e​gg. — Nothing is simple :-) Speaking of which, I am able to reproduce that final time rebase bug, but I have no idea what is going on...

15:35 <discord-_> e​gg. — @scimas note though that there is hope on the guidance front, since lamont, who has done a lot of research on guidance methods that have a tendency to actually work, has outlined that there might be a way to get away with a fairly small amount of coupling (just asking for the planned state at the end of the burn), and that this should be enough to guide reasonably well in reasonably-Keplerian situati

15:43 <discord-_> s​cimas. — Of course I have no idea how lamont plans to do it, but I don't know how getting the planned state would help. I can already manually enter the planned state in code, the problem is I can't match that planned state with the actual state without numerically integrating the trajectory into the future. And if the situation is reasonably-Keplerian, I can already rely on the values provided by KSP, wou

15:44 <discord-_> e​gg. — reasonably-Keplerian, but still involving engines

15:44 <discord-_> e​gg. — the game doesn’t integrate the engines for you

15:45 <discord-_> e​gg. — (and then whatever internal parameters your guidance logic wants to integrate together with the motion)

15:45 <discord-_> e​gg. — the PV in PVG, for instance

15:46 <discord-_> e​gg. — consider, e.g., that PVG is pretty good at launching into the right orbit with Principia, even though it disregards J2 which is quite significant on Earth

15:46 <discord-_> s​cimas. — No, it doesn't integrate the engines, but I can always observe the current state. And base my guidance solely on how "close" the current state is to the planned state.

15:49 <discord-_> e​gg. — that is unlikely to be a very good guidance method, but if it works then it should work well enough in Principia too (again, consider PVG launches and J2-induced error, it is not that bad)

15:51 <discord-_> e​gg. — (and conversely, launch-to-orbital-parameters *taking perturbations into account* is a really nasty problem, because then you start having to optimize for mean elements, the things shown by the orbital analyser, which means you need to compute them and likely some jacobian involving them, and mean elements are a weird salad already)

15:55 <discord-_> s​cimas. — I will admit that I was only talking about "Moon" because you people tend to play with RSS. I personally don't, so can't talk about complications arising with J2 and company. But even my hacky kOS script does a good job of launching into the right orbit. There really is no problem when operating very close to single celestial bodies. It's just that a lot of interesting stuff happens in the non-Kep

15:56 <discord-_> e​gg. — that is actually very close to Keplerian where it happens

15:56 <discord-_> e​gg. — (you inject into your transfer orbit from a low orbit)

15:57 <discord-_> s​cimas. — Okay, I was thinking about where you end up going after the burn.

15:57 <discord-_> e​gg. — yeah, but that either doesn’t matter or summons horrible demons, no middle ground there

16:00 <discord-_> e​gg. — if optimizing for the immediate-post-burn state is enough, then it doesn’t matter. If you need to optimize for something else, the something is effectively mission-dependent (approach distance? aeorobraking speed? terrain distance? landing/impact site coordinates?), and even a generic "make it look like what I have in map view" is a mess (least squares in some frame? but how do you clearly communic

16:01 <discord-_> e​gg. — (of course besides the horrible UX problem the actual technical problems are a right mess there too)

16:13 <discord-_> e​gg. — @Butcher what is the intended behaviour when rebasing after the end of the flight plan?

16:13 <discord-_> e​gg. — Not crashing obviously :-p But I am not sure whether it should do nothing and yell at you, delete the flight plan, or delete the flight plan and recreate one

16:14 <discord-_> B​utcher. — I think having it just delete it maybe? Or recreate one. I'm not sure which is better.

16:15 <discord-_> B​utcher. — Maybe just create a new default flight plan.

16:15 <discord-_> e​gg. — yeah I guess that is the least annoying option

16:15 <discord-_> e​gg. — delete would be redundant with the delete button

16:16 <_whitenotifier-9244> [Principia] eggrobin labeled issue #2658: Rebasing a flight plan when past the end fatals the game. - https://git.io/JJgx1

16:16 <_whitenotifier-9244> [Principia] eggrobin assigned issue #2658: Rebasing a flight plan when past the end fatals the game. - https://git.io/JJgx1

16:16 <discord-_> B​utcher. — I'm not a fan of klaxons for things that don't really need them.

16:37 <_whitenotifier-9244> [Principia] eggrobin opened pull request #2660: Fix a couple of bugs in flight plan rebasing - https://git.io/JJVGj

16:38 <discord-_> e​gg. — @scimas @Butcher https://github.com/mockingbirdnest/Principia/pull/2660

16:49 <discord-_> s​cimas. — Isn't the else condition in that ternary operator exactly what the code was doing earlier?

16:54 <discord-_> e​gg. — it is; the ternary is a fix to the @Butcher bug. The fix for your bug is the ResetValue business: the final time does not change, but the way it is displayed should change; failing to do that means that it eventually gets reparsed as the existing length, and pushes the final time forward

16:56 <discord-_> s​cimas. — So the render was causing the actual flight plan to extend? Btw thank you for answering so many questions today 🙂

16:57 <discord-_> e​gg. — yeah, something in the C# layer, I have not dug through the exact sequence of events but there is some self-parsing going on in many places (since keyboard input is a thing, and since we want the formatted output to be consistent with what we would read)

16:58 <discord-_> s​cimas. — I see..

18:04 <_whitenotifier-9244> [Principia] pleroy reviewed pull request #2660 commit - https://git.io/JJVCt

18:04 <_whitenotifier-9244> [Principia] pleroy labeled pull request #2660: Fix a couple of bugs in flight plan rebasing - https://git.io/JJVGj

19:04 <discord-_> V​_i-MADx. — hello i want know if principia work with ksp 1.7.3 RO\RP-1 ?

19:37 <discord-_> s​cimas. — Galileo was the last version to support 1.7.3. You can find a download link for that on github by going through the history of the README.md file. And read the wiki (also on github) if you're going to use Principia.

19:50 <_whitenotifier-9244> [Principia] eggrobin synchronize pull request #2660: Fix a couple of bugs in flight plan rebasing - https://git.io/JJVGj

19:58 <discord-_> V​_i-MADx. — @scimas thx ❤️

20:03 <discord-_> V​_i-MADx. — @scimas but i don't know how to going through the history of the readme.md

20:05 <discord-_> s​cimas. — Click the README.md link in the list of files, there should a History button near top right.

20:07 <discord-_> V​_i-MADx. — ok there many history what i need to open?

20:08 <discord-_> V​_i-MADx. — @scimas ok what next?

20:10 <discord-_> s​cimas. — Look for the name of the version you want, open that link and look for the download link.

20:11 <discord-_> V​_i-MADx. — @scimas ok thanks for help ❤️

20:12 <discord-_> V​_i-MADx. — find it

20:19 <discord-_> V​_i-MADx. — @scimas broken download 😦

20:20 <discord-_> V​_i-MADx. — @scimas the link working but the download no

20:22 <discord-_> V​_i-MADx. — @egg please i need principia for ksp 1.7

20:24 <discord-_> V​_i-MADx. — ok well

20:24 <discord-_> V​_i-MADx. — work

20:24 <discord-_> s​cimas. — Not, sure what you mean, it works just fine for me. Also, please avoid pinging unless it's something that needs specific attention from me.

20:24 <discord-_> s​cimas. — Not sure what you mean, it works just fine for me. Also, please avoid pinging unless it's something that needs specific attention from me. (edited)

20:24 <discord-_> V​_i-MADx. — @scimas sorry mybe my internet was bad

20:25 <discord-_> l​pg. — stop @ing people every time you say something

20:25 <discord-_> V​_i-MADx. — ok

20:25 <discord-_> V​_i-MADx. — well

21:35 <discord-_> d​awidePl. — Did you know? You don't have to and you are not supposed to ping people every message

21:35 <discord-_> d​awidePl. — Did you know? You don't have to and you are not supposed to ping people every message. (edited)

21:37 <raptop> @@@@@@@@