• 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.

Pondering starship evolution

The yacht/hunter shooting range got me to thinking, might be a market for your optimized ship designs in that arena.

Slimmed down yacht for fast distant travel, load up for an expedition with small craft and expeditionary vehicles on exterior boxes.
One of the main benefits of a yacht is that it is a secured mobile living space/office under your exclusive control. Security is the key here. If you have to rent modules from an outside vendor, you can never be quite sure that they haven't been bugged or otherwise tanpered with. This is especially true if you do not have access to the highest technology to security-sweep for tampering.

And if you can't trust your own ship, just take high passage and rent a luxury suite at the destination. Saves you the overhead anyhow.

If it's just picking from among your own set of modules based on mission requirements, that's different.
 
Before you mentioned the idea?
No.

Part of my reasoning is that the 16 ton form factor is decidedly sub-optimal for LBB2.81 letter drives.
Also, my own sense of starship design is that small craft/big craft need to have their engineering spaces "integrated" into the craft, rather than being something that can be "bolted on" (or into) the shell of a hull.

Closest I would get to the notion of an "engineering module" would be to start with a Cargo Box and put a fusion power plant into it (either a TL=9 PP-A drive from LBB2.81, or something smaller from Striker) along with an Internal Demountable Fuel Tank (with a Collapsible Fuel Tank optional if buying a smaller Internal Demountable Fuel Tank to make room). That way you've got a source of housekeeping/baseload power for an outpost on deployment. Gives you a way to "containerize" a power+fuel source.

But maneuver drives?
No.

Besides, if you add a power plant AND maneuver drives, you're most of the way to building a self-propelled small craft of some kind (like a Launch or a Ship's Boat) ... at which point you need either a Bridge or a Computer, and a crew.



Now if you're talking about some kind of dedicated shipping container for the interstellar transport of drive components, rather than something that can be "switched on" and be made to work in situ ... at that point the drive components are "just cargo" that needs to be delivered.
Pretty much this, in CT. Adding modular drive components is effectively changing the size of the ship's drive bay -- which is not allowed under LBB2 or HG.

Honestly, I'd allow it [edit: changing the size of the drive bay] but would set the cost and required time to make it about the same as building a new hull and swapping everything from the old ship to the new hull.

Or something like that. Almost anything is possible if you assume a large enough budget..
 
Last edited:
One of the main benefits of a yacht is that it is a secured mobile living space/office under your exclusive control. Security is the key here. If you have to rent modules from an outside vendor, you can never be quite sure that they haven't been bugged or otherwise tanpered with. This is especially true if you do not have access to the highest technology to security-sweep for tampering.

And if you can't trust your own ship, just take high passage and rent a luxury suite at the destination. Saves you the overhead anyhow.

If it's just picking from among your own set of modules based on mission requirements, that's different.
Basically THIS.
But let's take things a step further.



Let's say that you own a Yacht of some variety which does NOT have any kind of "swappable modular" living quarters section built into it. Everything is "integrated" into the ship (ala the classic Type-Y Yacht of LBB2).

Now let's say that there has been a security breach and the living quarters of the ship have been "bugged" somehow.
If you can't find the bug in order to neutralize it (or use it for disinformation), the security of the entire ship is now compromised.
In order to be certain that the bug is no longer a factor, you have to replace the entire starship ... because "everything is integrated" into the ship.



Compare and contrast that with the alternative of a "swappable modular" living quarters section built into a starship (using 16 ton Stateroom Boxes).

Let's say (again) that there has been a security breach and the living quarters of the ship have been "bugged" somehow.
If you can't find the bug in order to neutralize it (or use it for disinformation), the security of the entire ship those Stateroom Boxes is now compromised.
In order to be certain that the bug is no longer a factor, you have to replace the entire starship those Stateroom Boxes with new ones ... and you get to keep the starship that carries them.



Obviously, there a a lot more permutations of this very simplistic scenario I'm painting here, not all of which follow the contours of this pattern, but the point still stands. If you have to "junk" either a piece of the starship or the entire starship in order to neutralize a potential security breach/threat ... which is going to be preferable?

I know what my answer would be. ;)
 
I would just create an Engineering module (PP-MD-JD) sized for AAA, BBB, CCC, etc. and make anything else "Custom Work". Then the Engineering modules could be swapped to change performance (like real water-ships are built in segments and welded together).
 
