01:25 <_whitenotifier-2275> [Principia] rnlahaye synchronize pull request #2898: Prevent Vessel::RepeatedlyFlowPrognostication from bypassing sleep call. - https://git.io/JtHWD

01:26 <_whitenotifier-2275> [Principia] rnlahaye reviewed pull request #2898 commit - https://git.io/JtQdL

01:26 <_whitenotifier-2275> [Principia] rnlahaye reviewed pull request #2898 commit - https://git.io/JtQd3

01:27 <_whitenotifier-2275> [Principia] rnlahaye commented on pull request #2898: Prevent Vessel::RepeatedlyFlowPrognostication from bypassing sleep call. - https://git.io/JtQdn

03:11 <_whitenotifier-2275> [Principia] rnlahaye commented on pull request #2898: Prevent Vessel::RepeatedlyFlowPrognostication from bypassing sleep call. - https://git.io/JtQAD

08:05 <_whitenotifier-2275> [Principia] Pending. Build queued… - 

08:05 <_whitenotifier-2275> [Principia] Pending. Building… - http://casanova.westeurope.cloudapp.azure.com:8080/job/Principia/4813/

08:17 <dd> morning. Is there a way to notify BurnEditors that the values changed outside of the BurnEditor/FlightPlanner? I mean I change them via the c++ interface by replacing a burn with a new one, but the user interface doesn't refresh.

08:33 <_whitenotifier-2275> [Principia] Success. Build finished. - http://casanova.westeurope.cloudapp.azure.com:8080/job/Principia/4813/

09:05 <_whitenotifier-2275> [Principia] pleroy commented on pull request #2898: Prevent Vessel::RepeatedlyFlowPrognostication from bypassing sleep call. - https://git.io/Jt7YY

09:05 <_whitenotifier-2275> [Principia] pleroy reviewed pull request #2898 commit - https://git.io/Jt7Y3

10:00 <_whitenotifier-2275> [Principia] eggrobin commented on pull request #2898: Prevent Vessel::RepeatedlyFlowPrognostication from bypassing sleep call. - https://git.io/Jt7G4

10:17 <egg|anbo|egg_> dd: a downside of calling internals is that they were never designed to be called in arbitrary ways; this is especially apparent if those calls change the state of things as opposed to just reading it

10:32 <dd> i understand this, because that's exactly what i'm trying to do for my testing phase - expose the interface so I can create/edit/delete manoeuvre nodes (but mostly burns) via kRPC (and python, and c++...).

10:32 <dd> so this would be the wall that I've hit right now - as there's no way to notify BurnEditors about an update. While with FlightPlan it works - I can replace/edit FlightPlan tolerance, time, and steps outside of usual routines and the UI/KSP notices the changes.

10:34 <dd> I guess I'll move this discussion to the corresponding issue.

10:34 <egg|anbo|egg_> I am not sure how that is going to help

10:35 <egg|anbo|egg_> Nor do I understand what your question is; you are trying to do something for which the things you are using were never designed, so no, there is no mechanism for you to do that

10:35 <egg|anbo|egg_> the whole point of us asking for a design is that these problems need to be addressed in their entirety, otherwise you will keep running into things that cannot work because they were never meant to

10:37 <dd> there's no mechanism yet, correct. and you're also correct about design - i haven't proposed any (yet), because I wanted to see what can be done right know with what is already there.

11:37 <discord-_> e​gg. — dd: You seem to be confused about what the difficult part is, and spending a lot of energy on something trivial. The difficulty is not to implement an API, we mostly know how our code works. The difficulty is in defining an API that will keep making sense in the future, and not constrain us unnecessarily; for instance, manœuvres are currently located by their initial time, but that could change: the

11:37 <discord-_> e​gg. — From pleroy’s first reply to you in #1621, emphasis added:

11:37 <discord-_> e​gg. — > a design document detailing the APIs that you want added, *with some indication of why they would be useful to users*

11:37 <discord-_> e​gg. — You have so far left the « what are you trying to do and why » question entirely unanswered and immediately jumped to the « how to do it » aspect (which is probably a bit daunting unless you are familiar with the structure of the Principia codebase).

11:38 <egg|anbo|egg_> ah great, the relay truncated the first line..

11:39 <discord-_> B​utcher. — 640 characters should be enough for anyone egg. 😉

