On Newtonian trajectories vs. patched conics

[stupid_chris]

I won't respond to all you wrote (since, as you said, you hadn't fully read the post before responding), but I do want to comment on your statement that because the physics calculations in KSP are so costly, something else couldn't be added to the game. The part-to-part physics calculations certainly are costly; on my laptop the game is pretty much always chugging and using all the resources it can, either due to rendering or the physics calculations depending on the situation. But if what you say is the true state of affairs, that nothing else can be added because what is already there is so costly, it's a pretty lousy state of affairs. Either the developers really do need to drop everything else and do optimization (as posters occasionally complain about on the forum), or else expansion of the game is done. But I think your statement is incorrect, as evidenced by the popularity of mods that do add a moderate amount of additional calculation to the game (FAR, ISA Mapsat, MechJeb, etc.).

Unfortunately, I was called to work today and haven't had time to do much and I still am not in a mental state to process information (I have college tomorrow so I should be a bit more awake after my calculus class to give a look at this), but I can still see where you're heading wrong here. The thing some people do not know is that KSP is multi-threaded. But the problem is that the biggest thread, physics, is not threadsafe. This means the calculations for this cannot be done by more than one core. All the physics calculations are done on one single core, and once you reach that core's limit, this is where you hit the lag wall. KSP is barely GPU demanding, so rendering is not affecting your performance unless you have a terrible graphics card. Yes, part to part physics take a big part of it, but ultimately orbital calculations, acceleration and part to part physics all come bundled up in the physical calculations thread. The developers can't do much about it as this problem lies with Unity. They can't drop everything else to optimize, since they can't fix this as of right now. And doing so would be silly anyway, the game is still under heavy development and is still an alpha, optimizing an alpha is counter-productive. And adding mods like MapSat or FAR does add more calculations, but since those can be done by other barely used cores, this doesn't affect your gameplay as much.

So yes, adding more physics calculations is gonna make your PC cringe even more, and there's not much the devs can do about it unfortunately.

I'll take the time to fully read this tomorrow (I promise! ) and try to make sense out of it, but once more I doubt this is something we really want to add to the game right now.

[a humble lich]

Actually, the more I think about it, for the Kerbal-Mun system at least, Lagrange Points are possibly more stable in the current model than with Newtonian dynamics. I suspect that interactions from Minmus will fairly rapidly pull a craft away from L4/5. I wanted to try the stability calculation today, but have been to lazy. :-)

[Mattasmack]

Unfortunately, I was called to work today and haven't had time to do much and I still am not in a mental state to process information (I have college tomorrow so I should be a bit more awake after my calculus class to give a look at this), but I can still see where you're heading wrong here. The thing some people do not know is that KSP is multi-threaded. But the problem is that the biggest thread, physics, is not threadsafe. This means the calculations for this cannot be done by more than one core. All the physics calculations are done on one single core, and once you reach that core's limit, this is where you hit the lag wall. KSP is barely GPU demanding, so rendering is not affecting your performance unless you have a terrible graphics card. Yes, part to part physics take a big part of it, but ultimately orbital calculations, acceleration and part to part physics all come bundled up in the physical calculations thread. The developers can't do much about it as this problem lies with Unity. They can't drop everything else to optimize, since they can't fix this as of right now. And doing so would be silly anyway, the game is still under heavy development and is still an alpha, optimizing an alpha is counter-productive. And adding mods like MapSat or FAR does add more calculations, but since those can be done by other barely used cores, this doesn't affect your gameplay as much.

So yes, adding more physics calculations is gonna make your PC cringe even more, and there's not much the devs can do about it unfortunately.

I'll take the time to fully read this tomorrow (I promise! ) and try to make sense out of it, but once more I doubt this is something we really want to add to the game right now.

I'm glad we agree that this isn't something to add to the game right now! As I said initially, I am not suggesting that any change from patched conics trajectories be made now; if I were, I would have started the thread in the suggestions subforum. Rather, I was inspired by earlier conversations on the topic to try Newtonian simulations in the KSP solar system myself and see what technical issues actually came up, and see if and how they could be mitigated or avoided. My purpose in starting this thread was to share what I learned and hear from others.

