Jump to content

[WIP][1.8.1, 1.9.1, 1.10.1, 1.11.0–2, 1.12.2] Principia—version Hadamard, released 2021-10-06—n-Body and Extended Body Gravitation


eggrobin
 Share

Recommended Posts

14 hours ago, limelier said:

@R-T-B Can I have it too? Sorry for the spam, I would've PM'd directly, but my account is new.

Because my patched version is a version behind already, and it appears an official update is well on the way in the near future, I am going to ask you to wait for official at this time.

Plus sending out all the links to my binary to anyone who requests consumes time for my other projects, so consider this a notice to "just wait" for official now guys. :)

Edited by R-T-B
Link to comment
Share on other sites

Posted (edited)

For the new moon (lunation number 267), the new release (Grothendieck) is out.

  • Support for KSP 1.12.2 has been added.
  • A save compatibility bug has been fixed. Saves created with Cardano or later should now be readable.
  • An error in terminology in the Chinese translation has been corrected.

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

Edited by eggrobin
Link to comment
Share on other sites

34 minutes ago, eggrobin said:

For the new moon (lunation number 267), the new release (Grothendieck) is out.

  • Support for KSP 1.12.2 has been added.
  • A save compatibility bug has been fixed. Saves created with Cardano or later should now be readable.
  • An error in terminology in the Chinese translation has been corrected.

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

The change log links back to this forum page, not to the github.

Just in case that wasn't intentional. I don't want that to come across wrong.

Link to comment
Share on other sites

4 minutes ago, Delay said:

The change log links back to this forum page, not to the github.

Just in case that wasn't intentional. I don't want that to come across wrong.

Fixed, thanks for pointing that out.

Link to comment
Share on other sites

What is a good way of planning constellation maneuvers? For instance, my first relay satellite network would have 3 satellites at 120° phase angle in a 7000 km orbit around Earth. My launcher will place them all there at once, and then two of the satellites would then do a phase change maneuver to place themselves at the right separation along the orbit.

In vanilla KSP I would just place dummy maneuver markers and then execute burns until the apsis time matched the time of the respective maneuver marker.

With Principia, I can't easily place arbitrary maneuver markers anymore, but I think the rendezvous targeting frame would work really well for this, if only I could set a "virtual" target at +/- 120° phase angle of the primary satellite. Is that possible somehow? Or some other easy way of achieving equal separation along an orbit? I searched this topic for similar questions but found nothing using the obvious keywords.

Or do I have to manually calculate the transfer orbits based on the orbital period?

Link to comment
Share on other sites

Alright, in regards to my question above, I think I found a neat way of doing this.

