[WIP][1.8.1, 1.9.1, 1.10.1, 1.11.0–2, 1.12.2–5] Principia—version ‎‎Kronecker, released 2024-11-01—n-Body and Extended Body Gravitation

[Al2Me6]

12 hours ago, AloE said:

So if you wanted to experience decay drag starting around 160km for example, you could make your own revised custom atm model

And how will help that anything? Atmospheric drag isn't applied during timewarp or while the vessel is unloaded. Sure, it works for a few more kilometers while you're at the vessel, but you're just moving the problem elsewhere.

[jd284]

On 8/25/2021 at 9:48 PM, jd284 said:

It seems that when planning a maneuver with with significant off-tangent components, the maneuver node on the navball is not always placed correctly. [...]

Well, I think I now figured it out, I was intuitively expecting the plane change burn to be "inertially fixed" like all burns in stock KSP, but Principia expected me to follow the maneuver node marker that moves across the navball as the tangent vector rotates. The explanation of that setting could perhaps use some clarification, it seems to imply that it only matters for spin-stabilized spacecraft, not that if you don't set it you actively have to rotate the craft while burning to achieve the planned flight path.

So if I instead "manually" pointed in the direction that would've been indicated for an inertially fixed burn (before realizing that's what I was doing), I got the right flight path.

However, I still don't understand why it's not set by default, it seems like rotating the spacecraft during a burn by 30 to 60 degrees (as happens with major plane changes) uses substantially more delta-V than just burning in an inertially fixed way. Also, following the moving node around the navball makes the burn quite imprecise to execute. You have to start the rotation before the burn and make it pass through the marker just as the burn is supposed to start, or start rotating hard when you start the burn and try to control the rotation rate throughout.

Is there any advantage to non-inertially-fixed burns? I can see that it might help with extremely long-duration burns close to the atmosphere/surface, where initially the periapse might otherwise drop dangerously low, but in general it seems to offer far more disadvantages?

[eggrobin]

On 9/11/2021 at 1:44 PM, AloE said:

[…] you could make your own revised custom atm model […]

you certainly could, but as @Al2Me6 points out,

On 9/12/2021 at 2:25 AM, Al2Me6 said:

And how will help that anything? Atmospheric drag isn't applied during timewarp or while the vessel is unloaded. Sure, it works for a few more kilometers while you're at the vessel, but you're just moving the problem elsewhere.

it would be profoundly pointless; unless you want to watch your orbit decay over the course of a month in real time (and doing nothing else in the meantime), entirely new mechanisms would be needed to implement long-term drag.

In particular one would need, deep inside the works of Principia, to change the numerical methods to accommodate for long-term integration with velocity-dependent forces (and major restructuring would be needed so the orientation is available in the right place, since those forces are also orientation-dependent).

In any case, this (or even solar radiation pressure which raises similar considerations) is not particularly interesting from a gameplay standpoint unless the question of automated stationkeeping is also resolved (a problem which has already been mentioned here, and is even messier to even approach). It would artificially make many real-life mission profiles infeasible, since in real life you can happily regularly stationkeep such orbits.

19 hours ago, jd284 said:

it seems like rotating the spacecraft during a burn by 30 to 60 degrees (as happens with major plane changes) uses substantially more delta-V than just burning in an inertially fixed way.

This is the opposite of what is true.

Quote

Is there any advantage to non-inertially-fixed burns?

Indeed, these burns that track the Frenet frame are more efficient.

It can readily be seen that for a burn that aims to solely change the inclination (without affecting the semimajor axis), no net work should be done, since the orbital energy must not change. Any work done, that is, any thrust provided along the direction of motion, must be undone, and is thus wasted; thrusting orthogonally to the direction of motion is the only way to not waste energy in such a way. Conversely for a burn that does aim to change the orbital energy, all thrust should result in work in order to maximize that change, and thus the thrust should always be directed in the direction of motion.

[jd284]

1 hour ago, eggrobin said:

Indeed, these burns that track the Frenet frame are more efficient.

It can readily be seen that for a burn that aims to solely change the inclination (without affecting the semimajor axis), no net work should be done, since the orbital energy must not change. Any work done, that is, any thrust provided along the direction of motion, must be undone, and is thus wasted; thrusting orthogonally to the direction of motion is the only way to not waste energy in such a way. Conversely for a burn that does aim to change the orbital energy, all thrust should result in work in order to maximize that change, and thus the thrust should always be directed in the direction of motion.