And in that vein, I don't think it's particularly important that trajectory calculations and part-to-part physics calculations are in the same thread right now. They don't have to be. In fact, if mods like FAR run in separate threads as you say, then we already have a working example of some physics calculations being offloaded into a separate thread.

As I said, the scheme I have been looking at is fast enough to calculate the trajectories of several vessels at 100,000x warp (on my not-very-fast laptop, but running in its own thread). The calculations needed at 1x warp are negligible. And while time-warping, when more trajectory calculations are needed, there are no part-to-part calculations to compete with. The case where the most trajectory calculations are needed is when the player's vessel is under acceleration and the player is in map view, so that the projected trajectory needs to be continuously recalculated so that it can be displayed to the player. Even in this case, calculating the vessel's current state from one frame to the next is trivial, so that need not hold up the game frame-to-frame. But if calculating the projected trajectory is put in its own thread, it will happily use up all the CPU cycles available to it, calculating the current trajectory out as far as possible before throwing it away to start over from newer data. That's the one case where the player wouldn't get feedback in map view as quickly as he or she does now. It should take only a fraction of a second to calculate the new predicted trajectory, but it wouldn't be fast enough to do each frame.

[asmi]

It's time to debunk some myths about KSP:

1. Orbital calculations DO NOT use PhysX - it's completely custom algorithm.

2. Orbital calculation DO use double-precision variables (double type), not single-precision (float) as many seem to imply.

3. Patched conics calculation is VERY cheap, you'd need to have tens of thousands of flying orbital objects before they incur any serious performance penalty.

To the OP - I was thinking of implementing something similar to what you're suggesting in a mod, but run low on spare time to do so. But I'd like to point out that orbit propagations can happen in parallel for several objects at once (and even more if offloaded to GPU), and over long time there could be some sort of combined approach (like "orbit stabilization" in Orbiter). I honestly suck at math of all of this (I know how this works on a fundamental level, but lack mathematical details), but if you would be so nice to provide all equations, I'd find some time to try implementing something like this for CPU and let's see what happens.

[Herbert McCheese-Wang]

Although this would make the game far more realistic, it would be incredibly challenging, like NASA-level.

Frankly, as much as KSP wants to be realistic, this is just too complicated.

[DAVIDESCOTT]

This half-way approach (planetary bodies on Keplerian trajectories and vessels on Newtonian trajectories) doesn't seem to have Lagrangian points.

This doesn't sound right. Vessels are low mass and can be assumed to have no impact on the orbit of the planet. Lagrange points should exist for netwonian vessels interacting with Keplerian large bodies. What makes you think they don't?

[KrazyKrl]

I would be very very impressed if the Interplanetary Transport Network was implemented. I could see the stylized depiction of it on the Wikipedia page as an overlay to the map. It would even incorporate Lagrange points.

Since the Kerbal system is known, and on rails. The ITN could be extrapolated long beforehand, and implemented into something like a rainbow table or just a compressed array of precomputed vectors.

Implementing this would actually be quite easy, you can keep the current SOI system for rough calculations and general orbits. And when you zoom out into a planetary system scale, it overlays the Interplanetary Transport Network, and applies the proper orbital calculations when/if you intersect it.

And, the calculations for the look-up table for the Interplanetary Transport Network could even be cloud computed. i.e. each KSP client could take a job for a time-slice of the age of the KSP system, and upload the data it calculates to a server somewhere. And each client could download said data as needed. Of course caching any data it has downloaded, to be reused locally.

[Mattasmack]

Although this would make the game far more realistic, it would be incredibly challenging, like NASA-level.

Frankly, as much as KSP wants to be realistic, this is just too complicated.

I don't know if a change like this would really increase the difficulty very much. I don't think it will (the biggest aid the player has -- being able to see where their trajectory will take them in map view -- will still work), but I admit I'm guessing.

This doesn't sound right. Vessels are low mass and can be assumed to have no impact on the orbit of the planet. Lagrange points should exist for netwonian vessels interacting with Keplerian large bodies. What makes you think they don't?

