pleroy

Thanks for reporting. I created issue #3473 to track this.

Did I say Player.log? No, I didn't. I cannot make sense of your post. Reminder: for anyone wishing to report bugs about Principia, please follow the instructions in the FAQs.

There is a mechanism to override the version check. No support if you do this.

Please follow the instruction in the FAQs for reporting bugs. The KSP.log file is generally useless.

Technically, Principia doesn't quite control the movement of parts. It does control the movements of parts-that-are-in-contact-with-each-other (we call these things "pile-up") and let KSP do the part placement within the pile-ups. There is no way to separate this from N-body physics because precisely N-body physics is the integration of the motion of pile-ups. At least, that's a nice picture . But obviously, it's not supposed to happen. Ideally, if you could reproduce the problem with the stock game and give us a save, that would be great. If not, I would suggest looking at the mods that you use and see if any one of them believes that it can change the location of parts; mods that do this are typically incompatible with Principia (see the FAQs for details). You can try removing the mods one-by-one to determine which one interacts with Principia.

Believe it or not, the Earth is not a perfect sphere. It is flattened at the poles (oblate) and it has mountains and oceans that make its gravity field inhomogeneous. Principia simulates this, so for instance geostationary orbits are only stable in some places (over India and Mexico), elsewhere they need stationkeeping. The effect you are seeing is mostly due to oblateness.

For the real solar system, it's quite easy, we used the JPL Horizon System which gives us real-life numbers. For a fictitious system, however, things might get more challenging.

The configuration files which are used to describe a solar system are documented here.

Please read this post and the posts it references. TL;DR: it's not possible, it won't happen.

There was never a version that supported 1.12.0. Any reason why you couldn't upgrade to 1.12.3?

Have you read the concepts page and taken a look at @rsparkyc's tutorial? I'd suggest doing so before randomly clicking buttons.

Just to clarify: are you saying that हरीश चंद्र works for you but Hausdorff (the version immediately after) does not? That's interesting to know and quite puzzling as there were very few changes in between.

I think you'll have to try progressively older versions of Principia (older download links can be found in the history of README.md on GitHub). We are building on Ubuntu 20.04, which apparently pulls this version of libm. I believe that the last version built on Ubuntu 18.04 (which may or may not have the version of libm you need) was Hardy.

You have version 11 of the libraries, we require version 8, so that should not be the problem. Is there any useful message in KSP.log?

So, do you have libc++abi1-8 and libc++1-8 (or later) installed? If so, which version?

This has been proposed before. It's hard.

The KSP manœuvres are instantaneous, which is not sufficient for the realism that we try to achieve. We are not in the business of reinventing a UI to extend the KSP manœuvres nodes, that's just too much hassle. Regarding speeding up time to reach a manœuvre, you can do that with "Warp to manœuvre" in the flight plan UI.

I told you so a week ago. No point in trying and trying and trying. You need 1.9.1 (no idea why you would not upgrade).

There never was a version of Principia supporting 1.9.0. You need to upgrade to 1.9.1.

Believe it or not, it's documented.

You need to override the version check.

Also note that your flight plan is 16234 days long, which is nearly 44.5 years. Among other things, we are computing the state of the solar system 44.5 years in the future, which is not going to help with performance. Oh, and the computing tolerance of the flight plan is 1 m, which is tiny and forcing us to do more precise integrations. All these setting are wasteful, unless you really mean to nail a landing with an accuracy of 1 metre 44.5 years in the future.

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

Turns out it's documented (note that signal 6 is SIGABRT).

@[email protected]@Gotmachine The 1.12 DLL loading problem is now understood, see: