• 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.

Making "Fleet Jumps" in Traveller

When a fleet or squadron makes a jump from one system to another, do they all arrive at the same time (like in Star Wars), or do they arrive independently, within hours (or even days) of each other? In addition, do they arrive at their destination in close proximity to each other or scattered about the system?

This has major implications regarding ship design, squadron & fleet composition, as well as tactics & strategy.
 
It seems to me that each ship will arrive at the designated system in it's own time (168 hours, plus or minus ... I forget). This leads to...

1) The ships of a task force all agree to meet at a certain location by a certain time, and then they will all set the same course to the target area from the same direction.

2) The ships of a task force trickle into a system over a period of a few days or weeks, and then set their courses so that they all arrive at the target area at the same time from different directions.

3) Someone uses a battle rider to bring a number of battle-ready ships into the area at the same time.

4) Someone else constructs the biggest, baddest fighter carrier ever, and launches a squadron of attack fighters.


IMHO: Any of the above scenarios require vast resources, intensive pre-planning, and a lot of luck.
 
This is covered in various threads and in the Starship Operators handbook (and an issue of either Travellers' Digest or the Megatraveller Journal.

In short, for fleet manoeuvres, much longer time is spent in jump preparation, calculating vectors, establishing communiation links.

A new formula was created for time in jump for each ship which represented the much tighter jump exit. Instead of 160 hours plus or minus 48 hours we see an exit at 160 hours plus or minus 6 hours (sorry the figures are fuzzy, I don't have the reference in front of me). Enough time to marshall the fleet before a strike but not enough for a true surprise attack.
 
Don't forget that the accuracy of the jump must be considered. Jumps are accurate to 3000km, so your ships would need to calculate their emergence to be at least 6000km apart, then they will have to stay put until everyone else arrives and they can get into formation. If they move too soon, they could be at the emergence point of another ship trying to come out of Jump.
 
What comes to mind when I read this is that the '168 hours +/- 10%' could be commercial/civilian grade. A TL15 fleet tuned to Naval standards could cut this waaay down. 2% would probably be optimum.

I dimly recall in the "Star Fleet Spaceflight Chronology" book published in the 70's about an engineer who devised a method of using tractor beam and subspace radio linked cargo carriers to move multi-BILLION ton superconvoys. Of course, tractor beams and FTL radio is a CT no no...darn.
 
And here is the definitive answer, quoted from DGP's Megatraveller Journal Issue 2. Joe Fugate came up with this with MWM.
"When a group of starships know they have to arrive in unison they elect to spend significantly more time at the start computing and sharing jump vector computations. This leads to a much more accurate jump exit at the other end with the error dropping significantly.

The formula in the Starship Operator's Manual for normal jumpspace exit is:

124hrs + (2D x 6 hrs)
yielding a result of 136 - 196 hours (that is 5.7 to 8.2 days)

If double the jump preparation time is spent with all the affected ships in computer linl via tight beam communication, use the following formula instead:

167 hours = (2d x 0.1 hr)
yielding a result of 167.2 - 168.2 hours.

Most ships now arrive within minutes of each other, with the worst spread being up to 60 minutes apart (and this only happens in about 1 out of 20 jumps). Considering the vast distances found in a star system, starships arriving minutes apart would not spoil a surprise arrival.

Constant communication during the jump vector generate (sic) is essential for this to work, and double the normal vector generation time must be observed. But when getting there "on a dime" timewise is essential then this technique is the key. Most civilian vessels don't need this level of schedule precision, so they don't bother."
There we are. I would possibly add either a computing skill and navigation skill of 2 being required by at least one ship's navigator and mil-spec navigation programmes being essential.
 
I would think that there would be times when civilian (as in PC) ships would be that interested in travel time. In interstellar commerce, whoever gets it there first gets to sell it first. And don't you think a passenger liner would gain more business if it advertised that it can get you there in 6 days instead of 7? What about a chase/escape adventure? If the PCs are pursuing a nefarious evil-doer who makes it to the 100-dia limit ahead of them, wouldn't it be nifty if the pursuing ship pops out of jump at the other end three hours ahead of the ship they're chasing?
IMTU, I have made it possible for a HIGHLY skilled engineer to modify downwards the jumpspace exit calculation, so a ship regularly takes less time than 'normal' to transit.

Best Regards,

Bob Weaver
 
Gentlemen,

DGP's 'fleet jump' or 'squadron synchronization' rules, although welcome, are just another example of their not thinking things through. In the words of a GDW alumnus; They never quit their day jobs.

Knowing the duration of a jump to within 60 minutes accuracy BEFORE you initiate that jump opens up far too many cans of worms in the Official Traveller Universe. Among the many problems it creates, you can now aim a near-c KKM through jump space to impact on a planet. Near-c rocks are enough of a headache already without having them pop out of jump space at the 100D limit.

Also, as Mr. Weaver points, the benefits derived by civilians from knowing their jump's duration before they initiate jump are equally numerous.

While I gladly accepted DGP's idea of a 60 minute 'squadron synch' window, indeed I had something like it IMTU beforehand, I applied the 'suadron synch' in a slightly different way.

IMTU, a squadron can synchronize its arrival in the same manner DGP suggests and the vessels involved in that synchronization will arrive in the destination system within minutes relative to each other. The duration of the jump is still determined via the 168 +/- 10% formula. Once the squadron arrival time is determined, the squadron's members' individual arrival times are then each scattered around the squadron arrival time within DGP's suggested 60 minute window. For that I used (2D - 7) x 0.1hr.


Have fun,
Bill
 
The fact that traveller keeps it's inertial energy over the course of a jump, always had the threat of long distance jump torpedoes. 50,000 dton iron ore vessels with a jump escape boat for the crew to leave the ship just as they leave jump space, would be perfect for taking out ground installations and high-ports. The nuclear winter caused by having that much mass hit a planet would effectively destroy that systems ability to support the enemy navy.

No matter how much firepower is pumped into the incoming ship, it would do little to change the incoming ships vector. (too much mass/inertial velocity)

IMTU I dealt with this by having the ship keep its velocity, but, with a random direction. This way black globe ship tactics are not effective, but so are the jump based dead weight bombing runs.

There are alot of things in the OTU that was never fully thought out. Simple things like using gravity as a weapon, it would be devastating, but never applied in the OTU.

In comes down to the ref and how the ref wants to apply the rules of his/her universe. I like alot of DGP's stuff, and even if they kept their day jobs, what they produced was pretty amazing. I may only use 30% of it, but, well, that is still an amazing amount of material.

best regards

Dalton
 
Originally posted by Dalton:
The fact that traveller keeps it's inertial energy over the course of a jump, always had the threat of long distance jump torpedoes.
Dalton,

No, there hasn't.

When you're facing a 33.6 hour arrival window you can't 'aim' your KKM, near-c rock, or massive ore barge with any certainty. You don't know your jump's duration until after you initiate. Because you don't know when you'll arrive, you don't where your target will be. Your target can be anywhere 'inside' a slightly curved 'tube' 100D wide and 33.6 hours long.

DGP's ill thought out 'jump synch' rules changed all that. Now, by spending extra plotting time, you could cut your arrival window from a 33.6 hour span either side of 168 hours to 1 hour span between ~167 and ~168 hours. Depending on the size of the target body and its orbital speed, that might just be enough to allow you to aim your KKM through jump space.

I like a lot of DGP's work too. You'll notice I use their 'jump synch' idea, I simply apply it in a fashion that does less damage to canon.


Have fun,
Bill
 
Hi Bill,

You may have missed the part about the crew still being on the torpedo until it enters the destination system. Since the ship has no weapons etc., it can easily afford a few full 6g burns to compensate for any variation at the end point.

The crew then immediately jumps out of system from the jump boat that is carried by the big rock.

I am not postulating near C velocities - as you can get away with a much smaller mass, but, the energy required to get a small mass to near C speeds, while having enough fuel at the destination to modify the course, and be over 100dtons and carry the nesessary crew, makes it easier to invade with a fleet.

Make a very large iron based rock, travelling at a 14-18 G velocity and you have enough mass to do massive amounts of damage, cheap enough to produce in quantity, and large enough to carry the crews escape jump boat and anything else they need.

At 120 diametres out (far enough to let the crew make the adjustment and jettison/jump) the defense force would not have enough time to respond.

They may get some hits in, they may even shatter it, but, they will not divert enough of the inertial mass from devestating the target.

best regards

Dalton
 
Originally posted by Dalton:
You may have missed the part about the crew still being on the torpedo until it enters the destination system. Since the ship has no weapons etc., it can easily afford a few full 6g burns to compensate for any variation at the end point.
Dalton,

Since unmanned jumps don't seem to work in the OTU, I didn't miss that at all. And at the speeds I'm talking about a 'few' 6G burns are a spit in the ocean.


... travelling at a 14-18 G velocity...
First, you can stop right there. You have either made a mistake or don't know what you're talking about. A gee is a measure of acceleration and not velocity. Saying '14-18 G velocity' is gibberish.

Second, you need to look at some actual numbers in order to understand what sort of distances we're talking about. Let's assume an Earth-sized world with UWP factor 8. That's a diameter of 8,000km and 100D limit of 800,000km. Covering that distance at 1 G of acceleration with the usual turn-around (something our KKM won't do I know) takes 301 minutes or 5 hours.

Let's say your KKM was accelerated by some means at 18 G for an hour. That would give it a velocity of ~635km per second. With that velocity it would still take your KKM ~21 minutes to cover the 100 diameter distance of 800,000km.

Next, I want you to pull out a piece of graph paper. Fill in one tiny box and then count 100 empty boxes out to the left and right and make marks. That's your Earth-sized target inside its 100D limit. Each one of those boxes represents 8,000km But wait! We're going to add the dimension of time too.

'Rad-con' math time here(1), Earth moves at 30km/sec. Every hour, Earth moves 108,000km. Dividing our 8,000km box size into that gives us 13.5 and we'll round it down to 13 make it easier for you.

You're KKM is going to exit jump space sometime during a 33.2 hours window. You don't know when until you jump. Rounding down 33.2 to 33, again for ease, and multiplying by our 13 boxes from above gives us 429 boxes. Let's round that up to 430 because we've round down all the other times.

Take you graph paper and count 215 boxes above and below the center box, then make marks. Complete the 'rectangle' you just formed. It has sides of 201 boxes; Earth and its 100D limit, and 430 boxes; roughly the distance Earth moves in 33.2 hours.

Finally, color in the entire column of boxes Earth is in. That's your 33.2 hour Earth target. Pretty small huh?

It gets worse.

Your KKM is going to arrive at a point you can calculate to within 3,000km per parsec jumped. Again, to make things easier for you we'll say within a single box. The trouble arises that you don't know when you'll arrive at that box so you don't know what vector to choose.

Try this fun game. Take the sheet of graph paper I've had you mark and place a chit on the bottom of the 'Earth' column. Then select a box along one of the 100D sides. That's where you're KKM will arrive. Draw a line from your entry box to other 100D side. The line must be straight, but it can 'slope' in any fashion wyou want. Next, roll 3D6-3. That will give you a number between 0 and 33. It won't be random, there will be a bell curve distribution, but its the best we can do.

With the Earth chit in the 'zero' position and your KKM entry box marked along the 100D side and it's vector string marked across to the other side, apply your 3D6-3 roll to the Earth chit. Every interger in the roll represents 13 boxes of movement for the chit; 0 = none, 1 = 13, 2 = 26, etc. Repeat until the lesson is learned.

How many times did your vector line cross the Earth chit's final position(2)? Let me guess, was it none?

If you bother to do more math, you'll see that adjusting the vector of your KKM to impact the body your trying to target runs into serious problems. It seems the greater your velocity, the less time you have to correct your aim. As your velocity increases, you get to a point where Traveller's 6 G manned acceleration limit is wholly inadequate to make any real change in the KKM's vector before it passes the target. If you limit your velocity enough to allow for post-exit aiming, you give the defenders time to do something and severely limits your KKM's effectiveness on impact.

Another thing to remember, unless you're planet busting or are not interested in using the planet for anything for the next few millennia, you're not aiming at an entire world. Instead, you're aiming at an extremely small portion of an entire world. That makes your attempt at aiming even more problematic. You simply aren't trying to intersect a 8,000km 'box as in my graph paper game. Also, because planets revolve your target might not be on the hemisphere facing you when your KKM arrives at the planet. Going into orbit in order to hit it will further lower your velocity, give the defenders more chances to do something, and limit the amount of damage inflicted.

Gee, ain't math a BITCH?


Have fun,
Bill

1 - Rad-con i.e. quick and dirty. Earth's orbit, indeed any orbit, is elliptical which means the distance it covers during any given time period will very depending on when it is during it's orbit. That means its orbital speed varies too.

2 - Some folks will point out that you can exit ahead of the Earth chit and simply fly down its column for a slam dunk. Sory, no cigar. In reality the column the Earth chit is moving in is curved, just like the section of orbit the column represents.
 
Sounds like it would be easier to go to the local Planetary Belt or Oort cloud, find a nice Water-Ice Asteroid or comet, strap on a 6G M-Drive and using the water from the asteroid as fuel, slam it into the planet. You could probably get pretty accurate with that using a Model/1 computer! Or, find a nice comet that is already going pretty close to where you want it to go and use your M-Drive to "redirect" it a bit. Might not take a 1-G drive either... Doesn't require Jump Drives, doesn't require Gravitics, just a simple M-Drive available at TL7 per LBB3...

Sorry Off-Topic...

Actually, I liked BillC's compromise on the Fleet Jump, that is how I envisioned it as well. You cannot change the +/- 10%, but you can make the ships all come out together... I used Handwavium and said that you meshed your jump-fields.
 
Originally posted by Plankowner:
Sounds like it would be easier to go to the local Planetary Belt or Oort cloud...
Plank,

Yup. Near-c rocks are alreayd enough trouble in Traveller. DGP's poorly thought out 'fleet synch' rules simply added to the problem. Because you can know in advance when you exit, you can aim far better. The 33.2 hour window you're fighting and losing against in the graph paper game I wrote about suddenly becomes a 1 hour window.

Sorry Off-Topic...
It wasn't off-topic. While good, DGP's fleet synch rules are broken. Any discussion of them must include a fix.

[qb]Actually, I liked BillC's compromise on the Fleet Jump...[QB]
It's not exactly a compromise. I had something like 'fleet synch' IMTU well before MT was released. I just used DGP's numbers in my previous framework.

Because I am a wargamer first and a roleplayer second, my tweaks and house rules tended to the long view. I was more worried about how they would effect the game (and history of the setting) than how they would effect the players. Knowing when you'll arrive in a system before you jump creates too many problems, near-c rocks through jump space is just one of many.


Have fun,
Bill
 
Back
Top