Well, I put an object where Kerbin's L4 point ought to be, and it didn't stay there. There are different possible explanations, including simply that I've made an error, either a bug in the code or in my initial placement of the object. I don't think it's a matter of numerical drift, because I can change the local error limit of the RK scheme by a few orders of magnitude and see no significant difference in the result. My theory is that the problem is that Kerbin's orbit is centered around Kerbol's center (which is stationary), rather than the center of mass of the Kerbin-Kerbol system. So the two bodies aren't quite where the ought to be for the forces to balance properly to form the L4 point. The difference is small, but the drift away from the L-point is also slow at first (as compared to the radius of Kerbin's orbit).

I would be very very impressed if the Interplanetary Transport Network was implemented. I could see the stylized depiction of it on the Wikipedia page as an overlay to the map. It would even incorporate Lagrange points.

Since the Kerbal system is known, and on rails. The ITN could be extrapolated long beforehand, and implemented into something like a rainbow table or just a compressed array of precomputed vectors.

Implementing this would actually be quite easy, you can keep the current SOI system for rough calculations and general orbits. And when you zoom out into a planetary system scale, it overlays the Interplanetary Transport Network, and applies the proper orbital calculations when/if you intersect it.

And, the calculations for the look-up table for the Interplanetary Transport Network could even be cloud computed. i.e. each KSP client could take a job for a time-slice of the age of the KSP system, and upload the data it calculates to a server somewhere. And each client could download said data as needed. Of course caching any data it has downloaded, to be reused locally.

Now that would be cool! That's something I've wished I could figure out before -- when and how to launch a rocket so that it can get multiple gravity assists on its way to another planet (or out of the solar system entirely).

[Mattasmack]

It's time to debunk some myths about KSP:

1. Orbital calculations DO NOT use PhysX - it's completely custom algorithm.

2. Orbital calculation DO use double-precision variables (double type), not single-precision (float) as many seem to imply.

3. Patched conics calculation is VERY cheap, you'd need to have tens of thousands of flying orbital objects before they incur any serious performance penalty.

To the OP - I was thinking of implementing something similar to what you're suggesting in a mod, but run low on spare time to do so. But I'd like to point out that orbit propagations can happen in parallel for several objects at once (and even more if offloaded to GPU), and over long time there could be some sort of combined approach (like "orbit stabilization" in Orbiter). I honestly suck at math of all of this (I know how this works on a fundamental level, but lack mathematical details), but if you would be so nice to provide all equations, I'd find some time to try implementing something like this for CPU and let's see what happens.

1: I don't think anyone here said they do, although I might have missed it. Who are you replying to here?

2: Good to know!

3: Yeah, being able to just specify the Keplerian orbital elements and then leave it alone unless and until you need to calculate a position (rather than integrating the trajectory) is a big advantage. But has anyone actually done a study of how many independent objects can be in space in KSP before it starts to lag? I would expect it to be in the mid- to high-hundreds rather than tens of thousands. Actually calculating a position from the orbital elements involves several sin() and cos() calls, and those get costly quickly. (In my own simulations, I found that calculating the planetary body locations from their orbital elements was by far the most costly part of the simulation.)

I hadn't even considered trying to implement the Newtonian trajectories in a mod, I assumed that trajectories and the curves shown in map view weren't accessible to the modder. If they are, well, it would be very cool indeed to try this method out that way. For a first cut at it, I don't think there's any need to worry about parallelization at all, although if it proved successful and other optimizations had been done it would help improve performance. I don't know how much the GPU would help; these calculations must be done in double precision, and I was under the impression that most GPUs don't actually provide all that many double precision FLOPS. I'd be happy to provide the equations, but what level of detail or what sort of information are you looking for? The article on my website (linked from my original post) has links to the articles I used for the core parts of the simulation (the embedded Runge Kutta scheme and the interpolation scheme for it), and I can go into more detail on the other parts or give a more coherent overview of the whole thing if you'd like.

[stupid_chris]

Well you<,ve pinned the exact problem, we can'T separate all those physical calculations across different threads Having all the physics bundled up under the same thread is not something intended, it's just that, as I said, physics are not threadsafe and we cannot separate the different calculations across different cores, hence the lag. If it was as easy as splitting them to different cores, the problem would be nearly inexistant and the last black sheep of KSP would be it'S 32bitness. But the problem is that we can't right now. Unity is kinda unhappy about it.

I read through your stuff, its very well thought. I would like indeed to see something like this at some point. Although I' getting a small spidey feeling it might be better as a mod.

[asmi]

1: I don't think anyone here said they do, although I might have missed it. Who are you replying to here?

2: Good to know!

3: Yeah, being able to just specify the Keplerian orbital elements and then leave it alone unless and until you need to calculate a position (rather than integrating the trajectory) is a big advantage. But has anyone actually done a study of how many independent objects can be in space in KSP before it starts to lag? I would expect it to be in the mid- to high-hundreds rather than tens of thousands. Actually calculating a position from the orbital elements involves several sin() and cos() calls, and those get costly quickly. (In my own simulations, I found that calculating the planetary body locations from their orbital elements was by far the most costly part of the simulation.)

I didn't reply to anybody in particular, I've just gathered this across multiple threads on a subject. As for trigonometric functions, there are easy approximations (like lookup tables) - infact some earlier video cards used built-in lookup tables for them instead of actual computations.

I hadn't even considered trying to implement the Newtonian trajectories in a mod, I assumed that trajectories and the curves shown in map view weren't accessible to the modder. If they are, well, it would be very cool indeed to try this method out that way. For a first cut at it, I don't think there's any need to worry about parallelization at all, although if it proved successful and other optimizations had been done it would help improve performance. I don't know how much the GPU would help; these calculations must be done in double precision, and I was under the impression that most GPUs don't actually provide all that many double precision FLOPS. I'd be happy to provide the equations, but what level of detail or what sort of information are you looking for? The article on my website (linked from my original post) has links to the articles I used for the core parts of the simulation (the embedded Runge Kutta scheme and the interpolation scheme for it), and I can go into more detail on the other parts or give a more coherent overview of the whole thing if you'd like.

For the GPU - allthough recent generations of video cards have pretty good built-in support for double precision, there are ways to achieve double-precision (and even quadruple!) using single-precision math, there are many articles on the subject so this is not that big of issue. But I agree that optimizations can wait a little and proof-of-concept have to be built first.

At first I was thinking about implementing a mod that would calculate and display in map view "real" trajectories along with built-in ones so we would be able to validate that calculations work as we expect them in all modes, including time warp. This sounds like a good enough first stab at subject.

What I need is state vectors propagation function (over integration step). Essentially, it's the function (x₁, v₁) = f(x₀, v₀, dt). I do know Newton's second law (dv/dt=F/m) that would allow to come up with simple function, but it's not going to be accurate enough for our case. Let's leave rotational state propagation alone for now - we can always add it afterwards once we're done with the main thing. In addition it would be great to have some sort of interpolation function that would provide ability to calculate state vectors in between steps (i.e. let's say we have a lookup x_i => t₀ + i * dt, but we want to estimate x at the moment of t₀ + (i + 0.3) * dt).

