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

ACS Compact Format

Back to the ACS format.

At the moment I'm implementing the writer to a D64 disk image with a single sequential (USR) file.

To do this, I wrote a little BASIC program that created the file the way I want it to look, and opened up my image viewer to see the bytes written. The first block looks like this:

Code: 
00: 11 0b 2d 2d 2d 0d 41 43  53 31 2e 30 20 32 30 31    ..---.ACS1.0 201
10: 37 31 32 30 32 0d 41 32  2d 46 53 32 32 2d 45 20    71202.A2-FS22-E 
20: 43 2b 30 20 44 2d 31 20  31 35 34 2e 31 0d 48 53    C+0 D-1 154.1.HS
30: 4c 20 36 30 30 20 31 20  20 44 30 20 30 30 30 30    L 600 1  D0 0000
40: 30 20 53 4c 20 48 55 4c  4c 0d 48 4c 4c 20 36 20    0 SL HULL.HLL 6 
50: 20 20 31 20 20 46 31 20  30 30 30 30 30 20 4c 41      1  F1 00000 LA
60: 4e 44 45 52 53 0d 41 4b  43 20 30 20 20 20 32 38    NDERS.AKC 0   28
70: 20 46 31 20 30 30 30 30  30 20 4b 49 4e 45 54 49     F1 00000 KINETI
80: 43 0d 41 43 41 20 30 20  20 20 31 20 20 46 31 20    C.ACA 0   1  F1 
90: 30 30 30 30 30 20 41 42  4c 41 54 0d 46 46 46 20    00000 ABLAT.FFF 
a0: 31 31 38 20 31 20 20 44  30 20 30 30 30 30 30 20    118 1  D0 00000 
b0: 46 55 45 4c 0d 44 50 46  20 36 20 20 20 32 20 20    FUEL.DPF 6   2  
c0: 46 31 20 30 30 30 30 30  20 50 4c 41 4e 54 0d 44    F1 00000 PLANT.D
d0: 4a 46 20 31 31 20 20 32  20 20 46 31 20 30 30 30    JF 11  2  F1 000
e0: 30 30 20 4a 55 4d 50 0d  44 4d 46 20 33 20 20 20    00 JUMP.DMF 3   
f0: 32 20 20 46 31 20 30 30  30 30 30 20 4d 41 4e 55    2  F1 00000 MANU

Then I opened up an image created by my program to see what I need to adjust.

Code: 
00: 11 01 01 01 01 00 2d 2d  2d 20 0a 41 43 53 31 2e    ......--- .ACS1.
10: 30 3a 20 46 72 69 20 44  65 63 20 31 20 30 31 3a    0: Fri Dec 1 01:
20: 31 34 3a 31 30 20 47 4d  54 2d 30 36 30 30 20 32    14:10 GMT-0600 2
30: 30 31 37 0a 0a 41 32 2d  46 53 32 32 2d 31 34 20    017..A2-FS22-14 
40: 43 2b 30 20 44 2d 31 20  31 35 34 2e 31 0a 48 20    C+0 D-1 154.1.H 
50: 36 30 30 20 31 20 20 44  30 20 30 30 30 30 30 20    600 1  D0 00000 
60: 53 74 72 65 61 6d 6c 69  6e 65 64 20 48 75 6c 6c    Streamlined Hull
70: 2c 20 6c 69 66 74 65 72  73 0a 48 20 36 20 20 20    , lifters.H 6   
80: 31 20 20 46 31 20 30 30  30 30 30 20 4c 61 6e 64    1  F1 00000 Land
90: 69 6e 67 20 6c 65 67 73  20 77 69 74 68 20 70 61    ing legs with pa
a0: 64 73 0a 41 20 30 20 20  20 31 20 20 46 31 20 30    ds.A 0   1  F1 0
b0: 30 30 30 30 20 41 56 3d  32 38 2e 20 31 20 4b 69    0000 AV=28. 1 Ki
c0: 6e 65 74 69 63 20 43 68  61 72 67 65 64 0a 41 20    netic Charged.A 
d0: 30 20 20 20 31 20 20 46  31 20 30 30 30 30 30 20    0   1  F1 00000 
e0: 41 62 6c 61 74 20 43 6f  61 74 69 6e 67 0a 46 20    Ablat Coating.F 
f0: 39 39 20 20 31 20 20 44  30 20 30 30 30 30 30 20    99  1  D0 00000


