Jump to content

eggrobin

Members
  • Posts

    483
  • Joined

  • Last visited

Everything posted by eggrobin

  1. 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.
  2. 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.
  3. For the new moon (lunation number 281), the new release (Ἵππασος) is out. Three bugs have been fixed. See the change log for more details
  4. 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.
  5. 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.
  6. 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, Σκοπός.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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 腾讯微云.
  16. From https://github.com/mockingbirdnest/Principia/wiki/Principia-configuration-files#the-principia_override_version_check-configuration:
  17. 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).
  18. 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 腾讯微云.
  19. 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.
  20. 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 腾讯微云.
  21. A significant issue was found with this, which should have been a usability improvement in Hadamard (#3144, it was impossible to type in the flight plan duration and flight plan initial time fields), so we have hotfixed the release; if you downloaded Hadamard prior to this post, please download it anew (the version string in the Principia UI should say 2021100611-Hadamard-0-g5a4626303afea27800d7ef283ce66c54f98be3c8, not 2021100611-Hadamard-0-g541a52fbd877e03e589f025c16d3b0e7cb02e590). We apologize for the inconvenience.
  22. 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 腾讯微云.
  23. you certainly could, but as @Al2Me6 points out, it would be profoundly pointless; unless you want to watch your orbit decay over the course of a month in real time (and doing nothing else in the meantime), entirely new mechanisms would be needed to implement long-term drag. In particular one would need, deep inside the works of Principia, to change the numerical methods to accommodate for long-term integration with velocity-dependent forces (and major restructuring would be needed so the orientation is available in the right place, since those forces are also orientation-dependent). In any case, this (or even solar radiation pressure which raises similar considerations) is not particularly interesting from a gameplay standpoint unless the question of automated stationkeeping is also resolved (a problem which has already been mentioned here, and is even messier to even approach). It would artificially make many real-life mission profiles infeasible, since in real life you can happily regularly stationkeep such orbits. This is the opposite of what is true. Indeed, these burns that track the Frenet frame are more efficient. It can readily be seen that for a burn that aims to solely change the inclination (without affecting the semimajor axis), no net work should be done, since the orbital energy must not change. Any work done, that is, any thrust provided along the direction of motion, must be undone, and is thus wasted; thrusting orthogonally to the direction of motion is the only way to not waste energy in such a way. Conversely for a burn that does aim to change the orbital energy, all thrust should result in work in order to maximize that change, and thus the thrust should always be directed in the direction of motion.
×
×
  • Create New...