And as a bonus it would be great to have a function that would allow calculating Keplerian orbital elements (eccentricity, semi-major axis, inclination, LAN, argument of periapsis and mean anomaly) from state vectors since that would help with displaying this info. I could come up with this function myself, but if you happen to have it handy, I'd appreciate if you'd share it.

Please create a thread in "Addon Development" section since that seems to be more appropriate place, and let's go from there.

I can't promise anything until the weekend, but I show have a fair amount of spare time to come up with some prototype. Thank you!

Well you<,ve pinned the exact problem, we can'T separate all those physical calculations across different threads Having all the physics bundled up under the same thread is not something intended, it's just that, as I said, physics are not threadsafe and we cannot separate the different calculations across different cores, hence the lag. If it was as easy as splitting them to different cores, the problem would be nearly inexistant and the last black sheep of KSP would be it'S 32bitness. But the problem is that we can't right now. Unity is kinda unhappy about it.

KSP PhysX issues have nothing to do with orbital calculations (see my post above about that), and indeed it's trivially easy to calculate orbits for different objects in parallel (just as there are ways to make "regular" physics algorithms parallelled, it's just a bit more involved).

Edited September 10, 2013 by asmi

[DAVIDESCOTT]

Well, I put an object where Kerbin's L4 point ought to be, and it didn't stay there. ... My theory is that the problem is that Kerbin's orbit is centered around Kerbol's center (which is stationary), rather than the center of mass of the Kerbin-Kerbol system. So the two bodies aren't quite where the ought to be for the forces to balance properly to form the L4 point. The difference is small, but the drift away from the L-point is also slow at first (as compared to the radius of Kerbin's orbit).

