Pondering starship evolution

[Silverhawk]

Fair enough. I only went into the weeds on this to correct the historical record and highlight the limits of the engineering metaphor.

What happened with the arguably TL transitions was very much a factor of multiple conditions and it could, likely would have played out very differently without the war and specifics of the US industrial plant and transport needs.

I would take that to mean things can play out in your universe any darn way you like, just work out the background to a consistent level whether you do SFlow’s full business case driven ship designs or some lesser involved but unlikely to be punctured by player disbelief.

I totally understand. When it comes to railroads I can get seriously into the weeds (or the ruff for you golfers). I try to keep it under firm control to stay away from straying off topic.

And you're right about the TL transition. This is a good example of new tech vs old tech and the inertia that adoption sometimes has to overcome.

I also absolutely agree about consistent background for (any) universe. There are a number of ideas that I have tossed over the years before they even are suggested for play because I was/am not satisfied with the consistency.

 

[Spinward Flow]

I would take that to mean things can play out in your universe any darn way you like, just work out the background to a consistent level whether you do SFlow’s full business case driven ship designs or some lesser involved but unlikely to be punctured by player disbelief.

In my case, the reason why I "go so far" as to examine the "full business case driven ship designs" can be summed up in a single word.

But jokes aside ...the other reason is to delve into the "end user experience" of what it means to LIVE WITH the design choices of the Naval Architect's Office Work for years/decades of operations, so as to learn what impacts different choices make on The Bottom Line™ for bean counters who care about profit margins (because their lives and livelihoods depend on them, so ... go figure, eh? ).

It's something of a "traveling salesman problem" to figure out what kind of starship class design you "need" in order to be able to operate as a tramp merchant along the frontier with enough self(ish) sufficiency AND security to be able to keep operating for years/decades and have a decent expectation that you'll "come out ahead" after all that work (with hopefully enough profit to re-invest and start the cycle all over again).

And yes, in order to investigate that question and the impacts of design decisions made before construction, you kind of HAVE TO do the sort of deep dive into The Simulation™ that I've been exploring over the long haul of this thread, with the occasional foray into making deck plans once I've got the Naval Architect Office Spreadsheet of features and functionality nailed down.

At some point here, I'm going to switch over to the (newer) 300 pixels per deck square resolution size Geomorphs set and start making new sets of deck plans for a 100 ton Scout/Courier (Type-S2), a 280 ton Rule of Man Long Trader and a 410 ton Rule of Man Clipper ... because it's FUN to think about these things and see where they go.

The bonus experience then becomes realizing that just because a class design was built by a specific polity (Second Imperium/Rule of Man, pre-Long Night) doesn't mean that the engineering, design and business operation principles are necessarily "confined" to that polity (or era) only. Convergent Evolution IS A THING, even in the realm of interstellar transport and merchant operations, so the insights that I manage to tease out of the CT ruleset can be broadly applicable to more than just a single point in time or specific region of space.



For example ...



The Vilani designed J1/1G Free Trader is something that "makes sense" if your homeworld is part of a J1 Main.
The Vilani Main includes 985 star systems.

It therefore makes perfect sense for the Vilani to have somewhat subtantially stagnated on J1 as being "adequate" to most interstellar transport "needs" when building out an empire from their home star system.

Likewise, Zdant is a part of the Zdant Main and thus J1 would be "adequate" for most interstellar transport "needs" in the Zhodani polity when building out the Consulate for an extended period of time.



By contrast, the Solomani homeworld is NOT on a Main ...

... and thus J1=1 parsec range interstellar transport options would be ... sub-optimal ... to the needs of any Rule of Man Empire that needed to interface with the homeworld of the Solomani. That kind of "environmental pressure" resulting from the jump map arrangement of nearby stars would therefore logically produce a "need" for J2=2 parsec range interstellar transport options that would become an enduring "feature" of the cultural attitudes of businesses within the polity of the Second Imperium/Rule of Man/Ramshackle Empire. I can also likely surmise that such "demands for mercantile range options" are what (eventually) prompted the development of the Vilani J2 Far Trader class design after the Interstellar Wars era.

But that still begs the question ... what kind of (early expansion) starship classes would the Solomani have been building as their "tramp merchant" starship classes in time to meet the needs of the Second Imperium? Because no matter what anyone says, your basic J1/1G Free Trader is simply NOT GOING TO CUT IT as an all around solution for "small time, breakbulk" merchant transport to all locations.

Furthermore, there are going to be places on the map where you need 2+ parsecs of range in order to "marry up" differing interstellar markets. Caravanserie can help bridge between J1 Mains, but their services can potentially be "expensive" (in a variety of ways and meanings), so ... Use At Own Risk. Sometimes you're going to want to have an unrefueled range of 3-4 or even 5-6(!) parsecs, in order to bypass/jump over potential trouble spots/profit loss sinks on the way to your ultimate destination. Being able to multi-jump through empty hexes on the interstellar map can be a highly advantageous shortcut *IF* your starship is capable of performing such maneuvers (reliably).

All of these considerations would have far more "merit" to them in the context of a Solomani cultural background than would be the case with a Vilani (or Zhodani) cultural background ... because Main: YES vs Main: NO.



And then you get to places like the Great Rift, Lesser Rift, Delphi Rift and Windhorn Rift where the demand for jump RANGE becomes an overriding priority (of the "you must be this high to ride this ride" variety). Any kind of extended range (via multi-jump) starship design can (start to) solve the "problem" of being able to transit across the Rifts while still carrying a "useful load" of revenue tonnage capacity for doing merchant transport work with. What does it take in order to jump so far into the void and make it back out again? Is it even (theoretically) possible to do so ... and still turn a profit, so the business enterprise can survive long enough to keep making the journey(s)?

