pleroy

@Clockwork13: As mentioned in the FAQs, you need version 6.0-2 of libc++. You must have a rather ancient version to be missing shared_mutex (it was added in the 3.4/3.5 timeframe).

@AloE: Yes, that's correct. That's mostly a round number (in JD) that's happens to fall shortly before the first observation of TRAPPIST-1. We run a fairly complex and expensive optimization to determine orbital elements that match the observed transits, so it's convenient to start a short time before the first observation. Also, many sources give dates like "7282.80570" where the leading JD245 is omitted.

@flyby2412: Cramer, the last version of Principia to support 1.2.2, can be obtained at https://goo.gl/XgRdRP. No support, no bug fixes, no questions answered. This being said, we recommend to use RP-1 with 1.3.1 and the latest Principia. Other people seem to have been successful with that setup.

@AloE: Regarding EVE and Scatterer: please see my response on the Principia thread. You want to download trappist-1 for principia δημόκριτος.zip which should do what you want.

Ah, thanks a lot for reporting this, @AloE. It turns out that while we coordinated with @GregroxMun when he was developing version 0.6.0 of his SLIPPIST-1 mod, we never fixed the link if the FAQs. So the version that you downloaded (trappist-1 for principia dedekind.zip) was designed for 0.5.x and had plenty of problems, one of which was an incompatibility with Kopernicus that caused the crash that you encountered. I have fixed the link in the FAQs to point to trappist-1 for principia δημόκριτος.zip. I suggest that you download this version and install it instead of what you have at the moment. It is better in a number of ways, in particular better alignment of the planetary textures, more realistic radius and atmospheres, data suitable for EVE and Scatterer, etc. (See PR #1856 and #1859 for details.) Apologies for the confusion caused by the outdated FAQs.

The UI has not changed substantially. There have been a number of improvements and fixes regarding memory usage, but it's hard to tell if it has anything to do with what you observed: if you don't submit bug reports, there is no guarantee that bugs will get fixed.

We were on vacation, this is a bulk reply to the thread regarding the ephemeris. Yes, we neglect the acceleration exerted by vessels on celestials and on other vessels. It does save a lot of computations. It's not as small as @Teilnehmer believes, even though the vessels can be 10^15 times lighter than the celestials, because vessels can be very close to each other (so the 1/r^2 factor matters). Note that saving the state of the celestials to a file would be much slower than just recomputing the whole thing. We are able to integrate about 3 million seconds/second, and as @scimas mentioned the file would be huge. Just say no to disk I/O. We'd be interested to know more about this. We have not observed noticeable differences in performance ourselves except at very large warp factors or at very large distance from the Sun. If you could open an issue on GitHub with details that help reproduce the problem, that would be great. Right. The ephemeris is used to (lazily) compute the trajectories of the celestials, and the trajectories of the vessels are then computed in the resulting gravitational field. That would defeat the purpose of the ephemeris, which is to determine once and for all the gravitational field in time and space, and then to integrate the vessels in that field. So the two forces that you mention are computed in two completely separate steps, and possibly at different points in time. As an implementation detail, the mass of the vessels is taken to be exactly 0 in the ephemeris so the forces are not helpful, what we need are the accelerations. To be a bit more specific (for RSS): we start from the positions and velocities, derived from JPL data, for all the celestials at a fixed point in time (1950-01-01); we integrate this configuration forward in time with a Quinlan-Tremaine symmetric linear multistep 12th order integrator and a time step of 10 minutes; for each celestial, we compute polynomials of degree between 3 and 15 to approximate the positions and velocities over 8 points (80 minutes) to 1 mm; these polynomials are constructed in the Чебышёв basis for accuracy and evaluated in the monomial basis for performance; when we need to compute the trajectory of a vessel, we use these interpolating polynomials to compute the position of each celestial.

Dunno, did you report it on GitHub? We fixed two bugs that could match that description (see the change log) but it's hard to know for sure. Nope, the solar system is constructed when you start a new game.

Probably not: we have been supporting 1.2.2 until mid-May 2018.

I tested it with 1.4.3. It works fine. Not tested with older releases 1.4.x but should be ok.

@王小谦同学: I was able to download your KSP.log file, but unfortunately this is not the log file that we need for debugging. Please see the FAQs for information on reporting bugs, and where to find our log files. Also, if you have a save that you could upload that might be helpful.

Use the FAQs, Luke! The FAQs have instructions for installing "Trappist-1 for Principia". Two caveats, though: Our mini-mod is on top of GregroxMun's mod, not on top of RSS, so it's incompatible with RSS (you cannot be in two solar systems at the same time, right?). If you are using 1.4.3 there's a glitch and it will fail to load because of an incompatibility with Kopernicus. Give us a few days to update the .zip file.

Thanks to @scimas for the reply. Public service announcement: the links to the releases are in the README.md file on GitHub. By looking at the history of this file, it's easy to find previous versions of the mod.

@Delay is right: if using Kopernicus, you want to look at this section of our FAQs.

Cramer for 1.2.2 is at https://goo.gl/XgRdRP. We won't be looking into bugs or otherwise supporting Principia versions that target 1.2.2, though.

It has not escaped our notice that the specific physics computations we have implemented immediately suggest a possible extension to support angular momentum conservations. As a matter of fact, quite a few of the classes that manage parts, vessels and pile-ups were designed with this in mind: "if, in addition to position and speed, we also had rotation and angular momentum, then it would still work because...". We just never got to implement it. A bit of design will be required, but I think that the foundation is sound.

@AlliedForth @hypervelocity @scimas: I have added some words to the FAQ but basically reusing a save that was not created with Principia will have strange results because the celestials will be in different places. It should not crash, but it may or may not be what you expect. This is unrelated btw to the notion of adding new vessels: vessels get created and removed all the time as part of normal gameplay (e.g. when stages separate or when a rendezvous happens) so this is something that we have to handle properly.

I guess we can never be too explicit: unzip the archive and copy the Principia folder into the GameData folder. You heard wrong. I am curious to know where this rumour comes from, though.

This is documented in the FAQs here. We do axial tilt by tilting the universe. The current main body must always have its axis vertical as seen by the game, otherwise the terrain system and other entertaining things break. This fundamentally requires a plugin capable of tracking the orbits in a fixed reference frame in order to be able to represent them in the tilted universe. This means that this plugin would have its own model of where every vessel is located and would have to evolve the orbits itself. At this point the plugin owns all the physics and is essentially Principia. (Principia without n-body gravitation would be as hard to develop/maintain and much less interesting to us.)

We'll be releasing for 1.4.1, courtesy of @awang. We don't think there are any issues related to the DLC, vessels appearing are already handled by Principia.

The last version that supported KSP 1.1.3, Cantor, can be downloaded at goo.gl/eZbr4e. It only supported Windows and Linux, not Mac. Note that since we are not building for 1.1.3 anymore, we won't be fixing bugs for that version.

@Eriksonn: Thanks for reporting this problem. I have created 1741 to track it. There appears to be some deep problem with the numerics that we are still investigating. Amusingly, this appears to be fixed by some post-Cohen changes, although we don't really understand why.

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.