Jump to content

eggrobin

Members
  • Posts

    459
  • Joined

  • Last visited

Reputation

655 Excellent

7 Followers

Profile Information

  • About me
    An egg drowning in a sea of papers

Recent Profile Visitors

5,584 profile views
  1. 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.
  2. Maybe file a bug for the performance issue? Having the UI open is not supposed to slow things down to a crawl... The UI features that help make the UI smaller are there to make the UI smaller, not faster; if it is slowing things down to start with, there is a bug (probably the KSP localization logic being slow, but it should be easy to cache things).
  3. 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 腾讯微云.
  4. 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 腾讯微云.
  5. 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 腾讯微云.
  6. This is not a bug, this is how Principia manœuvre execution works: see https://github.com/mockingbirdnest/Principia/wiki/Concepts#flight-planning-user-interface. With Principia, manœuvre execution is either closed-loop by hand (look at map view, cut the engine when the trajectory does what you want), or open-loop based on the countdowns given in the flight plan (this latter approach is hampered by spool-up times in RO though, so it is better to keep an eye on map view). Note that MechJeb has an implementation of the timing-based approach (an « Execute next Principia node » button) since around the time of Fuchs (May 2020). I don’t think we have much in the way of guides beyond what is on the wiki and the odd video. On the other hand, you may wish to ask questions on the Discord/IRC/matrix channel listed in the OP, there is a fairly active community there.
  7. 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 腾讯微云. It depends what you mean by « Keplerian orbital elements » (and possibly on what you mean by « extract »), which in turns depends on what « something » is. In this perturbed Keplerian context, there are many kinds of elements, suitable for various applications. In a lot of cases you care about mean elements. These encompass many definitions, but the concept is « elements that smooth out the perturbations that are on the scale of one revolution », so as to tell you something meaningful about the whole orbit around a given time ; they will still change over time (in particular you will encounter nodal and apsidal precession). The orbit analyser gives you mean elements. Osculating elements do not really tell you meaningful things about the overall orbit, since they change significantly along the orbit; they are primarily useful as a way to express the exact position and velocity at the current time, for systems that prefer that to cartesian coordinates. KSP handles osculating elements, so this is what is surfaced in the stock UI, and in other mods (MechJeb, KJR, etc.).
  8. 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 腾讯微云.
  9. This sounds like a symptom of the same issue as https://github.com/mockingbirdnest/Principia/issues/2957 and https://github.com/mockingbirdnest/Principia/issues/2953; it should be fixed in the next version, Green. The Principia window spawns an asynchronous orbit analyser (this is used to give you a short description of orbit you are currently in, e.g., « circular semisynchronous Kerbin orbit » or something around those lines). This is not new, and is not a performance problem in itself (it runs fairly rarely and does so in the background). When the vessel lands, it becomes « unmanageable » by Principia, and all Principia-side state is destroyed. Due to a bug in our handling of the interruption of a numerical integration, the destruction of a running analyser is very slow, especially since Grassmann. This explains lag on landing. A walking Kerbal just keeps landing and taking off.
  10. That might be slightly less useless; please also film a launch that doesn’t crash, so that we can actually see a transition to lower lag in space (without an intervening scene change), and figure out if it is correlated with something on the Principia side.
  11. 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 腾讯微云.
  12. 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 腾讯微云.
  13. Calling Part.Add(Torque|Force(AtPosition)?) is the only way for a mod to apply a net force to a vessel in the presence of Principia. Calls to RigidBody.Add(Torque|Force(AtPosition)?) will have no net effect on the vessel (though they may deform it). Mods that use RigidBody.Add(Torque|Force(AtPosition)?) are Principia-incompatible.
  14. 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 腾讯微云.
×
×
  • Create New...