Transfer Orbits

[whartung]

Just want to make sure, but basically with the technologies of something like Traveller, there is simply little reason to use things like transfer orbits and sling shot effects to maneuver in the inner solar system, correct?

Rather it's pretty much going to be (roughly) point, shoot, and brake when you get there.

The premise being that Traveller has very powerful engines and very cheap fuel (even in TNE).

Obviously these affects are available, but since a 1G drive can get you from Earth to Jupiter in about a week, there's not a lot of motivation of a low energy transfer orbit. Just turn and burn.

In TNE, I think there would be a lot of in system jumping, if fuel is cheaper than time. (Takes about 3 weeks and 20 Ghours to get form Earth to Jupiter with TNE -- Jump is faster).

 

[deadlock]

whartung:
Just want to make sure, but basically with the technologies of something like Traveller, there is simply little reason to use things like transfer orbits and sling shot effects to maneuver in the inner solar system, correct?

Incorrect. There are plenty of worlds that have not discovered or use Maneuver and Jump drives for a variety of reasons.

 

[far-trader]

Incorrect. There are plenty of worlds that have not discovered or use Maneuver and Jump drives for a variety of reasons.

Fair point, but for all the rest (and certainly the majority of game play) it will be pretty much as whartung said: Point (1), Shoot (2), and Brake (3).

It is a little more complicated...

(1) You want to point where your destination will be at the end of your trip time. Aim where it is now and you'll be chasing it down all the way and take much longer getting there. You'll be travelling in an arc instead of a straight line. Traveller glosses this over of course, but it's important in such cases as drive breakdowns or damage...

(2) aka Thrust applied, in Traveller, steady to the half way point. Now if for some reason your drives malfunction (I roll at the start, midpoint and endpoint) you could be in trouble so many different ways. If your drives fail at the start it's no big deal. If they fail at the midpoint turnaround you can't stop (or start stopping) until they are fixed and you'll go on in a straight line forever if you don't fix them. In any case you'll be late for where you were going.

(3) aka Thrust applied, though to slow and stop you where you want to be, in orbit preferably. If the drives fail at the end you're left in orbit while you fix them which is probably not a big problem. Most of the time.

 

[Icosahedron]

Strictly, you'd need to figure in your orbital speed at both ends, too, if you're going orbit to orbit.

 

[far-trader]

Strictly, you'd need to figure in your orbital speed at both ends, too, if you're going orbit to orbit.

True, another bit glossed over I wonder if it would be significant though? About 30km/sec for Earth iirc which you cancel with about 3G turns. So less than an hour with 1G drive, a few minutes with 6G drive. And you would not need to cancel all of it or add much too it. Maybe figure 35 minutes extra, less 5 minutes per G?

 

[aramis]

More like 6/Gmd, Dan. Divide, not subtract.

 

[Starviking]

How about transfer orbits for bulk non-perishable insystem cargo? Boost it up, let it coast, rendezous at target?

 

[whartung]

The classic transfer orbit requires two bits of thrust -- the first to knock it out of the original orbit destined to the new one, and the second to actually place it in the final orbit. So either the payload needs to have a drive of its own, or you need a tug of some kind at the other end to "Catch it".

Then there's simply the time involved over any long distance.

With the thruster plates, you have, effectively, unlimited acceleration (Jupiter in a week with a 1G drive) while simply running the power plant. Whereas with TNE, it's much more frugal since it takes in to account reaction mass.

Currently all of our current operations are rightly fixated on low energy maneuvers, low fuels costs, etc. Mass and fuel affect everything. In Traveller, this is not the case, particularly with thruster plates.

Finally, I see a lot more intrasystem jumping in TNE than I do in regular Traveller, simply because it's faster to jump than maneuver to the target.

It also dramatically affects ship design I think. Save for combat vessels, a TNE vessel would rarely need a drive beyond 1G, if even that much. With a thruster plate ship, a larger M Drive makes a lot more sense, since it can dramatically affect travel times. But a TNE ship, the fuel is the limiting factor, not the drive.

For example, on a TNE ship, with a limit of burning 20 G-Hrs of fuel, a 5G drive will get a ship to Jupiter a 1/2 day faster than a 1G drive. But that's only 1/2 day out of 21+ days total travel. Not much of a savings.

With Thruster plates, it goes from 5.86 days for 1G down to 2.62 days. More than twice as fast. A great benefit. And, of course, the Thruster plate ship will actually have fuel for a return trip, a TNE ship will not.

Rather, I think the TNE ship will coast to the 100D limit, then jump, and fly in for the Jupiter trip.

 

[Hal]

For those who want to have fun with a bit of math involved... (and of course keeping it SIMPLE), here's a thought to try out.