Vilani attitude: That's Somebody Else's Problem.
Solomani attitude: HOLD MY BEER.

Those kinds of differences in cultural background then become the springboard for fun little ideas of how to tackle these kinds of challenges ... and what might result from success in those efforts ... to Boldly Go Where No One COULD Go Before ...

 

[whartung]

By contrast, the Solomani homeworld is NOT on a Main ...

I went and looked it up in GT:ISW to find out how the Terrans broke out early one with just J1, and with ISW, early on, you couldn't jump to "empty space".

They mention that they surveyed for a rogue planet out in the dark that was with J1, then built it up as a remote fueling base before breaking out to Bernards Star. I imagine they kept that up until they connect to the J1 main and spread like rats.

 

[Spinward Flow]

I went and looked it up in GT:ISW to find out how the Terrans broke out early one with just J1, and with ISW, early on, you couldn't jump to "empty space".

They mention that they surveyed for a rogue planet out in the dark that was with J1, then built it up as a remote fueling base before breaking out to Bernards Star. I imagine they kept that up until they connect to the J1 main and spread like rats.

Exactly.
A Calibration Point within 1 parsec was necessary in order to "escape" from the Solomani home star system and reach their first J1 main segment ... at which point the Land Grab™ was ON and the Solomani spread between the stars.

Eventually, the Solomani "cracked" the secret of being able to jump into empty space/hexes and then jump again, but that was a later development, later on down the timeline.

 

[Rupert]

The Vilani designed J1/1G Free Trader is something that "makes sense" if your homeworld is part of a J1 Main.
The Vilani Main includes 985 star systems.

It therefore makes perfect sense for the Vilani to have somewhat subtantially stagnated on J1 as being "adequate" to most interstellar transport "needs" when building out an empire from their home star system.

Likewise, Zdant is a part of the Zdant Main and thus J1 would be "adequate" for most interstellar transport "needs" in the Zhodani polity when building out the Consulate for an extended period of time.

Looking at other species, the K'kree start on a decent main, and have a couple of other large mains in their empire, so they get a decent start before their inefficient starship design practices will start to bite.

Aslan space tends towards being bunches of clusters and short mains, but they got to start with a decent type of jump drive and this astrography probably suits their preferred political and trade structure. Hiver space is much the same, which would've slowed them right down with their early (terrible) jump drives.

Vargr space is similar, but contacts some really nice mains, one going deep into Zho territory, another other deep into Vilani (now Imperial) space. Fun for everyone.

Solomani space is just awful, with tiny clusters, and next to no decent mains until you get well into Vilani/Imperial space to coreward. Rimward, it's just scattered clusters. It's easy to see why the Solomani went coreward, especially once Vilani political and military resistance collapsed. It wasn't just more attractive politically and commercially, but also astrographically. So rimward settlement by the Solomani being something that was done by fringe groups who wanted to get lost and 'insurance' projects by paranoid Terrans in the early days makes a good deal of sense.

 

[AlHazred]

Solomani space is just awful, with tiny clusters, and next to no decent mains until you get well into Vilani/Imperial space to coreward. Rimward, it's just scattered clusters. It's easy to see why the Solomani went coreward, especially once Vilani political and military resistance collapsed. It wasn't just more attractive politically and commercially, but also astrographically. So rimward settlement by the Solomani being something that was done by fringe groups who wanted to get lost and 'insurance' projects by paranoid Terrans in the early days makes a good deal of sense.

It's not paranoia when SolSec/Vilani Shadow Imperium/Ancients (probably) are definitely out to get you!

 

[Spinward Flow]

Solomani space is just awful, with tiny clusters, and next to no decent mains until you get well into Vilani/Imperial space to coreward. Rimward, it's just scattered clusters.

I hadn't done a deep dive into the interstellar mapping of the other major race homeworlds like you've done here ... but it's Nice To Know™ that the Solomani are basically the only major race (aside from the Droyne!) who started at a "2+ parsecs away from anywhere useful" disadvantage with respect to the location of their homeworld and the astrogation needed in the region around that starting point once jump drive got discovered.

 

[Condottiere]

In theory, they could have hopscotched in quarter parsec increments, with jump factor/zero drive, to the next star system.

 

[mike wightman]

Which is how I think they really did it.

Canon has conflicting stories with just enough wiggle room.

Earth produced jump drives required a mass to aim at, consumed all their fuel in the jump, and yet took a long time to get there and back.

I think a more likely scenario is that the fifferent nations trying for the first interstellar mission had to do it the hard way, jump to the furthest kueper/oort object that had been detected along the path of travel to the destination star. Once there they would need a JWT like array to find the next suitable body to jump to, not to mention fuel and stores to be brought by support vessels. The would thus make the crossing in multiple small jumps from object to object until they are actually detecting suitable bodies in the "kuiper/oort" region of the target system.

The US, ESA, China, India, Russia all had their missions, the US was lucky in that they found their path first. It is also likely they were all attempting different routes to different nearby stars. Fortunately the US mission encountered Vilani traders rather than a fully occupied Ziru Sirka world...

the rest, as they say, is future history.

 

[Condottiere]

Default ten percent fuel consumption is minimum, so it's obvious why development kept to factor/one.

But, in the spirit of hitting the hundred diameter boundary, a quarter parsec jump can exit, look around, set up sensors, and jump back.

 

[Spinward Flow]

a 100 ton Scout/Courier (Type-S2), a 280 ton Rule of Man Long Trader and a 410 ton Rule of Man Clipper

