Search the Community

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-05-08 For the new moon (lunation number 301), the new release (کاشانی) is out. Compatibility with pre-Grossmann flight plans has been improved. See the change log for more details. 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.

-=Duna Sample Return Mission=- - Part 1: Destination Duna - The target area for the Duna Sample Return Mission. <<<<<<<<<<Foreword>>>>>>>>>> The amount of information that accumulated during this initial mission step... was starting to get to a point were, if I decided the entire completion of the challenge had to be included, the post would become excessively long (even for my standards). It felt naturally to conclude part 1 with the (to a varying degree) successful arrival of all 3 vehicles to Duna SOI. I hope you'll all find what I learned, doing this, engaging and interesting to read. <<<<<<<<<< Mission Tasks >>>>>>>>>> A. Launch Duna Rover and Duna Sample Retriver into a Duna transfer orbit, and return 1st and 2nd stage - Success B. Launch Duna Sample Returner into a LKO, and return 1st and 2nd stage - Success C. Land Duna Rover within the Target Area on Duna - Success D. Land Duna Sample Retriever within the Target Area on Duna - Success E. Get Duna Sample Returner into LDO ~60km - with enough Δv for the return trip - Failure <<<<<<<<<<< Lessons Learned; Lessons Identified>>>>>>>>>> Goal Post A: Launching the Ground Vehicles Duna Sample Retriever being launched into orbit - 5 days after the Duna Rovers succesful launch The launch of the 2x ground vehicle was succesful. I was not too worried about these launches as I had a very good understanding of the behavior of the launch vehicle. I scheduled the launch to coincide with the "optimal transfer maneuver node position" (I decided to wait for KSC to be in the ideal position to launch the rover.) Normally I always launch the vehicle into LKO first. Then find the optimal place on the vehicles orbit, to do the transfer burn that will take me out of the Kerbin SOI. But I decided that I did not need to take such precaution, and launched the vehicles directly from the pad and into a duna transfer trajectory. KSCs position in relation to Kerbins orbit around Kerbol. I was however still very conservative. (could have launched later) I wanted to perform the transfer burn around Kerbins retrograde around Kerbol - roughly the area K.G.01 is located on the image (the orbiting object) - because that would push my prograde towards the travel direction of Kerbin - placing me on the outside of its orbit, and towards Duna. (i'm sure you all know what I mean) 1st stage has reached the target velocity and is preparing for stage separation and return to KSC The 1st stage had no issues pushing the much lighter vehicle into its target suborbit. Normally it is very slow to gain altitude and needs to cut the engines at ~900m/s - But I had ample Δv left to push it up to a 1100-1200m/s before performing stage separation and the flip maneuver. (as mentioned in a previous post - the 1st stage usually launch a much heavier vehicle) Stage separation and flip maneuver - it would be days before the 2nd stage would make it back to Kerbin. The stage separation was successfully performed and the 1st stage would soon find itself back on the pad - while the 2nd stage would start its climb, to push the Duna Rover Capsule out of the Kerbin SOI - It would then be ~6 days before it would reach AP and start its fall back towards Kerbin. Which coincided with the Duna Rover Capsule escaping Kerbin. With a buffer of 6 days it felt safe to launch the Duna Sample Retriever. I hoped that 6 days would give me ample of time for the capsules to arrive at Duna in a manner where I could land them both in a short succession. I was some what successful - for more details jump to goal post C Both 1st stages was successfully returned to KSC - and even on the first go! - see spoiler section for details: 2nd stage of the Duna Sample performing Duna Transfer Burn. The 2nd stage would then perform an initial burn - aiming to get its AP into the vicinity of Kerbins retrograde vector. Like I said earlier, I was conservative with the launch window - giving me a coasting phase, and ample time to plan the Duna Transfer Maneuver: Left: Duna Sample Retriever Transfer Trajectory - Right Duna Rover Transfer Trajectory. After the 2nd stages had performed a majority of the transfer burn to Duna. The stage would separate and burn retrograde to push its PE back within Kerbins SOI. After that it was just a long coasting phase until PE - at which they would perform a maneuver putting the vehicle into a suborbital trajectory, and end up in the oceans on Kerbin again. The Duna Rover Capsule performing the rest of the Duna Transfer Burn. Upon stage separation the Duna Rover Capsule and Duna Sample Retriever capsule would spend 428Δv and 403Δv of their total 525 Δv getting a intercept trajectory with Duna. Once out of Kerbin SOI it was time to do the fine maneuvering, putting the two capsules into a crashing trajectory with Duna - My theory was that If I aimed at the center of the planet, then I would arrive more "centerly" on the planet, and then when I did the final aiming maneuver for the target landing zone - I would get an suborbital ark that would hug the polar atmosphere more tight than if I came in above the poles. Which would result in a PE on the "back side" of Duna, since dipping into the atmosphere would happen after they passed over the target area and subsequently result in a much more equatorial landing. The theory was some what right.. although I probably have to aim south of the southpole to get the effect I was actually looking for. Future missions will tell. After the succesful transfer burn to Duna there was only one thing left to do. See if the Grid fins on the 2nd stage would be enough to keep the heat shield pointed in the right direction on reentry. Duna Rover second stage successfully landed in the ocean of Kerbin. The Duna Rover 2nd stage reentered the atmosphere with 400 Δv left (remember it's 400Δv after shedding the weight of the capsule) - making it able to keep the heat shield pointed down. However it did splash down with 15 m/s - meaning it only landed unscathed because it landed in the ocean. To see if the 2nd stage would go sub 10 m/s if it was empty the Duna Sample Retriever 2nd stage was spending its last Δv making sure to target ocean. The lost mass from the front, meant that it was no longer able to point prograde - but it survived the angled reentry. How ever it still splashed down at 12 m/s. Meaning that a re-design has to be made for the stage. I have a feeling that I get better performance from aerobreaks when re-entering. So I'll try change the grid fins for aerobreaks and add more parachutes. The chances of hitting land is slim.. but it would be annoying to lose a perfectly good engine because of a hard landing... and It is very hard to gauge where you land from the edge of Kerbins SOI Goal Post B: Launching the Orbitter The Duna Sample Return vehicle being launched into LKO According to the KSP Δv roadmap - the tour- from LKO to LDO is ~1700 Δv. By getting better at finding the optimal launch window for Duna I had cut my Δv consumption on a Duna Transfer from 2000+ Δv to around 1200Δv (observation from the failed duna rover mission.) The Duna Sample Return vehicle had almost 5000 Δv in total- meaning that I should have 1600 Δv to spare, since the return trip would be a collision trajectory with Kerbin. It should be no issue to launch it to a LKO and have the vehicle leave the Kerbin SOI on its own power. I wanted to do this to see how many passes around Kerbin it would take to get it on to a Duna transfer trajectory. Stage separation - the first stage is performing its flip maneuver, engines still glowing hot red. Launching the small ion driven vehicle into orbit was going to be a walk in the park - since the 1st stage, and triple LV-909 "Terrier" engined 2nd stage (as I am sure you know by now) is well understood and tested. - it is the glider without wings after all. The 1st stage was of course returned safely to the pad. This time I made sure to burn enough Δv that I would end up with the around 300 Δv needed to break the fall and land... not taking any chances that it was a weight issue that caused the leg to break off last time. - look at the spoiler section to see succesful launch and landing of the 1st stage. the 2nd stage coasting after releasing the Duna Sample Return vehicle - blinding the camera with its huge solar panels providing the vehicle with 67,76 EC/s The 2nd stage boosted the vehicle into an elliptical orbit, reserving only a 100 Δv to get it back into a suborbital trajectory. The 7 ion engines of the Duna Sample Return vehicle would then be tested for good, checking how many passes around Kerbin it would take to get enough power to leave Kerbin SOI. Duna Sample Return vehicle doing the last corrections before coasting to Duna - waving Kerbin goodbye Amazingly enough it would only take the vehicle 5 orbits to gain enough velocity to escape Kerbins SOI. However.. either the Δv readings for the vehicle is wrong, or I have been super inefficient at doing the transfer burn to Duna. Because once the Duna Transfer Trajectory was set - the fuel reserve was halfed but the Δv readings were ~1/5th. The Duna Sample Retriever vehicles route to Duna - notice that the vehicle has lost 3707/4852 Δv on the transfer maneuver. But have only halfed its Xenon reserve. The Duna Sample Retriever vehicle were also aimed to arrive at Duna at the second intersection point of the orbit - giving the rover more time to pick up relevant samples from the target area - to be send home for analysis. Checking the site for habitability for future missions. 2nd stage re-entering high above Kerbin. Although the 2nd stage was the last to get into orbit around Kerbin, it would still be the first vehicle to touch down on Kerbin again. It had a soft landing in the desert on the continent west of KSC. The 3 aero breaks proved sufficient at keeping the nose pointed forward - albeit the vehicle were still having a bit of fuel to make the nose heavier. But were the vehicle had sufficient drag to keep the engines out of the plasma cone. The heatshield did not ample protect the faring disc right underneath it. Resulting in the piece failing on the final stretch, just before sheading velocity enough to not "be safe". Fortunately Kerbals make their vehicles of sturdy stuff! So even though the heat shield was dumped from the failing farings disk. The loss of the heatshield drastically reduced the speed! the vehicle did not suffer any further failures and landed perfect. The 2nd stage waiting to be retrieved in the deserts to the west of KSC. An easy solution to this issue will be to move the faring disk Infront of the heat shield, and add a decoupler to drop it once re-entering? or swap places and use it as a form of pre-heat shield? Avoiding further vehicle complexity. Goal Post C: Landing the Rover Duna Rover intercept trajectory - running low on fuel. For some reason the Duna Rover's, last adjustment of its trajectory to hit Duna, spend ~100Δv of the ~150Δv (that were left after leaving Kerbin SOI.) Whereas the Duna Sample Retrieve vehicle would successfully do the same maneuver at less than half the same Δv. Even so, I was not worried - 52 Δv was more than enough to do the final corrections once inside the Duna SOI - provided I did them upon entering the edge of the SOI (if you didnt know, the further away from the body you do your maneuver, the cheaper it is). Aming the vehicle - so it would land on the target area - would become much more challenging though. Especially if it would be on the night side since its hard to see the terrain features in the dark (and spoiler alert - the target area would be on the night side). However.. as a stroke of fortune out of missfortune. The Duna Rover were not going to be the first vehicle to arrive at Duna. Even though I had given it a 5 day buffer it had still been overtaken by the Duna Sample Retriever: Vehicle order from left to right: 1: Duna Sample Returner - 2: Duna Rover - 3: Duna Sample Retriever. This meant that the Duna Sample Retriever capsule - which had 115 Δv to play with, could afford to do path corrections all the way down to Duna, and land on the right spot. And then the Duna Rover Capsule could look at the Duna Sample Retrievers relative position to were it were heading and do relative precise maneuver corrections to the target area from a great distance. Duna Rover closing in on Duna - Ike visible in the distance. It all paned out great. To make sure I got the right point, I quick saved upon entering the Duna SOI and then allowed the vehicle fly within 200km of the planet. Then I checked where the Duna Sample Retriever were located in relation to the spot of the Duna Rover impact. Quick loaded and adjusted the course onto roughly the spot the Retriever would be in the 2d and 5h it took to get to Duna. The maneuver costed less than 10Δv. Cruise module separates from the capsule once the final aiming has been done. Once within 100 km of the landing area, I made the last adjustments, decoupled the cruise stage and enjoyed the show. - see section D for capsule performance thoughts See spoiler section for slideshow of the capsule entering Dunas atmosphere. After the Capsule decoupled from the rover, the rover did have some issues though. The lack of RCW meant that it was rolling uncontrollable on the way down, and would not stabilize before hitting the ground. I could somewhat control the rate, with which the vehicle was falling, by firering the landing engines for the durating the engines were pointing downwards, as seen here: But as you can see it was not optimal.. luckily the Rover landed "successfully" and by a stroke of luck.. it rolled over, onto the wheels again. I disengaging the decent stage ASAP the wheels were all level with the ground... I was simply afraid the stage was making the rover top heavy and it would fall again. In the end it all panned out and the Rover landed only 5.7km away from the Duna Sample Retriever. - Mission Success! Kerbol dawning on Sol 1 of the Duna Rover mission. Goal Post D: Hitting the Target Area. Duna Sample Retriever after the final course corrections - all the Δv spend. As mentioned in Goal Post C, the Duna Sample Retriever were the first to reach Duna. Once inside the SOI I saw that it would take it 2d and 5 hours to hit the surface. I looked at the position of the Challenge 2 lander to the target area, and tried to roughly aim were I thought the place would be within 2d. and 5h. - I really wish the game had a tool that allowed us to see future rotation when planning a maneuver. Then periodically on the way down I would fine tune the landing site. Until I was only 200km from the surface. At which point I believed I could do the fine tuning of the landing and ditch the Cruise Stage. After that it was all about figuring out how the capsule would perform on the way down. The Duna Sample Retriever Capsule after ditching the cruise stage. The capsule performed well, although, just like the Challenge 2 Lander, It accelerated for a long time. In the end I had to perform a flip maneuver to break the fall - It seems the heat shield work a lot more like a speeder than a break. One should think that the blunt shape of the heatshield would make it break more.. compared to the pointy farings. But It may just be me thinking too much of Dunas thin atmosphere. See spoiler section for the hot reentry: The faring sustained the final speed drop facing forward and were jettisoned: Duna Sample Retriever dropping the capsule and preparing for landing. I had some issues were the ditching of the faring, within the atmosphere, would severely warp the assent stages. It made me re-do the landing several times as I was sure it was the issue were if you time warp with the vehicle SAS set to point to a direction (like prograde) it can warp the vehicle (same bug mentioned in the CommNet satelite deployment). I tried disable all RCWs on the accent stage, so It could not bend the stage into a wrong shape during time warp. Then made multiple Quick Saves - always dropping the faring afterwards to check if the vehicle had warped - before quick loading and proceeding the landing. I got all the way to re-entry.. were I noticed the warp happened from the decoupling within the atmosphere. To combat it I made the vehicle flip one last time before decoupling, and decoupled as the ascent stage was pointing roughly prograde. It warped a tiny bit.. but not so much that it clipped into the launching ramp (which it did before, and i was sure would result in a catastrophic failure) Lessons Learned; Lessons Identified - use struts. I am sure its a bug.. but since struts break when placed across a decoupler.. I can always strut the pieces in place. After that drama, it was all about deploying the chute and prepare the landing. Duna Sample Retriever performing landing burn. The lander touched down no issues - I turned off the lights and then waited for the sun to come up before deploying the solar panels. I had to put the stage into hibernation as it does not have enough battery power to make it through the Duna Night. I dont see it as an issue - since the challenge does not state that the vehicle needs to be able to last a Duna Day. It can launch the accent stage during the day time once the time for that arrives. Duna Sample Retriever - safe on Dunas Surface, generating power. After a short test that the accend stage could launch without failing, I saved and uttered a sigh of relief - The hard part was done - The Lander had hit the target area without circularising its orbit first and without breaking. Soon the rover would join it.. and then it was just waiting for the Return Vehicle to get into a LDO before concluding Challenge 5 and 6. Goal Post E: So close and yet so far Duna Sample Return vehicle circularising its orbit. The experienced KSP player will have guessed that this is as far as the journey went for the retriever. I know I said I allowed it to get its rendezvous with Duna on its second cross of its path. the II: symbol on the maneuver node. But I waited the time and pretend that I performed the survey of the valley in the mean while. I had to know if the returner would have enough Δv to finish the mission. Or if a sample return had to be postponed another 4 years. Alas the latter was the case. I made 2 important lessons though: Lesson A: Capture Burn I learned i was right about taking a path that brought my PE high into Dunas SOI. I tried to break and stay within Duna on a trajectory that brought me close to the planet ~100km altitude. I did not have enough Δv to circularise the orbit. I could reverse my orbit, but not circularize it. So I remained far out: Duna Sample Returner capture maneuver As you can see it would take a majority of my Δv to capture Duna. If any one has any council on how to perform this part at a Δv discount, I am all ears. - and before you say aerobreak, I dont think Dunas atmosphere is thick enough that it will break the vehicle to not break out of the SOI again. Lesson B: Solar panel effectiveness. Around Kerbin - the two SP-XXL "Colossus" produces a total of 66.76 EC/s. But around Duna the two sails only produce 31,56 EC/s - more than a half in reduction. I did not expect the effect to drop that much - Duna is not that much further from Kerbol than Kerbin. The result was that the vehicle could only use 3½ of its 7 ion engines around Duna. In other words over half the engines were dead weight this far out. Maneuver to LDO: Even though the vehicle had arrived at Duna with no means to complete the mission, I still spend the time to find out what was the optimal way to lower my orbit. I arrived at the conclusion that the cheapest way to lower my orbit was this: A. Lower the PE to the target distance of ~60km: 3 burns at AP - duration: 3 min B. Lower the AP to the target distance of ~60km: 5 burns at PE - duration: 3 min - 1.100km altitude 4 burns at PE - duration: 6 min - 150km altitude 1 burn at PE - duration: 4 min - 91km altitude 1 burn at PE - duration: unknown - ~60km altitude. If any one have any better solutions to get the orbit down cheaper - I am all ears. The Duna Sample Return vehicle in LDO In the end the vehicle successfully lowered its orbit from the edge of the Duna SOI to a ~60km circular LDO. However, as is evident from the screenshot. It completed this leg with far to little Δv to bring the sample back to Kerbin. - After I had learned what there was to learn, I spend the last 173 Δv to de-orbit the lander. <<<<<<<<<< Moving Forward >>>>>>>>>> The Ground Vehicles were succesful in their designs and execution - the retriever needs more work. How ever I have already redesigned the vehicle from the LL;LI in Goal Post E. - Reduced the number of engines and increased the fuel capacity. As the post is already really long, I will be pushing that update into the Part 2 of this mission. Next post will be the challenge completion of Challenge 5. I will take samples in the target valley - to determine if it's ideal for a science outpost to continue further excursions. Stay inquisitive, stay engineous - until next time! Final landing places of the Duna Rover, and the Duna Sample Retriever.

The trade is risk from boost/repair vs risk from doing nothing (the only alternative). I have no idea when the risk-reward heads into the right territory, but I'm confident that those curves cross at some point. It supposedly fails 2030-2040 assuming nothing bad happens before that (an eqp failure). Assuming it can be dealt with after such a failure, or once the end game for it is actually in play, then such a mission could wait until then, clearly. If the plausible failures include modes that make rendezvous and boost/repair impossible, then waiting too long could result in the certain loss of Hubble (tumbling?). Where the risk outweighs the benefit? Again, unsure. What I do know is that NASA has exactly zero capability to deal with it for the foreseeable future.

Anyway it seems the financials are out and they reported an over 2 billion impairment loss in Q4 and total loss of near 3 billion that I am quite sure wasn't there in Q3. https://ir.take2games.com/static-files/c189ec33-cb0d-44a0-8d20-2d3352836999 Page 17 shows 2.7 billion loss in Q4 alone. That's rather eyebrow raising to say the least. This guy is restreamimg the conference call now, it's live now:

Dude, you need some sleep. And perhaps a good chat with a good friend. If I have 1000 apples, and someone says me that between 3.85% and 16.48% of them are rotten, I have a loss somewhere between 38.5 and 164.8 rotten apples. If some other dude by some reason guessed that perhaps about 1% of the apples were rotten, then that guess would be about 10 rotten apples. Now please tell me: 10 is a number more near 35.8 or more near 164.8? Anyway, I think that enough is enough. At this point, absolutely nothing that I can say will change anything, so the best option is just to... Ignore. I see no reason to keep feeding the trolls - and some people here are trolling.

So when I was searching for how high a high-altitude balloon can go, I found that the Pongsats had their own Wikipedia page: https://en.wikipedia.org/wiki/PongSat Buried in the references is a 2020 roundtable by Weekly Space Hangout where they interview John Powell (segment starts 10:34, ends 20:31) and he lays out the whole rationale behind the Airship To Orbit program: Condensed transcript (to read the transcript for yourself instead of watching the video - and this works on all subtitled YT vids - go to the page, expand the description and click on "Show Transcript"): JP Aerospace is a volunteer aerospace company with a small paid staff and about 70 volunteers. The airship-to-orbit thing is their patented(!) idea, and the Pongsat was a side thing about 15 years ago of taking student payloads to orbit for free, that's kinda grown to this "giant, unwieldy monster" that's now about half of what they do. Airship-to-orbit is a new way to get to space that doesn't use rockets. Not until the end, at least. Unlike Orbital Sciences and Pegasus' 50,000 feet, they want to start at mach ten and about 300,000 feet (91,440m) and go from there. Starting with the predecessors to Echo 1 in 1959 and onwards to something called the ROBIN program, almost to the present day people have been firing off sounding rockets and deploying balloons at very high altitudes and at Mach 10. (The latest reference I found on a cursory search is of a 1991 paper, "The inflatable sphere: A technique for the accurate measurement of middle atmosphere temperatures." Fire rocket up to 85km, deploy balloon, track with radar as it sinks, gain accurate density and thus temperature data on the middle atmosphere.) There's actually been a dozen of these balloons, and they're all about the same: getting balloons to cruise at Mach 10 for atmospheric research, measuring drag, consistency, and after a while they started putting solar panels, radio, instruments on them. They also dovetailed into using them as nuclear weapon decoys which ended up as big sources of funding of such work; the science ended up being a rider of the decoy program. When an ICBM comes in it deploys quite a few decoys, and these are reentry vehicles at hypersonic speeds, but they're also balloons. (Found under "Penetration aid" *snrk* on Wikipedia, where mylar balloons are indeed mentioned. For pictures, see also: https://www.globalsecurity.org/space/systems/decoys.htm. I love the dummy nuclear warhead.) Their thinking was: what if you made it more aerodynamic? What if you went faster? What could you do with 60 years of advances in technology: Mach 14? 500,000 feet (152,400m)? Mach 18? 800,000 feet (243,840m, which is above the final 224km VLEO of ESA's GOCE, which had xenon ion thrusters)? That's the question they're trying to answer: can you take it all the way to orbit? He has no idea! V-shape of high-altitude-to-orbit vehicle is because it ended up being statically stable in all three regimes: subsonic, supersonic and hypersonic. Craziest part is this has to be so big: you end up as a gossamer structure that goes at hypersonic speeds. An airship like that doesn't survive in the lower atmosphere. With a 5MPH crosswind you suddenly have 800,000 tons (assuming US imp. tons, that's 725,600 metric tons) acting on the side, and then you have confetti. It basically cannot fly any lower than the edge of space. So they have three stages: the blunt, minimally-aerodynamic v-shaped bulk load-lifter that goes to 140,000 feet (42.6 km) and no higher, the Dark Sky Platform high-altitude station and the high-altitude-to-orbit launch vehicle that docks and lives there. They tested their 100-foot (30m) long Ascender 9 prototype [in 2019] and their DS is made of 5 of them connected together, which makes a stable platform. The giant things they launch are completely silent as they streak away. They had some nasty official outs from that as it kinda freaks out the authorities - which they enjoy. Orbital vehicle, as mentioned, has to live on the platform, and has to be assembled - well, inflated - there. It's buoyant to 180,000 feet (54.8km) then slowly starts to move forward. Not even breaking Mach (presumably Mach 1) till they get to 200,000 feet (61km). Engines are plasma engines. Had 200 test firings and literally 800-900 more test firings to go, probably 5-6 more years (from 2020. Most recent Dec. 2023 update they had just started on the magnetohydrodynamic tests, where they added energy by making a spark gap in a magnetic field, and turned on the propellant). Ion engines are too low thrust, chemical rockets would rip the ship apart. Their solution is essentially 'dirty' ion engines: the mixed gas coming out of the combustion chamber is the plasma to be ionised (Editor's note: sounds like a magnetically-contained arcjet-boosted rocket). The engines they're running right now (in 2020) could be thought of as the world's worst ion engines: instead of about 60,000 ISP, theirs are about 1200 ISP. Which is actually good for chemical. It's a stupid engine that only has one use: it's "a steamship engine that goes putt-putt-putt for days". (Propellant is paraffin seeded with potassium. No note on oxidiser.) Once they get to the altitude of the rocket-launched weather balloons, they have a little more structure and aero and hopefully they can go faster. Once clear of the atmosphere, they turn off the electrical stage to have a final chemical-only orbital insertion burn. On the way down they fly at mach 1. Sounds impressive for a structure made out of foam and carbon fibre, but at 100,000 feet (30km) they've kinda pulled the teeth out of that; it's really not impressive. Efficiency-wise it's not very efficient; a more instantaneous release of propellant is the most efficient. What you gain is thinking time for emergencies: he cites the narrow windows of escape in the space shuttle; a loss of an engine is a loss of crew. With this, say you're Mach 15, you're only three quarters of the way through the entire process and you have a big engine failure. Well you go back and you take a look at it. You sit down and have a meeting while you're drifting back down to try to get it to work. If you do, you continue on. If you don't you can float back down and rejoin the station. You really don't have that in rocketry. (I will note that their focus in 2024 has shifted to bulk cargo transport, with a humongous 30-metre payload bay that'd let them capture Hubble intact.) Pongsat has become so overwhelming with 80,000 ping-pong balls flown and 3-4 missions a year, it's being spun off into its own non-profit. They get so much flat-earth hate mail.

You mean a game they so far have put in about $50M into and that raised over $10M in Early Access already, before having a full marketing push or having a console release? Again, I'll say it a little louder for these in the back. KSP2 was on track to be a positive RoI despite all of the delays even with existing leadership. If T2/PD really believed that Intercept was being mismanaged, they needed to replace 3-4 people to create the minimal disruption to the project. The Intercept layoffs had absolutely nothing to do with T2 having doubts about KSP2's financials. This is purely about cutting costs. T2 just posted a $2.9B loss. Their operating costs shot up from $1B in 2023 to over $3B in 2024FY. The interest on loans was $14M in 2022, $140M in 2023, and $100M in 2024FY. The company has been borrowing and hiring aggressively over the 2020-2023, and currently cannot be sustaining these expenses. They had to cut costs dramatically for 2025FY, because GTA VI isn't shipping until 2026FY. And that's the ENTIRE reason for KSP2 getting suspended. To not come back to KSP2 development the moment the situation changes would be just leaving money on the table. T2 simply has bigger problems right now than smaller titles PD normally handles.

Since it seems a new thread pops up every time a celebrity dies, I thought maybe a thread should be dedicated to their memory. Hopefully this thread will become the place to report news of celebrity deaths, instead of RIP threads scattered all over. This thread was triggered by the recent loss of two Canadians who, while not well known, played major roles in Canadiana. First up is Emily Griffiths, who died last week at age 96. A philanthropist, she was instrumental in convincing her husband Frank to buy the Vancouver Canucks NHL team and keep them in the city. https://globalnews.ca/video/4914013/emily-griffiths-is-remembered-after-she-passes-away-at-the-age-of-96, A big deal to locals, this news probably meant little outside BC And on the news today, Ron Joyce, the co-founder of the iconic Tim Horton's coffee shop chain passed away Thursday at age 88. https://www.cbc.ca/news/canada/nova-scotia/tim-hortons-ron-joyce-died-1.5001820. This could turn into a national day of mourning, since a double-double from Timmy's is as Canadian as apple pie is American. RIP to them both. Edit. I will try to keep the thread title updated with the name of the most recent loss(es).

No logs => No support. If you can not find the time to provide the info I need to diagnose your problem do not expect I will find the time to reply to your post. (The thread was lost after an incident on the forum. The really old thread from even before is here) Anatid Robotics and Multiversal Mechatronics proudly presents the first flight assistant autopilot: MechJeb I would like to thank CardBoardBoxProcessor and Keptin for their amazing MechJeb models. Sarbian is the current maintainer. Current version: 2.14.3 2.14.3 Localization fix fix related to radian vs degree New infoItems about the Target ( MeanAnomaly, TrueLongitude, LDN, TimeToAn, TimeToDN ) that nay be of use to Principia players More work on PVG 2.14.1 Fix a bug with infoItem in the editor 2.14.0 UI refactor of the Ascent Guidance Improved Principia node Execution Performance fix and optimization Stuff 2.12.0 Stuff. I am tired. 2.11.0 Landing AP fixes and improvements Plane landing AP fixes and improvements Rover AP fixes and improvements Updated Chinese loc 2.10.0 Compact UI now the default Spanish translation Russian translation Updated Chinese translation Principia node execution (WIP) Many PVG updates Plane Landing and autopilot improvements Stuff I missed in the commit logs Various fix and improvements 2.9.2 Localization support with included Simplified Chinese Localization Improved integrator and Brent's Method for maneuvers Fix the ApR and SMA maneuvers Support Multi-Node maneuvers Various fixes and code improvements Stuff I forgot 2.9.1 ReflectionTypeLoadException will now list the DLLs that are the actual source of the exception in the log. tinygrox on GithUb took on the huge work required to add localization to MJ. People who want to translate MJ should have a look at this file The DeltaV window now has buttons to hide the empty stages and switch between s and dhms for burn time 2.9.0 Built for KSP 1.8 Added "Land somewhere" and "Land target" KSP Action Improvements for remote vessel control Overhaul of bi-impulsive transfer planner Improvements for PVG ascent Porkchop plot can now be translated with WASD and arrow keys Unlock all MJ techs by creating a MechJebUnlocked folder in GameData And a bunch of fix. See here for details 2.8.4 Built for KSP 1.7 2.8.3 fix for launch-to-plane PVG stabilization fixes Fix xenon delta V 2.8.2 Primer Vector Guidance bring back simple coplanar transfer option make the hybrid controller the default controller Incorporate "MechJebAndEngineerForAll" style functionality adding ∆v display to flight recorder add steering/drag/gravity loss to flight recorder Add Apoapsis and Periapsis to scripting conditions Fixes 2.8.0 Replace Hohmann Transfer with Bi-Impulsive Transfers [ui_fix] no space after altitude meters label in ascent autopilot 2.7.4 Change the "Online Manual" link to the github wiki since the old site is gone Updated the landing sites list with the one from @El Sancho Improved the landing sim precision (aka "write code with both eyes opened") A bunch of small fixes 2.7.3 Fix the fuels sim in the editor with surface attached decouplers... 2.7.2 Fix for the engine plate autostagging Fix for the scripting module SAS controls Fix the MOI code to handle "control from here" properly. Should help with Docking 2.7.1 KSP 1.4.1 auto-deploy antennas Plane landing improvements Rover AP fix bugs fix 2.7.0 New launch profiles selection, including one that is the classic "KSP ascent", a "PEG" clone for RSS and the classic MJ profile Scripting module Update with new features (you ll have too look) New spaceplane landing AP A rework of the advanced transfer code A lot of FuelSim (dV) fix Better FAR integration A bunch of fix and UI improvement 2.6.1 Compatibility with KSP 1.3 Fix and improvement for the transfer calculator Specific orbital energy, potential energy, and kinetic energy Orbit Info items added Ascent AP improved circularization burn inclination error Ullage/RO improvement Remove a large recurrent allocation that froze the game every few seconds from some Flight recorder UI improvement and export Plenty of fixes Thanks to all contributors 2.6.0 Compatibility for KSP 1.2.2 Scripting module by @SPD13 Auto RCS Ullage for RO by Lamont (whose name here I forgot..) Option to move the menu on any side of the screen A bunch of fixes and minor features stuff I most likely forgot about 2.5.8 Compatibility for KSP 1.1.3 Add ‘At the highest AN/DN’ and ‘At the nearest AN/DN’ time selectors for inclination and plane maneuvers. Add a setting for the node executor lead time Custom Windows new Overlay mode MJ Pod disabled since it does not work properly with the current leg code FAR compatibility included lots of fix 2.5.7 1.1 Stuff More stuff 2.5.6 Launch Inclination improvement Improvement of the Landing Sim Predicted Trajectory overlay in the flight view (in Landing AP window) Ascent AP Fairings autodeploy with support for Procedural Fairings RSS Mode swtich in the settings windows. For now it prevents engine shutdown when disabling the ascent AP Greatly lowered memory garbage generated. May improve frame rate on some PC A lot of bug fix 2.5.5 Flight Recorder Graph module Education mode option (rename SmartASS to SmartACS) see MM patch here https://raw.githubusercontent.com/MuMech/MechJeb2/master/MechJebEdu.cfg Improvement to the Attitude control Dynamic Pressure limiter to replace the now useless terminal velocity Attitude control speed limiter to save some RCS Add "periapsis in target SoI" InfoItems Add "minimum DV required for capture by target" InfoItems Add "Docking guidance: Angular velocity" infoitem Add electric throttle limiter to avoid empty batteries on ion powered craft 2.5.6 1.1 release. Be aware that the Pod leg are not working and will generate fantom force Other stuff but I don't have time to write the change log atm Download 2.14.3.0 for KSP 1.12.x Download 2.12.3.0 for KSP 1.8 to 1.12 Download 2.12.0 for KSP 1.11.x Download 2.11.0 for KSP 1.10.x Download 2.9.2 for KSP 1.8.x and 1.9.x Download 2.8.4 for KSP 1.7.x Download 2.8.3 for KSP 1.6.x Download 2.7.4 for KSP 1.4.1 Download 2.7.0 for KSP 1.3 Download 2.6.0 or Dev #698 for KSP 1.2.2 Source code available here. LGPL3 license for MechJeb code. MIT for SmoothFoundations & UnityToolbag You can also get the latest dev builds here. Usage instructions: Use the button on the right side of the screen to access MechJeb window selection interface, and click on the buttons to activate the windows. The windows can be dragged anywhere on screen, and their position is saved and reused among all rockets. Manual Useful links and companions mods Manual MechJeb for All or MechJeb Embedded Universal to add MechJeb to all the probe and command module and use it without the parts. Also allow to unlock all MechJeb features from the start in career mode Small MechJeb touchscreen case an alternative model for the part An other model A video from speedio explaining the basic operations you can do with it (outdated but still useful): Another video, this one by tncm for AR202, but still very useful: Adding "eduMode = true" to the module will rename the SmartASS to SmartACS. You can use this Module Manager patch to do it. How to Install Manual install : unzip the zip in KSP GameData directory. You should have something that looks like that : KSP GameData MechJeb2 Icons Parts Plugins CKAN has all the release of MechJeb. If you want the dev version of MechJeb then : open CKAN settings (Settings => CKAN Settings) press the New button select the MechJeb-dev line, click OK and exit the options. refresh select "Mechjeb2 - DEV RELEASE" in the list and then "Go to Change" to install Common problems The MechJeb menu is not showing. First make sure you have the part on your ship (AR202 case in the Control section). Some windows protection and anti-virus can sometimes block KSP from loading MechJeb. You should install KSP outside the C:\Program Files (x86) directory. Steam has an option to change the install directory of a game or you can just copy the directory somewhere else. Some function are not present in career. Some function require to unlock some specific node in the Research and Development tree. Some other also require to upgrade the tracking station to level 2 (Game code restriction we can't do much about) Bugs There is two version of MechJeb available The main version that we release once or twice per KSP version The dev version that gets a a couple or release per month, week or even days. It may also have more bugs than the main version since new features are added The dev release gets all the new features and bugs fix and the main version gets them when a new KSP version is released (or major bugs requires it). If you experience a bug the first thing I advise is to try the dev release. You can read the change log of the dev release here. If your bugs don't seems to be fixed then please open a new ticket on the project tracker. Don't forget to include a link to your log (see here to find it and how to share it) and the version of Mechjeb you where using (shown in MechJeb Menu). Please send Suggestions/Bug reports here: https://github.com/MuMech/MechJeb2/issues

Unusual depends on what the currently ongoing situation really is. It's not at all unusual if you assume the worst. Whether one bases this on a bunch of EA games or game devs that go out with a whimper with people guessing they're dead because the website etc. has not seen a single update in ages, or on the typical hiding head in the sand until the problem goes away (media buzz dies down) this is rather typical in such scenarios. It is unusual only if there are concrete plans to continue development. The absolute best case scenario would be that PD is still fishing for or in negotiations with another studio to "handle" (which might not necessarily mean "finish the roadmap") the game and they don't want to say anything without being certain (having a contract). But honestly if that was the case PD would outright clarify the situation since there is PR fallout from it. The only reason why one would not bother to minimize PR fallout is if there is even worse PR fallout on the horizon. It's possible T2 is waiting until after the annual report goes public on the 16th of May so that it overshadows any other news related to them for one reason or another lessening the impact of the news (either because the figures are good, so why complain or they're so bad that IG getting closed is not the same order of bad new magnitude). I already mentioned earlier ITT that the timing of the job cuts rumors mentioned in the first post of this topic is not coincidental. The leak might have been deliberate to pre-emptively soften the impact of what is in the annual figures, after all why do job cuts if figures are great? FYI their Q3 earnings release indicated a 842 million USD net loss for the 3 quarters. Projections for Q4 also have a loss with the lower (worst case) bound being slightly over a billion year to date, now the market is aware of that, they have been given explanations which are no doubt somewhere in the transcript. Most of this seems to be from impairment on on some intangible assets (IPs, brand value, goodwill etc. of something they overpaid for like another studio possibly, need to check) that clearly had way more value initially posted into the books than in reality and needed a correction. Page 15 and 16 of the below is where I got this from: https://ir.take2games.com/static-files/2f8bd105-3bb8-4f05-97a2-36749e251a27 In any case if they say nothing next week I'm quite certain there will be radio silence until they publish their annual report on the 16th IIRC.

KSP Community Fixes This plugin is a collection of code patches for fixing bugs and performance issues in the KSP codebase, and adding small QoL improvements. Entirely new features (especially those already covered by other mods) are out of scope, as well as patches that might alter the stock behaviors to minimize potential mod compatibility issues. This mod is meant as community project, so feel free to propose additional patch ideas by opening an issue, or to contribute with a pull request. Download and installation Compatible with KSP 1.8.0 to 1.12.5 - Available on CKAN Required and must be downloaded separately : HarmonyKSP : Download - Homepage - Available on CKAN ModuleManager : Download - Forum post - Available on CKAN Installation Go to the GitHub release page and download the file named KSPCommunityFixes_x.x.x.zip Open the downloaded *.zip archive Open the GameData folder of your KSP installation Delete any existing KSPCommunityFixes folder in your GameData folder Copy the KSPCommunityFixes folder found in the archive into your GameData folder Features Individual patches can be enabled or disabled by editing the Settings.cfg file. To make sure your changes persist when the mod is updated, it is recommended to make them in a ModuleManager patch. Open the Extras\KSPCF_UserSettings.cfg.extra file in a text editor for further instructions. While all KSP versions from 1.8.0 to 1.12.5 are supported, using the latest one (1.12.5) is highly recommended, as many patches only apply to the most recent KSP versions. When a bug fix patch doesn't apply to an older KSP version, this doesn't mean those bugs don't exist there. User options are available from the "ESC" in-game settings menu : Major bugfixes RefundingOnRecovery [KSP 1.11.0 - 1.12.5] Vessel recovery funds properly account for modules implementing IPartCostModifier. This bug affect stock fairings, cargo parts and many modules from various mods (part switchers and procedural parts mods, USI, Kerbalism, Tweakscale, etc). KerbalInventoryPersistence [KSP 1.12.2 - 1.12.5] Fix the whole kerbal inventory persistence system being inactive in KSP 1.12.2+. This cause multiple issues, like being able to bypass kerbal inventories mass/volume limits, and various cargo part duplication / disappearance issues when EVAing / boarding. RoboticsDrift [KSP 1.12.0 - 1.12.5] Prevent unrecoverable part position drift of Breaking Grounds DLC robotic parts and their children parts. DockingPortRotationDriftAndFixes [KSP 1.12.5] Make the stock docking port rotation feature actually useable : Completely prevent unrecoverable position drift of children parts of docking ports. Fix joint failure and phantom forces when a docking port pair is set to opposite extreme angles. Allow tweaking the rotation in the editor and while not docked in flight. Rotation can now be properly used in a robotic controller. Remove the -86°/86° hardcoded limitation of hardMinMaxLimits, it is now -180°/180°. Fix many issues and state inconsistencies. An optional DockingPortExtendedRotation.cfg.extra MM patch extending rotation range to 360° is available in the Extras folder. Copy it to your GameData folder and remove the .extra extension to use it. AutoStrutDrift [KSP 1.8.0 - 1.12.5] Improves the overall physics stability when using autostruts and prevent autostrut induced deformations following vessel modification events (decoupling, docking/undocking, fairing separation...). ModuleIndexingMismatch [KSP 1.8.0 - 1.12.5] Prevent modules persisted state from being lost in existing saves/ships following a mod installation/uninstallation/update. Note that this won't handle all cases, but it massively reduce occurrences of that issue. PackedPartsRotation [KSP 1.8.0 - 1.12.5] Fix part rotations not being reset to their pristine value when a non-landed vessel is packed, resulting in permanent part rotation drift when docking and other minor/cosmetic issues. PartStartStability [KSP 1.8.0 - 1.12.5] Fix vessel deformation and kraken events on flight scene load, also prevent some kraken issues when placing parts with EVA construction. Minor bugfixes PAWGroupMemory [KSP 1.8.0 - 1.12.5] Fix the expanded/retracted state of Part Action Window groups being reset when the PAW is closed or internally rebuilt (especially frequent in the editor). PAWItemsOrder [KSP 1.8.0 - 1.12.5] Fix PAW items position randomly changing and flickering. KerbalTooltipMaxSustainedG [KSP 1.8.0 - 1.12.5] Fix the kerbals tooltip giving wrong "Max sustainable G" information. ROCValidationOOR [KSP 1.8.0 - 1.12.5] Fix ROCManager crashing during loading with Kopernicus modified systems. ReactionWheelsPotentialTorque [KSP 1.8.0 - 1.12.5] Fix reaction wheels reporting incorrect available torque when "Wheel Authority" is set below 100%. Fix stock SAS (and possibly other attitude controllers) instability issues. StockAlarmCustomFormatterDate [KSP 1.12.0 - 1.12.5] Make the stock alarm respect the day/year length defined by mods like Kronometer. Fix the underlying AppUIMemberDateTime UI widget API to use the mod-provided IDateTimeFormatter if present. StockAlarmDescPreserveLineBreak [KSP 1.12.0 - 1.12.5] Stock alarm preserve line breaks (and tabs) in the description field. ExtendedDeployableParts [KSP 1.12.0 - 1.12.5] Fix deployable parts (antennas, solar panels, radiators...) always starting in the extended state when the model isn't exported in the retracted state. This bug affect parts from various mods (ex : Ven's stock revamp solar panels). DeltaVHideWhenDisabled [KSP 1.12.0 - 1.12.5] Hide the stock stage delta-v UI elements and navball extended burn info when DELTAV_CALCULATIONS_ENABLED and DELTAV_APP_ENABLED are disabled by another mod or in the KSP settings.cfg file. AsteroidSpawnerUniqueFlightId [KSP 1.8.0 - 1.12.5] Fix the asteroid/comet spawner generating non-unique Part.flightId identifiers. This has a few minor side effects in stock (mainly incorrect science bonuses), but this field is heavily relied upon by various mods and this can cause major issues for them. PartListTooltipIconSpin [KSP 1.8.0 - 1.12.5] Fix editor tooltip part icons not spinning anymore after hovering on a greyed out surface attachable only part while the editor is empty. ScatterDistribution [KSP 1.8.0 - 1.12.5] Fix incorrect terrain scatter distribution when a partial longitude range is defined in the PQSLandControl definition. LostSoundAfterSceneSwitch [KSP 1.12.0 - 1.12.5] Fix audio source not being centered/aligned with the current vessel after scene switches, causing loss of vessel effects audio and random volume or left/right channel weirdness. EVAKerbalRecovery [KSP 1.11.0 - 1.12.5] Fix recovery of EVAing kerbals either causing their inventory to be recovered twice or the science data they carry not being recovered, depending on the EVA kerbal variant/suit. StickySplashedFixer [KSP 1.8.0 - 1.12.5] Fix vessel never leaving the splashed state if it starts out splashed, and decouples from its only splashed parts. This also fixes an issue where Splashed overrides Prelaunch as a situation. RescaledRoboticParts [KSP 1.8.0 - 1.12.5] Fix rescaled robotics parts propagating their scale to childrens after actuating the servo in the editor EnginePlateAirstreamShieldedTopPart [KSP 1.11.0 - 1.12.5] Fix engine plates causing the part attached above them to be incorrectly shielded from airstream. AsteroidInfiniteMining [KSP 1.10.0 - 1.12.5] Fix asteroid/comet mass being restored to 100% when reloading after having mined it down to 0%. CometMiningNotRemovingMass [KSP 1.12.2 - 1.12.5] Fix mass of comets not actually reducing when mining them, despite the PAW saying so. DoubleCurvePreserveTangents [KSP 1.8.0 - 1.12.5] Fix DoubleCurve flattening the tangents of the first keyframe regardless of whether tangents are supplied. StrategyDuration [KSP 1.8.0 - 1.12.5] Fix Strategies not using Duration settings. UpgradeBugs [KSP 1.12.0 - 1.12.5] Fix various bugs with upgrades, like the part stats upgrade module breaking, upgrades not properly applying in the editor, upgrade cost not being applied to part cost, and various issues int the public API. MapSOCorrectWrapping [KSP 1.10.0 - 1.12.5] Fixes issues with biomes crossing the poles (South pole biome at north pole and vice versa). Fixes "polar spikes" in the terrain for 8-bit heightmaps. ChutePhantomSymmetry [KSP 1.10.0 - 1.12.5] Fix spread angle still being applied after decoupling symmetry-placed parachutes. CorrectDragForFlags [KSP 1.12.3 - 1.12.5] Fix the "panel" variants of the flag parts using a single drag cube, causing excessive drag for the smaller options. LadderToggleableLight [KSP 1.8.0 - 1.12.5] Fix for the stock "Kelus-LV Bay Mobility Enhancer" light being always active even when the ladder is retracted, and implements manual control of the light. ReRootPreserveSurfaceAttach [KSP 1.8.0 - 1.12.5] Disable the stock behavior of altering surface attachment nodes on re-rooting, a questionable QoL feature that doesn't work correctly, leading to permanently borked attachement nodes. ThumbnailSpotlight [KSP 1.12.0 - 1.12.5], fix rogue spotlight staying in the scene when a part thumbnail fails to be generated. FixGetUnivseralTime [KSP 1.8.0 - 1.12.5] Fix Planetarium.GetUniversalTime returning bad values in the editor. DockingPortConserveMomentum [KSP 1.12.3 - 1.12.5] Make docking ports conserve momentum by averaging the acquire force between the two ports. Notably, docking port Kraken drives will no longer work. PropellantFlowDescription [KSP 1.8.0 - KSP 1.12.5] Fix printing the resource's base flow mode instead of the (potentially overridden) propellant's flow mode when printing propellants in an engine's info panel in the Part Tooltip. ModuleAnimateGenericCrewModSpawnIVA [KSP 1.8.0 - 1.12.5] Fix IVA & crew portrait not spawning/despawning when ModuleAnimateGeneric is used to change the part crew capacity. Notably affect the stock inflatable airlock. TimeWarpOrbitShift [KSP 1.8.0 - 1.12.5] Fix active vessel orbit moving randomly when engaging timewarp while under heavy CPU load. Quality of Life tweaks PAWCollapsedInventories [KSP 1.11.0 - 1.12.5] Part Action Window inventory UI widgets in a collapsed group by default, group title show volume and mass usage. Applied to part and kerbal inventories. AltimeterHorizontalPosition [KSP 1.8.0 - 1.12.5] Altimeter widget horizontal position is now tweakable in the pause menu settings. PAWStockGroups [KSP 1.10.1 - 1.12.5] Part Action Window groups for a selection of stock items/modules TweakableWheelsAutostrut [KSP 1.8.0 - 1.12.5] Allow tweaking the autostrut mode of wheels/landing legs. Still default to "Heaviest part". AutostrutActions [KSP 1.8.0 - 1.12.5] Allow autostrut mode to be toggled with action groups (requires advanced tweakables to be enabled). UIFloatEditNumericInput [KSP 1.8.0 - 1.12.5] Allow numeric input ("#" button) in "float edit" PAW items DisableManeuverTool [KSP 1.12.0 - 1.12.5] Allow disabling the KSP 1.12 maneuver planner tool in the KSPCF in-game settings menu. It can cause stutter and freezes on scene load, when changing SOI or when editing maneuver nodes, especially with Kopernicus modified systems. FairingMouseOverPersistence [KSP 1.10.0 - 1.12.5] Make the "Fairing Expansion" state persistent when reloading a craft in the editor. HidePartUpgradeExtendedInfo [KSP 1.8.0 - 1.12.5] Hides irrelevant extended info on the part tooltip for PartUpgrades in the RnD screen. AutoSavedCraftNameAtLaunch [KSP 1.8.0 - 1.12.5] Append [Auto-Saved Ship] when relevant in the Launchpad / Runway UI. ShowContractFinishDates [KSP 1.12.0 - 1.12.5] For archived contracts, show accepted/finished dates. NoIVA [KSP 1.8.0 - 1.12.5] Allow to disable IVA functionality and prevent related assets from being loaded, reducing RAM/VRAM usage and slightly increasing performance in some cases. Has a "use placeholder IVA" option allowing to keep crew portraits. This patch is disabled by default and must be enabled from the KSP "ESC" settings menu. It has no entry in the Settings.cfg file and require a restart to take effect. Do not use this option alongside IVA mods like RPM or MAS. DisableNewGameIntro [KSP 1.8.0 - 1.12.5] Disable the "intro" popups appearing in the space center, VAB/SPH and tracking station upon creating a new career game. Disabled by default. ToolbarShowHide [KSP 1.8.0 - 1.12.5] Add a button for hiding/showing the stock toolbar. Also allow accessing the toolbar while in the space center facilities windows (mission control, admin building, R&D...). ResourceLockActions [KSP 1.8.0 - 1.12.5] Add part actions for locking/unlocking resources flow state. Performance tweaks SceneLoadSpeedBoost [KSP 1.8.0 - 1.12.5] Reduce scene switches loading time with large/modded saves by caching the current save in memory instead of loading it from disk. OnDemandPartBuoyancy [KSP 1.8.0 - 1.12.5] Prevent the part buoyancy integrator from running when not needed. Improves performance for large part count vessels while in the SOI of a body that has an ocean (Kerbin, Eve, Laythe...) FastLoader [KSP 1.12.3 - 1.12.5] Complete rewrite of the KSP asset/part loader : prevent GPU framerate limits from affecting loading speed, implement multithreaded asset loading (20% to 40% speedup depending on CPU & storage specs), provides an opt-in mechanism for caching PNG textures in the DXT5 format. PQSUpdateNoMemoryAlloc [KSP 1.11.0 - 1.12.5] Prevent huge memory allocations and resulting occasional stutter on PQS creation happening when moving around near a body surface. PQSCoroutineLeak [KSP 1.8.0 - 1.12.5] Prevent KSP from spawning multiple PQS update coroutines for the same PQS after scene switches and on other occasions, causing large performance degradation over time. MemoryLeaks [KSP 1.12.0 - 1.12.5] Fix a bunch of managed memory leaks, mainly by proactively removing GameEvents delegates originating from destroyed UnityEngine.Object instances on scene switches. Will log detected leaks and memory usage. Also seeSettings.cfg to enable advanced logging options that can be useful to hunt down memory leaks in mods. ProgressTrackingSpeedBoost [KSP 1.12.0 - 1.12.5] Remove unused ProgressTracking update handlers. Provides a very noticeable performance uplift in career games having a large amount of celestial bodies and/or vessels. DisableMapUpdateInFlight [KSP 1.8.0 - 1.12.5] Disable the update of orbit lines and markers in flight when the map view isn't shown. Provides decent performance gains in games having a large amount of celestial bodies and/or vessels. CommNetThrottling [KSP 1.12.0 - 1.12.5] Disabled by default, you can enable it with a MM patch. Prevent full CommNet network updates from happening every frame, but instead to happen at a regular real-world time interval of 5 seconds while in flight. Enabling this can provide a decent performance uplift in games having an large amount of celestial bodies and/or vessels, but has a detrimental impact on the precision of the simulation and can potentially cause issues with mods relying on the stock behavior. AsteroidAndCometDrillCache [KSP 1.12.5] Reduce constant overhead of ModuleAsteroidDrill and ModuleCometDrill by using the cached asteroid/comet part lookup results from ModuleResourceHarvester. Improves performance with large part count vessels having at least one drill part. FewerSaves [KSP 1.8.0 - KSP 1.12.5] Disables saving on exiting Space Center minor buildings (Mission Control etc) and when deleting vessels in Tracking Station. Disabled by default. ConfigNodePerf see also [KSP 1.8.0 - KSP 1.12.5] Speeds up many ConfigNode methods, especially reading and writing ConfigNodes. RestoreMaxPhysicsDT [KSP 1.8.0 - 1.12.5] When using physics warp, Unity will set the max physics dt to be at least as high as the scaled physics dt. But KSP will never restore it back to the normal value from the settings. This can degrade performance as it allows more FixedUpdates to run per frame. ContractProgressEnumCache [KSP 1.8.0 - 1.12.5] Prevent performance drops when there are in-progress comet sample or rover construction contracts DragCubeGeneration [KSP 1.12.0 - 1.12.5] Faster and more reliable implementation of drag cube generation. Improves overall loading times (both game load and scene/vessel/ship load times), prevent occasional lag spikes (in the editor mostly) and fix some issues causing incorrect drag cubes to be generated (notable examples are the stock inflatable heat shield, the 1.25m and 2.5m nose cones and the Mainsail shroud). Note that by design, this patch results in a small deviation from the stock behavior for buyoancy, aerodynamics and thermodynamics, as the generated drag cubes will be slightly different. LocalizerPerf [KSP 1.8.0 - 1.12.5] Faster and minimal-allocation replacements for the Localizer.Format() methods, can provide significant speedup for GUI-heavy mods using localized strings. DisableHiddenPortraits [KSP 1.8.0 - 1.12.5] Prevent non-visible crew portraits from being rendered after a switch back from the map view (and other cases), causing a significant perf hit when there are many kerbals in the vessel. IMGUIOptimization [KSP 1.8.0 - 1.12.5] Eliminate structural GC allocations and reduce performance overhead of OnGUI() methods. Can provide significant performance gains when having many mods using IMGUI heavily. API and modding tools MultipleModuleInPartAPI [KSP 1.8.0 - 1.12.5] This API allow other plugins to implement PartModules that can exist in multiple occurrence in a single part and won't suffer "module indexing mismatch" persistent data losses following part configuration changes. See documentation on the wiki. DockingPortLockedEvents [KSP 1.12.2 - 1.12.5] Disabled by default, you can enable it with a MM patch. Fire GameEvents onRoboticPartLockChanging/onRoboticPartLockChanged respectively before/after calls to ModuleDockingNode.ModifyLocked(), following a modification of the ModuleDockingNode.nodeIsLocked field. OnSymmetryFieldChanged [KSP 1.8.0 - 1.12.5] Disabled by default, you can enable it with a MM patch. Change the UI_Control.onSymmetryFieldChanged callback to behave identically to the UI_Control.onFieldChanged callback : The callback will only be called when the field value has actually been modified. The "object" argument will contain the previous field value (instead of the new value). PersistentIConfigNode [KSP 1.8.0 - 1.12.5] Implement IConfigNode members marked as [Persistent] serialization support when using the CreateObjectFromConfig(), LoadObjectFromConfig() and CreateConfigFromObject() methods. Also implements Guid serialization support for those methods. Includes a complete rewrite of underlying ConfigNode code (in line with ConfigNodePerf) for performance, lower GC impact, and to fix some stock bugs. ReflectionTypeLoadExceptionHandler [KSP 1.8.0 - 1.12.5] Patch the BCL Assembly.GetTypes() method to always handle (gracefully) an eventual ReflectionTypeLoadException. Since having an assembly failing to load is a quite common scenario, this ensure such a situation won't cause issues with other plugins. Those exceptions are logged (but not re-thrown), and detailed information about offending plugins is shown on screen during loading so users are aware there is an issue with their install. This patch is always enabled and has no entry in Settings.cfg. DepartmentHeadImage [KSP 1.8.0 - 1.12.5] Fix administration building custom departement head image not being used when added by a mod. ModUpgradePipeline [KSP 1.8.0 - 1.12.5] This will save mod versions in sfs and craft files, and use those versions for mods' SaveUpgradePipeline scripts so that mods can handle their own upgrade versioning using native KSP tools instead of having to always run their upgrade scripts. BetterDDSSupport [KSP 1.12.3 - 1.12.5] Implement compatibility with the DXT10/DXGI specification, and support of loading additional texture formats : BC4 : single channel (R) compressed 4 bpp BC5 : 2 channels (RG) compressed 8 bpp BC6H : 3 channels (RGB) compressed 8 bpp with HDR color range (Not available on MacOS) BC7 : 4 channels (RGBA) compressed 8 bpp (Not available on MacOS) R16G16B16A16 : 4 channels (RGBA) uncompressed 64 bpp R16_FLOAT / R32_FLOAT : single channel (R) uncompressed 16/32 bpp R16G16_FLOAT / R32G32_FLOAT : 2 channels (RG) uncompressed 32/64 bpp R16G16B16A16_FLOAT / R32G32B32A32_FLOAT : 4 channels (RGBA) uncompressed 64/128 bpp Stock configs tweaks ManufacturerFixes Fix a bunch of stock parts not having manufacturers, add icons for the stock "Stratus Corporation" and "LightYear Tire Company" and two new agents, "FreeFall Parachutes" and "Clamp-O-Tron". LandingGearLights Fix the lights on the "LY-10" and "LY-35" landing gears not automatically turning on/off when extending/retracting the landing gear. License MIT Localization This mod supports localization. If you wish to contribute a localization file, you can have the mod generate or update a language template by editing the Settings.cfg (see instructions near the end of the file). Changelog

Operations don't run on loss. They run on expectations of profit, so it's an investment. On the exact moment someone decide that operation is running on loss, someone else calculates the odds of reverting the trend and how much time it will tale to recover the money after the profits are back. If such money can render more profits somewhere else, the axe-man is called.

Evyad, 29 Erbol 1971, all times UTC attempted launch of Space Geographer 1 (CAI name: SPY GLASS Mark 1 Flight Alpha, just a straight-up irl KH-1 Corona because I lack imagination). Launch "scrubbed due to loss of pressure in combustion chamber resulting in flameout", according to the Central Agency for Intelligence. Rolled back to VAB, investigation pending. 09:56 - SPY GLASS 1 rolled out to pad. Resuming countdown. 11:27:35 - RL79 ignition 11:27:44 - Contained failure of turbopump, small explosion on flameout. Rolling back for replacement and inspection of engine section. Publicly released imagery of the vehicle on the pad, from a WDR some days ago

From a business POV this kind of situation of having a loss-making division is not as clear cut as you think it is. I've seen multiple restructuring attempts of loss-making divisions or plants, firing everyone is a last resort, usually you try to salvage as much as possible, cut fixed costs (including cutting admin/support jobs), centralize/consolidate/move staff around, reduce shifts, shutdown one production line etc. Severance packages cost money, hiring new people costs money, preparing layoffs costs money, union negotiations cost money etc. so it must all be worth the end result and the alternative cost. As for how this connects to the topic at hand, well T2 says "support" will continue (YMMV on what they mean by this or how much you can trust PR as such), so we have an odd case where they supposedly are not axing the project but feel no need to keep the production staff around, which is odd to say the least. I would expect retaining an engineering handover team if this is a switch of studios responsible is happening at a minimum (well unless they want to start over, which normally is what happens, here it is hard to say, again PR is vague), but even that doesn't guarantee better results than merely keeping IG around with new management. AFAIK studios versed in making orbital mechanics games with the KSP2 roadmap feature set are not exactly growing on trees... This is before going on a long tangent about how much value added a CEO actually provides as compared to his salary, and how good are prospects of a company that sells the output of "knowledge workers" skilled labor rather than one of production machinery, if one just fires all the staff with their know-how. Or one about how much actual business need there really is to lower costs in the company and how much is purely artificial based on bonus targets the CEO has, because big investors want to squeeze their lemons dry. Or one about how good of a manager the mentioned CEO is. Or the social responsibility impact of his salary cut vs people losing jobs etc.

That’s what I meant, poor performance leads to money loss, so it’s what raises your chances to get you fired.

Didn't the original game have multiple CommNet ground stations placed around Kerbin to prevent this? Correct me if I'm wrong, I'd have to open up the game to check, but I remember seeing 'relayed through Island Station' or something. Yeah, but this game has been in development 6+ years now. If CommNet hasn't been implemented properly yet, is it likely to ever be? Things like CommNet being missing seriously makes me wonder what they were doing for all that time. If you are correct and that doing calculations for all Active Craft hampers things, I'm worried that they're being seriously handicapped by their decision to simulate all active vessels. Instead of calculating the area, couldn't this be done more efficiently by just using a cosine equation? Get the vector from current position to the Mun or occluding body, get the vector from current position from to light source (Kerbol) or CommNet relay, and compare the two vectors with a cosine (past a threshold of close to 1.0 or -1.0, I forget which) to see if they're intersecting. The distance to each object is also known, which tells which body is occluding which, and also the radius of the planetary body will be known, which along with the distance allows the area or field of view to be calculated - a Solid Angle measured in steradians. This value along with the cosine value can be used to attenuate the light intensity (or block a signal). This calculation has the advantage of being more lightweight and therefore be run on multiple planetary bodies and vessels. I wouldn't be surprised if CommNet from the original game used some kind of similar calculation.

I think Take-Two is definitely being silent due to the near date for that earnings call. That may be the first time we hear anything new. Although it may be very low-content corporate-speak. I really don't know about Take-Two backing a restart of KSP 2. And any independent studio entering into a contract with Take-Two to do so better read and negotiate very very carefully. I am almost certain that Take-Two will never sell KSP, even if KSP 2 is shut down. That bears the grave risk of someone doing a better job with KSP than Take-Two's minions did, making Take-Two and its execs look incompetent. If they figure there's no future, they will take the loss and wind things down, one way or another.

"Still working" might very well just mean "We'll make sure that the Steam page remains up, that there is an account to receive any future income from sales, and that somebody is around to sue in case a competitor tries to market a Kerbal Weight Loss Program after we are gone."

The work was originally started by russnash37 who gave a permission to take over and extend his project Supported KSP version: 1.2.2, 1.3.0 License: GNU GPLv3 (included) Source code: on GitHub I've tried to make focus on realism as much as I was able to research the subject so the default settings assume that all kerbals including tourists are trained astronauts wearing G-suits. Pilots are more trained than others, of course. The following G-effects are simulated: Blackouts/redouts Loss of color vision a.k.a "greyout" Tunnel vision as G rises Kerbals grunt while they perform AGSM (anti-G straining maneuver) and take a heavy breath after Blood beating in kerbal's ears on redout (wear headphones with good bass and you'll feel it) G-LOC (G-induced loss of consciousness) Kerbal deaths of a sustained over-G G forces have different severity in four directions: upward, downward, backward, forward, so you may find that a kerbal launched in a rocket stands more G than a kerbal piloting a plane upside down on a circular trajectory. Kerbal's specialization also affects how much he can stand. You can use this mod together with KeepFit by timmers_uk. In this case kerbals' fitness will affect their ability to withstand over G effects (supported by G-Effects v0.2.3+ and KeepFit v0.8.3.3+). Download from SpaceDock (for KSP 1.3.0) Download from SpaceDock (for KSP 1.2.2) If you don't have a joystick it is recommended to use with Analog Control Continued mod for the best aircraft experience Installation: Save the old G-Effects.cfg file if you have changed it. Delete previous version of the mod. Place contents of the zip into your KSP/GameData folder. You'll have to enter the config params you have saved manually into the new version's configuration file because it has several important changes. Stock integration: Stock g-meters and notifications correspond to the mod's state. If you don't need them you may disable "Kerbal G limits" in the game's settings, the main mod's behaviour won't be affected. Kerbal experience and other stock g stats are still ignored. Configuration: Configuration of the mod is done via G-Effects.cfg file. Look through it to have an exhaustive description of its parameters. The major parameters of those you can fine tune are: A common kerbal's ability to resist G effects Restrict video and audio effects to IVA mode only Severity of effects of G forces applied from different directions How much specialization help a kerbal to resist an over-G Disable G-deaths and more The sounds are still a little WIP so you always have an option to disable them via config file if you find'em too annoying. Anyway, after trying the mod please respond to the poll in this thread for I knew which way to move further. Would also appreciate any comments or suggestions. Known issues and limitations: G-forces caused by a ship's rotation don't affect because they are not likely to be severe enough to induce any significant effects. Effects are calculated for the active vessel's crew only. You can switch to another vessel and back and have effects applied as if they have just started. Planned features:

Consider a spacecraft cooling system. It moves heat from inside the spacecraft to the radiators, and due to the Second Law, you end up with more heat in the radiators than you removed. Sounds like a net loss, right? Except having hot radiators is actually good, because then the heat radiates out into the rest of the universe. That seems to be the idea the OP is going for, except the issue is that it would be as if your radiators were covered by insulating blankets. In that case all you would be doing is getting the radiators hot to no good effect. (The atmosphere is the insulating blanket.)

That move screams to me "loss recovery," aka damage control. T2 had spent years worth of development and had nothing significant to show for it, so they ordered the tech-demo released "early access" to recoup some money before shelving the failure and moving on to the next IP.

Just saw this video and I think this guy really nails it, especially when he talks about the "business side" and why development may have gone so wrong. I feel like so many of the things I and several others were complaining about at the start were vindicated, and it's really dissapointing. I would rather have been wrong. I guess you could call this my "defeat lap". https://forum.kerbalspaceprogram.com/topic/217217-what-happened-to-the-reworked-core-systems/ This thread, from May of last year, talks about the startling lack of substantive gameplay improvements, compared to the stylistic upgrades. This is addressed in the video towards the end. https://forum.kerbalspaceprogram.com/topic/212504-fps-isnt-the-issue-interested-in-discussion/ This thread, from February just after the release, is about how there are much worse issues with the EA build than bad performance, which speak to core aspects of the game and bode poorly for the game's future. Even back then, I speculated " I can think of two scenarios, which dictate two different actions: 1) T2 is looking for high EA sales to justify continue funding the project. In this case, we should NOT refund the game, and try to give the dev team the benefit of the doubt that they haven't lost faith in the project. 2) T2 is looking to cut KSP 2 loose after finding themselves many years, and millions of dollars deeper into KSP 2 than they ever thought they would have to be, and with a product that is still sub-par and far from finished, and high EA sales will allow them to justify doing this. In this case, we ought to REFUND the game in order to force T2 to fund the dev team and finish the game, or accept a massive loss, likely at least on the order of tens, to even a couple hundred million dollars (reasonable estimate for what the game has cost them so far, including marketing, etc.). " https://forum.kerbalspaceprogram.com/topic/212173-reading-into-ksp-2-ea-featuresnon-features/ This post, from before the EA released, speculated that the most likely reason for the impending sorry state of the game was that T2 forced them to release into EA early because they were considering pulling the plug. Finally, this post: https://forum.kerbalspaceprogram.com/topic/217291-actual-quotes-for-substantiated-arguments-thread/ This thread contains discussion about actual statements made by Nate Simpson and others, which, at the time (May 2023) had been shown to be false, misleading, or otherwise concerning with regards to the prospects of the games development. I think, judging by https://steamdb.info/app/954850/charts/ , the consumers have decided it was not the right price. Of course, the irony is, while they likely set the price of the game at $50 to show big daddy T2 a proof-of-market revenue stream, the pricepoint, in conjunction with the poor quality of the game, lousy communication, etc. may have been one of the most significant contributing factors to the game's financial underperformance. Devs: If I'm wrong, prove it! I would love to get dunked on in a post saying the game isn't cancelled, and colonies is coming soon.

Parallax Development Update It's been a while since I've posted progress on my projects, so this is quite a meaty one! What am I working on? Over the last few months, I've been rewriting the entire mod from scratch including the shaders and architecture with the goal of massively improving performance, memory usage and eliminating annoying bugs. I've been successful so far with all of these to the point where I feel like I can share my progress. I can't provide any detailed analysis just yet as the mod is still evolving, but here are some of the key changes that are coming. Performance - Terrain Shader Performance is key with Parallax. Its original goal was to provide a terrain shader that was more flexible than and outperformed the stock shader. On some systems this is true, but we can do better than that! With the upcoming rewrite, both tessellation performance and texture performance are hugely improved. Not only does the current public version of Parallax use too much GPU bandwidth (something the KSP 2 terrain shader is notoriously terrible for), but it also does far too much in the wrong shader stages which worsens performance, more so on systems running OpenGL because of its awful vertex performance. Expect some major improvements to the terrain shader which will free up performance for things that matter more! Not only that, but the CPU usage for functions that support the terrain shader have already been massively optimized. Because KSP is so dated, its terrain is not detailed enough to support tessellation at a high enough density that looks good. I've written two mesh subdivision methods over the years to try and counter this, but they have been limited. None of the previous methods have satisfied all of these requirements: Gapless mesh (no T junctions) Fast / efficient High mesh detail Multithreaded But now after a month of two of experimenting, I've written a multithreaded subdivision scheme using the Unity Jobs system which achieves all four of these requirements. It's also entirely asynchronous which means aside from rendering the mesh at higher detail, there's zero performance loss from the subdivision itself! And it runs in realtime. Here's a gif: Note that the framerate of this video is low because it's a gif. Here's the link to a video that shows this more smoothly: https://i.imgur.com/96HPeBE.mp4 Performance - Scatter System The scatter system is where most of my time is being spent right now, and there are already a number of optimizations and improvements on the way! Firstly, instead of doing everything in 'world space' coordinates (which is bad, really bad), the scatter data generation is now entirely in mesh-space. This means that the days of the scatters becoming disconnected from the ground are gone! I've also managed to significantly reduce the VRAM usage of the scatter system by changing how the scatters are applied, which now only apply to visible quads. With the previous implementation this wasn't possible and you were actually generating and storing scatter information for quads that weren't even visible, but thanks to Harmony and some guidance from @Gotmachine this isn't the case anymore. The scatter shaders themselves have also been rewritten from the ground up. These include a much more streamlined process without the baggage that the previous shaders had - and there was quite a bit, especially since a lot of calculations were done to get around working in world space coordinates all the time. There are further improvements to VRAM usage here by reducing the memory required for each individual scatter object by around 88%. Before, an object's position, rotation and scale were stored as a 4x4 matrix using 64 bytes. This is absolutely unacceptable but sadly a byproduct of using the wrong coordinate system - this has now been reduced to just 8 bytes to store a float3 position, a float rotation and an unsigned integer index (for some internal processing needed elsewhere for aligning objects with the terrain). Combined with the VRAM usage I mentioned earlier, this will be a major part in improving performance and supporting lower tier hardware! Quality Improvements With the changes coming to the terrain mesh subdivision, the quality of the terrain tessellation is much better. The current public Parallax version also has a mistake in the biplanar texturing coordinates used for sampling mipmaps which results in slightly blurrier textures. This has been fixed, so expect a noticeable quality bump in the textures themselves. I've also added (cheap) reflection support to the shader which will massively improve the colouration of the terrain on atmospheric bodies which will be more noticeable when Scatterer is not installed. On the scatter system side of things I've rewritten the procedural noise system and moved it from relying on the terrain system to generating it on the GPU. Not only is this much faster, but the improved implementation allows for much finer detail that isn't tied to the number of vertices in the terrain. This is big news for RSS players but applies to stock scales too. Check out the detail we can get now! Ignore the cubes - as you can see, things are still very WIP. You can see here there is this weird pixelation of the procedural noise - this is a result of precision errors given the scales we are working at but there is a very nifty workaround for this too. On the technical side, I pass the 'direction to the planet center' to the GPU and it generates the noise from these spherical directions. Since these can be stored CPU-side as doubles, we can define a minimum procedural noise 'frequency' (which is really how large or small the noise appears) and multiply it before the lossy conversion to floats on the GPU. This means we'll have a minimum frequency which we can most likely safely set to 100 (larger for larger planets) which will make these precision errors much, much less prevalent. So, long story short - the pixelation can be largely ignored here. Again, WIP! However this improvement to how the noise is generated (and the types of noise available) is huge for modders who right now are very limited in how scatter placement and dynamics can vary. There are 5 noise types that will be available on release and I'm considering adding more if they're required: There are most likely things that I've forgotten here, since there are seriously a whole bunch of improvements on the way! I'm looking forward to being able to share more in the future and excited to release it when it's ready. As for when it releases, I'm aiming for within a few months at most if all goes well - but there's a lot going on in my life at the moment, so I can't promise anything! o7

Who knows Surely not; possibly would sell it for more than they paid for it + (assuming) their net loss on the development thus far Probably not considering it is also the forum for KSP1 and that will still remain available for sale Yes, they bought the IP which includes KSP I don't believe this is a matter of being part of a pattern. I think this is solely due to the incompetence of the development team and consistently failing to deliver on milestones within any reasonable timeframe. Concurred. Very disappointing. Incompetence means lacking the competence to do something; or in another definition "lack of ability to do something successfully or as it should be done". I think it is clear that the development team lacked the ability to successfully deliver on the product as described/shown since the 2019 trailer.

'NADUT' MODULE - YEAR 4, DAY 65 MISSION OBJECTIVE: Dock the Nadut Module to Kerman Station LAUNCH VEHICLE: Reusable Booster System With the Celestial Lounge now in Orbit, it's time for the next planned expansion module to go up. This is the Nadut Module. Nadut is definitely one of the most interesting modules that Beyond has ever built, as it's the very first habitable inflatable module. This is experimental technology, so the module is very small, but this experiment could be important for future interplanetary missions for lightweight habitats and inflatable rings. Other then that, there's not much else to write home about with this module. Just a hab, not too indifferent. "Liftoff on the Nadut Module, on its way to Kerman Station!" - Gene Kerman (Flight Director) "Nadut orbital entry is established." - Gene Kerman "Copy, handing over control of the RBS to EDL teams." - Silverstein Kerman (BOOSTER) "We report loss of signal with the RBS. Dispatch recovery teams immediately." - Jill Kerman (Head of EDL) Unfortunately, the RBS was coming in just a little too fast, causing the parachutes to be shredded when they deployed. Almost all of the rocket was destroyed on impact, in a massive explosion felt by several towns nearby. Administrations senses a hefty lawsuit coming in their direction. Back in orbit, Nadut is guided to Kerman Station by its ground teams. A rendezvous burn is made with the tug stage, the tug burned to match velocities with Kerman Station, and then module was ejected from the tug to move in to dock at Kerman Station. One painful docking process later and... Nadut is docked to Kerman Station! It's a great new addition to the station-scape, and once it's inflated, the crew on board Kerman Station describe it as being quite roomy. However, Kerman Station does have one issue: it now has no airlock! However, the Hope habitat module does have a docking port on the side for a future airlock. So, work has begun on a new small airlock module. However, that's quite a few flights away. A little bit more housekeeping has to be done at Kerman Station, as well as some routine satellite flights, and then a new airlock will be launched. *** Hey, sorry it's been almost a month since the last update. I've just felt really uninspired to write or play KSP, and Cities: Skylines is a vortex. The roads call for me. That's my excuse for not writing this or CKR at all. Anyways, I'm back I suppose, so, more updates! Yay! Also, sorry this update is written so weird I legitimately got 0 sleep last night. My eyes burn right now.