[WIP][1.8.1, 1.9.1, 1.10.1, 1.11.0–2, 1.12.2–5] Principia—version ‎‎Kronecker, released 2024-11-01—n-Body and Extended Body Gravitation

[Box of Stardust]

Hi everyone,

Awesome mod here; I'd forgotten about it for a long time until recently hearing about it again.

I know it's a bit of a general question, but what kind of mod compatibility am I looking at with this? The mod seems to overhaul mainly the physics portions, so could I assume that it probably won't 'destructively' interfere with that many other mods? Is there anything I should look out for in what kinds of other mods I have installed aside it? I can forsee a lot of mods involving flight plans and automation potentially having some problems, but what else?

Also, what kind of extra strain does this put on the computer's hardware? I'm already running a mod-heavy game, so I can't be sure if adding this in will still leave me with a running KSP (or a running computer).

[nanomage]

3 hours ago, Box of Stardust said:

Hi everyone,

Awesome mod here; I'd forgotten about it for a long time until recently hearing about it again.

I know it's a bit of a general question, but what kind of mod compatibility am I looking at with this? The mod seems to overhaul mainly the physics portions, so could I assume that it probably won't 'destructively' interfere with that many other mods? Is there anything I should look out for in what kinds of other mods I have installed aside it? I can forsee a lot of mods involving flight plans and automation potentially having some problems, but what else?

Also, what kind of extra strain does this put on the computer's hardware? I'm already running a mod-heavy game, so I can't be sure if adding this in will still leave me with a running KSP (or a running computer).

It breaks with the mods that modify physics - orbital decay, persistent thrust, this sort of stuff. As mentioned earlier, Sigma binary breaks but Duna/Ike behave like a proper binary in Principia anyway.  Proper gravity has the potential to break planet packs and especially star/galactic object packs, but check https://forum.kerbalspaceprogram.com/index.php?/topic/164681-122-13-and-131-planet-patches-for-principia/

I think it also causes Trajectories to go slightly crazy as it tries to constantly recalculate atmospheric predictions, and may cause Hangar to crash if a vessel is released in orbit. Performance is all right as far as i can say

[njbrown09]

wait, is there orbital decay in this mod? also does anyone know if it works on darkmultiplayer or lunamultiplayer

[jstnj]

Tried to find some already but, is there any other gameplay videos besides Scott Manley's that show the basic mechanics of manuver nodes etc with Principia?

Edited February 14, 2018 by jstnj
videos doesn't have a ' in it.

[Box of Stardust]

3 hours ago, njbrown09 said:

wait, is there orbital decay in this mod? also does anyone know if it works on darkmultiplayer or lunamultiplayer

As far as I have read in the documentation, orbital decay is a planned feature. However, naturally occurring orbital perturbations due to other gravitational bodies will happen.

[scimas]

5 hours ago, jstnj said:

Tried to find some already but, is there any other gameplay videos besides Scott Manley's that show the basic mechanics of manuver nodes etc with Principia?

If I remember correctly, there are some videos about going to the Lagrange / libration points, ballistic capture. But I haven't found anything extensive, like a career play through with Principia, if that's what you're looking for. 

[eggrobin]

For the new moon (lunation number 224), the new release (Cohen) is out.

The ephemerides are now computed using the Estrin method for polynomials expressed in the monomial basis instead of the Clenshaw method for polynomials expressed in the Чебышёв basis, improving the performance.

See the change log for more details.

