eggrobin

This is what I intend to go for: most of the code in unmanaged C++, interacting with the C# part once per FixedUpdate (get the new positions/velocities etc., send an update for thrusts &c.). I'll have to see what integration out of timewarp ends up looking like, but I won't have more than a few thunks per FixedUpdate (the only way 1000 thunks per update could happen is if I computed the increments in the unmanaged part, but accumulated them in the managed part; this would just be insane from a conceptual standpoint, besides the performance costs).

The acronym expansions are nice too. That's what the 'Open questions for the interested reader' are for. If you want I can notify you when new questions come up.

The ability to look at orbits in rotating reference frames might actually make commsat management easier. Yes, the same Matt Roesle (Mattasmack) also did a simulation of the Alternis system (he's mentioned in the 'acknowledgements' section). Scott Manley remarked that the system might be much more stable if the orbital parameters were read as barycentric, rather than Jool-centric. Experiments will be carried out in due time. Or better numerical stability. The current 'look at your free return trajectory; now look at the SOI change; your free return trajectory is now a Mun collision' behaviour is irritating, as is the numerical wobbling of orbits when out of timewarp. This game really needs decent integrators, independently from the N-body problem. The thing is, once you get used to how they work, 2-body orbital mechanics are pretty simple. This will hopefully provide an interesting challenge and new possibilities, while not fundamentally changing most of the game.

I'll have to experiment, but I'm not sure I will need that much of a speedup (going from CLR to native will already be nice). On the other hand, I'm not sure I need extended precision either (I certainly don't for stock, but it might be nice in RSS). I hope it will work, otherwise I can just import the DLL myself and take care of the marshalling and other interesting details. That's quite tedious though. I'll worry about that (as well as the two issues above) when I get to using C++ anyway. I'll first get most of it working in C# and see how that goes, premature optimisation is the mother of all sins. If Scott Manley's intuition proves right, things should be pretty stable (and thus stockalike) under N-body physics if you just interpret the stock orbital parameters as parameters of the orbits around the barycenter of the primary's system. I'll find out when I try to stabilise Vall.

Yes. For fine timesteps, this actually is easier than propagating them on their Keplerian rails, because solving the Kepler equation (which involves a few iterations of Newton's method; the derivative of Kepler's function has a trigonometric function, which is a few hundred clock cycles compared with 10 or so for a division/square root) is pretty slow. It should be noted that even if you want to keep things in 2-body orbits, it is a good idea to really use the solution of the 2-body problem (2 bodies orbiting a barycenter) rather than the pretty poor Keplerian approximation (one body orbiting another).

How does it compare with Honeyfox's take on gimballing?

Maybe. It should, but then I haven't looked too closely at the implementation details and I have heard reports of incompatibilities between PFCE systems and FAR. It will be some time before things are playable on my side though, so I really can't say what PlanetFactory will look like by then. What gave it away? Undergraduate student in Mathematics at the ETHZ. I don't think this really counts as pure math. Yes, I forgot to add that to the 'further modding' list. It turns out however that orbits far away from the critical points of the gravitational potential (Lagrange points in the CR3BP) are pretty stable on their own. Predictions should help for the more complicated trajectories. Once orbital decay drag is modeled, automated stationkeeping will definitely be needed though. Already in the 'further modding' list: See 'Gravitational Moment' in Eric Weisstein's World of Physics (I will add this to the bibliography).

Everyone: thanks! Thanks! I'm not sure when it happens (I have no idea how Unity actually works). I'm registering a callback to draw the GUI, and I draw the trajectories at the same time. I'll try moving this to Update(). It seems this is due to the origin of ScaledSpace moving (it's always near the camera, so that LocalToScaledSpace(0) != 0) and the trajectories staying in the same position relative to the ScaledSpace origin, so switching to localSpace (whatever that is) might fix it. You're welcome! I figured if I make a dev thread, I might as well make one from which I can gather useful information for development. This seems to be working.

Agathorn, NathanKell et al.: you asked me to make a dev thread for my N-body gravitation mod and notify you when I did that, so here it is. I may have gone overboard with the wall of text, but there are some nice pictures in the middle.

