• Welcome to the new COTI server. We've moved the Citizens to a new server. Please let us know in the COTI Website issue forum if you find any problems.
  • We, the systems administration staff, apologize for this unexpected outage of the boards. We have resolved the root cause of the problem and there should be no further disruptions.

Science and Planetary Approach

Makofan

SOC-1
I am a bit confused, so I thought I would ask scientists about this question. During approach to a planet, do you have to take into account the planet's vector?

I am going to use planet Earth as an example. Let's round its diameter off to 13000 km, and its speed around the sun to 30 km/sec. 1G acceleration is 10 km/sec. If my ship appears 100 diameters away (say, 1.3 million km), and start accelerating to Earth at 1G, it is going to take 6 or 7 hours, I believe. But the earth itself is travelling 30 km/s, so won't it take even longer to get there as it moves away from the ship? Or shorter, if they are in front if the earth's orbit?
 
I am a bit confused, so I thought I would ask scientists about this question. During approach to a planet, do you have to take into account the planet's vector?

I am going to use planet Earth as an example. Let's round its diameter off to 13000 km, and its speed around the sun to 30 km/sec. 1G acceleration is 10 km/sec. If my ship appears 100 diameters away (say, 1.3 million km), and start accelerating to Earth at 1G, it is going to take 6 or 7 hours, I believe. But the earth itself is travelling 30 km/s, so won't it take even longer to get there as it moves away from the ship? Or shorter, if they are in front if the earth's orbit?

Yes, but in canonical Traveller, the Jump Drive conserves momentum thru Jump. Meaning that the ship will exit Jumpspace in the destination system with the same momentum vector it had when it entered Jumpspace in the originating system. So it also matters what the relative momentum difference is between the two star systems.

But also consider, a smart pilot knows what the momentum of the destination system is before he even makes the Jump, and will pilot his ship in the originating system in such a way as to match the vector that he desires to have when he comes out of Jumpspace.
 
I am a bit confused, so I thought I would ask scientists about this question. During approach to a planet, do you have to take into account the planet's vector?


Do you have to? Of course not. It's a game, not MIT's Orbital Mechanics 210 sophomore midterm.

I am going to use planet Earth as an example....

Everything you wrote is correct. What you should be asking is whether it's fun and you should be asking yourself that rather than someone else.

It's a game. It's not a simulation. It only models things up to a point. While where that point exists depends on the individual in question, the fact is that the point still exists.

Don't sweat it. You're playing to have fun.
 
I am a bit confused, so I thought I would ask scientists about this question. During approach to a planet, do you have to take into account the planet's vector?

Actually the best way to put it is that you have to take in account the planet's orbit. As mention jump drive conserve momentum so you want to enter jumpspace with a vector that will allow the starship to be in the same orbit as the planet around it's primary.

Then from there you solve for a constant thrust trajectory to the desired orbit around the planet.

Given that Traveller uses constant thrust drives you can consider lining up the proper vector for emergence as part of the processing of getting out to 100D and initiating jump.
 
OK. I am going to assume the Navigation software and awesome computing power calculates all that so that the simple math works.

The reason I asked is that in a space battle, if your merchant is running for the starport, I would need to move the planet 3 inches every turn
 
I am going to use planet Earth as an example. Let's round its diameter off to 13000 km, and its speed around the sun to 30 km/sec. 1G acceleration is 10 km/sec.
Acceleration is not speed, it's change in speed. The Earth moves by 30 km/s. Your ship can change its speed by 10 m/s² or 10 m/s every second or 10 km/s every 1000 s (≈16.7 minutes). If you start from rest relative the Sun (questionable) it will take you 3000 s (almost an hour) to match speed with the Earth.

Note that you theoretically need to take the stars relative speed in consideration too.

If my ship appears 100 diameters away (say, 1.3 million km), and start accelerating to Earth at 1G, it is going to take 6 or 7 hours, I believe. But the earth itself is travelling 30 km/s, so won't it take even longer to get there as it moves away from the ship? Or shorter, if they are in front if the earth's orbit?
Yes, but not by all that much.

