[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

[pleroy]

20 minutes ago, Zeiss Ikon said:

Two, I can try to install an older version of Principia -- but I don't see that older binaries are available.  I'm looking for the oldest version that supports 1.6.1, in the hope that it won't require libraries newer than my 16.04 Ubuntu.

Three, if I can install the necessary libraries for only Principia, I'll be good to go for another several months, at least.  The libraries in question are libc++ and libc++abi.  I can download just the binaries for those libraries -- would Principia find them successfully if I place them inside the Principia folder?

The oldest binary that supports 1.6.1 is at bit.ly/2CWdvdo.  You're on your own, though: we upgraded past Xenial (16.04) in June 2017 so if a binary produced after that date works on Xenial, it's pure luck.

Recent versions of Principia want libc++-8-dev and libc++abi-8-dev, and I am not aware that these would be available before Bionic (18.04).

[Zeiss Ikon]

7 hours ago, pleroy said:

The oldest binary that supports 1.6.1 is at bit.ly/2CWdvdo.  You're on your own, though: we upgraded past Xenial (16.04) in June 2017 so if a binary produced after that date works on Xenial, it's pure luck.

Recent versions of Principia want libc++-8-dev and libc++abi-8-dev, and I am not aware that these would be available before Bionic (18.04).

Thanks.  I was afraid of that.

Clearly there's a strong bias in the Linux community in favor of those who upgrade everything at the earliest opportunity, vs. those who ride the old as long as possible to avoid having to spend their work/play time fighting bugs and learning a new system only to have it change again (figuratively) the next week.  If you jumped off 16.04 in mid-2017, it had to be to 16.10, 17.04, or pre-release builds of 17.10, and as you say, it's anyone's guess whether stuff made to run on that would work on 16.04.

I'll grab the binary you pointed to and see if it'll work.  Thanks for the help!

EDIT: Followup, not surprisingly, Principia Euclid (seemingly built under Ubuntu 16.10 or 17.04) caused my 1.6.1 RSS/RO/RP-1 game install to fail to start on Ubuntu 16.04.  The library versions cited above are those for 19.04.  I'd suggest that at the least, it might be more user friendly to keep support for LTS versions, at least until the next LTS comes out.  At present, it appears that one must keep up to the latest non-LTS releases of Ubuntu in order to keep the most current Principia as recommended by the devs.

Worth noting that the game itself seems to work in all supported versions of Ubuntu -- evidenced by the fact it works fine in 16.04, which is the oldest currently supported version.

FURTHER EDIT: If I had the faintest idea how to build a complex program like this, I'd try building it myself to see if that fixes the version dependency -- but I don't know in detail how to do that.

Edited December 8, 2019 by Zeiss Ikon
Add followup

[pleroy]

14 hours ago, Zeiss Ikon said:

I'd suggest that at the least, it might be more user friendly to keep support for LTS versions, at least until the next LTS comes out.  At present, it appears that one must keep up to the latest non-LTS releases of Ubuntu in order to keep the most current Principia as recommended by the devs.

The reason why it's not going to happen is that we need a recent version of Clang and libc++ to build Principia.  Essentially, we need complete support for C++17.  The version of libc++ that shipped with Xenial was 3.7, where they had hardly started looking into C++17.  We don't, at the moment, have complete C++17 support on MacOS (that only came with Catalina) and having to emulate the missing bits is a royal pain in the neck (and hampers development of useful features).

14 hours ago, Zeiss Ikon said:

FURTHER EDIT: If I had the faintest idea how to build a complex program like this, I'd try building it myself to see if that fixes the version dependency -- but I don't know in detail how to do that.

That wouldn't help you.  You'd need a Xenial version of libc++ version 8, or it would not even compile.

[Zeiss Ikon]

4 hours ago, pleroy said:

The reason why it's not going to happen is that we need a recent version of Clang and libc++ to build Principia.  Essentially, we need complete support for C++17.  The version of libc++ that shipped with Xenial was 3.7, where they had hardly started looking into C++17.  We don't, at the moment, have complete C++17 support on MacOS (that only came with Catalina) and having to emulate the missing bits is a royal pain in the neck (and hampers development of useful features).

Seems as if even upgrading to 18.04 wouldn't help me; I searched for libc++-8-dev and found it only in Ubuntu 19.04.  I am NOT going to jump on the "upgrade every six months" train.  Sad that the need for "useful features" pushes the entire mod out of the "Linux is just an OS, not a hobby in itself" world.

Maybe, instead of upgrading Ubuntu, I need to look at Debian based rolling distros...

[sthalik]

17 hours ago, Zeiss Ikon said:

Seems as if even upgrading to 18.04 wouldn't help me; I searched for libc++-8-dev and found it only in Ubuntu 19.04.  I am NOT going to jump on the "upgrade every six months" train.  Sad that the need for "useful features" pushes the entire mod out of the "Linux is just an OS, not a hobby in itself" world.

Maybe, instead of upgrading Ubuntu, I need to look at Debian based rolling distros...

You can always use `apt.llvm.org' for latest llvm packages. Furthermore, the `debootstrap' package included with each Ubuntu/Debian versions make upgrading issues entirely moot. I'm using debootstrap on Arch to avoid #include clashes with regard to the in-tree dependencies for Principia.

[pleroy]

20 hours ago, Zeiss Ikon said:

Seems as if even upgrading to 18.04 wouldn't help me; I searched for libc++-8-dev and found it only in Ubuntu 19.04.

It exists in 18.04.1.

[Zeiss Ikon]

6 hours ago, sthalik said:

You can always use `apt.llvm.org' for latest llvm packages. Furthermore, the `debootstrap' package included with each Ubuntu/Debian versions make upgrading issues entirely moot. I'm using debootstrap on Arch to avoid #include clashes with regard to the in-tree dependencies for Principia.

Did I mention Linux and Ubuntu aren't themselves a hobby for me, never mind a job?  I have no idea what llvm and debootstrap are or are good for.  I use Linux mainly because it isn't Microsoft or Apple...

[hanhan658]

Where can I edit the planets' axial tilt?

[pleroy]

On 12/14/2019 at 10:19 PM, hanhan658 said:

Where can I edit the planets' axial tilt?

There is a configuration file for that.  There was also a discussion earlier on this thread.

[hanhan658]

On 12/16/2019 at 3:03 PM, pleroy said:

There is a configuration file for that.  There was also a discussion earlier on this thread.

I can't seem to find it anywhere in the folder, does it i have to write the config manually? If so, should i write something after the colon in "principia_gravity_model:"? Where do I need to place it, what should I name it, do i have to fill in other things such as gravity parameter and mean radius which is irrelevant for things i want to edit? That page doesn't answer any of those questions at all.

[eggrobin]

1 hour ago, hanhan658 said:

That page doesn't answer any of those questions at all

 

By seeking to change the tilt of planets, you enter the realm of making your own mods, not unlike, e.g., changing other characteristics of planets with Kopernicus.

The page linked by @pleroy documents the Principia-specific aspects of that. It is not intended as a general introduction to KSP configuration modding.

It would be a good idea for you to become acquainted with that, and with ModuleManager patches in particular; see for instance @sarbian's ModuleManager handbook.

 

 

[Zeiss Ikon]

On 12/9/2019 at 11:52 PM, sthalik said:

You can always use `apt.llvm.org' for latest llvm packages. Furthermore, the `debootstrap' package included with each Ubuntu/Debian versions make upgrading issues entirely moot. I'm using debootstrap on Arch to avoid #include clashes with regard to the in-tree dependencies for Principia.

A couple weeks of digging around when I had time to do so, and I found this ppa host that has a backport of llvm-toolchain-8 for Ubuntu 16.04; I installed the needed libraries (libc++-8-dev and libc++abi-8-dev) from that ppa, and (so far) my Ubuntu still works (it should continue, since these are rebuilt under 16.04), and Principia for November at least doesn't crash on starting the RO install (nothing in orbit in the existing save that I opened).

I couldn't find a link for the binary for Frechet (also don't have the correct French accents on my keyboard), so I wound up with something with a Greek-looking name, dated November 23.  Since Frechet was only a couple hours old on GitHub, I presume the binary and updated Readme to link to it will be along later.

