So Where Do the Express Boat Tenders Stay

[Condottiere]

Doesn't make sense three millenia in the future since you know the technology tree and equipment has a maintenance schedule and cost, unless equipment has an aging penalty that actually deteriorates performance.

 

[Spinward Flow]

unless equipment has an aging penalty that actually deteriorates performance.

You mean like characters starting at age 34 ...?

 

[Spinward Flow]

Well this is certainly an interesting preliminary result for the respective Tender "package" construction costs and crew requirements that I'll need to write up fully (at some point, might take a week or so to write everything relevant) over in The Fleet forum, but here's how things are looking after the first draft.

J4 Package (legacy designs)
4x TL=9 J2 Scout/Courier = MCr 110.52 . Passengers=3 (7 if double occupancy), Cargo=3, Fuel=40, Air/Raft=1, Crew=1
6x TL=10 J4 XBoat = MCr 423.9 . Passengers=1 (possible), Cargo=1 (possible), Fuel=40, Crew=1
1x TL=10 J4 Tender = MCr 274.77 . Passengers=4 (10 if double occupancy), Low=20, Cargo=60, Fuel=150, Crew=6
= MCr 809.19 per Tender "package" (volume production) + 2000 tons total displacement (LBB2.77) + Crew=16

J5 Package (proposed)
4x TL=11 J2 Runabout = MCr 168.7488 . Passengers=2 (6 if double occupancy). Cargo=15 (10+5 possible), Fuel=22, Air/Raft=1, Crew=2
6x TL=14 J5 XBoat = MCr 509.088 . Passengers=1 (possible), Cargo=1, Fuel=52.5, Crew=1
1x TL=14 J5 Tender = MCr 210.55928 . Passengers=6 (high or 27 if double occupancy), Low=18, Cargo=70, Fuel=310, Crew=20
3x TL=14 Armored Gig = MCr 66.84 . Passengers=1 (2 if double occupancy), Cargo=1, Fuel=1.2, Crew=2
= MCr 888.39608 per Tender "package" (volume production) + 2060 tons total displacement (LBB5.80) + Crew=34

J5 Tender "package" = 109.788% construction cost of J4 Tender "package"
J5 Tender "package" = 212.5% crew complement of J4 Tender "package"

MCr values shown are per grouping of craft, not individual craft prices (except for Tenders since there is only 1 Tender per "package" of craft).

