eggrobin
-
Posts
504 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by eggrobin
-
-
1 hour ago, hanhan658 said:
That page doesn't answer any of those questions at all
By seeking to change the tilt of planets, you enter the realm of making your own mods, not unlike, e.g., changing other characteristics of planets with Kopernicus.
The page linked by @pleroy documents the Principia-specific aspects of that. It is not intended as a general introduction to KSP configuration modding.
It would be a good idea for you to become acquainted with that, and with ModuleManager patches in particular; see for instance @sarbian's ModuleManager handbook.
-
5 hours ago, Eriksonn said:
the new principia version doesnt work for me...
The Principia DLL failed to load. Dependencies, namely the Microsoft Visual C++ 2015-2019 Redistributable (x64) - 14.22.27821, were not found.
what should i do about this?
As documented in the FAQ, you should install the dependency mentioned in the error message.
-
7 minutes ago, Delay said:
What is the length of the prediction determined by?
@Delay same duration as the prediction of the active vessel, if any.
In the absence of an active vessel, i.e., in the tracking station with no vessel selected, no prediction is shown, only a history going back to the beginning of the game (or less, depending on the history length setting).
-
For the new moon (lunation number 246), the new release (פרנקל) is out.
- Principia now plots the trajectories of celestial bodies. This closes an ancient feature request (#942, March 2016), and builds up on a lot of intervening work; in particular, this is based on the method for trajectory plotting introduced for vessels in Чебышёв (August 2017).
- The history length setting now hides the history instead of forgetting it; this means that you can shorten histories when they are visually distracting, while retaining the ability to bring them back when you want an overview of your mission. It also uses the same duration format and selector used elsewhere in the Principia UI instead of seconds in scientific notation.
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 腾讯微云.
-
On 11/9/2019 at 8:08 PM, AloE said:
Wow, Io's 2032 position is so much better now than back in the 1.3.1 versions...is that improvement due to the modeling of Jupiter's geopotential?
I think so; going from J2-only to J2 through J12 (in del Ferro) reduced the error on the orbit of Io from 2″.1 per revolution to 0″.077 per revolution.
What does the transit look like in-game in the 1.3.1 versions (I think Fatou is the last one of those)? It would be fun to have a visualization of the improvement.
-
For the new moon (lunation number 245), the new release (Fourier) is out.
- Two crashes involving flight plan edition (one reported by @Neph) 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 腾讯微云
-
On 9/29/2019 at 12:37 AM, eggrobin said:
The tool is fairly complex; documentation will be provided soon.
The documentation is here: https://github.com/mockingbirdnest/Principia/wiki/Orbit-analysis.
It includes some background information on frozen orbits and ground track recurrence, as well as many examples based on real-life satellites to illustrate the underlying concepts.
-
For the new moon (lunation number 244), the new release (Fibonacci) is out.
-
An orbit analysis tool has been added which computes mean elements and orbit recurrence properties. This has been in the works since February; more features will be added at a later date, e.g., mean solar times of ascending nodes (for controlling sun-synchronicity). See below for a screenshot of the orbit analysis tool in action on a Молния orbit. The tool is fairly complex; documentation will be provided soon.
- A crash reported by @Delay has been fixed.
- A dependency issue that would prevent Principia from starting 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 腾讯微云
-
An orbit analysis tool has been added which computes mean elements and orbit recurrence properties. This has been in the works since February; more features will be added at a later date, e.g., mean solar times of ascending nodes (for controlling sun-synchronicity). See below for a screenshot of the orbit analysis tool in action on a Молния orbit. The tool is fairly complex; documentation will be provided soon.
-
On 9/11/2019 at 2:18 AM, gsantos9489 said:
I'm reading the link you sent me, but can't found which property into the configuration file we should use to set the Axial Tilt Angle.
Do you happen to know which property has to be set in this particular case?
A single angle is not enough to describe how a planet is oriented (this requires three degrees of freedom), nor even how its axis is oriented (two degrees of freedom).
You may find it useful to read the section on the semantics of the quantities used for body rotation, and to look at the figure referenced therein, to understand how to properly describe the orientation of a planet.
The section on the principia_gravity_model configuration will then tell you how to specify that information in the configuration file.
-
For the new moon (lunation number 243), the new release (del Ferro) is out.
- Higher degree and order gravity models have been added for Mercury, Venus, Mars, Jupiter, Saturn, Uranus, and Neptune; satellites of these planets will now have more realistic motion (this change only takes effect on new saves)
- Some bugs reported by @Sir Mortimer, @scimas, and @Kobymaru 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 腾讯微云.
-
40 minutes ago, Jim DiGriz said:
Would need to supply a `Vector3d force_function(double time, Vector3d pos, Vector3d vel)` (so passing a function handle rather than Vector3d forcevector) at a minimum so that the supplied force would be a function of time and could be a function of the dynamics. Because you need to supply more than just the force on the next physics tick, and you want to do more than supply a constant force for all time of the simulation -- you want to be able to say things like "apply a force that acts opposite the velocity vector".
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:
On 12/17/2017 at 11:10 PM, pleroy said:code would need to be executed inside the inner loop of the integrator. The time budget there is less than 100 ns (that's nanoseconds) so there is no way to do a kRPC call, or even a P/Invoke cross-language call (especially with the complex serialization involved).
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. -
11 hours ago, CrickCrickBang said:
Can't wait to try this out in my 3.2x scale game. I also use Orital Decay so I'm wondering if someone knows what the outcome of the two together will be? I'm willing to test it but was wondering if anyone has experience with the two yet. v1.7.1
Principia and Orbital Decay (or any other mod that alters the orbits) are fundamentally incompatible.
On 8/19/2016 at 2:02 PM, eggrobin said:I don't think this will work with any mod that alters the orbits (the changes will simply be ignored, since we persist our own Cartesian state and simply force the game to put things in the right place by setting the orbits).
More importantly though, it seems that @Whitecat106's mod and ours have roughly the same goals, so you probably don't want to have both installed: @Whitecat106 appears to be working on multibody and extended/inhomogeneous body gravitation, and we have atmospheric decay as one of our (rather long-term) aims.
@Whitecat106, you might want to put this mod in your list of known incompatibilities, since we're likely to attract the same users.
@Papa_Joe, since you are the new maintainer of Orbital Decay, please note the above; it may be useful to document this incompatibility.
5 hours ago, FreeThinker said:Intresting but what if you tried to change the orbit of a vessel to simulate persistant thrust. [...] How to achieve the same with Principia installed?
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:
On 12/17/2017 at 8:32 PM, Jim DiGriz said:You're not suggesting anything that isn't obvious. Orbital decay, stationkeeping and low-thrusting-spacecraft-on-rails are all mod ideas that have occurred to everyone that has used Principia. The mod authors are a busy with issues more directly related to the N-body physics simulation though.
[...] The problem is more that you need a mod which looks at the actual principia orbit (not the [osculating] orbit) and applies a perturbation to the orbit and drains some RCS, and can handle that process through timewarping (which is why decay, stationkeeping and low-thrust probably all should go into the same mod) [...].
On 12/17/2017 at 11:10 PM, pleroy said:@Jim DiGriz has actually a very good point. For things like station-keeping and orbital decay, code would need to be executed inside the inner loop of the integrator. The time budget there is less than 100 ns (that's nanoseconds) so there is no way to do a kRPC call, or even a P/Invoke cross-language call (especially with the complex serialization involved). Everything would need to be done in C++ using the Principia abstractions and linked into the Principia DLL. When you do this, well, you are just beefing up Principia and not interfacing with another mod. I am not saying that we won't be doing this one day, but not using 3rd party mods.
The interested reader might want to look at the PRs that fix #1628 in the new Christoffel release. It took me many pull requests and close to three weeks to just figure out if a vessel is inside a celestial during the force computation and bring that information up to KSP.
-
@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.
-
Quote
@eggrobin Hmm, so you are saying that having the geoid be equal to the terrain height is a bad approximation for a constant-density body?
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.
-
@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.
On 8/3/2019 at 2:36 PM, Eriksonn said:principia_gravity_model { Body { Name = Minmus geopotential_row { degree = 1 geopotential_column { order = 0 cos = 2.01267793181124960E-004 sin = 0.00000000000000000E+000 } geopotential_column { order = 1 cos = -1.67248927462036320E-003 sin = 2.96599647369928530E-003 } } geopotential_row { degree = 2 geopotential_column { order = 0 cos = 8.05394019210287260E-003 sin = 0.00000000000000000E+000 } geopotential_column { order = 1 cos = -2.80339441217786760E-003 sin = 1.38156354030291020E-003 } geopotential_column { order = 2 cos = -5.70133104974222470E-003 sin = 3.12729158537247910E-003 } } ...up to degree 10...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.
-
On 8/3/2019 at 2:36 PM, Eriksonn said:
@eggrobin Over the past few days i have been making a mini mod thing for automatically generating the spherical harmonics needed to allow some of the stock bodies to have geopotentials.
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.
QuoteOne is that i dont know where to put this new file(i am calling it gravity_model_extension)
The best practice is to put the files of your mod in the directory of your mod (so GameData\NameOfYourMod\whatever.cfg).
Quotei have tried adding an @ to the of start principia_gravity_model, but that didnt work either
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).
QuoteTwo is does my file contain enough information as is or do i need more? (as i saw that the gravity_model file contained lots of other information like gravitational_parameter and reference_radius. Do i need that too, or am i good with what i have?)
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_modelconfigurations 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).On 8/7/2019 at 11:19 PM, Eriksonn said:It generates up to degree 10, wich i think should be good enough, and as i am doing it for every body(everything is the default, although a whitelist is also an option) i dont want to have too high degree as i am not sure how performace intensive this operation is(i havent gotten any more lag than usual on max warp using this, so i think it is fine).
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).
QuoteIn this image i am orbiting in a circular 15km orbit around minmus, but due to the hills and flats, the orbit gets destabelized, and eventually crashes into minmus.
Here is the same orbit from the side, to show that it also affects inclination.
It even works with modded planets/moons. This one has a very oblate shape, leading to a very high precession rate of about 40 degrees per orbit.
Again, this looks cool.
-
28 minutes ago, Delay said:
I couldn't just add that to an already running career, right? The orbits would be very messed up.
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.
-
@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.
-
20 minutes ago, Riven said:
Anyways, I did a cursory search of this thread for a way to display predicted orbital parameters such as inclination, and I couldn't find anything immediately. Should I pull out an orbital dynamics textbook to hand calculate approximate plane change burns in two-body? I'm willing to do it to brush up on orbital dynamics, but am I overlooking an obvious setting or option that will display a patched conic approximation of a maneuver as in stock to check my work (or if I become lazy which is more likely)?
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,
On 7/6/2019 at 2:01 PM, pleroy said:- The orbit needs to be characterized and its mean properties determined. This is not easy in an N-body universe because there is a zoo of interesting orbits that must be considered, and therefore just finding an approximate ellipse requires care. @eggrobin has been spending the last 5-6 months looking into this specifically for perturbed Keplerian orbits, e.g. LEO; he read a treatise on the topic and numerous research papers, and is just starting to reach the point where he has an idea how to do that in the game.
I am working on something (the Ferrari change log mentions the ground track recurrence analysis), but this is nontrivial.
-
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 腾讯微云.
-
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 腾讯微云.
-
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 腾讯微云.
-
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:
-
1 hour ago, N9vaivie said:
Not sure if this has ever been noticed before, but I think I have discovered a strange glitch with Principia concerning gravity on aircraft. It appears to glue them to the ground?
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.
[WIP][1.8.1, 1.9.1, 1.10.1, 1.11.0–2, 1.12.2–5] Principia—version Καραθεοδωρή, released 2024-04-08—n-Body and Extended Body Gravitation
in KSP1 Mod Development
Posted
For the new moon (lunation number 247), the new release (Fréchet) is out.
See the change log for more details; note in particular the known issue with map view camera rotation when showing the menu.
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 腾讯微云.