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

Storing the speculative trade data

robject

SOC-14 10K
Admin Award
Marquis
The Traveller Book, page 105, has the nice roulette-style table for generating speculative goods.

Each entry has a label, base price, quantity, up to three purchase DMs, and up to three resale DMs.
Label could fit into a 16 character string.
Base price ranges from 300 credits to millions of credits. That’s a long int.
Quantity is of the form nD x m. Up to 8 dice. Multiplier is 1, 5, or 10.
There are six possible trade remarks taken into consideration - ag, non ag, rich, poor, industrial, and non industrial. These DMs range from -8 to +8. Example: item 41, gems.

Quantity has a slight wrinkle, in that items 51-56 are priced by unit, without a tonnage given. That could be rationalized by guesstimating the tons per unit, and then updating the base price and quantity multiplier accordingly.

E.g. guesstimates:
Aircraft, 10 tons, so KCr100 per ton.
Air/raft, 5 tons (call it grav craft and 5 tons would work fine), so KCr 120 per ton.
Computers, 5 tons, so MCr 2 per ton.
ATVs, 10 tons, so Cr 3000 per ton.
Armored vehicles, 10 tons? So Cr 7000 per ton.
Farm Machinery... 5 or 10 tons? 5 tons at KCr 30 per ton.
Or similar.


I’m coding in C, so values where reasonable will be coded in bits — six bits per trade code, quantity parameters as three bits and two bits, respectively, perhaps, or it can be more generous, stored as integers. Utility is more important than compression.

char label[16];
long base_price;
int quantity_dice :4;
int quantity_multiple :4;

// probably don’t have to all be 4 bits... and a couple might have to be 5 bits.
int purchase_ag :4;
int purchase_na :4;
int purchase_ri :4;
int purchase_po :4;
int purchase_in :4;
int purchase_ni :4;
int resale_ag :4;
int resale_na :4;
int resale_ri :4;
int resale_po :4;
int resale_in :4;
int resale_ni :4;


Guesstimate 27 bytes per record, 36 records = 972 bytes. Rough first approximation.
 
Purchase DM ranges.
Ag: -7 to 0 = 3 bits
Na: -5 to 0 = 3 bits
Ri: -4 to +5 = 4 bits
Po: 0 to +4 = 3 bits
In: -5 to +4 = 4 bits
Ni: -8 to +5 = 4 bits

Resale DM ranges.
Ag: -6 to +5 = 4 bits
Na: -8 to +2 = 4 bits
Ri: -4 to +8 = 4 bits
Po: 0 to +4 = 3 bits
In: -3 to +6 = 4 bits
Ni: -3 to +4 = 3 bits

Only saves one byte, and still requires a hard coded value modifier for each.
 
If I instead widen each trade code field to a signed char, then the record expands to 33 bytes, and totals just over 1k.

Probably worth the minor expense in size.
 
Air/raft, 5 tons (call it grav craft and 5 tons would work fine), so KCr 120 per ton.
Air/Raft = 4 tons, MCr0.6 per air/raft, quantity is 1D
Computers, 5 tons, so MCr 2 per ton.
This one is the messiest one.
It's basically MCr10 per computer, quantity is 1D (per the table).
Except that starship computers are "defined" (even in LBB2.77 and after) and have costs and tonnages and tech level (and notably, no starship computer is priced at MCr10 exactly). So what the tonnage is to assign for the speculative cargo Computers is very poorly defined and difficult to ascertain (since starship computer tonnages change with tech levels).
 
I don't quite remember how I came up with these numbers, but this is what I came up with.

Code:
        (51 "Aircraft" 250000 -3 0 1 4)
        (52 "Air/Raft" 1500000 -2 0 1 4)
        (53 "Computers" 2500000 -2 0 1 4)
        (54 "All Terrain Vehicles" 500000 -2 0 1 6)
        (55 "Armored Vehicles" 1166666 -2 0 1 6)
        (56 "Farm Machinery" 37500 -2 0 1 4)

The relevant attributes for this discussion are the price, and the last 2 numbers.

The price is "per ton", the 1 is "1D", and the 4/6 is the number of tons per qty.

So, a Computer cost 2,500,000 per ton, I had them at 4 tons each (thus, 10MCr/4 = 2.5MCr per ton), and 1D6 qty of them.
 
The simple answer - they are not starship computers.
They are not, but they are within the price per ton range of starship computers, so fudging there only helps.

If I use TTB then it’s a Model/2 with some added console equipment.
If I use T5 then it’s two Model/2s.

Model/1 style computers end up sort of running a similar cost per ton. And the resolution is low, so it almost doesn’t matter beyond guessing a few tons per unit. 1970s style mainframes.

So, two to four tons.

Etc
 
Last edited:
Are they manufactured at local TL?
Depends. The TL of the computers being manufactured could vary ... especially if they're intended for export to lower TL worlds that will need to be able to support and maintain the computers using the local manufacturing/fabrication/tech base in those other systems.

Given the fact that in Traveller "global supply chains" takes on an interstellar meaning, it would make perfect sense for high TL systems to manufacture goods that are "sympatico" with low TL support and maintenance requirements.
 
“We just put ‘me together from imbalance shipments of electronics and scrap.” ?
 
“We just put ‘me together from imbalance shipments of electronics and scrap.” ?
Oh I can do one better, for a referee-selected world:

“We strip these out of all the starship wreckage in the outback.”
 
I've stored it in 32 byte records:

Label (15 chars + null char)
Base price (unsigned int, in hundreds of Cr)
Dice (1 byte)
Multiplier (1 byte) I could have packed these two into one byte.
Three purchase TC pairs (one byte code, one signed byte DM)
Three resale TC pairs (one byte code, one signed byte DM)

I could have stored six DMs with the trade code at a fixed index.
I decided it didn't matter either way, so I stored it more directly from the table.

I "adjusted" grain to be 7Dx6, instead of 8Dx5.

Similarly, I converted items 51-56 to tons, dividing the cost similarly.
 
Back
Top