Pondering starship evolution

[Badenov]

To be fair, ground vehicle powered by ICE with transmission and wheels used for towing is a VERY DIFFERENT CONTEXT from mating two craft together in orbit by docking and then applying F=MA thrust to the combination on a specific vector.

The ground vehicle is "limited" by all kinds of engineering constraints (RPM, torque, transmission losses, power to load matching at speeds, contact patch friction limits on wheels, etc. etc. etc.) that simply do not apply when in orbit in space (with no friction worth mentioning and effectively in free fall). In space, it's all about F=MA thrust vectored through the center of mass (miss the center of mass with your vector and you start spinning).

In space, the F=MA reality is that if you 1/2x of the Mass (or in the CT context, combined displacement) you 2x the Acceleration from the exact same amount of Force.

Except that the equation is really 'A'. It just happens based on the engine relative to the volume being pushed. M is never really involved, so F is problematic to calculate.

This is why A/A/A drives are codes: 2/2/2 in a 100 ton hull (see: Type-S Scout/Courier) and the exact same type of A/A/A drives are codes: 1/1/1 in a 200 ton hull (see: Free Trader).
2x the mass (or displacement) = 1/2x the acceleration

Well, that's a COMBAT consideration, as opposed to being an economic/merchant type of reason.

Agreed.

The SHIP will.
However, if you're doing a modularized container system (like I am) you're "still paying for" the hull metal somehow.

Falling back on the napkin math I was using before:

• A 2000 ton craft pays MCr200 for its hull (before configuration modifiers)
• A 12,000 ton craft pays MCr1200 for its hull (before configuration modifiers)

So the hull construction cost for the tug itself is lower.

I concur. that it makes sense that it's possible, but it seems like a scam to me because the established, proper way is to have the carrying hull enclose everything, as Lurenti does even with the riders outside. The riders also pay for their own hull, so there's no synergy. Anything that involves not paying for that full hull cost for the total volume being jumped seems like trying to pull a fast one on the system. But I am OK with that method if there's some other tradeoff, like chance of misjump. That said, your campaign, your rules.

I view the 110% for Big Craft requirement as being "always operative" regardless of tender configuration.

Sorry for being slow on that bit.

So a 12,000 ton configuration: 7 tender can allocate 9900 tons for facilities to dock 9x 1000 ton Big Craft which can all be launched and recovered in a single combat turn (because, configuration: 7). If a tender wanted to accommodate a 10,000 ton Battle Rider, the tender would need to devote 10,000*1.1=11,000 tons to the docking facilities necessary for that purpose, regardless of tender hull configuration (and whether those facilities were accounted for as being "internal or external" to the hull with regards to berthing/towing). It's just that a configuration: 7 tender can "launch and recover EVERYTHING" in a single combat turn, unlike all other hull configurations which have launch and recovery constraints/limitations.

Concur here.

Somebody still has to pay for the hulls of the external loads.
The tug/tender might be cheaper, but the barges still need to be paid for (by someone) in order to exist.

Which is why I've gone to such pains as to define the modularized container form factor in my research in this thread ... and settled on the 16 ton form factor as the "best biggest small that is also the smallest big" (if that makes any sense) building block unit for interstellar trade because of how multi-purpose the form factor winds up being. Under CT, the 16 ton form factor "works wonders" up until you reach the point where your combined overall tonnage exceeds 1000 tons (starship+external loading), at which point a different solution becomes preferable/more economical. At over 1000 tons, the market incentives switch back towards "internal cargo" accounting due to a variety of "efficiency" factors.

This is the part where I got lost. I wil press the 'I believe' button so we can move forward.

But for the ACS "small time free trader/speculator" market, external loading and containerized shipping makes for an extremely compelling business model for what amount to "mom & pop" type independent operators working the "lower end" of the interstellar trade economy. It makes it possible to design "flexible" starships that can survive and thrive in a variety of world market conditions that would be difficult for a more "one size fits all" type of starship to profit from quite so reliably.

In other words, there's a niche/boutique market for these kinds of ACS designs that I'm coming up with.

Cool! Sounds like you have things worked out.

The closest we've got to that IMTU are cargo modules that are delivered in 30 dT lots by the supposedly ubiquitous Modular Cutter. Most of the cargo haulers IMTU carry the 30dT containers as it's a convenient and fast way to load and unload a ship. The military has attempted to use this configuration-by-modules method to make generic ACS-sized ships thet can do various roles based on the module loadout in kind of the same way that was planned for the newer US Navy ships, with modules for weapons, sensors, marines, and so on.

 

[Spinward Flow]

I concur. that it makes sense that it's possible, but it seems like a scam to me because the established, proper way is to have the carrying hull enclose everything, as Lurenti does even with the riders outside. The riders also pay for their own hull, so there's no synergy. Anything that involves not paying for that full hull cost for the total volume being jumped seems like trying to pull a fast one on the system.

Hence why I'm working so diligently to nail down all the corner cases.

The way that everything "works" to balance the books is that small ship+external load requires "overpowered" drives for the application in order to make things work. This places an upper limit on a matrix of drive performance @ various external loading breakpoints.