Again, we support two versions of KSP: downloads are available for 1.3.1 and for 1.2.2. Make sure you download the right one (if you don't, the game will crash on load).

[drtedastro]

thanks for all of the great work ...

really great mod.

Cheers.

[Kobymaru]

OK, I still can't figure out how to do maneuvers using Principia.

 

I created a flight plan with a burn. I engaged "show on navball". I aligned my ship. I am waiting for the "ignition" timer to count down to zero.

As soon as the timer counts down to zero... the maneuver jumps! I am suddenly misaligned,  ship starts spinning around, burn went all over the place. What did I do wrong?

Performance and Polynomials are fun and all, but it's getting a bit hard to enjoy them when I can't execute basic maneuvers.

Edited February 15, 2018 by Kobymaru

[lawndart]

@Kobymaru

My gut instinct is you have a stale manoeuvre node and this is causing the spacecraft to lose the plot.

As a relatively veteran Principia user my first action on switching to a vessel before a burn is to toggle Show on Navball off and on again, which recalculates the node marker position. 

Even a relatively simple plotted circularisation after a nudge to raise the orbit can leave the node 180 degrees out of position when you reach the time to perform the circularisation burn.

 

[Kobymaru]

On 16.2.2018 at 10:25 AM, lawndart said:

@Kobymaru

My gut instinct is you have a stale manoeuvre node and this is causing the spacecraft to lose the plot.

Nope, I triple-checked that. Recreated the flight plan, recreated the maneuver node, checked the reference frame of the burn, checked the plotting/navball reference frame, all should be correct. Still, when I start the burn, the maneuver node just jumps away.

In another burn, I just tried to follow the node "for fun" and it jumped 3 times during one burn. I'm slowly but surely getting getting turned off from this Mod. While numerical stuff and the premise of N-Body gravity is amazing, the inability to execute even the most basic of flight plans makes this whole thing very un-fun to actually play.

BTW, I have both situations as quicksaves, but they do require the whole Realism Overhaul suite, unfortunately.

 

On 16.2.2018 at 10:25 AM, lawndart said:

As a relatively veteran Principia user my first action on switching to a vessel before a burn is to toggle Show on Navball off and on again

I did, this didn't change anything.

 

 

[eggrobin]

On 2/15/2018 at 11:23 PM, Kobymaru said:

As soon as the timer counts down to zero... the maneuver jumps! I am suddenly misaligned,  ship starts spinning around, burn went all over the place. What did I do wrong?

I suspect that what is happening here is that your flight plan has two manoeuvres; the "show on navball" functionality always puts the upcoming or current manoeuvre on the navball, so that as soon as you reach the planned end of your first burn, guidance switches to tracking the (future) second one .

This is obviously far from ideal user experience, but in the meantime, you can mitigate it by switching your SAS to "Stability Assist" (rather than "Maneuver") near the planned end of the burn. Eventually we should devise a way to do that automatically, but this gets tricky.

As far as the general problem of guidance to a manoeuvre is concerned, we are working with @Jim DiGriz to provide utilities which will allow MechJeb's advanced guidance algorithms (PEG etc.) to know about Principia's flight plan, which will allow the manoeuvres to be automatically executed. Issue #1659 tracks this.

[Kobymaru]

It seems to me people aren't really believing me, so I made a Video:

https://youtu.be/P2ADq1CVm0o

I created a fresh (not stale) Flight plan, a creating a fresh (not old, and only one) maneuver node. When the time for the burn came, the node jumped. After the Burn Time, the maneuver disappeared.

 

2 hours ago, eggrobin said:

I suspect that what is happening here is that your flight plan has two manoeuvres; the "show on navball" functionality always puts the upcoming or current manoeuvre on the navball, so that as soon as you reach the planned end of your first burn, guidance switches to tracking the (future) second one .

This is not the case. There is only one maneuver in my flight plan, and it's the one that is currently produced by the "Show on Navball" option.

 

Quote

This is obviously far from ideal user experience, but in the meantime, you can mitigate it by switching your SAS to "Stability Assist" (rather than "Maneuver") near the planned end of the burn. 

My issue is that it jumps at the beginning of the Burn. Also, switching to stability assist doesn't work well with nodes that aren't inertially fixed, does it?

 

[pleroy]

1 hour ago, Kobymaru said:

It seems to me people aren't really believing me, so I made a Video:

Wouldn't it be cool if we could have informed technical discussions without grumping about "people not believing me"?

1 hour ago, Kobymaru said:

https://youtu.be/P2ADq1CVm0o

Thanks a lot for creating this video, it helps a lot in understanding what you are experiencing.  It was not clear to us from the previous posts that this was a new bug and not just a known quirk of the UI.

I think you have encountered a bug which has not been reported before.  I have created #1728 to track it.

[hypervelocity]

9 hours ago, eggrobin said:

As far as the general problem of guidance to a manoeuvre is concerned, we are working with @Jim DiGriz to provide utilities which will allow MechJeb's advanced guidance algorithms (PEG etc.) to know about Principia's flight plan, which will allow the manoeuvres to be automatically executed. Issue #1659 tracks this.

This would be pure gold !!!

[Jim DiGriz]

On 2/18/2018 at 2:10 AM, eggrobin said:

I suspect that what is happening here is that your flight plan has two manoeuvres; the "show on navball" functionality always puts the upcoming or current manoeuvre on the navball, so that as soon as you reach the planned end of your first burn, guidance switches to tracking the (future) second one .

This is obviously far from ideal user experience, but in the meantime, you can mitigate it by switching your SAS to "Stability Assist" (rather than "Maneuver") near the planned end of the burn. Eventually we should devise a way to do that automatically, but this gets tricky.

As far as the general problem of guidance to a manoeuvre is concerned, we are working with @Jim DiGriz to provide utilities which will allow MechJeb's advanced guidance algorithms (PEG etc.) to know about Principia's flight plan, which will allow the manoeuvres to be automatically executed. Issue #1659 tracks this.

Yeah, I actually already solved the problem of the maneuver node disappearing in PEG assisted burns.  PEG is kind of ideal for Principia usage since it targets the next orbit patch rather than caring anything at all about the maneuver node, so after a bit of defensive coding it no longer aborts the burn when the maneuver node disappears, and it still has a copy of the desired target orbit, so it just burns to get you on that orbit.

I've considered a feature where if you have e.g. three maneuvers planned that it could grab the next orbit patches for all of them, and then burn to target the orbits so that whatever imprecision occurred in the first burn would be compensated for in the second burn, etc.   So you could plan a multiple burn ejection maneuver and hit "execute all nodes" and it would just run through them all and wind up precisely on course.  Then of course, working backwards have a button to bust up an ejection burn into N burns.  Benefits of targeting orbital elements rather than the idealized impulsive burn node.

If anyone wants to play around with it now:

https://github.com/lamont-granquist/MechJeb2/releases

Note that the Node Executor has been replaced with PEG and there's no option to turn it off and go back, and there's known bugs with small dV / small lead time and possibly high inclination node execution that I'm working through (i.e. its a snapshot of my dev branch, it is not released code--i would not recommend it for serious career saves at this point).

To make it work with principia, FIRST you want to turn on "snow on navball" so that PEG has something to hold onto.  THEN you need to select "inertial frame" so that the navball doesn't rotate around the orbit.  THEN you need to select "infinite thrust" so that the orbit coming off of the navball and the principia orbit are tangent.  THEN it helps to "show patched conics" and ensure that the patched conic prediction and the principia prediction are tangent at the location of the maneuver node (if they're not something is messed up).  THEN you need to coast to just before the ignition point of the maneuver node manually in order to get the best agreement between the patched conic prediction and principia's prediction.  THEN finally hit execute on the maneuver node.