Thanks for the explanation, and it seems I can still learn something new about orbital mechanics each day.

However, at least for my flight plan that doesn't seem to be true. But it wasn't a pure plane change, I had to burn slightly +tangent because of the lunar masscons dragging my highly eccentric orbit well into the surface otherwise, which probably changes things. So when I reloaded the game at that point and tried to plan the same burn (ending at the same 13 km perilune and 102.1° inclination) in inertial mode it cost slightly less delta-V:

Standard: 13.519 tangent, -149.981 binormal, 150.589 m/s total

Inertial: -55.444 tangent, -134.587 binormal, 145.560 m/s total, about 5 m/s less despite the large anti-tangent component.

I got nearly the same Earth perigee 3 days later (only 150 m lower) so it really was an equivalent burn. And in addition to the 5 m/s saved by the inertial burn itself, I saved another 19 m/s on corrections that I had to do with the difficult-to-execute-properly rotating burn, ending up with 105 m/s left over instead of 81 m/s once on the final Earth return trajectory.

So I think it may still be worth considering to make inertial burns the default, or at least a global setting that defaults to this, to avoid Principia beginners such as myself falling into the trap of expecting inertial burns after being trained to do it that way during years of KSP maneuvers. Either way I'll try to update the wiki docs on this toggle to make it clearer what it means.

[AloE]

On 9/12/2021 at 2:25 AM, Al2Me6 said:

Sure, it works for a few more kilometers while you're at the vessel, but you're just moving the problem elsewhere.

Yes, exactly, with the specific point to simply demarcate that space as different for a particular specific scenario.  I agree with you & egg as right on target especially for smoothness of career game play.  Thank you for clarifying & emphasizing the setup that is indeed best for users.

In the case at hand, at the time I saw the post, I was musing about cubesats & microsats.  Specifically the JAXA SLATS mission as a scenario discussion project to work on this upcoming foggy winter period in the Swiss Seeland...In one of my RSS configs I have included a very thin atm to ~250k to demarcate, for scenario purposes, that region of space as significantly subject to other dynamics.  Dynamics which, as egg describes, make little sense to model in KSP.  That 250km config works well (yes, I deliberately wanted, for this particular case, those normally annoying implications egg describes) for my particular SLATS scenario in KSP.  It helps experientially emphasize some key points I plan to discuss (with my son in this particular case who finds microsats interesting & is the one who dragged me into KSP when he was age 3 & to my surprise has been unusually interested in mathematics & aero-astro since.)  Thus I let a special use case sneak into my posting.  Thanks for keeping things clarified.  Some links with interesting info about SLATS for anyone interested:

SLATS

additional interesting SLATS links:  https://global.jaxa.jp/press/2019/03/20190318a.html https://www.eoportal.org/web/eoportal/satellite-missions/content/-/article/slats https://www.guinnessworldrecords.com/world-records/592663-lowest-altitude-earth-observation-satellite-in-orbit

Edited June 22, 2022 by AloE
revise links

[Hoozemans]

Hi! New to Principia, fumbling my way through whatever tutorials are out there. 

Question I didn't yet see any answers to: how come my navball is so fuzzy?

Playing KSP 1.12.2 for MacOS, most recent Principia Haar release.

Thanks!

https://imgur.com/gallery/vTHKyY7

[R-T-B]

1 hour ago, Hoozemans said:

Hi! New to Principia, fumbling my way through whatever tutorials are out there. 

Question I didn't yet see any answers to: how come my navball is so fuzzy?

Playing KSP 1.12.2 for MacOS, most recent Principia Haar release.

Thanks!

https://imgur.com/gallery/vTHKyY7

I honestly can't say I've ever seen that.  That is really weird.

[Lisias]

On 9/29/2021 at 1:59 PM, Hoozemans said:

Hi! New to Principia, fumbling my way through whatever tutorials are out there. 

Question I didn't yet see any answers to: how come my navball is so fuzzy?

Playing KSP 1.12.2 for MacOS, most recent Principia Haar release.

Thanks!