Say you start 1.3 million km from the Earth and it will take you about 7 h to reach it. The Earth moves at 30 km/s so will have moved 7 h × 3600 s × 30 km/s = ~750000 km.

So you will have to travel ~2 million km to reach the Earth, presuming you chase it down directly from behind. It would take about 2 × √(2 000 000 000 m / 10 m/s) ≈ 28000 s ≈ 8 h.

The formula is not exactly correct since it assumes you start and end at the same speed, which you don't, but it's not all that wrong.
 
OK. I am going to assume the Navigation software and awesome computing power calculates all that so that the simple math works.

The reason I asked is that in a space battle, if your merchant is running for the starport, I would need to move the planet 3 inches every turn


Seeing as you're using LBB:2's vector combat system, your players are still going to have to plot some sort of course which will allow them to intercept the planet on the proper vector. They just can't zoom past it and think they're magically saved. They're going to have to "sidle" up "alongside" the planet while matching the planet's own vector.

Are your players up for that challenge? Are you the referee up for that challenge? Have anyone of you played a game using vector movement yet? The reason I'm asking is that it tends to trip people up the first few times, especially the need to begin decelerating well before you think you need to and especially how long it takes to change direction with even a moderate velocity.

Also, take a look at the ship weapons ranges in LBB:2 and compare that to the planet's 100D limit. Ships, stations, highports, or defense satellites orbiting the planet may be able to help your players' ship long before it reaches the safety of the port.
 
Last edited:
Seeing as you're using LBB:2's vector combat system, your players are still going to have to plot some sort of course which will allow them to intercept the planet on the proper vector. They just can't zoom past it and think they're magically saved. They're going to have to "sidle" up "alongside" the planet while matching the planet's own vector.

As an added detail, I would expect most planetside Traffic Control systems require incoming vessels to plot and fly a "missed approach" course that specifically does not intersect the future path and position of the planet itself should the m-drive fail (for any reason) at any point during the approach.

Only during the terminal phase of the approach -- around the time of entry interface, most likely -- will approaching vessels head directly toward the planetary surface and landing.

Safety First, and all that...
 
As an added detail, I would expect most planetside Traffic Control systems require incoming vessels to plot and fly a "missed approach" course that specifically does not intersect the future path and position of the planet itself should the m-drive fail (for any reason) at any point during the approach.


I would expect that too.

Sadly, LBB:2's vector movement rules with 1mm = 100 km and Mayday's vectors-with-hexes rules with 1 hex = 300K km are both too coarse to model such a common sense requirement with the level of detail required.

The only way to "enter" orbit in Mayday is to approach one of the six hexes surrounding the planet from their "sides" rather than their "tops" and with a vector one hex long. "Entering" orbit in LBB:2 is somewhat similar. You need to judge the speed component of your vector carefully with regards to the gravity "shells" surrounding it.

The ticklish maneuvering both games require to enter orbit is the reason I asked Makofan if he and his group had used vector movement before. Unlike role playing a surgeon, for example, and successfully performing an operation with the roll of a die, someone role playing a pilot while using vector movement has to accomplish something real. They need to carefully judge both speed and direction to enter orbit - a task which will be even harder with Makofan's decision to also move the planet.

This is one of many cases where the player's character is able to do something the player cannot. It most cases, the gulf between a player's abilities and their PC's abilities can be handled with a die roll. If they're going to be using vector movement, the dice won't save the players from bad decisions.
 
One advantage to having your jump entry vector set to give you the optimal minimum-time vector to your destination assuming you maintain constant acceleration to the planet is that you are automatically on a "missed approach" course; if you stop accelerating along the planned vector your ship (or its debris cloud) will miss the planet.
 
All of these details are interesting, but not necessarily important.

While the earth is moving along at a crisp, 30km/sec, that's less than an hour of acceleration at 1G to compensate and catch up. That's a "long time", but in terms of space flight in general, it's not long at all.

Spaceflight involves matching up lots of different bits floating around, the planet's just one of the aspects of the equation.
 
All of these details are interesting, but not necessarily important.

While the earth is moving along at a crisp, 30km/sec, that's less than an hour of acceleration at 1G to compensate and catch up. That's a "long time", but in terms of space flight in general, it's not long at all.

