[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

[Eriksonn]

8 hours ago, BadLeo said:

I think I did it!

It looks like you ended up at the L3 Point, unforunutly that one is unstable, as is every other lagrange point that is lined up with kerbin and mun,so your original plan of placing it in the L2 Point on the muns far side wont work either unless you do cource corrections every few months. What you want for your sattelite is the L4 or L5 points, they are 60 degrees in front of or behind the mun and having the same orbital radius as the mun. A good thing is that you are at one of the (unstable)lagrange Points already, and that means that it takes very little energy to get to any other L-point. 

Old pic of me going to the L5 Point, I did it from lko and using the mun to slingshot me, but it should give you an idea of where to place your sattelite for it to be stable:

Spoiler

You will also need to make some cource corrections at the start to get where you want to be but once it forms a loop should be good. With any of the L-Points you can Aalways do burns so that you shrink the "orbit" around the Point and in case of the L4 and L5 Points it becomes more stable that way, so try to aim for as small "orbit" as possible. You can see in the image that i did that too by the spiral shape.

 

[BadLeo]

1 hour ago, Eriksonn said:

It looks like you ended up at the L3 Point, unforunutly that one is unstable, as is every other lagrange point that is lined up with kerbin and mun,so your original plan of placing it in the L2 Point on the muns far side wont work either unless you do cource corrections every few months. What you want for your sattelite is the L4 or L5 points, they are 60 degrees in front of or behind the mun and having the same orbital radius as the mun. A good thing is that you are at one of the (unstable)lagrange Points already, and that means that it takes very little energy to get to any other L-point. 

Old pic of me going to the L5 Point, I did it from lko and using the mun to slingshot me, but it should give you an idea of where to place your sattelite for it to be stable:

  Hide contents

You will also need to make some cource corrections at the start to get where you want to be but once it forms a loop should be good. With any of the L-Points you can Aalways do burns so that you shrink the "orbit" around the Point and in case of the L4 and L5 Points it becomes more stable that way, so try to aim for as small "orbit" as possible. You can see in the image that i did that too by the spiral shape.

 

I didn't have the slightest idea on what direction to aim for the burn and what "pattern" of orbit to look for. The way I did was that I put the craft between Kerbin and the Mün and hoped it would drag me along it and, with a small nudge I could maybe hit the L5 (the one behind it, dunno if that's the correct one), but I guess my nudge was far to strong and it just threw me far away. Your pic is indeed very insightful, though, thanks!

[Eriksonn]

As you are currently at the L3 Point and want to go to L5, you can just burn slightly retrograde so you catch up with the mun. The thing is that L1, L2 and L3 are "open" is a sense as you can enter them, spin around for a while and then exit without thrusting at all(if you are careful about it) but the L4 and L5 are "closed" in that as they are stable(ie you wont fly out once you are in there) and as orbits are reversible(if you flip direction of everything things still work) that mens thay you cant just "glide" into the L5 Point without an input of energy(thrusting). So they are abit harder to get to, but they can be brute-forced by getting to the correct location and circuralizing there. So get to 60 degrees behind the mun in some way, and then force-circuralize there and you should be fine.

[BadLeo]

I think I got there. But...

Spoiler

... I'm having trouble understanding how to reduce the orbital period, as it seems any burn, even the slightest nudge, will kick me out of it eventually.

 

Edited March 10, 2019 by BadLeo

[Eriksonn]

I think that burning radial at the Points where you cross the muns orbit could do something. You need to get more to the center of the oval and circuralize there.

[Delay]

2 hours ago, BadLeo said:

I didn't have the slightest idea on what direction to aim for the burn and what "pattern" of orbit to look for.

Just burn retrograde to bring your relative velocity close to zero once you arrive where you want to arrive. The trajectory to get there looks exactly the same for all lagrange points, you "just" have to aim somewhere else.

[BadLeo]

It's been largely a guessing game, but I believe I'm doing it correctly. Well, at least for the orbits in sight...

Spoiler

 

[Delay]

3 minutes ago, BadLeo said:

 

  Hide contents



 

That looks pretty good to me!

[scimas]

9 hours ago, BadLeo said:

It's been largely a guessing game, but I believe I'm doing it correctly. Well, at least for the orbits in sight...

You're close enough to the L5. Since it is a stable point, you will stay around it. Yes, the orbit will wobble around the point, but it won't diverge. 

You can switch your plotting frame to inertial temporarily to help with when and in which direction to perform a burn. 

[Eriksonn]

13 hours ago, BadLeo said:

It's been largely a guessing game, but I believe I'm doing it correctly. Well, at least for the orbits in sight...

  Reveal hidden contents

 

That is perfect. The Mun has very stable L4 and L5 Points, as your large loop in the previous image was already quite stable by the looks of things. If you can get another sat to the other side of the mun you should have (almost)full connection on the whole mun at all times.(Not sure about how much the signals can go "through" the mun)

Minmus also has these points but there it is slightly harder to get them stable as the mun is much larger than minmus and tend to mess things up a bit. 

By experience I have found that the Duna-Ike L4 and L5 Points are not stable due to Ike being too large. Gilly might be too small to have significant Largrange points and the Jool moons Might be possible but i am not sure as they are very close to each other and are rather big(but Tylo is the most hopeful i think)

[RealTimeShepherd]

Apologies if this has been asked before

Is there anyway to have the RPM (IVA) Navball change in the same way as the game navball?