Well nobody ever said that the current Kerbin system was even a stable orbital system. For all we know a full Newtonian simulation will have Kerbol ejected into deep space by Jool.

That explanation does make sense though. Wherever you put the satellite it will orbit around the systems center of mass, but the planets themselves are not doing so. If you had two equally sized objects it would horribly bust the orbits as they should orbit around their center but one of them gets to be stationary while the other does the orbiting. Add a third object there and its path will be completely wacko. The question would be does that mean no L-points exist at all or just that they aren't where they are supposed to be. I would track the orbit of a large number of initial points and plot where they go, if there is an L-point they should pop out of such a plot.

[stupid_chris]

KSP PhysX issues have nothing to do with orbital calculations (see my post above about that), and indeed it's trivially easy to calculate orbits for different objects in parallel (just as there are ways to make "regular" physics algorithms parallelled, it's just a bit more involved).

At time warp 1x yes, because the game recalculates the orbit in taking account velocity, acceleration and other factors in real time. This is also why we can't have proper N-Body physics, because the orbital calculations would overflow the physics thread.

[Evrion]

My theory is that the problem is that Kerbin's orbit is centered around Kerbol's center (which is stationary), rather than the center of mass of the Kerbin-Kerbol system. So the two bodies aren't quite where the ought to be for the forces to balance properly to form the L4 point.

"Lagrangian points L2 through L5 exist only in rotating systems, such as in the monthly orbiting of the Moon about the Earth. At these points, the combined attraction from the two masses is equivalent to what would be exerted by a single mass at the barycenter of the system, sufficient to cause a small body to orbit with the same period."

-Wikipedia

With my reading of Wikipedia, I think you're right about why.

This would elminate L4 and L5 as viable Lagrange points. L1, L2 and L3 should still work, just at slightly different points from "reality". However, these ones require constant monitoring and adjustments just to hold position, so are much less interesting for KSP imo.

So I would say, cool idea! but KSP's physics is sufficiently wrong that adding Newtonian motion to spacecraft would be not really interesting. Essentially, the added computation in the simulation does not add enough interesting mechanics available.

[technicalfool]

Not sure if this has already been mentioned in a round-a-bout mathematicese language already, but would it be possible to "just" put phantom gravity wells in the right places? "Just" in quotes because, well, Coding Is Hard.

The L points are already in a fixed position relative to the bodies concerned, so surely they can go on rails like the planets do? It could also provide something for the forthcoming R&D mechanic. Get some gravitron-measuring probes out there, and after a little while an R&D guy (or perhaps a certain LaGrange Kermin) pops up with "hey, we've discovered this neat gravitational effect you can use. Look at your tracking station to see these 'LaGrange' points we've marked out!"

[asmi]

At time warp 1x yes, because the game recalculates the orbit in taking account velocity, acceleration and other factors in real time.

Acceleration doesn't affect orbit - only velocity and position do.

This is also why we can't have proper N-Body physics, because the orbital calculations would overflow the physics thread.

And you know that because...what?

The point is - there is no way to know until you try. And that's exactly what I'm planning to do.

Not sure if this has already been mentioned in a round-a-bout mathematicese language already, but would it be possible to "just" put phantom gravity wells in the right places? "Just" in quotes because, well, Coding Is Hard.

This is not possible due to different behavior of L points (L1-L3 actually push the vessel away in certain cases), not to mention singularity at the exact center point.

[stupid_chris]

Acceleration affects your trajectory. If you fire up your engine, your orbit changes. And the physics thread is already the limiting factor of KSP, I don't believe I need to expand the idea on that :l I'm not telling you not to try, I'm simply pointing out the limiting factor, and it's the physics thread.

[asmi]

Acceleration affects your trajectory. If you fire up your engine, your orbit changes.

Acceleration will affect your speed on next iteration. But it doesn't change the current one. Remember - it's integration.

And the physics thread is already the limiting factor of KSP, I don't believe I need to expand the idea on that :l I'm not telling you not to try, I'm simply pointing out the limiting factor, and it's the physics thread.

There is absolutely no reasons for orbital calculations to be in the same thread as physics.

[stupid_chris]