If you want to have high drive performance with large loads, those loads need to be internal in order to get (and maintain) the high drive performance.

Conversely, if low drive performance with large loads is "acceptable" as a mission parameter, then you can do EITHER:

• Small ship with high drive performance, which translates into small ship with low drive performance when encumbered by large external loads.
• Large ship with low drive performance, which will have low drive performance whether the ship is full or empty.

Either approach will work, but the small ship with a large external load potential is more "flexible" and can undertake a wider variety of mission roles simply by increasing/decreasing the amount of external load the ship is docked with and towing (with "none" yielding maximal drive performance).

For military applications, such as fighter carriers and tenders for battle riders ... naval architect spreadsheet "internal" berthing (even for configuration: 7 tenders) will often times make the most sense due to the minimum drive performances required (such as J4 and 5-6G in order to keep pace with fleet movements).

Conversely, for commercial merchant applications ... naval architect "external" docking & towing can make the most sense in some applications where J1/1G are "acceptable" drive performance levels.

Or to phrase it differently ... there's more than one way to scramble an omelette.



As for the "feels like a scam" part of it, that's because there's more moving pieces than JUST the tug/tender involved, so a more holistic understanding requires having all of the parts and pieces to make a more informed judgement with regards to the merits.

For example, I can build a 100 ton Scout/Courier design with a 32 ton hangar bay in it for 2x 16 ton Box modules (1 with 4 staterooms, 1 which is a cargo bay, possibly with an air/raft berth in it). Because of the "extra 32 tons of hull metal" the modular design is more expensive to construct, but it's also more flexible, and from the outset would be intended to make external towing of up to 6x 16 ton Box modules (+96 combined tons) an option. So slightly higher price to outfit a starship, but vastly improved mission role flexibility in return ... so to my mind, the exchange would be worth it. The Box modules can be transported for deployment as outposts for long term habitation and "research" of whatever is of interest, while the starship is just a "mobilizer" to get the 16 ton Boxes moved around to where they need to go. More modular means more mission roles and a wider range of mission tasking.

And although you could do much the same thing with the "stock" Type-S Scout/Courier, you would kind of need to refit each ship for each mission ... while with the modular variant you just hot swap in the modules that you need and off you go (no fuss, no muss). Better to have 1 modular ship with multiple modules available for use than needing 2 ships for 1 mission ... but that starts getting into mission logistics planning and admin territory. However, hopefully I've been able to make my case for how the flexibility option might cost more up front, but SAVE money (and resources) in the long run.

The closest we've got to that IMTU are cargo modules that are delivered in 30 dT lots by the supposedly ubiquitous Modular Cutter.

I actually started with the idea of using the 30 ton Modular Cutter Module as a foundational building block for a containerized shipping solution. However, as soon as I started thinking about it in terms of deck plans (and the drawing thereof) it all rapidly fell apart.

The first problem was that 30 tons does not integer divide by 4 (stateroom tons) nicely.
28 or 32 divide by 4 just fine into 7 or 8 ... but 30/4=7.5 so there were "2 tons at loose ends" when loading up the 30 ton module with (starship) staterooms.
And what if you don't NEED 7-8 staterooms because your crew is 5 or less?

The second problem with the 30 ton Modular Cutter Module is that they're cylinder shaped.
This means that any kind of "packing efficiency" is going to be mediocre because of the wasted space between the cylinders when you've got a lot of them. When volumetric space is at a PREMIUM (as it is in most ACS deck plans, when done faithfully), this can become a cascading problem. 1-3 Modular Cutter Modules isn't bad but when you start thinking in terms of 10-20+ of them, especially if you need to "daisy chain" them together (end to end) in addition to stacking them (in a hexagonal arrangement to minimize packing losses) the whole thing turns into an exercise of "I Say GOOD DAY To You SIR!" when it comes time to draw the deck plans. The naval architect's spreadsheet won't care, but the draftsman who has to draw the blueprints will. And you can forget about trying to make starship stateroom floor plans "make sense" inside the cylindrical confines of the Modular Cutter Modules.

The third problem was the 50 ton Modular Cutter itself.
As purely a transport (only) small craft, it is quite adequate for the job ... but as soon as you ask one to be a combatant, let's just say that your undergarments had better be enriched with iron. Modular Cutters are "optionally armed" meaning that they have a bridge but no computer by default ... and they have NO ARMOR. This means that from a hunter vs prey perspective, Modular Cutters are just 4G eggshells ... since any combat hits they take are likely to cripple a Modular Cutter (and in LBB5.80 combat, that means automatic critical hits). Against even "modest" computers on enemy craft, Modular Cutters (with no computer) are little more than sitting ducks, begging to be pot shot at. Even if you install a computer and arm a Modular Cutter, with only 4G and Agility=4 at best, the risks of taking battle damage in combat are still unacceptably high for crews (and whatever they're transporting).