Determine the orbital velocity of a planet based on determining the length of orbit (the circumference of the orbit) divided by the time it takes to complete one complete orbit. Then, assume that the ship in question has the escape velocity required to reach orbit of any given world - as its starting velocity. From there, determine just how long (in theory) it will take to reach the target world, from where the ship starts out. Determine where the world would be in the time it takes for the ship to traverse the expected distance. Modify your old original plot (time wise that is) by the additional distance that has to be travelled (or less distance as the case may be - perhaps the planet is actually moving towards you as it moves around its curved orbit?).

That more or less is what would be required of the navigator in the event you want to do planet to planet travel. There is however, one "case" that has never been covered by the official rules of Traveller...

What happens when your target world is on the other side of the sun(s) within the star system? How close can one shave their path near to the sun within the star system? When dealing with navigational laws, what might the Imperium mandate as minimum closest approach to the sun in the event that a ship's drive should fail and the now ballistic vessel is involved in possibly perishing because it cut its trajectory too close to the sun in question?

It would be fun if somone were to create a program to do all those rudimentary calculations for use with Traveller

 

[mike wightman]

When jumping between systems the stellar velocity around the galactic centre should also be considered since velocity is maintained through jump...

 

[Hal]

I think I figured out how to make the navigation program work...

While it may sound complicated, it isn't. Using Polar Coordinates so as to determine how far a planet will move from its current location to a new location based on degrees traversed per time unit - determine the endpoint of the planet at the end of the given time period. This is the "destination point" or the aim point that the ship is trying to reach. Using the formula given in Book 2, determine based on ship's accel - whether or not it will reach the same point the planet does at the same time. If TPlanet = TShip for a given X/Y coordinates, then you have your solution. IF Tplanet <> (ie not equals) TShip, then the "loop" continues.

Start of program assumes the following built in parameters:

distance to be travelled is equal to 1/2 the actual distance between ship's starting point and the planet's starting point.

Increment time by 1 second. Compare planet's new position with the time it will take a ship from its starting position to reach new planet's position. Probably will not be a match, so the loop continues to increment time required to reach the planet's new position 1 second further from its start position than before. Eventually, the time taken for a planet to reach a given point will equal the time it takes for a ship to reach the exact same point at max accel/decel. This becomes the time required to reach the planet at max acceleration and deceleration and will show where the navigator has to aim his ship, "leading" the planet by its initial orbital velocity. Ideally? Such a program would permit the "navigator" to feed in as input, the average velocity up to and even equalling the max velocity of the ship. For example? Where does the ship have to "aim" for a given planet if it wants to use .001 G's of constant acceleration/deceleration?

 

[Merxiless]

"It would be fun if somone were to create a program to do all those rudimentary calculations for use with Traveller."

I'm on it. I always wanted to do something like this.

I used to do this by hand, with a TI-85, but it got tedious.

 

[dean]

This looks like a likely source of definitive answers

 

[Icosahedron]

Hal, your 'first stab' is a brave attempt, but this is a complicated matter. As Dean's link shows, unless you know when to start your journey, your increments could have you chasing the planet around several complete orbits before you find a 'solution'.
I try to avoid too much realism - you get there when your GM says you get there.

 

[Hal]

Hal, your 'first stab' is a brave attempt, but this is a complicated matter. As Dean's link shows, unless you know when to start your journey, your increments could have you chasing the planet around several complete orbits before you find a 'solution'.
I try to avoid too much realism - you get there when your GM says you get there.

Now this problem is going to occupy my mind for a time to see if I can do it

The key to all of this is that not only do I increment the time tick by a given value (1 second, 10 seconds, 100 seconds, 60 seconds, an hour - what ever works best) but I have to keep in mind the following:

There has to be a limit where the ship may not pass closer to the sun than by a given amount. What this limit is - defined as the autodestruction zone, needs to be determined based on the sun's luminosity value. If someone said that the ship can come no closer than .1 AU's to a G2 main sequence sun - then I'd have to create the program to exclude any solutions that permit the ship to enter into that forbidden zone. All else being equal, keeping track of how many times a planet traverses its orbit is easily enough done. If Azimuth of planet = or > than 360, reset azumuth to current azimuth-360, and add 1 to the completed orbits counter. Then, when comparing time required to reach the intercept point by the planet and by the ship, I add the (Completed Orbits Counter x time required to complete one orbit) plus the time required to reach the X/Y point in space from the planet's original starting point for the simulation.

So, can it be done? Time for me to wrestle with it. Frankly? If someone beats me to the punch and creates their own C+ program, java program, or Visual Basic program, I won't complain I'd just like to see that it be done even if it is a rough draft copy so to speak.

 

[Icosahedron]

I'm sure it can be done - I imagine NASA did it. However, it's not something I'd want to spend my precious spare time on, even if I were convinced of my mathematical ability. I posted my solution above. Best of luck with it, though.