When in orbit, your craft is constantly under acceleration, gravity. I can't confirm it but I'm pretty sure it's stuck in the same thread. Else n-body physics wouldn't be such an hassle to add to the game.

[KrazyKrl]

I see no reason why the gravity calculations couldn't be on a separate, asymmetrically running thread. The fact Squad hasn't done it already, is because the backend for the game isn't even near being finished enough to start rewriting the game systems.

The physics thread itself, could do the very very simple force of gravity on the object. By taking distance calculations to all planets, then applying them to the vehicle. Or, even more efficiently, since your vehicle moves at a small fraction of the precession of the system you're in, it could simply read some global variable from the flightpath thread. It would only need the consolidated gravity vector and strength. And it could interpolate any data it needs, due to the relativity of time.

The flightpath thread could do all the n-body physics it wants. It could simply do For each timestep in flightpath, calculate vectors for each planet, calculate gravity for distance, and consolidate them. It's essentially how The Universe works anyhow. Doing n-body gravity calculations is EXPONENTIALLY easier than rigid-body physics.

Other than the alpha-ness of KSP (and problems with Unity's threading toolchain,) I see no reason why full n-body wouldn't be implemented at a later date. Which is probably why it's in the do-not-suggest thread.

[Hannu]

When in orbit, your craft is constantly under acceleration, gravity. I can't confirm it but I'm pretty sure it's stuck in the same thread. Else n-body physics wouldn't be such an hassle to add to the game.

What do you mean? N-body problems are quite common in physics and there are many ways to parallel them. Practically all large physical computations is now made in parallel supercomputers. However, N-body gravitation in KSP's scale is not very difficult or time consuming thing at all and it could be implemented well, if SQUAD would like to. Interactions between ships' parts, aerodynamics, detection of collisions etc. things are much more demanding.

[Mr Shifty]

I'm not sure why the continued calls for n-body physics in KSP. It's already drastically scaled down. All of the bodies are unrealistically dense. None of the planets have axial tilt. And all of this was done to make the game more accessible; n-body physics adds a bunch of complication (for the developers) that would only produce a tangible benefit to a very small sub-set of players. And it goes against the design philosophy of the game, which is to sacrifice realism to conceptual simplicity. It's very nice that you can use analytic equations to solve all orbits in KSP; means that it provides an entry point for the use of maths for someone who might not have seen the utility of algebra before.

If you want to visit Lagrange points, download Orbiter. It's free, and uses numerical methods -- described in detail here in the document called dynamics.pdf -- to determine orbital trajectories. The document also describes how, when, and why the simulation falls back to Keplerian orbits at high time-steps. Reading the Orbiter forums suggests that it is actually pretty difficult to reach and orbit the libration points because they are invisible. (Though there is an add-on to make them visible.) And though it's been mentioned a couple times, I can't find any references to someone actually successfully using the ITN in Orbiter for interplanetary transport.

[Mattasmack]

I didn't reply to anybody in particular, I've just gathered this across multiple threads on a subject. As for trigonometric functions, there are easy approximations (like lookup tables) - infact some earlier video cards used built-in lookup tables for them instead of actual computations.

That's something I played around a bit with yesterday, actually. I divided each body's orbit around its parent into segments and precalculated fifth-order polynomials in each segment to approximate its location. That's not at all optimized, but it worked surprisingly well. The number of segments needed for maximum location error less than 1 m ranged from 11 (for moons with circular orbits) to 118 (for Eeloo, with its large and eccentric orbit). The total amount of data to be stored was just under 100k, and I got about a 3x speedup above the fastest implementation using sines and cosines.

...

At first I was thinking about implementing a mod that would calculate and display in map view "real" trajectories along with built-in ones so we would be able to validate that calculations work as we expect them in all modes, including time warp. This sounds like a good enough first stab at subject.

Yeah, just being able to display the Newtonian trajectories alongside the patched conics ones would be a benefit, I think. It answers the question, "so just how much difference does it make?"

What I need is state vectors propagation function (over integration step). Essentially, it's the function (x₁, v₁) = f(x₀, v₀, dt). I do know Newton's second law (dv/dt=F/m) that would allow to come up with simple function, but it's not going to be accurate enough for our case. Let's leave rotational state propagation alone for now - we can always add it afterwards once we're done with the main thing. In addition it would be great to have some sort of interpolation function that would provide ability to calculate state vectors in between steps (i.e. let's say we have a lookup x_i => t₀ + i * dt, but we want to estimate x at the moment of t₀ + (i + 0.3) * dt).

