snuffy5000000

@Thiel Honestly it doesn\'t bother me, I only interjected because I thought that people were assuming that it was n-body resolution or bust and wanted to say that there is a third solution to the problem which I think would work well in KSP. I personally have no problem with how it works now though and I\'d rather see more fun features than a lengthy rewrite of the engine. Just contributing for the sake of discussion. Also in general changing out one method of resolving the force of gravity for another should not the colossal undertaking that people are suggesting, modular code is our friend. Though I totally understand that Unity may introduce unavoidable stumbling blocks.

@PakledHostage Ah yes, I\'m sure the devs have thought much more about this than I have and there is definitely no \'simple\' answer. I\'m sure that they will eventually find a more elegant solution than patched conics which doesn\'t really seem to fit with a real time interactive engine but in the mean time there is plenty more game play stuff to do Anyway I\'ll let this thread die as it does seem to have been rezzed from some time back.

I\'m sorry I don\'t mean to argue but I\'m not sure I communicated correctly what I was suggesting. By 'on rails' I mean the orbits of Kerbin, Mimas and the Mun are hard coded ahead of time, simply circular paths offset by the position of their parent body. This means that they are not reactive bodies in the simulation, and as such they cannot be shifted off their predetermined path. At a given time, they are always in the same place. So there wouldn\'t be 5 interacting bodies, in fact no two bodies would interact because only the player\'s ship would be effected at all by gravity. My understanding of the n-body problem is that a 2 body problem is body A affects B and B affects A, and a three body problem is body A affects body B and C while body B is also affecting A and C and C is affecting A and B. In my suggestion body A\'s position is a function on the time, i.e. at a given time, position is the same, and body B is affected by the gravity from body A. In this way body A, B, C and D are all defined by a fixed function, not dependent of any other body, and body E (your ship) is affected by A, B, C and D. hence 4 one body problems, not one 5 body problem. This is obviously a naive solution but this game is about flying your ship, not simulating the movement of the planets, so this would maybe be enough.

Hey, forgive me if I\'m wrong here but I\'m not quite understanding why an N-Body sim would be necessary. The planets and moons are on rails and the largest player-launched stuff is far too small for objects to have a noticeable effect on each other. I mean, yes, in the real world they would exert force on each other but in a KSP any effect would be so small it would be eaten up by floating point errors anyway. Just make it so that every celestial object exerts force on each player objects and no object exerts force on a celestial object. Basically only objects on rails have gravity and only objects with no gravitational pull can be affected by it. This would mean that the force on a ship would be the sum of n one-body problems, here n being the number of gravity wells. In the current game this would take at most 4 times longer than a patched conic sim which would be a single two-body problem per object. The upshot is that every celestial body would effect the players ship at once though the players ship could not effect other bodies. Or am I totally missing the point?