HG Nodal Freighters & Fuel Scow

[szurkey]

----------

 

[szurkey]

Fuel Scow stats

----------

 

[Zowy]

Sounds very dangerous......

 

[boomslang]

I was trying to figure out a way to move people and cargo faster, and came across the idea of fixed high speed shipping network using freighters and fuel scows.

Interesting design; I've considered similar schemes myself from time to time.

A handful of notes:

1. This does presume that drop tanks aren't necessarily destroyed when used; the j-fuel is transfered to the starship and burned, and the tanks are then jettisoned and deliberately scuttled with demolition charges to pulverize them and thereby effectively move the starship out of their 100-diameter limit so that it may jump away safely in short order. Using fuel sleds like you propose for this scheme presumes that your scow can scoot itself far enough away quickly enough to spare the starship a misjump. But if this is possible, you might as well just put a couple of rocket motors on regular drop tanks so they can thrust themselves away intact for later recovery by support craft. So you need a stronger rationale for the manned scow. I would propose that you eliminate everything on the starship but bridge, j-drive, powerplant, computer, crew staterooms, and p-fuel -- every other dton is reserved for payload. The scow then becomes a proper tender, and the freighter little more than a fat, hollow Xboat. You then have a system of these freight packets being hurled back and forth across interstellar space by the support fleet. Taking a cue from Xboat operations (and the Jules Verne currently on-orbit at the ISS), you could even experiment with automating the starships by replacing their crews with built-in robots, and scrapping the crew staterooms for even more payload space.

2. 400 dtons seems awfully small for an enterprise with this much support infrastructure; why aren't your freighters upwards of 1000 dtons? If you're going to all this trouble, why not move as much materiel as possible on each trip?

3. What sort of cargoes need to be moved so far so fast? This might also provide context for deploying such a special-purpose system...

 

[szurkey]

A Handful of Answers

----------

 

[boomslang]

Using the appropriate physics equation and solving for time results in 11.1 seconds for the fuel scow to get 100 radi away perpendicular from the freighter. 2g's will cut the time down to 7.9 seconds.

Which assumes that ~10 seconds is enough time between j-fuel consumption and Jump initiation. This is a non-trivial assumption, but it's not unreasonable.

I don't like the XBoat idea of being stranded, nor will most passengers. The reserve fuel for a J-1 jump is for safety.

Given that misjumps can throw a starship dozens of parsecs from nowhere, J-1 to get to safety is perhaps overly-optimistic. The reason that battle riders use a J-1 reserve is so that they can leave a losing battle by microjumping to the local outer system or a one-psc-away rally point where they can avoid enemy contact indefinitely to await later, casual pickup. Given that misjumps last 1d6 weeks, you might be better off with 2 weeks' more p-fuel and a slew of emer low berths. If one of your cargo nodals misjumps, they'd best just tuck themselves in until search & rescue finds them.

As for the freighter crew, I suspect that for pure freight version, a robot crew would be fine, but most passengers will probably prefer to interact humans.

Plus, Medics (and perhaps Stewards) are required. Combined with the general OTU bias against robots, I suppose flesh & blood crew are a necessity for any but Low passengers.

The point being is that costs are about equal to or less than the existing shipping option, the same number passengers, 4 to 5 times faster, but only 79.25% as much cargo. For players, this means the ability to move from one sector to another much faster and for the same price (or less) as on a J-1 Subsidized Merchant.

Are you including the maintenance and operating costs of the scow itself in those calculations?

IMTU, we just fix the rules for cargo & passenger rates so that they're charged by the parsec instead of the "jump"; this generates the required revenue fairly easily... in any TU, Jump-5 is a really expensive luxury; a private citizen who absolutely needs to go that fast can probably afford a speedy yacht to roar around in...

 

[szurkey]

----------

 

[Whipsnade]

I was trying to figure out a way to move people and cargo faster...

Szurkey,

Congratulations.

You've successfully re-invented the LASH(1) system used both in the Real World and in Traveller since at least the early days of MegaTraveller.


Have fun,
Bill

