[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]

2 hours ago, Wilhelm said:

 

In file included from tools/generate_configuration.cpp:16:
In file included from ./physics/solar_system.hpp:15:
In file included from ./physics/ephemeris.hpp:22:
./physics/geopotential.hpp:104:45: error: reference to enumeration must use 'enum' not 'enum class' [-Welaborated-enum-class]
  using SurfaceFrame = geometry::Frame<enum class SurfaceFrameTag>;
                                            ^~~~~~

 

This is just a random Clang diagnostic, not a language rule.  Just disable it.

[Wilhelm]

On 2/15/2021 at 4:56 PM, pleroy said:

This is just a random Clang diagnostic, not a language rule.  Just disable it.

This was simple enough that I feel I should have been able to have googled myself. Thanks for the help.

I inserted the disable flag on the Makefile and it worked like a charm (I also had to comment out the -lc++fs flag since it seems to be incorporated in libc++.so in the most recent versions). Then, I just copied the .so generated inside the Relesea/Gamedata/Principia/Linux to its respective folder in game and everything seems to be working.

There is only one thing that is bothering me. 3 tests fails.

[----------] Global test environment tear-down
[==========] 1260 tests from 176 test cases ran. (198830 ms total)
[  PASSED  ] 1257 tests.
[  FAILED  ] 3 tests, listed below:
[  FAILED  ] OrbitalElementsTest.KeplerOrbit
[  FAILED  ] FrequencyAnalysisTest.PoissonSeriesIncrementalProjectionNoSecular
[  FAILED  ] QuadratureTest.Sin10

 3 FAILED TESTS
  YOU HAVE 34 DISABLED TESTS

make: *** [Makefile:273: test] Erro 1

I was under the impression that none should fail. Should I be worried or I can ignore this safely?

[pleroy]

5 hours ago, Wilhelm said:

 

[----------] Global test environment tear-down
[==========] 1260 tests from 176 test cases ran. (198830 ms total)
[  PASSED  ] 1257 tests.
[  FAILED  ] 3 tests, listed below:
[  FAILED  ] OrbitalElementsTest.KeplerOrbit
[  FAILED  ] FrequencyAnalysisTest.PoissonSeriesIncrementalProjectionNoSecular
[  FAILED  ] QuadratureTest.Sin10

 3 FAILED TESTS
  YOU HAVE 34 DISABLED TESTS

make: *** [Makefile:273: test] Erro 1

I was under the impression that none should fail. Should I be worried or I can ignore this safely?

You can ignore these failures.  What happens is that we use the mathematical libraries of the platform (libm on Linux) and these libraries deliver different results depending on the hardware (presence of an FMA instruction or not, for instance) and the version of the OS.  This leads tu small numerical errors that can trip some of our tests.  This should not be problematic for the actual game.

[RKunze]

On 2/15/2021 at 6:13 PM, Wilhelm said:

Now, I have a help request. I decided to try gaming on Linux. I use Arch Linux, which I realize it is not supported by the precompiled binaries since it does not have libc++ 8 and libcx++abi 8.

I'm in the same situation (running KSP with Principia on Arch Linux), but for me, the 1.11 libc++ from Arch Linux works without problems.

The ready-made Principia build links against  /usr/lib/libc++.so.1 and /usr/lib/libc++abi.so.1, and the 1.11 version has a symlink under that name, so no linker problems. And the actual API and ABI seems to be compatible as well.

By the way, if you're playing with Principia in Arch Linux (probably other Linux distros as well), you might want to increase the vm.max_map_count sysconfig parameter (I set it to 5000000) to avoid this problem in mono.

Edited February 21, 2021 by RKunze

[yomaha15]

hello I use Principia on ksp rss ro rssve and I notice that when I make for example a trajectory of type Voyager 2 and the games start to lag and can even crash, I would like to know if it would be my computer which would be the cause, my computer is i5 3470 3.2ghz, gtx 1050ti, 16gb ram

[Wilhelm]

On 2/21/2021 at 10:13 AM, RKunze said:

I'm in the same situation (running KSP with Principia on Arch Linux), but for me, the 1.11 libc++ from Arch Linux works without problems.

The ready-made Principia build links against  /usr/lib/libc++.so.1 and /usr/lib/libc++abi.so.1, and the 1.11 version has a symlink under that name, so no linker problems. And the actual API and ABI seems to be compatible as well.

By the way, if you're playing with Principia in Arch Linux (probably other Linux distros as well), you might want to increase the vm.max_map_count sysconfig parameter (I set it to 5000000) to avoid this problem in mono.

Thanks for the heads up. I had not noticed any problems but increased it just to be on the safe side.

Now I really do not understand why it did not work on my install. The symlinks are there. This remembers what someone once told me: computer science is not an exact science. It is dark magic .

Anyway, things are working for me now. Thanks everyone for the advice.

[aleks01s]

Hi,

first of all thanks for your outstanding work!