Finally had time to do the necessary mathematical jiggery-pokery (the proper technical term, I'm led to believe) to redesign a 100 ton Scout/Courier into being something that uses the 30 ton Box inside an internal hangar bay as an intentional design feature which then becomes easy to "hot swap" for different mission profiles.

Here's what popped out the other end of that effort.

---

Rule of Man Scout/Courier (Type-SP, TL=9)
100 tons starship standard hull, atmospheric streamlining (configuration: 2) (MCr3) (LBB2.81, p15, p22)
0 tons for Armor: 0 (TL=9, Composite Laminates, bulkhead thickness=20cm)
15 tons for LBB2.81 standard A/A/A drives (codes: 2/2/2, TL=9, EP=2, Scout) (MCr22) (LBB2.81, p22)
32 tons of total fuel: 100 tons @ J2 = 20 tons jump fuel + 20 tons power plant fuel
20 tons for bridge (200 ton rating, MCr1)
2 tons for model/2 computer (MCr9)

• Standard software package (MCr2 budget for programs) (LBB2.81, p41)
  • Maneuver (Space=1, MCr0.1)
  • Jump-1 (Space=1, MCr0.1)
  • Jump-2 (Space=2, MCr0.3)
  • Navigation (Space=1, MCr0.4)
  • Generate (Space=1, MCr0.8)
  • Library (Space=1, MCr0.3)
• 0.1+0.1+0.3+0.4+0.8+0.3 = MCr2

1 ton for hardpoint+dual turret: no weapons (MCr0.6) (LBB2.81, p23)
30 tons for hangar capacity (MCr0.06)

• 16Sta14Car Box = 30 tons

* External Docking: 100 tons capacity (MCr0.2)

1. 
   
2. 
   

0 tons for cargo hold

= 0+15+32+20+2+1+30+0 = 100 tons
= 3+22+1+9+0.6+0.06+0.2 = MCr35.86

= MCr35.86+(4.169) = MCr40.029 * 1.0 = MCr40.029 single production
= MCr35.86+(4.169) = MCr40.029 * 0.8 = MCr32.0232 volume production

Crew = 1 (Cr6000 per 4 weeks crew salaries)

1. Pilot-1 = (6000*1.0) = Cr6000

• J2, 2G, Agility=2: 100 + 0 = 100 combined tons
• J1, 1G, Agility=1: 100 + 100 = 200 combined tons (3x 30 ton Boxes = 90 tons)

---

16Sta14Car Box (Type-RU, TL=9)
30 ton small craft hull, configuration: 4 (MCr1.8)
0 tons for Armor: 0 (TL=9, Composite Laminates, bulkhead thickness=20cm)
16 tons for 4x single occupancy starship staterooms (MCr2)
* External Docking: 6x 30 = 180 tons capacity (MCr0.36)
14 tons for cargo hold (vehicle berth or mail vault conversion ready)
• 9 tons for 9 ton capacity internal demountable fuel tank (MCr0.009)

= 0+16+14 = 30 tons
= 1.8+2+0.36+0.009 = MCr4.169 single production

---

Decided that I needed a "better standardized encoding method" to identify the various types of 30 ton Boxes, which could quickly/succinctly convey the major features inside. The solution was an extremely simplistic:

• 2 digits (indicating tonnage allocation) + first 3 letters of the feature/fitting
• repeat as necessary until all major design features/fittings specific to a particular Box are detailed
• add 1 space followed by the word "Box"

So the 16Sta14Car Box (seen above) is a 16+14=30 ton Box with 16 tons of staterooms (so 4x staterooms) and a 14 ton cargo hold as the basic features of that particular outfitting.



As mentioned previously (the last time I brought up the notion of a redesign of the stock Type-S Scout/Courier of LBB2 fame), the end result is slightly more expensive than the Vilani version ... but that's because the Solomani (Rule of Man) redesign is made with a "tow hitch" capability to facilitate external loading compatible with the 30 ton Box containerized modular shipping transport standard that I've come up with for the 280 ton Rule of Man Long Trader and the 410 ton Rule of Man Clipper starships, respectively. Other benefits include sufficient fuel capacity for J2+2 (32+9=41 tons) and the inclusion of the Generate program in the Standard Software Package, thanks to the upgrade to the model/2 computer, which completely dispenses with the need to purchase Jump Tapes (Cr10,000 per parsec of radius from star system of origin) in order to be able to jump.

In terms of the "tonnage budget" compared to the stock Type-S Scout/Courier ... the modifications functionally amount to:

1. The air/raft berth is removed, increasing cargo capacity from 3 tons to 7 tons.
2. Cargo capacity is reduced from 7 tons to 6 tons in order to upgrade the computer from model/1bis to model/2.
3. Cargo capacity is reduced from 6 tons to 5 tons in order to increase (combined) fuel tankage capacity from 40 tons to 41 tons, which then enables J2+2 before needing to refuel.
4. 5 tons of cargo capacity is sufficient for a mail vault (for courier duty) OR an air/raft + 1 ton of life support consumables reserves for extended operational endurance missions and duty assignments (exploration, survey, etc.). Courier duty would require the installation of offensive weaponry in the (dual) turret and the assignment of a Gunner to the crew roster, along with the purchase of the Target computer program (if using LBB2 space combat rules).

Being able to dock with external loads of up to 3x Boxes and still be capable of J1+1/1G drive performance makes a tremendous number of modular transport mission tasking options possible, while retaining a 2 parsec range before needing to refuel. The internal hangar bay is used to enable orbit to surface shuttle transfers through atmosphere without needing to rely upon the services of other craft. This makes it possible to deliver relief supplies (cargo Box), living agricultural products (environment Box), stasis passengers (low berths Box) and even outpost modules for sustained habitation/exploration/survey missions to extremely remote and austere locations in support of an incredibly wide variety of tasking needs. It even means that "in a pinch" the class can be used as a makeshift fuel transfer shuttle/tanker, using 3x 30Car Boxes with 30 ton collapsible fuel tanks installed inside, should the need arise (in sufficiently permissive environments).

 

[Spinward Flow]

16Sta14Car Box (Type-RU, TL=9)
30 ton small craft hull, configuration: 4 (MCr1.8)
0 tons for Armor: 0 (TL=9, Composite Laminates, bulkhead thickness=20cm)
16 tons for 4x single occupancy starship staterooms (MCr2)
* External Docking: 6x 30 = 180 tons capacity (MCr0.36)
14 tons for cargo hold (vehicle berth or mail vault conversion ready)

• 9 tons for 9 ton capacity internal demountable fuel tank (MCr0.009)

= 0+16+14 = 30 tons
= 1.8+2+0.36+0.009 = MCr4.169 single production

Is an internal demountable fuel tank (9 tons) really the best choice here?

• A demountable tank consumes tonnage regardless of whether it is filled or empty of fuel, so the tonnage is "inflexible"
• A demountable tank is "immediately available" as a fuel source (as if it were an internal fuel tank)

The thing is, the 9 tons of fuel in that tank will be "almost never" needed on an unplanned/immediate/emergency basis. It's there as a fuel reserve for jumps, but the internal fuel tankage of the 100 ton starship is 32 tons ... and thus fully capable of supporting the 20 ton fuel cost of a 2 parsec jump without requiring additional fuel reserves.



By switching to a 9 ton collapsible fuel tank instead of a 9 ton demountable fuel tank in the cargo hold, additional "usable" cargo space becomes contextually available (relative to the alternative) on a situational basis.

• 14 tons = 9 tons internal demountable fuel tank + 5 tons of multi-purpose capacity
• 14 tons =
  • 14 tons internal collapsible fuel tank + 0 tons of multi-purpose capacity
  • 9 tons internal collapsible fuel tank + 5 tons of multi-purpose capacity
  • 0.14 tons of (empty) collapsible fuel tank + 13.86 tons of multi-purpose capacity
  • 0.1 tons of (empty) collapsible fuel tank + 13.9 tons of multi-purpose capacity

Sure, fuel transfer time increases when using a collapsible fuel tank (3 hours, according to LBB A5, p13) rather than being fungible/instantly available with a demountable fuel tank ... so there IS a tradeoff. However, the typical/nominal circumstances under which that fuel reserve ought to be used/consumed will involve plentiful lead times/advance planning ANYWAY in which a 3 hour delay for a fuel tankage transfer becomes something of a non-issue.

For example ... when double jumping (J2+2 or J1+1) and spending 16 hours after breakout from jump on routine drive maintenance checks (LBB5.80, p17) ... that's plenty of time for a 3 hour fuel transfer to take place during the routine drive maintenance checks from the collapsible fuel tank (Box) to the internal fuel tanks (starship) prior to making the second of two jumps. It's not like the fuel transfer "needs to wait" until AFTER the 16 hour drive maintenance checks have been completed before the fuel transfer can begin. The 16 hour post-breakout routine drive maintenance checks can be happening concurrently while the 3 hour fuel transfer operation is going on, so in normal/routine operations there's "no (additional) delay" before jumping a second time.

It WOULD however mean that instead of being able to make a second jump "within the hour" after breakout that there would be a "minimum delay" (of at least 3 hours) before being able to initiate a second jump ... so rapid flashes (breakout, jump again) would not be possible with a collapsible fuel tank.

Which then brings up the notion that the internal demountable fuel tank is the "better option" for RAPID courier demands and mission tasking ... while the collapsible fuel tank alternative is the "more flexible choice" for more ROUTINE and ordinary deployment schedules where quickness to final destination is less of an issue/priority.

---

16Sta14Car Box (Type-RU, TL=9)
30 ton small craft hull, configuration: 4 (MCr1.8)
0 tons for Armor: 0 (TL=9, Composite Laminates, bulkhead thickness=20cm)
16 tons for 4x single occupancy starship staterooms (MCr2)
* External Docking: 6x 30 = 180 tons capacity (MCr0.36)
14 tons for cargo hold (vehicle berth or mail vault conversion ready)

• 0.1 tons for 10 ton capacity collapsible fuel tank (MCr0.005)

= 0+16+14 = 30 tons
= 1.8+2+0.36+0.005 = MCr4.165 single production

---

It's not that one alternative is "better" than the other in all possible contexts and circumstances ... but rather that the two different options/implementations play to different operational strengths when needing to double jump. Which alternative is "better" for the mission(s) depends on what the mission(s) are intended to be (and why you would want to be operating That Way™).

Oh and as a bit of side note trivia for the collapsible fuel tank option ...
The 20 ton Launch and 30 ton Ship's Boat (LBB2.81, p18) have 13 tons and 13.7 tons of multi-purpose/reconfigurable cargo space in them, respectively ... so a 30 ton Box having (up to) 13.9 tons of unused cargo hold capacity is hardly "out of bounds" for small craft at these tonnages (except that the Launch and Ship's Boat both have drive systems ).

 