And as a bonus it would be great to have a function that would allow calculating Keplerian orbital elements (eccentricity, semi-major axis, inclination, LAN, argument of periapsis and mean anomaly) from state vectors since that would help with displaying this info. I could come up with this function myself, but if you happen to have it handy, I'd appreciate if you'd share it.

Please create a thread in "Addon Development" section since that seems to be more appropriate place, and let's go from there.

I can't promise anything until the weekend, but I show have a fair amount of spare time to come up with some prototype. Thank you!

Thread created, let's see what happens. I'm in no hurry; I don't know anything about modding KSP so I'm going to try to educate myself a bit in the next couple of days, which will certainly keep me busy.

I haven't written out the equations here on the forum because there are lots of them and I'm not eager to struggle with formatting them here to get them readable. I'd rather just point you to the paper I used for a reference, Shampine (1986). The Butcher tableau on pages 148-149 is what I used, and it covers both the time integration and producing enough information to generate interpolation functions within a time step. If you'd like more detail, I'd just as soon show you my code.

[Mattasmack]

Well nobody ever said that the current Kerbin system was even a stable orbital system. For all we know a full Newtonian simulation will have Kerbol ejected into deep space by Jool.

That explanation does make sense though. Wherever you put the satellite it will orbit around the systems center of mass, but the planets themselves are not doing so. If you had two equally sized objects it would horribly bust the orbits as they should orbit around their center but one of them gets to be stationary while the other does the orbiting. Add a third object there and its path will be completely wacko. The question would be does that mean no L-points exist at all or just that they aren't where they are supposed to be. I would track the orbit of a large number of initial points and plot where they go, if there is an L-point they should pop out of such a plot.

I really want to do an n-body simulation of the Kerbol system, just to see what happens! I expect to see moons flying all around the system, it should be awesome.

I'm not sure why the continued calls for n-body physics in KSP. It's already drastically scaled down. All of the bodies are unrealistically dense. None of the planets have axial tilt. And all of this was done to make the game more accessible; n-body physics adds a bunch of complication (for the developers) that would only produce a tangible benefit to a very small sub-set of players. And it goes against the design philosophy of the game, which is to sacrifice realism to conceptual simplicity. It's very nice that you can use analytic equations to solve all orbits in KSP; means that it provides an entry point for the use of maths for someone who might not have seen the utility of algebra before.

If you want to visit Lagrange points, download Orbiter. It's free, and uses numerical methods -- described in detail here in the document called dynamics.pdf -- to determine orbital trajectories. The document also describes how, when, and why the simulation falls back to Keplerian orbits at high time-steps. Reading the Orbiter forums suggests that it is actually pretty difficult to reach and orbit the libration points because they are invisible. (Though there is an add-on to make them visible.) And though it's been mentioned a couple times, I can't find any references to someone actually successfully using the ITN in Orbiter for interplanetary transport.

Well, conversations in this vein seem to gravitate to n-body simulations. If nothing else, it's an interesting question of what would happen (see above) as long as it hasn't been tried. But I explicitly, and specifically, started this thread with a scheme that is not n-body simulation. And that avoids the need for very high-order numerical methods and/or short timesteps by not switching to Newtonian mechanics until an object reaches a relatively high distance from all planetary bodies. (Though higher-order methods than the ones I looked at would still be beneficial, I assume.)

[asmi]

Thread created, let's see what happens. I'm in no hurry; I don't know anything about modding KSP so I'm going to try to educate myself a bit in the next couple of days, which will certainly keep me busy.

I haven't written out the equations here on the forum because there are lots of them and I'm not eager to struggle with formatting them here to get them readable. I'd rather just point you to the paper I used for a reference, Shampine (1986). The Butcher tableau on pages 148-149 is what I used, and it covers both the time integration and producing enough information to generate interpolation functions within a time step. If you'd like more detail, I'd just as soon show you my code.

In this case your code would help a lot to me. I know C/C++ just as good as I do C#, so language is not a problem at all. If for some reason you'd prefer your code not to be published, feel free to PM me a link to it.