I have to report a compatability issue with KerBalloons, though.

Buoyancy of KerBalloons' balloons is broken if Principia is installed.

With (only) Principia and KerBalloon both installed simultaneously, you can inflate and deflate a balloon, with the corresponding animation displaying correctly.
However, once the balloon has inflated the vessel is momentarily lifted by a couple of centimeters, only to immediately descend back to the ground. It then oscillates between barely aloft and landed.

Once deflated, the balloon settles down. 

The issue occurs at KSC with only one probe core and a suitable balloon attached, I have not yet checked other locations.
Without Principia, on a heavily modded setup, KerBalloons works like it should.

Any idea what might cause this? Or how to fix it?

 

 

[scimas]

6 hours ago, aleks01s said:

Any idea what might cause this? Or how to fix it?

I don't know the exact technical details, but at a rough guess the problem is with how the forces are being applied by KerBalloons. If the mod isn't applying forces with the calls Principia expects, the forces will "magically" disappear. As for why it rises a little bit off the ground: Whenever a vessel is landed, Principia doesn't control it all. Stock physics has complete control over it. Which is why the force gets applied to the vessel and it rises above ground. But as soon as it is off the ground, Principia takes over, the force disappears and the vessel comes down; and so you get the oscillations.

[pleroy]

3 hours ago, scimas said:

I don't know the exact technical details, but at a rough guess the problem is with how the forces are being applied by KerBalloons. 

Yeah, this has been reported before:

 

[RKunze]

On 2/28/2021 at 7:44 PM, Wilhelm said:

Thanks for the heads up. I had not noticed any problems but increased it just to be on the safe side.

I first noticed the problem while using the Principia flight planner: Worked great for a couple of minutes, then crashed (my typical use case was planning a free return trajectory around the Mun, crash was typically while fine-tuning the munar periapsis about 5 minutes into the planning session).

But later on, I had the same crash in a kOS script that made heavy use of triggers (yes, I know, that's not the best idea anyway).

Increasing vm.max_map_count solved (OK, worked around - but a real solution would need Unity and/or KSP to finally stop using the deprecated Boehm GC) both cases.

[aleks01s]

Thanks! I'll let Linuxgurugamer know. 

It does not sound like too much of an issue then.

22 hours ago, pleroy said:

Yeah, this has been reported before:

 

 

[AloE]

On 3/1/2021 at 5:11 AM, scimas said:

how the forces are being applied by KerBalloons

 

On 3/2/2021 at 7:09 AM, aleks01s said:

Thanks! I'll let Linuxgurugamer know

LGG's KerBalloons Re-Inflated 0.5.0.7 appears to work as expected for me with Principia including in KSP 1.11.1  ( KerBalloons has been a favorite mod of mine in combination with with Principia regarding launching 'Rockoons' (link) for awhile... )

for reference: updated my old post on this issue to reflect LGG's adoption

[AloE]

@pleroy when you have a moment, I am seeing a strange type of fatal crash on frequent occasion after only some radial de-couplings...launching the same base rocket design over & over for various short Kerbin missions...

I'm posting it here rather than at github for now because way back there was #1549 that looked a bit similar...but in that case was due to KIS...so would like your suggestions of what to try next based on the following:

One odd thing about this one is that it occurs frequently but does not occur all the time, but with this craft always seems to occur some amount of time after we drop the 1st set of SRBs...as if the debris only creates a crash if it goes or has some yet unknown particular place or thing happen to it,

& when I grep the info log for the decouple events, it appears that the fatal sequence always has the additional "switches parent from Kerbin to Sun" like the following example line:

 

I0310 20:09:38.368726 19784 vessel.cpp:111] Vessel x2b Debris (1646c583-f59f-4180-b09a-3e06707d0ec6) switches parent from Kerbin to Sun

I am collecting full sets of logs & some grep output for "switches parent from Kerbin to Sun" & for "Removing part radialDecoupler" in this google drive folder (sorting by name at least puts the files in order)

I0309 20:38:27.741910 23448 pile_up.cpp:81] Constructing pile up at 000001CEB8852210
I0309 20:38:27.741910 23448 part.cpp:219] Adding part solidBooster.sm.v2 (74E942B3) to the pile up at 000001CEB8852210
I0309 20:38:28.101909 23448 vessel.cpp:111] Vessel x2b Debris (0fdfd659-daec-4c6c-91d6-5242c5294f22) switches parent from Kerbin to Sun
I0309 20:38:28.102910 23448 part.cpp:233] Removing part radialDecoupler (3319418D) from its pile up at 000001CEB884FE50
I0309 20:38:28.102910 23448 pile_up.cpp:106] Destroying pile up at 000001CEB884FE50
I0309 20:38:28.102910 23448 part.cpp:67] Destroying part radialDecoupler (3319418D)
    @   00007FFE68396360  	google::LogMessageFatal::~LogMessageFatal [0x00007FFE6839635F+47]
    @   00007FFDE561C2A5  	principia__VesselVelocity [0x00007FFDE561C2A4+1368708]
    @   00007FFDE55C760E  	principia__VesselVelocity [0x00007FFDE55C760D+1021421]
    @   00007FFDE549E213  	principia__FreeVesselsAndPartsAndCollectPileUps [0x00007FFDE549E212+386]
    @   000001CD994BBECD  	(No symbol) [0x000001CD994BBECC]
