[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

[eggrobin]

2018-11-07

For the new moon (lunation number 233), the new release (Ἐρατοσθένης) is out.

Support for KSP 1.5.1 has been added.

We working on extending geopotential models beyonds oblateness (mascons etc.), but that is not yet ready; see the change log for more details.

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

[Agustin]

Can it be that sometimes in orbit the ship tends to roll or pitch ?(this is when actually throttled up) I am using persistent rotation. Does this mod support it?

Edited November 12, 2018 by Agustin

[hypervelocity]

On 11/12/2018 at 8:14 PM, Agustin said:

Can it be that sometimes in orbit the ship tends to roll or pitch ?(this is when actually throttled up) I am using persistent rotation. Does this mod support it?

I use Principia with Persistent Rotation and have not experienced any malfunctions.

Your issue seems to indicate an imbalanced CoM from the thrust vector - I recommend you use the RCSBuildAid mod to check whether any torque will be produced upon engine firing.

[scimas]

11 hours ago, hypervelocity said:

I use Principia with Persistent Rotation and have not experienced any malfunctions.

Your issue seems to indicate an imbalanced CoM from the thrust vector - I recommend you use the RCSBuildAid mod to check whether any torque will be produced upon engine firing.

Yeah, if I remeber correctly, principia doesn't touch a craft's rotation at all. 

But I understand off center CoM causing pitch and yaw issues, I can't imagine what would cause roll problems. Unless the engines are placed to deliberately produce rolling torque. You would need both off center CoM and a thrust vector unparallel to the heading vector. Basically an offset AND rotated engine. 

[Eriksonn]

I am having lag issues with my slightly modified opm+principia world. I think it depends on objects getting too close to each other as that have cauced issues in the past (when using opm without changes ovok gets closer to sarnus and its orbit gets super twitchy when at periapsis and starts lagging). I think something similar is happening becauce the planets have moved into slightly different orbits. When starting a new world 100k warp is as smooth as no warp but in the old world even 10k warp is jittery. Is there some debug setting that allows me to see what planet or moon is causing the slowdown? Or is it the amount of active vessels(19)?

Edit: I updated to 1.5.1 and it got a little better, not as good as the new game but still better.

Edited November 25, 2018 by Eriksonn

[Agustin]

I am playing RSS/RO/RP1 in KSP 1.3.1
Did a fresh install and in log I get some ERRORS that seem important:
 

Spoiler

[ERR 17:32:23.896] Failed to load assembly C:\Kerbal Space Program\GameData\Principia\x64\libglog.dll:
System.BadImageFormatException: Format of the executable (.exe) or library (.dll) is invalid.
  at Mono.Cecil.PE.ImageReader.ReadOptionalHeaders (System.UInt16& subsystem, System.UInt16& dll_characteristics) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.PE.ImageReader.ReadImage () [0x00000] in <filename unknown>:0 
  at Mono.Cecil.PE.ImageReader.ReadImageFrom (System.IO.Stream stream) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.IO.Stream stream, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName) [0x00000] in <filename unknown>:0 
  at AssemblyLoader.ScanForBadTypeRefs (System.String file) [0x00000] in <filename unknown>:0 
  at AssemblyLoader.LoadExternalAssembly (System.String file) [0x00000] in <filename unknown>:0 

[LOG 17:32:23.912] Load(Assembly): Principia/x64/libprotobuf
[LOG 17:32:23.914] AssemblyLoader: Loading assembly at C:\Kerbal Space Program\GameData\Principia\x64\libprotobuf.dll
[ERR 17:32:23.978] Failed to load assembly C:\Kerbal Space Program\GameData\Principia\x64\libprotobuf.dll:
System.BadImageFormatException: Format of the executable (.exe) or library (.dll) is invalid.
  at Mono.Cecil.PE.ImageReader.ReadOptionalHeaders (System.UInt16& subsystem, System.UInt16& dll_characteristics) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.PE.ImageReader.ReadImage () [0x00000] in <filename unknown>:0 
  at Mono.Cecil.PE.ImageReader.ReadImageFrom (System.IO.Stream stream) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.IO.Stream stream, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName) [0x00000] in <filename unknown>:0 
  at AssemblyLoader.ScanForBadTypeRefs (System.String file) [0x00000] in <filename unknown>:0 
  at AssemblyLoader.LoadExternalAssembly (System.String file) [0x00000] in <filename unknown>:0 

