pleroy

Thanks. I created issue #3697 to track this. I verified that I could uncompress the journal. PS: Don't expect a quick resolution, it's a big journal and probably a hard problem.

Maybe. Maybe not. First, the speed-up only concerns the rotating-pulsating frame where we display equipotentials. Second, if you have many cores, it won't make much of a difference, equipotentials will burn some of your cores but won't affect interactivity. So we are left with the case where you don't have many cores (2-4) and you display equipotentials, then yes, there will be an improvement on warp speed.

This is not the log that we need. As a matter of fact, for such a tricky bug we'd need a journal taken while the problem happens. Details here. ETA: We would actually very much like to be able to investigate this issue. We have had a report years ago of a similar problem but we never managed to get to the root cause. Interestingly, there was a Service Module. So maybe that tells us something. You would help us greatly by providing a journal.

We don't test on macOS as we don't have access to macOS machines. We just build for it. There are people using macOS on the Principia Discord channel. You might try to ask there. We haven't heard of problems so far, so it might be your install.

We constantly recompute them, but not at every frame, because it takes may be one second to do the computation. You might observe that they update in a somewhat janky manner. And we don't try to do things incrementally, because that way lies madness. That's good feedback. I'm sure that there is room for optimization, but getting something out was our priority.

How many cores do you have? The equipotential computation is completely asynchronous so it should be invisible if you have enough cores. We will work on optimizing the equipotential computations in future releases. However, I don't see us having a setting for the number of equipotentials, the heuristics to decide what to plot is already complicated enough. Edit: Actually, computing the equipotentials is cheap (comparable to computing trajectories, which we do much faster than 50 fps for a single trajectory). The really expensive part is the computation of the maxima of the potential, because that's a global optimization. But the whole point of the feature is to locate these maxima, so there is no easy way out.

Sounds like a bug. Created #3569 to track this.

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).