The source code is available on GitHub under the MIT license. Abstract This mod aims to replace KSP's unstable physics integration with a higher-order symplectic integrator, adding n-body Newtonian gravitation in the process. Acronyms Documentation and download Principia is not built in the same way as most other mods (most of it is native code, with a thin C# interface layer), so that compatibility issues may arise depending on the platform. Binaries are available for Windows, Linux (built on Ubuntu, your mileage may vary when using these on other distributions), and Macintosh (thanks to @Jim DiGriz). Note that the mod only works with 64-bit versions of KSP. Please read the wiki page detailing the concepts carefully; a lot of things behave differently when using principia, in particular map view and flight planning. Many aspects of the mod are unfinished, and this is detailed on that page. In addition, please read the FAQ and bug reporting guide. Note that bug reporting procedures differ significantly from those of other mods because of our custom logging system, our use of fatal failures, and our journalling system (which, if activated, allows us to replay the events that led to a crash for later debugging). A tutorial is available on the topic of going to the Mun in various ways, applying the concepts described above. There is also a guide to low orbit rendezvous that should help with understanding the target LVLH frame. Since Principia makes all bodies attract each other according to Newtonian gravitation, the stability of the solar system is a concern; when using stock KSP, Principia modifies the Jool system so that it is stable. When using a customized system (e.g. with Kopernicus), you need to make sure that the system is stable. If you wish to ask questions, you may want to do so on the #principia IRC channel on EsperNet, the #principia channel on the KSP-RO Discord, or #principia:matrix.mockingbirdnest.com. Your concerns may be addressed more quickly there than on the fora (bear in mind however that there isn't always someone around who can answer your question right away; if no-one is around, you may want to stay on the channel for a while). Download the binary (Macintosh, Ubuntu, and Windows): Principia Καραθεοδωρή for 1.8.1, 1.9.1, 1.10.1, 1.11.0–2, and 1.12.2–5; or from 腾讯微云: Principia ‎Καραθεοδωρή for 1.8.1, 1.9.1, 1.10.1, 1.11.0–2, and 1.12.2–5. Alternatively, if you don't trust our binary, build the mod from the Καραθεοδωρή release. We provide a patch to turn @GregroxMun's SLIPPIST-1 into the TRAPPIST-1 system; see the installations instructions. Status Dates are ISO 8601 extended format. 2024-04-08 For the new moon (lunation number 300), which is a total eclipse, the new release (Καραθεοδωρή) is out. Some crashes that could occur when looking at trajectories in map view using the surface frame have been fixed. See the change log for more details. 2024-03-09 For the new moon (lunation number 299), the new release (Канторович) is out. Various crashes and errors resulting in non-functional windows have been fixed. See the change log for more details. 2024-02-09 For the new moon (lunation number 298), the new release (掛谷) is out. Principia now displays predicted and planned impacts in the right location when seen in the surface frame; this replaces the experimental approach that was attempted in Jordan. See the change log for more details. 2024-01-10 For the new moon (lunation number 297), the new release (Julia) is out. Several bugs introduced in recent versions have been fixed. See the change log for more details. 2023-12-12 For the new moon (lunation number 296), the new release (Jordan) is out. Performance with high part count vessels has been improved. In some limited circumstances, Principia now displays collisions between the prediction and the surface of a celestial at the right location, when seen in the surface frame. This is still work-in-progress. Other bugs have been fixed. See the change log for more details. 2023-11-13 For the new moon (lunation number 295), the new release (賈憲) is out. Local optimization of manœuvres has been added to assist in tuning flybys. The issue underlying the cryptic error message improved in the preceding release has been fixed. A three-year-old issue in our handling of rotation with stock aerodynamics has been fixed. Other bugs have been fixed. See the change log for more details. 2023-10-14 For the new moon (lunation number 294), the new release () is out. A cryptic error message has been improved. See the change log for more details. 2023-09-15 For the new moon (lunation number 293), the new release (Jensen) is out. No user-visible changes in this version as we have been laying the groundwork for a mechanism that would help optimize burns to meet certain criteria. See the change log for more details. 2023-08-16 For the new moon (lunation number 292), the new release (Jacobi) is out. A pinnable hover tooltip is displayed when the cursor is hovered over a manœuvre marker, emulating the stock KSP node markers. Thanks to @Al2Me6 for this contribution. See the change log for more details. 2023-07-17 For the new moon (lunation number 291), the new release (岩澤) is out. The manœuvre markers (specifically their Frenet trihedra) are now draggable. Thanks to @Al2Me6 for this contribution. See the change log for more details. 2023-06-18 For the new moon (lunation number 290), the new release (伊藤) is out. The computation of the equipotentials has been improved to make the results more useful for the outer planets, and its performance has been improved. A cryptic error message has been improved. See the change log for more details. 2023-05-19 For the new moon (lunation number 289), the new release (ابن الهيثم) is out. A new rotating and pulsating reference frame has been added; it is in this frame that the Lagrange points are defined for the elliptic restricted three body problem. When this frame is used as the plotting frame, the equipotentials of the centrifugal plus gravitational potential are drawn, so that the Lagrange points can be seen. This provides valuable context when planning low-energy transfers and other trajectories involving the Lagrange points. The following animation by @Al2Me6 illustrates the case of a ballistic capture around the Moon, where the trajectory can be seen to fall into the Moon’s potential well. See the change log for more details. 2023-04-20 For the new moon (lunation number 288), the new release (Ὑπατία) is out. Two bugs, one of which could cause crashes, have been fixed. See the change log for more details. 2023-03-21 For the new moon (lunation number 287), the new release (Hurwitz) is out. The orbit analyser now displays the local time of the ascending node, and can identify sun-synchronous orbits. See the change log for more details. 2023-02-20 For the new moon (lunation number 286), the new release (Householder) is out. No user-visible changes in this version as we have been laying the groundwork for future improvements. In particular, the orbit analyser has been completely rewritten with the goal of making it work with celestials (3493). Please report any bug or oddity that you may encounter with orbit analysis. See the change log for more details. 2023-01-21 For the new moon (lunation number 285), the new release (Horner) is out. Support for KSP 1.12.5 has been added. More quality-of-life improvements to flight plan editing. See the change log for more details. 2022-12-23 For the new moon (lunation number 284), the new release (l’Hôpital) is out. Several quality-of-life issues related to flight plan editing have been addressed. See the change log for more details. 2022-11-23 For the new moon (lunation number 283), the new release (Ἱπποκράτης) is out. Support for KSP 1.12.4 has been added. A bug in the orbit analyser has been fixed. See the change log for more details. 2022-10-25 For the new moon (lunation number 282), the new release (Ἱππίας) is out. Patched conics are no longer displayed in some reference frames where they made no sense. See the change log for more details. 2022-09-25 For the new moon (lunation number 281), the new release (Ἵππασος) is out. Three bugs have been fixed. See the change log for more details. 2022-08-26 For the new moon (lunation number 280), the new release (Ἵππαρχος) is out. A bug in RCS thrust estimation with some parts was fixed by @Flibble. The UI of the flight plan tolerance selector has been improved, matching the changes to the prediction tolerance selector in Hilbert. The axes used by Principia have been made consistent: MechJeb and Principia should now report a similar longitude of the ascending node for an active vessel in a sufficiently Keplerian orbit, instead of differing by 90°. Thanks to @rnlahaye for spotting a bug in that change shortly before the release.  See the change log for more details. 2022-07-28 For the new moon (lunation number 279), the new release (Hilbert) is out. Improvements have been made to the flight planning tool: It now supports multiple flight plans; Buttons have been added to move an orbital manœuvre to the preceding or next revolution; The digits may be individually adjusted by scrolling over them or using the arrow keys. A button has been added to declutter map view when it is overwhelmed by noodles and apsis or node markers. A bug has been fixed whereby the camera spinning wildly when hovering over the UI of some mods. The issue of map view markers jumping around as the trajectory changes has been improved, though likely not entirely solved.  See the change log for more details. 2022-06-29 For the new moon (lunation number 278), the new release (Hesse) is out. All Principia windows now have a close button in the upper-right corner. A crash has been fixed that would occur when loading a save if vessels made frequent short burns (for instance due to RCS).  See the change log for more details. 2022-05-30 For the new moon (lunation number 277), the new release (Ἥρων) is out. Nothing new this time; we have been investigating the possibility of computing and displaying the equipotential lines.  See the change log for more details. 2022-04-30 For the new moon (lunation number 276), the new release (Hermite) is out. The rotation of vessels is now adjusted using Davenport’s Q method, instead of the least rotating part of the vessel; this is not noticeable in most circumstances, but might yield more realistic physical effects for vessels on which large forces (notably, aerodynamic) are exerted. Performance has been slightly improved. Thanks to @rnlahaye for helping with the investigation of an incident in the macOS build.  See the change log for more details. 2022-04-01 For the new moon (lunation number 275), the new release (Heine) is out. Thanks to @rnlahaye for contributions improving the performance of the mechanism that rebuilds histories. A save corruption bug which would lead to crashes in map view or when selecting a vessel in the tracking station has been fixed.  See the change log for more details. 2022-03-02 For the new moon (lunation number 274), the new release (Hausdorff) is out. Thanks to @rnlahaye for contributions improving the performance of operations on trajectories on macOS. No new features in this version beyond rnlahaye’s contributions; we have been working on some cleanups and investigating bugs.  See the change log for more details. 2022-02-01 For the new moon (lunation number 273), the new release (हरीश चंद्र) is out. Support for KSP 1.12.3 has been added. Load times of saves with old vessels (especially ones in low orbits) have been improved by reducing save file size (specifically making the histories more compact), fixing the long-standing issue #2400. Note that trajectories computed prior to upgrading to हरीश चंद्र will not be made more compact; only trajectories computed from its installation onwards will be compact. Load times of saves with many flight plans have been improved by deferring the reconstruction of flight plans until they are actually needed. The trajectories drawn in map view are now correctly hidden by terrain, instead of being cut off at sea level regardless of topography. The performance of trajectory plotting has been improved. Thanks to Quadrupole, @Al2Me6, @lpgagnon, and @scimas for reporting bugs in test versions of this release. Thanks to @rnlahaye for contributions improving the performance of some operations on trajectories. See the change log for more details. 2022-01-02 For the new moon (lunation number 272), the new release (Hardy) is out. Russian localization has been added; thanks to @von Kerman for contributing the translation and answering an endless stream of questions on the grammar of Russian. An issue has been fixed which led to slow camera rotation in the plotting frame if the active vessel was at a low altitude. A crash has been fixed which would occur when drawing trajectories without the UI having ever been shown since KSP was started. 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 腾讯微云. 2021-12-04 For the new moon (lunation number 271), the new release (Hamilton) is out. A memory leak that led to visual anomalies has been fixed; A performance issue with text-heavy windows, in particular the reference frame selector, 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 腾讯微云. 2021-11-04 For the new moon (lunation number 270), the new release (Halley) is out. Nothing new this time; we have been working on changes to the internal representation of vessel trajectories, but this is not ready yet. 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 腾讯微云. 2021-10-06 For the new moon (lunation number 269), the new release (Hadamard) is out. Some bugs reported by @Bellabong and @lpgagnon have been fixed. The duration parser is a little more lenient. 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 腾讯微云. 2021-09-07 For the new moon (lunation number 268), the new release (Haar) is out. The reference frame selector has been revamped to take up less space, allow quicker switching between arbitrary frames, and provide better explanations of the uses of the various frames. Thanks to @Al2Me6 for translating the new UI to zh-CN, and to @Zaikarion for linguistic help. Celestial-specific terminology has been added (perigee instead of Earth periapsis, lunar orbit instead of Moon orbit, etc.). Principia is localized in French. 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 腾讯微云. 2021-08-08 For the new moon (lunation number 267), the new release (Grothendieck) is out. Support for KSP 1.12.2 has been added. A save compatibility bug has been fixed. Saves created with Cardano or later should now be readable. An error in terminology in the Chinese translation has been corrected. 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 腾讯微云. 2021-07-10 For the new moon (lunation number 266), the new release (Grossmann) is out, fixing a couple of bugs reported by @Flibble and @Al2Me6. 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 腾讯微云. 2021-06-10 For the new moon (lunation number 265), the new release (Gröbner) is out. It addresses one part of #2400, namely the lag on scene change far from 1951 in the absence of vessels. This means that @scimas’s custom initial states are no longer needed for late-starting games. 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 腾讯微云. 2021-05-11 For the new moon (lunation number 264), the new release (Green) is out, fixing a few bugs (two crashes and a temporary but potentially very long freeze). 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 腾讯微云. 2021-04-12 For the new moon (lunation number 263), the new release (Grassmann) is out. Support for KSP 1.11.2 has been added. The mechanism for overriding the version check so as to try new versions before we support them has been documented. Note that no support will be provided when this override is used. Some strings were untranslated in the Chinese version; this has been fixed. Thanks to @WC12366 for this contribution. A bug leading to steadily increasing memory usage up to crashing out of memory (#2919), reported by @Al2Me6 and @hxl11211, 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 腾讯微云. 2021-03-13 For the new moon (lunation number 262), the new release (Goldbach) is out. Performance has been significantly improved, especially on macOS. Thanks to @rnlahaye for this significant contribution. A bug found by @Robot_V1, which affected the handling of some aircraft, was fixed. The Chinese localization was improved. 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 腾讯微云. 2021-02-11 For the new moon (lunation number 261), the new release (Gödel) is out. Support for KSP 1.11.1 has been added. Principia is localized in simplified Chinese. Thanks to @CindyRIng for this significant contribution, and to @Zaikarion for helping with linguistic questions. Some crash-inducing bugs 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 腾讯微云. 2021-01-13 For the new moon (lunation number 260), the new release (Germain) is out. Support for KSP 1.11.0 has been added. The orbital analysis of the final trajectory is now available in the flight plan, making it possible to plan accurate orbital insertions and corrections. 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 腾讯微云. 2020-12-14 For the new moon (lunation number 259), which is a total eclipse, the new release (Гельфонд) is out. The orbit analyser now provides a short description of the current orbit, e.g., “highly eccentric semisynch. Earth orbit”. The trajectory colours can now be configured, thanks to a contribution from @Flibble (#2816). 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 腾讯微云. 2020-11-15 For the new moon (lunation number 258), the new release (Гельфанд) is out. Performance of operations based on iteration over trajectories has been improved thanks to a contribution from @rnlahaye. 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 腾讯微云. 2020-10-16 For the new moon (lunation number 257), the new release (Gauss) is out. A bug that would occasionally lead to crashes when parts exploded has been fixed (#2716). 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 腾讯微云. 2020-09-17 For the new moon (lunation number 256), the new release (Gateaux) is out. Support for 1.10.1 has been added. Note that the behaviour of Principia in the presence of comets is hard to test; users who encounter problems when comets are present are invited to report bugs. 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 腾讯微云. 2020-08-19 For the new moon (lunation number 255), the new release (Galois) is out. It is now possible to insert and delete manœuvres in the flight plan; in particular, this makes it possible to insert correction manœuvres after rebasing. Manœuvres can be collapsed and expanded, making it easier to manage flight plans with many manœuvres. A bug involving incorrect thrust when planning RCS manœuvres was fixed. Thanks to @Flibble for contributing this fix. 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 腾讯微云. 2020-07-20 For the new moon (lunation number 254), the new release (Gallai) is out. As previously announced, this release dose not support KSP 1.7.3 and earlier. A rebase button has been added to the flight plan, to take changes to the actual trajectory into account without having to recreate the flight plan. Altitude-related information has been added to the orbit analyser. A number of bugs have been addressed: EVA collision leading to absurd movement, EVA parachutes being broken, vessels disintegrating at absurd speeds, vessels deforming when coming out of warp. 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 腾讯微云. 2020-06-21 For the new moon (lunation number 253), the new release (Galileo) is out. The exceptions raised by the external API for other KSP mods now include an error message. Miscellaneous bugs have been fixed (most notably, the centre of mass offsets are now taken into account). See the change log for more details. We support two sets of versions of KSP: downloads are available for 1.9.1 & 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 腾讯微云. This is the last release to support KSP 1.5.1, 1.6.1, and 1.7.x, as Realism Overhaul and Real Solar System now support 1.8.1. 2020-05-22 For the new moon (lunation number 252), the new release (Fuchs) is out. The issues with rotation (uncontrolled spin-up, jerky motion, oscillations, etc.) introduced in Frobenius and Fubini have for the most part been solved. We are aware of one remaining case of aberrant spin-up, reported by @scimas, but this seems to be a very rare issue at this point. Prior to ignition, the manœuvre node marker on the navball for guided burns now points to the orientation at ignition, instead of following the current Frenet frame. This is more useful for manual burns (the spacecraft can be oriented correctly prior to ignition, instead of having to be guided even before the manœuvre starts). Perhaps more importantly, in conjunction with change MuMech/MechJeb2#1264 (available in MechJeb dev builds ≥ 958), this means that MechJeb can execute all Principia manœuvres. New APIs have been added for use by @Sir Mortimer’s KerbalismContracts. See the change log for more details. We support two sets of versions of KSP: downloads are available for 1.9.1 & 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 腾讯微云. This is the last release to support KSP 1.5.1, 1.6.1, and 1.7.x, as Realism Overhaul and Real Solar System now support 1.8.1. 2020-04-23 For the new moon (lunation number 251), the new release (Fubini) is out. Support for 1.9.1 has been added. The flight planning and orbit analysis window are now available in the tracking station, bringing into line with map view. Some changes have been made to mitigate the aforementioned issue #2519. Wild spin no longer seems to be an issue, however some unexpected oscillations arise under some circumstances. We will keep investigating this issue. Some issues that would cause crashes have been resolved. See the change log for more details. We support two sets of versions of KSP: downloads are available for 1.9.1 & 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 腾讯微云. 2020-03-24 For the new moon (lunation number 250), the new release (Frobenius) is out. After nearly a year of work and 96 pull requests, Principia now enforces the conservation of angular momentum, as had been alluded to earlier. This means, among other things, that: the long-standing bug #1639, reported by @Damien212 in 2017, whereby the orientation of vessels changed when they underwent an SoI transition, is resolved; vessels will rotate as rigid bodies, following Euler’s equations, in time warp; in particular they may exhibit the Джанибеков effect in time warp, as illustrated in the short video below; changes in mass distribution within the vessel, e.g., due to fuel transfer, will affect the angular velocity, as illustrated in the short video below. See the change log for more details. 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 腾讯微云. 2020-02-23 For the new moon (lunation number 249), the new release (Frenet) is out. Nothing new this time; we have been working on the preservation of angular momentum, but it is not quite ready yet. See the change log for more details. 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 腾讯微云. 2020-01-24 For the new moon (lunation number 248), the new release (Frege) is out. Celestial histories are now displayed as far as requested in the past (if available), rather than being limited to the time of launch. Miscellaneous bugs have been fixed (perhaps most visibly, the wild camera spin in the pause menu introduced in Fréchet).  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 腾讯微云. 2019-12-26 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 腾讯微云. 2019-11-26 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 腾讯微云. 2019-10-28 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 腾讯微云 2019-09-28 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 腾讯微云. 2019-08-30 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 腾讯微云. 2019-08-01 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 腾讯微云. 2019-07-02 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 腾讯微云. 2019-06-03 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 腾讯微云. 2019-05-04 For the new moon (lunation number 239), the new release (Fáry) is out. The UI now scales according to the KSP UI scale settings, and has been made a little more compact; those flight plan settings that are controlled by a slider can now also be edited by text entry (this includes the Δv components and timing of manœuvres); the TRAPPIST-1 patch has been updated for @GregroxMun’s SLIPPIST-1 v0.7.x.  See the change log for more details. We support two sets of versions of KSP: downloads are available for 1.4.x, 1.5.1, & 1.6.1, and for 1.3.1. Make sure you download the right one (if you don't, the game will crash on load). 2019-04-05 For the new moon (lunation number 238), the new release (Fano) is out. The predictions are now computed asynchronously, making long predictions usable; this is particularly noticeable in the vicinity of bodies with complex gravity models, such as the Earth and Moon in RSS. Some bugs involving map view markers have been fixed. See the change log for more details. We support two sets of versions of KSP: downloads are available for 1.4.x, 1.5.1, & 1.6.1, and for 1.3.1. Make sure you download the right one (if you don't, the game will crash on load). 2019-03-06  For the new moon (lunation number 237), the new release (Euler) is out. Issue #2072, introduced in Erdős, which manifested as free fall unaffected by parachutes or engines below 8.4 m altitude in RealSolarSystem (leading to rough splashdowns), has been resolved. An API has been added to allow @Jim DiGriz’s guidance algorithms to access the geopotential coefficients; see #2074. See the change log for more details. We support two sets of versions of KSP: downloads are available for 1.4.x, 1.5.1, & 1.6.1, and for 1.3.1. Make sure you download the right one (if you don't, the game will crash on load). 2019-02-04  For the new moon (lunation number 236), the new release (Εὐκλείδης) is out. Support for KSP 1.6.1 has been added. This release fixes a long-standing issue (reported in November 2017 by @Agustin, in June 2018 on GitHub as #1868 by @scimas, and by @Delay in January 2018) where, under some circumstances, the SAS would not point the ship towards the markers (it would point the ship towards the position that the markers would have in stock instead). It also fixes a relatively rare issue involving fragments of vessels getting close to the centre of a celestial on reentry (#2056). See the change log for more details. We support two sets of versions of KSP: downloads are available for 1.4.x, 1.5.1, & 1.6.1, and for 1.3.1. Make sure you download the right one (if you don't, the game will crash on load). 2019-01-06 For the new moon (lunation number 235, partial eclipse), the new release (Εὔδοξος) is out. We have added an enhanced selenopotential in RSS, complete to degree and order 30; this means that the moon now has mascons, making some low lunar orbits unstable. Note that you will only get the new selenopotential when making a new save. As a concrete example, consider this screenshot of a lunar orbit, whose periapsis decreases by 3400 m over the course of 18 orbits because of the irregularities of the Moon's gravitational field (another dozen orbits later, the spacecraft collides with the Moon, between craters Spencer Jones and Spencer Jones W). Saves are now encoded in base64 instead of hexadecimal, making them smaller and faster to load. We have rerun the TRAPPIST-1 optimization, this time with a small enough integration time step allowing us to accurately model the dynamics of the system. Thanks to @AloE for spotting the incorrectly-timed transits. The resulting system has residuals similar to those reported by Grimm et al., with χ² = 358.79 vs. χ² = 342.29 in the paper. See the change log for more details. We support two sets of versions of KSP: downloads are available for 1.4.x & 1.5.1, and for 1.3.1. Make sure you download the right one (if you don't, the game will crash on load). 2018-12-07 For the new moon (lunation number 234), the new release (Erdős) is out. Support for realistic geopotential modeling at arbitrary degrees is finally available, with a 10th-degree model of the Earth geopotential in RealSolarSystem; more advanced modelling for other bodies (Moon, Mars, etc.) will be added in future versions. #1955, a performance issue on macOS (continuation of #1908), was resolved by using a different synchronization library. The issue reported by @AloE above (#1999) has been temporarily addressed by using the same integrator configuration that was used for the optimization. We will redo the optimization with a more appropriate configuration in a future version, as this issue likely indicates that the integrator had not quite converged. see the change log for more details.  We support two sets of versions of KSP: downloads are available for 1.4.X & 1.5.1, and for 1.3.1. Make sure you download the right one (if you don't, the game will crash on load). 2018-11-07 For the new moon (lunation number 233), the new release (Ἐρατοσθένης) is out. Support for KSP 1.5.1 has been added. We working on extending geopotential models beyonds oblateness (mascons etc.), but that is not yet ready; see the change log for more details.  We support two sets of versions of KSP: downloads are available for 1.4.x & 1.5.1, and for 1.3.1. Make sure you download the right one (if you don't, the game will crash on load). 2018-10-09 For the new moon (lunation number 232), the new release (Διόφαντος) is out. Nothing new this time; we have been working on improved gravity models, but they are not ready yet. See the change log for more details.  We support two versions of KSP: downloads are available for 1.4.5 and 1.3.1. Make sure you download the right one (if you don't, the game will crash on load). 2018-09-09 For the new moon (lunation number 231), the new release (Descartes) is out. Important note for mac users: Principia no longer supports macOS El Capitan, as that version is no longer supported by Apple. We now require macOS Sierra or later. As a consequence, there should be noticeable performance improvements for macOS users. We have added generalized Runge-Kutta-Nyström methods, which allow for a more accurate prediction of burns that are fixed in the Frenet frame. See the change log for more details.  We support two versions of KSP: downloads are available for 1.4.5 and 1.3.1. Make sure you download the right one (if you don't, the game will crash on load). 2018-08-11 For the new moon (lunation number 230), the new release (Desargues) is out. No new features in this version beyond the 1.4.5 upgrade, as we have been on vacation.  See the change log for more details.  We support two versions of KSP: downloads are available for 1.4.5 and 1.3.1. Make sure you download the right one (if you don't, the game will crash on load). 2018-07-13 For the new moon (lunation number 229), the new release (Δημόκριτος) is out. Vessels are now managed by Principia when they are in the atmosphere, which means that atmospheric flights have Principia histories and predictions in map view. The “Trappist-1 for Principia” mini-mod has been improved to better reflect the physical properties of the celestials. See the change log for more details. We support two versions of KSP: downloads are available for 1.4.4 and 1.3.1. Make sure you download the right one (if you don't, the game will crash on load). 2018-06-12 For the new moon (lunation number 228), the new release (Dedekind) is out. This release fixes a memory leak which could lead to increases in memory usage to the tune of 1 GiB / min when using the flight plan. Further, we are releasing a mini-mod that turns @GregroxMun's SLIPPIST-1 into the real TRAPPIST-1 system; the 7-planet resonant chain of that system makes it interesting from the perspective of n-body gravitation. The configuration is computed by transit-timing variation based on the transit timings from the recently-published paper The nature of the TRAPPIST-1 exoplanets by Grimm et al. See the change log for more details. We support two versions of KSP: downloads are available for 1.4.3 and 1.3.1. Make sure you download the right one (if you don't, the game will crash on load). 2018-05-15 For the new moon (lunation number 227), the new release (Darboux) is out. This release: uses a new implementation of the cube root which is more accurate and faster than most, as part of an ongoing effort for Principia to use its own implementation of elementary functions; adds Gipfeli compression and arena allocation when saving and loading, reducing save file size by about 2.5× and scene load times by about 2× for large saves; adds support for KSP 1.4.3. See the change log for more details. We support two versions of KSP: downloads are available for 1.4.3 and 1.3.1. Make sure you download the right one (if you don't, the game will crash on load). Darboux does not support KSP 1.2.2, as Realism Overhaul and Real Solar System now support 1.3.1. 2018-04-16 For the new moon (lunation number 226), the new release (Cramer) is out. This release: fixes a bug which caused manoeuvre nodes to jump at the time of ignition, especially on ejection and capture burns. Thanks to @Kobymaru and @EstrelaGaliza for reporting and helping diagnose this bug. adds support for KSP 1.4.2. Note that you may need to install a newer C++ runtime; see the change log for more details. We support three versions of KSP: downloads are available for 1.4.2, 1.3.1, and 1.2.2. Make sure you download the right one (if you don't, the game will crash on load). Cramer will not support 1.4.3, as Principia has special handling to work around ladder-related bugs, so we will need to test the new release to see if changes are needed. This is the last release to support KSP 1.2.2, as Realism Overhaul and Real Solar System now support 1.3.1. 2018-03-17 For the new moon (lunation number 225), the new release (Coxeter) is out. This release: uses SSE2 intrinsics for improved performance; addresses numerical stability issues in the Jool system reported by @Eriksonn; introduces an API for @Jim DiGriz's guidance algorithms; introduces support for KSP 1.4.1, thanks to @awang. See the change log for more details. We support three versions of KSP: downloads are available for 1.4.1, 1.3.1, and 1.2.2. Make sure you download the right one (if you don't, the game will crash on load). 2018-02-15 For the new moon (lunation number 224), the new release (Cohen) is out. The ephemerides are now computed using the Estrin method for polynomials expressed in the monomial basis instead of the Clenshaw method for polynomials expressed in the Чебышёв basis, improving the performance. See the change log for more details. Again, we support two versions of KSP: downloads are available for 1.3.1 and for 1.2.2. Make sure you download the right one (if you don't, the game will crash on load). 2018-01-17 For the new moon (lunation number 223), the new release (Clifford) is out. A bug in the implementation of DoublePrecision that caused a test to fail on Macintosh, as reported by @awang and @Jim DiGriz, was fixed. Solar system designers can now pick an integrator more suited to their solar system, as requested by @GregoxMun whose surprisingly stable Alternis Kerbol Rekerjiggered does not fare well with Principia's default integration parameters, which were chosen (in Cartan) to work for stock KSP and the real solar system. See the change log for more details. Again, we support two versions of KSP: downloads are available for 1.3.1 and for 1.2.2. Make sure you download the right one (if you don't, the game will crash on load). Thanks to @awang for contributions (clang warning cleanups) during this lunation. 2017-12-18 For the new moon (lunation number 222), the new release (Christoffel) is out. Vessels no longer pass through a planet unharmed at sufficiently high timewarp like in stock, and are detected by Principia as having collided with the planet, and are destroyed. In particular, this resolves the crash that occurred in 陈景润 when a vessel went through a planet unscathed (#1628, reported by @awang and @John FX). Support for KSP 1.3.0 has been dropped. We support two versions of KSP: downloads are available for 1.3.1 and for 1.2.2. Make sure you download the right one (if you don't, the game will crash on load). See the change log for more details. 2017-11-18 For the new moon (lunation number 221), the new release (陈景润) is out. This release solves a longstanding issue (#228) with the way trajectories were stored, which caused spikes or loops in histories computed at high timewarp. Again, we support three versions of KSP: downloads are available for 1.3.1, 1.3.0 and for 1.2.2. Make sure you download the right one (if you don't, the game will crash on load). See the change log for more details. Thanks to @awang for contributions (fixed a UI bug) during this lunation. 2017-10-19 For the new moon (lunation number 220), the new release (Chasles) is out. A long-standing bug, #1413, initially reported by @maccollo, and also reported by @Cristi, @DaMichel, @goldstarstickergiver, @lyttol, @nanomage, @Parafaragarmus, @rsparkyc, et al., was fixed. This bug prevented landing on peaks of some bodies (notably Minmus) as well as on the Moon in the current version (12) of RealSolarSystem. The fix involves making Principia handle vessels even when KSP's physics operate in a rotating reference frame, all the way down to the ground; as soon as a Kerbal jumps on Minmus, Principia computes its trajectory. Note that vessels within an atmosphere are unaffected; we intend to also handle these down to the ground, but this requires an update in @ferram4's FAR since we want to remain FAR-compatible. Further, Principia now supports KSP 1.3.1; downloads are available for 1.3.1, 1.3.0, and 1.2.2. Make sure you download the right one (if you don't, the game will crash on load). See the change log for details. Thanks to @awang for contributions (clang warning cleanups) during this lunation. 2017-09-20 For the new moon (lunation number 219), the new release (Cesàro) is out. The histories of the vessels are now computed in parallel, speeding up high timewarp on multi-core processors. A bug was fixed that caused a crash when crashing two vessels into each other. Again, we support two versions of KSP: downloads are available for 1.3 and for 1.2.2. Make sure you download the right one (if you don't, the game will crash on load). See the change log for details. 2017-08-21 For the new moon (lunation number 218), which is a total eclipse, the new release (Чебышёв) is out. The speed of the plotting of histories has been improved by about an order of magnitude. The slow plotting in previous versions was responsible for most of the slowdown in map view. Further, the predictions are now plotted smoothly even when they are integrated with a large tolerance. The flight plan now supports burns that guide themselves to follow the Frenet trihedron, e.g., tracking the tangent (prograde), or the binormal (the normal to the orbital plane). Select "Inertially fixed" in the flight planner to use an unguided burn instead, e.g., for spin-stabilized burns. For the first time, Principia supports two versions of KSP: downloads are available for 1.3 and for 1.2.2. Make sure you download the right one (if you don't, the game will crash on load). A couple of bugs reported by @panourgue and @scimas were fixed. See the change log for details. Thanks to @Iskierka and @Jim DiGriz for testing the Linux and Macintosh builds respectively. Note to RSS users: Principia correctly simulates the motion of the moon, so the eclipse occurs as expected when using Principia, even after more than 66 years of numerical integreation, see below. Conversely, without Principia, the Moon's motion cannot be simulated with the requisite accuracy to get correct eclipses, since it is a heavily perturbed orbit. 2017-07-23 For the new moon, the new release (Cayley) is out. It brings trajectories in map view, an update reminder driven by the Moon, a fix to a whole class of off-by-one physics bugs, and further bugfixes. Further, the build includes a binary for Macintosh, thanks to @Jim DiGriz. Note that the version string on Macintosh will mention Cayley-4 instead of Cayley-0. This will be resolved in future versions. See the change log for details. 2017-06-24 For the new moon (lunation number 216), the new release, Cauchy, is out. It brings relative speed markers on nodes, the unification of navball speed mode and reference frame selection, and displaying the trajectory of the target vessel if it moves in the plotting frame. This addresses requests by @lawndart, @maccollo, and @scimas. This release fixes: physics bugs: 1307 reported by @Damien212 and @maccollo, 1404 reported by @Bocian and @lawndart, 1415 reported by @scimas, 1421 reported by @NathanKell and @rsparkyc; a UI bug, 1402, reported by @lawndart and @maccollo; crashes: 1422 reported by @maccollo, 1441 reported by @rsparkyc. See the change log for details. NOTE: due to a forum mishap (stares at @technicalfool ) this thread has changed address, and all followers have been lost; if you had bookmarked the thread or followed it, you may want to do so again. 2017-05-25 For the new moon (lunation number 215), the new release, Catalan, is out. It brings no new features, but fixes a number of bugs and improves the underlying libraries. See the change log for details. 2017-04-26 For the new moon (lunation number 214), the new release, Cartan, is out, bringing with it a utility for rendezvous: the target local vertical local horizontal reference frame. There is a guide to low orbit rendezvous using the new reference frames (screenshots to be added in the near future). See the change log for details. Please read the concepts page carefully, it has been expanded since Cardano. Remember to also have a look at the FAQ if you have a question. Thanks again to @Iskierka for testing the Linux build. 2017-03-28 For the new moon (lunation number 213), the new release, Cardano, is out, bringing with it axial tilt, new reference frames, and timewarp-independent free fall. It marks the beginning of lunar releases. See the change log for details. In particular, note that Cardano is save-incompatible with Cantor. Please read the concepts page carefully, it has been expanded since Cantor. Thanks to @Iskierka for testing the Linux build. 2016-08-13 Cantor is out. This version is mostly the same as بوژگانی (see the change log), the intent is to make sure it is as stable as بوژگانی was: this is the first broadly available release, with a link to binaries outside the IRC channel (see the OP). In the meantime, progress has been ongoing (note that this is about a future release, Cantor contains none of the features below). Regarding our internal libraries, we have clarified the way we handle time (which is always an extremely confusing thing), with our Instant type aligned with Temps Terrestre (TT), and support for date literals in TT, Temps Atomique International (TAI), Coordinated Universal Time (UTC), and UT1 (based on the rotation of the Earth). This allows us to specify dates more cleanly in our tests. We tested the difference between the orbits of Mercury predicted by our ephemeris and by JPL's over a century, and we find the expected error in perihelion precession due to general relativity. On the side of flashier features, we seem to be well underway to having working axial tilt, by tilting universe the current main body (with terrain) is aligned with the axis used by KSP, and rotating the other ScaledSpace models appropriately; in a future release of Principia, the Jupiter, Saturn, and Uranus systems should look much nicer, with the planet properly aligned with its satellites. 2016-06-26 بوژگانی is out. A change log can be found here. 2016-05-20 Burnside is out. A change log can be found here. 2016-05-05 Буняковский is out. A change log can be found here. 2016-02-24 There is a bug in Buffon (2016022220-Buffon-0-g0455d0cb0e4b0b584a84caf40520cf7993903e0c) that causes a crash when starting a new save with RSS (loading an existing save works fine). The hotfix "2016022220-Buffon-12-g1298cffba22d90119bd59e9933a9ef261922a423" (let's call it "Buffon + 12") resolves that, so if you run into this issue just go back to the IRC channel to get the latest build, it will be Buffon + 12. There are no other changes between Buffon and Buffon + 12. 2016-02-22 Buffon is out, you can get it by asking on IRC (#principia on EsperNet), as usual. Changes: The integrators now limit the number of steps they perform, and terminate if their step size vanishes. This avoids issues where the plugin would hang when the trajectory would accidentally get very close to the centre of a celestial body or spend a long time in a low orbit. A use-after-free bug has been fixed which caused a variety of crashes (#872, #881, #889, #896) when the historical trajectory was shortened in a way that would cause it to start after the beginning of the flight plan. The version identifier of the plugin is now displayed in the UI to make it is easier to assert what version is running. A verbosity option has been added to the journalling which makes it easier for us to reproduce crashes. The first two items above are illustrated by the following two reports. For more details see all 19 pull requests between Brouwer and Buffon. 2016-02-11 Some clarifications regarding reference frames and flight planning. 2016-02-09 Brouwer is out, you can get it by asking on IRC (#principia on EsperNet), as usual. User-facing features: The whole Frenet trihedron is now displayed in the correct reference frame when "fix navball in plotting frame" is selected. The initial state (and thus the evolution) of the system is now deterministic even when not using RSS. Tidally locked bodies no longer spin back and forth madly (on the other hand, they may not be tidally locked if their mean period differs from their Jacobi osculating period). When using stock, the Jool system is modified, cancelling the apocalypse. Specifically, we make the inner Jool system nonresonant, since we have been unable to replicate the results (Manley, priv. comm.) according to which some interpretations of the orbital elements yielded a stable Laplace resonance, despite systematic searches of the Jacobi osculating elements. In addition, at Scott Manley (@illectro)'s and @UmbralRaptor's suggestion, we put Bop in a surprisingly stable, though highly precessing, retrograde orbit. The modified system is stable for upwards of a century. Flight planning has been implemented. Modder-facing changes: When a Cartesian initial state cfg is not given, the KSP orbital elements are interpreted in a hierarchical osculating Jacobi fashion; for instance, the orbital elements of Jool are the osculating elements at game start of the orbit of the barycentre of the Jool system around the barycentre of the (sun, moho, eve, gilly, kerbin, mun, minmus, duna, ike, dres) system; the elements of Laythe are the osculating elements at game start of the orbit of Laythe around Jool; the elements of Vall are the osculating elements at game start of the orbit of Vall around the Laythe-Jool barycentre. Optimizations: The Windows build now uses profile-guided optimization (we estimate that this improves performance by ~20%); in theory this could be extended to other platforms. The evaluation of the Чебышёв series has been significantly optimized. @sarbian made trajectory rendering faster (as he pointed out, there is still lots of room for improvement). Other features: Everything that crosses the interface can now be journalled if the right flag is set, allowing us to replay the C++ side of a session; this is useful for tracking down tricky bugs, and it enables profile-guided optimization. Highlights of miscellaneous library changes; beware, this gets technical: In order to get the full Frenet trihedron, which in turn was needed for manœuvres, since the Δv is defined in the Frenet frame at the point of ignition, geometric acceleration (the acceleration of a free-falling trajectory) in any reference frame was needed. To that we created two abstractions, RigidMotion, the derivative of a RigidTransformation, and DynamicFrame, the definition of an arbitrary reference frame. The navigation frames (the frames in which the trajectory is drawn, or with which the manœuvres are defined) implement that (see BodyCentredNonRotatingDynamicFrame and BarycentricRotatingDynamicFrame). In order to interpret the orbital elements of KSP in the hierarchical Jacobi fashion described above, support was added for Kepler orbits (implementation), Jacobi coordinates, and hierarchical systems. Discrete trajectories were reworked, with a heavy dose of CRTP. In preparation for the surface frame in the future, RotatingBody was added. The C++ interface headers and C# extern declarations were repetitive and error-prone, this was exacerbated by the addition of journalling code and replaying code, so a generator was written to produce all of that from an annotated proto. @UmbralRaptor contributed some tests of lunar eclipse timings. For both Kepler orbits and lunar eclipse timings, a simple root finder was needed, bisection does the job for now. A bibliography was written, at @UmbralRaptor's request (it is somewhat out of date). SolarSystem, a class for initializing ephemerides from protobuf text format configuration files for testing purposes was written. A script for generating the initial state configuration files from the emails sent by JPL's HORIZONS system was written (the gravity model configuration file is hand-curated). An utility turns the protobuf text format configuration files into KSP ModuleManager configuration files for RSS support. Various geometric utilities were added: angles (implementation), spherical coordinates (more are needed). More C++11/14 features were used as they became available (for instance, the units are now constexpr), in addition we now use std::experimental::optional. C++14-related improvements were made to not_null. For more details, see all 195 pull requests between Bourbaki and Brouwer. 2015-08-16 Bourbaki is out, you can get it by asking on IRC (#principia on EsperNet), as usual. Please bear in mind that the channel operators may be away from keyboard, so you should wait until you're noticed (it also helps to say the name of the channel operators since that pings them). As of 2015-08-16T15:38Z, the build for Win32 is ready, we're waiting for Norgg and armed_troop for the Linux and Macintosh builds respectively. Note that you should read the FAQ before installing principia. Rough changelog: Reimplemented integrators: the symplectic Runge-Kutta-Nyström integrator was reimplemented more cleanly, an embedded explicit Runge-Kutta-Nyström integrator was implemented. Abstractions for differential equations were created. Ephemeris: the celestial bodies are integrated on their own, with their own (much larger) timestep (45 min); their trajectories are then fitted using чебышёв series, yielding continuous trajectories. This means that when there are no vessels (including asteroids, see the FAQ), timewarp at very high speed (6'000'000x was tested in RSS) is smooth. The predictions are computed using an adaptive step size, so they're faster and less fiddly (you still get a tolerance setting, but it doesn't need as much attention as the step size setting; the step size will shorten near periapsis and lengthen near apoapsis on its own). The histories are still in fixed steps of 10 s, that will likely change in Brouwer, since it is one of the biggest performance costs now. There is an initial configuration for Real Solar System: the planets will start in the right places as given by the JPL HORIZONS service, and they are given gravity models using the freshest data available (Vesta's model is from Dawn data, some Cassini data gets used). Please note the RSS-specific recommendations in the FAQ. A side effect of that is that the moon becomes far more accurate: since the motion of the moon is very much a 3-body problem, it cannot be accurately represented in RSS alone. In particular, real-life eclipses can be observed in principia + RSS (please note the unexpected inaccuracy mentioned in the FAQ). This initial configuration also includes J2 for the Sun, the planets, the Moon, and Vesta, so the resulting effects are felt (precession of Earth orbits, the possibility of heliosynchronous orbits, etc.). Bourbaki is save-compatible with Borel, for RSS users, please note that unless you reset the plugin, the new initial state and gravity model configuration files will not be taken into account. 2015-05-07 The new version, Borel, is out (you can get it on IRC, as previously; the same caveats apply). Rough changelog: ported to 1.0.x (that only took a couple of lines); custom navball settings, so that the navball can be fixed in the reference frame in which the trajectory is plotted; the IVA navball is unaffected; when using the custom navball, the prograde/retrograde vectors are now in the correct reference frame, consistent with what is shown is map view; the rest of the Frenet trihedron (the radial and normal vectors) are unaffected at the moment and will be fixed in another version; fixed a few bugs (the tetrydsbug, the melonbug, the thutmosebug); less memory-hungry; added a setting to clip histories; added a toolbar button to show/hide the UI; the UI now acknowledges the F2 key; other things that I forgot. Moreover, Norgg and armed_troop have made good progress on Linux 64-bit and Macintosh 32-bit builds respectively, so if you're on these platforms you can go on IRC and ask for a build or for build instructions. With Windows 32-bit, Linux 64-bit and Macintosh 32-bit, we should be covering most users (I don't think it's worth doing a Linux 32-bit build). 2015-03-22 Serialization has been implemented, and rudimentary predictions have been added. The predictions are currently using the same integration method (McLachlan and Atela's 1992 optimal 5th order method), with the same splitting of the Hamiltonian (kinetic + potential energy), this is somewhat usable but unacceptably slow. I am currently implementing as many symplectic integrators as I can find in order to compare them, and I will also be comparing various splittings (as as nonsymplectic methods in use for computing ephemerides). I will probably write a post about these at some point (probably an advanced one, rather than an elementary introduction, this is quite a complicated topic). It seems that there is some interest in builds of Principia, no matter how unstable or slow they may be. If you want to try out the current version of Principia (Bolzano) for the Windows 32-bit version of KSP, go the IRC channel linked below and ask me for a build (my nickname there is egg, or sometimes something of the form egg|<status>|egg). CAVEAT: The current version is not stable, it can corrupt or otherwise destroy saves, it has been known to crash, and predictions are horrendously slow. #principia IRC channel on EsperNet. 2015-01-22 The refactoring of the physics bubble has been done (and some tests have been added), as well as some cleanup in the C# adapter (including some performance improvements, a lot of the performance issues occur on the C# side since the implementation is a bit careless there). More refactoring occurred (use of a not_null template for non-null pointers). The next step on the path towards playability is persistence: the state of the plugin must be persisted so that we remember the states of the planets, the histories of the vessel trajectories, etc. (currently loading a save or reverting will result in either a crash or a loss of consistency due to the planets having moved around). Persistence of our types will be achieved using protocol buffers, stored in config nodes: we don't want to use KSP's config format directly, since we have lots of highly structured data and operate far from KSP's API it would be inefficient and clumsy. We'll probably also use protobufs for caching when implementing trajectory predictions later on. Some work has already been done in that direction. Here are some more screenshots, showing a flight from Kerbin to the Kerbin-Mun L4 Lagrange point (the reference frame for each screenshot is indicated in the "Traces of various description" window). antedated 2014-12-13 Support for intrinsic acceleration has been added. Refactoring will be needed, but it works, as demonstrated by the following plane change manÅ“uvre: 2014-11-07 Some work has been done on better abstractions for rendered trajectories, nothing significant yet (in particular there still is something in Õ(n) which could be in Õ(1), runs at each frame, where the constant factor involves evaluating trig functions, and n~10_000 is the number of rendered points, so that rendering trajectories in the barycentric rotating frame is slow), but some pretty pictures. This shows a vessel near the L5 point of the Kerbin-Mun system. In the first image, the trajectory of the vessel is displayed in the nonrotating reference frame centred on the Mun, in the second it is displayed in the nonrotating reference frame centred on Kerbin, and in all subsequent images it is displayed in the barycentric corotating reference frame of the Kerbin-Mun system. Work on intrinsic acceleration is ongoing. 2014-10-28 Code has been written to plot the trajectories in nonrotating body-centred reference frames (and barycentric corotating, not reviewed yet). While abstractions will have to be written to do that more cleanly and efficiently, this yields some pretty pictures. Caveat lector: While some of the following orbits may look very wild, bear in mind they are in non-inertial reference frames. Two of these wilder trajectories are followed by the same trajectory in a more pedestrian reference frame. In the Kerbin-centric non-rotating reference frame, they would all look like two or three elliptic orbits connected by strange segments where the perturbation by the Mun is to blame. The last picture below (in the barycentric corotating frame of the Kerbin-Mun system, that is, the unique frame in which the Kerbin-Mun barycentre as well as the line through Kerbin and the Mun are invariant) shows a trajectory that differs strongly from what stock KSP would have yielded: in stock this would have been a circular orbit around the Mun near the edge of its SoI. Instead it is a transfer to an eccentric Kerbin orbit, which is picked up by the Mun again after a while and ends with a crash on the Mun. With the addition of plotting, the C++ plugin has caught up with the features of the initial C# prototype. After the abstractions for plotting are written (we will add the remaining interesting reference frames in the process), the next step will be to take care of altering the trajectory when, e.g., engines are used. It is apparent that the C++ plugin is significantly faster, much more reliable, and easier to debug than the C# prototype (it is also correct; some hasty shortcuts were made in the prototype that resulted in unreliable initial states and other problems). 2014-09-30 Trajectory, an abstraction for a tree of trajectories that can be forked into child alternatives (useful i.e. for predictions, manoeuvre nodes, but also simply computations at different precisions), has been written (part of the physics namespace) The plugin has returned, first as a simple orbit-freezing plugin, then as a plugin that actually integrates the motion of vessels (only on-rails for the moment). Is does not plot yet, so it is still behind the C# prototype in terms of features, but it is significantly faster. As was previously mentioned, all calculations are done in a native assembly, called by P/Invoke via a (cdecl) interface. It should be noted that the plugin uses glog everywhere for logging (since logging from native code is needed). Of course, this means Principia will have its own log files (in <KSP directory>/glog/Principia, with a log of the last session in <KSP directory>/stderr.log. Another interesting aspect is that there will be no silent exceptions as in managed plugins, instead, the game will either segfault (when dereferencing an invalid pointer) or abort (SIGABRT) if a glog CHECK macro fails (on Windows the latter yields the "KSP.exe has stopped working" message). I have been informed by Sarbian et alii that this will result in Fun support. 2014-07-04 I wrote the second explanatory post, on Hamiltonian mechanics (PDF). Prerequisites are chapters 4, 8, and sections 11-4 and 11-5 of Richard Feynman's Lectures on Physics. The next post will be on symplecticity and the leapfrog integrator. 2014-06-27 The integrator (still a 5th order SPRK, same as in the C# prototype, the Saha & Tremaine stuff isn't here yet) has been implemented, tested and benchmarked (using a Windows port of google/benchmark) in C++, as well as the first level of abstraction above it, principia::physics::NBodySystem (header, body, test, header for test data, test data, test of test data (which is also a nice example of the use of principia::quantities and principia::geometry, benchmark (using the test data)). A significant change of plans has occured: As Unity uses the .NET Framework v2.0, it is not possible to use plugins compiled for the Framework v4.5. This means C++/CLI projects need to be compiled using the platform toolset v90 (from VS2008), rather than VS2013's v120. Of course v90 does not support C++11 nor C++14, so it is not an option for this code that strongly depends on C++11 features. As a result, we will keep using the C++11 codebase, compiling it to a native DLL, and using P/Invoke to call it from a C# adapter. The C# adapter will perform no calculations, only transmit data from KSP to the native plugin and apply the changes/render the trajectories returned by the plugin. A simple test P/Invoke plugin can be seen on the repository (header, body, C# adapter) and works in KSP. This means there will be separate x86 and AMD64 builds for each target operating system (Microsoft Windows and 57 varieties of Unix), possibly more if we decide to do specific optimisations for Intel chips (though ICC is not cheap). Moreover, this will allow a switch to clang in the near future, so that we can have saner error messages and better compliance with the standard. 2014-05-12 I now have a collaborator on Principia, https://github.com/pleroy (my father). This means the code gets reviewed and that development is faster. We have decided to completely switch to C++/CLI due to better test tools and useful language features. Most of the code will actually be written in standard C++, with the implementation inlined in header files, so that they are seen by the eventual C++/CLI managed assembly (If we were to use C++/CLI everywhere, we would need managed boundaries between the assemblies, which is quite inconvenient). As an added advantage, using standard C++ enables putting performance-critical parts into a native assembly if needed at a later time, without requiring a significant rework of the code. We have started switching to gmock, gtest and glog for mocking, testing and logging. These tools are more convenient and powerful than the Visual Studio testing framework and are open source, so that users of Visual Studio Express (which does not support Microsoft's testing framework) will be able to build and run tests if they want to. Here is the first test to be converted to gtest: https://github.com/mockingbirdnest/Principia/blob/master/geometry/sign_test.cpp. 2014-04-03 The Quantities library (C++) is pretty much done and tested. I am currently porting the C# Geometry assembly mentioned previously (now called CTSGeometry) to C++ in order to enable its use with these quantities. 2014-03-15 The Geometry assembly seems to be mostly feature complete, so I'll start writing tests tomorrow (Saturday) after changing a few access modifiers, replacing the ugly switch statements in Permutation by something nicer, and a few optimisations. See here for an overview of its features. 2014-03-04 I have investigated the feasibility of using other languages for KSP plugins: The following languages can be used on their own to write a plugin: C#(unsurprisingly), F#, C++/CLI (with no calls to native code). VB.NET can be used, but wrappers in one of the above languages are needed due to its case-insensitivity. Unity does not support mixed-mode DLLs, so calls to native code have to be made using DllImports in one of the above languages. I have started doing some refactoring since the sphaghettiness of the code was getting on my nerves. I have written strongly typed wrappers for the numerous reference frames spawned by KSP (direct vs. indirect, rotating vs. inertial, world vs. body-centric, etc.) as I have had numerous bugs due to a misplaced xzy, rotation, translation, scaling, inertial force etc. Of course, since KSP has the brilliant idea of using both direct and indirect reference frames, I needed distinct types for vectors, bivectors and trivectors (basically I had to strongly type Grassmann algebras; there can be no cross product, only wedge products, commutators and left and right actions of alternating forms---where is identified with through the inner product, and is identified with ). I do not think I will implement strong typing for physical quantities yet (though I'd like to), since C# generics are not powerful enough for that; I would need C++ templates. I'll do that when I rewrite things in C++/CLI. The next step is to implement my own versor, since Unity's Quaternion is in single-precision float and KSP's QuaternionD is broken. The rest should be more straightforward refactoring. 2014-02-24 It turns out I have trouble properly setting the position when off-rails (finding out where the reference frame actually is is hard). However, there are some nicer news: I seem to have found the source of the phantom acceleration bias (not the ones arising from rotation, the bias that is removed by timewarping). The floating origin sometimes floats several km away from the ship, so that's probably just floating-point inaccuracies (the usual Kraken). If that hypothesis turns out to be true, this particular acceleration bias will be easy to fix, just reset the floating origin often enough. 2014-02-19 I have successfully implemented the integration of proper acceleration for the active vessel when off-rails. Further experimentation on proper acceleration has led me to the following conclusions: There is a bias in proper acceleration coming from some improperly initialised variable in KSP. Indeed, when loading a vessel in LKO, I observe a strong bias in proper acceleration (~20 mm s-2). This bias is observed independently of the way proper acceleration is computed (differentiating position twice, differentiating any of the numerous velocities, etc.) and geometric accelerations have been checked from first principles (the difference in geometric acceleration depending on the point of the vessel it is computed at is negligible). The bias is reduced to below 1 mm s-2 when warping then coming out of warp. It should be noted that the strong bias is not seen in Vessel.perturbation, but Vessel.perturbation consistently has a bias of 4 mm s-2. As I have attempted to compute the proper acceleration in many different ways and all were consistent with each other and inconsistent with Vessel.perturbation, I assume Vessel.perturbation is mostly nonsense. Accelerations below 1 mm s-2 are biased, unavoidable, unusable in stock, and should be clamped to 0. The acceleration from low-thrust engines will have to be fetched by hand. It had previously been mentioned that spinning the ship accelerates it. If spinning the ship with angular velocity É produces a phantom acceleration a, then spinning it with angular velocity -É produces a phantom acceleration -a. It seems a is either prograde or retrograde. 2014-02-17 I have finally managed to work on this a bit over the weekend. Extensive experimentation has failed to yield a better velocity, so we are stuck with computing the proper acceleration from the rather mysterious Vessel.obt_velocity for now (for some reason in whatever reference frame this velocity is in, the geometric accelerations are as expected, except for the Coriolis acceleration which is halved ). This yields roughly the same results as Vessel.perturbation without the moving average. The same experiments have further shown that a naïve low-pass filter will not be enough to remove Unity's silliness. For instance, one finds the proper acceleration is strongly correlated with the rotation rate of the ship. Smarter post-processing will be needed. I shall now attempt to actually integrate whatever proper acceleration I have managed to grab. I also wrote the first explanatory post, which describes ODEs and Runge-Kutta methods (PDF). I have tried not only to explain how Runge-Kutta methods work (this can easily be found on Wikipedia) but why they have this structure. Hopefully you will find it interesting. 2014-02-08 I fixed a bug or two since 2014-02-05, added a few TODOs, but have not cleaned up the code to any measurable extent. I am, however, publishing it on GitHub (under the MIT license). Caveat Compilator: As previously stated, this is just a proof of concept with a bunch of traces. Pressing the wrong buttons in the wrong order will result in lots of NullReferenceExceptions and off-rails crafts will behave weirdly. Using HyperEdit to set up initial conditions, then switching to Newtonian physics and fooling around with reference frames can be entertaining though. You might learn something from looking at the Integrators part (which admittedly contains only one integrator), the rest was quickly hacked together, has no tests, is badly structured &c. The 'Simulator' project probably won't compile, it's leftover from my Alternis Kerbol simulations. It's not needed. 2014-02-05 This is currently hardly more than a proof of concept. The simulation only affects on-rails vessels, thrust is ignored (thus you can't actually play while the simulation is running) and the integrator is too slow. However, it shows a few interesting things: Near-unit-roundoff (using IEEE 754 binary64) errors can be achieved while sustaining 100_000x timewarp with B = 17, V < 5. Handwavy asymptotic calculations indicate that for V = 100, this integrator would slow down to about 20_000x timewarp. Using better integrators (and saner tolerances), performance could easily be increased by a couple of orders of magnitude, making the simulation usable for RSS as well as stock. Trajectory plotting in rotating reference frames, or reference frames centered around a body other than the primary, can be useful even for near-Keplerian orbits: it allows for visualisation of RT2 satellite coverage, easier landing prediction, etc. The stock integrator is terrible, and will have to be overriden at all times while in space (when near a Lagrange point, a fraction of a second under stock integration will turn a Kerbin capture into a Mun collision). If you think floating SOIs (or worse yet, SOIs with repulsive gravity) are a half-decent model for Lagrange points, you don't really understand how Lagrange points work. Expect a slow development cycle, due to a combination of laziness, exams, and this actually being a complicated project. I'll put the source on GitHub as soon as I can clean things up a bit (there are quite a few traces that were too hastily implemented for my taste). This might take a few days, see above. Nonetheless, here are some pictures that illustrate the fun trajectories in the N-body problem. The second and third pictures have a misplaced trajectory, this bug has been fixed. Some pictures have three strange red, green and blue lines, which indicate the origin and axes of world space. Notations Terminology Considerations on numerical integration The current prototype uses a straightforward fifth order SPRK method. The coefficients used are from (Atela & McLachlan 1992). The increments are accumulated using Kahan summation. The integration is performed with a constant 10 second timestep (numerical experiments suggest that the error is close to an unit roundoff with a 5 second timestep for LKO). Regarding implementation details, the integrator is written in C# (compiled with VS2013) and uses double (IEEE 754 binary64) for all computations. Scott Manley suggested using hybrid symplectic integrators (Chambers 1999) in order to speed things up. It should be noted that the concerns that the Chambers paper attempt to alleviate might not be critical for gameplay purposes (the main integration can probably be done with a very small timestep compared to the ones commonly used in astronomy. Moreover, timestep reduction occurs de facto when getting out of warp, as the game cannot conceivably be played with timesteps of several seconds). It could become relevant for trajectory predictions in vessels under thrust, which has to be done in a few hundred milliseconds over several years. For those predictions, the timestep would have to be increased to durations comparable to those used in the paper, and similar concerns would arise. The results from the papers quoted by Chambers, namely (Saha & Tremaine 1994) and (Holman & Wisdom 1991), will probably have to be used in order to make the main integrator faster. Experiments will have to be carried out in order to find out whether a higher order (> 2) integrator is worth using, and how the added cost of Keplerian evolution (which requires numerically solving the Kepler equation for all bodies, which is very costly due to the trigonometric functions) affects performance at acceptable time steps. Open questions for the interested reader Regarding KSP modding The method I currently use for drawing trajectories (LineRenderers, object in layer 9, transform.parent = null, useWorldSpace=true, updated every time the GUI is drawn) has some issues: when rotating the camera in map mode, the lines lag behind. Does this have a known solution? (I guess so, RT2 doesn't have this problem). And indeed, the RT2 code contained the solution. Thanks, Cilph! Is there a way to directly set the position and velocity of the planets and vessels in world coordinates? OBE, the API does not make sense in highly original ways. Can anybody think of a way to mod in axial tilt (even a hacky one; remember that I'm the one moving the planets around anyway)? OBE (done in RSS, we actually have axial tilt, it's just that all planets rotate around parallel axes). Regarding aerodynamics Could somebody help me with the implementation of orbital decay drag when I get to implementing that? ferram4 told me he'd help. Thanks! Would it be conceivable to predict the results of aerobraking/aerocapture/ballistic reentry with FAR (within some error margins, to be displayed on the predicted trajectory)? How slow would that be? Answered by ferram4. This might end up happening. Regarding astrophysics and astrodynamics The uniformly rotating reference frame around the barycenter with respect to which the two massive bodies are fixed is very useful when looking at trajectories in the CR3BP (Lagrange 1772). What would a good reference frame for the ER3BP (for bodies with highly eccentric orbits, e.g., Eeloo in stock, Pluto in RSS) be? the uniformly rotating one around the barycenter that follows the mean anomalies, the nonuniformly rotating one that follows the true anomalies, or something else entirely? In the rotating-pulsating reference frame that fixes both bodies, the equilibrium points are fixed. Is there a way to draw things in that reference frame on the in-game map that's not too confusing? Can it still be useful to draw the potential for the parts of the equations of motion that derive from a potential, given that the independent variable is true anomaly rather than time? Should long-term trajectory predictions for vessels under thrust be inaccurate, is there a good way of estimating the uncertainty (for instance, would predicting a few perturbed trajectories and plotting them all give a representative idea of what might happen)? ferram4 suggested a few interesting things. Would drawing the gravitational potential in the current orbital plane (together with the centrifugal potential if orbits are drawn is a rotating reference frame) be useful? Answered by ferram4 with visualisation suggestions. The answer is 'yes'. How should stationkeeping be implemented? In particular, how should the user set the orbit they want to maintain? Regarding the KSP fora Do we have LATEX support? If that isn't the case, is it conceivable to have it in the foreseeable future? Further modding Once the mod gets to a functional state (taking thrust into account), I shall attempt to solve the problem of trajectory prediction for vessels under thrust. In the process, the smarter integrators mentioned above will be implemented, and the most efficient one will be kept. This should significantly increase computation speed. This will also enable instantaneous-burn maneuver nodes (the kind of maneuver node we have now). The barycenters will be fixed in order to stabilise the Jool system. Scott Manley (illectro)'s predictions indicate this will make it stable over at least 1_000 years (Pol was not part of those predictions, its stability remains to be determined). Speed will be further increased by rewriting the numerical integration in (unmanaged) C++, interfaced with C# through C++/CLI. The unmanaged C++ (compiled with clang) will use 80-bit extended precision 'long double' (64-bit mantissa instead of 53-bit) for added precision. Once the mod becomes playable with N-body gravitation with point masses, the following effects should be relatively easy to add: Conservation of angular momentum through timewarp and outside timewarp (allowing for spin-stabilisation and thus fixed RT2 antennae if Cilph decides to implement that); Thrust through timewarp, for ion engines and the like, together with maneuver nodes for non-instantaneous burns; Orbital decay drag, with ferram4's help; Stationkeeping, to deal with orbital decay and unstable weakly bound orbits; Gravitational moment (quadrupole) for planets, enabling such amusing things as Sun-synchronous orbits; Insert crazy idea here... Acknowledgements I would like to thank (in alphabetical order of forum usernames) Anatid for his attempt at documenting the KSP API, armed_troop for his help in making the codebase clang-compatible. Ezriilc, Forecaster, khyperia, Payo and sirkut for their HyperEdit plugin, which is really useful for setting up initial conditions, Scott Manley (illectro) for his help with numerical integration of the N-body problem, Matt Roesle (Mattasmack) for writing an integrator which was far better than the one I used, thus prompting me to write my current SPRK integrator, NovaSilisko for his Alternis Kerbol mod, which piqued my interest in the simulation of the N-body problem, The entire KSP modding community (especially the subset which writes clean, well-commented code) for providing code examples from which one can learn the subtleties of dealing with the KSP API. If I forgot you in the above list, please complain! Bibliography Mathematica documentation on SPRK methods. [Atela & McLachlan 1992] Robert I McLachlan and Pau Atela, The accuracy of symplectic integrators, 1992. [Chambers 1999] John E. Chambers, A hybrid symplectic integrator that permits close encounters between massive bodies, 1999. [Holman & Wisdom 1991] Jack Wisdom and Matthew Holman, Symplectic maps for the N-body problem, 1991. [Kenniston 2002] Michael Kenniston, Dimension Checking of Physical Quantities, 2002. [Lagrange 1772] Joseph-Louis Lagrange, Essai sur le problème des trois corps, 1772. [saha & Tremaine 1994] Prasenjit Saha and Scott Tremaine, Long-term planetary integration with individual time steps, 1994. [Tao 2012] Terence Tao, A mathematical formalisation of dimensional analysis, 2012. Eric Weisstein's World of Physics, Gravitational Moment. [Yoshida 1990] Haruo Yoshida, Construction of higher order symplectic integrators, 1990. [Yoshida 1992] Haruo Yoshida, Symplectic Integrators for Hamiltonian Systems: Basic Theory, 1992.

