eggrobin

Members
  • Content Count

    383
  • Joined

  • Last visited

Community Reputation

466 Excellent

5 Followers

About eggrobin

  • Rank
    Sr. Spacecraft Engineer

Recent Profile Visitors

3,466 profile views
  1. For the new moon (lunation number 241), the new release (Fermat) is out. Support for KSP 1.7.1 and 1.7.2 has been added; as previously announced, this release does not support KSP 1.3.1 and 1.4.x. A long-standing feature request (#1936, opened by @王小谦同学) has been addressed: all manœuvres of a flight plan can be edited, instead of only the last one. Manœuvres now take the thrust limiter into account (#2128, opened by @Kinexity). 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. For the new moon (lunation number 240), the new release (Fatou) is out. Support for KSP 1.7.0 has been added. Note that 1.7.1 was released after we built the release, so it is not supported. Also note that we have no special support for the new orbital information display, so that, like MechJeb or Kerbal Engineer Redux, it will display the largely-useless osculating elements at current time instead of mean elements for some appropriate theory. Further, note that we have no special support for the new manœuvre node editor, so that it will likely be unusable. This is the last version to support KSP 1.3.1 and 1.4.x, as Realism Overhaul and Real Solar System now support 1.6.1. The next version will only support 1.5.1 and up. The ascending and descending nodes are now shown with respect to the equator in the body-centred, body-fixed frame, and in the body-centred inertial frame if the central body is sufficiently close (#1841). Many bugs have been fixed that were introduced with the UI changes in Fáry and during the underlying restructuring of the UI code in Fano.  See the change log for more details. We thank @Miracle Magician for reporting a severe bug that would otherwise have been introduced in this release. We support two sets of versions of KSP: downloads are available for 1.4.x, 1.5.1, 1.6.1, 1.7.0, and for 1.3.1. 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 腾讯微云.
  3. It has come to our attention that there is a very active community of Chinese users of Principia; notably @王小谦同学 wrote a very detailed introduction to the mod for the Chinese audience, https://www.kerbcat.com/tutorial/md/13601/. For their convenience, in addition to the binaries hosted on Google Drive, we are experimenting with providing links to copies of the Principia Fáry binaries (and the TRAPPIST-1 patch), hosted on 腾讯微云. We welcome the feedback of the affected users on whether this makes things easier. 腾讯微云 links: Principia Fáry for 1.3.1; Principia Fáry for 1.4.x,1.5.1, and 1.6.1.; TRAPPIST-1 for Principia Fáry.
  4. Summarizing a discussion on IRC: this is a symptom of forces being applied using RigidBody.AddForceAtPosition, instead of Part.AddForceAtPosition. The latter (added in 1.2.x) allows other mods (such as Principia) to inspect the forces that were added; Principia needs that in order to be able to integrate the overall motion of the vessel; any forces added via the former will have no net effect on the vessel. Note that rocket engines, AJE jet engines, FAR aerodynamic forces, etc. use Part.AddForceAtPosition, and work correctly. In this case, the rotor (from Airplane Plus) is powered by Firespitter. It appears that Firespitter makes heavy use of RigidBody.AddForceAtPosition, see https://github.com/snjo/Firespitter/search?l=C%23&q=addforceatposition, so that its effect is ignored as soon as you are no longer touching the ground, leading to the observed behaviour. @Snjo: the calls to RigidBody.AddForceAtPosition linked above should be changed to Part.AddForceAtPosition; a lot of them are actually part.GetComponent<Rigidbody>().AddForceAtPosition, so you can simply drop the RigidBody in the middle.
  5. For the new moon (lunation number 239), the new release (Fáry) is out. The UI now scales according to the KSP UI scale settings, and has been made a little more compact; those flight plan settings that are controlled by a slider can now also be edited by text entry (this includes the Δv components and timing of manœuvres); the TRAPPIST-1 patch has been updated for @GregroxMun’s SLIPPIST-1 v0.7.x.  See the change log for more details. We support two sets of versions of KSP: downloads are available for 1.4.x, 1.5.1, & 1.6.1, and for 1.3.1. Make sure you download the right one (if you don't, the game will crash on load).
  6. Fano has no support for 1.7.0, and support for 1.7.0 has not yet been added at master (I am not sure whether we will get around to adding it in Fáry). There is at the very least some configuration work to be done when adding support for a new version; sometimes fixes are needed to make it build, and in any case thorough testing is in order to check that the changes did not break us.
  7. Hm, this means we will have to update the Principia TRAPPIST-1 patch. Opened #2129 to track this.
  8. For the new moon (lunation number 238), the new release (Fano) is out. The predictions are now computed asynchronously, making long predictions usable; this is particularly noticeable in the vicinity of bodies with complex gravity models, such as the Earth and Moon in RSS. Some bugs involving map view markers have been fixed. See the change log for more details. We support two sets of versions of KSP: downloads are available for 1.4.x, 1.5.1, & 1.6.1, and for 1.3.1. Make sure you download the right one (if you don't, the game will crash on load).
  9. This is really tricky, because the constraint here is not just to change the system until it is stable (that is easy, just put the orbits very far apart and make the central masses very high), but somehow to keep the general feel of the original system (including difficulty). For the changes to the Jool system, we did not change the masses, we tried keeping the moons as closely packed as we could, and we made the strange (possibly captured) satellite stranger, by making it retrograde and putting it in a strongly perturbed orbit. I don’t really see how to turn these constraints into anything that lends itself to being optimized, so some level of trial and error seems unavoidable. A possibility here would be to sidestep the game, which is quite a waste of time for these purposes. I experimented with the changes to the Jool system by writing a command-line utility that would simulate modified system and output relevant plots (similar to those shown in the wiki page). A quick glance at the apsis plot made it easy to see whether something happened; in the attempt illustrated below, Bop’s orbit gets kicked up about 50 years in, probably by a close encounter with Tylo. In fact, the foray into the integration of n-body systems that became the first Principia prototype started, in December 2013, as a standalone utility to investigate the stability of @NovaSilisko’s Alternis Kerbol. These utilities are a bit ad hoc, so they tend to fall in disrepair, and they strongly depend on the plotting tool used (the plots above were made with Mathematica, which may not be readily available). If you want to investigate this sort of thing extensively, you could write one for your specific needs using the Principia physics libraries (feel free to ask if you need help finding your way around these libraries).
  10. I suppose this is the mod we are talking about here. I am not familiar with it, but quickly skimming its original post, I see mentions of a teleportation process (that interacts poorly with RemoteTech antennae), and an attribution to HyperEdit. It seems that this is a mod which, among the many things it does, changes the orbit of vessels, or otherwise sets their position or velocity. These mods typically interact very poorly with Principia, as a core principle of Principia is to keep an internal model of where things are, and adjusting their in-game positions and velocities accordingly: this is how Principia can perform high-order symplectic integration even though the physics engine only does explicit Euler (which is a first order nonsymplectic method), and it is how it enforces conservation of momentum. Mods that try to change the orbit without going through Part.AddForce and the like have, at best, no effect (this is in particular the case of HyperEdit itself, which cannot be used to move vessels around when using Principia).
  11. I am not familiar with your mod, but at a glance your diagnosis seems accurate. I don't really see a meaningful way out of that incompatibility; there just is more information to show with Principia (in this case, the choice of reference frame), so throwing more stuff into the navball is tricky. We are actually working on orbital analysis tooling, to provide a better understanding of perturbed near-Keplerian orbits; this would provide contextual information (things like the nodal and apsidal orbital periods., synchronicities, repeat ground track properties if applicable, etc.), but would likely be displayed in a separate window.
  12. We have been on vacation for the past three weeks; aside from the release post, whose timing is dictated by the motion of the Moon, we haven’t really been following the forum during that time. It is indeed the case that planning things in this situation is a right mess; thank you for pointing to a concrete scenario, this is helpful when it comes to figuring out how best to improve things. I assume we are talking about the flight plan here, not the fuchsia prediction. Even with text entry to get the timing roughly where it needs to be, the fine tuning would be awful, because every change will force Principia to recompute the entire month of sitting around in LEO, freezing the UI in the process. There are several things at play in this scenario: Principia should not recompute the entire penultimate coasting arc when the final burn is moved: the LEO parking will not change because you do more or less of it, so it is a waste of time to recompute it all; Principia should not recompute the trajectory on the main thread: blocking the game on something that is a planning tool (rather than the core logic of where things currently are) is bad practice; waiting in LEO has a discrete nature to it: there is one window per orbit for a burn in the right direction, and putting your burn anywhere else is pointless, but there is no way to tell Principia to advance your burn timing by one orbit; additional entry mechanisms (including text entry) could be less fiddly than the sliders in some circumstances. I suspect that the most critical problem here is 1. Indeed, as the flight planner only allows edition of the last node (we plan on changing that eventually, but this is tricky: see the discussion in #1936), it is always the last manoeuvre that is being changed; the flight planner then recomputes the penultimate coast arc, the burn arc, and the final coast arc. When planning, e.g., an orbital insertion, one is generally not interested in what happens hundreds of orbits after insertion, so that the interesting part final coast arc does not take long to compute; the burn arc is short; it is the penultimate coast that may be long and costly to entirely recompute (such as the case of the parking orbit at hand). We have mechanisms in place to save the state of the integrator from time to time, so as to be able to resume an integration without redoing the whole thing; we should probably use them for the flight plan. Regarding 2.: @pleroy has been hard at work on recomputing the prediction on a separate thread, so as to display the freshest one rather than stalling the UI while waiting for a brand-new prediction. We started with the prediction in part because, with the advanced gravity models for the Moon, it was becoming laggy even at short lengths in low lunar orbits (the prediction is always on, so this makes things constantly laggy in map view). This could pave the way for doing something similar for the flight plan if needs be. Regarding 3.: I have been investigating the analysis of spacecraft trajectories as perturbed Keplerian orbits, with the aim to provide a way to tell what kind of orbit your satellite is in, since the osculating elements given by KSP constantly vary along the orbit. Such an analysis could also identify repeat ground track orbits, a sun-synchronous orbit, etc. Principia currently is completely agnostic to orbits; it considers vessel trajectories as completely arbitrary, and has no concept of “one orbit later”, so moving the nodes that way is not an option. With orbit analysis, it may become possible to have that, and thus to move a burn to the next orbit while keeping it in the right direction for an interplanetary transfer (you would probably need several options here: one synodic period later, one sidereal period later, one nodal period later, or one apsidal period later, depending on what you seek). Regarding 4.: Changes to the UI are tricky from a design standpoint (see, again, the discussion in #1936). However, we also have a lot of technical debt in the C# that impedes changes there; @pleroy has been working on refactoring that.
  13. For the new moon (lunation number 237), the new release (Euler) is out. Issue #2072, introduced in Erdős, which manifested as free fall unaffected by parachutes or engines below 8.4 m altitude in RealSolarSystem (leading to rough splashdowns), has been resolved. An API has been added to allow @Jim DiGriz’s guidance algorithms to access the geopotential coefficients; see #2074. See the change log for more details. We support two sets of versions of KSP: downloads are available for 1.4.x, 1.5.1, & 1.6.1, and for 1.3.1. Make sure you download the right one (if you don't, the game will crash on load).
  14. @Delay: It seems this is a KSP (or mono) bug, not a Principia bug, for the following reasons: I. error.log says KSP_x64.exe caused an Access Violation (0xc0000005) in module KSP_x64.exe at 0033:4079a4ba. whereas when we have a bug of that kind in Principia, error.log mentions the module accordingly (this could also say physics.dll or serialization.dll): principia.dll caused an Access Violation (0xc0000005) in module principia.dll at 0033:db9294cc. II. The stack trace in the output_log is not in Principia, it is in mono: ========== OUTPUTING STACK TRACE ================== 0x000007FEE1EF23D3 (mono) g_free 0x000007FEE1F284EB (mono) mono_gc_is_finalizer_thread 0x000007FEE1F28611 (mono) mono_gc_is_finalizer_thread 0x000007FEE1F93B87 (mono) mono_thread_interruption_request_flag 0x000007FEE2048E77 (mono) mono_unity_class_get 0x0000000076DF59CD (kernel32) BaseThreadInitThunk 0x000000007705385D (ntdll) RtlUserThreadStart ========== END OF STACKTRACE =========== This is confirmed by running it against our stack trace decoder with the PDBs for Εὐκλείδης, which yields: <!--- Using Principia base address 7FEE2540000 --><!--- Using Physics base address 7FEDFD20000 --><!--- Not in loaded modules: 0x000000007705385D (ntdll) RtlUserThreadStart --><!--- Not in loaded modules: 0x0000000076DF59CD (kernel32) BaseThreadInitThunk --><!--- Not in loaded modules: 0x000007FEE2048E77 (mono) mono_unity_class_get --><!--- Not in loaded modules: 0x000007FEE1F93B87 (mono) mono_thread_interruption_request_flag --><!--- Not in loaded modules: 0x000007FEE1F28611 (mono) mono_gc_is_finalizer_thread --><!--- Not in loaded modules: 0x000007FEE1F284EB (mono) mono_gc_is_finalizer_thread --><!--- Not in loaded modules: 0x000007FEE1EF23D3 (mono) g_free -->
  15. @Delay Thank you. We will also need the corresponding INFO log (that would be in the glog directory; there will be many INFO logs, make sure you pick the correct one, that is, the last one that was created before the crash).