Simplified Principia

[MAFman]

Has anyone come up with an implementation of Principia that does 3-body gravitation instead of n-body? This would be where the ship's only gravitational influences are its orbital body and that body's parent (e.g. if you were in orbit around the Mun, you'd be affected by the Mun and Kerbin only). This would make Lagrange points possible without adding too much complexity, I think.

[sarbian]

Do you have a general analytical solution to the 3-body problem ? If not then I do not see how using 3 bodies will make anything easier.

[MAFman]

How does Principia do it then?

20 minutes ago, sarbian said:

Do you have a general analytical solution to the 3-body problem ? If not then I do not see how using 3 bodies will make anything easier.

What I'm thinking is specifically the restricted 3-body problem, where the third mass is negligible.

[sarbian]

40 minutes ago, MAFman said:

How does Principia do it then?

It uses a numerical solution.

Edited July 10, 2020 by sarbian

[MAFman]

17 minutes ago, sarbian said:

It uses a numerical solution.

Why not do that for a 3-body solver then?

[Superfluous J]

If you only count the body you're orbiting and its parent, you won't get Lagrange points. You need the bodies orbiting the thing you're orbiting.

For example, to get Mun Lagrange points around Kerbin you need Kerbin and Mun, not Kerbin and Sun.

[MAFman]

2 hours ago, Superfluous J said:

If you only count the body you're orbiting and its parent, you won't get Lagrange points. You need the bodies orbiting the thing you're orbiting.

For example, to get Mun Lagrange points around Kerbin you need Kerbin and Mun, not Kerbin and Sun.

...You know what I mean... lol

[pleroy]

4 hours ago, MAFman said:

Why not do that for a 3-body solver then?

So do you really believe that a loop from 1 to 3 is simpler than a loop from 1 to N?

What problem are you trying to solve anyway?

[MAFman]

1 hour ago, pleroy said:

So do you really believe that a loop from 1 to 3 is simpler than a loop from 1 to N?

What problem are you trying to solve anyway?

I want Lagrange points in my game.

[eggrobin]

1 hour ago, MAFman said:

I want Lagrange points in my game.

There is a mod that gives you that: Principia.

Evidently you want something else.

19 hours ago, MAFman said:

without adding too much complexity

It is not clear to me whether you mean complexity for the player or complexity for the implementer.

If you care about implementation complexity (but why would you? it is our burden, not the player’s),

7 hours ago, MAFman said:

Why not do that for a 3-body solver then?

3 hours ago, pleroy said:

So do you really believe that a loop from 1 to 3 is simpler than a loop from 1 to N?

Dealing only in three-body mechanics would make things strictly more complicated: you would end up with a maze of special cases and nasty transitions between situations where you choose two given bodies, and you would still have to deal with the full complexity of stable numerical integration of trajectories in the 3-body problem; see @chuckstables’s post for an introduction to that.

More importantly, most of the implementation complexity comes not from computing where your spacecraft goes (that was pretty much done 5 years ago), but from providing the player with the tools needed to understand where it is going. The very concept of orbit, as understood by stock KSP (and stock KSP players), falls apart under the influence of a third body, so a reimplementation of the entire patched conics & manœuvre node system (which relies on the stock orbit logic) is needed to be able to plan your flight in those situations. For complex trajectories such as, in particular, those that stay near Lagrange points, a stock-style trajectory display in a nonrotating reference frame centred on one body is unusable; we therefore need to introduce a choice of reference frame so that trajectories that involve Lagrange points are understandable as such, and not merely as weirdly perturbed orbits of one of the bodies.

The custom flight planning, reference frame selection, and other aspects, besides being a major source of implementation complexity, are also the major source of gameplay complexity: not only do we need to build those new tools, the player needs to learn to use them.

These tools are needed in order to understand the varied trajectories that can arise in the non-Keplerian world. They are needed even if you only have two massive bodies (and in particular they are needed to work with Lagrange points). In fact they are needed to effectively work even with a single non-spherical body: oblateness makes orbits precess, and you need tools to understand how they do so.

The gameplay complexity comes from the fact that you are dealing with complex trajectories, and not just with easily-classified Kepler orbits anymore; this is true with two massive bodies just as much as it is true with twenty.

 

Have you tried Principia, and if so, what issues did you run into that brought up these questions?

[MAFman]

I stand corrected! I’ll use Principia then.

[MAFman]

Speaking of which, it needs to be updated. @eggrobin are you the mod's manager?

[eggrobin]

@pleroy and I are the authors. This is not our job, no managers are involved (except of course for @sarbian’s ModuleManager).

5 hours ago, MAFman said:

it needs to be updated

As for your remark, there is a new Principia release every new moon; whether the mod needs to be updated or not is entirely irrelevant to that schedule.

I think with that needs you are alluding to 1.10 support; even when things go smoothly, it often takes several Principia releases before we support a new KSP version, just to check that everything is fine with the new version.

Here things may not be completely smooth, as, depending on how they were implemented, correctly handling the comets may require a lot of work.