Sounds great! However, I think frizzank's FASA H-1 is a better model for the H-1 than the Mainsail.

They do. I was confused. Yes, several tank types per resource would solve a lot of problems. Not only the 'main engines feeding to RCS' problem, but also fancier things like life support (life support O2 and H2 in the Apollo SM or STS shouldn't be drained by the engines, and having a separate resource for the same thing would be an inelegant solution). Plus, the idea of RCS that doesn't work under acceleration or whose thrust decreases with use sounds like potential for hilarious failure.

You need the bladder to fill the tank completely when inflated, so I'm afraid this would be next to impossible. Piston or rolling diaphragm designs might work. As for a solution, I think we should ignore the really fiddly details of the STS OMS and go with the following for engines non-RCS: - All non-RCS engines need stable fuel to start (the fuel should be at the bottom, current ullage simulation). - Pressure-fed non-RCS engines can only feed from pressurised tanks, which are heavier (thicker tank wall, helium piping and tanks). The fancy tank types are only used for RCS engines, with the following characteristics. - RCS can only feed from bladder (representing bladder, piston and rolling diaphragm) and surface tension tanks. Bladder tanks are heavier for the same fuel quantity, as they represent clusters of small tanks (the mass should increase linearly with the volume for volumes above 50 L, representing clusters of tanks rather than one tank getting larger). - If the ullage simulation says the bubble's not in the middle, RCS can only feed from bladders. RCS can always feed from bladders. This way RCS doesn't accidentally feed from main propellant tanks, and if you want to do that (which should be a backup plan), you can use the game's fuel transfer. EDIT: for the proportionality constant for bladder tank mass, I would suggest using the Astrium site as a reference: 8.5 kg of tank mass for 39 L of propellant. Add to that about 100 g of He (for a starting pressure of 26 bar, which is the upper range of inlet pressures specified by the Ariane 5 ACS thrusters), handwave in another 400 g for a few valves and piping, and call that 230 g/L (litres of fuel). As far as density goes, the volume of the sphere seems to be 58 L, so if we pack the spheres closely, that's 1 l of fuel for 2 l of tank space. This should be enough to make filling the stage with bladder tanks prohibitive. EDIT2: If we want to add an interesting detail, both types of RCS tank have two possible configurations: blow down, where the tank contains some set amount of pressurant gas and pressure (thus thrust) decreases as fuel gets used up (many examples Ariane 5 is one), and pressure regulated as in the LM bladders or most large surface tension tanks. Pressure regulated means constant thrust, but more mass (more pressurant gas, need an He or N tank). So that would make our lineup: - For non-RCS engines: -- Unpressurised for turbopumps -- Pressurised for pressure fed - for RCS: -- Bladder blow down, heavy but always works, decaying thrust. -- Bladder regulated, heavier still but constant thrust. -- Surface tension blow down, works in zero g, don't shake, decaying thrust. -- Surface tension regulated, a bit heavier, constant thrust. If we only want two types of RCS tanks, I'd recommend bladder blow down and surface tension regulated: the point of bladders is to be simple. If we can allow three, I'd say both bladders (but if we can do three we can do four). With that we should be set as far as tank types go. (There's the spin stabilized ones, but we'll worry about those when we can keep things spinning through timewarp). Caveat: I haven't tested this yet. The thing you really want is *unmanaged* C++, compiled with clang or something like that, which you call from *managed* (CLR) code in your plugin (managed C++ won't be much faster, and using the Visual Studio compiler, double is the same as long double, so you can't make use of 80-bit extended precision either). The most straightforward way to do this is to just import an unmanaged dll, but you have to be very careful with marshalling and keeping your interfaces compatible and declaring your members in the right order... O, that way madness lies. Let me shun that; No more of that. A better solution is to have your C# code call some C++/CLI code, also managed, so it's like calling C# code, and have the C++/CLI code reference unmanaged C++ (as you have a header file, you don't have to do the interfacing brute-force).

Yes, and they did that on the LM (they used two tanks for each ergol, cleverly called 'Oxidizer/Fuel A and B'; see schematics APOLLO EXPERIENCE REPORT - LUNAR MODULE REACTION CONTROL SYSTEM, page 4). That's quite a bit of piping though. On the one hand, that makes sense. On the other hand, I've not heard of something other that RCS/tiny satellite engines being fed from bladders. Even the larger RCS tanks seem to be surface tension. It depends whether you still have the old-style pressurised fuel tanks. If we want to fully model the mass overhead from He blowdown (and thus He tank, piping &c.), we will probably need to have them, thus pressure-fed engines can only feed from pressurized tank (as in real life), but they still need fuel stability. If we want to ignore this (it doesn't change much gameplay-wise now), pressure-fed engines are just like any other engine. http://cs.astrium.eads.net/sp/spacecraft-propulsion/propellant-tanks/surface-tension-tanks.html On modern tanks, the acquisition vanes are all around the walls, yes. It seems to only be used on RCS. Nope, it's just another kind of positive-expulsion (bladder-like) tank. It would only matter if we considered shifts to the part CG due to fuel mass distribution, and I don't quite think we're ready for a realistic plumbing mod where you have to make sure your propellants won't eat through your tanks, route the pipes, place the tanks inside the stage, chose their shape, place He tanks, route the helium to the preheaters and then to the tanks... Perhaps, I haven't looked at that in detail. They're only used for storable propellants, from what I can see, so there's no bubble (the gas is outside the bladder). Maybe, but the plumbing would probably be insane. I've not seen any evidence of that. As a conclusion, Non-RCS/ACS/whatever it's called engines don't seem to use bladders. However, So the OMS was fed in a surface-tension way (but not quite, since they still work under their own thrust), unless the fuel level is below 28%, in which case you need ullage thrust for long burns (this is getting complicated). Moreover, Ok, let's not go down the rabbit hole of the plumbing weirdness of the STS. How about this: engines need ullage acceleration no matter what (and if we want do model thicker pressurised tanks as well as the overhead from He storage and piping, pressure-fed engines can only feed from pressurised tanks). They can't feed from bladder and surface tension tanks. RCS can feed from either bladder or surface tension tanks (if you really want to allow for crazy stuff, let's say they can also feed from normal pressurised tanks, though as this might accidentally drain your main engine fuel, it needs to be toggleable in flight), with no ullage requirements for bladder, low acceleration for surface tension (basically, any acceleration that makes the water clinging to your ceiling fall down is bad), and if you want to go that way, standard ullage requirements for standard pressurised tanks. This is simple enough to be understandable, models most of the existing interesting complexity, and doesn't force us to draw plumbing schematics and do advanced fluid mechanics in order to be sure that the OMS *will* fire when we need it. EDIT: Apparently, NathanKell was right about the gas being inside the bladder and the propellant outside.

This would be easy* to put in the integrator I think, as would orbit decay due to atmospheric drag at higher altitudes (provided I can get assistance from Ferram in computing drag). I need some sleep right now. * Rien n'est simple, Tout se complique (two books by Sempé). EN: Nothing is simple, Everything gets more complicated. This applies surprisingly well to anything software-related.

Next up: "general relativistic effects, such as frame-dragging and the precession of the perikerbolion of Moho, are impossible!" (and I'm not doing that in the foreseeable future). EDIT: unrelated to GR, but not treating the planets as point masses, but as quadrupoles, might allow for Sun-synchronous orbits, which would be a nice thing. Let's get this point-mass thing working first.

With the current (C#) integrator, a 10 s timestep won't let you above 120_000x (and with 80 vessels, that would go down to ~24_000x). I'm not sure how much unmanaged code will improve things and while I might end up doing it, I don't want to think about doing computations on the GPU right now. However, once I implement the Chambers-Saha-Tremaine integrator (Saha & Tremaine 1994), with modifications by (Chambers 1998), who apparently worked with the one and only Manley, I should be able to do most of the integration with timesteps of a few weeks, thereby making thing way faster (hopefully fast enough for a few years of prediction---with reduced tolerances---in a FixedUpdate or two for vessels under thrust). I might still use the 5 s timestep stuff, which seems to be as good as exact, for low timewarp, and maybe tweak the Chambers-Holman-Saha-Tremaine-Wisdom (yes, there's also Holman & Wisdom 1991) integrator to a higher order than 2. EDIT: Regarding floats, it's a bad idea to ever manipulate anything with lower precision than doubles. Depending on how it's compiled and what it's compiled on/for, computations with floats can also be slower

Actually, it would tend to make things slower. Computing a force pair is one square root and one division, each on the order of 10 clock cycles (the multiplications and additions are free for all practical purposes) If B is the number of planets, V the number of vessels---considered massless---, that's roughly 20 B(B + V) = 20 B^2 + 20 B V cycles for the step (actually, a single one of the six stages of the integrator). Computing the position of the planet at a given time (which I'd need, as I'm applying the forces from there) requires computing the inverse of Kepler's function K(E, e) = E - e sin E, which, even if you start with a table, has to be refined by a few steps of Newton's method, each step of which will require a division (which might as well be for free) and a trig function, which will be a few hundred cycles. Let's say 200 cycles, three Newton steps, 600 cycles. That's 600 B cycles to compute the positions of all the bodies, 600 B + 20 B V cycles for the stage. In KSP, B=20, so 20 B^2 = 8000 < 12000 = 600 B. (Okay, I was biased in picking the numbers, but that's the same sort of speed). Things change if you want to pick significantly larger steps, and I'll need to read a few papers Scott mentioned. The general idea seems to be that you move bodies following their orbits around the barycenter, then take care of the influence of other bodies, handle close encounters separately, rinse and repeat. This still is fully N-body though. The concerns of system stability that Scott was raising are irrelevant to RSS (if I can show that Jupiter will lose one of its moons within the next year, I probably screwed something up---or I should be published in Nature), and can probably be handled in stock KSP by moving the planets to a more stable configuration. Anyway, who doesn't like stray planets flying around? EDIT: Another reason for not keeping the planets on-rails is that you lose symplecticity (the energy, momentum and angular momentum of your system may drift).

I already have something that moves the planets around (I just set the orbits of the planets and vessels according to their q and v as predicted by the integrator at every tick, brute-force but it works). Doing the integration in a separate thread is possible, and I intend to do it at high timewarp, but it won't improve performance much (I can very nearly sustain 100_000x timewarp and I've been talking to Scott Manley about making the integrator smarter than 'pick a tiny timestep, integrate slowly at that timestep'. Experiments seem to show that for LKO, my 5th order SPRK is exact to an unit roundoff for timesteps of 5 s though, so I might use that at reasonable timewarps and maybe up to and including 100_000x. I will need Scott's smarter techniques for predictions of vessels under thrust, which have to be done within a tick over at least a year). At some point I'll rewrite the classes that don't interact directly with KSP in unmanaged C++ (compiled for the processor rather than for the CLR) so it's faster (and so I can use long double extended precision 80-bit floating points, whose 64-bit mantissa give me a discretisation of 1 mm at 1 light-year instead of 1.4 mm on Sedna with doubles, at no cost in performance). As I said, lots of work ahead. EDIT: This isn't the right thread, but while I'm talking about floating-point precision, why don't you use doubles in MFS/RF? That would nearly eliminate the problems from error accumulation during resizing. Just convert to float when you talk to somebody that wants a (single) float and to double when you get a float.

I'm making an integrator that computes the positions/velocities of the ships and planets, so it doesn't do collision physics and the like. I'll do that. What is it and where can I find it?

NathanKell: I might as well say it more explicitly: n-body physics (and once that works, I'd like to add other stuff, e.g., orbit decay outside the 'official' atmosphere, conservation of angular momentum through timewarp to allow for spin-stabilisation, etc.). Let me hijack your thread with pictures of trajectories (which don't really show fancy n-body physics, but do show plotting of n-body trajectories which happen to be very close to the 2-body ones in various reference frames). As you can see, the other orbit is ever so slightly broken. Also, this only affects on-rails craft at the moment. There is quite a bit of work ahead.

NathanKell: What about surface tension tanks? It seems fun (from a gameplay perspective) to have to worry about ullage on large RCS tanks (especially since the conditions for stability are somewhat backwards from normal tanks). Ullage simulation would have to be integrated into the RCS (or altogether moved to the tanks) though. They aren't exactly a niche thing either, the list I wrote above included the ATV and BepiColombo, as well as a good number of satellites (admiteddly, they're mostly used on satellites for stationkeeping, which we don't need---yet. I'm slowly working on that.---but the ATV is another story).

It seems you got it right originally: you *need* ullage thrust for anything other than small-capacity tanks (the propellant is in a bladder by the way, not the other way around). It's a good thing you don't need ullage thrust for RCS, otherwise you'd need to light an SRB in order to to enable fine attitude control... The exception is low-thrust stuff, where you can use surface tension tanks. You'd have to tweak the ullage simulation for those though, as they settle in zero g but are messed up by any acceleration. Apparently, these are widely used. The Astrium site seems to confirm they're used in quite a few spacecraft: Astra 1K, Insat-SE, Astra 1M, Amazonas 2, Arabsat 5B, Astra 1N, Astra 2E-F, Astra 5B, Artemis, Arabsat 2, Cesasat, Eutelsat W24, Arabsat BSS, Thaicom 3, Sinosat, Sirius, GEII, HotBird, Sircal, Globalstar, Theos, Pleiades, RocSat, Cosmo/SkyMed, Aeolus, BepiColombo, AMOS-3, TV-Sat, TDF, Tele-X, Italsat, DFS Kopernikus, Eutelsat-2, Turksat, Nahuel, Insat-2A to 2D, the ATV... EDIT: for surface tension tanks, I guess you want to check that the radial and vertical ranges of the bubble are mostly in the middle, in which case you can feed from tanks marked as surface tension (the surface tension flag needs to be implemented on the MFS/RF side, like the current pressurised one of course). EDIT2: This stuff is pretty reliable... EDIT3: Actually, I'm not sure pressurised fuel tanks are interesting to model (you *need* a pressurised tank for a pressure-fed engine, but since it's an engine property, maybe we can just abstract it out of the tank, much like we ignore the helium used to fill the ullage space in non-pressurised tanks, e.g., on Saturn V), perhaps the following classification might make sense; - bladder (no ullage constraints to feed from it, max. volume a few 100 L) - surface tension (can only feed from it at very low accelerations) - normal (can feed from it under the current ullage conditions) Where only pressure-fed engines can feed from bladder and surface tension tanks. EDIT4: Of course things would have to be tuned so that starting an AJ-10 from a bladder or a surface tension tank and then feeding from a normal tank isn't practical. Perhaps only RCS thrusters should be able to feed from the bladder and surface tension tanks. In any case, there should be some ullage simulation in RCS thrusters in case they feed from surface tension tanks (which they often do).

I'm confused by this part of the statement (and previous ones regarding pressure-feeding). Pressure-feeding shouldn't remove the need for ullage: if your pressurised gas ends up below the propellant in the tank, opening the valve will just throw helium into space, depressurising the tank, the propellants will not reach the combustion chamber, and you will not return from space today. As an example of a real-life pressure-fed engine which required ullage, take the TRW Descent Propulsion System (hypergolic pressure-fed). Note that +X is upwards here, just to confuse everyone. The same considerations hold for the SPS (AJ-10). EDIT: The RCS doesn't require ullage because its propellants are stored in a bladder which sits inside a tank of pressurised gas. This can only be done for small volumes though. Here is an example of a hydrazine bladder manufactured by Astrium EADS (wait, now it's Airbus Defence & Space) for the Ariane 5 ACS (picture with humans for scale. They don't make bladder tanks for more than 39 L of hydrazine.). EDIT2: Of course, the LM RCS used bipropellants, each in its own bladder. The schematics can be seen on page 4 of this document. It seems the tanks are larger than on Ariane 5, but they're still below 100 L. EDIT3: With surface tension tanks, you can remove the need for ullage (as in, at low accelerations or in zero-g, the fuel will eventually settle where you need it), but it doesn't work under significant accelerations (in a way, the ullage works backwards for them).

I just looked through your code and unless I'm missing something it doesn't seem like you're implementing compensated summation. That means you'll get a very significant accumulation of unit roundoffs, which would explain the higher errors. I would suggest taking a look at http://reference.wolfram.com/mathematica/tutorial/NDSolveSPRK.html#1464293172 (this article is about SPRK methods, but it can also be applied to your integrator; basically, you run your Runge-Kutta step to compute the increments instead of the actual state, and you use compensated summation to add up the increments). There are also a few places where you could shave off an unit roundoff or two, e.g., r = 1.0/(dx*dx + dy*dy + dz*dz); r *= sqrt(r); tmp = sys[j].mu*r; // Could be: r = (dx*dx + dy*dy + dz*dz); r *= sqrt(r); tmp = sys[j].mu/r; // That will cost you a division, as you also do that with sys[i], but you gain an unit roundoff by doing a division instead of an inversion followed by a multiplication. but this is minor. In my simulation over 10 years with a constant 1 s time step (downsampled to 1 ks for plotting), Minmus and Pol escape (Boepli and the satellite are still happily watching the show in highly stable orbits). I'm not sure simulations make much sense with such a chaotic Mun though. I looked at the positions and velocities when I get outliers in H, p and L, and they don't seem to be near 0. I have no idea where these outliers are coming from... There are some close Kerbin approaches by the Mun and Pol. I think the closest Mun approach is either a collision or a Mun-shattering encounter: the closest distance I have is 1351 km center-to-center, which is above the Roche limit of 921 km, but I only sample every 1 ks, so the distances at the datapoints either side of the minimum are 2360 km and 2480 km. A collision is well within the uncertainty.