Spaceflight involves matching up lots of different bits floating around, the planet's just one of the aspects of the equation.

Do not forget that the whole solar system is moving as well. I am not sure what that velocity vector is.
 
Jump Tapes and the Generate program are supposed to handle the needed vectors to arrive in the next system safely. Unless your group usually behaves like Han Solo flying the Millennium Falcon, don't worry about it.

But showing what you usually ignore would make a change-of-pace episode...
 
Do not forget that the whole solar system is moving as well. I am not sure what that velocity vector is.

But it doesn't matter.

At the meta level, the problem is taken care of. within the "week of jump, week in system" model of transport and commerce, all of these problems are basically addressed without having to figure out the exact vectors.

The navigation charts know all of these things. From casual googling, system velocities discrepancies are not that high. Arguably, all systems on the same galactic arm are all moving in "roughly" the same direction anyway (they're all circling the same core).

And, in the end, these velocities are nothing compared to what can be compensated against in reasonable time with a 1G drive. A 1G drive is REALLY powerful.

These inter system velocity deltas are dealt with the same as trade winds and other ocean conditions that have affected shipping over the ages.

The inter system deltas are how you can tell which system a trader is jumping to, as they will use their time getting to 100D as part of establishing the correct delta vector for the destination system. Whatever vector that will bring them the most efficient arrival times when they arrive will start to be established as they leave. You should be able to see a stream of traders all on similar vectors from the origin world if they're all going to the same place. You can imagine 5 different streams of ships as they head to the 5 neighboring systems within J1-2.

But all of that plotting is why you have a navigator, charts, and computer systems. To handle all of that for you.

At a game, level, it's a week in transit plus some time to and from 100D. A well placed vector can save a day or two of total travel, easy.
 
At a game level, it's a week in transit plus some time to and from 100D. A well placed vector can save a day or two of total travel, easy.
One could also handwave and say the 'plus or minus 10% time in jump' is part of compensating for the system movement vector.

Suppose that the nature of jump drive is such that you precipitate out with a 0 vector with respect to the nearby star. Going into jump with a large local vector might mean a nasty WHUMP when you come out, because you are being brought to a rather sudden stop. (Therefore luxury passenger ships have top-of-the-line Generate programs and fly the in-system vectors which come back into normal space as gently as possible, even if it means a little longer flight time on both / either end.)
 
But it doesn't matter.

At the meta level, the problem is taken care of. within the "week of jump, week in system" model of transport and commerce, all of these problems are basically addressed without having to figure out the exact vectors.


Exactly.

You can create a data base containing the relative velocities of every star in Chartered Space. You can add each add the orbital data of every planet, moon, and planetoid. You can track how all those vectors change every second of every minute of every hour. You can spend time calculating how all of that will effect in-system travel times.

Or you can just play the game.

Fretting over vectors is almost always below the game's level of resolution. Almost always, as I'll remind the Usual Suspects. The effort necessary to calculate the relatively minor variations in travel time is rarely worth the effect such variations have on play.

There's an adventure late in MT's run in which a raiding ship's high velocity when exiting jump is a clue to that ship's base. In that case, figuring vectors adds something to the session being played. It's a clue and a hurdle which must be surmounted, not a chore.
 
There's an adventure late in MT's run in which a raiding ship's high velocity when exiting jump is a clue to that ship's base. In that case, figuring vectors adds something to the session being played. It's a clue and a hurdle which must be surmounted, not a chore.

Which adventure, by the way?

I entirely agree figuring vectors should only be attempted when it adds to the fun. (In any case, if you want to worry about "realism", you would need to make it 3D.)

I can only see cracking out a vector map being worthwhile when something interesting is due to happen on the run in to planet (piracy or rescue attempt, or salvage opportunity, for example). In that case, if the pilot and/or navigator fail their throws at jump, I might introduce planetary movement as an additional complication the players have to deal with.

As someone said, PC skills cover the gulf between character and player expertise. It's only worth making skill throws when success or failure will have an impact on the story. When PCs fail skill throws, players have to use their wits to deal with it.
 
Back
Top