https://imgur.com/gallery/vTHKyY7

Texture Quality. You can adjust it on Main Menu / Settings  / Graphics . You can set it to Full Res, Half Res, Quarter Res and Eight Res.

It essentially lower the resolution of the meshes used on the game,  allowing it to run  on modest GPU rigs,  as our Macs.

Problem is that KSP applies the stunt indiscriminately! EVERTYTHING is downscaled, including widgets and small images for the UI  - if you select Eight Res, you will barely be able to tell if a CheckBox is checked or not.

There was a hack in the past that alleviated the problem by brute force reloading some images without the MIPMAP setting. I can't remember it right now,  but I will edit this post with it once I recalled it - if someone else didn't did that first!

— — POST EDIT — — 

@Hoozemans, I rememebered! It's Unblur! But I don't know if it still works on KSP >= 1.8, I will give this a try later...

 

 

Edited October 2, 2021 by Lisias
POST EDIT

[eggrobin]

On 9/29/2021 at 6:59 PM, Hoozemans said:

how come my navball is so fuzzy?

I remember encountering this issue a long time ago; the texture quality setting was indeed to blame.

[eggrobin]

For the new moon (lunation number 269), the new release (Hadamard) is out.

• Some bugs reported by @Bellabong and @lpgagnon have been fixed.
• The duration parser is a little more lenient.

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 腾讯微云.

[eggrobin]

On 10/5/2021 at 10:39 PM, eggrobin said:

• The duration parser is a little more lenient.

