-
Posts
487 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
Everything posted by eggrobin
-
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 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.
-
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.
-
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.
-
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.
-
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.
-
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 腾讯微云.
-
A critical issue was found in Hamilton (#3226, the reference frame selector was broken unless the UI was set to English), so we have hotfixed the release; if you downloaded Hamilton prior to this post, please download it anew (the version string in the Principia UI should say 2021120408-Hamilton-0-gd0f59ca12318ef52bff4ee83615a2e1851f719a1, not 2021120408-Hamilton-0-g7522c92837f25fcc9d696e9d1a12fe2ff43ffd5a).
-
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 腾讯微云.
-
If you are trying to find a transfer rather than tune the resulting flyby (which I suppose is the case here, given how far you are zoomed out and given that the closest approach to Mars seems to be about three quarters of an astronomical unit away, you are looking at the wrong reference frame, which is sure to result in a mess. What you want is MSO or perhaps HCI. See the hovertexts on the selector buttons, which explain what the frames are for. Once you actually have a transfer and are tuning your flyby (or capture) to the scale of a few kilometres, rather than astronomical units, you should zoom in on mars; at that point MCI may be appropriate (though MSO will still do the job, and will tell you where the night side will be). If you are planning to land directly, MCMF should be used to see where you land.
-
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 腾讯微云.