Basic idea is that a single Tender on an XBoat Network will usually act as the hub/node for 6 XBoats and 4 Scout/Couriers (or equivalents) in support of on and off network communications relays and routine runabout duties to keep the Tender on station in support of XBoat operations. The Armored Gig fighters/maneuver tugs use a Tender as their "home base" for their flight operations and their crews are included in the crew complement of 20 for the J5 Tenders (so don't count their crews twice).

All things considered ... what amounts to a +10% increase in construction costs for a +25% increase in range potential (Jump-4 to Jump-5) sounds like a pretty sweet deal if you ask me. Of course, the operational overhead costs (life support, crew salaries) for the J5 "package" will be higher due to the increased crew sizes ... but the Quality of Life improvements that come with that increase in crew size on the Tender (and on the armed from the shipyard Runabouts) will more than make up for those additional overhead costs through personnel retention and the reputation of the J5 Express Network service not being a "punishment posting" for people who aren't good enough to get better assignments elsewhere.

Best of all, the J5 Tender could carry two J5 XBoats and one J2 Runabout in its three hangar bays (plus 3 Armored Gigs of course) and successfully "self deploy" those assets to a destination star system 5 parsecs away to establish a new base of operations on a Jump-5 Express Network. The Tender itself has 310 tons of fuel capacity, plus the 52.5 tons on each of the two J5 XBoats (+105 tons), plus the 22 tons on the J2 Runabout, plus the 70 ton collapsible fuel bladder in the 70 ton cargo hold of the J5 Tender ... for a total of 507 tons of fuel. Simply adding a 10 ton collapsible fuel bladder or demountable fuel tank into the hold of the J2 Runabout increases total fuel capacity aboard to 517 tons ... sufficient for 5 Jump-1 and 47.6 days (6.8 weeks) of power plant operational endurance (515 tons of fuel would be 5J1 plus 6 weeks exactly). The Tender will need to refuel at the destination system and stock up on consumables (mainly life support and raw materials for onboard manufacturing of parts and spares needed to sustain the mission), but the Tender has the needed workshop spaces to be able to generate the supplies it needs given appropriate feedstocks of raw materials (hence the need for the J2 Runabout on the initial deployment and the larger cargo hold size on the J2 Runabouts than what is commonly seen on Scout/Couriers in the IISS).

So, all in all ... looking rather promising as an LBB5.80 variation on the LBB2.77 theme, except done "better" at a higher tech level for increased capabilities and security. Same idea, just updated to Jump-5 standard.

 

[aramis]

I thought post delivery by courier was as and when, or maybe once a month to keep the system connected to the rest of the Impeium.

I have understood courier service to be roughly weekly...

My understanding is that a ship (usually a subsidized merchant or liner) must have a dedicated mail vault, and must be armed as a prerequisite to getting a mail contract.

That's more than the book requirements. You just have to keep 5 Tons of cargo bay free for mail, be armed, and have a properly qualified gunner on the crew.

On the other hand, it also means you have to tell them where you're going.

I'll note that, based upon Bk 7, I use the same 4 day requirement... you have to give the locals 4 days to load your mail allotment. Likewise, Bk 7 says locals have 4 days to deliver to the ship.

 

[Condottiere]

1. I think the important aspect would be less how often, more the regularity; it sort of reminds me of those remote ocean islands where a ship or a plane is subsidized to maintain a connection to one of the continents. In the grand scheme of things, the service costs next to nothing, except operating costs, the expensive part is likely maintaining facilities so that the courier can dock and refuel.

2. Equipment tends to deteriorate, depending on usage and environment.

 

[Spinward Flow]

I'll note that, based upon Bk 7, I use the same 4 day requirement... you have to give the locals 4 days to load your mail allotment. Likewise, Bk 7 says locals have 4 days to deliver to the ship.

I'm going to object to this interpretation (of needing to wait a mandatory 4 days for mail to be delivered, just like any other cargo).

The reason I object to this interpretation is that the logistics of xmail cargo don't work exactly the same as the logistics for all other cargo. Outbound xmail simply accumulates at the dispatch point waiting for a starship to show up and take it away. The dispatch point that interfaces with the starships is almost certainly going to be within the jurisdiction of the starport. Basic idea being that there is xmail accumulating "organically" at the dispatch point inside the starport, pre-sorted for the various offworld destinations ... so when a starship with a mail vault qualified to carry xmail cargo "declares" to the local Postal Union where they are going next, the xmail to load up onboard the starship is already there waiting to be loaded.

Now, for an individual on that world, it may take 4 days for their package/letter/xmail contribution to reach the dispatch point in the starport. THAT is something I do not have a problem with. That part still makes sense.

However, the reverse does not make sense from the perspective of the starship. The starship doesn't declare where they are going and it then takes the local dispatch point 4 days to sort the mail outbound to that destination. In other words, the 4 day delivery window is "upstream" of the departure time concerns of the starship.

Essentially, whatever xmail is sorted and ready to go when the starship is ready to depart ... THAT is what gets loaded onboard "in the last few minutes/hour" before departure, rather than making the starship WAIT for 4 days before loading can begin. It's done that way because there is xmail flowing into the dispatch point in the starport all the time ... and you want anything that comes in and gets sorted just before departure to be included in the (proverbial) "xmail bags" that get loaded onboard immediately prior to departure. That way, the starship takes everything that came in up to the last moment, rather than needing to wait around to leave with everything that got sent 4 days ago.

So from a locals perspective, the locals need to send xmail 4 days before the starship departs to be sure their xmail gets onboard.
From a starship perspective, they just load whatever xmail is sorted and ready to go to their next destination immediately prior to departure.

All the xmail that "missed" the departure window for the starship simply stars accumulating again to go out on the NEXT starship going to that destination. So it's more of a fill/hold/drain type of cycle managed by the local dispatch point in the starport.

 

[Quint]

I have always seen the X-Boat network as primarily working along the XBoat Routes as canon suggests, supplemented by Scout/Courier service (and SubMail) to non-XBoat serviced systems. That said, I also tend to think that systems with XBoat stations/stops as having many more XBoats (and Scout/Couriers) on hand than is being suggested above (especially if there is a Scout Base or Way Station present). IMTU, in emergencies, this allows for "Broad spectrum" and "full spectrum" transmission of news and information, broad being additional ships being sent out to important systems to insure that the information is, well, broadly and quickly available. Full spectrum is ships being sent everywhere within range. Both of these also provide redundancy in case of mis-jump or intentional shenanigans. The Imperial Navy has a similar system.

The danger with Broad/Full spectrum transmission is that it depletes available resources to transmit new information if it comes in.

Then there's J-Torps...

D.

 

[Spinward Flow]

So I've continued playing around on the TCS webpage with different variations of parameters and have landed on the following interesting subset by way of comparison.

---

J4 Package (legacy designs) = MCr 809.19 per Tender "package" (volume production) + 2000 tons total displacement (LBB2.77) + Crew=16

• 4x TL=9 J2 Scout/Courier (unarmed) = MCr 27.63 each
  MCr 110.52 | Passengers=3 (7 if double occupancy), Cargo=3, Fuel=40, Air/Raft=1, Crew=1
• 6x TL=10 J4 XBoat (unarmed) = MCr 70.65 each
  MCr 423.9 | Passengers=1 (possible), Cargo=1 (possible), Fuel=40, Crew=1
• 1x TL=10 J4 Tender (unarmed) = MCr 274.77 each, quad hangar arrangement
  MCr 274.77 | Passengers=4 (10 if double occupancy), Low=20, Cargo=60, Fuel=150, Crew=6

---

J5 Package (proposed) = MCr 952.2704 per Tender "package" (volume production) + 2060 tons total displacement (LBB5.80) + Crew=34

• 4x TL=13 J2 Runabout (armed) = MCr 42.112 each
  MCr 168.448 | Passengers=2 (6 if double occupancy). Cargo=20 (w/ 20 ton collapsible fuel bladder), Fuel=23.8, FPP, Crew=2
• 6x TL=14 J5 XBoat (unarmed) = MCr 84.80 each
  MCr 508.8 | Passengers=1 (possible), Cargo=1, Fuel=54, Crew=1
• 1x TL=14 J5 Tender (unarmed) = MCr 208.1824 each, triple hangar arrangement
  MCr 208.1824 | Passengers=3 (high or 21 if double occupancy), Low=12, Cargo=200 (w/ 200 ton collapsible fuel bladder), Fuel=200, FPP, Crew=20
  • 3x TL=14 Armored Gig (armed) = MCr 22.28 each
    MCr 66.84 | Passengers=1 (2 if double occupancy), Cargo=1, Fuel=1.2, Crew=2

---

J5 Tender "package" = 117.7% construction cost of J4 Tender "package"
J5 Tender "package" = 212.5% crew complement of J4 Tender "package"

---

So the new design array for the J5 Package enables a J5 Tender to berth one J5 XBoat and two J2 Runabouts in the hangars (along with the three Armored Gigs) and have enough combined fuel tankage onboard to achieve 5J1 to cross 5 parsecs without external refueling and arrive with some ~25 tons of reserve consumable cargo/fuel capacity to spare upon reaching the destination system. It's a bit pricier that the previous version posted above, but the new J5 Package is also more flexible and capable than the previous draft.

Still think that a +17.7% increase in purchase cost (in volume production) is worth a +25% increase in jump range on an Express Network ... provided there is sufficient logistical/technological support available to keep a higher tech level network operational.

 

[Spinward Flow]

By Jove, I think I've finally got it.

The LBB2.77 Express Tender design parameters have been bothering me for months now ... mainly because all the "important stuff" you need to know in order to replicate the darn things properly is just so poorly explained and nebulous (which was fine for LBB S7, but not so great for those of us who like to crunch numbers until they scream). I kept playing with the basic details in the TCS website and it kept not adding up right ... until I figured out what I was doing wrong.

In LBB5.80, carried craft of 100 tons or more cost 110% of their tonnage to put into a hangar.
But in LBB2.77, carried craft were basically all small craft, so they were carried at 100% of their tonnage (including, presumably, 100 ton XBoats because there weren't any rules yet saying anything differently).

So the only way to make the TCS website "behave" and do what I wanted it to do required "bluffing" the programming by saying that the hangar bay was holding 12 Cutters of 50 tons each.
And there it was ... a 600 ton hangar bay for 4 XBoats and 2 Scout/Couriers ... just like LBB S7 said there should be.
I could even put in the H-drives (as specified), the 150 tons of total fuel, crew of 6, the 4 middle and 20 low passengers, the 60 ton cargo bay, the model/3 computer, 3 hardpoints ... all of it ... and there was 21 tons of space left over.
3x Workshop = machine shop, electronics shop, fuel probe ...
Fuel lab that monitors quality = TL=10 fuel purification plant (8 tons) ...
2x Laboratory = Heavy Duty communicator banks (in+out) ...

Here's what the whole thing looks like using the TCS website with all the parameters laid out on a 1000 ton custom hull.
Funny thing is, it's the Jump-H drive that dictates the TL=10 minimum for this starship ... while a custom LBB5.80 Jump-1 drive would have only required TL=9 (as I'm finding out in my research on the topic).

Express Tender, Transport Tender
1,000 ton, TL=10 Civilian Design, 268.84 MCr
6 crew (pilot/navigator, communications specialist, medic, 3x engineers)
4 Mid passengers, 20 Low passengers

__Ton._____MCr.____EP.____
| ___.__ | _60.00 | _.__ | Close Structure, partially streamlined
| ___.__ | __1.00 | _.__ | fuel scoops
| __8.00 | __0.04 | _.__ | purification plant
| _20.00 | __5.00 | _.__ | bridge
| __3.00 | _18.00 | 1.00 | computer model 3
| _45.00 | _80.00 | _.__ | drive jump H #1
| _15.00 | _32.00 | _.__ | drive maneouver H #1
| _25.00 | _64.00 | _.__ | power plant H #1
| _10.00 | ___.__ | _.__ | fuel, PP endurance 4 weeks (4 weeks powered down)
| 100.00 | ___.__ | _.__ | fuel, jump range 1 parsec
| __3.00 | __0.30 | _.__ | hard points x3 with no turrets
| _40.00 | __5.00 | _.__ | staterooms  x10
| _10.00 | __1.00 | _.__ | low berths  x20
| _60.00 | ___.__ | _.__ | 60 tons cargo capacity
| _40.00 | ___.__ | _.__ | additional fuel 40 tons
| __8.00 | __1.00 | _.__ | laboratory x2 (communicator banks simultaneous in+out)
| _12.00 | __1.50 | _.__ | workshop x3 (electronics shop, fuel probe, machine shop)
| 600.00 | ___.__ | _.__ | hanger space for 50 ton Cutters x12 (6x 100 ton starships)
‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒
| 999.00 | 268.84 | 1.00 EP used, PP generates 10.00 EPs

271.52 MCr (first ship, includes architect fees) built in 120 weeks
215.07 MCr (20% discount in volume, TCS) built in 96 weeks
CT Ship Designer by Matt. Visit https://tca-2014-12.herokuapp.com

So a bit of a kitbash effort for the legacy example to emulate and take as precedent to follow.

Why 4 (live) middle (not high) passengers?
Up to 3 of those staterooms might be needed for Gunners for the 3 turrets, plus 1 more passenger slot to host an XBoat pilot on layover between jumps while the Tender's engineering crew run standard maintenance checks on the XBoat. Also, high passengers requires a steward, which this crew does not have (see below).

Why 20 low berths?
This one feels excessive to me, although the explanation is for reserve pilots for XBoats and for medical cases (to cause deaths or prevent them? ). 20 low berths is enough for a replacement Tender crew of 6, a replacement pilot for every XBoat that can be docked simultaneously (4), plus a replacement pilot for 2 Scout/Couriers plus 3 replacement gunners ... and still have another 5 low berths left available for "medical" cases ... which seems, weird. Given the era when the original Express Tender was defined using LBB2 construction rules, I wouldn't be at all surprised to find out that this one is no more than a case of "eh, it's a nice round number, use it" for lack of anything more descriptive. Might even be a case of deciding 5 low berths per 1 passenger stateroom, which sounds simplistic as far as that goes ... but there's no way to know that for sure given the text of LBB S7. At least this one is specified, although the justification for it leaves something to be desired (like, a more fulsome explanation of why 20, specifically).

I have no idea why the crew in LBB S7 is captain/pilot, navigator/medic, communications specialist, 3x engineers. The one that gets me is the navigator/medic combination. In LBB6, the only way to obtain this combination is via the Technical Branch skill table with a DM +4 (requires 9+ education) or Specialist School as a result of a Training mission. At least LBB1 made it easier for Scouts to wind up with Medical and Navigation skills on the same character. But still, the obvious choice is to instead combine pilot and navigator together, since those are skills that Scouts are more likely to have in combination with each other (in LBB1 or LBB6) and let the medic be a dedicated single role crew member (and get their skill above Medical-2 for that all important DM +1 on survival rolls with low berths!). The pilot/navigator then becomes the "captain" of the Tender practically by default (because, bridge duty station, everyone else can potentially be posted elsewhere aboard).

Still ... at least I've got something defined now that I can cross compare against when making my own LBB5.80 version using different tech levels and drives and fuel and cargo and and and and ...

 

[Grav_Moped]

The problem with a dual-hatted Pilot/Navigator is that both of those skills are needed simultaneously at the time of Jump. It's a fair tradeoff in a Type S that doesn't technically require a navigator (at least in CT), but less so in a 1KTd XBoat Tender.

Most medical situations can spare the Medic for long enough to plot a Jump.

The XBoat Tender is broken by simple geometry, rather than by the rules (though HG rules break the design also, with their requirement for 10% overage for carried vessels over 99Td in any ship). There was a long-running thread (and probably several over the years) trying to figure out how to pack four 1350m^3 ice cream cones into its mostly-rectangular bay -- and basically, you can't do it despite having (in theory) 200Td extra space to play with.

 

[infojunky]

I have understood courier service to be roughly weekly...

See that is a assumption I can live with. It has been the a question I have been pondering.

On the other hand, it also means you have to tell them where you're going.

If you are liner on a route that isn’t a issue. My assumption that most subsidized liners are on a route, hence the subsidy for a less than optimal route.

 

[infojunky]

.

The XBoat Tender is broken by simple geometry, rather than by the rules (though HG rules break the design also, with their requirement for 10% overage for carried vessels over 99Td in any ship). There was a long-running thread (and probably several over the years) trying to figure out how to pack four 1350m^3 ice cream cones into its mostly-rectangular bay -- and basically, you can't do it despite having (in theory) 200Td extra space to play with.

Hint, they leave the door open.

 

[Spinward Flow]

I have understood courier service to be roughly weekly...

Roughly weekly for off network courier service amounts to 2 starships jumping a continuous loop ... if you're willing to accept that every 8-10 days counts as roughly weekly so as to account for transits to 100 diameters in both star systems (up and down) plus delivery and pickup time delays, refueling (add more time if wilderness refueling away from the starport), stopping to "get lunch" at the starport pub while ground crews recharge the life support systems for you.

A single starship running a single jump loop like that would probably complete a run every 2.5-3 weeks.
You would need to assign three starships to that single jump loop in order to make courier delivery service roughly weekly.

So this is where you can wind up with a "four pack" of Scout/Couriers assigned to transporting communications through jump to systems that are 3-4 parsecs away from the nearest XBoat linked system.
3 Scout/Couriers run a single jump loop from the XBoat system an off-network system 1-2 parsecs away with arrivals approximately every week.
1 Scout/Courier runs a single jump loop from the off-network system 1-2 parsecs still further away with arrivals approximately every 3 weeks.

This then would be why the XBoat routes are laid out such that most (not all, but most) worlds are within 4 parsecs of the nearest Express Network linked system ... and why worlds that are 5-6 parsecs off-network are "out in the boonies" as far as being connected to the rest of the Third Imperium is concerned.

And that's using 4 Scout/Couriers just to jump loops between 2 worlds.
Grow that out to all of the off-network star systems in a single sector (like the Spinward Marches) and you can easily reach 1000+ Scout/Couriers being needed just for dissemination of communications and "news" away from the Express Network ... and that's not counting all of the Scout/Couriers assigned to exploration and survey work, that's just the communications side of things.

No wonder the Scout/Couriers are designed to be as dirt cheap as they are. There might be 100,000+ of them in service with the IISS at all times spread across all sectors of the Third Imperium (and beyond). That's 10+ million tons of hulls! Once you get up to that scale, even small changes in the unit price per starship can have significant budgetary impacts (we're talking giga-credits here). No wonder there's an institutional inertia of the "ain't broke, don't fix it" variety when it comes to the economics of building, maintaining and selling for surplus all of those Scout/Couriers that get rolled over every 40 years.

