Jump to content

eggrobin

Members
  • Posts

    468
  • Joined

  • Last visited

Everything posted by eggrobin

  1. Indeed; and at this point, we run into the code complexity of threading that callback all the way down to the integrator; further, even if we did that, there is the aforementioned performance problem: In addition, the integration method1 that we use for long-term vessel trajectories only works if the forces that it is applying depend solely on the position of the vessel, not its velocity; and it only has nice properties if these forces derive from a potential. This in turn means that we would need to switch to a different kind of integration method (which would likely have to be slower to have comparable accuracy), again inducing lots of complexity. TL;DR: thrust in timewarp is not trivial, and will not happen soon; it cannot be a simple “apply force” binding like the ones found in Unity or KSP. ⸻ 1 A symmetric linear multistep method, whose underlying one-step method is conjugate-symplectic.
  2. Principia and Orbital Decay (or any other mod that alters the orbits) are fundamentally incompatible. @Papa_Joe, since you are the new maintainer of Orbital Decay, please note the above; it may be useful to document this incompatibility. You cannot; this is inherently at odds with what Principia does, because keeps an internal dynamical state that it gets propagated by numerical integration, and overrides what stock orbits do. Any changes to the orbits would have to be done as part of the numerical integration, and considerations of complexity as well as performance mean that they have to be done by Principia. To quote some related past discussion to that effect:
  3. @Eriksson What about the Fukushima paper linked by @pleroy, or the ones that @Jim DiGriz linked? Those are specifically about computing the gravitational field given the shape. @AloE Kerballoons is using Rigidbody.AddForceAtPosition instead of Part.AddForceAtPosition, which means that Principia cannot learn about those forces, and therefore cannot make them affect the trajectory; this is the same issue that we found in FireSpitter earlier: In order to be compatible with Principia, a mod that imparts a net force to the vessel must do so with Part.AddForceAtPosition (or Part.AddForce) instead of Rigidbody.AddForceAtPosition (or Rigidbody.AddForce); the force can then be handled by the game (and any mods) instead of being passed directly to Unity. This should be a pretty simple change: all usages of AddForceAtPosition are actually on the RigidBody of a part (part.RigidBody.AddForceAtPosition), so dropping the .RigidBody would do the trick.
  4. Indeed: if the geoid is equal to the terrain height, there is no such thing as downhill (everything is horizontal), which should intuitively be pretty disturbing when you are standing on the slopes of Minmus. As an extreme example, consider a cube of uniform density; figure 1 of Chappell, Iqbal, and Abbott (2012), The gravitational field of a cube, shows the shape of a lake on one of the faces of the cube (lakes, being fluid, lie on an isopotential). Note that the shape of the lake (and thus the geoid) resembles a sphere far more than the face of the cube, whose corners are mountains.
  5. @Eriksson I have not checked the correctness of your code. However, I believe that there is an issue with the general approach: what you are doing is computing a spherical harmonics expansion for the topography (the shape of the ground), rather than the gravitational field (the shape of would-be sea level). In other words, if you correctly compute that which you are trying to compute, you will end up with a gravity field such that the geoid and the topography are the same, i.e., where the ground is (locally) horizontal everywhere. This should not be the case (the sides of mountains are not horizontal, that's how things go downhill). Instead, the geoid tends to be smoother than the topography. For an illustration of this principle, see figure 1 of Franz Barthelmes (2013), Definition of functionals of the geopotential and their calculation from spherical harmonic models: theory and formulas used by the calculation service of the ICGEM. Further, something about the numbers you list in your earlier post give me pause. You have coefficients for degree 1. These correspond to a translation of the geoid; if the geopotential is computed around the centre of mass, they are 0; Principia makes the assumption that they are, and ignores them. However, in your case, they are not only nonzero, but they are fairly large (about the same order of magnitude as, say, C22); this indicates that, if your calculations are correct, you are computing the spherical harmonics with respect to something fairly far from the centre. Note that Principia also ignores degree 2, order 1, as, for bodies whose axis of figure is close to the axis of rotation (which is most often the case), these coefficients are tiny. This may not be the case for arbitrary planets. Note that if it is not the case, it is possible that the rotation of the planet would be chaotic.
  6. This sounds cool; I would be interested in knowing how you generate that; computing the gravitational field from the shape of the body is not trivial, even making simplifying assumptions about internal structure. The best practice is to put the files of your mod in the directory of your mod (so GameData\NameOfYourMod\whatever.cfg). The @ thing is ModuleManager syntax. This means that you need to have ModuleManager (it can be redistributed with your mod, most mods that patch configs do that); you need to look at the ModuleManager documentation to see what you want to do with that syntax (if I recall correctly, @principia_gravity_model:FOR[NameOfYourMod] should do the job, but I am no ModuleManager expert). The specification for these files can be found in https://github.com/mockingbirdnest/Principia/wiki/Principia-configuration-files (using the terminology from that page, you want sufficient principia_gravity_model configurations for the relevant bodies), which means that the gravitational_parameter and reference_radius are not required (the in-game gravitational parameter and radius will be used if they are omitted). We support up to degree and order 30; we have found that this was needed to accurately capture the behaviour of orbits around the Moon (the Moon is very lumpy). For the Earth, we only go to degree and order 10. You should probably inspect the coefficients that you generate and handwave a cutoff from that (if the coefficients remain very large at high degrees, go to high degrees, otherwise ignore higher degrees). Note that we do have a cutoff in-game, so the higher degrees have more a limited range (and thus should only incur a computational cost where they matter). Again, this looks cool.
  7. This would have no effect: Principia creates the ephemeris (and the celestial bodies) when a new game is started, and never reads the configurations again.
  8. @Delay, that would just be the osculating inclination at the node (assuming that we are in the body-centred inertial frame, otherwise it is a largely meaningless angle). As previously discussed, osculating elements are not that useful when it comes to describing your orbit, because they vary wildly along the orbit; arguably the inclination is less affected than the other elements, but I would rather have a consistent approach when it comes to displaying this information, and keep the stuff on the nodes about strictly instantaneous properties at that node (apsis distances, velocities, etc), and display global properties of the orbit (including mean elements) separately.
  9. There is currently nothing that will show a good corresponding two-body orbit. At any time, the game is made to believe that the vessel is following its osculating orbit, so your usual orbital element displays (Kerbal engineer, MechJeb, etc.) will show the osculating elements, which may help; however, the osculating elements are subject to short-period variations that can be misleading as to the true nature of the orbit (in particular the osculating eccentricity and argument of periapsis of near-circular orbits will be wildly inaccurate, to the point of being entirely useless: for TOPEX/Poseidon, the osculating eccentricity ranges between 0.000'2 and 0.001'2, whereas the proper (“mean”) eccentricity is less than 0.000'11.). As @pleroy previously mentioned, I am working on something (the Ferrari change log mentions the ground track recurrence analysis), but this is nontrivial.
  10. For the new moon (lunation number 242), the new release (Ferrari) is out. Support for KSP 1.7.3 has been added. Some bugs reported by @scimas 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 腾讯微云.
  11. 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 腾讯微云.
  12. 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 腾讯微云.
  13. 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.
  14. 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.
  15. 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).
  16. 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.
  17. Hm, this means we will have to update the Principia TRAPPIST-1 patch. Opened #2129 to track this.
  18. 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).
  19. 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).
  20. 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).
  21. 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.
  22. 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.
  23. 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).
  24. @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 -->
  25. @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).
×
×
  • Create New...