eggrobin
-
Posts
504 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by eggrobin
-
-
4 minutes ago, Einstein_Cross_X1 said:
when trying to build for 1.7.0.
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.
-
6 minutes ago, GregroxMun said:
- Renamed SLIPPIST-1b "Beta" to "Bravo." Dunno why I thought the NATO alphabet used Beta for "B", but a few months ago a friend of mine who's a pilot notified me that it should be Bravo, and she's right. Frankly it's more fitting like this, because if you land and launch from there... bravo.
Hm, this means we will have to update the Principia TRAPPIST-1 patch.
Opened #2129 to track this.
-
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).
-
On 3/25/2019 at 8:42 PM, Einstein_Cross_X1 said:
I've only been able to make progress through trial and error and that has been incredibly slow and unpredictable so far.
QuoteIt's tough balancing collision avoidance between celestial bodies while still making planets reachable with stock parts within a given system. Thank you for the continued support of this mod!
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.
QuoteDo you have any recommendations about more efficient ways to simulate the planetary systems in order to predict collisions more reliably and thus create patches faster and more accurately?
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).
-
1 hour ago, RocketSquid said:
For some reason in KRASH simulations this mod seems to move suborbital bodies differently than it should, resulting in them being effectively dragged along the ground.
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),
QuoteIf you are running RemoteTech, be sure that ALL your antennas are set to start retracted,
otherwise they will be ripped off during the teleportation process.and an attribution to HyperEdit.
QuotePortions taken from Hyperedit by khyperia
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).
-
7 hours ago, flart said:
I was thinking you talking that SUA shows wrong numbers with Pricipia, but Principia has its own Navball panel for the Orbit mode.
SUA Surface mode works ok, and I am not sure what happens with the Target mode. Even if I win the battle for Navball Panel, you still lose Pricipia's short mode-titles (KCI, KCKF, etc) and numbers for Ap/Pe will be same as KER, but not Principia's Predicted Next Ap/Pe
I mean, even if the Principia pass me API for disabling its Navball panel and for getting a current title ("KCI" etc) then Ap/Pe and maybe a speed still will be not correct,
and passing the next Ap/Pe to Flight mode looks too CPU wasteful.
@eggrobin any thoughts there?
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.
-
Quote
A reply that "this may be done some day" or "no, I really don't care about this" would have been nice.
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.
QuoteI realise that I have launched at the wrong time for interplanetary transfer - okay my bad. Well I planned for this; the tanks are cryogenic; it can sit in orbit for a month until its time to go.
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.
QuoteNow, I need to crank the prediction up to like 64000 *minimum* in order to plot a course that does not leave LEO for a month. I have tried turning the resolution down; the prediction just turns rubbish - no dice.
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.
-
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).
-
@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 --> -
@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).
-
2 minutes ago, Delay said:
Okay, so here is error.log
Thanks; however, that is only one of the two files we need.
From the relevant section of the FAQ (https://github.com/mockingbirdnest/Principia/wiki/Installing,-reporting-bugs,-and-frequently-asked-questions#have-a-crash-folder-ie-a-folder-whose-name-is-the-date-in-your-ksp-install-directory):
QuoteReporting bugs
Have a crash folder, i.e., a folder whose name is the date in your KSP install directory
Put the contents of the
error.logon gist as well as the contents of theoutput_log.txt(a copy may exist in the crash folder, otherwise if the game has not been restarted since the crash it is found at a location is documented on the KSP fora).We need the output_log to figure out where this happened, as it contains the stacktrace.
Since you tried reproducing the bug, the output_log in the usual location was overwritten, but there should be a copy in the crash folder.
-
43 minutes ago, Delay said:
Perhaps Principia and Trajectories are mutually incompatible?
They are not compatible in the sense that they are not aware of each other, which means that both will draw in map view (possibly in different reference frames), making map view a bit of a mess, and Trajectories will show an inaccurate prediction.
However, beyond that they should not interact with each other, and certainly not cause a crash; your crash is likely unrelated to having Trajectories (or any other mod); it is a Principia bug.
QuoteShould I post the required files
Yes, otherwise we cannot figure out what happened (if you have a crash dump, give us that too).
-
17 minutes ago, Eriksonn said:
I have found a possible bug. The normal/antinormal markers on the navball are flipped. notice how in the image i am pointing down but the navball shows "up"
Note that normal and antinormal in stock, (or, with Principia, binormal and negative binormal) do not mean up and down, they are relative to the (oriented) plane of the orbit.
It seems your orbit around Minmus is retrograde; this would have the effect depicted in your screenshot.
-
2019-02-04
For the new moon (lunation number 236), the new release (Εὐκλείδης) is out.Support for KSP 1.6.1 has been added.
This release fixes a long-standing issue (reported in November 2017 by @Agustin, in June 2018 on GitHub as #1868 by @scimas, and by @Delay in January 2018) where, under some circumstances, the SAS would not point the ship towards the markers (it would point the ship towards the position that the markers would have in stock instead).
It also fixes a relatively rare issue involving fragments of vessels getting close to the centre of a celestial on reentry (#2056).
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).
-
On 1/12/2019 at 11:05 PM, Delay said:
I think this error is present at all times
Unfortunately, this is not the case; in all my attempts to reproduce the issue, the SAS correctly pointed to the chosen marker as I changed the plotting frame (and thus the orientation of the markers).
I definitely remember encountering it myself, but I do not know how to reliably reproduce it; the steps given by @scimas in #1868 do not appear to work for me.
Do you have a save with no mods other than Principia and for which you have deterministic reproduction steps for this issue?
-
54 minutes ago, Delay said:
The markers are perfectly fine.
I manually executed the burn, aligned with both the retrograde marker and the maneuver node marker. As you can see, the burn was done correctly. It's the direction SAS aims at that's incorrect.
Yes, this is what issue #1868 is about, @pleroy was a bit confused.
-
2019-01-06
For the new moon (lunation number 235, partial eclipse), the new release (Εὔδοξος) is out.-
We have added an enhanced selenopotential in RSS, complete to degree and order 30; this means that the moon now has mascons, making some low lunar orbits unstable. Note that you will only get the new selenopotential when making a new save.
As a concrete example, consider this screenshot of a lunar orbit, whose periapsis decreases by 3400 m over the course of 18 orbits because of the irregularities of the Moon's gravitational field (another dozen orbits later, the spacecraft collides with the Moon, between craters Spencer Jones and Spencer Jones W).
- Saves are now encoded in base64 instead of hexadecimal, making them smaller and faster to load.
-
We have rerun the TRAPPIST-1 optimization, this time with a small enough integration time step allowing us to accurately model the dynamics of the system. Thanks to @AloE for spotting the incorrectly-timed transits.
The resulting system has residuals similar to those reported by Grimm et al., with χ² = 358.79 vs. χ² = 342.29 in the paper.
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, and for 1.3.1. Make sure you download the right one (if you don't, the game will crash on load).
-
We have added an enhanced selenopotential in RSS, complete to degree and order 30; this means that the moon now has mascons, making some low lunar orbits unstable. Note that you will only get the new selenopotential when making a new save.
-
Another serious issue was found with the Erdős release (#2021, adding a manœuvre to a flight plan would cause a crash, effectively rendering flight planning unusable), so we have hotfixed it again; if you downloaded Erdős prior to this post, please download it anew (the version string in the Principia UI should say 3e2334a95bcfc6869b5464ecda5ae48b5412dba0, not
773e6fbad7f9fb59790de49fde48650d9451a278orf772b71b057b64f978bbabdc95ebea2095f27018).We apologize for the inconvenience.
-
The NaN PotatoRoids have been addressed, Erdős is back. If you downloaded it before the above note was posted, you should redownload it to avoid running into crashes when NaN PotatoRoids appear in the gravitational field of an extended body (the version string in the Principia UI should say 773e6fbad7f9fb59790de49fde48650d9451a278, not f772b71b057b64f978bbabdc95ebea2095f27018).
-
Note: Erdős is not quite available yet as we are scrambling to address a last-minute issue involving NaN PotatoRoids.
-
2018-12-07
For the new moon (lunation number 234), the new release (Erdős) is out.
- Support for realistic geopotential modeling at arbitrary degrees is finally available, with a 10th-degree model of the Earth geopotential in RealSolarSystem; more advanced modelling for other bodies (Moon, Mars, etc.) will be added in future versions.
- #1955, a performance issue on macOS (continuation of #1908), was resolved by using a different synchronization library.
- The issue reported by @AloE above (#1999) has been temporarily addressed by using the same integrator configuration that was used for the optimization. We will redo the optimization with a more appropriate configuration in a future version, as this issue likely indicates that the integrator had not quite converged.
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, and for 1.3.1. Make sure you download the right one (if you don't, the game will crash on load).
-
2018-11-07
For the new moon (lunation number 233), the new release (Ἐρατοσθένης) is out.
Support for KSP 1.5.1 has been added.
We working on extending geopotential models beyonds oblateness (mascons etc.), but that is not yet ready; 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, and for 1.3.1. Make sure you download the right one (if you don't, the game will crash on load).
-
10 hours ago, Dagger said:
Yeah also the TiltX and TiltZ should be relative to the ecliptic and at this moment they are relative to the unity "world" axis so they must be worked on... Hopefully I will get into this once I manage to fix the bug described below
Well, α and δ are relative to the celestial equator, not the ecliptic; the ecliptic is rarely used in modern astronomy, see Capitaine and Soffel (2015), On the definition and use of the ecliptic in modern astronomy, arXiv:1501.05534 [astro-ph.EP].
You should probably follow the usual astronomical convention (right ascension and declination of pole), to make it easy to supply tilt for real-world bodies.
Regarding your general vessel rotation woes, it seems that below the inverse rotation threshold, you are doing exactly what we do (tilt the universe around the main body). Since you don't actually own the physics of everything, it means you must chase down the various bits of the universe to tilt them (which seems to be the bug at hand), whereas our approach (we own the orbit of everything, whether it is packed or not, as soon as it leaves the ground) makes it easier to just tilt the whole universe at once.
Both variants however will run into the issue of the vessels themselves being rotated, even if their orbits are fine (Principia issue #1639), so to answer @Phineas Freak, this mod should have the same issue, just at the inverse rotation threshold instead of the SOI boundary.
@Phineas Freak: note that we do plan to do something about #1639 eventually; it is a bit tricky, but with the Principia approach of keeping an authoritative record of the position of everything, it should be feasible, see
At the moment we are working on extended geopotential models (mascons, etc.) however.
-
On 10/26/2018 at 1:27 PM, Dagger said:
I'm still not satisfied with the "TILTX" and "TILTZ" names... There must be some more technical name...
The standard astronomical convention is to use the right ascension and declination of pole (α0 and δ0 in figure 1 of https://astropedia.astrogeology.usgs.gov/download/Docs/WGCCRE/WGCCRE2015reprint.pdf).
They probably don't map directly to the numbers you use: (90° - α0, 90° - δ0, W) are ZXZ Euler angles, i.e., the rotation of 90° - α0 is about the celestial north Z, the rotation of 90° - δ0 is about the rotated X axis (lying on the celestial equator, 90° - α0 from the origin of right ascension), and the reference system used is right-handed (with Z being celestial north).
From a cursory reading of your code, you seem to be applying those rotations around X and Z in left-handed, Y-up reference systems instead (it's not clear to me which one is applied first when starting from the celestial frame), so that the transformation between (TILTX, TILTZ) and (α0, δ0) would be nontrivial.
[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 239), the new release (Fáry) is out.
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).