If you are liner on a route that isn’t a issue. My assumption that most subsidized liners are on a route, hence the subsidy for a less than optimal route.

You may be interested in reading my thoughts about subsidies and when a route isn't a route (complete with example, map and explanation of why there's more than one way to navigate a subsidy).

Hint, they leave the door open.

That's the only logical conclusion, but it makes a right mess of trying to reconcile 600 tons of hangar capacity with the volume that can be encompassed by the jump drive field ... not to mention needing to play 3D Tetris with the ice cream cones and pyramids. I suppose if you put the ice cream cones jump drives "down" into the four corners hangar bay (so the ice cream spheres "overhang" out the top) you can fit a Scout/Courier with drives "down" into the bay between two of them with the tapering point sticking up out of the open hangar bay doors.
X S X
X S X
Rotate the Scout/Couriers longitudinal axis a little bit so they aren't perfectly orthogonal in the bay pointing up/out and you might be able to make everything fit ... with the doors open, as hinted at.

Anyone care to do a bit of woodworking to craft some representative block shapes to scale and see if they "fit in the box" with the lid open?
Or if that's too much trouble, there's always 3D graphics I suppose ...

 

[Grav_Moped]

Hint, they leave the door open.

Now try that with freighters with multiple cargo bays that they can leave open to adjust their effective tonnage for jump.
Try it again with fuel tanks having openable doors.

