eggrobin

For the new moon (lunation number 247), the new release (Fréchet) is out. Support for KSP 1.8.1 has been added. The camera is oriented in map view and the tracking station so that the horizontal is the reference plane of the selected plotting frame. Further, the camera rotates with the plotting frame, so that the plotted trajectories do not rotate as time passes.  See the change log for more details; note in particular the known issue with map view camera rotation when showing the menu. We support two sets of versions of KSP: downloads are available for 1.8.1, and for 1.5.1, 1.6.1, 1.7.x. Make sure you download the right one (if you don't, the game will crash on load). For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云.

By seeking to change the tilt of planets, you enter the realm of making your own mods, not unlike, e.g., changing other characteristics of planets with Kopernicus. The page linked by @pleroy documents the Principia-specific aspects of that. It is not intended as a general introduction to KSP configuration modding. It would be a good idea for you to become acquainted with that, and with ModuleManager patches in particular; see for instance @sarbian's ModuleManager handbook.

As documented in the FAQ, you should install the dependency mentioned in the error message.

@Delay same duration as the prediction of the active vessel, if any. In the absence of an active vessel, i.e., in the tracking station with no vessel selected, no prediction is shown, only a history going back to the beginning of the game (or less, depending on the history length setting).

For the new moon (lunation number 246), the new release (פרנקל) is out. Principia now plots the trajectories of celestial bodies. This closes an ancient feature request (#942, March 2016), and builds up on a lot of intervening work; in particular, this is based on the method for trajectory plotting introduced for vessels in Чебышёв (August 2017). The history length setting now hides the history instead of forgetting it; this means that you can shorten histories when they are visually distracting, while retaining the ability to bring them back when you want an overview of your mission. It also uses the same duration format and selector used elsewhere in the Principia UI instead of seconds in scientific notation.  See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云.

I think so; going from J2-only to J2 through J12 (in del Ferro) reduced the error on the orbit of Io from 2″.1 per revolution to 0″.077 per revolution. What does the transit look like in-game in the 1.3.1 versions (I think Fatou is the last one of those)? It would be fun to have a visualization of the improvement.

For the new moon (lunation number 245), the new release (Fourier) is out. Two crashes involving flight plan edition (one reported by @Neph) have been fixed.  See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云

The documentation is here: https://github.com/mockingbirdnest/Principia/wiki/Orbit-analysis. It includes some background information on frozen orbits and ground track recurrence, as well as many examples based on real-life satellites to illustrate the underlying concepts.

For the new moon (lunation number 244), the new release (Fibonacci) is out. An orbit analysis tool has been added which computes mean elements and orbit recurrence properties. This has been in the works since February; more features will be added at a later date, e.g., mean solar times of ascending nodes (for controlling sun-synchronicity). See below for a screenshot of the orbit analysis tool in action on a Молния orbit. The tool is fairly complex; documentation will be provided soon. A crash reported by @Delay has been fixed. A dependency issue that would prevent Principia from starting has been fixed.  See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云

A single angle is not enough to describe how a planet is oriented (this requires three degrees of freedom), nor even how its axis is oriented (two degrees of freedom). You may find it useful to read the section on the semantics of the quantities used for body rotation, and to look at the figure referenced therein, to understand how to properly describe the orientation of a planet. The section on the principia_gravity_model configuration will then tell you how to specify that information in the configuration file.

For the new moon (lunation number 243), the new release (del Ferro) is out. Higher degree and order gravity models have been added for Mercury, Venus, Mars, Jupiter, Saturn, Uranus, and Neptune; satellites of these planets will now have more realistic motion (this change only takes effect on new saves) Some bugs reported by @Sir Mortimer, @scimas, and @Kobymaru have been fixed.  See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云.

Indeed; and at this point, we run into the code complexity of threading that callback all the way down to the integrator; further, even if we did that, there is the aforementioned performance problem: In addition, the integration method1 that we use for long-term vessel trajectories only works if the forces that it is applying depend solely on the position of the vessel, not its velocity; and it only has nice properties if these forces derive from a potential. This in turn means that we would need to switch to a different kind of integration method (which would likely have to be slower to have comparable accuracy), again inducing lots of complexity. TL;DR: thrust in timewarp is not trivial, and will not happen soon; it cannot be a simple “apply force” binding like the ones found in Unity or KSP. ⸻ 1 A symmetric linear multistep method, whose underlying one-step method is conjugate-symplectic.

Principia and Orbital Decay (or any other mod that alters the orbits) are fundamentally incompatible. @Papa_Joe, since you are the new maintainer of Orbital Decay, please note the above; it may be useful to document this incompatibility. You cannot; this is inherently at odds with what Principia does, because keeps an internal dynamical state that it gets propagated by numerical integration, and overrides what stock orbits do. Any changes to the orbits would have to be done as part of the numerical integration, and considerations of complexity as well as performance mean that they have to be done by Principia. To quote some related past discussion to that effect:

@Eriksson What about the Fukushima paper linked by @pleroy, or the ones that @Jim DiGriz linked? Those are specifically about computing the gravitational field given the shape. @AloE Kerballoons is using Rigidbody.AddForceAtPosition instead of Part.AddForceAtPosition, which means that Principia cannot learn about those forces, and therefore cannot make them affect the trajectory; this is the same issue that we found in FireSpitter earlier: In order to be compatible with Principia, a mod that imparts a net force to the vessel must do so with Part.AddForceAtPosition (or Part.AddForce) instead of Rigidbody.AddForceAtPosition (or Rigidbody.AddForce); the force can then be handled by the game (and any mods) instead of being passed directly to Unity. This should be a pretty simple change: all usages of AddForceAtPosition are actually on the RigidBody of a part (part.RigidBody.AddForceAtPosition), so dropping the .RigidBody would do the trick.

Indeed: if the geoid is equal to the terrain height, there is no such thing as downhill (everything is horizontal), which should intuitively be pretty disturbing when you are standing on the slopes of Minmus. As an extreme example, consider a cube of uniform density; figure 1 of Chappell, Iqbal, and Abbott (2012), The gravitational field of a cube, shows the shape of a lake on one of the faces of the cube (lakes, being fluid, lie on an isopotential). Note that the shape of the lake (and thus the geoid) resembles a sphere far more than the face of the cube, whose corners are mountains.

@Eriksson I have not checked the correctness of your code. However, I believe that there is an issue with the general approach: what you are doing is computing a spherical harmonics expansion for the topography (the shape of the ground), rather than the gravitational field (the shape of would-be sea level). In other words, if you correctly compute that which you are trying to compute, you will end up with a gravity field such that the geoid and the topography are the same, i.e., where the ground is (locally) horizontal everywhere. This should not be the case (the sides of mountains are not horizontal, that's how things go downhill). Instead, the geoid tends to be smoother than the topography. For an illustration of this principle, see figure 1 of Franz Barthelmes (2013), Definition of functionals of the geopotential and their calculation from spherical harmonic models: theory and formulas used by the calculation service of the ICGEM. Further, something about the numbers you list in your earlier post give me pause. You have coefficients for degree 1. These correspond to a translation of the geoid; if the geopotential is computed around the centre of mass, they are 0; Principia makes the assumption that they are, and ignores them. However, in your case, they are not only nonzero, but they are fairly large (about the same order of magnitude as, say, C22); this indicates that, if your calculations are correct, you are computing the spherical harmonics with respect to something fairly far from the centre. Note that Principia also ignores degree 2, order 1, as, for bodies whose axis of figure is close to the axis of rotation (which is most often the case), these coefficients are tiny. This may not be the case for arbitrary planets. Note that if it is not the case, it is possible that the rotation of the planet would be chaotic.

This sounds cool; I would be interested in knowing how you generate that; computing the gravitational field from the shape of the body is not trivial, even making simplifying assumptions about internal structure. The best practice is to put the files of your mod in the directory of your mod (so GameData\NameOfYourMod\whatever.cfg). The @ thing is ModuleManager syntax. This means that you need to have ModuleManager (it can be redistributed with your mod, most mods that patch configs do that); you need to look at the ModuleManager documentation to see what you want to do with that syntax (if I recall correctly, @principia_gravity_model:FOR[NameOfYourMod] should do the job, but I am no ModuleManager expert). The specification for these files can be found in https://github.com/mockingbirdnest/Principia/wiki/Principia-configuration-files (using the terminology from that page, you want sufficient principia_gravity_model configurations for the relevant bodies), which means that the gravitational_parameter and reference_radius are not required (the in-game gravitational parameter and radius will be used if they are omitted). We support up to degree and order 30; we have found that this was needed to accurately capture the behaviour of orbits around the Moon (the Moon is very lumpy). For the Earth, we only go to degree and order 10. You should probably inspect the coefficients that you generate and handwave a cutoff from that (if the coefficients remain very large at high degrees, go to high degrees, otherwise ignore higher degrees). Note that we do have a cutoff in-game, so the higher degrees have more a limited range (and thus should only incur a computational cost where they matter). Again, this looks cool.

This would have no effect: Principia creates the ephemeris (and the celestial bodies) when a new game is started, and never reads the configurations again.

@Delay, that would just be the osculating inclination at the node (assuming that we are in the body-centred inertial frame, otherwise it is a largely meaningless angle). As previously discussed, osculating elements are not that useful when it comes to describing your orbit, because they vary wildly along the orbit; arguably the inclination is less affected than the other elements, but I would rather have a consistent approach when it comes to displaying this information, and keep the stuff on the nodes about strictly instantaneous properties at that node (apsis distances, velocities, etc), and display global properties of the orbit (including mean elements) separately.

There is currently nothing that will show a good corresponding two-body orbit. At any time, the game is made to believe that the vessel is following its osculating orbit, so your usual orbital element displays (Kerbal engineer, MechJeb, etc.) will show the osculating elements, which may help; however, the osculating elements are subject to short-period variations that can be misleading as to the true nature of the orbit (in particular the osculating eccentricity and argument of periapsis of near-circular orbits will be wildly inaccurate, to the point of being entirely useless: for TOPEX/Poseidon, the osculating eccentricity ranges between 0.000'2 and 0.001'2, whereas the proper (“mean”) eccentricity is less than 0.000'11.). As @pleroy previously mentioned, I am working on something (the Ferrari change log mentions the ground track recurrence analysis), but this is nontrivial.

For the new moon (lunation number 242), the new release (Ferrari) is out. Support for KSP 1.7.3 has been added. Some bugs reported by @scimas have been fixed.  See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云.

For the new moon (lunation number 241), the new release (Fermat) is out. Support for KSP 1.7.1 and 1.7.2 has been added; as previously announced, this release does not support KSP 1.3.1 and 1.4.x. A long-standing feature request (#1936, opened by @王小谦同学) has been addressed: all manœuvres of a flight plan can be edited, instead of only the last one. Manœuvres now take the thrust limiter into account (#2128, opened by @Kinexity). See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云.

For the new moon (lunation number 240), the new release (Fatou) is out. Support for KSP 1.7.0 has been added. Note that 1.7.1 was released after we built the release, so it is not supported. Also note that we have no special support for the new orbital information display, so that, like MechJeb or Kerbal Engineer Redux, it will display the largely-useless osculating elements at current time instead of mean elements for some appropriate theory. Further, note that we have no special support for the new manœuvre node editor, so that it will likely be unusable. This is the last version to support KSP 1.3.1 and 1.4.x, as Realism Overhaul and Real Solar System now support 1.6.1. The next version will only support 1.5.1 and up. The ascending and descending nodes are now shown with respect to the equator in the body-centred, body-fixed frame, and in the body-centred inertial frame if the central body is sufficiently close (#1841). Many bugs have been fixed that were introduced with the UI changes in Fáry and during the underlying restructuring of the UI code in Fano.  See the change log for more details. We thank @Miracle Magician for reporting a severe bug that would otherwise have been introduced in this release. We support two sets of versions of KSP: downloads are available for 1.4.x, 1.5.1, 1.6.1, 1.7.0, and for 1.3.1. Make sure you download the right one (if you don't, the game will crash on load). For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云.

It has come to our attention that there is a very active community of Chinese users of Principia; notably @王小谦同学 wrote a very detailed introduction to the mod for the Chinese audience, https://www.kerbcat.com/tutorial/md/13601/. For their convenience, in addition to the binaries hosted on Google Drive, we are experimenting with providing links to copies of the Principia Fáry binaries (and the TRAPPIST-1 patch), hosted on 腾讯微云. We welcome the feedback of the affected users on whether this makes things easier. 腾讯微云 links: Principia Fáry for 1.3.1; Principia Fáry for 1.4.x,1.5.1, and 1.6.1.; TRAPPIST-1 for Principia Fáry.

Summarizing a discussion on IRC: this is a symptom of forces being applied using RigidBody.AddForceAtPosition, instead of Part.AddForceAtPosition. The latter (added in 1.2.x) allows other mods (such as Principia) to inspect the forces that were added; Principia needs that in order to be able to integrate the overall motion of the vessel; any forces added via the former will have no net effect on the vessel. Note that rocket engines, AJE jet engines, FAR aerodynamic forces, etc. use Part.AddForceAtPosition, and work correctly. In this case, the rotor (from Airplane Plus) is powered by Firespitter. It appears that Firespitter makes heavy use of RigidBody.AddForceAtPosition, see https://github.com/snjo/Firespitter/search?l=C%23&q=addforceatposition, so that its effect is ignored as soon as you are no longer touching the ground, leading to the observed behaviour. @Snjo: the calls to RigidBody.AddForceAtPosition linked above should be changed to Part.AddForceAtPosition; a lot of them are actually part.GetComponent<Rigidbody>().AddForceAtPosition, so you can simply drop the RigidBody in the middle.