pleroy

It is not a silly question, but this is a complicated topic. A few observations: The file size is really not the interesting metric because disk is cheap. The time needed to read/write the save is the interesting metric because it affects the user experience. If you make the file 2x smaller but you burn 2x the CPU, you are most likely making the wrong trade-off. Most of the time spent reading/writing saves is spent in KSP code. Arguably this part might be proportional to the file size, but we really don't know as we have no idea what KSP is doing. The KSP saves are not a clean channel, in particular the characters { = } define the structure of the save. Pure base64 for instance would not work because of the = characters that it would generate. We could invent our own encoding but that's messy. If we had a clean channel we would just use binary data and the saves would be 2x smaller. We could compress the data that's written to the save. But that's quite a bit of code complexity, and it's going to burn more CPU for compression/decompression, so it's not clear if it would work better. To be honest I don't feel like spending a month on this topic just to find out that it's not improving the situation.

70 MiB? I have forgotten how to count that low... Yes, all the data is necessary, we do not store random junk just to annoy users. We store a lot of binary data (encoded in hex), notably the trajectories of all the vessels and of all the celestials. This is not something that can be recomputed on the fly. The saves are (roughly) proportional to the number of vessels. You can reduce their size to some extent by reducing the size of the history in the Principia UI, but you will get shorter trajectory plots. If you edit or delete that section from the save, it will most probably crash on load in various mysterious ways.

Wouldn't it be cool if we could have informed technical discussions without grumping about "people not believing me"? Thanks a lot for creating this video, it helps a lot in understanding what you are experiencing. It was not clear to us from the previous posts that this was a new bug and not just a known quirk of the UI. I think you have encountered a bug which has not been reported before. I have created #1728 to track it.

@Jesusthebird: So I suspect that Sigma is the culprit here. From what I understand it's trying to do binary systems using the cheezy physics of the stock KSP. To do that it creates a bogus body at the barycentre of Duna and Ike. Then Principia comes along and tries to apply real physics to this mess. This is not going to end well. Even if we did not crash, the barycentre body would be shoved around and would not stay where Sigma wants it to be. It should be possible to design real binary systems and Principia would make them work naturally, although as usual finding a stable configuration may be tricky. The bottom line is that Sigma and Principia are mutually exclusive.

Thanks for the logs. From a quick look at them it seems that you are using a nonstandard solar system (I suppose that some mod does that for you) in which there is a celestial named DunaIke that has a zero rotational velocity. This is not something that we support. I don't remember the exact reason for rejecting this (I think it introduced unnecessary complexity) but it is never something that happens in real life: planets are not inertially fixed. Do you have any idea what mod or config change could cause this?

@Jesusthebird: We'll need the Principia logs to investigate. Please see the FAQs for how to report problems. Basically, what @scimas said... Are you sure that you have downloaded the version of Principia that's for 1.3.1? If you pick the version for 1.2.2, it will crash in mysterious ways.

The reasons are a bit lost in the mists of time. I vaguely remember that when we started Principia 4 years ago, CKAN had limitations that were problematic for us. Also, we were only targeting Windows at the time and CKAN didn't support mods that wouldn't work on all platforms. It's possible that all the problems have been solved since then, and it's just a matter of writing a configuration. There may be minefields, though: for instance I see that they recommend to use ASCII digits and letters in the version names, but we take great pride in using all the possible writing systems in our version names.

I think this is documented in the FAQs: if you have more planets than the basic RSS, the game will crash. You could confirm this by looking at the log files. Even if it didn't crash, it's unclear if RSS Constellations would work well with Principia as the floating-point granularity would become problematic when you move very far away from the main solar system.

The bodies are modeled as oblate spheroids. We only go to the J2 term, and this introduces some inaccuracies for celestials where S22 or C22 are large (Mars is one example, and the orbits of Phobos and Deimos are significantly off). No higher spherical harmonics or gravitation maps as the force computations are in the critical loop and have a very tight CPU budget.

@hypervelocity: This is a question that gets asked all the time. The answer is that you cannot do that, Principia doesn't let vessels exercise a force on celestials. That would be very expensive to compute and pointless as demonstrated by Scott Manley here.

Yeah, this has been suggested before, see issue #947. The reality is that: We are not UI people so we are not very motivated to invest lots of times in the UI when we could be playing with numerics or astronomy. As is customary with UI, things get sticky when you look at the details, and everybody has their own opinion as to how it should work. Unity is somewhat limited in the kind of UI devices that it lets you build. So don't hold your breath. On the other hand, we would welcome contributions in this area: it's fairly isolated from the rest of Principia and could be developed/improved independently .

@Bosun: The stabilization of the Jool system was introduced in Brouwer around February 2016. We have a regression test to make sure that it is not lost when KSP or Principia evolves, so I'd be surprised if it had vanished in Christoffel. Two observations, though: The stabilization only works for the stock solar system. If you have any mod that does any modification to the stock system, Principia won't try to stabilize Jool. In the case of a mod that just adds more celestials, the FAQ has some information about how to stabilize Jool. For more general changes to the system, you're on your own. If you are using a very old save, the Jool stabilization may not be present in the save. You'll need to start anew.