1 - LASH = Lighter Aboard Tender

 

[szurkey]

----------

 

[boomslang]

The problem is how do you book passengers and cargo when there is no way to tell how many/much are continuing on the Nodal Freighter? I can't answer this one...

Which is why I mentioned point 3 above; the main issue (the feasibility of drop tanks and published rates for commercial transport notwithstanding) is rationalizing the need for such a system.

I'm thinking the only really practical, commercially-viable application would be steady bulk haulage from a production world to a consumption world (with waste/recycling returning on the backhaul leg).

As you mention, anticipating passenger demand over such a route distance is daunting, if not impossible, from a logistical standpoint.

 

[szurkey]

----------

 

[boomslang]

The nodal system will work, but trying to make it run faster, say a jump every 8 days is problematic because of the lack communications faster then a ship.

Well, not if you're moving them on scheduled runs. I figure one of your scows should be able to service around one starship per day. IMTU, I have main route freighters that average a jump a week: they breakout of jumpspace at high velocity and decelerate all the way into port, are serviced on-orbit by small flotillas of mainworld-based cargo and fuel shuttles, blast themselves back up to jump altitude accelerating all the way, and spend no more than perhaps a few hours out of jumpspace any given week that they're not in annual overhaul.

If jump takes somewhere between 150 and 175 hours (as per HG2), that leaves an average 5.5-hour window every week for cargo swap and refueling; no problem... just don't put your warehouse facility on a Size-A world, or inside the jump shadow of a GG...

 

[Plankowner]

Also, if this is a scheduled, fixed run between major Hi Pop worlds, contracts and factors can be used to pretty much guarentee a certain minimum passenger and cargo volume on every run. When the minimums don't make the run profitable, the route isn't set up.

 

[Whipsnade]

Actually, I just have all CT Reprints, and a few TNE products, so LASH is not something I heard of before in Traveller. I Googled it, and apparently there is a difference.

Szurkey,

The difference is in degree and not kind.

LASH ships use modularization, but they include fuel pods, not Fuel Scows.

The only difference between a fuel pod and a fuel scow is that the scow has a M-drive...

... a M-drive you'll be toting through jump instead of cargo for one reason or another.

I'm looking at fuel scows to further the performance of ships.

Google "rift traders" and other similar phrases then. People have been designing "modular" ships comprised of differing mixtures of pods, barges, scows, small craft, and what-not since the earliest days of Traveller, or at least since either LBB:2 High Guard rev. 2 and/or A:5 Trillion Credit Squadron. Annic Nova is "modular" to a certain degree, so is the Zhodani Shivva-class frigate.


Have fun,
Bill

 

[dean]

Modularize it more..

I didn't take the time to look up the LASH system, but if you simply modularized the cargo and passenger spaces (including the space for the medic and stewards) and make the jump-ship portion a clamp-on frame, keeping basically the same spec, the jump-ship could be made to be extremely efficient at the destination ports.