[can of worms thingy]

 

[Condottiere]

I have, dead silence.

Or, is it dead space?

Or negative space?

Or zeroed volume?

 

[Spinward Flow]

Now try that with freighters with multiple cargo bays that they can leave open to adjust their effective tonnage for jump.
Try it again with fuel tanks having openable doors.

[can of worms thingy]

So long as you account for it in the LBB2 spreadsheet LBB5 spreadsheet Naval Architect's blueprints, what's the problem?

 

[aramis]

That's the only logical conclusion, but it makes a right mess of trying to reconcile 600 tons of hangar capacity with the volume that can be encompassed by the jump drive field ... not to mention needing to play 3D Tetris with the ice cream cones and pyramids. I suppose if you put the ice cream cones jump drives "down" into the four corners hangar bay (so the ice cream spheres "overhang" out the top) you can fit a Scout/Courier with drives "down" into the bay between two of them with the tapering point sticking up out of the open hangar bay doors.

It's actually doable to put 4 in and close the door... but two are upside down, and none aligned to the decks of the tender.
You put one so it's flush against the back left, one against the back right. then the other two are flush against the door center, and inverted from the other two. (I worked it out in Sketchup a long time ago.)

 

[Spinward Flow]

Here's a thought I had while contemplating how to deal with keeping a Tender in orbit on station as a matter of routine.