[Spinward Flow]

Aw ... {FNORD}



So I was looking at stress testing fuel endurance under the most adverse of conditions ... which in this case involved the 280 ton J2/2G Long Trader attempting a 6 parsec unrefueled range without using L-Hyd Drop Tanks. This means J2+2+2.

Originally I had calculated the fuel consumption for this performance based on use of 24 ton Boxes (not 30 ton).
The starship design (currently) has an 82 ton internal fuel tank, a 120 ton hangar bay, a 2 ton cargo bay and a 122 ton collapsible fuel tank stored in that cargo bay.
Here's how the computation for that shook out.

Revenue Tonnage @ J2+2+2/2+2+2G = 400 combined tons/328 combined tons/280 combined tons

• Fighter Escort docked externally (24 tons)/Fighter Escort docked externally (24 tons)/Fighter Escort docked internally (24 tons)
• 4x Boxes docked external/3x Boxes loaded internal/4x Boxes loaded internal
• 4x high passengers
• 0x low passengers
• 0 tons internal cargo capacity
• 24 tons owned environmentally controlled cargo capacity
• 0 tons internal hangar cargo capacity
• 122 tons collapsible fuel tank in internal hangar+internal cargo hold

Fuel Consumption: 82+122-400*0.2-328*0.2-280*0.2 = 2.4 tons remaining

