pleroy

That would be because Principia does not log anything in the console. As it stands the video is useless because it doesn't show the Principia UI. It doesn't help that it ends before the point where the speed gets back to normal. No there is not because Principia really does nothing at all with the atmosphere, it just gets the forces computed by FAR and applies them. How do you know that? Do you have evidence that the problem goes away when you remove Principia, or are you speculating? For all I know, it could just be that the FAR computations on an under-powered machine eat up all the resources. That's a terrible advice to give because (1) we don't support old versions, so if there is actually a bug it will never get fixed (2) the support of rotations has nothing to do with anything (3) integration with FAR, which could possibly have something to do with the problem was added at the same time as support for 1.4.4 -- who wants to revert to that? Cool idea, because, in fact, atmospheric flight is left to FAR. As for the handling of rotations, believe it or not the laws of physics work the same whether you are in the atmosphere or not.

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.

This is because of the way KerBalloons applies forces. Principia doesn't find them at the places that it expects. Over the years we've managed to get quite a few mods fixed, but until recently KerBalloons was in a coma.

Yeah, this has been reported before:

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.

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

Sure. Make a copy of the en-us.cfg file, name it es-es.cfg, translate all the strings and send us a pull request. Try to use the correct technical terms, e.g., obtained from Wikipedia, not the KSP jargon. (I seem to remember that you're in South America, so es-419.cfg might be more appropriate, but I am not sure that KSP knows about language subtleties.)

This has been asked before, this will be asked again. Please take a look at this post, notably the reply to point #3. Also take a look at the subsequent replies from @Jim DiGriz.

Right, as mentioned in the README there is a single binary for 1.8.1 to 1.11.0. Note that 1.11.1 is not supported yet (but see above in this thread if you got hit by a Steam update). No worries, English is not my native language either.

Interesting. That happens from time to time. When I give VirusTotal the bit.ly link I get Comodo Valkyrie Verdict: Malware and when I give it the .zip file I get, as you do, Jiangmin: RiskTool.CoinMiner.j. The latter seems to be triggered by the glog.dll library that we are using. Antiviruses are full of this kind of false positives. There is not much I can say or do to prove that we are in good faith, other than tell you that the source is on github and you can inspect it and build from it.

Add a cfg file containing: principia_override_version_check {}. Don't forget to remove it once the next version is out: we won't support you if you override the version check (we'll know from the logs).

This has been asked before, this will be asked again... Pretty much the same reasons that were given recently in reply to a question by @R-T-B. Note that system-specific dependencies are particularly bad: since CKAN doesn't know about them (not even to the point of informing the user), 90% of the installs through CKAN would be broken and users wouldn't have a way to find help. See also CKAN issue #1739.

From a quick look at your log, this is probably issue #2853 (which was itself similar to issue #2716). I am pretty confident that I have fixed it (once and for all!) by rewriting the algorithm used to diagonalize the inertia tensor. The fix will be in the next version, Gödel, to be released around Feb. 11th.

This is open-source software, so it is not breaking any rules. This being said, we are not too keen on people posting random builds on the Interwebz: Custom builds typically go through very little testing ("seems to work fine") so non-trivial bugs may be lurking that would cause users to be disappointing/confused/annoyed. For instance, I believe that in 1.11 you can weld parts and store parts in other parts, and this will almost surely require changes to Principia to avoid breaking the laws of physics (even if it doesn't crash, conservation laws are probably violated). Custom builds are harder to support: if someone runs into problems, it might take us some time to figure out that it was a custom build (the logs would tell us that, but most users just report "it doesn't work" without giving the logs). I'd rather spend time on doing useful work than on wild goose chases.

It's always eminently satisfying to see that Principia correctly simulates astronomical events.

FWIW, tracked in #2757.

Please follow the steps here and give us a PML file tracing what KSP is doing and what is happening on your machine.

Probably never. Principia is not intended as a general-purpose astronomic calculator (there are much better tools for that), it's trying to add value to KSP. The precession of equinoxes is less than 1 degree per century, it's hard to believe that it would be useful in any game situation. Regardless, this is irrelevant for your tidal locking problem.

Older versions can be found by looking at the history of the README file on github.

No. I mean, 1.10.0 was released 11 days ago, what do you expect? As mentioned in another thread, comets might be a challenge.

So do you really believe that a loop from 1 to 3 is simpler than a loop from 1 to N? What problem are you trying to solve anyway?

Let's ignore for a moment the inconvenience of having to special-case a solar system, of having new code paths to test, bugs that would show up only for some solar systems, etc. The real question is: why would anyone want to trade CPU for I/O? Computing a year of ephemeris for the real solar system takes about 10 seconds on an average computer, which means that, in the absence of vessels, we support timewarp at 3'000'000x. A representation based on an existing ephemeris (DE431, INPOP, EPM, etc.) would take tens of megabytes per year. That would require several seconds to load (for mysterious reasons KSP reads saves no faster than 5 MB/s even from SSD). And then we would have to be super-cautious to be consistent with said ephemeris when it comes to masses, geopotential, and the like. For instance, we truncate the geopotential at large distance, we might not be able to do that. On top of this, the real cost of integration is in the vessels: we use a step size of 10 seconds whereas we use 10 minutes for the ephemeris, and many games have dozens of vessels. Difficult enough that we have extensive documentation of the mathematical details, because the code is incomprehensible in isolation. A very insightful comment. We have been working on this thing for 6 years but the first cut of a symplectic integrator took a few days.

Report the bug? I realise that you did so already back in April, but we were not aware that it was still around. We should obviously not have this kind of non-physical behaviour, and when do we try to fix the problem in a timely manner. The difficulties you are experiencing are not a physical consequence of the rotation effects, they probably stem from something that we never did right (tracking of CoM) that suddenly becomes very visible because it introduces funky rotations. We should have both nice rotation effects and flyable planes. Please cut us some slack. Bugs happen, and we try really hard to find them and fix them.

We typically move forward as soon as RSS/RO/RP-1 is available for a version. We cannot keep supporting old versions forever. If you absolutely want to stick to 1.7.x, you'll have to stick to Fuchs. Fine, but this is an RSSVE problem, not a Principia problem: there are hundreds of mods around and we cannot track everyone of them. Have you opened an issue on RSSVE asking them to recompile for 1.8.1? No you haven't. You can, but you'll need to do some work. There is a configuration file for that. There was also a discussion earlier on this thread.

It's a perfectly valid suggestion, in fact it has been suggested before, see #2295. With any reasonable GUI system it would be a 10-minute fix, but not so with Unity's GUILayout which doesn't support such an advanced UI feature. We'd need to program it ourselves and even so it couldn't be on the title bar but it would have to be in the window pane itself, which would probably look odd, and require some repositioning of the current UI elements.