• Welcome to the new COTI server. We've moved the Citizens to a new server. Please let us know in the COTI Website issue forum if you find any problems.
  • We, the systems administration staff, apologize for this unexpected outage of the boards. We have resolved the root cause of the problem and there should be no further disruptions.

Pondering starship evolution

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. :cool:

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.
 
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.
 
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.
 
Back
Top