Talking to principia correctly will result in that process just becoming "plan a maneuver and hit execute" and it'll actually target the principia orbit instead of a mostly-correct tangent orbit -- that whole tapdance is just about letting MJ grab a tangent orbit to the correct principia prediction.

[Eriksonn]

I seem to have a problem when i tried to make my way to pol. After some time gravity assisting with everything to get Close to pol, both bop and pol started vibrating alot and made pol kick me out after i spent about 300 m/s trying to go into orbit.

pol and bobs speeds occilates with period of about 1 hour and up to 20 m/s. The period of my probes speed has period of about 2 hours.

principias own orbit prediction is consistent with these speedshiftings, making the orbit plot look like junk no matter what reference frame i use (it is most visible in pol corotating frame)

Every other orbit seems fine as far as i can tell.

 

if you think savefile will help i will try send it but right now i dont know how...

[marcio0214]

I am observing the same issue with the node marker flipping to a different (and incorrect) orientation. After some testing, I noticed it always happens when the flight path changes from an orbit to a hyperbolic trajectory. I am running my games on RSS/RO.

To mitigate the issue, I use MechJeb Smart A.S.S. to lock on the node before the burn. I start the burn normally and before the trajectory goes hyperbolic, I engage the "KILL ROT" mode in Smart A.S.S. so it ignores the node marker.

I hope this information helps to reproduce the issue.

Thank you all for the effort you put into this mod. It is the only reason I am playing KSP again. Excellent work!

[John FX]

On 19/02/2018 at 7:16 PM, Jim DiGriz said:

So you could plan a multiple burn ejection manoeuvrer and hit "execute all nodes" and it would just run through them all and wind up precisely on course.  Then of course, working backwards have a button to bust up an ejection burn into N burns.

Ooh, yes please!

On 19/02/2018 at 7:16 PM, Jim DiGriz said:

Talking to principia correctly will result in that process just becoming "plan a maneuver and hit execute" and it'll actually target the principia orbit instead of a mostly-correct tangent orbit

This would indeed be the best solution.

 

Thank you for putting your time and effort into this!

[SleweD]

How large are the save files created by this mod supposed to be? For me they're in excess of 70MB with a section for Principia with 500-600 lines of "serialized_plugin = <131,000 hex characters>". Is that really necessary data, because it's lagging up autosaves and quicksaves.

Can I delete that section from the save file? Does it increase with the number of vessels I launch, or the time I go forward in the game? Is it supposed to be that size?

[pleroy]

19 minutes ago, SleweD said:

How large are the save files created by this mod supposed to be? For me they're in excess of 70MB with a section for Principia with 500-600 lines of "serialized_plugin = <131,000 hex characters>".

70 MiB?  I have forgotten how to count that low...

19 minutes ago, SleweD said:

Is that really necessary data, because it's lagging up autosaves and quicksaves.

Can I delete that section from the save file? Does it increase with the number of vessels I launch, or the time I go forward in the game? Is it supposed to be that size?

Yes, all the data is necessary, we do not store random junk just to annoy users.  We store a lot of binary data (encoded in hex), notably the trajectories of all the vessels and of all the celestials.  This is not something that can be recomputed on the fly.

The saves are (roughly) proportional to the number of vessels.  You can reduce their size to some extent by reducing the size of the history in the Principia UI, but you will get shorter trajectory plots.

If you edit or delete that section from the save, it will most probably crash on load in various mysterious ways.

Edited February 23, 2018 by pleroy

[SleweD]

@pleroy Thanks, I was just checking it wasn't my game bugging out when the mod crashes. I forgot I had put the history value higher, that could be part of the reason.

This might be a silly question but could it not reduce the file size/length by using something like yEnc or base64 instead of hex?

Edited February 24, 2018 by SleweD

[DocRockwell]

Is there a way to increase the size of the UI? It's quite illegible at 4k resolution.

[pleroy]

11 hours ago, SleweD said:

This might be a silly question but could it not reduce the file size/length by using something like yEnc or base64 instead of hex?

It is not a silly question, but this is a complicated topic.  A few observations:

• The file size is really not the interesting metric because disk is cheap.  The time needed to read/write the save is the interesting metric because it affects the user experience.  If you make the file 2x smaller but you burn 2x the CPU, you are most likely making the wrong trade-off.
• Most of the time spent reading/writing saves is spent in KSP code.  Arguably this part might be proportional to the file size, but we really don't know as we have no idea what KSP is doing.
• The KSP saves are not a clean channel, in particular the characters { = } define the structure of the save.  Pure base64 for instance would not work because of the = characters that it would generate.  We could invent our own encoding but that's messy.  If we had a clean channel we would just use binary data and the saves would be 2x smaller.
• We could compress the data that's written to the save.  But that's quite a bit of code complexity, and it's going to burn more CPU for compression/decompression, so it's not clear if it would work better.  To be honest I don't feel like spending a month on this topic just to find out that it's not improving the situation.

Edited February 24, 2018 by pleroy

[pleroy]

On 2/20/2018 at 8:31 PM, Eriksonn said:

I seem to have a problem when i tried to make my way to pol. After some time gravity assisting with everything to get Close to pol, both bop and pol started vibrating alot and made pol kick me out after i spent about 300 m/s trying to go into orbit.

pol and bobs speeds occilates with period of about 1 hour and up to 20 m/s. The period of my probes speed has period of about 2 hours.

principias own orbit prediction is consistent with these speedshiftings, making the orbit plot look like junk no matter what reference frame i use (it is most visible in pol corotating frame)

@Eriksonn: Thanks for reporting this problem.  I have created 1741 to track it.  There appears to be some deep problem with the numerics that we are still investigating.  Amusingly, this appears to be fixed by some post-Cohen changes, although we don't really understand why.