F0309 20:38:28.102910 23448 vessel.cpp:155] Check failed: !parts_.empty() 

Thanks!

 

 

Edited March 10, 2021 by AloE

[pleroy]

On 3/10/2021 at 9:44 PM, AloE said:

I'm posting it here rather than at github for now because way back there was #1549 that looked a bit similar...but in that case was due to KIS...so would like your suggestions of what to try next based on the following:

So I would suggest creating an issue on GitHub and attaching a set of log files.  We don't even try to track issues on the forum.  This does indeed seem somewhat similar to #1549, in the sense that I suspect that we end up with a vessel having no parts, although that probably happens in a completely different manner.

From looking at one particular log file, we have a vessel (Vessel x2b Debris) that has 3 parts (a noseCone, a solidBooster and a radialDecoupler).  The first two parts are removed from the vessel (so far so good) and then the third part is destroyed.  Since we see no message telling us that the vessel itself is destroyed, we are probably left with an empty vessel.

My gut feeling is that this could be KSP violating one of its own "invariants" or some other mod not properly managing parts and vessels.

If you know how to reproduce this, a journal would help greatly. 

[AloE]

22 hours ago, pleroy said:

or some other mod not properly managing parts and vessels.

If you know how to reproduce this, a journal would help greatly. 

Ok, thanks! I will create an issue at GitHub & attach the journal that I just added to the same google drive folder...I can reproduce it immediately by just adding FAR & dropping those boosters...FAR appears to not have yet been released yet for 1.11 so I am hopeful that team will be willing to look into whatever is identified....so will be grateful for you taking a look when you have time.

[eggrobin]

For the new moon (lunation number 262), the new release (Goldbach) is out.

• Performance has been significantly improved, especially on macOS. Thanks to @rnlahaye for this significant contribution.
• A bug found by @Robot_V1, which affected the handling of some aircraft, was fixed.
• The Chinese localization was improved.

 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 腾讯微云.

[NotMyProblem]

Is the Geocentric system part of Principia or a bug?

[Al2Me6]

23 minutes ago, NotMyProblem said:

Is the Geocentric system part of Principia or a bug?

You're looking at an Earth-centered reference frame then; please read https://github.com/mockingbirdnest/Principia/wiki/Concepts#plotting-frame.

[NotMyProblem]

Thanks!

[DanDucky]

does this only work with 1.11.1? or is there a simple fix I can use to get it to work with 1.11.2?

[RKunze]

19 hours ago, DanDucky said:

does this only work with 1.11.1? or is there a simple fix I can use to get it to work with 1.11.2?

You need to switch off the version check:

Principia Goldbach seems to work with 1.11.2 (read: I have duplicated my 1.11.1 main game with a 1.11.2 based install yesterday, fired it up, and none of the craft im my save exploded spontaneously).

[eggrobin]

For the new moon (lunation number 263), the new release (Grassmann) is out.

• Support for KSP 1.11.2 has been added.
• The mechanism for overriding the version check so as to try new versions before we support them has been documented. Note that no support will be provided when this override is used.
• Some strings were untranslated in the Chinese version; this has been fixed. Thanks to @WC12366 for this contribution.
• A bug leading to steadily increasing memory usage up to crashing out of memory (#2919), reported by @Al2Me6 and @hxl11211, has been fixed.

 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 April 11, 2021 by eggrobin

[DanDucky]

Is it possible to make principia not as laggy in atmosphere? maybe disable the use of principia while in atmosphere with some sort of config? Idk why it is so laggy in the atmosphere but not in space 

[ZAJC3W]

5 hours ago, DanDucky said:

Is it possible to make principia not as laggy in atmosphere? maybe disable the use of principia while in atmosphere with some sort of config? Idk why it is so laggy in the atmosphere but not in space 

Never noticed that with full RSS+RO+RP-1 install on Ryzen 5 3600+rx580+48GB ram machine.

Check console for warnings/errors, must be some other mod conflicting, persistent rotation is not compatible, and unnecessary with principia for instance.

Stage recovery can be laggy in stock especially after dropping of 9 strap on boosters - at least it was laggy on my old PC.

 

Edited April 18, 2021 by ZAJC3W

[DanDucky]

7 hours ago, ZAJC3W said:

Never noticed that with full RSS+RO+RP-1

hmm, ok, I will look into it. For example an 80 part craft can set me back to 3fps on my 24gb ram + gtx 980m + i7-4710HQ CPU @ 2.50GHz