[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

[limelier]

3 hours ago, pleroy said:

FWIW the next release, which will support 1.12.2, will be out in less than 24 hours.

Alright, then, I'll wait. Thank you!

[R-T-B]

14 hours ago, limelier said:

@R-T-B Can I have it too? Sorry for the spam, I would've PM'd directly, but my account is new.

Because my patched version is a version behind already, and it appears an official update is well on the way in the near future, I am going to ask you to wait for official at this time.

Plus sending out all the links to my binary to anyone who requests consumes time for my other projects, so consider this a notice to "just wait" for official now guys.

Edited August 8, 2021 by R-T-B

[eggrobin]

For the new moon (lunation number 267), the new release (Grothendieck) is out.

• Support for KSP 1.12.2 has been added.
• A save compatibility bug has been fixed. Saves created with Cardano or later should now be readable.
• An error in terminology in the Chinese translation has been corrected.

See the change log for more details.

For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云.

Edited August 8, 2021 by eggrobin

[Delay]

34 minutes ago, eggrobin said:

For the new moon (lunation number 267), the new release (Grothendieck) is out.

• Support for KSP 1.12.2 has been added.
• A save compatibility bug has been fixed. Saves created with Cardano or later should now be readable.
• An error in terminology in the Chinese translation has been corrected.

See the change log for more details.

For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云.

The change log links back to this forum page, not to the github.

Just in case that wasn't intentional. I don't want that to come across wrong.

[eggrobin]

4 minutes ago, Delay said:

The change log links back to this forum page, not to the github.

Just in case that wasn't intentional. I don't want that to come across wrong.

Fixed, thanks for pointing that out.

[jd284]

What is a good way of planning constellation maneuvers? For instance, my first relay satellite network would have 3 satellites at 120° phase angle in a 7000 km orbit around Earth. My launcher will place them all there at once, and then two of the satellites would then do a phase change maneuver to place themselves at the right separation along the orbit.

In vanilla KSP I would just place dummy maneuver markers and then execute burns until the apsis time matched the time of the respective maneuver marker.

With Principia, I can't easily place arbitrary maneuver markers anymore, but I think the rendezvous targeting frame would work really well for this, if only I could set a "virtual" target at +/- 120° phase angle of the primary satellite. Is that possible somehow? Or some other easy way of achieving equal separation along an orbit? I searched this topic for similar questions but found nothing using the obvious keywords.

Or do I have to manually calculate the transfer orbits based on the orbital period?

[jd284]

Alright, in regards to my question above, I think I found a neat way of doing this.

After calculating various orbital periods, I realized that to achieve a 120° phase angle, i.e. 1/3 orbit, I could make a transfer with an orbital period of 4/3 the original, or in general (3N+1)/3N and the phase angle would be right after N orbits. So I picked 28/27, and boosted prograde for a bit until there were enough visible "rosettes", I counted off the 27th encounter (I'd be doing 27 orbits plus the one orbit indicated by the rosettes, so 28 while the target does 27), and boosted prograde until that encounter matched my current position. At that point everything lined up very neatly again, which I took for a good sign.

I guess I'll know if it worked in a few days... but the orbital period seems correct, my 4:26:01.5 is 28/27 of the primary 4:16:31.5.

[edit] I just realized that, counting off the 9 encounters after which the phasing should be right, I realized that it was about 120° away from my current position, so I guess that's another good sign. But making the rosettes align was definitely more precise than eyeballing the angle would've been.

I've gotta say, I'm extremely impressed with Principia and how it displays the various references frames, thanks everyone for the great work!

I don't know if it's worth a ticket, but for the above it definitely would've helped to have a counter for the encounters so I wouldn't have to count the markers manually.

Edited August 11, 2021 by jd284

[lopixl]

I have been consistently getting this error message upon loading into a new save, without any other mods installed:

Error extending trajectory for Laythe. Error trying to fit a smooth polynomial to the trajectory. The approximation error jumped from +2.30344324226492217e-03 m to +8.35706270893752298e+03 m at time 2000-01-19T18:40:00,0000000000000000 (TT). The last position is [+2.82771976953634682e+10 m, +5.89455954369199753e+10 m, +3.17994282982390106e+08 m] and the last velocity is [-3.61414693067490953e+03 m s^-1, -1.47464668046310658e+03 m s^-1, +9.66125813160947615e+01 m s^-1]. An apocalypse occurred and two celestials probably collided because your solar system is unstable.

I believed that Principia altered the stock system to create stability, and now I'm confused. Vall has been ejected from the Jool System and is now orbiting the sun in a highly elliptical pattern.

Please help

Edit: In addition to other wild bugs, (terrain being reshaped, causing kerbin to be unrecognizable, none of the celestials progressing in their orbit, etc.,) the problems were isolated to the singular save I had created. I did have Kopernicus in the game directory when I made it. I'm a derp.

Edited August 24, 2021 by lopixl
I'm a derp

[Delay]

15 minutes ago, lopixl said:

I believed that Principia altered the stock system to create stability, and now I'm confused. Vall has been ejected from the Jool System and is now orbiting the sun in a highly elliptical pattern.

Principia does indeed make changes to the Jool system to prevent Vall from being kicked into interplanetary space. The errors in the integration are probably from the fact that Vall's gravity assists, if I remember correctly, end up with it inside Laythe.

The fact that Principia failed to alter the system suggests that the solar system somehow isn't the stock one.

[lopixl]

13 minutes ago, Delay said:

The fact that Principia failed to alter the system suggests that the solar system somehow isn't the stock one.

I had Kopernicus (without a planet mod) in the game directory when I made the save, along with too many other mods to count. That probably did something. I just removed all my mods excluding Principia, and it's working fine.

[ballisticfox0]

On 8/23/2021 at 7:48 PM, lopixl said:

I had Kopernicus (without a planet mod) in the game directory when I made the save, along with too many other mods to count. That probably did something. I just removed all my mods excluding Principia, and it's working fine.

iirc either Principia disables the jool system change if Koperncius is detected or Kopernicus forces the stock system on top of principia

Edited August 25, 2021 by ballisticfox0

[jd284]

It seems that when planning a maneuver with with significant off-tangent components, the maneuver node on the navball is not always placed correctly. I had to aim several degrees off from it (see screenshot), about half-way between the maneuver node and the target -binormal vector instead (where the maneuver node ended up after moving around during the first wrong burn).

I was trying to do a plane change intercept for a rescue operation on the Moon, at apolune of a highly elliptical orbit, with mostly -binormal delta-v. The planned separation was 200 m, but when I aimed for the maneuver node on the navball, I ended up on a way different orbit with 75 km separation with a 50 m/s tangent/normal correction needed. Same when I reloaded and aimed at the binormal node instead. I had to aim half-way in between and got it down to 3 km separation and "only" 6 m/s correction needed afterwards.

Or did I do something wrong here? I can provide a savegame a few seconds before the burn but I use a bunch of mods (USI, SpaceY) and several custom ModManager patches so it will probably be difficult to use...

[Al2Me6]

1 hour ago, jd284 said:

I ended up on a way different orbit

It would be helpful if your screenshot actually showed the position of the maneuver...

I'd guess that your actual trajectory wasn't the same as the flight plan because you didn't rebase.

[jd284]

1 hour ago, Al2Me6 said:

It would be helpful if your screenshot actually showed the position of the maneuver...

I'd guess that your actual trajectory wasn't the same as the flight plan because you didn't rebase.

OK, I don't know which perspective and frame would show it most clearly so I uploaded several others to https://imgur.com/a/kbXiQdI. And I've learned pretty quickly to always rebase after a maneuver, so that wasn't the problem here.

[scimas]

Spoiler

 

You're looking at the target vehicle navball in this screenshot, so the tangent, binormal, normal markers are in that frame. But your manoeuvre is planned in the body inertial frame. That is making you think that those things don't align. And indeed they don't since they're two different frames. Manoeuvres cannot be planned in the target vehicle frame.

[jd284]

1 hour ago, scimas said:

Manoeuvres cannot be planned in the target vehicle frame.

Alright, that kind of makes sense, although I'd still expect the maneuver node to be in the right place, and not off by about 10 degrees, since the required direction of thrust should be the same regardless of the plotting frame and its tangent/normal/binormal directions. I don't understand why a different planning frame should affect that. Anyway, in my screenshots it seems that the blue marker is actually in the same place for both frames. But it's the wrong place for the planned maneuver.

So what's the proper way of planning an intercept then if it can't be done in the target frame, which is after all the only way I can see how close the intercept will be?

Is it enough to roughly create the new maneuver in the inertial frame, and then switch to the target frame for fine tuning? And obviously I need to fine-tune the maneuver execution in the target frame as well.

Though I'm actually pretty sure that I've done this, because planning the maneuver time required seeing the apolune in the MCI frame. So I created the maneuver in the MCI frame, changed the binormal value for a plane change to roughly the target plane, and then switched to target frame to fine-tune the intercept.

[eggrobin]

For the new moon (lunation number 268), the new release (Haar) is out.

• The reference frame selector has been revamped to take up less space, allow quicker switching between arbitrary frames, and provide better explanations of the uses of the various frames. Thanks to @Al2Me6 for translating the new UI to zh-CN, and to @Zaikarion for linguistic help.
• Celestial-specific terminology has been added (perigee instead of Earth periapsis, lunar orbit instead of Moon orbit, etc.).
• Principia is localized in French.

See the change log for more details.

For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云.

Edited September 10, 2021 by eggrobin
Acknowledgements!

[AloE]

for people like me who tend to leave UI windows open (makes it easier when working with younger people), if you encounter lag while right click dragging the KSP flight or map view scenes with the new reference frame selector UI open, minimizing it returns the normal smoothness (and to clarify, pinning just the celestial you are working with & using the '+' to collapse the full list helps a lot as well...which, If I interpret correctly, is what pleroy suggested in the change log)...I really like the revamped UI...thanks egg & pleroy!

Edited September 8, 2021 by AloE

[eggrobin]

On 9/7/2021 at 11:17 AM, AloE said:

 if you encounter lag while right click dragging the KSP flight or map view scenes with the new reference frame selector UI open, minimizing it returns the normal smoothness...

Maybe file a bug for the performance issue? Having the UI open is not supposed to slow things down to a crawl...

Quote

pinning just the celestial you are working with & using the '+' to collapse the full list helps a lot as well...which, If I interpret correctly, is what pleroy suggested in the change log

The UI features that help make the UI smaller are there to make the UI smaller, not faster; if it is slowing things down to start with, there is a bug (probably the KSP localization logic being slow, but it should be easy to cache things).

Edited September 8, 2021 by eggrobin

[serg1983]

hello! I use rss ro, I launched the satellite into orbit with parameters of 160 km at perigee and 250 at apogee, accelerated it, a year passed but the craft did not fall, that is, the orbit parameters did not change significantly, although in reality it was supposed to fall within a month

Edited September 9, 2021 by serg1983

[Al2Me6]

12 hours ago, serg1983 said:

hello! I use rss ro, I launched the satellite into orbit with parameters of 160 km at perigee and 250 at apogee, accelerated it, a year passed but the craft did not fall, that is, the orbit parameters did not change significantly, although in reality it was supposed to fall within a month

Principia does not model decay due to atmospheric drag.

[yomahabaca]

Hello in the last version of principia why did you remove one of the frame references? (barycenter reference is missing)

[AloE]

On 9/9/2021 at 1:09 PM, serg1983 said:

although in reality it was supposed to fall within a month

While Principia itself does not directly model decay from atm drag as Al2Me6 clarified, Principia does work nicely with FARc & RSS, especially after all the great work that was done associated with the "Spin-up on reentry under physics warp with FAR #2519" issue.

Prompted by your query, I looked more carefully at data from the FARc "Flt Data" log & KerBalloons flight recorder log.  Interestingly, the current RSS Earth atm model registers at a lower altitude than I expected (see data images below).

Looking at the numbers from the FARc "Flt Data" log, FARc will at least apply drag & lift for atmosphere pressure on the order of E-08.  So if you wanted to experience decay drag starting around 160km for example, you could make your own revised custom atm model using @OhioBob's "Make your own Atmospheres for KSP (automatically)" spreadsheet and paste the values into your copy of the RSS Earth.cfg for Kopernicus, replacing the atm keys for the default model in that .cfg...in which case also make sure to also delete the Earth.bin in the Kopernicus cache so that it rebuilds the model of the Earth at next KSP load.  I'll probably tinker a bit in this area of the atmosphere model this fall/winter as well.

Edited September 11, 2021 by AloE
added Kerballoons Reinflated link

[AloE]

a fyi update on #3064: The a.k.a 'flickers/textures' symptom that appears to manifest only on some machines, correlates with an as yet unexplained large (~ 1 MB/s) & constant increase in memory allocation by the KSP_x64 process only when the "Principia 'Flight Plan UI' window with an active flight plan" is Open on screen.

To help understand who is & who is not affected (all machines to which I have access for KSP are badly affected ;-), I have created a short Google Survey (link) that you are welcome to fill out if you would like.

 

You may easily observe if your machine has the effect by watching the size of KSP_x64 process memory as you alternately open & close the Principia Flight Plan UI window with an active flight plan.

 

For example, on a windows machine:

• watch the memory value called 'Private Working Set' for the KSP_x64 process either from the 'Details' tab of Task Manager, or using Process Explorer. 
• If your machines shows the effect,  the 'Private Working Set' value will immediately start & steadily increase by on the order of 1024 KB/s = 1 MB/s = 1GB per 20 minutes ONLY when the Flight Plan UI window is OPEN on screen.
• Use the 'Flight Plan' button on the main Principia UI to close the Flight plan UI & after a few seconds the memory will stabilize.
• Repeat the process for reliable control of growth in the KSP_x64 process memory.
• The above method should be similar on MacOS & Ubuntu, etc...from my reading online the default memory reporting metric on those systems is basically similar to the 'Private Working set' value on windows.

The reason remains a mystery.    Current details at #3064.  Thanks!

Edited September 11, 2021 by AloE

[jd284]

How does the flight planner "time base" work?

From the term "End of maneuver #1" one would expect that the time of maneuver #2 moves accordingly when I move maneuver #1 in time. However it stays at the same time as planned originally.

This makes it very hard to plan flights with multiple burns, for instance a return from the moon with #1 tangent burn into an elliptical lunar orbit, then #2 plane change at apolune, and #3 Earth transfer tangent burn at the following perilune. Ideally I'd like to play with the initial time to get a good perigee, however if I move it the other maneuvers will no longer be at apolune/perilune, but offset by the amount of time I moved maneuver #1 and so I continuously have to adjust all three at the same time.

Am I doing it wrong or do I understand it wrong? Is there a way to change the time base of maneuvers to work like what I want?