T5 M-Drive distance limit
- Thread starter sudnadja
- Start date
Yes it's "Wolfram Language", it's not easy to show some of these things because it's scattered across a bunch of different helper functions and mixed in with the equations of motion for other forces as well. I'll translate it to Go or C at some point.
But basically: given every position update (whenever the ODE Solver decides to set its tilmestep at that moment) compute the gravitational potential energy the ship has relative to the target - you'll get net acceleration possible due to gravity from v == Sqrt[m g h] 1/2 and subtract from that total deceleration possible from the ship (just sum up the different performances via a piecewise function). You can extend that if you want to include the vector components of other gravitational sources with the same Sqrt[m g h] 1/2, just with an h relative to the position of the other body. If current velocity plus integrated gravitational potential energy when converted to kinetic energy is greater than (or close to) deceleration potential, turnover and begin decelerating. Keep in mind that you don't really want to aim for the target planet's center position and velocity, aim for a chosen orbit's position and velocity so when you turn off the drive you are in orbit already.
I transform everything into the frame of the moving ship and generally operate within that frame.
Last edited:
That's would be great to see.
I mostly follow this, as that's essentially what I was doing in my simulation. I simply compared where I was, how fast I was going, how fast I COULD be going (i.e. if I accelerated more) and compared that to how close I was and how much declaration I needed to get there.
And it was even able to coast by setting a maximum velocity over which I wouldn't accelerate any more.
This mostly worked, but I was doing it as a "real time" animated display, rather than a bunch of coordinates to show the path. And I didn't have anything of note for orbital insertion.
Simply my plan was "when I got close enough that my vector and the orbital vector differ by less than the drive potential, then just put the ship in to orbit with a 'magic burn'".
Kind of like how the game rules deal with missile strikes. "When it gets Close Enough, just Hit the Target".
I haven't looked at this in some time.
But, also, both our techniques are iterative. Maybe that's just how differential equations are solved numerically.
There are analytic solutions to the two body problem and many kinds of differential equations but I don't believe there is an analytic solution to this one. It would be a two body problem if you discount gravity and only worry about ship's thrust (and in fact, that problem can be solved without calculus) but with more than one applied non-uniform force it's no longer two body.
There is a giant field of study around numerical methods which are essentially to solve ODEs that don't have analytic solutions. Generally in the first 3 or 4 chapters of a astrodynamics textbook they'll introduce modern numerical methods as they're needed to solve these sorts of problems. As I mentioned before, even lambert's problem (used for interplanetary transfers) is a BVP that is solved via some form of "intelligent" iteration.
If you were trying to iteratively evaluate your system ("every 1/60th of a second for frame refresh advance the simulation time by 1 hour, add accelerations due to force to velocity and add velocity to position") it's very likely to be unstable. This is essentially Euler's method in explicit form with a fixed (and large) timestep. You need a method that is variable timestep or a symplectic integrator.
For my purposes, instability and loss of precision aren't a real big issue. If it makes a single orbit, it's good. Once in orbit, the ship is "in orbit" and "it's stable", rather than having to recalculate its actual orbit every minute.
What I'm looking for is much what you demonstrated.
Simply, I'd like to have a ship, in orbit, in an arbitrary system, and be able to plot a "realistic" course to an outer system body or to a jump point, and similarly when I arrive at a system (taking in to account the net ship vector on arrival) plot a realistic course to the destination.
Extra brownie points for routing around the solar mass due to jump shadowing or avoiding Jupiter to get to Saturn because "it's in the way".
"Oh, the Earth. I was going to blow it up. It obstructs my view of Venus."
It's not just the ship, the moons have to remain in orbit of the planet and the planet in orbit of the star and so on. You could treat the motion of all of those objects with Kepler two-body elements but for me it's actually more difficult to work that into the n-body integrator than just directly compute their motion just like all of there objects.
I need to package all of this up and make it usable by other people. My system is very specific to both Mathematica and the way all of my utilities and helper functions have congealed over the years and have somewhat isolated me from the way everyone else does things. (Even to the point that when the latest version of Mathematica actually included a specific nBody solver I kept using my collection of automatically-generated-differential-equations system as I have more control over what's happening).
I do compute jump shadowing / jump masking, and that's actually quite a bit easier than the turn around problem, but I do so for a 3d universe and most people run Traveller in 2d. I'd posted and example of it before:
But to compute jump shadows, you need the instantaneous position of the orbit of your departure world - you need to be able to compute its position in orbit at an arbitrary given time and the positions in orbit of the destination worlds. Basically, in addition to a UWP or even in addition to the expanded T5 system rules, you need orbital elements for each object as well. I should be able to leave the system and return 15 months later and the world is in the correct position in orbit.
Sure, but there's no reason to actually model them typically rather than just project them.
For example we all know that orbits are ellipses and such, but for most purposes, especially game purposes, they can readily be modeled as simply circle centered on a star with radius R and orbital velocity V, rather than as an object with mass interacting with other objects of mass (i.e. Earth holding the moon, while the Sun holds the Earth, while both fight with Jupiter). Modeled this way, the orbits are implicitly stable, and the simulations don't need worry about accumulated error, since it always "knows" where everything is. "At 10am on the 30th of May, year 1115, Jupiter will be at jX, jY in system S".
Yea, your charts have always impressed.
Right, and using a static method of placement (i.e. radius R, velocity V, time T) makes all that easy.
You can simply put all of the system objects starting at degree 0 off the main star, with time 0 being Year 0, Day 1, Month 1. By the time you get to imperial times, year 1100 plus, the planets will all be scrambled up and be as "realistic" as anything, simply computing bearing offsets based on V (measure in radians or degree per unit time) * T mod (360 degrees or 2pi radians).
If you don't like that, just add a random start bearing offset for each body in the system, and go from there. Certainly more than adequate for gaming. And, if you want ellipses instead of circle, you know, logic is the same -- be my guest
.For game purposes, depending on the nature of the game, you don't even need that. I would disagree that treating the orbits as a circle work for most purposes - though I have caught in Traveller 2300 material authors presuming an elliptical orbit and stating it, yet seemingly unaware that objects in an elliptical orbit move faster when they're closer to their primary and end up with statements implying that "great seasons" are of equal length when they couldn't be.
I do have a system which I can say "show positions at time=n" and it will do so from the kepler 2-body elements (which works fine with ellipses too, though I need to make it work properly with hyperbolic orbits yet). The top two panels of this diagram come out of that for the Lusor/Regina system, while the bottom panel is n-body output. The two body system naturally won't model the wobbling of the barycenter as Speck orbits Lusor (which has a more dramatic effect than implied in Book 6) but a hybrid system in which I initialize the nbody system with two body elements can kind of work - but I do need elliptical orbits to work properly.
Yea, your charts have always impressed.
Right, and using a static method of placement (i.e. radius R, velocity V, time T) makes all that easy.
You can simply put all of the system objects starting at degree 0 off the main star, with time 0 being Year 0, Day 1, Month 1. By the time you get to imperial times, year 1100 plus, the planets will all be scrambled up and be as "realistic" as anything, simply computing bearing offsets based on V (measure in radians or degree per unit time) * T mod (360 degrees or 2pi radians).
If you don't like that, just add a random start bearing offset for each body in the system, and go from there. Certainly more than adequate for gaming. And, if you want ellipses instead of circle, you know, logic is the same -- be my guest
I do, naturally, include the two body elements in the database I use for the game:
- the "random start" is the anomaly at epoch, but essentially I'm already doing what you suggest there.
All depends on your overall goals of course. As I said, it's only a minor leap in complexity to jump from circular static orbits and elliptical ones. The overall point was to have them be static and trivially computable rather than having to model the entirety of the systems, all the time when most of the time you're (I'm) just interested in a ships course.
With a trivially computed system, you don't have to worry about the stability or precision of the ongoing simulation. Just need to put the pieces on the board and route the ships around them.
I agree. I don't really think there's much more to pursuing this in the Traveller context and am going to completely drop it. Thanks for the commentary