[LOG 17:32:23.994] Load(Assembly): Principia/x64/physics
[LOG 17:32:23.996] AssemblyLoader: Loading assembly at C:\Kerbal Space Program\GameData\Principia\x64\physics.dll
[ERR 17:32:24.032] Failed to load assembly C:\Kerbal Space Program\GameData\Principia\x64\physics.dll:
System.BadImageFormatException: Format of the executable (.exe) or library (.dll) is invalid.
  at Mono.Cecil.PE.ImageReader.ReadOptionalHeaders (System.UInt16& subsystem, System.UInt16& dll_characteristics) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.PE.ImageReader.ReadImage () [0x00000] in <filename unknown>:0 
  at Mono.Cecil.PE.ImageReader.ReadImageFrom (System.IO.Stream stream) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.IO.Stream stream, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName) [0x00000] in <filename unknown>:0 
  at AssemblyLoader.ScanForBadTypeRefs (System.String file) [0x00000] in <filename unknown>:0 
  at AssemblyLoader.LoadExternalAssembly (System.String file) [0x00000] in <filename unknown>:0 

[LOG 17:32:24.048] Load(Assembly): Principia/x64/principia
[LOG 17:32:24.050] AssemblyLoader: Loading assembly at C:\Kerbal Space Program\GameData\Principia\x64\principia.dll
[ERR 17:32:24.100] Failed to load assembly C:\Kerbal Space Program\GameData\Principia\x64\principia.dll:
System.BadImageFormatException: Format of the executable (.exe) or library (.dll) is invalid.
  at Mono.Cecil.PE.ImageReader.ReadOptionalHeaders (System.UInt16& subsystem, System.UInt16& dll_characteristics) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.PE.ImageReader.ReadImage () [0x00000] in <filename unknown>:0 
  at Mono.Cecil.PE.ImageReader.ReadImageFrom (System.IO.Stream stream) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.IO.Stream stream, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName) [0x00000] in <filename unknown>:0 
  at AssemblyLoader.ScanForBadTypeRefs (System.String file) [0x00000] in <filename unknown>:0 
  at AssemblyLoader.LoadExternalAssembly (System.String file) [0x00000] in <filename unknown>:0 

[LOG 17:32:24.115] Load(Assembly): Principia/x64/serialization
[LOG 17:32:24.118] AssemblyLoader: Loading assembly at C:\Kerbal Space Program\GameData\Principia\x64\serialization.dll
[ERR 17:32:24.191] Failed to load assembly C:\Kerbal Space Program\GameData\Principia\x64\serialization.dll:
System.BadImageFormatException: Format of the executable (.exe) or library (.dll) is invalid.
  at Mono.Cecil.PE.ImageReader.ReadOptionalHeaders (System.UInt16& subsystem, System.UInt16& dll_characteristics) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.PE.ImageReader.ReadImage () [0x00000] in <filename unknown>:0 
  at Mono.Cecil.PE.ImageReader.ReadImageFrom (System.IO.Stream stream) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.IO.Stream stream, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName) [0x00000] in <filename unknown>:0 
  at AssemblyLoader.ScanForBadTypeRefs (System.String file) [0x00000] in <filename unknown>:0 
  at AssemblyLoader.LoadExternalAssembly (System.String file) [0x00000] in <filename unknown>:0 

FULL Log:
https://www.dropbox.com/s/lq9jcl4o4m72yiw/KSP.rar?dl=0

Edited November 24, 2018 by Agustin

[pleroy]

On 11/25/2018 at 12:24 AM, Agustin said:

Did a fresh install and in log I get some ERRORS that seem important:

All working as intended.  KSP is just a bit confused by our DLL because they are unmanaged and it tries to load them as if they were .Net assemblies.

[Agustin]

yeah I figured it out because all was working well and because Principia has its own log. Thanks!

[IncongruousGoat]

