eggrobin

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.

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.

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.

A major issue was found in the previously released build for 伊藤: creating a manœuvre while the plotting frame was X–Y–Orbit would cause a crash, see #3689. As a result, we have hotfixed the release; if you downloaded 伊藤 prior to this post, please click on the link in the OP or the GitHub readme to download it anew (the version string in the Principia UI should say 2023061805-伊藤-0-g2771ba5fa7f1d43341a5ca70adbd7f296449c300, not 2023061805-伊藤-0-gc3140c5f2bf7a8438e41cd5e3bcfcb2fd3f52356). We apologize for the inconvenience.

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.

A major issue was found in the previously released build for ابن الهيثم: switching to the target-centred frame would cause an immediate crash, see issue #3653. As a result, we have hotfixed the release; if you downloaded ابن الهيثم prior to this post, please click on the link in the OP or the GitHub readme to download it anew (the version string in the Principia UI should say 2023051916-ابن الهيثم-0-gd3ebe8f338fefbc96249e305fba493979fd67f32, not 2023051916-ابن الهيثم-0-g9f3105efa9ead54ad17567161fb59e5094829f7d). We apologize for the inconvenience.

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.

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.

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.

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.

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.

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.

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.

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.

For the new moon (lunation number 281), the new release (Ἵππασος) is out. Three bugs have been fixed. See the change log for more details

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.

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 or by apsis and 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 somewhat.  See the change log for more details.

That would eliminate the optimization problem. The other difficulties would remain, and overall things would get much worse. First, « rails » means an analytic solution, so it would mean bypassing the integrator, which programmatically would be a mess. But let’s set aside software engineering concerns for a second, what those rails do is an even bigger nightmare; keeping the Keplerian orbit unchanging is neither what you do nor what you want. For a perturbed Keplerian orbit around an extended body, you have various precessions; stationkeeping doesn’t cancel all of those, that would be completely impractical, ridiculously costly, and counterproductive for sun-synchronous orbits. Instead it preserves some properties of the orbit as it precesses (such as the alignment with respect to the ground, or sun-synchronicity, etc.). And then you have orbits that don’t even look like Keplerian orbits, such as things hovering about Lagrange points etc. And of course there are those software engineering concerns; mixing various types of propagation (analytic, likely with many kinds of analytic models, and numerical) would be a mess that we are not willing to contemplate. That eliminates the interaction with KSP, which admittedly is the boring and tedious part in addition to being difficult. But that leaves you with: which is probably the harder part (though the more interesting one). That aspect is actually not that bad, since we control orientation, including in timewarp. Right now we assume that vessels tumble inertly in timewarp, but obviously attitude-keeping is a thing. Attitude-keeping is a much more bounded problem than stationkeeping; it requires defining a handful of attitude control laws, but it does not involve optimization, and there are only so many attitude control laws that are interesting (point at the sun, put the hinge of the antenna in the plane containing the Earth, like Молния; point at the Earth, put the hinge of the solar panel in the plane containing the Sun, like satellites with hinged solar panels, etc.). I could imagine adding attitude keeping (though in order for that to be really useful, other mods, such as RealAntennas, should take the attitude into account); there is an open issue (#2556) about that. As usual, there is an appropriate xkcd; telling the trivial from the intractable takes deep familiarity with the problem. If you want to gain some familiarity with the subject, I strongly recommend this book if you want to learn more about orbits, how they are perturbed, how you either take advantage of that or avoid it, and more generally why you pick an orbit for a given mission (an English translation exists, titled Handbook of Satellite Orbits: From Kepler to GPS). The orbit analyser in Principia is inspired by that book; so is the career mode mod I’ve started working on, Σκοπός.

I should rewrite the first post someday; that section aged poorly :-) While atmospheric drag would likely take quite a bit of work in and of itself, the real difficulty would be that, as you point out, it would make things unplayable without stationkeeping to match. Stationkeeping is not happening in the foreseeable future; it would involve thrusting in timewarp (its own rabbit hole of messy interactions with KSP), optimization to figure out when to thrust (which is hard, though at least interesting), and figuring out how the player should specify what properties of the orbit are being kept (so something like the orbit analyser, but with input instead of being an already overwhelming read-only report). Solar radiation pressure is similar.

It looks like you did not correctly remove the planet pack.

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.

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.

This is a common question, which does not really have a good answer at this time. KerbalismContracts is now known as Σκοπος (and while some of it will depend on Kerbalism, not all of it will). The goal remains to have contracts based on mission goals, (e.g., provide transatlantic television), rather than a specific solution (e.g., put this many satellites in that orbit). Besides putting mission design in the player’s hands, which should be interesting, not having an assigned orbit would also neatly sidestep the problem of figuring out if you are in this orbit in the presence of perturbations. I am currently working on getting part of Σκοπος to some sort of prototype state usable for preliminary testing and getting basic information that could inform balance (but such a prototype would not itself be balanced, nor usable as a proper full-fledged career), so this is still in progress. Use the orbit analyser, set the mission duration to however long you need your orbiter to be around, and see if the analyser says collision or collision risk.

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.

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.