Ideally I would like to use exclusively IVA controls and the Principia navball changes currently do not seem to affect the navball that you bring up on internal MFDs

[Antstar]

On 3/4/2019 at 3:44 PM, Antstar said:

Second, and kind of worse, those damn sliders in the flight planners are so woefully bad for flight planning. And it would be so easy to put a box next to it with a number that we can write in and hit enter. You even have this for things like trajectory projection in the basic principia dialog box

Well I was wrong. I didn't realise that the projection values in the main Principia dialog could only be changed with buttons. A reply that "this may be done some day" or "no, I really don't care about this" would have been nice.

So let me be specific about why I think this is desperately needed addition to this mod: I have a watercooled, overclocked computer. As home processing goes, it is within about 50% of what is possible to have on any budget. Now, say I launch a rocket. I 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.

 

Now, 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.

 

Now with my node a month in the future, I need to try to phase my node in its orbit around the Earth, so that I am burning in the right direction WRT Earth. Except the game is lagging so goddam badly that the sliders are all frozen up. I dare not move the mouse or hold the button down because who cay say where the node will end up?? A simple text entry box would solve this, allowing me to move it by an arbitrary amount instead of swearing at my computer for 5 minutes, only to find I'm still a month early and need to move the node forwards and spend another 5 minutes micromanaging the node. The exact same problem applies to far future nodes; for instance I want to know if this trajectory to Jupiter will allow me to do a powered slingshot to Saturn within my dV budget? Lag, lag and more lag.

Its not like I'm blaming Principia for causing lag - its an N body simulator, of course there is going to be lag. I'm just saying please, for the love of KSP, put in some text entry boxes!!!!

 

Of course, its your mod and your time. And your choice. And I wont post on this subject again...

[eggrobin]

 

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.

Quote

I 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.

Quote

Now, 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:

1. 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;
2. 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;
3. 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;
4. 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.

[pleroy]

On 3/16/2019 at 1:14 PM, RealTimeShepherd said:

Is there anyway to have the RPM (IVA) Navball change in the same way as the game navball?

Ideally I would like to use exclusively IVA controls and the Principia navball changes currently do not seem to affect the navball that you bring up on internal MFDs

We should definitely replace the navball in IVA.  I have created #2099 to track this.

The interaction with RPM is another kettle of fish entirely.  I don't think that we want to start having dependencies on other mods.  I guess we could expose an API to read the orientation of the navball, and then other mods could use that orientation in their processing.

[Eriksonn]

On a related note with the gui hanging when planning too much; when i make a flightplan from lko out to the mun and do a bunch of gravity assistes with the mun over several days and then when i am done i delete the maneuver, the huge plan length remains and it hangs for several seconds while trying to compute hundreds of orbits in lko before i can click delete flight plan...

[Einstein_Cross_X1]

@eggrobin

I just want to start off by saying I cannot say how happy I was when I discovered this mod. The work you've done here is nothing sort of incredible, and I can't wait to see where you take this mod!

Now on to the main reason I wanted to reach out; recently I have been trying to make patches for some of the more popular planet packs (The world beyond and Other worlds rebooted in particular) but I've only been able to make progress through trial and error and that has been incredibly slow and unpredictable so far. Do 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? It'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!

Edited March 25, 2019 by Einstein_Cross_X1

[RocketSquid]

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. Landed or orbital bodies do not experience this, it is only suborbital rockets and kerbals that try to walk. Additionally, while in orbit principia's predicted orbit quickly stops being around the body; as if it is not moving with the body. In trying to land on the mun, my ship crashed once, and afterwards whenever a kerbal tried to walk on the surface they would be dragged along the ground until they died. When I tried to take back off with the rocket, it was slammed into the ground. The movement was very jerky. I don't even know how to file a proper report for this one.

[eggrobin]

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),

Quote

If 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.

Quote

Portions 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).

[eggrobin]

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.

Quote

It'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.

Quote

Do 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).

[RocketSquid]

1 hour ago, eggrobin said:

 

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).

The weird part is that the teleportation worked fine. The vessel briefly spawned on the pad, then teleported into an orbit around Mun. While it was in orbit, the only anomalous behavior observed was that the principia path didn't move with the planet or vice versa. When the ship was landed, it was also fine. It was only while on a suborbital trajectory that there were problems. Hell, it might have been mun rotating erratically, rather than actually moving.

[pleroy]

@Einstein_Cross_X1: A possible way to make progress would be to clone the test we use to check the stabilization of the KSP stock system and adjust it for the system(s) you are interested in.  It would make it reasonably quick to experiment with various tweaks of the system.  The drawback of course is that you'd need to build Principia (instructions here) and then do some C++ programming.

[eggrobin]

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).

[Einstein_Cross_X1]

On 4/4/2019 at 1:29 PM, eggrobin said:

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).

I've been getting a CS0246 error when trying to build for 1.7.0.

I simply copy the KSP assemblies from my KSP Managed folder into a folder labeled 1.7.0 in my principia build folder and try compiling as normal. That's when I run into the error. One example of the error produced: 

ksp_plugin_adapter.cs(118,44): error CS0246: The type or namespace name 'Orbit' could not be found

Any tips on on what I could do would be fantastic. Thank you!

[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.

[Einstein_Cross_X1]

2 minutes ago, eggrobin said:

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.

Understood. Thanks for the speedy reply! Hoping 1.7 supports comes at some point in the future.