After calculating various orbital periods, I realized that to achieve a 120° phase angle, i.e. 1/3 orbit, I could make a transfer with an orbital period of 4/3 the original, or in general (3N+1)/3N and the phase angle would be right after N orbits. So I picked 28/27, and boosted prograde for a bit until there were enough visible "rosettes", I counted off the 27th encounter (I'd be doing 27 orbits plus the one orbit indicated by the rosettes, so 28 while the target does 27), and boosted prograde until that encounter matched my current position. At that point everything lined up very neatly again, which I took for a good sign.

G3zyKH8.jpg

I guess I'll know if it worked in a few days... but the orbital period seems correct, my 4:26:01.5 is 28/27 of the primary 4:16:31.5.

[edit] I just realized that, counting off the 9 encounters after which the phasing should be right, I realized that it was about 120° away from my current position, so I guess that's another good sign. But making the rosettes align was definitely more precise than eyeballing the angle would've been.

I've gotta say, I'm extremely impressed with Principia and how it displays the various references frames, thanks everyone for the great work!

I don't know if it's worth a ticket, but for the above it definitely would've helped to have a counter for the encounters so I wouldn't have to count the markers manually.

Edited by jd284
Link to comment
Share on other sites

  • 2 weeks later...

I have been consistently getting this error message upon loading into a new save, without any other mods installed:

Error extending trajectory for Laythe. Error trying to fit a smooth polynomial to the trajectory. The approximation error jumped from +2.30344324226492217e-03 m to +8.35706270893752298e+03 m at time 2000-01-19T18:40:00,0000000000000000 (TT). The last position is [+2.82771976953634682e+10 m, +5.89455954369199753e+10 m, +3.17994282982390106e+08 m] and the last velocity is [-3.61414693067490953e+03 m s^-1, -1.47464668046310658e+03 m s^-1, +9.66125813160947615e+01 m s^-1]. An apocalypse occurred and two celestials probably collided because your solar system is unstable.

I believed that Principia altered the stock system to create stability, and now I'm confused. Vall has been ejected from the Jool System and is now orbiting the sun in a highly elliptical pattern.

Please help

Edit: In addition to other wild bugs, (terrain being reshaped, causing kerbin to be unrecognizable, none of the celestials progressing in their orbit, etc.,) the problems were isolated to the singular save I had created. I did have Kopernicus in the game directory when I made it. I'm a derp.

Edited by lopixl
I'm a derp
Link to comment
Share on other sites

15 minutes ago, lopixl said:

I believed that Principia altered the stock system to create stability, and now I'm confused. Vall has been ejected from the Jool System and is now orbiting the sun in a highly elliptical pattern.

Principia does indeed make changes to the Jool system to prevent Vall from being kicked into interplanetary space. The errors in the integration are probably from the fact that Vall's gravity assists, if I remember correctly, end up with it inside Laythe.

The fact that Principia failed to alter the system suggests that the solar system somehow isn't the stock one.

Link to comment
Share on other sites

13 minutes ago, Delay said:

The fact that Principia failed to alter the system suggests that the solar system somehow isn't the stock one.

I had Kopernicus (without a planet mod) in the game directory when I made the save, along with too many other mods to count. That probably did something. I just removed all my mods excluding Principia, and it's working fine.

Link to comment
Share on other sites

On 8/23/2021 at 7:48 PM, lopixl said:

I had Kopernicus (without a planet mod) in the game directory when I made the save, along with too many other mods to count. That probably did something. I just removed all my mods excluding Principia, and it's working fine.

iirc either Principia disables the jool system change if Koperncius is detected or Kopernicus forces the stock system on top of principia

Edited by ballisticfox0
Link to comment
Share on other sites

It seems that when planning a maneuver with with significant off-tangent components, the maneuver node on the navball is not always placed correctly. I had to aim several degrees off from it (see screenshot), about half-way between the maneuver node and the target -binormal vector instead (where the maneuver node ended up after moving around during the first wrong burn).

I was trying to do a plane change intercept for a rescue operation on the Moon, at apolune of a highly elliptical orbit, with mostly -binormal delta-v. The planned separation was 200 m, but when I aimed for the maneuver node on the navball, I ended up on a way different orbit with 75 km separation with a 50 m/s tangent/normal correction needed. Same when I reloaded and aimed at the binormal node instead. I had to aim half-way in between and got it down to 3 km separation and "only" 6 m/s correction needed afterwards.

Or did I do something wrong here? I can provide a savegame a few seconds before the burn but I use a bunch of mods (USI, SpaceY) and several custom ModManager patches so it will probably be difficult to use...

SIXxDpc.jpg

Link to comment
Share on other sites

1 hour ago, jd284 said:

I ended up on a way different orbit

It would be helpful if your screenshot actually showed the position of the maneuver...

I'd guess that your actual trajectory wasn't the same as the flight plan because you didn't rebase.

Link to comment
Share on other sites

1 hour ago, Al2Me6 said:

It would be helpful if your screenshot actually showed the position of the maneuver...

I'd guess that your actual trajectory wasn't the same as the flight plan because you didn't rebase.

OK, I don't know which perspective and frame would show it most clearly so I uploaded several others to https://imgur.com/a/kbXiQdI. And I've learned pretty quickly to always rebase after a maneuver, so that wasn't the problem here.

zX4QElX.jpg

Link to comment
Share on other sites

Spoiler

 

You're looking at the target vehicle navball in this screenshot, so the tangent, binormal, normal markers are in that frame. But your manoeuvre is planned in the body inertial frame. That is making you think that those things don't align. And indeed they don't since they're two different frames. Manoeuvres cannot be planned in the target vehicle frame.

Link to comment
Share on other sites

1 hour ago, scimas said:

Manoeuvres cannot be planned in the target vehicle frame.

Alright, that kind of makes sense, although I'd still expect the maneuver node to be in the right place, and not off by about 10 degrees, since the required direction of thrust should be the same regardless of the plotting frame and its tangent/normal/binormal directions. I don't understand why a different planning frame should affect that. Anyway, in my screenshots it seems that the blue marker is actually in the same place for both frames. But it's the wrong place for the planned maneuver.

So what's the proper way of planning an intercept then if it can't be done in the target frame, which is after all the only way I can see how close the intercept will be?

Is it enough to roughly create the new maneuver in the inertial frame, and then switch to the target frame for fine tuning? And obviously I need to fine-tune the maneuver execution in the target frame as well.

Though I'm actually pretty sure that I've done this, because planning the maneuver time required seeing the apolune in the MCI frame. So I created the maneuver in the MCI frame, changed the binormal value for a plane change to roughly the target plane, and then switched to target frame to fine-tune the intercept.

Link to comment
Share on other sites

  • 2 weeks later...

For the new moon (lunation number 268), the new release (Haar) is out.

  • The reference frame selector has been revamped to take up less space, allow quicker switching between arbitrary frames, and provide better explanations of the uses of the various frames. Thanks to @Al2Me6 for translating the new UI to zh-CN, and to @Zaikarion for linguistic help.
  • Celestial-specific terminology has been added (perigee instead of Earth periapsis, lunar orbit instead of Moon orbit, etc.).
  • Principia is localized in French.

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

Edited by eggrobin
Acknowledgements!
Link to comment
Share on other sites

for people like me who tend to leave UI windows open (makes it easier when working with younger people), if you encounter lag while right click dragging the KSP flight or map view scenes with the new reference frame selector UI open, minimizing it returns the normal smoothness (and to clarify, pinning just the celestial you are working with & using the '+' to collapse the full list helps a lot as well...which, If I interpret correctly, is what pleroy suggested in the change log)...I really like the revamped UI...thanks egg & pleroy!

Edited by AloE
Link to comment
Share on other sites

On 9/7/2021 at 11:17 AM, AloE said:

 if you encounter lag while right click dragging the KSP flight or map view scenes with the new reference frame selector UI open, minimizing it returns the normal smoothness...

Maybe file a bug for the performance issue? Having the UI open is not supposed to slow things down to a crawl...

Quote

pinning just the celestial you are working with & using the '+' to collapse the full list helps a lot as well...which, If I interpret correctly, is what pleroy suggested in the change log

The UI features that help make the UI smaller are there to make the UI smaller, not faster; if it is slowing things down to start with, there is a bug (probably the KSP localization logic being slow, but it should be easy to cache things).

Edited by eggrobin
Link to comment
Share on other sites

hello! I use rss ro, I launched the satellite into orbit with parameters of 160 km at perigee and 250 at apogee, accelerated it, a year passed but the craft did not fall, that is, the orbit parameters did not change significantly, although in reality it was supposed to fall within a month

Edited by serg1983
Link to comment
Share on other sites

12 hours ago, serg1983 said:

hello! I use rss ro, I launched the satellite into orbit with parameters of 160 km at perigee and 250 at apogee, accelerated it, a year passed but the craft did not fall, that is, the orbit parameters did not change significantly, although in reality it was supposed to fall within a month

Principia does not model decay due to atmospheric drag.

Link to comment
Share on other sites

On 9/9/2021 at 1:09 PM, serg1983 said:

although in reality it was supposed to fall within a month

While Principia itself does not directly model decay from atm drag as Al2Me6 clarified, Principia does work nicely with FARc & RSS, especially after all the great work that was done associated with the "Spin-up on reentry under physics warp with FAR #2519" issue.

Prompted by your query, I looked more carefully at data from the FARc "Flt Data" log & KerBalloons flight recorder log.  Interestingly, the current RSS Earth atm model registers at a lower altitude than I expected (see data images below).

Looking at the numbers from the FARc "Flt Data" log, FARc will at least apply drag & lift for atmosphere pressure on the order of E-08.  So if you wanted to experience decay drag starting around 160km for example, you could make your own revised custom atm model using @OhioBob's "Make your own Atmospheres for KSP (automatically)" spreadsheet and paste the values into your copy of the RSS Earth.cfg for Kopernicus, replacing the atm keys for the default model in that .cfg...in which case also make sure to also delete the Earth.bin in the Kopernicus cache so that it rebuilds the model of the Earth at next KSP load.  I'll probably tinker a bit in this area of the atmosphere model this fall/winter as well.

X7HRYNN.pngEx0SRyj.png

Edited by AloE
added Kerballoons Reinflated link
Link to comment
Share on other sites

a fyi update on #3064: The a.k.a 'flickers/textures' symptom that appears to manifest only on some machines, correlates with an as yet unexplained large (~ 1 MB/s) & constant increase in memory allocation by the KSP_x64 process only when the "Principia 'Flight Plan UI' window with an active flight plan" is Open on screen.

To help understand who is & who is not affected (all machines to which I have access for KSP are badly affected ;-), I have created a short Google Survey (link) that you are welcome to fill out if you would like.
 
You may easily observe if your machine has the effect by watching the size of KSP_x64 process memory as you alternately open & close the Principia Flight Plan UI window with an active flight plan.
 
For example, on a windows machine:
  • watch the memory value called 'Private Working Set' for the KSP_x64 process either from the 'Details' tab of Task Manager, or using Process Explorer. 
  • If your machines shows the effect,  the 'Private Working Set' value will immediately start & steadily increase by on the order of 1024 KB/s = 1 MB/s = 1GB per 20 minutes ONLY when the Flight Plan UI window is OPEN on screen.
  • Use the 'Flight Plan' button on the main Principia UI to close the Flight plan UI & after a few seconds the memory will stabilize.
  • Repeat the process for reliable control of growth in the KSP_x64 process memory.
  • The above method should be similar on MacOS & Ubuntu, etc...from my reading online the default memory reporting metric on those systems is basically similar to the 'Private Working set' value on windows.
The reason remains a mystery.    Current details at #3064.  Thanks!
Edited by AloE
Link to comment
Share on other sites

How does the flight planner "time base" work?

From the term "End of maneuver #1" one would expect that the time of maneuver #2 moves accordingly when I move maneuver #1 in time. However it stays at the same time as planned originally.

This makes it very hard to plan flights with multiple burns, for instance a return from the moon with #1 tangent burn into an elliptical lunar orbit, then #2 plane change at apolune, and #3 Earth transfer tangent burn at the following perilune. Ideally I'd like to play with the initial time to get a good perigee, however if I move it the other maneuvers will no longer be at apolune/perilune, but offset by the amount of time I moved maneuver #1 and so I continuously have to adjust all three at the same time.

Am I doing it wrong or do I understand it wrong? Is there a way to change the time base of maneuvers to work like what I want?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...