*1* I have an extra 01 01 01 00 at the beginning. Issue one.
(The date format is long. Not a serious issue.)
*2* I'm using 0x0a instead of 0x0d for newlines. Issue two.

Actually those two issues are probably the most important ones.
 
OK, that did the trick. Many relatively detailed ACS designs readably fit into 5 blocks (less than 1.25k) of data.
 
agorski said:
Code: 
            "sensors":
            [
                
                {
                    "attached":"yes",
                    "controlpanelid":41519,
                    "deployable":"no",
                    "extendable":"no",
                    "location":159569,
                    "mount":"Surface",
                    "mountlocation":"Surface",
                    "powersource":"Power Plant",
                    "range":"Attack",
                    "stage":"Ultimate",
                    "type":"Communicator"
                },
                
                {
                    "attached":"yes",
                    "controlpanelid":520540,
                    "deployable":"no",
                    "extendable":"no",
                    "location":159569,
                    "mount":"Surface",
                    "mountlocation":"Surface",
                    "powersource":"Power Plant",
                    "range":"Attack",
                    "stage":"Advanced",
                    "type":"Radar"
                },
                
                {
                    "attached":"yes",
                    "controlpanelid":922606,
                    "deployable":"no",
                    "extendable":"no",
                    "location":159569,
                    "mount":"Surface",
                    "mountlocation":"Surface",
                    "powersource":"Power Plant",
                    "range":"Attack",
                    "stage":"Advanced",
                    "type":"Scope"
                }
            ],
Click to expand...

I saw this and wondered how it compared to how I represent sensors.
I'm storing a lot of detail (not relying on the software to know how to compute) -- including the "original" sensor data before stage effects -- and I'm also abbreviating the heck out of keys, which I think was a mistake.

I think I like how you break out Extendable and Deployable away from the mount. I mash them into the mount codes themselves.

Code: 
    {"original": 
      {"tons": 3,
      "mcr": 2.5,
      "label": "AR Ext Communicator",
      "CP": 1,
      "range": "AR",
      "q": 0,
      "r": 0,
      "s": 0,
      "howMany": 1,
      "tl": 16,
      "b": 0,
      "eff": 1,
      "basetl": 8,
      "totalTons": 3,
      "mod": 4,
      "totalMCr": 2.5,
      "target": 20,
      "e": 0,
      "category": "AR Ext Communicator",
      "name": "Communicator",
      "Sq": 6,
      "notes": "",
      "mount": "Ext",
      "config": "Sensor",
      "type": "Sensor"}
,
    "stage": "Adv",
    "mcr": 2.5,
    "label": "Adv AR Ext Communicator",
    "tons": 3,
    "CP": 1,
    "range": "AR",
    "q": 6,
    "r": 5,
    "s": 1,
    "howMany": 1,
    "tl": 13,
    "b": -3,
    "eff": 1.2,
    "basetl": 8,
    "totalTons": 3,
    "mod": 7,
    "totalMCr": 2.5,
    "target": 20,
    "e": 0,
    "category": "AR Ext Communicator",
    "name": "Communicator",
    "mount": "Ext",
    "rating": 0,
    "notes": "R0",
    "Sq": 6,
    "config": "Sensor",
    "type": "Sensor"}
 
Yeah, I don't store things I can calculate. My app uses lots of computed properties for that, like Tons and Cost. Clarifications:

Location is the hull that this is installed in.
Attached is a duplication. If the hull is attached, this is True.
Mountlocation can be "Surface", "Hardpoint", or "Firmpoint".
PowerSource can be the default of power plant or any of the dispersed power options which is only for color at this time as there are no details for cost and tonnage of dispersed power options in T5.
 
And I'm warming up to your use of unique IDs for control panels/points, and power dispersal indicator. My version 2 is going to use those.


I do store roll-up values, quite a bit. It's dangerous. But I do it, because I write other software that doesn't know how to compute commonly-needed values. I want to share data without requiring knowledge of the construction rules. And I didn't want a separate export format...

I also had this wild idea that I could off-load custom components into the file system. So if you want a custom Whirligig that the rules didn't allow or account for, no problem, just drag and drop it in, and it's in, and you can do to it what you can do to everything in its class. It works, nicely.

And even though I have different types of data in each component record, it's all pretty flat. At one time, I had a more organized structure -- for example, QREBS were in a substructure. But the data is all about convenience rather than beauty, so in the end I just splat everything at the same level. I may change that.
 
In the Constructor for control panels and hulls I just generate a long random number for the ID, and pray it doesn't get duplicated. ;)

As for custom components:
For compartments T5 specifies 3 kinds of compartments based on complexity, so I let the user define by name and tonnage whatever they want like a wardroom or torture chamber and assign the complexity.
For crew I let the user pick a descriptive name, service, rank, and a list of duties which can be whatever you want to type in if my list doesn't have it.

I don't track QREBS or spaces for anything.
 
Yes, I really like your crew information. I backed off on crew details, which originally tallied number of each role needed. After awhile I simply abstracted to the number of each control surfaces and left it at that.

I track deck squares, but it's a waste of data space. Tonnage is sufficient. Any program can multiply by two :/
 
I've felt the desire to "compress" data, even though I don't need to. Heck, a zipfile is all the compression one needs.
 
So JSON Version 2 of my shipyard data components may look something like

Code: 
    "category": "Sensor",
    "config": "",  # context-sensitive: Deployable, or Streamlined, or...
    "code": "C",
    "type": "Communicator",
    "mcr": 2.5,
    "totalMCr": 2.5,
    "mount": "Ext",
    "number": 1,
    "panels": 1,      # or, alternately, a list such as [45619]
    "powersource": "Central",
    "range": "AR",
    "stage": "Ult",
    "basetl": 8,
    "tl": 13,
    "mod": 7,
    "rating": 20,   # context-sensitive: jump rating, target number, or...
    "tons": 3,
    "totalTons": 3,
    "quality":
    {
        "q": 6,
        "r": 5,
        "e": 0,
        "b": -3,
        "s": 1,
        "efficiency": 1.2
    }

I might or might not need a constructed "Label" field. If not, Label might (MIGHT) be construct-able as:

STAGE - RANGE - MOUNT - CONFIG - TYPE - RATING

Meanwhile, the "ACS" version will be sort of like the original post.