The first point is that the worst thing that can happen to a Tender is a surprise call to battle stations, for whatever reason. Operationally speaking (for the service), a dull boring day where nothing out of the ordinary happens is a good day. So the first order of business is to locate an Express Tender in a place that is difficult (not impossible, just difficult) to surprise attack. Since breakout from jump would definitely represent a surprise for such an attack, the most obvious bastion location for giving a Tender sufficient time to react to an incoming threat after breakout from jump would be to have the Tender orbit a world within that world's 100 diameters jump shadow. This location has 2 corresponding immediate benefits.

By locating the Tender inside the 100 diameter jump shadow, any starship breaking out of jump cannot be "right on top of" the Tender for either a surprise attack (weapons range?) or in an incredibly unfortunate circumstance needing emergency agility to avoid a collision (I know, I know, space is VAST and a collision is unlikely, but unlikely is not impossible and an impact shortly after breakout is going to ruin EVERYONE'S day). So ideally speaking a Tender would prefer to be on ready standby within the 100 diameter jump shadow of the specific world it is stationed in orbit around, substantially for safety reasons. Gas giants, by virtue of their size, will tend to have the largest 100 diameter jump shadows among planets, and some stars are large enough to have 100 diameter jump shadows that encompass entire planetary orbits (with Pax Rulin/Pax Rulin/Trojan Reach being a prime example of this phenomenon).

Additionally, the closer a Tender is to the world it is orbiting, the faster the Tender will orbit around that world (lower orbits circle faster than higher orbits). This means that although the a lower orbit will increase the shortest distance/time to a recovery rendezvous with an XBoat after breakout from jump at the 100 diameter jump shadow, because of the faster orbital speed around the world such a lower orbit would also dramatically decrease the longest distance/time to a recovery rendezvous with an XBoat after breakout from jump "on the far side" (so to speak) from the orbit the Tender is maintaining. Needless to say, there is going to be a "goldlocks zone" where the orbital distance the Tender maintains while on ready standby awaiting incoming XBoats in which the Tender is orbiting the world "fast enough" to be able to recover an XBoat breaking out of jump in any direction, while at the same time offering the greatest amount of "sky coverage" for communications to be received in which the obscuring disk of the planet isn't large enough from the Tender's orbit to block line of sight transmissions from XBoat to Tender (can't communicate through planets without meson communicators or neutrino communicators, for example). Having 2 or 3 Tenders orbiting a single world eliminates the opportunity for occultation problem of the planet being between the a Tender and an XBoat breaking out of jump on the far side of the planet, delaying download transmission of data communications.

The important thing to remember is that the orbital environment the Tenders are meant to be operating in is an orbital frame in which the Tenders are in continuous motion in orbit around the worlds they are stationed at. Although the Tenders do have maneuver drives and could potentially "park" and station keep on a single incoming vector from another star system, doing so would require that the maneuver drives be in continuous operation (a great way to needlessly use up their lifespan) and the world they would be "parked" around would be orbiting its star anyway, so the vector to/from an interstellar targeting navigation set will be constantly shifting as the planet moves in orbit around its star. The parallax shift might not be that much, but it IS there.

Besides, not everyone's navigation is going to be pinpoint accurate/perfect every single time ... there are going to be errors of navigation occasionally as well as variances within acceptable tolerances. In other words, XBoats aren't going to be breaking out of jump exclusively within a 1000km³ cube of defined space and nowhere else in the vicinity of the world. Some will break out of jump in the "northern/western/southern/eastern hemisphere" of a world's 100 diameter jump shadow, depending on the skill of the navigation involved in setting the jump coordinates before the jump (and the maintenance state of the jump drive itself). Gas giants with their larger 100 diameter jump shadows make for "bigger targets" that can be "more forgiving" of poor target accuracy in jump navigation. Smaller worlds with their comparitively smaller 100 diameter jump shadows can make for "smaller targets" that are easier to "miss" with lower accuracy/precision in jump navigation, resulting in "undershooting" or "overshooting" the planet's 100 diameter jump shadow and winding up possibly some distance away from the intended/desired breakout point from jump.

In other words, it would be a mistake to simply assume that each and every single jump made is going to be "stop on a dime" pinpoint accurate/precise every single time. We are talking about trying to target a planet's 100 diameter jump shadow from up to 3.26*4=13.07 light years away with a starship.

Jupiter in the Sol system, for example, is roughly 70,000km in diameter (a large gas giant), so 100 diameters is 7,000,000km.
1 light year = 9,460,000,000,000km
1 parsec = 30,900,000,000,000km
4 parsecs = 123,600,000,000,000km
7,000,000 / 123,600,000,000,000km = 0.0000000566343042071

Do the sin() math and you find out you're looking at an accuracy/precision of within 0.0116185 arc seconds(!) to be able to hit a Jupiter sized 100 diameter jump shadow from 4 parsecs away.

It may look really big from up close (in orbit) around Jupiter ... but from parsecs away (including 4 parsecs away) ... it's a really small target to try and hit with any kind of reliable accuracy. And just think ... all the other planets in the Sol system are smaller than that and would need even tighter accuracy/precision tolerances to "hit" their 100 diameter jump shadows from 4 parsecs away.



So, circling back to my points above and earlier in this thread ... in my opinion, there is a STRONG bias in the Express Network service to basing Tenders in orbit around gas giants in star systems for what amounts to three fundamental operational reasons.

• Easy access to jump fuel (XBoat operations consume A LOT of fuel!)
• Reduce the impact of navigational accuracy and precision errors (bigger target, less mishaps)
• Defensive bastion against collision/impacts or surprise attacks from jumpspace

Mind you, the last point is more a matter of slowing down how quickly attacks incoming jump traffic can be executed, as opposed to being a matter of prevention. If a Tender is on station "deep enough" within a 100 diameter jump shadow then it would essentially take too long for an attacker to surprise a Tender's crew by jumping in "too close" to a Tender for the Tender to have time to respond. So essentially the Tender would be positioned in an orbit where there is ample warning time after a starship breaks out of jump for the Tender to sound general quarters and be put on alert to whatever the threat is.

Being able to evade/escape/repulse an attacker breaking out of jump is a completely different problem, and Tenders are not exactly known for their maneuvering characteristics (since most prefer to "wallow" around in a gravity well), so being able to evade/escape/repulse a direct attack on a Tender is going to come down more to system defense and fighter assets in the area that can come to the defense of and/or screen a Tender that comes under attack.

Note that orbiting within the 100 diameter jump shadow of a planet (or star) means that Breaking Off By Jumping is usually not going to be an option for a Tender that comes under attack by hostile actors. Tenders stationed outside of a 100 diameter jump shadow however would be capable of executing a Break Off By Jumping maneuver if necessary.

During XBoat recovery operations, it is very likely that a Tender will either be near to or exit the 100 diameter jump shadow limit around a particular planet (or star) because XBoats have no maneuver drive, so if there is a known threat that could prompt a need for a quick exit from a star system at any time (such as a declared war and the like), Tenders may reposition themselves to be a small distance inside the 100 diameter jump shadow such that they can make a "quick getaway" outside the limit before jumping out of the system in the event of needing to beat a hasty retreat away from an incoming hostile force (including invading military forces).

 

[mike wightman]

You haven't read MWM's Jumpspace article?

Jump drives are very accurate.

One of the benefits of the jump drive is its controllability; jumping is predictable. When known levels of energy are expended, and when certain other parameters are known with precision, jumping is accurate to less than one part per 10 billion. Over a jump distance of one parsec, the arrival point of a ship can be predicted to within perhaps 3,000 kilometres (on larger jumps, the potential error is proportionally larger). Error in arrival location is also affected by the quality of drive tuning and the accuracy of the computer controlling the jump; these factors can increase jump error by a factor of 10.

 

[Spinward Flow]

You haven't read MWM's Jumpspace article?

Jump drives are very accurate.

One of the benefits of the jump drive is its controllability; jumping is predictable. When known levels of energy are expended, and when certain other parameters are known with precision, jumping is accurate to less than one part per 10 billion. Over a jump distance of one parsec, the arrival point of a ship can be predicted to within perhaps 3,000 kilometres (on larger jumps, the potential error is proportionally larger). Error in arrival location is also affected by the quality of drive tuning and the accuracy of the computer controlling the jump; these factors can increase jump error by a factor of 10.

As demonstrated above, they would have to be!
But no, I wasn't previously aware of that reference point.

Still, even if we take the assumption of 3,000km tolerance standard deviation at 1 parsec ... it kind of depends on how things scale up from there. Are we talking straight multiplier (x2, x3, x4, x5, x6) for extra parsecs? Or are we dealing with a powers of 2 increase (x4, x9, x16, x25, x36) for extra parsecs?

And that's before factoring in the (up to) x10 multiplier for drive tuning/calibration and navigation computer accuracy/precision.

If we take a "lousy" case scenario of x10 for poor tuning/accuracy (30,000km) and assume a Jump-4 with a powers of 2 increase (because, r²) we're suddenly looking at a situation of having a +/- 480,000km tolerance around the target destination point (circular error probable if you like). For reference, that's the 100 diameters jump shadow size of a world size code: 3 (3000 miles/4800 km), so planetary jump shadows smaller than that could potentially be missed by Jump-4 starships, depending on drive tuning/computer accuracy in navigation.

My point being that " it's a small world after all " will be a lot more challenging to get the pinpoint astrogation exactly spot on right every single time without failure ... by contrast a relatively "big target" such as a Gas Giant (large or small) will be much easier to "always hit no matter what" because of the "proverbial barn door" factor precipitating starships out of jumpspace at useful to work with distances/locations even if their navigation and/or drives are scuffed.

However, this understanding alters the operational calculus for where to best put Express Tenders in orbit around worlds, particularly gas giants. With something akin to a 1,000,000 km diameter patch of sky to be responsible for XBoats breaking out of jump from a known vector, a Tender could potentially "sidereal park" at a distant orbital location within the 100 diameter jump shadow limit, using continuous low power maneuver drive thrust to maintain sidereal station keeping in a high orbit on a known approach vector from nearby star systems (pick one per Tender). Basic idea being that XBoats arriving from Star System 1 always breakout from jump on a specific "side" of the planet's orbital motion, so you don't have to try and cover ALL orbital approach vectors with a single Tender. You can just assign 1 Tender per incoming approach vector.

So if you have 3 systems that dispatch XBoats into a particular star system, you'll logistically want to have 3 Tenders on station (one for each approach/departure vector) operating independently in support of that point to point transfer segment of the Express Network.

So if there are 3 Tenders on station at Persephone/Lunion/Spinward Marches, they would be positioned at the sidereal vector approaches from Tenalphi, Marastan and Strouden. If there is a 4th Tender assigned at Persephone, they would also be able to cover the vector approach from Shirene as well so as to have coverage for all XBoats that could Jump-4 to Persephone.

After that, you simply assign 1 more Tender to the group to permit rotations for servicing/maintenance/overhauls.
So if Persephone has only 3 Tender stations, there would be 4 Tenders assigned to the system (with the 4th offline for maintenance/downtime).
If Persephone has only 4 Tender stations, there would be 5 Tenders assigned to the system (with the 5th offline for maintenance/downtime).

By contrast, a place like Lanth/Lanth/Spinward Marches only has 2 star systems to connect to on the Express Network. Consequently it would only need 2 Tenders on active duty to receive XBoats from Ghandi and D'Ganzio, with a 3rd Tender offline for maintenance/downtime in reserve so as to rotate active duty with the other 2 Tenders. The same would be true for Ghandi and D'Ganzio, since each of those star systems only link to 2 other systems on the Express Network in the Lanth subsector of the Spinward Marches.

Lanth might have extra XBoats and Tenders assigned to it than just 3, but all that would really do is increase the tempo of XBoat communications to Ghandi and D'Ganzio, but it wouldn't significantly speed up communications tempos downstream of Ghandi and D'Ganzio because of Lanth's location in the network. Doubling the number of XBoats departing Lanth to D'Ganzio doesn't increase the tempo of XBoats departing D'Ganzio for Ivendo (and on to Rhylanor, Lunion or Mora subsectors), so there's a definite "bottleneck" factor involved in some segments of the Express Network. Merely doubling the number of Tenders and XBoats assigned to a subsector capital (only) doesn't modify the operational tempo of the network away from the subsector capital.

So just like with TCP/IP routing and switches, the bandwidth of the entire "pipe" of data along the relays in the network can be subject to slowdowns away from the fastest/widest bandwith portions of the network. The trick then is to figure out where adding capacity to the network ought to help "unclog the arteries" of the communications pathways across the network to speed up the flow without needing to buy all new equipment (just more of the old stuff to widen the pipes) ... and that's something that manifests itself only after the network has been put into action and been operational for some time, hence my assumption of 10 year sector reviews of communications flows inside each sector to "rebalance the load" over time as populations grow, settlements mature and the ebb and flow of trade and commerce shifts and adjusts over the centuries.