Jump to content

eggrobin

Members
  • Posts

    464
  • Joined

  • Last visited

Everything posted by eggrobin

  1. 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.
  2. 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 腾讯微云.
  3. 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.
  4. 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 腾讯微云.
  5. 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.
  6. 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).
  7. 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 腾讯微云.
  8. 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 腾讯微云.
  9. 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 腾讯微云.
  10. 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.
  11. 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.).
  12. 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 腾讯微云.
  13. 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.
  14. 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.
  15. 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 腾讯微云.
  16. 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 腾讯微云.
  17. 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.
  18. 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 腾讯微云.
  19. They are not, which is why the installation process requires installing the right system dependencies metioned (and, for Windows, linked to) in the FAQ.
  20. Please don’t bundle Principia. Instead direct users to the README.md page on GitHub. There are several reasons for that: Principia has its own (system-level and platform-specific) dependencies, which you cannot bundle without a platform-dependent installer: if Principia is provided in a bundle, it will simply not work out of the box; we want users to know where the concepts & FAQ pages can be found, as well as the specific bug reporting procedures, and the readme will tell them about that—Principia is complicated enough that if users get it as part of a bundle, there will be an enormous amount of confusion (for instance when it come to plotting frames) that will require support from your part or ours; we very much prefer that users upgrade in a timely manner, which is much harder to do for a bundle that may or may not track our releases closely, especially in the longer term—few mods are updated every new moon for years; we like to track usage and analytics of the mod, and, again, that’s impossible through a bundle; we would like new users to be able to find the existing community of Principia users (on IRC, discord, this thread, etc.), so that their questions may be answered by more experienced users rather than us.
  21. For the new moon (lunation number 260), the new release (Germain) is out. Support for KSP 1.11.0 has been added. The orbital analysis of the final trajectory is now available in the flight plan, making it possible to plan accurate orbital insertions and corrections. 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 腾讯微云.
  22. A notice to all Principia users: DO NOT use the « fix » provided in the above post. @100055 you have completely misunderstood how the axial tilt configuration works, and therefore your so-called fix is incorrect. All orientations of the planetary axes are given by right ascensions and declinations in the International Celestial Reference System (ICRS), whose reference plane is the mean equator of the Earth at the standard epoch J2000; in particular, this means that the axis of the Earth has a declination of 90°. This is the convention used by the International Astronomical Union, and specifically by its Working Group on Cartographic Coordinates and Rotational Elements. Our use of these conventions is documented. It is also evident by looking at your « fix » that you do not understand how the Principia initial state configuration works: you patch the Kopernicus orbits, whereas those are completely ignored in the presence of the initial state file. If this part of your patch has any effect at all, it means you improperly installed Principia or RSS. The initial positions and velocities of the planets, given in the sol_initial_state_jd_2433282_500000000.cfg file, are in the ICRS. Having axis orientations given in a reference frame different from the positions and velocities of the bodies means, obviously, that the orientation of the axes with respect to the solar system will be incorrect. Nothing should be relative to the ecliptic, everything should be in the ICRS. Indeed, to quote Nicole Capitaine, As a side note You also do not understand how Principia implements axial tilt: Principia does the exact same thing as RSS, except with respect to the current main body, so Principia will always tilt the universe so that the current main body is horizontal. This is, however, invisible with Principia, because we then tilt the camera according to the currently-selected reference plane. If you play with the reference frame selection (e.g., switching between Earth-Centred Inertial and Sun-Earth Barycentric), you will notice that your view is differently-oriented. Don’t try to fix things that you don’t understand, you are doing a disservice to everyone. If for some reason your game is showing you things that you don’t expect, ask about it ; maybe you don’t understand what you are seeing, maybe your install is misconfigured. What is definitely not the case is that a configuration used by hundreds of people, with which they have accurately replicated astronomical events dependent on axial tilt, is wrong in such an egregious manner.
×
×
  • Create New...