For a more thorough explanation, here's what basically happens.

When ready to jump from the origin system, the (24 ton) Fighter and 4x (24 ton) Boxes are docked externally to the 280 ton starship.
280 + 5*24 = 400 combined tons
J2 @ 400 combined tons costs 80 tons of fuel.

Following breakout after the first jump, 80 tons of fuel can be transferred from the collapsible fuel tank in the internal hangar bay into the starship's internal fuel tanks. This then makes 80 tons of internal hangar space available to move 3x (24 ton) Boxes inside the starship's hull in preparation for the second jump. The (24 ton) Fighter) and 1x (24 ton) Box remain docked externally.
280 + 2*24 = 328 combined tons
J2 @ 328 combined tons costs 65.6 tons of fuel.

Following breakout from the second jump, the remaining 122-80=42 tons of fuel left in the collapsible fuel tank can be transferred into the starship's internal fuel tanks. This then frees up the entirety of the internal hangar bay to accommodate the (24 ton) Fighter and all 4x (24 ton) Boxes internally, leaving no external loading to be towed outside the hull.
280 + 0*24 = 280 combined tons
J2 @ 280 combined tons costs 56 tons of fuel.

So ... 82+122-400*0.2-328*0.2-280*0.2 = 2.4 tons remaining after completing J2+2+2
That's 2.4 tons of fuel to meet the needs of Basic Power and the EPs needed to maneuver.



The PROBLEM that I encountered is ... what happens if you convert 5x 24 tons = 120 tons into being 4x 30 tons = 120 tons in terms of modular form factors.

Well ... the jump fuel consumption rate "doesn't work/fit" anymore.



With a 24 ton modular form factor "building block" ... after making a 400 ton J2 = 80 tons of fuel consumed, you can move 3x 24 = 72 tons of loading from external to internal, so the second jump gets made at 328 combined tons. But if you're working with a 30 ton form factor, you can only move 2x 30 = 60 tons of loading from external to internal, so the second jump gets made at 340 combined tons and the third jump gets made at 280 tons.
Here's how that tonnage differential computes out in actual practice:

• 24 ton Boxes: 82+122-400*0.2-328*0.2-280*0.2 = 2.4 tons remaining for Basic Power and Maneuver over the duration
• 30 ton Boxes: 82+122-400*0.2-340*0.2-280*0.2 = 0 tons remaining for Basic Power and Maneuver over the duration

In other words ... OOPS!



I can ALMOST make it work by doing a J1+1+2+2 in order to reach 6 parsecs of range using the 30 ton Boxes form factor ... but that's an UGLY UGLY HACK of a row to hoe.

• 30 ton Boxes: 82+122-400*0.1-370*0.1-340*0.2-280*0.2 = 3 tons remaining for Basic Power and Maneuver over the duration

It's basically "not worth the effort" at that point.
Yes, it can be done but it "takes too long" to reach the destination 6 parsecs away (via 4 jumps instead of 3).



So although in other respects there's basically "no difference" between 5x 24 = 120 and 4x 30 = 120 in terms of "stacking" the tonnage of the modules themselves ... when it comes to the "breakpoints in rates of fuel consumption over multiple jumps" the 24 ton form factor is actually a SUPERIOR OPTION because it makes the TL=9 J2/2G in 280 tons Long Trader "viable" when needing to transit 6 parsecs without refueling.

That in turn means going back to the 24 ton Boxes (and Fighter) form factor, which in turn means a 7.5m x 7.5m x 6 m (5:5:4 ratio of dimensions) "square box shape" to do everything with. That's a 5x5 deck squares floor plan on 2 decks ... which then means a single access corridor on the centerline of each deck (with a grav lift shaft in the center for vertical access). However, those central access corridors can be rotated 90º to each other on the two decks (fore/aft on the lower deck, port/starboard on the upper deck, for example).

The alternative would be a 15m x 7.5m x 3m (10:5:2 ratio of dimensions) "rectangular box shape" to do everything with. That's a 10x5 deck squares floor plan on a 1 deck.

Ironically, the 7.5m x 7.5m x 6m "double deck, square box" form factor would have trouble accommodating a variety of Geomorphs vehicle iconography, since there are plenty that need more than 5 deck squares of length in order to fit. So, strangely enough, it might be necessary to berth parking spot some types of vehicles DIAGONALLY inside such a form factor, with the egress doors opening from the sides so as to enter/exit from the CORNERS of the Box, rather than from the "flat sides" of the Box. Just one of those bits of trivia that crop up when working at small scales with form factors that can't be conveniently "divided up" and redistributed to fill every cubic meter available to work with inside the bulkheads.







Could always do the Stateroom/Lab/Environment/Cargo Boxes as the 7.5m x 7.5m x 6m "double deck" form factor ... then make the Fighter work with the 15m x 7.5m x 3m "single deck" form factor on the deck plans. That way, BOTH form factors of identical tonnage would be "available" for modular swapping depending on demand for transport services, improving flexibility in the long run.