I would just create an Engineering module (PP-MD-JD) sized for AAA, BBB, CCC, etc. and make anything else "Custom Work". Then the Engineering modules could be swapped to change performance (like real water-ships are built in segments and welded together).
:unsure:

Okay, I see where you're going with that now.
Each module would need to have custom sizing ...
  • A/A/A = 15 tons
  • B/B/B = 25 tons
  • C/C/C = 35 tons
  • D/D/D = 45 tons
  • ... etc.
... but it could be done if you REALLY wanted to. 💰💸💸

The thing is ... what's the point in doing that?
Aside from "paying double for the hull metal" ... why would anyone do that?

Why double for the hull metal?
Well ... :rolleyes:

Let's say you want to build 15 ton Boxes of A/A/A drive units that can be installed into starships built to accept them.
What you wind up with is a set of A/A/A drives (MCr22, as per LBB2.81, p22) plus a 15 ton metal hull of configuration: 4 (MCr0.9).
However, if you're going to put that into a 100 ton hull, you're still paying MCr11 for a custom configuration: 2 hull ... or ... paying MCr3 for a standard hull with atmospheric streamlining.

Either way, the "put the drives into their own box" option is adding a minimum of MCr0.9 to the construction costs because of the "duplicate hull" of the box you want to put the drives into.



Now I can think of boutique reasons for wanting to do something like that (basically regulated racing circuit stuff, where lots of rules dictate engineering) ... but for generic/general everyday usage, it's an (added) expense that doesn't make sense. It's not like starships are in the "habit" of hot swapping their drives multiple times per year between annual overhaul maintenance cycles.

My notion is that during annual overhaul maintenance at a shipyard a starship's drive assemblies DO get pulled out of the hull for inspection and testing before being reinstalled and recalibrated, but that's a shipyard workshop process rather than any kind of "plug & play" hotswap in the field type of thing. It's not like the drives NEED to be moving outside the starship's hull as a matter of routine in normal operations.

Passengers come and go ... so it makes sense for their accommodations to be "removable" from a starship's hull (to facilitate embark/disembark, if nothing else).
Cargo will come and go ... so it makes sense for cargo containers to be "removable" so that the breakbulk contents can be loaded/unloaded at an appropriate marshaling yard for drop offs and deliveries to third parties.
Laboratories (pick your flavor) and Environmental Tanks ... substantially the same thing, especially if you've got a small craft that can perform "sky crane" services to deliver those Boxes exactly where they need to be on a terrestrial surface. (Think SA-2 Sampson, except scaled up to a small craft instead of a vehicle)


Point being that anything that doesn't need to be "integrated" into a starship CAN be modularized for hotswapping when practical.
Drive systems don't exactly meet that "practical" criterion except in some boutique edge cases.

Possible ... sure.
Useful ... not so much. 😖
 
So ... something I've been thinking about with regards to my research into this topic of containerized modular shipping in Traveller is ... if it exists, when might it have started happening?

The obvious answer is "as soon as it became practical" ... which then begs the question, how Soon™ might that be in the Imperial timeline? :unsure:



Well, according to Travellerwiki, the First Imperium reached TL=11 in time for the Consolidation Wars era, unlocking J2 before -5400.
The Second Imperium (Rule of Man) reached a "solid TL=13" before the coming of the Long Night in -1776.

I think it's fair to say, even though it isn't explicitly stated, that a polity which is "solidly TL=13" will have unlocked J3 and J4 during its era.



Which means ... that a 250 ton J3/3G TL=9 Clipper like the one I'm working up could potentially have existed as far back as the Rule of Man :oops: ... and that the class features could have been created so far back in history that no records of the first ships survives into the modern "golden" era of 1105 CT Traveller. :unsure:



One fun side effect of this "historical opportunitism" in creative writing (of Fluff Text™) then becomes the notion that the class is more "Solomani in lineage" (see: Rule of Man/Second Imperium) than it is Vilani. Additionally, it would mean that "breakaway factions of Solomani colonization waves" could have made use of the class, and just like with the legacy J2 Type-S Scout/Courier and J1 Free Trader designs, managed to keep (and/or recreate) the class in order to sustain production of it up until the modern era of 1105 CT Traveller.

