Jump to content

eggrobin

Members
  • Posts

    483
  • Joined

  • Last visited

Everything posted by eggrobin

  1. For the new moon (lunation number 255), the new release (Galois) is out. It is now possible to insert and delete manœuvres in the flight plan; in particular, this makes it possible to insert correction manœuvres after rebasing. Manœuvres can be collapsed and expanded, making it easier to manage flight plans with many manœuvres. A bug involving incorrect thrust when planning RCS manœuvres was fixed. Thanks to @Flibble for contributing this fix. 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 腾讯微云.
  2. The stock tidal locking flag never really works in the presence of Principia, and leads to aberrant spin and de-spin; Principia thus always disables it. It should be noted that, in a non-Keplerian world, finding the correct rotation period for tidal locking is tricky. As you have seen in the orbit analyser, satellites have three different orbital periods, none of which are equal to the osculating period (the period of the stock Kepler orbit at a given instant), and the same holds for a celestial body. Since we do not model pressions of the axes at this time (the rotation axis is fixed in space), you want to use the sidereal period of the body as its rotation period. Computing that period may prove to be a challenge, as the orbit analyser does not currently work for celestial bodies.
  3. For the new moon (lunation number 254), the new release (Gallai) is out. As previously announced, this release dose not support KSP 1.7.3 and earlier. A rebase button has been added to the flight plan, to take changes to the actual trajectory into account without having to recreate the flight plan. Altitude-related information has been added to the orbit analyser. A number of bugs have been addressed: EVA collision leading to absurd movement, EVA parachutes being broken, vessels disintegrating at absurd speeds, vessels deforming when coming out of warp. 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. @pleroy and I are the authors. This is not our job, no managers are involved (except of course for @sarbian’s ModuleManager). As for your remark, there is a new Principia release every new moon; whether the mod needs to be updated or not is entirely irrelevant to that schedule. I think with that needs you are alluding to 1.10 support; even when things go smoothly, it often takes several Principia releases before we support a new KSP version, just to check that everything is fine with the new version. Here things may not be completely smooth, as, depending on how they were implemented, correctly handling the comets may require a lot of work.
  5. There is a mod that gives you that: Principia. Evidently you want something else. It is not clear to me whether you mean complexity for the player or complexity for the implementer. If you care about implementation complexity (but why would you? it is our burden, not the player’s), Dealing only in three-body mechanics would make things strictly more complicated: you would end up with a maze of special cases and nasty transitions between situations where you choose two given bodies, and you would still have to deal with the full complexity of stable numerical integration of trajectories in the 3-body problem; see @chuckstables’s post for an introduction to that. More importantly, most of the implementation complexity comes not from computing where your spacecraft goes (that was pretty much done 5 years ago), but from providing the player with the tools needed to understand where it is going. The very concept of orbit, as understood by stock KSP (and stock KSP players), falls apart under the influence of a third body, so a reimplementation of the entire patched conics & manœuvre node system (which relies on the stock orbit logic) is needed to be able to plan your flight in those situations. For complex trajectories such as, in particular, those that stay near Lagrange points, a stock-style trajectory display in a nonrotating reference frame centred on one body is unusable; we therefore need to introduce a choice of reference frame so that trajectories that involve Lagrange points are understandable as such, and not merely as weirdly perturbed orbits of one of the bodies. The custom flight planning, reference frame selection, and other aspects, besides being a major source of implementation complexity, are also the major source of gameplay complexity: not only do we need to build those new tools, the player needs to learn to use them. These tools are needed in order to understand the varied trajectories that can arise in the non-Keplerian world. They are needed even if you only have two massive bodies (and in particular they are needed to work with Lagrange points). In fact they are needed to effectively work even with a single non-spherical body: oblateness makes orbits precess, and you need tools to understand how they do so. The gameplay complexity comes from the fact that you are dealing with complex trajectories, and not just with easily-classified Kepler orbits anymore; this is true with two massive bodies just as much as it is true with twenty. Have you tried Principia, and if so, what issues did you run into that brought up these questions?
  6. While the cost of prolonging the ephemeris is quadratic in the number of massive bodies (whereas computing the trajectory of a vessel is linear in that number) the timescales are very different (at least in the worst case, and since it is not possible to have variable step size and symplecticity, the chosen step size must accommodate the worst case); this is a case where the constant factor matters more than the asymptotic behaviour (the number of massive bodies remains fairly small, even with RSS). As @scimas said, these are vessels. We had this kind of thing in mind when choosing the number of terms in the selenopotential—we go up to degree and order 30—: it was chosen to keep the qualitative behaviour of the low orbits described in a 2006 paper by Ryan P. Russel and Martín Lara, Repeat Ground Track Lunar Orbits in the Full-Potential Plus Third-Body Problem; see figures below. Do you have any screenshots of your frozen orbit, and of what the orbit analysis window says about it? My attempts at getting a frozen lunar orbit in-game have not been very successful. ⸻ Figures from our investigation of Russel and Lara’s Orbit C with various selenopotential truncations.
  7. For the new moon (lunation number 253), the new release (Galileo) is out. The exceptions raised by the external API for other KSP mods now include an error message. Miscellaneous bugs have been fixed (most notably, the centre of mass offsets are now taken into account). See the change log for more details. We support two sets of versions of KSP: downloads are available for 1.9.1 & 1.8.1, and for 1.5.1, 1.6.1, 1.7.x. Make sure you download the right one (if you don't, the game will crash on load). For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. This is the last release to support KSP 1.5.1, 1.6.1, and 1.7.x, as Realism Overhaul and Real Solar System now support 1.8.1.
  8. To elaborate on @pleroy’s reply, in case you are interested in the technicalities: It is a bug, and it is exacerbated by using these specific engines. Indeed, but that would make things laughably unflyable in stock just as much as with Principia. This is true of the model (note that the J57 is from AJE modified by RO, rather than being from RP-1 itself). This is not true, and this is where the bug lies: the centre of mass is offset from the model. This is what the rapier looks like on its own, with the centre of mass shown: note that the centre of mass is quite far outside the part. Principia has heretofore ignored that offset between the position of the part and that of its centre of mass; this went largely unnoticed before we started handling rotations, but it now becomes visible. This is tracked by issue #2560. It looks like your plane becomes flyable once these offsets are taken into account: #2604 will fix #2560, and your plane in the process. All going well that fix should make it into the upcoming release at the end of the week.
  9. We cannot deal with bugs that we do not know about and cannot reproduce. We only know about one remaining instance of #2519 at this time; the issue seems to have become exceptionally rare. If you want us to investigate what happens to your plane, you may want to send it to us. This is a known incompatibility. I believe it could be resolved on the KCT side by signalling to Principia that the craft is not ready to be managed by Principia, via the vessel situation. @siimav may have more thoughts on this.
  10. In order to interact with manoeuvres you would also need an API for that; perhaps you may want to resurrect something like https://github.com/mockingbirdnest/Principia/issues/2144 (and to talk to @Butcher, who has worked on that and may have some useful insights, about it).
  11. Predictions are predictions, they come with a lot of fine print (beyond the obvious impossibility of actually predicting the future in the presence of a player, computing the future in the same way as we compute the past would be prohibitively slow, so that the predictions are approximate; this means that you need to supply additional data on how accurate you want them, computing them may require lengthening the ephemeris which can be expensive, etc.). External APIs with a lot of parameters and a lot of fine print mean more work, not just to implement them, but to maintain them in the years to come. VesselGetPosition was added for a specific use case in @Sir Mortimer's KerbalismContracts, whose design is, while not wholly dependent on Principia, at least highly aware of its existence. For that use case, past positions were enough. What is your use case?
  12. For the new moon (lunation number 252), the new release (Fuchs) is out. The issues with rotation (uncontrolled spin-up, jerky motion, oscillations, etc.) introduced in Frobenius and Fubini have for the most part been solved. We are aware of one remaining case of aberrant spin-up, reported by @scimas, but this seems to be a very rare issue at this point. Prior to ignition, the manœuvre node marker on the navball for guided burns now points to the orientation at ignition, instead of following the current Frenet frame. This is more useful for manual burns (the spacecraft can be oriented correctly prior to ignition, instead of having to be guided even before the manœuvre starts). Perhaps more importantly, in conjunction with change MuMech/MechJeb2#1264 (available in MechJeb dev builds ≥ 958), this means that MechJeb can execute all Principia manœuvres. New APIs have been added for use by @Sir Mortimer’s KerbalismContracts. See the change log for more details. We support two sets of versions of KSP: downloads are available for 1.9.1 & 1.8.1, and for 1.5.1, 1.6.1, 1.7.x. Make sure you download the right one (if you don't, the game will crash on load). For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. This is the last release to support KSP 1.5.1, 1.6.1, and 1.7.x, as Realism Overhaul and Real Solar System now support 1.8.1.
  13. 2020-04-23 For the new moon (lunation number 251), the new release (Fubini) is out. Support for 1.9.1 has been added. The flight planning and orbit analysis window are now available in the tracking station, bringing into line with map view. Some changes have been made to mitigate the aforementioned issue #2519. Wild spin no longer seems to be an issue, however some unexpected oscillations arise under some circumstances. We will keep investigating this issue. Some issues that would cause crashes have been resolved. See the change log for more details. We support two sets of versions of KSP: downloads are available for 1.9.1 & 1.8.1, and for 1.5.1, 1.6.1, 1.7.x. Make sure you download the right one (if you don't, the game will crash on load). For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云.
  14. This issue has been reported by @nepphhh and @scimas https://github.com/mockingbirdnest/Principia/issues/2519, however I have not been able to reproduce it, which makes it very difficult to diagnose. Could you provide a stock craft that reliably reproduces the issue? I am currently unable to run RSS/RO (the only machine I have that can run that at usable speeds is about 600 km away, and given the circumstances it will be a while before I can get back to it).
  15. This was done in #2505 already. Support will thus be added in Fubini, which will be released on the next new moon, on the 23rd of April. Please don’t do that. It would make support messy, as we would need to keep track of versions built in between releases (the mod is frequently in a broken state at master). Further, building reproducibly on all three platforms may prove a challenge for you (we have a fairly robust setup based on Azure pipelines now, but this used to be a mess for years), and releasing a Windows-only build would likely lead to further confusion.
  16. Frobenius is available again. Note that if you downloaded it before March 24, 21:00 UTC, you probably have a buggy version (see #2503). Please download it again. If you have the correct version, the version string in the Principia UI says 2020032409-Frobenius-0-g21e623384639abd4bdd277a9fb722e94ee9763e4. We apologize for the inconvenience. Also note that, as mentioned in the change log for Frobenius, Principia is now incompatible with PersistentRotation, as Principia now handles rotation. Please uninstall PersistentRotation if you have been using it, otherwise the two mods will fight each other.
  17. Important notice: we have discovered an issue in Frobenius that renders the game unplayable (rockets occasionally get flipped back-to-front while being launched). As a result, we have retracted the Frobenius binaries while we investigate the issue; Frobenius will be re-released once we have resolved it.
  18. For the new moon (lunation number 250), the new release (Frobenius) is out. After nearly a year of work and 96 pull requests, Principia now enforces the conservation of angular momentum, as had been alluded to earlier. This means, among other things, that: the long-standing bug #1639, reported by @Damien212 in 2017, whereby the orientation of vessels changed when they underwent an SoI transition, is resolved; vessels will rotate as rigid bodies, following Euler’s equations, in time warp; in particular they may exhibit the Джанибеков effect in time warp, as illustrated in the short video below; changes in mass distribution within the vessel, e.g., due to fuel transfer, will affect the angular velocity, as illustrated in the short video below. See the change log for more details. We support two sets of versions of KSP: downloads are available for 1.8.1, and for 1.5.1, 1.6.1, 1.7.x. Make sure you download the right one (if you don't, the game will crash on load). For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云.
  19. @viktor19, @hypervelocity: by the way, we are interested in your large saves: looking at them will allow us to test the effectiveness of our solutions on real orbits. Please post them on #2400.
  20. This is known and expected, and tracked in #2400: the underlying issue is that the past trajectories of vessels accumulate over the years, and end up being very voluminous. We are working on a solution, but this will take a while, and will likely happen in multiple steps*. In the meantime, the suggested workaround is to delete old vessels (including debris) if you don't need them. ⸻ * We have experimented with a quick fix (using a lossy floating-point compression algorithm) that reduces savefile size by a factor of 4. I am currently looking at papers on compact representation of ephemerides by Jean Chapront, Vũ Dương Tuyền, and Сергей Михайлович Кудрявцев, with whose methods I hope to gain several orders of magnitudes by taking advantage of the highly periodic behaviour of orbits.
  21. For the new moon (lunation number 249), the new release (Frenet) is out. Nothing new this time; we have been working on the preservation of angular momentum, but it is not quite ready yet. See the change log for more details. We support two sets of versions of KSP: downloads are available for 1.8.1, and for 1.5.1, 1.6.1, 1.7.x. Make sure you download the right one (if you don't, the game will crash on load). For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云.
  22. Some of them will be unstable: see the orbit shown in the release announcement for Εὔδοξος for an example. There are however low lunar orbits that remain stable (so-called frozen orbits), and there is extensive literature on the subject. For instance, the figure below, from Martín Lara's 2011 paper Design of long-lifetime lunar orbits: A hybrid approach, shows the stable eccentricity corresponding to a given inclination for lunar orbits with selected semimajor axes (for a frozen orbit, the argument of periapsis ω is either 90° or 270°, so that the value plotted on the vertical axis, e sin ω, is ±e). Note that only 4 non-equatorial inclinations are permitted for stable circular (e = 0) orbits at any of these altitudes. You can use the orbit analysis tool to see the mean orbital elements of your current orbit; by aligning those with the values given by that figure, you should be able to keep your spacecraft in low lunar orbit without need for long-term stationkeeping.
×
×
  • Create New...