The "double deck" form factor has a lot of advantages to it, especially when "stacking arrays" of them together in (almost) any orientation relative to each other to form outpost base habitats and the like.

Conversely, the "single deck" form factor is better for "sleek needle/wedge" hull forms (Configuration: 1) that ought to work as an airframe style hull design when laying out deck plans.



At any rate ... BACK TO THE DRAFT BOARD ... again ... at the Naval Architect's Office!
Now I've got 3 starship classes (100 ton J2/2G Scout/Courier, 280 ton J2/2G Long Trader, 410 ton J3/3G Clipper) designs that all need to be updated for commonality of using the 24 ton Box form factor and abandon the 30 ton Box form factor ... because of fuel limitations in the 280 ton J2/2G Long Trader.

Roll the jingle ...

 

[Silverhawk]

---

16Sta14Car Box (Type-RU, TL=9)
30 ton small craft hull, configuration: 4 (MCr1.8)
0 tons for Armor: 0 (TL=9, Composite Laminates, bulkhead thickness=20cm)
16 tons for 4x single occupancy starship staterooms (MCr2)
* External Docking: 6x 30 = 180 tons capacity (MCr0.36)
14 tons for cargo hold (vehicle berth or mail vault conversion ready)

• 0.1 tons for 10 ton capacity collapsible fuel tank (MCr0.005)

= 0+16+14 = 30 tons
= 1.8+2+0.36+0.005 = MCr4.165 single production

So I like the idea of a quick identifier. I'm keeping in mind that every company that has to classify it's equipment of a certain type is either going to use the manufacturer's model designation or as it was one time for the railroads their own system.

So for my traveller universe I might classify this module as P4C14. (P)assenger (4) (C)argo (14). If the module was equipped with a mail vault it would be a P4C9M. (P)assenger (4) (C)argo (9) [remember the 5 tons for the mail vault has to come from somewhere] (M)ail.

I'm working something similar for civilian ships based on primary use, C for cargo, P for Passenger. So a 200 ton Jump 2 2g cargo ship might be a C222 series for example.

The idea is to be descriptive in a concise manner.

Just my thoughts on it

 

[Spinward Flow]

So I like the idea of a quick identifier.

Me too, hence why I'm moving to it.

So for my traveller universe I might classify this module as P4C14. (P)assenger (4) (C)argo (14). If the module was equipped with a mail vault it would be a P4C9M. (P)assenger (4) (C)argo (9) [remember the 5 tons for the mail vault has to come from somewhere] (M)ail.

I considered doing (what amounts to) the same thing ... until I realized that the single letter designation created opportunities for confusion when different words start with the same letter.

(P)assenger also doesn't differentiate between high/mid/low, let alone accommodations for crew.
(C)argo could be confused with (C)rew, for example.
(F)ighter and (F)uel could be problematic, before even getting to (F)uel Purification Plant
(L)ow berths and (L)aboratory was another potential point of confusion that could arise from a premature optimization down to a single (first) letter.
And that's not even including potential "oddball" cases where that kind of truncation could result in some very nasty disambiguation problems.

That's why I moved in the direction of a more descriptive "3 letters + 2 digits" encoding for what the Boxes would be fitted out with. Using the 2 digits for tonnage allocated, rather than quantity of item being fitted helps with standardization when dealing with things that don't have discrete units of quantity (such as cargo holds) that are done in blocks of a multiple (1 stateroom = 4 tons, for example). Easier to give the tonnage and compute "how many of those you get" rather than give the quantity and then try to compute "how many tons does that add up to" going in the other direction.