However, due to the size and limited/low technology of the class, it is primarily relegated to frontier/free trader scale operations ... rather than being a primary bulk transport used by megacorporations (meaning, it's no Leviathan-class).

However, such an "ancient lineage" stretching all the way back to the Second Imperium suggests the possibility for a class name ... the Rule of Man Clipper (or RoM Clipper). However, that name also suggests an obvious epithet for detractors/competitors to use ... the Ramshackle Clipper ... since the Rule of Man was also known as the Ramshackle Empire.

The beauty of this turn in the backstory is that the class is "so old" (multiple millenia, TL=9) that it's practically Public Domain™ as far as intellectual property rights go. This means that there can be a wide variety of individual shipyards building their own localized industrial base version (same stats, twiddle the immersion details) of the class for the low tech/frontier/provincial market merchant starship buyers and no megacorp is going to give a Cr1 about it.

So you could have "boutique shipyards" in places like Paya/Aramis/Spinward Marches and Grote/Glisten/Spinward Marches as well as the major industrial center of Vilis/Vilis/Spinward Marches building the class for their local regional markets. You could even have the class starships being built by the shipyard at Gram/Sword Worlds/Spinward Marches (type A starport) while many of the other Sword Worlds build Boxes at their own shipyards (type B starports) to facilitate trade within the Sword Worlds.



Yeah. I think I'll take things in that direction for the class backstory this time. :cool:
 
Point being that anything that doesn't need to be "integrated" into a starship CAN be modularized for hotswapping when practical.
Drive systems don't exactly meet that "practical" criterion except in some boutique edge cases.

Possible ... sure.
Useful ... not so much. 😖
[I pick up the gauntlet.] :cool:

Challenge accepted (but for another topic). ;)
 
I think it's fair to say, even though it isn't explicitly stated, that a polity which is "solidly TL=13" will have unlocked J3 and J4 during its era.
While not Implied clearly until T4, and not as a rule until T5, but none of the FTL are automatic for their minimum TLs. (T5.10 p122.) Nor is Jump a needed precursor to discover Hop, Skip, Leap, Bound, Vault... (ibid.)
So, solidly TL13 does not axiomatically include Jump. It does include the needed tech to build it if it is discovered.

We do know they had J3... but it isn't a TL assumption, but explicit elsewhere in canon.
 
Last edited:
General thoughts on why engineering modules…

I am aware of the rules re drive changing, although purely LBB2 isn’t that explicit except in terms of a defined engineering section. There was one hull range, I forget which, that allowed multiple combinations of drives and if you ditch the jump drive more options for higher maneuver/power plants. Or the xboat option.

I’m pretty onboard with the limitation as it makes sense- drives are likely the most dense equipment on board which affects flight characteristics and the floating/lifting characteristics of grav.

I would stick with an engineering space limitation so maybe you can retrofit a higher tech smaller power plant in and get more drive, or get more power for weapons or increased agility under combat EP use.


I was thinking more of a standard ship design that could be more readily customized at build or in a few cases be rapidly customized after retirement. In a sense the standard ship hulls are that way anyway, at least at build time.

Having modules that are standard options for a modular build would be more doable then first glance suggests. Again drives with their million plus per ton cost travels well from IND planets, easily shipping 100 parsecs or more- the same would be true of engineering modules. Worth it if there is a base of 1000s of ships.

The payoff should be something like the standard hull reduced cost and build time as the module should shave months off and thus cost.

Come to think of it, maybe that is the very definition of the standard hulls, formula to slap in an engineering module for that class, hookup the pipes and cables and go.

As to the spacing issue re module bulkheads, take a look at those ship plans from things like Snapshot- definitely an extra bulkhead there (I always figured armor 1 by HG standards). It’s not a problem it’s a feature.
 
I've been wondering for a while what a Stateroom Box of "luxury suites" ought to look like. :unsure:
In this particular case, I'm taking the word "suite" to its logical conclusion here, where it basically means spending 2 compartments instead of just 1.

The result is something more in tune with an accommodation for couples (who want to share the same bed together). What you wind up with is the same arrangement of bulkheads (no change), but the contents of the staterooms in the corners changes.
  • The starboard side staterooms have a king sized bed, end tables and a large closet within the room. The window and privacy/radiation screen is retained.
  • The port side state staterooms become "luxury bathrooms" for the stateroom across the hall, including an actual 2m long bath, a shower outside the bath (to get clean before soaking in the tub) along with the typical hygiene amenities. The connecting access corridor/eva airlock can be set to privacy mode by the stateroom occupant when desired (which can be overriden by authorized crew in emergencies).