I've been trying to get Principia running in KSP 1.3.1 on Debian Linux, and like @Clockwork13 I'm running into issues with libc++abi versions. Debian Stretch's apt repositories, as it turns out, only support up to libc++abi 3.5-2. I have, however, found a (horrible) workaround. You can get a .deb file for libc++abi1 6.0-2 for Ubuntu, stick that somewhere, and then manually install it using dpkg. It's got no dependencies, and Ubuntu is close enough to Debian that it just works. Of course, apt will downgrade the package every time you install something which has libc++abi1 as a dependency, so it's probably best to just keep the .deb around and set up a script to re-install it whenever needed. Is it an awful hack? Yes. Does it work? So far, yes. I will update this post if something breaks as a result of this.

[Clockwork13]

23 hours ago, IncongruousGoat said:

I've been trying to get Principia running in KSP 1.3.1 on Debian Linux, and like @Clockwork13 I'm running into issues with libc++abi versions. Debian Stretch's apt repositories, as it turns out, only support up to libc++abi 3.5-2. I have, however, found a (horrible) workaround. You can get a .deb file for libc++abi1 6.0-2 for Ubuntu, stick that somewhere, and then manually install it using dpkg. It's got no dependencies, and Ubuntu is close enough to Debian that it just works. Of course, apt will downgrade the package every time you install something which has libc++abi1 as a dependency, so it's probably best to just keep the .deb around and set up a script to re-install it whenever needed. Is it an awful hack? Yes. Does it work? So far, yes. I will update this post if something breaks as a result of this.

This is what I tried, which is the closest I was able to get for it working. I'm not actually using Debian but a distro based off of but very similar to Debian, which might be my problem.

[AloE]

On 2/5/2014 at 1:19 AM, eggrobin said:

Note to RSS users: Principia correctly simulates the motion of the moon, so the eclipse occurs as expected when using Principia, even after more than 66 years of numerical integreation,

@pleroy Thank you. I have been exploring upcoming eclipses in KerbalEDU 1.3.1 Principia/RSS/RSSVE/RO...indeed they match nicely other data.  I also am delighted that the 2032 March 20 Jupiter triple shadow transit event is reasonably well replicated.

I also see in KSP 1.4.5 TRAPPIST1 for Principia the planet transits occurring within a few minutes of the observed transits published in the appendix of this May 2018 article, at least for the observations I checked for the late 2016 time period...

except that 1b is transiting about 44 minutes "early" in KSP relative to the published observations (1c, 1d, 1e, 1f, 1g, 1h are all very close matches)...so I am curious, what is the story with 1b?

The third video below shows an abbreviated excerpt from my TRAPPIST1 transit comparison showing 'on time' transits for 1c,1d,1e,1f,1g....

KSP view angle is held constant for the measurements...except at the very end to verify that view angle is not causing the time difference as the amount of angle change needed to line up 1b at the expected time is large.

time clock text is most clear when viewed at 1080p

1b transits at 2m14s into the video...the ~44 minutes 'early' pattern with 1b continued beyond the excerpt...that data is pasted below....

Eclipses Principia RSS RSSVE KerbalEDU 1.3.1 & KSP 1.4.5 TRAPPIST1 for Principia

Uncert.     Planet   Observ. DateTime    Observ. Calendar DateTime   KSP Transit time
0.00035     1b       2457 721.3875       2016-11-29	21:18:00         20:34:42
0.00059     1b       2457 739.5177       2016-12-17	0:25:29	         23:40?
0.00055     1b       2457 741.0279       2016-12-18	12:40:11         11:56:??
0.00089     1b       2457 757.6484       2017-01-04	3:33:42	         02:48:??

 

[pleroy]

Thanks for the nice videos @AloE, and thanks for reporting the problem with 1b.

I believe that I understand what is happening: there is a stupid mistake whereby the configuration of the integrator used in the game differs from the one we used to do the transit-time variation optimization.  For the transit at JD2457721.38747, the former produces an effective transit at 20:34:47 (pretty much what you observe), the latter an effective transit at 21:18:08 (pretty much the correct value).

Note that this probably tells us that the integrator is not converged for 1b, presumably because the step size we used is too large.  Darn, we'll need to rerun the optimization...

Created #1999 to track this.  Follow the music there.