[pleroy]

53 minutes ago, Zeiss Ikon said:

A couple weeks of digging around when I had time to do so, and I found this ppa host that has a backport of llvm-toolchain-8 for Ubuntu 16.04; I installed the needed libraries (libc++-8-dev and libc++abi-8-dev) from that ppa, and (so far) my Ubuntu still works (it should continue, since these are rebuilt under 16.04), and Principia for November at least doesn't crash on starting the RO install (nothing in orbit in the existing save that I opened).

Good to hear that you managed to make things work on 16.04, and thank you for reporting it.

I just updated the links for Fréchet on github.  Announcement coming in a few minutes.

[eggrobin]

For the new moon (lunation number 247), the new release (Fréchet) is out.

• Support for KSP 1.8.1 has been added.
• The camera is oriented in map view and the tracking station so that the horizontal is the reference plane of the selected plotting frame. Further, the camera rotates with the plotting frame, so that the plotted trajectories do not rotate as time passes.

 See the change log for more details; note in particular the known issue with map view camera rotation when showing the menu.

We support two sets of versions of KSP: downloads are available for 1.8.1, and for 1.5.1, 1.6.1, 1.7.x. Make sure you download the right one (if you don't, the game will crash on load).

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

 

[Pethos]

Thank you, and Merry Christmas!

[Delay]

May I offer a suggestion?

I love the fact that Principia now shows celestial predictions as well. However, it takes an extreme prediction length to show significant portions of just the Mun's orbit. It may be better to either mutliply the prediction time for celestials before drawing them or to add a new option because I personally don't need a massive prediction length for my own craft, only for celestials.

[Jim123]

Question im not sure if this is true but does Principia have any bugs with rss ro and axis tilt or any bugs at all with RSS? I ask because id like to add it to my RP1 save i want to make sure it doesn't have any bugs before i add it? Thank you in advance:)

[Delay]

13 minutes ago, Jim123 said:

Question im not sure if this is true but does Principia have any bugs with rss ro and axis tilt or any bugs at all with RSS? I ask because id like to add it to my RP1 save i want to make sure it doesn't have any bugs before i add it? Thank you in advance:)

Adding Principia mid-save is, while possible, a bad idea. Celestials and spacecraft will be in vastly different positions.

[MorePortal]

Can I give you a suggestion?

You could add barycentre fixed, non rotating reference frame. Because it's kinda hard to fly like "this":

Spoiler

 

[eggrobin]

22 hours ago, MorePortal said:

Can I give you a suggestion?

You could add barycentre fixed, non rotating reference frame. Because it's kinda hard to fly like "this":

  Hide contents

 

It looks like it is indeed necessary for the orbits of circumbinary planets to be legible. This will be a nontrivial amount of work (both for implementing the reference frame and sorting out UI questions). I opened #2454 to track this.

In the meantime, for interplanetary flights, I suggest using the reference frame centred on the target planet and fixing the direction of the Sun (the reference frame with the orange navball). This reference frame is similar to the target vessel frame (red navball) and should hopefully remain usable even with the binary star.

Impressive work stabilizing the Beyond Home system by the way!

[eggrobin]

For the new moon (lunation number 248), the new release (Frege) is out.

• Celestial histories are now displayed as far as requested in the past (if available), rather than being limited to the time of launch.
• Miscellaneous bugs have been fixed (perhaps most visibly, the wild camera spin in the pause menu introduced in Fréchet).

 See the change log for more details.

We support two sets of versions of KSP: downloads are available for 1.8.1, and for 1.5.1, 1.6.1, 1.7.x. Make sure you download the right one (if you don't, the game will crash on load).

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

 

Edited January 24, 2020 by eggrobin

[mateusviccari]

Is there a way to display the next apoapsis / periapsis on the flight screen? I always forget when I'm looking to the mechjeb / Kerbal engineer HUDs, sometimes I think I got a good apoapsis and a few moments later I'm falling through the atmosphere

[DylanPruden]

does this mod basically make it so i an de-orbit a moon?

[eggrobin]

On 1/28/2020 at 4:37 AM, mateusviccari said:

Is there a way to display the next apoapsis / periapsis on the flight screen? I always forget when I'm looking to the mechjeb / Kerbal engineer HUDs, sometimes I think I got a good apoapsis and a few moments later I'm falling through the atmosphere

We have a feature request tracking that, #2348.

In the meantime, I would recommend using the Orbit Analysis window, which gives you general information about your current orbit; it focuses on long-term properties (orbit size, shape, orientation, and stability) rather than the immediate "am I about to reenter?", but it should be useful nonetheless.

11 minutes ago, DylanPruden said:

does this mod basically make it so i an de-orbit a moon?

No.

On 1/10/2018 at 4:08 PM, pleroy said:

@hypervelocity: This is a question that gets asked all the time.  The answer is that you cannot do that, Principia doesn't let vessels exercise a force on celestials.  That would be very expensive to compute and pointless as demonstrated by Scott Manley here.

 

[AloE]

On 1/24/2020 at 4:15 PM, eggrobin said:

• Miscellaneous bugs have been fixed (perhaps most visibly, the wild camera spin in the pause menu introduced in Fréchet).

 See the change log for more details.

& @pleroy 

first & most important: thank you both for these great changes!

second, a couple of questions:

• with Frege, could the changes (zombies ;-) introduced for #2443  lead to some information persisting & affecting a splice when when I create KSP principia scenarios by using the previously described 'splice' a "landed" state vessel method?  More details in the spoiler:
• Spoiler

  for example, when I edit the principia save of a vessel landed at Earth KSC launchpad (note: this issue may only occur if I do not use launch clamps with the vessel...KSP seems to apply "prelaunch" state rather than "landed" state if I use launch clamps & my splices with launch clamps on them seem to behave well so far)

  I 'splice' the ("no-launch clamp") vessel to the Jovian moon Io by giving it the 'landed' at Io parameters taken from a Mission Builder DLC save with the same vessel placed at the desired location on Io,

  it seems like the altitude of the Earth launchpad may be being added to the correct Io altitude parameter I pasted into the principia save.

  The 'splice' method appeared to work perfectly in the past (& appears to also be fine in Frege if I use launchclamps connected to the vessel to be spliced resulting in a vessel 'pre-launch' state), but with Frege I seem to be floating too high by the amount of the ASL altitude of the vessel's pre-splice position.

  .I am not familiar enough with this type of code to quickly understand what the  zombie_prediction_adaptive_step_parameters  etc. are actually doing. 

  I would much appreciate your insights with what issues/side effects, if any such as possibly "altitude addition" , the 'zombies' might be expected to produce with my 'splicing landed vessels to various celestial bodies' method of "scenario/mission/ building.with Principia saves (ref: open WIP #2457 ) 

  or if not the 'zombies' then I will keep looking for more clues as to why [some] of my splicing does not seem to be going as smoothly now...

  I also will do more to investigate splices of vessels connected to launch clamps v without as so far the splicing of vessels in "prelaunch" state with launch clamps seems to work well...

 

• Understanding at least the conceptual order & direction of flow of CB parameters such radius between RSS cfgs, Kopernicus, RSSVE, Principia (gravity_model), Modulemanager, & KSP would be very helpful to me. Clarification request details in the spoiler:
• Spoiler

   

  eggrobin commented on Aug 9, 2018 (GitHub)
  "Yes, because Principia's axial tilt (in the gravity models) and its initial state override the Kopernicus elements."

  The above indicates that Keplerian elements are overruled, but how about radius?

  The Trappist1 Principia MM/Kopernicus patch for SLIPPIST1 explicitly updates Kopernicus grav parameter & radius, as well as keplerian elements, as well as defining the 'reference_angle"...however for RSS Principia appears to rely on/overrule whatever comes to Kopernicus from RSS? .

  Just to make sure I am clear: Principia takes control of celestial bodies, but, for example with RSS, do the parameters of the gravity_model.cfg in Principia's "real_solar_system" folder completely overrule RSS's .cfgs for Kopernicus like for the values such as the RSS radius (or oblate.cfg radius) so that:

  • these Principia gravity_model provided parameters are the values actually used by Kopernicus/KSP(PQS?) to built the actual visual model of the planet in KSP (e.g. for Jupiter RSS sends a smaller radius to Kopernicus in the Jupiter.cfg & JupiterOblate.cfg multiplies the radius to a value so that the oblate radius becomes much closer to the value given to Jupiter's mean_radius in gravity_model.cfg, & my understanding is that RSSVE removes the oblate.cfg using Kopernicus !debug because, according to what I have read, apparently EVE (clouds) do not like/handle oblate configs...
  • or does Kopernicus/KSP generate a visual model, say of Jupiter, just based on only the RSS .cfg data?  Leaving the Principia gravity_model.cfg data to be only used by Principia (and not fed back into KSP via module manager to Kopernicus or some other Principia generated path to KSP)? 
  • or some other flow? 

  In other words, if I tell Kopernicus (for example, just change the RSS Kopernicus config for Jupiter) to make Jupiter the size of Neptune but leave the Principia gravity model for Jupiter 'as is'...a craft's orbit etc. would still behave like it is near Jupiter but just would not encounter an atmosphere until the much smaller sphere of a 'neptune sized' physical atmosphere/surface since those (if my understanding is correct) are defined & fed to Unity via Kopernicus (& not via Principia) to build the physical 'mesh' model of the celestial.

  (also related note: My current experimenting suggests that Kopernicus constructed celestial body models (stored as .bin files in the RealSolarSystem\RSSKopernicus\cache ) are not dynamic during gameplay...i.e. even with Kittopia I could not force a rebuild of the shape of the surface model while ingame, changing values then reloading KSP was required)

  ________________________________________________

  reference material to help me remember:

  RSSVE appears to use Kopernicus !debug to nuke ! oblate.cfgs

  RSSVE's (likely RSS aligned) cloud map textures (i.e. especially visible with the gas giants)  appear to become "misaligned with the surface texture" due to the Principia astronomically correct rotations of celestial bodies (i.e. the 90 deg rotation change)

  code reminders:

  https://github.com/mockingbirdnest/Principia/blob/389f1fe480948759917f23618c0c085cc1969a23/ksp_plugin_adapter/config_node_parsers.cs#L79-L80

  
   return new BodyParameters{
          name                    = body.name,
          gravitational_parameter =
              node?.GetAtMostOneValue("gravitational_parameter") ??
              (body.gravParameter + " m^3/s^2"),
          // The origin of rotation in KSP is the x of Barycentric, rather
          // than the y axis as is the case for Earth, so the right
          // ascension is -90 deg.
          reference_instant       =
              node?.GetAtMostOneValue("reference_instant") ?? "JD2451545.0",
          min_radius =
              (body.pqsController?.radiusMin ?? body.Radius) + " m",
          mean_radius = body.Radius + " m",
          max_radius =
              (body.pqsController?.radiusMax ?? body.Radius) + " m",
          axis_right_ascension    =
              node?.GetAtMostOneValue("axis_right_ascension") ?? "-90 deg",
          axis_declination        =
              node?.GetAtMostOneValue("axis_declination") ?? "90 deg",
          reference_angle         = node?.GetAtMostOneValue("reference_angle") ??
                                    (body.initialRotation + " deg"),
          angular_frequency       =
              node?.GetAtMostOneValue("angular_frequency") ??
              (body.angularV + " rad/s"),
          reference_radius        = node?.GetAtMostOneValue("reference_radius"),
          j2                      = node?.GetAtMostOneValue("j2"),
          geopotential = node?.GetBodyGeopotentialElements()?.ToArray()
      };
    }

   

  ?? = In English, it means "If whatever is to the left is not null, use that, otherwise use what's to the right."

  
          reference_angle         = node?.GetAtMostOneValue("reference_angle") ??
                                    (body.initialRotation + " deg"),

  https://github.com/mockingbirdnest/Principia/wiki/Principia-configuration-files

  https://github.com/mockingbirdnest/Principia/wiki/Interface-for-other-KSP-mods

  https://github.com/mockingbirdnest/Principia/wiki/Technical-Overview

  https://github.com/mockingbirdnest/Principia/wiki/Change-Log#frege

  https://github.com/mockingbirdnest/Principia/blob/master/ksp_plugin_adapter/ksp_plugin_adapter.cs#L304

  

  Thank you :-)

Edited March 25, 2020 by AloE
hopefully improving clarity