This realization pushed me into the direction of a dedicated (light) Fighter design, armed with a computer, max agility (6) and "decent" weaponry to deter "wannabe pirates" from emoting too much interest. The "no get hitsu" protection of small craft hull size (-2DM) and high agility (-6DM) bolstered by a "modest" computer (model/2-3 @ TL=9) made for a compelling package as a "mobile turret" which could be used to screen a more vulnerable parent craft, limiting the exposure to hostile fire to the Fighter alone (which would be best equipped to evade hostile fire in an exchange).

Eventually, I was able to figure out the design for a 16 ton (light) Escort Fighter ... which just so happened to be the same displacement as the 16 ton Boxes that I was using for my modularized container transport business model ... and yet another puzzle piece settled into place.

At TL=11, the Fighter can be "upgraded" into a 32 ton (medium) Fighter type that would be better used for system defense and police patrol support roles, while still being something of a cutting edge combatant (with a bridge, agility 6 and a model/5 computer!). Beyond TL=11, the computers start getting too big/power hungry/expensive to remain practical, so I would expect the heyday of fighter craft designed in the style that I'm doing them would peak at TL=11 before starting to decline towards obsolescence.



But yeah, using 50 ton Modular Cutters as fighter craft is a pretty decent way to get them in combat against pirates (and/or system defense). As an improvised combatant, they can be pressed into service ... but against a professional (para)military adversary, don't expect them to get away unscathed, which for a capital investment on the order of one of these small craft is NOT a good risk for them to be taking. You REALLY want a dedicated fighter small craft if you want something reusable/survivable in a combat mission role.

 

[Badenov]

Hence why I'm working so diligently to nail down all the corner cases.

The way that everything "works" to balance the books is that small ship+external load requires "overpowered" drives for the application in order to make things work. This places an upper limit on a matrix of drive performance @ various external loading breakpoints.

If you want to have high drive performance with large loads, those loads need to be internal in order to get (and maintain) the high drive performance.

Conversely, if low drive performance with large loads is "acceptable" as a mission parameter, then you can do EITHER:

• Small ship with high drive performance, which translates into small ship with low drive performance when encumbered by large external loads.
• Large ship with low drive performance, which will have low drive performance whether the ship is full or empty.

Either approach will work, but the small ship with a large external load potential is more "flexible" and can undertake a wider variety of mission roles simply by increasing/decreasing the amount of external load the ship is docked with and towing (with "none" yielding maximal drive performance).

For military applications, such as fighter carriers and tenders for battle riders ... naval architect spreadsheet "internal" berthing (even for configuration: 7 tenders) will often times make the most sense due to the minimum drive performances required (such as J4 and 5-6G in order to keep pace with fleet movements).

Conversely, for commercial merchant applications ... naval architect "external" docking & towing can make the most sense in some applications where J1/1G are "acceptable" drive performance levels.

Or to phrase it differently ... there's more than one way to scramble an omelette.



As for the "feels like a scam" part of it, that's because there's more moving pieces than JUST the tug/tender involved, so a more holistic understanding requires having all of the parts and pieces to make a more informed judgement with regards to the merits.

For example, I can build a 100 ton Scout/Courier design with a 32 ton hangar bay in it for 2x 16 ton Box modules (1 with 4 staterooms, 1 which is a cargo bay, possibly with an air/raft berth in it). Because of the "extra 32 tons of hull metal" the modular design is more expensive to construct, but it's also more flexible, and from the outset would be intended to make external towing of up to 6x 16 ton Box modules (+96 combined tons) an option. So slightly higher price to outfit a starship, but vastly improved mission role flexibility in return ... so to my mind, the exchange would be worth it. The Box modules can be transported for deployment as outposts for long term habitation and "research" of whatever is of interest, while the starship is just a "mobilizer" to get the 16 ton Boxes moved around to where they need to go. More modular means more mission roles and a wider range of mission tasking.

And although you could do much the same thing with the "stock" Type-S Scout/Courier, you would kind of need to refit each ship for each mission ... while with the modular variant you just hot swap in the modules that you need and off you go (no fuss, no muss). Better to have 1 modular ship with multiple modules available for use than needing 2 ships for 1 mission ... but that starts getting into mission logistics planning and admin territory. However, hopefully I've been able to make my case for how the flexibility option might cost more up front, but SAVE money (and resources) in the long run.

I actually started with the idea of using the 30 ton Modular Cutter Module as a foundational building block for a containerized shipping solution. However, as soon as I started thinking about it in terms of deck plans (and the drawing thereof) it all rapidly fell apart.

The first problem was that 30 tons does not integer divide by 4 (stateroom tons) nicely.
28 or 32 divide by 4 just fine into 7 or 8 ... but 30/4=7.5 so there were "2 tons at loose ends" when loading up the 30 ton module with (starship) staterooms.
And what if you don't NEED 7-8 staterooms because your crew is 5 or less?

The second problem with the 30 ton Modular Cutter Module is that they're cylinder shaped.
This means that any kind of "packing efficiency" is going to be mediocre because of the wasted space between the cylinders when you've got a lot of them. When volumetric space is at a PREMIUM (as it is in most ACS deck plans, when done faithfully), this can become a cascading problem. 1-3 Modular Cutter Modules isn't bad but when you start thinking in terms of 10-20+ of them, especially if you need to "daisy chain" them together (end to end) in addition to stacking them (in a hexagonal arrangement to minimize packing losses) the whole thing turns into an exercise of "I Say GOOD DAY To You SIR!" when it comes time to draw the deck plans. The naval architect's spreadsheet won't care, but the draftsman who has to draw the blueprints will. And you can forget about trying to make starship stateroom floor plans "make sense" inside the cylindrical confines of the Modular Cutter Modules.