(Note that "Range" is two characters, and "Stage" is three... there's a fixed format lurking in there somewhere...)

"Mount" fits into four characters. Surf, Ant, BAnt, Bolt-In, T1, T2, T3, T4, B1, B2, Bay, LBay, M.

Deployable and Extendable are two characters (De, Ex), and the hull configs could similarly fit into two chars.
 
Last edited:
ACS1.0. Its basis is YAML, but it is actually fixed-format. Thus it doesn't require a YAML parser, but YAML could be used to grab out the first level of data. In other words, it's a reasonable compromise.

Code: 
---
ACS1.0: Sat May 19 18:40:57 GMT-0500 2018

Mission: Far Trader
QSP: A2-FS22
TL: 14
Name: Far Trader
Actual Tons: 600

MCr: 154.1
Crew comfort:     +0
Passenger demand: -1

Comments: Using a 600-ton TL 14 streamlined hull, the far trader ranges 
far and wide, and deals with every world it finds.

Even amber zones and red zones are not considered off limits by its captains, 
provided there is profit to be made and the risk of being caught is slight. 
It has drives capable of jump-2 and 2-G acceleration. Fuel tankage supports 
jump-2 and two months of operation, and the ship incorporates fuel scoops 
and fuel intakes for wilderness refuelling. The bridge is standard and has a 
computer Model/ 1bis and a basic sensor suite.

There are two hardpoints, but no weapons are mounted. Like the free trader, 
the far trader is built around its cargo bay, in this case just over 300 tons, 
plus passenger staterooms.

A single air/raft is carried for various ship duties. The ship is streamlined, 
and can land on uneven terrain.  The far trader requires a crew of four: 
pilot/astrogator, two engineers, and a steward.

Components:
 - Hull 600  1  38 D D 00000 0 Streamlined Hull, lifters
 - Hull   6  1   6 F F 00000 1 Landing legs with pads
 - Armo   0  1   0 F F 00000 1 AV=28. 1 Kinetic Charged
 - Armo   0  1   0 F F 00000 1 Ablat Coating
 - Driv  99  1   0 D D 00000 0 Jump Fuel (2  parsecs)
 - Driv  19  1   0 D D 00000 0 Plant Fuel (2 months)
 - Driv 6.3  1  19 C F 00000 1 Adv PowerPlant F
 - Driv  12  1  35 C F 00000 1 Adv Jump Drive F
 - Driv 3.6  1  22 C F 00000 1 Adv Maneuver Drive F
 - Driv   9  1 6.5 9 9 00000 6 Complete Fuel Collection
 - Oper .33  1   3 C H 00000 1 Adv Computer Model/1bis std
 - Oper 0.5  1 0.5 F F 00000 0 Med Console
 - Oper   2  2   1 F F 00000 0 Emergency Low Berth
 - Oper   2  2   2 F F 00000 0 Life Support Standard
 - Oper   8  1 0.4 F H 00000 0 Spacious Bridge
 - Vehi   4  1 0.1 A A 00000 0 Air/Raft Enclosed
 - Crew   6  1 0.4 F F 00000 1 Owner's Suite
 - Crew   6  3 0.3 F F 00000 0 Crew Staterooms
 - Crew 0.5  1 0.5 F F 00000 0 Crew's Shared Fresher
 - Crew   5  1   0 F F 00000 0 Crew Lounge
 - Payl 0.5  1 0.1 F F 00000 1 Personnel Air Lock
 - Payl 320  1   0 D D 00000 0 Cargo Hold
 - Payl   1  1   1 F F 00000 0 Container Handler
 - Payl   8  1 1.8 F F 00000 1 Large Cargo Lock
 - Pass  30  5   2 F F 00000 0 Luxury Stateroom
 - Pass  40 20   2 F F 00000 0 Standard Stateroom
 - Pass   2  2   2 F F 00000 0 Common Fresher
 - Pass  10  1   0 F F 00000 0 Passenger Lounge + Commons
 - Sens   0  1 3.5 C F 00000 1 Adv DS Surf Communicator
 - Sens   0  1 3.5 C F 00000 1 Adv DS Surf Scope
 - Sens   0  1 3.5 C F 00000 1 Adv DS Surf Radar


ref: [<a href='http://www.farfuture.net/'>Far Future Enterprises</a>]
 
I like it.

I would include a header hinting at the columns contents.

I would use another character for tonnage and cost. ACSs can be larger than 1000 Dt.

Total armour might be calculated somewhere in the text description?

Space should be reserved for the hardpoints? We can't really just reduce cargo space to mount weapons?



From personal prejudice I would group the components in functional groups and with derived components after what it's depending on, perhaps something like this:
Code: 
Components:
 = Type  ton  #  MCr ? ? QREBS ? Comment
 - Hull  600  1   38 D D 00000 0 Streamlined Hull, lifters
 - Hull    6  1    6 F F 00000 1 Landing legs with pads
 - Armo    0  1    0 F F 00000 1 AV=28. 1 Kinetic Charged
 - Armo    0  1    0 F F 00000 1 Ablat Coating
 - Driv   12  1   35 C F 00000 1 Adv Jump Drive F
 - Driv  3.6  1   22 C F 00000 1 Adv Maneuver Drive F
 - Driv  6.3  1   19 C F 00000 1 Adv PowerPlant F
 - Driv   99  1    0 D D 00000 0 Jump Fuel (2  parsecs)
 - Driv   19  1    0 D D 00000 0 Plant Fuel (2 months)
 - Driv    9  1  6.5 9 9 00000 6 Complete Fuel Collection
 - Oper    8  1  0.4 F H 00000 0 Spacious Bridge
 - Oper  .33  1    3 C H 00000 1 Adv Computer Model/1bis std
 - Sens    0  1  3.5 C F 00000 1 Adv DS Surf Communicator
 - Sens    0  1  3.5 C F 00000 1 Adv DS Surf Scope
 - Sens    0  1  3.5 C F 00000 1 Adv DS Surf Radar
 # Weapons summarised here?
 # Separate a payload block from the engineering above?
 - Crew    6  1  0.4 F F 00000 1 Owner's Suite
 - Crew    6  3  0.3 F F 00000 0 Crew Staterooms
 - Crew  0.5  1  0.5 F F 00000 0 Crew's Shared Fresher
 - Crew    5  1    0 F F 00000 0 Crew Lounge
 - Pass   30  5    2 F F 00000 0 Luxury Stateroom
 - Pass   40 20    2 F F 00000 0 Standard Stateroom
 - Pass    2  2    2 F F 00000 0 Common Fresher
 - Pass   10  1    0 F F 00000 0 Passenger Lounge + Commons
 - Life  0.5  1  0.5 F F 00000 0 Med Console
 - Life    2  2    1 F F 00000 0 Emergency Low Berth
 - Life    2  2    2 F F 00000 0 Life Support Standard
 - Payl  0.5  1  0.1 F F 00000 1 Personnel Air Lock
 - Payl  320  1    0 D D 00000 0 Cargo Hold
 - Payl    1  1    1 F F 00000 0 Container Handler
 - Payl    8  1  1.8 F F 00000 1 Large Cargo Lock
 - Vehi    4  1  0.1 A A 00000 0 Air/Raft Enclosed
 = Type  ton  #  MCr ? ? QREBS ? Comment
This way the technically disinclined only has to look at the payload section to find the people and cargo capacity.
 
I feel I'll get into trouble by not having separate classifier codes for e.g. staterooms versus common areas. In particular this can be an important distinction when you calculate how crowded your spaces could be.

So for example.

CSn - crew stateroom; n = number of bunks.
CC0 - crew common space.
CC1 - crew fresher space.

Thus

PSn - payload - stateroom; n = number of bunks.
PC0 - payload - common space.
PC1 - payload - fresher space.

MW0 - magazine
 
Last edited:
AnotherDilbert said:
I like it.

I would include a header hinting at the columns contents.
Click to expand...
You're right -- in fact a header that also serves as a field width guide sounds super useful.

AnotherDilbert said:
I would use another character for tonnage and cost. ACSs can be larger than 1000 Dt.
Click to expand...
You're right again.

AnotherDilbert said:
From personal prejudice I would group the components in functional groups and with derived components after what it's depending on, perhaps something like this:
Click to expand...
The code that generates these files greps components out in this manner. It could easily emit commented hints.
 
AnotherDilbert said:
That was for human-readability. I don't suppose the software cares a jot either way.
Click to expand...
It doesn't --- but I do.

I'm always thinking about this format, and right at the moment I'm thinking about adjusting it to be even easier for humans to read, without destroying its machine-readability. It doesn't matter if the data takes up 2K versus 4K -- those sorts of size differences just haven't mattered since the last millennium.
 
Playing around with the format.... reordering the fields.

Code: 
---
ACS1.0: Fri Apr 15 18:15:18 2022
Mission: Free Trader
QSP: A-DS12
TL: 11
Name: Eakhau
Tons: 400
Actual Tons: 398

MCr: 94
Owner: Aslan
Allegiance: As

Crew comfort: 0
Passenger demand: 1
Cargo: 162
FuelPercentage: 12
Components:

#    TONS   # HULL                              MCR  CODE  R QREBS
#   ----- --- ------------------------------- -----  ;--- -- -----
 -    400   . Streamlined Hull                   26  ;HH0  S 00000

#    TONS   # ARMOR                             MCR  CODE  R QREBS
#   ----- --- ------------------------------- -----  ;--- -- -----
 -      0   . AV=11. 1 Blast Plate                0  ;AA1 11 00000

#    TONS   # DRIVES                            MCR  CODE  R QREBS
#   ----- --- ------------------------------- -----  ;--- -- -----
 -     80   . Jump Fuel (2  parsecs)              0  ;DF0  - 00000
 -      4   . Plant Fuel (0.5 months)             0  ;DF0  - 00000
 -     13   . PowerPlant-2 (D)                   13  ;DP1  D 00000
 -     25   . Jump Drive-2 (D)                   25  ;DJ1  D 00000
 -      3   . Maneuver Drive-1 (B)                6  ;DM1  B 00000
 -      1   . Fuel Scoops 100t/hr                 0  ;DF1 S1 00000

#    TONS   # OPERATIONS                        MCR  CODE  R QREBS
#   ----- --- ------------------------------- -----  ;--- -- -----
 -      2   . Computer Model/2 std                5  ;OC1  2 00000
 -      2   . Life Support Long Term              2  ;OL0  L 00000
 -      1   . Life Support Luxury                 1  ;OL0  X 00000
 -      1   . Life Support Adaptable              1  ;OL0  A 00000
 -      2   . Clinic                              1  ;OM1  - 00000
 -     10   . Spacious Controls                   0  ;OB0  2 00000

#    TONS   # WEAPONS                           MCR  CODE  R QREBS
#   ----- --- ------------------------------- -----  ;--- -- -----
 -      0  4x FR T1de Empty                       1  ;WW1 -2 00000

#    TONS   # CREW                              MCR  CODE  R QREBS
#   ----- --- ------------------------------- -----  ;--- -- -----
 -      0  2x Crew Shared Fresher                 0  ;CF0  1 00000
 -      4  3x Crew Lounge                         0  ;CC0  - 00000
 -      2  6x Crew Stateroom                      0  ;CS0  1 00000

#    TONS   # PAYLOAD                           MCR  CODE  R QREBS
#   ----- --- ------------------------------- -----  ;--- -- -----
 -      0 16x Low Berth                           0  ;PL0  - 00000
 -    162   . Cargo Hold Basic                    0  ;PC0  - 00000
 -      6  8x Luxury Stateroom                    0  ;PS0  1 00000
 -      0   . Shared Fresher                      0  ;PF0  1 00000
 -      2   . Standard Stateroom                  0  ;PS0  1 00000
 -      1   . Aslan Shrine                        0  ;PO0  - 00000
 -      4   . Passenger Lounge                    0  ;PC0  - 00000

ref: [<a href='http://www.farfuture.net/'>Far Future Enterprises</a>]
 
robject said:
Playing around with the format.... reordering the fields.
Click to expand...
Yes, that is much easier to read.

I would not place life support with the "bridge".
Perhaps grouping the accommodations?
I would reverse the order of the drives, to start with drives and then derived components such as power plants and fuel.

Something like this:
Code: 
#    TONS   # HULL                              MCR  CODE  R QREBS
#   ----- --- ------------------------------- -----  ;--- -- -----
 -    400   . Streamlined Hull                   26  ;HH0  S 00000

#    TONS   # ARMOR                             MCR  CODE  R QREBS
#   ----- --- ------------------------------- -----  ;--- -- -----
 -      0   . AV=11. 1 Blast Plate                0  ;AA1 11 00000

#    TONS   # DRIVES                            MCR  CODE  R QREBS
#   ----- --- ------------------------------- -----  ;--- -- -----
 -      3   . Maneuver Drive-1 (B)                6  ;DM1  B 00000     <== Start with the decision point, the performance
 -     25   . Jump Drive-2 (D)                   25  ;DJ1  D 00000
 -     13   . PowerPlant-2 (D)                   13  ;DP1  D 00000     <== Then the automatic derived support?
 -      4   . Plant Fuel (0.5 months)             0  ;DF0  - 00000
 -     80   . Jump Fuel (2  parsecs)              0  ;DF0  - 00000
 -      1   . Fuel Scoops 100t/hr                 0  ;DF1 S1 00000

#    TONS   # OPERATIONS                        MCR  CODE  R QREBS
#   ----- --- ------------------------------- -----  ;--- -- -----
 -      6   . Spacious Contr Consoles             0  ;OB0  2 00000     <== Separate types of consoles?
 -      4   . Spacious Op Consoles                0  ;OB0  2 00000
 -      2   . Computer Model/2 std                5  ;OC1  2 00000
 -      2   . Commo                               5  ;OC1  2 00000
 -      2   . Sensors                             5  ;OC1  2 00000

#    TONS   # WEAPONS                           MCR  CODE  R QREBS
#   ----- --- ------------------------------- -----  ;--- -- -----
 -      0  4x FR T1de Empty                       1  ;WW1 -2 00000

#    TONS   # ACCOMMODATIONS                    MCR  CODE  R QREBS
#   ----- --- ------------------------------- -----  ;--- -- -----
 -      0  2x Crew Shared Fresher                 0  ;CF0  1 00000
 -      4  3x Crew Lounge                         0  ;CC0  - 00000
 -      2  6x Crew Stateroom                      0  ;CS0  1 00000
 -      6  8x Luxury Stateroom                    0  ;PS0  1 00000
 -      0   . Shared Fresher                      0  ;PF0  1 00000
 -      2   . Standard Stateroom                  0  ;PS0  1 00000
 -      1   . Aslan Shrine                        0  ;PO0  - 00000
 -      4   . Passenger Lounge                    0  ;PC0  - 00000
 -      0 16x Low Berth                           0  ;PL0  - 00000
 -      2   . Life Support Long Term              2  ;OL0  L 00000
 -      1   . Life Support Luxury                 1  ;OL0  X 00000     <== Note: 1 Dt lux per person
 -      1   . Life Support Adaptable              1  ;OL0  A 00000
 -      2   . Clinic                              1  ;OM1  - 00000

#    TONS   # PAYLOAD                           MCR  CODE  R QREBS
#   ----- --- ------------------------------- -----  ;--- -- -----
 -    162   . Cargo Hold Basic                    0  ;PC0  - 00000
 
You must log in or register to reply here.

Similar threads

S
Holiday Filler Campain
Replies
2
Views
891
Sir Brad
S
Spinward Flow
CT Only: 30 ton Strike Fighter (TL=11)
Replies
16
Views
894
kilemall
K
A
calculating Hybrid SLM cost
Replies
4
Views
155
Apricus
A
Spinward Flow
CT Only: LSP Modular Pinnace
4 5 6
Replies
111
Views
2K
Grav_Moped
Grav_Moped
Spinward Flow
CT Only: 16 ton Light Fighter (TL=9)
Replies
2
Views
713
Spinward Flow
Spinward Flow
Back
Top