A significant issue was found with this, which should have been a usability improvement in Hadamard (#3144, it was impossible to type in the flight plan duration and flight plan initial time fields), so we have hotfixed the release; if you downloaded Hadamard prior to this post, please download it anew (the version string in the Principia UI should say 2021100611-Hadamard-0-g5a4626303afea27800d7ef283ce66c54f98be3c8, not 2021100611-Hadamard-0-g541a52fbd877e03e589f025c16d3b0e7cb02e590).

We apologize for the inconvenience.

[Alex415]

@eggrobinHi. Developing an addon for ksp, and wanted to know, is there any way to get positions and velocities of CBs and vessels in some known reference frame(i.e. J2000 or M50) using either KSP's stock API or Principia's external addon API? Or maybe convert from Unity's world reference frame using some kind of reference vector/rotation? In stock KSP one can use Planetarium.right, but it doesn't seem to work with Principia. From a quick look at ksp_plugin_adapter I noticed you are fiddling with Planetarium.inverseRotAngle, but I couldn't figure out much.

[eggrobin]

For the new moon (lunation number 270), the new release (Halley) is out.

Nothing new this time; we have been working on changes to the internal representation of vessel trajectories, but this is not ready yet.

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 腾讯微云.

[Makrom]

Guys...do we really need all this mess for to do a simple hohmann transfer? maybe some bodies can be filtered out? maybe that can help with avoid overloading the pc?

 

[eggrobin]

If you are trying to find a transfer rather than tune the resulting flyby (which I suppose is the case here, given how far you are zoomed out and given that the closest approach to Mars seems to be about three quarters of an astronomical unit away, you are looking at the wrong reference frame, which is sure to result in a mess. What you want is MSO or perhaps HCI.

See the hovertexts on the selector buttons, which explain what the frames are for.

Once you actually have a transfer and are tuning your flyby (or capture) to the scale of a few kilometres, rather than astronomical units, you should zoom in on mars; at that point MCI may be appropriate (though MSO will still do the job, and will tell you where the night side will be). If you are planning to land directly, MCMF should be used to see where you land.

Edited November 15, 2021 by eggrobin

[pleroy]

Also note that your flight plan is 16234 days long, which is nearly 44.5 years.  Among other things, we are computing the state of the solar system 44.5 years in the future, which is not going to help with performance.  Oh, and the computing tolerance of the flight plan is 1 m, which is tiny and forcing us to do more precise integrations.  All these setting are wasteful, unless you really mean to nail a landing with an accuracy of 1 metre 44.5 years in the future.

[Makrom]

27 minutes ago, pleroy said:

Also note that your flight plan is 16234 days long, which is nearly 44.5 years.  Among other things, we are computing the state of the solar system 44.5 years in the future, which is not going to help with performance.  Oh, and the computing tolerance of the flight plan is 1 m, which is tiny and forcing us to do more precise integrations.  All these setting are wasteful, unless you really mean to nail a landing with an accuracy of 1 metre 44.5 years in the future.

Nah that was a consequence, the Pc becames so slow that it did a big step from a  little one giving that unholy numbers, then I take the screenshot.....

1 hour ago, eggrobin said:

If you are trying to find a transfer rather than tune the resulting flyby (which I suppose is the case here, given how far you are zoomed out and given that the closest approach to Mars seems to be about three quarters of an astronomical unit away, you are looking at the wrong reference frame, which is sure to result in a mess. What you want is MSO or perhaps HCI.

See the hovertexts on the selector buttons, which explain what the frames are for.

Once you actually have a transfer and are tuning your flyby (or capture) to the scale of a few kilometres, rather than astronomical units, you should zoom in on mars; at that point MCI may be appropriate (though MSO will still do the job, and will tell you where the night side will be). If you are planning to land directly, MCMF should be used to see where you land.

Thanks for the useful info , will do it

[itsthatguy]

Serious question (I know that this has probably been discussed before, but bear with me)

If this mod implements N-body Newtonian physics, does that mean that the precession of Mercury's orbit is incorrect when using RSS?

Edited November 15, 2021 by itsthatguy

[Delay]

9 minutes ago, itsthatguy said:

If this mod implements N-body Newtonian physics, does that mean that the precession of Mercury's orbit is incorrect when using RSS?

That is correct. Apsidal precession is not modelled. However, at some 40 arcseconds per century, does it really matter for RSS timescales?

Edited November 15, 2021 by Delay

[Hoozemans]

On 10/1/2021 at 6:29 PM, Lisias said:

Texture Quality. You can adjust it on Main Menu / Settings  / Graphics . You can set it to Full Res, Half Res, Quarter Res and Eight Res. [...]

It's Unblur! But I don't know if it still works on KSP >= 1.8, I will give this a try later...

Thank you! And now to get the hang of thinking in knots and twists.

[Axelord FTW]

Current career play is going well, and I'm thinking about what challenge to add on to next. Principia sounds like torture a good idea. The only planet pack (Kopernicus) I use is also described as being stable, which is nice.

What I'm really curious about is how well Principia handle multiple crafts, performance-wise. Is everything handled in real time, and only flight planning calculate the future?
I'm also concerned about orbital stability. How often (if at all) does one need to go back and stationkeep their crafts? I'm slowly making my way through the available documentation, when time allows.

EDIT: Also having some issues adding Kopernicus stuff to the game. Initially encountered a CTD upon loading a save with Event Horizon, but I've since come across the same problem if I add Outer Planets Mod. I'm effectively locked from using planet packs right now. That got fixed, somehow. Principia+OPM runs okay now. Now to see if I can unfug EH.

Edited December 2, 2021 by Axelord FTW

[eggrobin]

For the new moon (lunation number 271), the new release (Hamilton) is out.

• A memory leak that led to visual anomalies has been fixed;
• A performance issue with text-heavy windows, in particular the reference frame selector, 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 腾讯微云.

[Axelord FTW]

Any reason why parts on a craft become so jittery with Principia?

https://youtu.be/5T6wiwzoe38

I thought this was due, at first, to planet packs with very distant objects to the focus, but even testing with only Principia resulted in the same jank.

[eggrobin]

A critical issue was found in Hamilton (#3226, the reference frame selector was broken unless the UI was set to English), so we have hotfixed the release; if you downloaded Hamilton prior to this post, please download it anew (the version string in the Principia UI should say 2021120408-Hamilton-0-gd0f59ca12318ef52bff4ee83615a2e1851f719a1, not 2021120408-Hamilton-0-g7522c92837f25fcc9d696e9d1a12fe2ff43ffd5a).

Edited December 5, 2021 by eggrobin

[JeromeHeretic]

Hello kerbonauts!

My game crash with principia Hamilton after upgrade game to 1.12.3. I wasn't searching for details, but i removed principia and game start normaly.

Anybody have the same expirience? I know, 1.12.3 is fresh, so im asking do you already know about it?

Edited December 14, 2021 by JeromeHeretic