@Jim DiGriz: So at some point @eggrobin and I looked into the TRAPPIST-1 system, where quite a bit of data is known. There is a significant amount of work needed to go from the Nature paper to a proper KSP configuration, but I suspect that it would be great fun. We might decide to do that in some upcoming release.

@Jim DiGriz has actually a very good point. For things like station-keeping and orbital decay, code would need to be executed inside the inner loop of the integrator. The time budget there is less than 100 ns (that's nanoseconds) so there is no way to do a kRPC call, or even a P/Invoke cross-language call (especially with the complex serialization involved). Everything would need to be done in C++ using the Principia abstractions and linked into the Principia DLL. When you do this, well, you are just beefing up Principia and not interfacing with another mod. I am not saying that we won't be doing this one day, but not using 3rd party mods. The interested reader might want to look at the PRs that fix #1628 in the new Christoffel release. It took me many pull requests and close to three weeks to just figure out if a vessel is inside a celestial during the force computation and bring that information up to KSP.

@itsthatguy: You must be new to mod development. See, developing a mod is quite a bit of work, and it takes some dedication to keep spinning out releases to fix bugs, add improvements, and generally address user feedback. Now add to that the issues that arise because of coexistence with other mods; we get a fair number of reports along the line of: "I am using mod XYZ and it causes Principia to crash"; this is hard to debug and sometimes require that we sync up with the other mod authors to understand what's happening or to get them to change their code. Also add the fact that different mods are on different release cycles: we support KSP 1.2.2 not because we love it but because RO is not on 1.3 yet; it does make our release cycle significantly more cumbersome. The bottom line is that there is no way that the authors of three distinct mods can coordinate and synchronize to come up with a consistent design and implementation to make those mods work together smoothly. The overhead would just be overwhelming; and, to be honest, it's not the fun part of mod development. As @scimas said, having an API would help to some extent, but so far no-one has volunteered to help with that work.

@lawndart, @影之瑒: Thanks for the reports. It seems that the capability to start/stop Principia has decayed over time. It was useful at the beginning of the development, when the mod was experimental, but it has probably overlived its usefulness. In particular we know that running without Principia and re-enabling it causes no end of trouble because KSP and Principia get into inconsistent states. I have created #1643 to remove this capability.

This is not a known bug. We'll need you to open an issue on Github and give us your complete logs to investigate, as explained in the FAQs. Don't read too much in the similarity to #1561, it's unlikely to be the same problem because the code has changed quite a bit. Also, the glog message that you mention is innocuous.

That would be a lot of work. Such a mod would have to use the Principia APIs directly. This would be a nightmare because our APIs are quite complex and not-very-well documented, and we change them all the time; we are just not prepared to provide documented and stable APIs to the outside world; also, the autopilot mod would have to be written in C++. To put things in perspective, Principia has about 75,000 lines of hand-crafted C++ and another 25,000 lines of automatically generated C++. Understanding how it all works is not for the faint of heart.

It would be cool if you could open an issue for this on github. Easier to track for us and to incorporate in the release notes, etc. The work-around was actually in RSS, so it only applies to the Moon. The underlying issue is still open, but it will take a while to fix.

The .d files (not folders) are created automatically by make early in the construction and contain dependencies between the units. Are you sure that you have write access to the directory/ies where you downloaded Principia? I have seen problems with the .d files when I had forgotten to run sudo.

From the main thread: Notice that I was talking about Vagrantfile, not Dockerfile. We have not used the Dockerfile for 2 years, so it's probably awfully out of date. Anyway, I just removed it as it was only causing confusion. If you want to build on a Linux, you need to execute by hand all the commands in the Vagrantfile (from "echo Provisioning Principia" to the marker "SCRIPT". Then you need to make sure that you have the KSP assemblies in a directory named "KSP Assemblies" next to the "principia" directory. Don't go modifying the Makefile unless you really understand what it is doing (and what you are doing). Ah, good point, fixing it now.

Please open an issue on github and attach your logs and save to that issue (maybe as a zip archive) just like you did for 1416. It's just too hard for us to track bugs here on the forum.

There is a MacOS version build by lamont-granquist on github here. His builds lag a few days behind ours but he is keeping up with the changes we make. Well, the README file on github is a good starting point...

Good point. We are creating a new thread (below) to help people who want to build Principia themselves. @Rory Yammomoto@HebaruSan

No, this is a question that gets asked periodically (see e.g., issue 1420) and this cannot be made to work. Basically in order to implement proper N-body physics Principia wants to control the positions and velocities of the celestials and therefore has to ignore everything that comes from the game. That includes changes done by other mods such as Hyperedit. Kopernicus works since it produces an initial configuration, not random changes during the game. Same thing for our configurations for RSS.