Sudden thought - try the website of 'Nyrath the Nearly Wise' (Winchell Chung IIRC?) It's just the sort of thing he might have done already. Sorry, I don't have a link but you should be able to find him.

 

[Merxiless]

Seems to me, that going from orbital velocity in a transfer orbit, to another orbit, you are not gonna be anywhere near the sun in a single primary system, unless for the exact opposite side of the sun at arrival kind of long extremely elliptical orbit.

But your concerns are valid. someone with more knowledge of solar radiation, chronoshpere etc could say more about close approaches to any solar body. I'm definitely not that guy.

 

[whartung]

Here's the thing.

In Traveller, we don't need Hohmann Transfer Orbits. That's what the point of my original post. Just turn and burn. HTO's are handy when you're trying to maximize fuel and overall vehicle mass -- neither of which is really a problem in Traveller.

So, how do you "solve" this problem?

Easy.

Let's say you want to go from Jupiter to Earth, because, frankly, the short flights are uninteresting (What to go to the moon at 1G? Put the moon in your viewscreen and light the rocket).

Then, you make a couple of assumptions. Notably that we won't be "dodging" planets, even something as big as Jupiter. We'll "go over" or "go under". The body simply isn't big enough of an obstacle (when it's all said and done) to bother accounting for. Next, we'll assume that planets have constant velocities. Yes, they vary "a little" at the extremes, but not enough to matter.

We'll make the star "Special" and try to avoid it. Other than that, gravity, asteroids, rocks, comets -- ignore them. We have power and thrust to burn, so we'll use that to "move around" anything like that. It's simply not worth the complexity.

So, how do we get to Earth from Jupiter?

Earth's orbital speed is:

155M Kilometers from the Sun, thus it's orbit is 2 pi R = 2 x 3.14 x 155M = 973.4Mk

973.4Mk/365.25 days = 2.67Mk per day, or 111Kk per hr. That's, basically, 1 degree of motion along the orbit, per day. Put the Earth someplace in the orbit, doesn't matter where.

We'll assume for the sake of discussion that he earth is at it closest point to your location, and that as time passes, it will only move farther away.

Earth and Jupiter are 588Mk apart.

With a 1G drive, accelerating and decelerating the entire time, it take ~5.6 days to get 588Mk, and be at velocity zero.

If you do the simplest thing and "aim" at where the earth "was", how far are you off?

Well, the earth moved 5.6 days down orbit. That's, roughly 15M kilometers, or about a 20hr flight.

So, if instead, knowing it's going to take 5.6 days to get there, let's move the earth to the earth down that far along the orbit and plot that course instead.

Well it turns out that 588Mk at 1G take 5.67 days. If you instead aim for the Earths estimated destination in 5.67 days, it turns out that it's new destination is only 5.68 days trip from Jupiter -- 590Mk instead of 588Mk. That's well within margin of error and correction.

So, after two quick iterations, you have your plot.

Now, how do you "dodge" a star? Simple. Do two plots. When the star is in the way, only real choice is "which side of the star will the planet be closest to". i.e. Should I plot going around the left, or the right side of the star. Once you've done that, simply plot for that course change, then plot a new course towards the planet.

Remember, that barring gravity, each course change will likely require deceleration. Especially with M Drives in Traveller that constantly accelerate.

On this trip from Jupiter, you're pushing 2300+ km/sec. That's a lot of velocity to scrub off.

Finally, in TNE, you have to be more accurate and more careful. Fuel matters there, whereas it doesn't in other versions. But, I see in system jumps being far more routine in TNE simply because of that. The trips are so long, it's simply faster to Jump than fly.

 

[samuelvss]

Thoughtful discussion, but a couple of observations.

There are so many variables, that the actual calculations can bog down a great deal. This is justification to simplify for playability, but allow for randomness to represent some of this abounding complexity.

Figure a distance between the orbits, and multiply by (2D6 x 10) + 30 percent. That will give you a somewhat normal distribution around 100 percent, varying from 50% (in about 2.8% of the times) to up to 150% at the top end.

This is also a space where the navigator's skill could come in. Allow a subtraction of the navigator's SL in percent. Here, a REALLY good navigator can reduce the distance by a maximum of 5%, assuming obital physics is orbital physics, but that by using more tricks a little advantage can be gained.

Another idea is that since maneuver drives can fail on the decceleration leg, every trip should be headed for an orbit on the far end. If drives fail, the ship will still be going far too fast for any graceful alighting, but the orbit (even if it is a decaying orbit - more drama), will allow time to fix things rather than burning in or driving right on by. Subcraft may simplify the crews situation. If drives don't fail, then toward the end of the decceleration, this orbit is vectored out of.