[eggrobin]

2018-12-07

For the new moon (lunation number 234), the new release (Erdős) is out.

• Support for realistic geopotential modeling at arbitrary degrees is finally available, with a 10th-degree model of the Earth geopotential in RealSolarSystem; more advanced modelling for other bodies (Moon, Mars, etc.) will be added in future versions.
• #1955, a performance issue on macOS (continuation of #1908), was resolved by using a different synchronization library.
• The issue reported by @AloE above (#1999) has been temporarily addressed by using the same integrator configuration that was used for the optimization. We will redo the optimization with a more appropriate configuration in a future version, as this issue likely indicates that the integrator had not quite converged.

see the change log for more details.

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

Edited December 6, 2018 by eggrobin

[eggrobin]

Note: Erdős is not quite available yet as we are scrambling to address a last-minute issue involving NaN PotatoRoids.

[eggrobin]

The NaN PotatoRoids have been addressed, Erdős is back. If you downloaded it before the above note was posted, you should redownload it to avoid running into crashes when NaN PotatoRoids appear in the gravitational field of an extended body (the version string in the Principia UI should say 773e6fbad7f9fb59790de49fde48650d9451a278, not f772b71b057b64f978bbabdc95ebea2095f27018).

[Someone2018]

@pleroy @eggrobin

Congratulations with the milestone

Realistic geopotential modeling has been in the works for a for a few months as far as I know?

[SnailnamedSnail]

Adds whether Principia realistic inclinations of the axes in RSS?

[Agustin]

what is the meaning of the new geopotential modelling? Would I notice anything behaving different?

[pleroy]

@Agustin: You would notice differences if you were trying to replicate very accurately real-life missions: the old geopotential would exhibit drifts of hundreds of kilometers over a few months to a few years depending on the altitude.  Things will get more interesting though when we extend this to the Moon, where the geopotential is very weird and affects orbit stability, or to Mars, where the position of Phobos and Deimos is currently bogus.  More to come in future versions: stay tuned.

@Someone2018: We started working on this in August.  Making it correct was the first challenge, and then making it fast was even more interesting.

[hypervelocity]

congratulations on the new release!

[eggrobin]

Another serious issue was found with the Erdős release (#2021, adding a manœuvre to a flight plan would cause a crash, effectively rendering flight planning unusable), so we have hotfixed it again; if you downloaded Erdős prior to this post, please download it anew (the version string in the Principia UI should say 3e2334a95bcfc6869b5464ecda5ae48b5412dba0, not 773e6fbad7f9fb59790de49fde48650d9451a278 or f772b71b057b64f978bbabdc95ebea2095f27018).

We apologize for the inconvenience.

[Delay]

I think I'll go back to the previous release for the time being.

[Eriksonn]

It would be interesting to have some sort of geopotential for some of the stock bodies. Maybe assume constant density and use the altitude at each point? I think it would have an effect on very lumpy bodies like minmus or gilly.

Is that a possibillity?

[pleroy]

@Eriksonn:  It is completely feasible, but it requires some understanding of the way geopotential modeling works.  You don't directly use the altitude.  Instead you specify coefficients (conventionally named C_nm and S_nm) for spherical harmonics of various degrees and orders.  This image gives an intuition of what the spherical harmonics look like (the poles are on the left and right, the equator is vertical on the image).  For instance, degree 2 order 0 makes it possible to put more mass at the poles and less at the equator or vice-versa; degree 2 order 2 makes it possible to put more mass at Greenwich and Fiji and less in the Appalachians and Himalayas, etc.  Unfortunately the Wikipedia article on Geopotential model is rather lame, so I recommend looking at section 6 of the IERS Conventions.

In practice you'll need to write a custom principia_gravity_model configuration covering (at least) the body for which you want to specify the geopotential.  This configuration is described here.  Look in particular for geopotential_row and geopotential_column.

[Eriksonn]

So if I understand correctly: If you want to have something that matches minmus you need to do a weighted sum of those spheres until the blue and red areas match with the more/less dense areas on minmus. And for an approximation you can treat more elevated areas as more massive ie more blue on the sphere.(so the minmus flats would be more red and the hills more blue).

Is this correct?