The jump carrier would arrive at the system, and establish contact with the barge. At the appropriate time, then de-couple with the inbound cargo and passenger pod (you'd need a small concession of space to provide power for the free-floating pod) it's carrying, perhaps transferring continuing passengers with a ship's boat type of craft. The jump carrier then would match up with the scow (which is carrying a fully-loaded cargo/passenger pod), and put the jump-carrier back into jumpspace. Complete within 12-24 hours tops. The scow mates up with the delivered pod and carries it to port. Should be able to servie several jump-carriers per week. Maximum jump speed and maximum in-system utilization of the Jump Ship. Crews could also transfer to allow for time off at the port-of-choice.

Happy Travelling!

 

[szurkey]

----------

 

[Whipsnade]

Actually, there's a big difference between a fuel pod and fuel scow. The scow doesn't go with you when you jump.

Szurkey,

My apologies. I misunderstood your terminology. Because a scow is merely another name for a barge and can be powered or unpowered plus, your references to TNE and the Manta-class fuel shuttles the RCES clippers use, I assumed you were using scows in a certain manner.

You're suggesting that vessels in this system use the scows as "self-powered drop tanks" of a sort. That could work... maybe... if the problems associated with drop tanks didn't make civilian vessels blow up frequently enough not to be used by civilian vessels. The OTU militaries may use drop tanks, but civilians tend not to do so. (After all, how many civilian airlines perform in-flight refueling?)

I'm looking at this for scheduled high speed routes through key systems where increased costs of the ship and scow are compensated by the decrease in travel time.

Look at your numbers again. Pay special attention to the amount of time supposedly saved in each system versus jump drive's temporal accuracy. You did figure in the fact that a jump can take anywhere from ~153 to ~183 hours, didn't you? If you're saving less than 34 hours in-system, you'll lose it all in jump variation.

This is not cost effective for a scheduled route.

Says who? In fact, later in the same post you mention several problems with your system. To whit:

...how do you book cargo and passengers when you don't know how much space is available on the ship...

... if the cargo has to go way up the network, it gets on loaded and off loaded at every single node, and that is expensive.

You don't have the on load and off load everything, but you still have a big time delay of at least a day.

And that day you "saved" is still less than the ~34 hours "wiggle' your jump drives will throw into the mix.

Still, this "powered drop tanks' idea isn't new. I've seen it in other homebrewed TUs before and many GMs have looked it before ditching it due to the scheduling problems you mention. The time saved just isn't worth the additional effort, additional cost, additional equipment, and additional danger.

Shipping firms in the OTU who wish to obviate the need for that in-system trip to the mainworld either use LASH vessels or have their normal designed freighters serviced by barges and shuttles. LASH vessels act like battlerider tenders and pick up powered cargo, passenger, and fuel scows/barges while normal freighters can use the "farport" small craft or starport facilities as their route requires. Both systems are much more flexible, much more robust, and much more cheaper than the "powered drop tanks" system you propose.

Traveller's rules mention in many, many places that it all comes down to economics. Thanks to jump drives' temporal accuracy, your system provides no real time savings over LASH or "farport" systems and thus cannot demand premium freight/pasengers rates. Simply put, no one is going to pay for it because it provides no real benefits.

Of course, all this applies to the OTU only. Your system would be an excellent feature of any personal TU.


Have fun,
Bill

 

[szurkey]

----------

 

[Whipsnade]

I still think Fuel Scows can make long distance jumps very economically viable.

Szurkey,

I still haven't gotten the point across....

Your fuel scow idea is nothing new. Canon, even pre-GT canon, is littered with examples of merchant lines operating fast-turn-around systems. Those systems fall into two broad catagories; LASH and farports.

LASH systems are the merchant/civilian version of the military's "battleriders and tender" system. The LASH freighter enters the system, drops off cargo, passenger, and empty fuel barges with m-drives, picks up cargo, passenger, and full fuel barges with m-drives, and jumps away. The LASH freighter's integral fuel capacity may or may not be enough to make a long distance jump or multiple jumps. However, the fuel in the barges makes up the deficit.

(The barges also allow the LASH freighter to be modular, just like the RCES clipper ships your idea somewhat mimics. Depending on the jump in question, a LASH freighter can carry more cargo, more passengers, or more fuel. This flexibility makes the system attractive, if the projected revenues can account for the initial costs.)

A farport system is somewhat simpler. Instead of requiring a modular freighter like the LASH system, farports can service all kinds of freighters. In the farport system, groups of small craft operating from either a nearby station or the mainworld service freighters beyond the jump limit. Cargo, passengers, and fuel are loaded and unloaded. The freighter needn't make any in-system voyage and she can jump away as soon as her equipment checks and manifest changes are made.

Your fuel scow system merely adds a type of drop tank to the pre-existing canonical LASH/farport systems. We know that in the OTU civilian shipping does not use drop tanks - either powered or unpowered - due to the inherent danger of the practice; hence the reference you misunderstood to Real World in-flight refueling. LASH and farports provide the speed the OTU shipping market needs without adding the danger drop tanks represent.

Now, that's only what occurs in the OTU. What goes on in your own Traveller universe is entirely up to you!


Have fun,
Bill