In other words, it looks like this ...

g4SbDoY.png


I figure that this sort of Stateroom (Suites) Box modification of accommodations for a noble's yacht would fulfill the 2x staterooms for 1x person (living in luxury) precedent established by the Type-Y Yacht in LBB2.

It's still a 16 ton Box with "4 staterooms" in it, for the purposes of a naval architect's spreadsheet of features, so the construction costs are basically the same. The difference is primarily a matter of interior decorating. The two "suites" (fore and aft) would ordinarily be "double occupancy" per suite (equating to 2x staterooms for 2x people), even for high passengers.

Compare and contrast the above with the Stateroom (Singles) Box that I published earlier.

SOGZWs9.png
 
The grav lift is used for direct vertical access (dorsal/ventral) between Boxes when they are docked together (vertically) in arrays.

(…)

Although the Boxes are generically intended for transport, they can also be used in stationary deployments as accommodation modules in a base camp delivered to planetary surfaces (or by prospectors living in planetoid belts). There are many "non-transport" roles that these Boxes can be used for, so the EVA Airlocks are included to better support these other mission uses that have nothing to do with starship operations.

I thought about this, but I see some practical problems on this:
  1. Is the lift already in the module or must be added? I mean, if every module has a lift on it, when you have several of them piled up there’s a lift on each, and so they are inoperable, and, if there is not, it must be added (not sure how easy is to add it)
  2. The only access to the holo or gallery is through the lift… So, if there are several such modules piled and the lift is active, you can only access to them when it is in your “floor”, and have not if it’s in use.
  3. Which kind of upper and lower doors do you set on this lift column? It must be airtight when closed (as otherwise the problem in 2 above is even worse), but open enough as to allow the lift to pass when in use. Also, the clamps among several such modules piled up must be also airtight, as otherwise the lift column would not be protected by the sealed environment
  4. If the modules are piled up this way, IMHO there should be some kind of backup stairs (or ladder) system, just in case, and most multi-floor ships have.
 
While not Implied clearly until T4, and not as a rule until T5, but none of the FTL are automatic for their minimum TLs.

Well, the existence of Sabmyqys, a TL 17 world without star travel, already hinted it in CT, IMHO...
 
I thought about this, but I see some practical problems on this:
  1. Is the lift already in the module or must be added? I mean, if every module has a lift on it, when you have several of them piled up there’s a lift on each, and so they are inoperable, and, if there is not, it must be added (not sure how easy is to add it)
  2. The only access to the holo or gallery is through the lift… So, if there are several such modules piled and the lift is active, you can only access to them when it is in your “floor”, and have not if it’s in use.
  3. Which kind of upper and lower doors do you set on this lift column? It must be airtight when closed (as otherwise the problem in 2 above is even worse), but open enough as to allow the lift to pass when in use. Also, the clamps among several such modules piled up must be also airtight, as otherwise the lift column would not be protected by the sealed environment
  4. If the modules are piled up this way, IMHO there should be some kind of backup stairs (or ladder) system, just in case, and most multi-floor ships have.
It (the "lift" concept) always had problems that were never addressed, so Spinward just "does it in a module" however they "do it in a standard ship deckplan" where the access is sometimes between floors and sometimes through the top of the hull and sometimes out the bottom of the hull. It really doesn't "work" as modern ELEVATORS function, so it must WORK in some other way.

In practical terms, the ship/module provides access for a levitating floor (and nothing more).
Given the low frequency of use, reducing the grav plate to micro-gravity when "open" and allowing people to jump/fall effortlessly between levels would work as the simplest "non-canon" approach. Then a wall-mounted ladder could provide access when landed and powered down (no grav plates).
 
Last edited:
In practical terms, the ship/module provides access for a levitating floor (and nothing more).
This is what I had in mind. There's a "levitating floor plate" to stand on that goes up/down through the grav lift shaft. Less of an enclosed "car" ride and more of a platform that just goes up/down.

If it's just a platform that rises/falls through an open (yet enclosed by bulkheads and partitioned by iris valves) space, you've got your Grav Lift.

If you're stacking the Boxes high (to create a sort of "hotel experience") you can have a grav lift platform in every box, but allow only one platform in a vertical shaft to be occupied at any one time (so the others "stack up" to get out of the way).

So, for example, let's say you had 10 Stateroom Boxes stacked vertically on top of each other (excuses for why remain pending).
Let's say you're on the 10th floor and you want to get down to the 1st floor at ground level ... kind of like any ordinary elevator, right? :rolleyes:

So the first thing you do is start in the 10th Stateroom Box, you walk up to the iris valve for the grav lift shaft and you push the wall stud, indicating you want to enter the grav lift shaft.
  • Floors 1-9 "lock out" access to the shaft, preventing others from entering until you've left the grav lift shaft.
  • The Floor 10 grav platform moves into postion to be stepped on by someone entering the grav lift shaft.
  • Floors 1-9 slow to a halt wherever they are located in the shaft.
You enter the grav lift shaft, step onto the #10 grav lift plate (that comes with Stateroom Box #10) and the iris valve to the hallway you entered from closes.

Inside of the shaft, on the wall, there is a touch screen to indicate which floor you want to go to and wall studs beside each iris valve to command that specific iris valve to open.

You use the touch screen to command a descent to Stateroom Box #2 (not #1, the "ground floor").

The grav lift platforms for Stateroom Boxes #1-9 all "collect" into the grav lift shaft of Box #1, occupying the interior of that lift shaft.
The #10 grav lift platform descends to Stateroom Box #2.
You press the wall stud to command one of the lateral iris valves to open and step through, letting the iris valve close behind you.

Grav lift platforms #1-10 move up the shaft, clearing the way for grav lift platform #1 to be positioned in Stateroom Box #2.
When grav lift platform #1 is in position at floor level of Stateroom Box #2 (and #2-10 are now higher in the shaft above), the lateral iris valve reopens and you step back through onto the grav lift platform.
The #1 grav lift platform descends to Stateroom Box #1.
You press the wall stud by the lateral iris valve you want to exit through, the valve opens and you exit the gav lift shaft at your destination.



The only time this kind of "two step shuffle" is necessary is when there are 3+ Boxes stacked vertically and you want to go from the dorsal Box to the Ventral Box (or vice-versa). Any of the intermediate levels can be accessed in a single lift, but in order to get to the end of the line you need to enter/exit/enter/exit so as to let the grav lift platforms "reshuffle" their positions inside the grav lift shaft in order to "get out of the way" of the passenger getting to where they need to go.

The grav lift shaft has enough floor space/headroom space to allow 2 grav lift platforms to be at the floor and ceiling of a single Box's interior simultaneously. This allows 2 platforms to stack on the floor or 2 platforms to stack at the ceiling and still be able to use the grav lift shaft for movement of people (and their luggage).
Which kind of upper and lower doors do you set on this lift column?
The standard is to use vertical axis iris valves between floors, to maintain pressure compartmentalization between decks.
Also, the clamps among several such modules piled up must be also airtight, as otherwise the lift column would not be protected by the sealed environment
Already included in the "external hangar bay" capacity allowance, costing Cr2000 per ton of external docking capacity.
Note that internal hangar bays cost Cr2000 per ton as stipulated in LBB5.80 on p32.