The third problem was the 50 ton Modular Cutter itself.
As purely a transport (only) small craft, it is quite adequate for the job ... but as soon as you ask one to be a combatant, let's just say that your undergarments had better be enriched with iron. Modular Cutters are "optionally armed" meaning that they have a bridge but no computer by default ... and they have NO ARMOR. This means that from a hunter vs prey perspective, Modular Cutters are just 4G eggshells ... since any combat hits they take are likely to cripple a Modular Cutter (and in LBB5.80 combat, that means automatic critical hits). Against even "modest" computers on enemy craft, Modular Cutters (with no computer) are little more than sitting ducks, begging to be pot shot at. Even if you install a computer and arm a Modular Cutter, with only 4G and Agility=4 at best, the risks of taking battle damage in combat are still unacceptably high for crews (and whatever they're transporting).

This realization pushed me into the direction of a dedicated (light) Fighter design, armed with a computer, max agility (6) and "decent" weaponry to deter "wannabe pirates" from emoting too much interest. The "no get hitsu" protection of small craft hull size (-2DM) and high agility (-6DM) bolstered by a "modest" computer (model/2-3 @ TL=9) made for a compelling package as a "mobile turret" which could be used to screen a more vulnerable parent craft, limiting the exposure to hostile fire to the Fighter alone (which would be best equipped to evade hostile fire in an exchange).

Eventually, I was able to figure out the design for a 16 ton (light) Escort Fighter ... which just so happened to be the same displacement as the 16 ton Boxes that I was using for my modularized container transport business model ... and yet another puzzle piece settled into place.

At TL=11, the Fighter can be "upgraded" into a 32 ton (medium) Fighter type that would be better used for system defense and police patrol support roles, while still being something of a cutting edge combatant (with a bridge, agility 6 and a model/5 computer!). Beyond TL=11, the computers start getting too big/power hungry/expensive to remain practical, so I would expect the heyday of fighter craft designed in the style that I'm doing them would peak at TL=11 before starting to decline towards obsolescence.



But yeah, using 50 ton Modular Cutters as fighter craft is a pretty decent way to get them in combat against pirates (and/or system defense). As an improvised combatant, they can be pressed into service ... but against a professional (para)military adversary, don't expect them to get away unscathed, which for a capital investment on the order of one of these small craft is NOT a good risk for them to be taking. You REALLY want a dedicated fighter small craft if you want something reusable/survivable in a combat mission role.

Totally concur about Mod cutters not having any chance in a fight against a cub scout with a slingshot. It was done entirely based on the allegedly extant infrastructure of 30-ton utility modules and cargo offload requirements.

Actual warships with the capability to mount a combat-worthy computers could mount hardpoints and gunners' staterooms in various propotions, so there were no 'just stateroom' modules, (except for the 6x first class plus three steward module, with 6 4T staterooms and 3 2T staterooms, with 1 steward per 2 passengers, which is how MgT1 required it. I'm not sure about CTs requirements for Stewards and passengers).

Other common configs were: Lab space - 5x 4T labs and 5x 2T cabins; Fighter Hangars 20T Hangar requires 26T+2x2T Staterooms; various planetary exploration configurations like 3 Air/Rafts (12T)+9 Crew (18T) and 1 Air/Raft (4T)+2 ATV (20T)+3 Staterooms (6T); a Sickbay - 1 stateroom (2T) for the medic/autodoc operator, 1 Lab (4T) configured as an operating room including a TL14 autodoc, 4 recovery rooms (16T, as 1st Class space is needed to recover), and 8T of low berths for those that can't be helped by the limited facilities aboard.

 

[Spinward Flow]

I'm not sure about CTs requirements for Stewards and passengers

1 Steward (skill-0) required per 8 high passengers (round fractions up).

 

[Spinward Flow]

Just realized that the notion of a 16 ton Light Fighter with (LBB2.81 standard) Drives-A/A installed has a fundamental flaw in it.
Links: 1 & 2

Which means that it's back to the drawing board at the naval architect's office for me on this topic.



The alternatives are to design a Fighter Escort small craft that has a 29-33 ton displacement, so that (LBB2.81 standard) Drives-A/A can be installed rated code: 6/6 (2 EP) ... OR ... switch to LBB5.80 drives in a 28- ton form factor.

The advantage of the standard drives (maneuver+power plant) is that they're SMALL (1+4=5 tons) and they're CHEAP (4+8=MCr12) for their performance in a 29-33 ton form factor.

