Aerobraking and apogee Caleuche (29 Jan 2018 08:35 UTC)
Re: [TML] Aerobraking and apogee Thomas Jones-Low (30 Jan 2018 00:14 UTC)
Re: [TML] Aerobraking and apogee Rupert Boleyn (30 Jan 2018 00:24 UTC)
Re: [TML] Aerobraking and apogee Tim (30 Jan 2018 01:04 UTC)
Re: [TML] Aerobraking and apogee Caleuche (30 Jan 2018 05:58 UTC)
Re: [TML] Aerobraking and apogee Kelly St. Clair (30 Jan 2018 06:28 UTC)
Re: [TML] Aerobraking and apogee Caleuche (30 Jan 2018 06:53 UTC)
Re: [TML] Aerobraking and apogee Caleuche (30 Jan 2018 01:14 UTC)
Re: [TML] Aerobraking and apogee Caleuche (30 Jan 2018 03:11 UTC)
Re: [TML] Aerobraking and apogee Tim (30 Jan 2018 04:10 UTC)

Re: [TML] Aerobraking and apogee Caleuche 30 Jan 2018 01:14 UTC

Yes, those maps are useful (and there's one for KSP's mini solar system as well). It is, in effect, the heliocentric two-body difference in specific orbital energy between the two orbits. In some cases there are somewhat more efficient transfer orbits available such as the bi-elliptic transfer or orbits that take a fair amount of computation as they're considering an nbody rather than two body system when computing the transfer.

Everything I've been computing in terms of orbit motion comes down to F = m a, the key being able to determine the net forces acting on an object, but it ends up being a fairly mundane set of second order ordinary differential equations that must be evaluated numerically and the fun is selecting (and coding!) appropriate numeric methods to evaluate them (though Mathematica's built in solvers are quite good for most cases). A more robust model for atmospheric capture does require evaluating the NS equations and that's probably beyond where I want to go for game purposes. Once you have the system in place though, it's moderately offensive that objects are being treated as if they move under constant acceleration, rather than constant thrust and varying mass and acceleration (as force varies anyway as you move through a gravitational field - why not handle varying propellant mass at the same time?)

Evaluating the system in such a way that you duplicate known relativistic effects can also become an issue at times, but there are manageable ways to do that these days, such as the suddenly bizarrely popular relativistic Newtonian dynamics ( https://en.wikipedia.org/wiki/Relativistic_Newtonian_dynamics ), but even systems like Find_Orb (in use by real astronomers for real astronomy tasks) only compute relativistic effects from the Sun's influence.

Sometimes fun problems fall out of some of the numeric evaluation, for example say you appear 100D from a world, constantly accelerate at 1g toward the world, turn over at some point and decelerate at 1g intending to touch the surface of the world at exactly 0 velocity, The turnover point is not the halfway mark, as you are falling into a gravity field that is increasing in strength as well​. (16 year olds have more fun with these kinds of problems than they do with typical story problems, so Traveller can serve as a worthwhile learning tool and story problem generator).

In short, the details of the physics are often much more simple than the game rules that are trying to simply duplicate the real world physics.

-------- Original Message --------
 On January 29, 2018 4:14 PM, Thomas Jones-Low <xxxxxx@gmail.com> wrote:

>
> I thought you might also be interested in this, a subway style map of transit
> requirements from earth to other worlds in the solar system.
>
>http://i.imgur.com/AAGJvD1.png
>
> One of the challenges I've seen out of this thread is taking detailed
> information (like delta-V requirements) and presenting it in a clear manner for
> viewers that may not be as interested in all of the details. But this is a neat
> approach.