11:39 <discord-_> e​gg. — dd: You seem to be confused about what the difficult part is, and spending a lot of energy on something trivial. The difficulty is not to implement an API, we mostly know how our code works.

11:39 <discord-_> e​gg. — The difficulty is in defining an API that will keep making sense in the future, and not constrain us unnecessarily; for instance, manœuvres are currently located by their initial time, but that could change: there has been discussion of anchoring them to the mean mean anomaly or the mean argument of latitude.

11:39 <discord-_> e​gg. — Such an API is likely to be entirely unlike the internal interface; the latter is tightly coupled to the current Principia data model, the UI logic, and the KSP execution order.

11:39 <discord-_> e​gg. — Compare, for instance, <https://github.com/mockingbirdnest/Principia/wiki/Interface-for-other-KSP-mods#vesselgetposition>

11:39 <discord-_> e​gg. — with <https://github.com/mockingbirdnest/Principia/blob/6f3c9a15de8d75724170af9638b512260e5f03e6/serialization/journal.proto#L2225-L2240>

11:39 <discord-_> e​gg. — which implicitly uses the current time or <https://github.com/mockingbirdnest/Principia/blob/6f3c9a15de8d75724170af9638b512260e5f03e6/serialization/journal.proto#L1888-L1908>

11:39 <discord-_> e​gg. — which combines fetching the history and rendering it, and has some tricky memory management aspects.

11:39 <discord-_> e​gg. — From pleroy’s first reply to you in #1621, emphasis added:

11:39 <discord-_> e​gg. — > a design document detailing the APIs that you want added, *with some indication of why they would be useful to users*

11:39 <discord-_> e​gg. — You have so far left the « what are you trying to do and why » question entirely unanswered and immediately jumped to the « how to do it » aspect (which is probably a bit daunting unless you are familiar with the structure of the Principia codebase). (edited)

11:40 <dd> Well, to phrase it shortly: I want to use Principia's trajectory/burn/manoeuvre plotting from kRPC to test my math from basic orbital mechanics which I want to implement in a hobby autopilot.

11:42 <discord-_> B​utcher. — Why not use patched conics if it;s just for basic orbital mechanics?

11:43 <dd> because I *thought* they produce different results with Principia installed?

11:45 <discord-_> e​gg. — well, what is it you want to model in your hobby autopilot? if you model two-point-masses dynamics, you are not going to get the same thing Principia does; if you implement some sort of orbital precession model you might approximate decently low Earth orbit mechanics

11:46 <discord-_> e​gg. — also, if it is just to test your autopilot, why are KSP and kRPC even in that loop? You could just test it unitarily against a self-standing orbital mechanics library of your choice

11:50 <dd> I want to achieve at least simple parked-in-low-orbit to another-celestial-body transfers.

11:50 <dd> KSP and kRPC are simply there because it's fun - you can interact with the components and your environment and not just develop it in a vacuum.

12:09 <dd> thanks for the links. and yes, I agree with you on what's actually hard in this case.

12:09 <dd> maybe I'll go back to the drawing board, and when I exhaust the stock KSP model, and I have the hopefully sane, abstracted interface I'll come back to Principia with a proposal. there's no rush.

21:03 <_whitenotifier-2275> [Principia] rnlahaye synchronize pull request #2898: Prevent Vessel::RepeatedlyFlowPrognostication from bypassing sleep call. - https://git.io/JtHWD

21:04 <_whitenotifier-2275> [Principia] Pending. Build queued… - 

21:04 <_whitenotifier-2275> [Principia] Pending. Building… - http://casanova.westeurope.cloudapp.azure.com:8080/job/Principia/4814/

21:08 <_whitenotifier-2275> [Principia] rnlahaye reviewed pull request #2898 commit - https://git.io/Jt5mf

21:08 <_whitenotifier-2275> [Principia] rnlahaye commented on pull request #2898: Prevent Vessel::RepeatedlyFlowPrognostication from bypassing sleep call. - https://git.io/Jt5mJ

21:29 <_whitenotifier-2275> [Principia] Success. Build finished. - http://casanova.westeurope.cloudapp.azure.com:8080/job/Principia/4814/

21:51 <_whitenotifier-2275> [Principia] eggrobin reviewed pull request #2898 commit - https://git.io/Jt5Yn