The downside is that there's no usable EP "surplus" (it's all spent on Agility), so the maximum computer that can be installed is a model/2 (0 EP) and there are no EPs to spare for a laser ... meaning the only weapons that can be installed are missiles and sandcasters (and sandcasters with a model/2 aren't all that practical as a defensive measure against near peer threats).

By contrast, a 30 ton small craft with LBB5.80 drives @ TL=9-12 are going to be LARGE (5.1+5.4=10.5 tons, minimum) and EXPENSIVE (2.55+16.2=MCr18.75, minimum). For each extra +1 EP to power higher computer model # and/or add laser weapons into the mix, add +3 tons and +MCr9 to the tally.

A 20 ton small craft with LBB5.80 drives @ TL=9-12 are still going to be LARGE (3.4+3.6=7 tons, minimum) and EXPENSIVE (1.7+10.8=MCr12.5, minimum). For each extra +1 EP to power higher computer model # and/or add laser weapons into the mix, add +3 tons and +MCr9 to the tally ... but at least you can build something smaller than 29 tons that is capable of Agility=6. Still, EPs are EXPENSIVE to generate @ TL=9-12!



This then has knock on consequences for the standardization of modularized cargo containers (and all the variants that come with that: stateroom, laboratory, environment tank, etc.) if the Escort Fighter CAN'T BE a mere 16 tons (using Drives-A/A).

Ideally speaking the modularized containers form factor ought to be in multiples of 4 (because of starship stateroom tonnage requirements).

• 20 ton form factor = 5x staterooms per Box
• 24 ton form factor = 6x staterooms per Box
• 28 ton form factor = 7x staterooms per Box
• 32 ton form factor = 8x staterooms per Box

However, if I'm going to be "refactoring" the Box form factor away from 16 tons (to something larger) ... are there "sweet spots" in the multiples of 4 to angle towards?
There might be ...

• 24 ton form factor = 4x staterooms (16 tons) + Environmental Control Type V-c capacity: up to 4 persons (aquaculture, hydroponic wall gardens and carniculture) (8 tons)
  • 24*14 = 336m³
  • 7.5m x 7.5m x 6m = 337.5m³ = 5 deck squares x 5 deck squares x 2 decks high box form factor
  • 15m x 7.5m x 3m = 337.5m³ = 10 deck squares x 5 deck squares x 1 deck high box form factor
• 24 ton form factor = 3x staterooms (12 tons) + Environmental Control Type V-d capacity: up to 3 persons (aquaculture, hydroponic wall gardens and carniculture) (12 tons)
• 30 ton form factor = 5x staterooms (20 tons) + Environmental Control Type V-c capacity: up to 5 persons (aquaculture, hydroponic wall gardens and carniculture) (10 tons)
  • 30*14 = 420m³
  • 9.3m x 7.5m x 6m = 418.5m³ = 6.2 deck squares x 5 deck squares x 2 decks high box form
  • 19.2m x 7.5m x 3m = 418.5m³ = 12.4 deck squares x 5 deck squares x 1 deck high box form

The 24 ton form factor is more flexible with regards to fittings (staterooms, laboratory, etc.), but then requires a Fighter Escort to use a 24 ton form factor to occupy an interchangeable hangar berth, which in turn requires LBB5.80 custom drives (increasing the overall cost).

The 30 ton form factor isn't quite as flexible with regards to stateroom accommodations, but does work out better for major/minor cargo lots (that come in multiples of 10 tons and 5 tons respectively) ... and the Fighter Escort will (probably) be cheaper to construct (and maintain and bank finance, if necessary).



This is going to require some Analysis of Alternatives to properly weigh the pros vs cons of each approach.

 

[Grav_Moped]

Just realized that the notion of a 16 ton Light Fighter with (LBB2.81 standard) Drives-A/A installed has a fundamental flaw in it.
Links: 1 & 2

Which means that it's back to the drawing board at the naval architect's office for me on this topic.



The alternatives are to design a Fighter Escort small craft that has a 29-33 ton displacement, so that (LBB2.81 standard) Drives-A/A can be installed rated code: 6/6 (2 EP) ... OR ... switch to LBB5.80 drives in a 28- ton form factor.

The advantage of the standard drives (maneuver+power plant) is that they're SMALL (1+4=5 tons) and they're CHEAP (4+8=MCr12) for their performance in a 29-33 ton form factor.

The downside is that there's no usable EP "surplus" (it's all spent on Agility), so the maximum computer that can be installed is a model/2 (0 EP) and there are no EPs to spare for a laser ... meaning the only weapons that can be installed are missiles and sandcasters (and sandcasters with a model/2 aren't all that practical as a defensive measure against near peer threats).

By contrast, a 30 ton small craft with LBB5.80 drives @ TL=9-12 are going to be LARGE (5.1+5.4=10.5 tons, minimum) and EXPENSIVE (2.55+16.2=MCr18.75, minimum). For each extra +1 EP to power higher computer model # and/or add laser weapons into the mix, add +3 tons and +MCr9 to the tally.

A 20 ton small craft with LBB5.80 drives @ TL=9-12 are still going to be LARGE (3.4+3.6=7 tons, minimum) and EXPENSIVE (1.7+10.8=MCr12.5, minimum). For each extra +1 EP to power higher computer model # and/or add laser weapons into the mix, add +3 tons and +MCr9 to the tally ... but at least you can build something smaller than 29 tons that is capable of Agility=6. Still, EPs are EXPENSIVE to generate @ TL=9-12!



This then has knock on consequences for the standardization of modularized cargo containers (and all the variants that come with that: stateroom, laboratory, environment tank, etc.) if the Escort Fighter CAN'T BE a mere 16 tons (using Drives-A/A).

Ideally speaking the modularized containers form factor ought to be in multiples of 4 (because of starship stateroom tonnage requirements).

• 20 ton form factor = 5x staterooms per Box
• 24 ton form factor = 6x staterooms per Box
• 28 ton form factor = 7x staterooms per Box
• 32 ton form factor = 8x staterooms per Box

However, if I'm going to be "refactoring" the Box form factor away from 16 tons (to something larger) ... are there "sweet spots" in the multiples of 4 to angle towards?
There might be ...

• 24 ton form factor = 4x staterooms (16 tons) + Environmental Control Type V-c capacity: up to 4 persons (aquaculture, hydroponic wall gardens and carniculture) (8 tons)
  • 24*14 = 336m³
  • 7.5m x 7.5m x 6m = 337.5m³ = 5 deck squares x 5 deck squares x 2 decks high box form factor
  • 15m x 7.5m x 3m = 337.5m³ = 10 deck squares x 5 deck squares x 1 deck high box form factor
• 24 ton form factor = 3x staterooms (12 tons) + Environmental Control Type V-d capacity: up to 3 persons (aquaculture, hydroponic wall gardens and carniculture) (12 tons)
• 30 ton form factor = 5x staterooms (20 tons) + Environmental Control Type V-c capacity: up to 5 persons (aquaculture, hydroponic wall gardens and carniculture) (10 tons)
  • 30*14 = 420m³
  • 9.3m x 7.5m x 6m = 418.5m³ = 6.2 deck squares x 5 deck squares x 2 decks high box form
  • 19.2m x 7.5m x 3m = 418.5m³ = 12.4 deck squares x 5 deck squares x 1 deck high box form

The 24 ton form factor is more flexible with regards to fittings (staterooms, laboratory, etc.), but then requires a Fighter Escort to use a 24 ton form factor to occupy an interchangeable hangar berth, which in turn requires LBB5.80 custom drives (increasing the overall cost).

The 30 ton form factor isn't quite as flexible with regards to stateroom accommodations, but does work out better for major/minor cargo lots (that come in multiples of 10 tons and 5 tons respectively) ... and the Fighter Escort will (probably) be cheaper to construct (and maintain and bank finance, if necessary).

I

This is going to require some Analysis of Alternatives to properly weigh the pros vs cons of each approach.

Why assume a dash result instead of a repeat result of 6 in the next column?

 

[Spinward Flow]

Why assume a dash result instead of a repeat result of 6 in the next column?

• 200 / 200 = code: 1 @ 200 tons
• 200 / 100 = code: 2 @ 100 tons
• 200 / 66 = code: 3 @ 66 tons
• 200 / 50 = code: 4 @ 50 tons
• 200 / 40 = code: 5 @ 40 tons
• 200 / 33 = code: 6 @ 33 tons
• 200 / 28 = code: 7 @ 28 tons
• 200 / 25 = code: 8 @ 25 tons
• 200 / 22 = code: 9 @ 22 tons
• 200 / 20 = code: 10 @ 20 tons
• 200 / 18 = code: 11 @ 18 tons
• 200 / 16 = code: 12 @ 16 tons
• 200 / 15 = code: 13 @ 15 tons

Precedent used with LBB2.81 drives CLEARLY SHOWS that codes: 7+ (bold text in the above listing) are NOT ALLOWED when using standard drives.

Intellectual Honesty ... not to mention internal consistency to home brewed rules extensions to account for intermediate tonnages not explicitly spelled out on the table ... DEMANDS the revision in thinking and understanding (as outlined above).

 

[Grav_Moped]

Yeah, 12 is a bit high, and a dash is appropriate there.

 

[kilemall]

• 200 / 200 = code: 1 @ 200 tons
• 200 / 100 = code: 2 @ 100 tons
• 200 / 66 = code: 3 @ 66 tons
• 200 / 50 = code: 4 @ 50 tons
• 200 / 40 = code: 5 @ 40 tons
• 200 / 33 = code: 6 @ 33 tons
• 200 / 28 = code: 7 @ 28 tons
• 200 / 25 = code: 8 @ 25 tons
• 200 / 22 = code: 9 @ 22 tons
• 200 / 20 = code: 10 @ 20 tons
• 200 / 18 = code: 11 @ 18 tons
• 200 / 16 = code: 12 @ 16 tons
• 200 / 15 = code: 13 @ 15 tons

Precedent used with LBB2.81 drives CLEARLY SHOWS that codes: 7+ (bold text in the above listing) are NOT ALLOWED when using standard drives.

Intellectual Honesty ... not to mention internal consistency to home brewed rules extensions to account for intermediate tonnages not explicitly spelled out on the table ... DEMANDS the revision in thinking and understanding (as outlined above).

Why not max speed and extra power for weapons?

 

[Grav_Moped]

Why not max speed and extra power
for weapons?

Not the OP, but I'd guess
because LBB2 doesn't provide for ratings above 6. Mind you, that should make no difference in LBB2 designs because they don't require accounting for EPs... except that LBB2 small craft do, sort of, because they're (mostly) designed in LBB5.

 

[Spinward Flow]

Why not max speed and extra power for weapons?

This is what I was going for in the first iteration.
The maneuver code was limited to 6 instead of being 12(.5), which then meant there would be an EP surplus which could be spent on computer and/or (laser) weapons while maintaining Agility=6.

Doing that required appealing to the "round tonnage up to the next row on the table" rule from LBB2, which in turn would have meant that Drive-C would be required to achieve 6G in hull form factors from 1-100 tons ... which (obviously) wasn't a conclusion I was reaching for.

An interpolation of that rule would be that small craft can mount Maneuver-A, B or C but are limited to code: 6 output (just like a 100 ton hull), but because they're small craft ... and thus the math gets "wacky" for codes in hulls this small ... Power Plants could exceed code: 6 in order to generate excess EPs for other systems (because LBB5.80 exists and made that precedent "necessary" for combatants).

Unfortunately, that's just a matter of cherry picking what you like while ignoring what you don't like ... which results in a level of cognitive dissonance on the topic that I (personally) find to be unacceptable, because it isn't intellectually honest ... hence the "disavow" stance regarding the notion of putting LBB2.81 standard Drive-A into anything smaller than 29 tons (smallest integer tonnage that yields code: 6), which then "invalidates" the legality of a 16 ton Fighter mounting Drives-A/A (let alone Drives-A/B) as being consistent with rules precedents.

 

[kilemall]

This is what I was going for in the first iteration.
The maneuver code was limited to 6 instead of being 12(.5), which then meant there would be an EP surplus which could be spent on computer and/or (laser) weapons while maintaining Agility=6.

Doing that required appealing to the "round tonnage up to the next row on the table" rule from LBB2, which in turn would have meant that Drive-C would be required to achieve 6G in hull form factors from 1-100 tons ... which (obviously) wasn't a conclusion I was reaching for.

An interpolation of that rule would be that small craft can mount Maneuver-A, B or C but are limited to code: 6 output (just like a 100 ton hull), but because they're small craft ... and thus the math gets "wacky" for codes in hulls this small ... Power Plants could exceed code: 6 in order to generate excess EPs for other systems (because LBB5.80 exists and made that precedent "necessary" for combatants).

Unfortunately, that's just a matter of cherry picking what you like while ignoring what you don't like ... which results in a level of cognitive dissonance on the topic that I (personally) find to be unacceptable, because it isn't intellectually honest ... hence the "disavow" stance regarding the notion of putting LBB2.81 standard Drive-A into anything smaller than 29 tons (smallest integer tonnage that yields code: 6), which then "invalidates" the legality of a 16 ton Fighter mounting Drives-A/A (let alone Drives-A/B) as being consistent with rules precedents.

You’re already breaking RAW eggs, might as well go omelette. Its aesthetics at this point.

 

[Grav_Moped]

You’re already breaking RAW eggs, might as well go omelette. Its aesthetics at this point.

Yes, and no.
Yes in the rules don't ouutright say you can do this.
No, in that it's an extrapolation of performance from the portion of the drive performance table that conforms to the apparent formulas, using hardware explicitly described in other tables. The less-supportable alternative would be to attempt to extrapolate smaller-(letter) sized drives using those formulae, and that doesn't work for M-Drives.

 

[Spinward Flow]

You’re already breaking RAW eggs, might as well go omelette. Its aesthetics at this point.

I want to RESPECT the precedents that have been set, rather than bulldoze past them.
I want to extend the paradigm into new territories "in between" ... rather than throw the past paradigm in the trash and start from scratch.

 

[kilemall]

I want to RESPECT the precedents that have been set, rather than bulldoze past them.
I want to extend the paradigm into new territories "in between" ... rather than throw the past paradigm in the trash and start from scratch.

Ok it’s your show. I’m all for you presenting your stuff according to your design druthers. Someone may buy in whole hog or get inspiration. I’d stop with the extra juice point to cover the LLB2 small craft weapons before hard adherence to a fixed power curve but that’s just me.

 

[Silverhawk]

This then has knock on consequences for the standardization of modularized cargo containers (and all the variants that come with that: stateroom, laboratory, environment tank, etc.) if the Escort Fighter CAN'T BE a mere 16 tons (using Drives-A/A).

I think you are overlooking one possibility. The RW standard is a 20 foot container both for size and capacity but most containers seen now are 40 foot containers. Maybe you go with the same for the escort fighter. Allows for a 25 to 30 ton fighter without disturbing any of the other modules. Of course your losing a revenue bearing container but if the environment is such that your needing the fighter in the first place the potential losses if you didn't have it are likely greater than the revenue of one container.

just my thoughts

 

[Spinward Flow]

I think you are overlooking one possibility. The RW standard is a 20 foot container both for size and capacity but most containers seen now are 40 foot containers. Maybe you go with the same for the escort fighter. Allows for a 25 to 30 ton fighter without disturbing any of the other modules. Of course your losing a revenue bearing container but if the environment is such that your needing the fighter in the first place the potential losses if you didn't have it are likely greater than the revenue of one container.

If the only concern is the (raw, not RAW) tonnage of the escort fighter, then "any" tonnage will work just fine and then starship design system "won't complain" about it. Just make the numbers add up on the spreadsheet (and Bob's Your Uncle).

The thing is, I'm going beyond that in the realm of deck plans ... which means that form factors become important.

Yes, from a "pure spreadsheet" perspective, a 100 ton Scout/Courier and a 100 ton Express Boat are both 100 tons of displacement ... but they have different hull configurations, which means different dimensions.

• 100 ton Scout/Courier: 24m wide, 7.5m high, 37.5m long (LBB S7, p17)
• 100 ton Express Boat: 12m diameter, 22m long (LBB S7, p9)

As much as I might LIKE to equate those two form factors to each other ... common sense dictates that "one of these things is not like the other..." (or song lyrics to that effect).



The difficulty that I've got is that I'm trying to figure out how to fit a Configuration: 1 craft (the escort fighter) into the same form factor that ought to be occupied by a Configuration: 4 craft (the cargo/stateroom/etc. boxes) in order to achieve maximum interchangeability in the hangar bay space. One way to achieve that is to make the Boxes into "single deck rectangular prisms" and then just make the escort fighter fit inside of that form factor. The alternative is to NOT EVEN TRY and just decide that the escort fighter and the boxes are simply "too different" in configuration to "fit" into hangar compartments meant for the other (boxes are 2 decks in height each, escort fighter is single deck height).

When the tonnages were "small" (12-20 tons) it was almost practical to try and fit the escort fighter into the same form factor that would be used for the hangar berths of the boxes ... but as the tonnage goes up, the practicality of that solution goes down. At 24 tons, it starts becoming sensible to make the 24 ton Boxes into a 6m high "double decker" form factor, which then DOES NOT WORK for a Configuration: 1 Needle/Wedge hull escort fighter design (unless if you "fold" the escort fighter in half for stowage, which makes no sense whatsoever).



Been doing some preliminary analysis of the relative advantages of the 24 ton and 30 ton form factors ... and although the 24 ton form factor makes for "tighter designs" (aesthetically speaking), it's starting to look like the 30 ton form factor has some unexpected economic advantages to it that I wasn't expecting, which also creates some unanticipated flexibility that I didn't know I would be wanting until running through all of the possibilities.

A big one is that a "double decker" 30 ton form factor that is 6m high can be 8.25m x 8.25m square in floor area (5.5x5.5 deck squares)

• 8.25 * 8.25 * 6 = 408.375m³
• 30 * 14 = 420m³
• 408.375 / 420 = 97.232%

By making the 30 ton form factor both square at the base AND 2 decks in height, it becomes possible to rotate the axis of the access corridor on the two decks by 90º (fore/aft on the lower deck, port/starboard on the upper deck). This then makes it possible to stack the 30 ton Boxes in arrays in all 3 directions and have their airlocks on their decks link up seamlessly together ... so there's an additional benefit over making them into single decks with only a single axis corridor for access.

Another possible form factor would be the 7.5m on each side cube.

• 7.5 * 7.5 * 7.5 = 421.875m³
• 30 * 14 = 420m³
• 421.875 / 420 = 100.446%

You wind up with a "box" form factor that is 5 deck squares by 5 deck squares in floor area and 2.5 decks tall (allowing for more "services" plumbing clearance in the floors and ceilings of the habitable compartment volumes).

Actually, now that I think about it, a 7.5m cube would actually make for a somewhat (more) reasonable Cargo Box form factor as a starting point ... which all of the other variant Boxes then develop from.

 

[Grav_Moped]

Why can't the fighter be box-shaped? Most combat is in space anyhow....

 

[Condottiere]

So can missiles and torpedoes.

 

[Spinward Flow]

Why can't the fighter be box-shaped? Most combat is in space anyhow....

There's no reason why the fighter CAN'T be a box shape (or even a dispersed structure, for that matter) if the intent is pure combat.

However, for the purposes of what I'm researching here, I'm wanting a combination fighter and "external docking sky crane" VTOL lifter for the Boxes (cargo, etc.) to provide logistical support in austere locations for the loading/unloading of the starship. This means that entry into atmosphere (2+) becomes necessary, which then requires streamlining (configuration: 1, 2 or 6), even if the fighter isn't going to be transitioning from orbit through atmospheric entry with an external load (since that's the job of the starship to do orbital interface runs using internal loads). Of those choices, the "maximal" fighter option is configuration: 1 (which is only useful against meson guns, but still...). But it's still important for the fighter to be able to enter atmosphere and "be available" down near the surface as a VTOL sky crane for the marshaling of Boxes in the absence of ground support infrastructure (so as to be able to deploy outposts, make deliveries to austere locations and other "logistical services" as useful/necessary).