Jump to content


  • Posts

  • Joined

  • Last visited

Posts posted by eggrobin

  1. 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.

  2. 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.

  3. 38 minutes ago, ZAJC3W said:

    Put vessel on rails and deduct propellant based on time spent on rails, that's roughly how station keeping in OrbitalDecay mod worked.

    Sounds simple but putting vessel "on rails" would probably mean rewriting half of the integrator.(I know nothing about it)

    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.



    Maybe starting point would be adding flight  planner option to calculate burn to return to current orbit in user selectable number of days?

    That eliminates the interaction with KSP, which admittedly is the boring and tedious part in addition to being difficult. But that leaves you with:


    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).

    which is probably the harder part (though the more interesting one).



    Big prolem with atmospheric drag and solar pressure is that their influence strongly depends on vessel orientation, unless vessel is a sphere.

    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.



    I wish I had the skill to help more than just throw ideas around.

    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, Σκοπός.

  4. Just now, ZAJC3W said:

    First post mentions orbital decay as a thing "relatively easy" to add once the mod is playable ;)

    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.

  5. 7 hours ago, Krazy1 said:

    I installed a planet pack that repatched the Jool system, then I removed that planet mod.


    6 hours ago, Krazy1 said:

    Well, I deleted and re-copied the Principia (Hesse) folder and started a new save and it did not fix the issue... Jool system looks like stock in the tracking station with patched conics on. […]

    But it's stock... it should recognize it and change Bop's orbit. […]

    UPDATE2: I found this in the first glog files before installing the planet pack: [This appears to be the dreaded KSP stock system!]

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

  6. 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.

  7. On 5/10/2022 at 1:50 AM, WilliamRiker2701 said:

    Hi!, i'm having a difficult time trying to complete satellite positioning missions. I'm using RSS as well as Principia.
    These are the kind of missions where you must position spacecraft at a specific orbit around a celestial object, and i find it very hard to accomplish one specific mission objective: stay in the orbit within reasonable deviation. Since with principia the orbit doesn't stay the same all the time, it's harder to stay at specific Pe and Ap points and also inclination, but looks like no matter how close i managed to make it, the objective doesn't get green ticked. Is it possible to do it? if i try harder i will accomplish the objective, or i'm just going to waste time?

    This is a common question, which does not really have a good answer at this time.

    On 5/21/2020 at 12:31 PM, pleroy said:

    I believe that this is a well-know annoyance of the stock contracts with Principia.  They are based on 2-body mechanics (a.k.a. conics) and don't work well in the presence of more complex trajectories.

    I also believe that KerbalismContracts plans to support more realistic contracts that would work well with Principia.

    On 5/22/2020 at 10:55 AM, Sir Mortimer said:

    My best guess is that the "maintain stability for 10 seconds" part of the contract fails because Principia keeps changing the orbit information all the time. My advice: cheat it to completion, and never take such a contract again, ever. (They're boring anyway)

    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.

    49 minutes ago, MaltYebisu said:

    I'm playing a game in the stock solar system to familiarize myself with Principia before (hopefully) starting a RP-1 game. 

    After losing two SCANsat probes trying to map the Mun I'm searching for a way to know if a vessel is dropping below a certain altitude or the perigee is lower than a certain distance. How do you guys do it? Any mods that are able to give that kind of warning would make the game a lot less about babysitting my satellites and more about going new places.

    The Kerbalism mod have a setting for warning you about a vessel entering atmosphere, but I couldn't find anything about going too low. I guess most people don't have to worry about orbits not being stable, because they play without Principia. 

    Any tips would be appreciated! :D

    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.

  8. 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.

  9. 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.

  10. 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.

  11. 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.

  12. 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 腾讯微云.

  13. 9 hours ago, JeromeHeretic said:

    Hm... but i still have problem. With config game starts, but […], game crash.

    From https://github.com/mockingbirdnest/Principia/wiki/Principia-configuration-files#the-principia_override_version_check-configuration:


    Note however that there will be no support whatsoever if the version check is overridden.


  14. 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).

  15. 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 腾讯微云.

  16. 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.

  17. 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 腾讯微云.

  18. On 10/5/2021 at 10:39 PM, eggrobin said:
    • The duration parser is a little more lenient.

    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.

  19. 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 腾讯微云.

  20. On 9/11/2021 at 1:44 PM, AloE said:

    […] you could make your own revised custom atm model […]

    you certainly could, but as @Al2Me6 points out,

    On 9/12/2021 at 2:25 AM, Al2Me6 said:

    And how will help that anything? Atmospheric drag isn't applied during timewarp or while the vessel is unloaded. Sure, it works for a few more kilometers while you're at the vessel, but you're just moving the problem elsewhere.

    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.

    19 hours ago, jd284 said:

    it seems like rotating the spacecraft during a burn by 30 to 60 degrees (as happens with major plane changes) uses substantially more delta-V than just burning in an inertially fixed way.

    This is the opposite of what is true.


    Is there any advantage to non-inertially-fixed burns?

    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...