Best example of this phenomenon would be the double stateroom suites for 1 person (ala Type-Y Yacht from LBB2). If you give the quantity of staterooms, counting the "double" stateroom as 1, you open yourself up to issues later when it comes time to reconcile the accounting of internal volume (unless you "know" there's an unusual case involved in this instance). By contrast, if you give the tonnage devoted to staterooms instead, whether they are single staterooms or double suites "doesn't matter" that much for the topline descriptor, which is only concerned with the tonnage allocated to which purposes. 4x single staterooms = 2x double stateroom suites = 16 tons ... no matter which way you slice it.

So more of a "six of one, half a dozen of the other" sort of difference.
The immediate meaning is the same ... but the "downstream implications when put into practice" differentiate pretty quickly.

 

[Silverhawk]

Me too, hence why I'm moving to it.

I considered doing (what amounts to) the same thing ... until I realized that the single letter designation created opportunities for confusion when different words start with the same letter.

(P)assenger also doesn't differentiate between high/mid/low, let alone accommodations for crew.
(C)argo could be confused with (C)rew, for example.
(F)ighter and (F)uel could be problematic, before even getting to (F)uel Purification Plant
(L)ow berths and (L)aboratory was another potential point of confusion that could arise from a premature optimization down to a single (first) letter.
And that's not even including potential "oddball" cases where that kind of truncation could result in some very nasty disambiguation problems.

That's why I moved in the direction of a more descriptive "3 letters + 2 digits" encoding for what the Boxes would be fitted out with. Using the 2 digits for tonnage allocated, rather than quantity of item being fitted helps with standardization when dealing with things that don't have discrete units of quantity (such as cargo holds) that are done in blocks of a multiple (1 stateroom = 4 tons, for example). Easier to give the tonnage and compute "how many of those you get" rather than give the quantity and then try to compute "how many tons does that add up to" going in the other direction.

Best example of this phenomenon would be the double stateroom suites for 1 person (ala Type-Y Yacht from LBB2). If you give the quantity of staterooms, counting the "double" stateroom as 1, you open yourself up to issues later when it comes time to reconcile the accounting of internal volume (unless you "know" there's an unusual case involved in this instance). By contrast, if you give the tonnage devoted to staterooms instead, whether they are single staterooms or double suites "doesn't matter" that much for the topline descriptor, which is only concerned with the tonnage allocated to which purposes. 4x single staterooms = 2x double stateroom suites = 16 tons ... no matter which way you slice it.

So more of a "six of one, half a dozen of the other" sort of difference.
The immediate meaning is the same ... but the "downstream implications when put into practice" differentiate pretty quickly.

Absolutely agree that differentiation could be a problem. But I like to think that these are where plot complications are created.

PC #1 - What do you mean its the wrong container?

Broker - Its the wrong container. Look the notice required a P4C14.

PC #2. - Yeah, and that's what we got.

Broker - No no, you boys have a P4C9M with the mail vault. The cargo is 12 tons and you only have 9 tons available.

PC #1 - We can put it in the vault.

Broker - No, you can't without violating IR (Imperial Regulation) 77345.205(b)

So, how are our daring heroes going to handle this conundrum?

 

[Spinward Flow]

"There are no experimental failures. There's only more data."
- Bryce Lynch, Head of Research & Development, Network XXIII

So after realizing that I couldn't standardize on a 30 ton Box form factor and still make my 280 ton J2/2G @ TL=9 Long Trader remain capable of J2+2+2 with a positive fuel fraction remaining after triple(!) jumping ... but COULD do so by standardizing on a 24 ton Box form factor instead ... that brought up a somewhat obvious question.

If the 24 ton Box "has to be the standard" used by a "family of starship classes" intended to mobilize that particular form factor ... what modifications (if any) would be needed in order to outfit the ...

1. 100 ton J2/2G @ TL=9 Scout/Courier
2. 280 ton J2/2G @ TL=9 Long Trader
3. 410 ton J3/3G @ TL=A Clipper
4. 24 ton Box family of "unpowered" small craft hulls (which draw their Basic Power requirements from the power plants of craft they are docked with)
5. 24 ton 6G @ TL=9-A Fighters (used as mobile screening escorts for the merchant starships) and what backstory/history did they have in system defense operational roles before being adapted for use as Fighter Escorts

So I've redesigned the Scout/Courier with the 24 ton Box form factor, and here's how that turned out.

---

Rule of Man Scout/Courier (Type-SP, TL=9)
100 tons starship standard hull, atmospheric streamlining (configuration: 2) (MCr3) (LBB2.81, p15, p22)
0 tons for Armor: 0 (TL=9, Composite Laminates, bulkhead thickness=20cm)
15 tons for LBB2.81 standard A/A/A drives (codes: 2/2/2, TL=9, EP=2, Scout) (MCr22) (LBB2.81, p22)
22 tons of total fuel: 100 tons @ J2 = 20 tons jump fuel + 20 tons power plant fuel
20 tons for bridge (200 ton rating, MCr1)
2 tons for model/2 computer (CPU: 3, Storage: 6, EP=0, TL=7) (MCr9)

• Standard software package (MCr2 budget for programs) (LBB2.81, p41)
  • Maneuver (Space=1, MCr0.1)
  • Jump-1 (Space=1, MCr0.1)
  • Jump-2 (Space=2, MCr0.3)
  • Navigation (Space=1, MCr0.4)
  • Generate (Space=1, MCr0.8)
  • Library (Space=1, MCr0.3)
    • 1+1+2+1+1+1 = 7 Spaces
    • 0.1+0.1+0.3+0.4+0.8+0.3 = MCr2

1 ton for hardpoint+dual turret: no weapons installed (MCr0.6) (LBB2.81, p23)
24 tons for hangar capacity (MCr0.048)

1. 24Car Box = 24 tons
   • 0.19 tons for 19 ton capacity collapsible fuel tank (MCr0.0095)
   • 5 tons ready for multi-purpose reconfiguration (air/raft berth, cargo, mail vault, etc.)

* External Docking: 100 tons capacity (MCr0.2)

1. 
   
2. 
   
3. 
   

16 tons for 4x single occupancy starship staterooms (MCr2)
0 tons for cargo hold

= 0+15+22+20+2+1+24+16+0 = 100 tons
= 3+22+1+9+0.6+0.048+0.0095+0.2+2 = MCr37.8575

= MCr37.8575+(1.728) = MCr39.5855 * 1.0 = MCr39.5855 single production
= MCr37.8575+(1.728) = MCr39.5855 * 0.8 = MCr31.6684 volume production

Crew = 1 (Cr6000 per 4 weeks crew salaries)

1. Pilot-1 = (6000*1.0) = Cr6000

Drive Performance under external loading

• J2, 2G, Agility=2: 100 + 0 = 100 combined tons
• J1, 1G, Agility=1: 100 + 100 = 200 combined tons (4x 24 ton Boxes = 96 tons)

=====

24Car Box (Type-AU, TL=9)
24 ton small craft custom hull, configuration: 4 (MCr1.44)
0 tons for Armor: 0 (TL=9, Composite Laminates, bulkhead thickness=20cm)
* External Docking: 6x 24 = 144 tons capacity (MCr0.288)
24 tons for cargo hold

= 0+24+0 = 24 tons
= 1.44+0.288 = MCr1.728

7.5m x 7.5m x 6m = 337.5m³ / 14 = 24.10714286 tons ≈ 24 tons (5:5:4 dimensions ratio)
5 x 5 deck squares area, 2 decks

---

So ... why no weaponry installed at construction, and why retain the dual turret rather than upgrading to a triple turret?

Because from a LBB5.80 combat system perspective, dual beam lasers are actually the "best bang for the credit" option. Twin beam lasers require 2 EP (the standard Power Plant-A only generates 2 EP), produces the best weapon code factor (2) @ TL=9 in a single battery, at the lowest aftermarket cost (MCr2 for the twin beam lasers plus MCr1 for the Target computer program under LBB2 computer programming rules). This would mean a total of 7+1 program spaces in the computer, leaving 1 program space left over (3 CPU+6 Storage = 9 spaces) for an additional offensive or defensive computer program before needing to load/unload computer programs from the library into the computer (at the end of "your phases" during LBB2 combat). So an aftermarket MCr3+ investment to outfit the (empty) dual turret (using LBB2 considerations).

Achieve the same thing with a triple turret missile launcher (code: 2, battery: 1 @ TL=9) would require an additional MCr0.5 in construction cost for the dual to triple turret upgrade (LBB2.81, p23), MCr2.25 for the 3x missile launchers, MCr1 for the Target computer program plus an additional MCr2 for the Launch computer program for minimum functionality in a maximal armament configuration. That's an aftermarket MCr5.75 investment to outfit an (empty) triple turret (using LBB2 considerations) ... and still doesn't include the costs of actually buying the missiles themselves! A triple turret could load 3x3 + 12 = 21 missiles total capacity (LBB2.81, p32), which at MCr0.005 per HE missile (default baseline) would cost an additional MCr0.105 for 21 missiles. Total cost increase over the dual turret baseline ... MCr5.855 ... almost TWICE the expense of the dual beam lasers option, with 9 spaces of computer programs to be kept on file.

Although additional combat computer programs COULD be purchased and kept in the ship's software library (unload the jump, navigation and generate programs while maneuvering in normal space to free up room for combat programs), acquisition of those computer programs will cost additional (mega)credits on top of the baseline "stock" build configuration (if bothering with LBB2 computer programming rules at all).

So although the triple turret option FEELS better/more powerful from a min-max gaming perspective, from a thrifty/economical allocation of resources perspective, the dual turret option is both less ambitious and more economical to deploy.

A dual beam lasers turret option costs MCr33.2632 (after volume discount) and adds MCr1 for the Target program to the final cost of MCr34.2684 for the complete package (if built that way from initial construction).

A triple missile launchers turret option costs MCr33.8632 (after volume discount) and adds MCr3.105 for the Target and Launch programs plus the initial loadout of 21x HE missiles for the (now) triple turret. The final cost (if built that was from initial construction) would be MCr36.9734 for the complete package.

36.9734 / 34.2684 = 107.89356959%

That means that a service could buy 14 dual turret armed Scout/Couriers for the price of 13 triple turret armed Scout/Couriers (using these specific parameters as a benchmark for comparisons). Across runs of hundreds/thousands/tens of thousands of hulls produced (or even more!) ... that kind of cost savings by installing a dual turret rather than a triple turret is going to ADD UP into extra hulls (and thus, crews) available for mission tasking for approximately the same amount of budget outlays. When you get into truly MASS PRODUCTION levels of construction of hulls ... that simple little bit of economizing on the turret WILL add up ...



Of course, for X-mail Courier duty, offensive weaponry and a Gunner on the crew roster are required ... but those can be "simple kit upgrade packages" added onto the (above) basic "stock" class design. Put weapons in the turret (mix can vary, depending on region of operations), add a Gunner to the crew, outfit the 5 tons remaining in the Box cargo hold as a Mail Vault ... and you're ready to go on Courier duties. I'm thinking that twin beam lasers would be a "very common option" for this sort of thing, due to the "economizing factor" that lasers will have in operational expense accounts (don't need to restock them with ordnance that requires a logistics tail, for example).

For exploration and survey mission tasking, a "simple kit upgrade package" for a 4 ton air/raft plus 1 ton of life support consumables reserves to support extended duration assignments to the field and be installed into the 5 tons remaining in the Box cargo hold ... and you're ready to go. With 1 ton of life support consumables reserves (MCr0.15, 1 ton, 150 person/weeks supplies) a Scout starship with a 4 person crew (1-2 for the starship itself, depending on armament options, 2-3 specialists for field work) can spend the majority of a year (40-41.5 weeks straight) in the field for longitudinal studies before needing to return to base for life support resupply and crew debriefing/rotation.

For the surplus aftermarket conversions, such as into Type-J Seeker equivalents, there are going to be a variety of alternatives available for armament and outfitting to enable use as belters/prospectors ... just like with the Type-S Scout/Courier of LBB2 fame.

 

[coliver988]

from the nomenclature part of the discussion: BITS 1001 Cargos has a very long cargo profile. https://wiki.travellerrpg.com/101_Cargos

 

[kilemall]

I have a taxonomy for containers, mostly to define what unique cargo they can carry and their costs.

 

[Spinward Flow]

from the nomenclature part of the discussion: BITS 1001 Cargos has a very long cargo profile. https://wiki.travellerrpg.com/101_Cargos

For those who have access to JTAS issues, the article for this one appears in JTAS #26, originally printed in Challenge Magazine.

Side note, I first looked in JTAS #25 (due to the citation in the Travellerwiki article linked above, which turned out to be an Off By One error) ... and found an article on Q ships! This article included the VERY USEFUL rule for pop turrets (that I've been looking for in CT since FOREVER!).

JTAS #25:

The pop turrets installed on Q ships do not move except to retract and extend, and they include special stabilizing gear (tonnage equal to turret tonnage, MCr 0.1 per ton). Thus, these pop turrets do not suffer any penalties when fired.

So basically, x2 tonnage for the turret and add MCr0.1 to convert an "ordinary" turret into a "pop" turret (surprise! ).
My 24 ton Fighter design @ TL=9 has 1 ton "leftover" that I allocated as cargo space ... but with this pop turret rule in hand, I could convert the existing turret installation from an "ordinary" turret into a "pop" turret and make the 24 ton Fighter have concealed weaponry.