If an internal hangar bay has equipment to assist with the launch and recovery of sub-craft, I figure that "the same thing on the outside of the hull" ought to be adequate for hard docking and securing to other craft as well, hence the additional expense for the capability being built in as part of the stock design specifications.
and sometimes through the top of the hull and sometimes out the bottom of the hull.
Correct.
There are iris valves at the top and bottom of the grav lift shaft, but the grav platform can go a "short distance" beyond the confines of the shaft (I'm thinking 10m or less, usually less). This then gives an exterior access point when the craft is grounded and parked on its landing gear. So rather than needing to drop a set of folding stairs, you can just have a grav lift platform drop down onto the ground/tarmac from the ventral side, step onto it, and be grav lifted up into the interior (assuming sufficient clearance below to do this). Same deal for the dorsal side of the hull ... except there the grav lift platform is likely to stop when level with the outside of the hull so you can just step off onto the upper hull (at which point the grav platform descends and the iris valve closes.

If you're having trouble imaging what this might "look like" in person ... try this mildly famous example of a grav lift shaft in operation, which opens to the dorsal hull of a craft.

 
I would just create an Engineering module (PP-MD-JD) sized for AAA, BBB, CCC, etc. and make anything else "Custom Work". Then the Engineering modules could be swapped to change performance (like real water-ships are built in segments and welded together).
I really like the idea, but it directly contravenes LBB2 and HG. There might be rule sets that allow it, but I'm not familiar with them.
 
Having some additional fun with the 16 ton form factor. :sneaky:



So one of the ideas is that (as per LBB5.80, p32):
  • Small craft are carried at their own tonnage on ships 1000 tons and under; they require tonnage equal to 130% of their mass within the hull of larger ships.
  • Big craft require tonnage equal to 110% of their mass in the ship
In the context of 16 ton Boxes that can be "linked together" (via docking points) there's going to be an "accounting trick" going on.
Small craft are 99- tons ... and big craft are 100+ tons.

Therefore ...
  • 6x 16 ton Boxes = 96 combined tons ≈ still small craft scale
  • 7x 16 ton Boxes = 112 combined tons ≈ becomes big craft scale
Therefore, in order to carry small craft at their own tonnage, the combined tonnage of starship + external load (if any) needs to remain 1000 tons or less ... and no "grouping" of 16 ton Form Factors put together can exceed 6x 16 ton Boxes.

You can have "multiple chunks" of 6x16 ton Boxes, but they need to be discrete and separate arrays, rather than being a single monolithic block.

For example:
  • A 250 ton starship with D/D/D drives is code: 1/1/1 @ 800 tons combined displacement (so under the 1000 tons or less limit to carry small craft at their own tonnage).
  • (800-250)/16 = 34.375 ≈ 34x 16 ton Boxes can be docked externally.
However, those 34x 16 ton Boxes must be subdivided into groups of 6 or less per "block" in order to not be so large (when combined) as to displace as much as a big craft (100+ tons) in a single "chunk" of Boxes. This then necessitates that there be 34/6 = 5.667 ≈ 6 docking points, minimum around the exterior hull of the starship.

For the record, I'm currently thinking in terms of 9 external docking points on the deck plan, with a total capacity of 550 tons external load capacity. 🧐



However, this same line of thinking continues to apply as you move down the scale from big craft into small craft.
The 16 ton Escort Fighter is designed to be capable of external loading as well, and the same rules apply, however you're working at a different scale.
  • A 16 ton small craft with A/A drives (code: 1 @ 200 tons) has the following drive performance outputs at the following external loads:
    • 0x 16 ton Box = 16 combined tons = code: 6/6
    • 1x 16 ton Box = 32 combined tons = code: 6/6
    • 2x 16 ton Box = 48 combined tons = code: 4/4
    • 3x 16 ton Box = 64 combined tons = code: 3/3
    • 5x 16 ton Box = 96 combined tons = code: 2/2
    • 11x 16 ton Box = 192 combined tons = code: 1/1
However, as already stipulated in the above analysis ... if a block of joined Boxes exceeds 6, that "block of Boxes" starts getting accounted for as a big craft, rather than as 6 small craft (because 7*16=112 combined tons).

This means that a small craft capable of docking with up to 11x 16 ton Boxes is going to need 2 external docking points, so as to be able to dock with a 6x Boxes block and a 5x Boxes block at the two docking point interfaces with the small craft.



Okay ... so what? (I hear some of you thinking) :rolleyes:
What does that have to do with the price of farm equipment on Terra?

Well, what it means is that there are going to be some "standard docking configurations" of Boxes when towing them externally using the Escort Fighter.

Easiest way to demonstrate this is a sort of "form factor symbolic" view from the front/aft.
The purple box is the form factor of the Escort Fighter (seen bow/aft on).
The black box(es) are the 16 ton Boxes being docked to and towed by the Escort Fighter. The Boxes are rotated 90º to the Escort Fighter, so as to not obstruct visibility (as much) from the bridge cockpit in the forward nose of the Escort Fighter (because the form factor is longer than it is wide).

So although this representation is crude, it ought to convey the idea of how everything links up together if you were watching the bow of an Escort Fighting coming towards you (these are NOT top down deck plan views!) towing external loads.



6G = Escort Fighter (purple) + 1x 16 ton Box
hoDMFvO.png




4G = Escort Fighter (purple) + 2x 16 ton Boxes
KisF9Xh.png




3G = Escort Fighter (purple) + 3x 16 ton Boxes
1eVne61.png




2G = Escort Fighter (purple) + 5x 16 ton Boxes
y7W48kA.png




1G = Escort Fighter (purple) + 11x 16 ton Boxes
oEhalMP.png




So as you can see, no more than 6x 16 ton Boxes per docking port interface with the parent (small) craft with the maneuver capability.
 
Back
Top