pleroy

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

@JeromeHeretic@R-T-B@Gotmachine The 1.12 DLL loading problem is now understood, see:

(Principia author here.) PSA: Since 1.12 the mods that have DLLs with an empty "File Version" will fail to load and the game will be stuck on "loading part upgrades". Details: the 1.12 change log has the sentence: To do this, it seems that KSP parses the file versions of the DLLs it finds in GameData. Unfortunately, if the file version is empty (which may be the default depending on details of how the DLLs were built) an exception gets raised during parsing. Error handling is hard so this exception seems to bubble up to a place where it confuses the loading process and KSP gets stuck. Advice to modders (including @linuxgurugamer who has been active on this thread): add file versions to all your DLLs. The exact value probably doesn't matter as long as it can be parsed by the System.Version constructor.

@Dirt_Merchant @AloE There is extraordinarily little useful information in this discussion about "flickering textures" and "Cheshire cat navballs". There is also blaming of Gröbner with very few supporting facts. It is true that Gröbner contains significant changes, notably in the C++ side of things; it is conceivable that our C++ code would stomp on Unity data in ways that would just result in visual garbage but not in crashes. But really this seems amazingly unlikely and I would need a lot more data (including reproducible scenarios with only stock and Principia) to be interested in investigating what the gremlins are doing.

OMG, this is so stupid! Changing the path where we look for the C++ DLLs is easy enough, but this is going to be a support headache: "just drop the archive in GameData" won't work and users will get utterly confused.

This is true, but note that there is a mechanism for overriding the version check. No support if you do that, though.

Correct, any save created with del Ferro (August 2019) or later should benefit from all the improvements added since then. Technically any save created with Cardano (March 2017) or later should be readable, but some performance or realism improvements might be missing. Note that this compatibility code is rather hard to test, so if you run into trouble with ancient saves, please open an issue and give us the save.

I wouldn't know, I don't play Principia, I write it This is a question that gets asked often on Discord (server KSP-RO, channel #principia), you might find hints there.

Newtonian. Besides being computationally expensive (the Einstein–Infeld–Hoffmann equations typically require some kind of iterative resolution) relativity really has a minuscule effect compared to many other things that Principia doesn't take into account, like orbital decay or radiation pressure. Principia accurately represents the characteristics of the solar system. The inclination of the Moon on the ecliptic is 5° and the obliquity of the Earth is 23°. Depending on how the two combine, going to the Moon may be hard, especially if you start, say, from Cape Canaveral.

Principia does not preserve the history of landed vessels, so your landed vessel should not cost anything in terms of scene change after you warp to 2020. (Ah, I missed that @scimas had replied already.)

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