Frieght charges IMTU
- Thread starter Proneutron
- Start date
Decent analysis there.
Details can be argued, but it's a good overview of the issues driving cost and availability.
If you're stuck with flat-rate per-Jump rates, that's a useful workaround.
I still think that if the cargo rules were modeled on economics rather than a game artifact, rates would be based on "cheapest available shipper over distance X" with a time-sensitivity premium that increases by Jump distance*, for a proportion of available cargo that decreases by Jump distance.
*or more precisely, by time savings. Over a 6 Pc distance, a shipper that can deliver in 1 week (J-6) can charge more than one that takes 2 weeks (J-3), who can charge more than one that takes 3 weeks (J-2). There will be a lot of cargo willing to pay the 3-week rate, some that will pay the 2-week rate, and a very small amount at the 1-week rate. Non-cryo passengers are more likely than shippers to pay a time-sensitivity premium.
kilemall
SOC-14 5K
No question, but to what extent do you want to work up rules for all that, both the background hauling of 80-90% of the tonnage by the 'big boys' and what may increase or depress shipping prices at any given moment?
It's the kind of question that makes sense if you are doing some sort of Oberlindes Lines campaign, and otherwise it's going to be adventure hooks that are ref managed anyway.
This patron is hot to charter to this cargo get off the rock fast, Amber Zone? 4x the price, or boy the passenger in Stateroom 4 sure is antsy about our arrival times.
I just figured going this way gets that whole main trade route/cutting costs to the bone/desirable velocity means more business would flow to the faster ships/gives you a logical framework for small ship universe design for varying cargo runs without having to run a Gurps Trade subsector sim.
I still think it's worth figuring out your subsector, and what weird mix of tech happens and why some major interstellars might get hot about the grav vehicle market when they are shipping in the stuff from 20 parsecs away. If nothing else, where the guns and missiles are coming from and who might be interested in buying up or interdicting all that. Mix in planets or megacorps/nobles or equivalent with their own commercial and power agenda and you have a hotbed of adventure generation.
Straybow
SOC-14 1K
That's why I posited a professional group formed to write the program (possibly generations ago), and a large group of independent (assuming megacorps are happy with Generate pricing little guys out of the market) ship owners forming a risk retention group (allowing them to share testing costs and such, again, possibly taking place generations ago).
It circumvents the "home written" situation and the "where did this cost come from?" situation of the RAW price.
Ah, yes, the bug that doesn't appear when tested, but only appears when the plot requires it. And it's such a huge bug that it will appear in 8% of cases? No, the rule is preposterous.coliver988 said:I would go with the open source software in this case being the same as a home written piece of software. A 5.5% probability (assuming I read the table correctly) each time you jump. Eventually it will catch up with you.
and, though the rules never say anything about it, there have been some discussions on insurance for ships. If YTU has insurance, what sort of premium would homebrew cost? and another one on rules and regulations with software: would your ship even be permitted to have non-official software, assuming it is checked for inspections or anything?
There are considerations of this beyond the mere technical aspects
edit: the 5.5% is the chance of rolling an 11, with a 2.77% of a 12, so 8% or so. dang - need to go back to the BBB as chapter 1 has ALL the odds! anyway, I am certain I will be corrected shortly
Consider that J1 requires Model/1, which was originally cited as being possible at TL6 (hand calculator technology, essentially). That means you or I could probably write that program in BASIC.
Straybow
SOC-14 1K
Who says you can't charge for open source code? It depends on how the laws are structured. It is entirely possible for something to be both openly revealed and fully proprietary... that is the definition of a patent.
Now, normally the patent is time-limited. But that's where the risk retention mechanism comes in. You have to be willing to assume the risk (which has been minimalized for generations, just as the Official MCr0.8 Generate Program was written and certified who knows how many centuries ago), and that comes with the cost of joining the group and pays for the program.
If caught using the program without being part of the group you could be sued by the group and end up paying back royalties established in the risk retention group incorporation, fines established in the patent/risk retention laws, and the group's legal expenses when you lose (almost guaranteed). The group could subpeona records of ships suspected of operating without license. The group could pay for a staff of private investigators keeping an eye out for likely violators. The staff is as large as the fees and fines generated will pay for, averaged over time and the demesne involved.
Another way to get Generate cheaper than the list price would be aftermarket. Suppose a ship is salvaged, and it has an intact Generate program. Your GM doesn't let you get full price for anything, which means it sells at a discount. After a while, in a milieu with thousands of worlds and possibly a billion starships, there would be a million ships a year being broken up, bankrupted, repossessed, etc. under conditions where simple transfer under the same ownership doesn't apply. From each of these, legally owned and saleable programs (not just Generate, but all of them) could be widely available.
The market for new programs would likely adjust to compete.
Straybow
SOC-14 1K
Ah, but now you run into the whole what-is-a-ton problem. The pricing would make sense for mass tons, in most cases, but the game is structured in dTons, which can be as high as 15 mass tons or even 310 mass tons* according to various versions of Trav. It is a primary failure of RAW, and MWM has refused to rectify it. (Problem? What problem?)
* 14 m³ of solid Osmium.
kilemall
SOC-14 5K
It's only a problem if you INSIST on it being a problem.
I'm familiar with the whole issue, having got into providing lists with cargo type density, etc., so hauling heavy ore means maybe using 5% of a dTon, etc.
Since I'm not interested in adding up the weight of the ship even empty and calculating vector based on that vs. full loads, I go with 'safety limits' on having too heavy cargo that can shift or break loose and do damage or strain the local cargo bay supporting hull structure or container capacity to handle, and not worry about the specific total weight.
That way the players have to worry about the loadmaster handling of how things get loaded into the cargo bay, but we aren't fretting over being 12000 kg over limit and not being able to lift off at all.
If it's play value vs. real world engineering, I roll with play/refsplaining.
True, but having written software, tested, and gone through QA, bugs do happen in the real world (no software survives contact with the user). Admittedly that is software for people, not a simple calculation (define simple) that really only has 2 points to consider: here and there (the non-simple part is the time, vectors, etc). So while I can see your point, I'll stick with the game rules as it is the game I am playing.
But I do like your idea about the software on older ships being available cheaper (fully refurbished!
). Unless (and this would be entirely ref-driven) that software has to be customized for that particular ship. but then that implies any changes to a ship require software changes to reflect that, and that is a rabbit hole I do not want to fall into.
Last edited:
Proneutron
SOC-13
In Trav, ship tonnage and cargo tonnage has pretty much always been 13.5 to 14 cubic meters of volume to the ton.. Not that complex
Last edited:
kilemall
SOC-14 5K
In terms of the Generate program, I figured that by the first 100 years of jump drive there WOULD be freeware/open source versions floating around. It would be a well understood software logic that Navigators/Astrogators HAVE to study as part of their skill.
Two factors though that have to be accounted for.
#1, the program will need to change along with changes in computers, control systems and jump drives. The core logic may be the same, but it has to be maintained at the API level at least.
That alone can introduce bugs, and most any QA work that makes Generate space-ready is going to have to go even further then avionic QA does today. That means expense, and people that want to be compensated and profit by that requirement. Work from the freeware version? Make changes to the ship, and no service support, it's bug rolling time.
#2, I assume that there is more then just the program logic, there is also an astrogation database the Generate program is working from. Once explored, the gravitically important objects like stars, planets, moons and asteroids should be mapped out and move through the system like clockwork, making an opensource Generate database workable for 100s of years. However, surprise little rocks, comets that had not been mapped before, and potentially underlying jumpspace/gravitic fields may be changing and eventually cause error.
All those Scout ships are out there doing the space equivalent of oceanographic mapping, and you need updates from their work to get accurate Generates. That implies a service contract, for DECADES, so that explains the money up front that then keeps the ship in updates during it's service life.
Two factors though that have to be accounted for.
#1, the program will need to change along with changes in computers, control systems and jump drives. The core logic may be the same, but it has to be maintained at the API level at least.
That alone can introduce bugs, and most any QA work that makes Generate space-ready is going to have to go even further then avionic QA does today. That means expense, and people that want to be compensated and profit by that requirement. Work from the freeware version? Make changes to the ship, and no service support, it's bug rolling time.
#2, I assume that there is more then just the program logic, there is also an astrogation database the Generate program is working from. Once explored, the gravitically important objects like stars, planets, moons and asteroids should be mapped out and move through the system like clockwork, making an opensource Generate database workable for 100s of years. However, surprise little rocks, comets that had not been mapped before, and potentially underlying jumpspace/gravitic fields may be changing and eventually cause error.
All those Scout ships are out there doing the space equivalent of oceanographic mapping, and you need updates from their work to get accurate Generates. That implies a service contract, for DECADES, so that explains the money up front that then keeps the ship in updates during it's service life.
kilemall
SOC-14 5K
I think he's referring to the continuing conflation between a ton meaning the dTon and a ton meaning 1000kg, the weight of hydrogen in that much volume of space. Virtually ANYTHING you load on the ship is going to be more dense then hydrogen, and so the cargo ton as tossed off in many merchant or adventure writings bothers people trying to figure out the economics.
Straybow
SOC-14 1K
Except Model/1 hasn't changed since TL5 (TL6 for 1 bis), and Model/2 hasn't changed since TL7 (TL8 2 bis), Model/3 since TL9, Model/4 since TL10, and so on. If you found a mothballed starship from 1I, thousand of years ago, it would still be up to spec by canon.
Any database of astrogation hazards would have to be public domain. A newly discovered rock or iceball would immediately be registered and updated through X-boat network. It would be criminally negligent to hide navigation hazards behind a paywall.
Proneutron
SOC-13
In the Trav rules these have never been mixed up. It would have to be people who don't understand the concept of displacement tonnage conflating them in their own head.
Drakon
SOC-14 1K
Probably handled the same way the FAA handles changes to their charts and directories. Possibly handled in the standard x-boat traffic package.
The FAA reprints their charts and directories on a quarterly basis and issues notices to airmen when needed to fill gaps between updates
Side question: What would be in the hypothetical "Standard Package" that an X-boat or courier transmits while it transits a system? Traffic details and astrogation hazards, obviously, but what else? Stock prices, standard news packages, TAS database updates...
mike wightman
SOC-14 10K
They were mixed up in CT.
In 77 edition the ship construction rules didn't define a displacement ton, while there were references to tons and kg in a few places places - fuel use and the trade rules. The authors have even said they originally intended 1 ton in ship construction to be 1000kg.
The trade rules equivalence of 1 ton being 1000kg remain in 81 revision and The Traveller Book and starter edition.
Straybow
SOC-14 1K
No, they've been conflated from the original 1977 LBBs. Ships are designed using dT, but then spec cargoes are priced at a level that would be much closer to 1000 kg tons, but often falls short of that.
My favorite example of LBB2 spec cargo is "Firearms" at kCr 30. So, a 1000 kg lot would be about how many? Let's try the heaviest one, the Automatic Rifle at 5 kg. Let's assume an equal mass in packaging (a wooden crate, dense foam packing), so that 1000 kg is 100 ARs. The AR costs kCr 1, so the 1000 kg lot would be kCr 100 at retail. If I buy at kCr 30 I would need to roll a 14 on resale to even come close to the retail price at kCr 90, while a 15 would garner kCr 120 (a small premium on the retail price).
So, the spec cargo pricing is much too low for a 1000 kg lot, and an order of magnitude too low for a dT which might be 10 tons of arbitrary size. For that it would be only kCr 3 per ton. Am I buying a spec lot of supersoakers?
If we go with shotguns instead of ARs, the price would be for 200 at retail, and they would mass 750 kg. Assuming they're packed several in a crate we'll agree to the 1000 kg with packaging. But now the rules say we can only put 1 lot in a 1 dT space. How much space would 200 shotguns take up?
The shotgun is 1 m long. Let's allow 25 cm on either end to make a round 1.5 m. It doesn't say how wide, but it can't be even 5 cm or the average hand would have difficulty gripping it. Let's say the packing frame puts them at 12.5 cm center to center, and 12.5 cm to the side of the crate, or actually two rows facing in opposite directions (each staggered toward one side) for 10 in a crate. They're probably not more than 20 cm from the lower tip of the stock to the top of the sights. We'll handwave a half meter depth. Our crate is then 1.5 m x 0.75 m x 0.5 m. We can fit 1 x 2 in the std 1.5 m tile, two tiles per dT. If we stack the crates 2.5 m high (we're allowed 3 m) that's 20 crates.
With a bit of work, we've managed to make this one item fit both 1000 kg and 1 dT, and the list price of kCr 30. But really they could by packaged much tighter and probably only take up ½ dT. No other firearms will come as close to matching mass and volume and price at the same time.
Another example is Air/Raft. It lists for MCr 6, which is the price in the ship construction section. But an A/R is 4 dT, not 1 dT nor 1000 kg. OK, let's say that's an exception that we can handwave away as something anybody should figure out without help.
Likewise the spec ATV for MCr 3, same price as equipment list, except it takes 10 dT. We know the size so we say it is not an error.
What about Computers at MCr 10? Well, the 1 dT starship computers are at most MCr 5. There is no starship model that costs MCr 10, but models that take 2 dT are either MCr 9 or 12. OK, maybe we "close enough" and the lot takes 2 dT instead of 1 dT. Maybe they are Model/1 bis but when not installed they only take up ½ dT. Or maybe it's an entirely different type of computer and it does take 1 dT and cost MCr 10.
It turns out the 50s in the spec list make make sense if you acknowledge that they are not 1 ton (mass or dT) items or fudge a bit.
Then in the 60s it again doesn't fit mass ton or dT for the one item we can check. In LBB3, a Vacc Suit is kCr 10 and 10 kg. The spec item is kCr 400. So that's only 40 of them, with lots of packing materials for 1000 kg (not a close fit, just a "whatever" fit). But not 1 dT, again probably less than ½ dT in reasonable packaging.
Proneutron
SOC-13
What!? you can't use trade prices to change from displacement of the cargo to mass. Otherwise you cannot determine if you are filling your hold
mike wightman
SOC-14 10K
You are missing the point.
The trade rules make it clear that a ship ton is 1000kg.
Which is contrary to your statement that there was no confusion in the rules.
