CT+?

[Jame]

My other thing, now that F-T mentions it, is the cost of programs. Personally, I find they're too expensive. Now, maybe a suite of programs should be in the hundreds of thousands of Cr, but that would include not only library data (least expensive) to mechanical/engineering assistance programs (moderately expensive, along with gunnery programs) to astrogation programs and ship schematics (not only the most expensive, but the most complex).

Though part of the tonnage issue could be taken up by access space, though this would be the bulk of it aside from sensors.

 

[Jame]

My other thing, now that F-T mentions it, is the cost of programs. Personally, I find they're too expensive. Now, maybe a suite of programs should be in the hundreds of thousands of Cr, but that would include not only library data (least expensive) to mechanical/engineering assistance programs (moderately expensive, along with gunnery programs) to astrogation programs and ship schematics (not only the most expensive, but the most complex).

Though part of the tonnage issue could be taken up by access space, though this would be the bulk of it aside from sensors.

 

[far-trader]

Yep, two ways I adjusted the computer programming costs imtu follow.

The first way was to allow a larger (I'd say fairer) programming budget. I figured the cost of the computer is the value of the programming. This let's you outfit small computers with the needed programs and really lets the military with the big computers have just about any programming they want.

The second way was to just divide the costs of all the programs by 10.

But both those methods were too generous imo and experience so I finally settled on just a small change. I count bis model computers as the next higher level for programming budgets. So the model/1bis gets MCr2 for programs while it's basic model/1 cousin only gets MCr1.

It's really not that hard to make the programming package budget work at cannon levels, I just think that paying more for the computer should count for something on the programming side too.

One thing you'll have to do imo is change the costs of the preprogrammed single use jump data since many small traders won't have a Generate program in the basic package. Again a simple division by 10 works well (Cr1,000 per jump number). In mtu these have a limited window for use, you pick the time and destination of your jump out and the SPA programs your jump. If you miss the window you buy a new program, or risk a misjump. It's about a 12hour window centered on your chosen time and the nearest 100d point. Miss ing the window by more than 12hours or 10d adds 1 to the chance of misjump (each if you miss both), along with any other factors (such as being short of 100d). The program will not function at all at twice the window. After 24hours or more than 20d from the jump point the program will not engage.

 

[far-trader]

Yep, two ways I adjusted the computer programming costs imtu follow.

The first way was to allow a larger (I'd say fairer) programming budget. I figured the cost of the computer is the value of the programming. This let's you outfit small computers with the needed programs and really lets the military with the big computers have just about any programming they want.

The second way was to just divide the costs of all the programs by 10.

But both those methods were too generous imo and experience so I finally settled on just a small change. I count bis model computers as the next higher level for programming budgets. So the model/1bis gets MCr2 for programs while it's basic model/1 cousin only gets MCr1.

It's really not that hard to make the programming package budget work at cannon levels, I just think that paying more for the computer should count for something on the programming side too.

One thing you'll have to do imo is change the costs of the preprogrammed single use jump data since many small traders won't have a Generate program in the basic package. Again a simple division by 10 works well (Cr1,000 per jump number). In mtu these have a limited window for use, you pick the time and destination of your jump out and the SPA programs your jump. If you miss the window you buy a new program, or risk a misjump. It's about a 12hour window centered on your chosen time and the nearest 100d point. Miss ing the window by more than 12hours or 10d adds 1 to the chance of misjump (each if you miss both), along with any other factors (such as being short of 100d). The program will not function at all at twice the window. After 24hours or more than 20d from the jump point the program will not engage.

 

[mike wightman]

Originally posted by far-trader:
One thing you'll have to do imo is change the costs of the preprogrammed single use jump data since many small traders won't have a Generate program in the basic package. Again a simple division by 10 works well (Cr1,000 per jump number). In mtu these have a limited window for use, you pick the time and destination of your jump out and the SPA programs your jump. If you miss the window you buy a new program, or risk a misjump. It's about a 12hour window centered on your chosen time and the nearest 100d point. Miss ing the window by more than 12hours or 10d adds 1 to the chance of misjump (each if you miss both), along with any other factors (such as being short of 100d). The program will not function at all at twice the window. After 24hours or more than 20d from the jump point the program will not engage.

They are very good ideas Dan, I especially like this one [add to hard drive}

 

[mike wightman]

Originally posted by far-trader:
One thing you'll have to do imo is change the costs of the preprogrammed single use jump data since many small traders won't have a Generate program in the basic package. Again a simple division by 10 works well (Cr1,000 per jump number). In mtu these have a limited window for use, you pick the time and destination of your jump out and the SPA programs your jump. If you miss the window you buy a new program, or risk a misjump. It's about a 12hour window centered on your chosen time and the nearest 100d point. Miss ing the window by more than 12hours or 10d adds 1 to the chance of misjump (each if you miss both), along with any other factors (such as being short of 100d). The program will not function at all at twice the window. After 24hours or more than 20d from the jump point the program will not engage.

They are very good ideas Dan, I especially like this one [add to hard drive}

 

[Uncle Bob]

Alright, I'll try again.

The Book 2 rules are BROKEN. Until we fix them computer literate gamers will continue to discount Traveller as serious SF. That may only be 5% of gamers, but it is easily 25% of our demographic.

They make sense as game rules in the abstract, and show a good understanding of where data processing was in 1970. The microchip revolution knocked that all in the head, making the jump from TL6 to 7 several orders of magnitude. And TL7 to 8 at least two more. So if a 1 ton TL6 computer can run 1 program a 1 ton TL7 computer can run a at least a hundred (for the same cost) and TL8 ten thousand at least. Which if a 1 space program is judged to be a real-space navigation program is entirely reasonable.

Beyond that we are getting close to speed-of-light limitations on computing power, so future improvement in computing power, whatever the technology used, will require that the gates be closer together and thus the whole computer smaller.

The extra programing power means you can get away with programing bloat. Which means you can add extra, unnecessary capabilities to the program. One example would by the "year 2K" disasters that didn't happen. Most TL6 programs used only two digits to identify years (55, 68, 74, etc) to save space in the data registers, and were unable to tell the difference between 00 (1900) and 00 (2000). In real world there were few problems because TL7 progrms were mostly written to store four digit numbers, because they ran on computers with more speed and memory. The older programs were easily rewritten because they now ran on more powerful machines.

And I haven't touched on how object oriented languages, modular design, and database use have changed programing. And computer intrusion has divided into hackers and script kiddies, white hats and black hats,

To make an analogy, it would be as if Traveller guns never made the jump to metallic cartridges at TL4. So TL5 small arms were 10 shot cap 'n ball revolvers and machine guns were heavy Gatlings loading paper cartridges with seperate caps. And higher TL used better propellants and lighter metals, but never quite got the hang of an all-in-one cartridge. Meanwhile, players who are gun nuts or military veterans wonder where their auto pistols and assault rifles are.

In brief,
At TL7+ computers, up to the limits of the technology, become trivial compared to the 20+ ton bridge slice. At higher TL the more powerful computers will not be bigger.

Programs at TL8 + are so sophisticated they are written by teams of programmers over months. And sufficiently generalized (to amortize over a large market) that they can work for a number of people in different places with only a change in a datafile. At higher TL computers will program themselves with limited human guidance.

Keeping the computer percentage and making it sensor enhancement keeps Book5 combat and the canon designs. The other proposals either do not address the underlying concerns or are band-aids. The GT and T4 fixes risk being out of date in a very few years, if they aren't already.

I admit I think a complete rewrite of the rules, trivialising computers and applying weight and cost penalties for military and scout sensors would be preferable, but that would break the cannon designs and still break Book2and Mayday combat.

 

[Uncle Bob]

Alright, I'll try again.

The Book 2 rules are BROKEN. Until we fix them computer literate gamers will continue to discount Traveller as serious SF. That may only be 5% of gamers, but it is easily 25% of our demographic.

They make sense as game rules in the abstract, and show a good understanding of where data processing was in 1970. The microchip revolution knocked that all in the head, making the jump from TL6 to 7 several orders of magnitude. And TL7 to 8 at least two more. So if a 1 ton TL6 computer can run 1 program a 1 ton TL7 computer can run a at least a hundred (for the same cost) and TL8 ten thousand at least. Which if a 1 space program is judged to be a real-space navigation program is entirely reasonable.

Beyond that we are getting close to speed-of-light limitations on computing power, so future improvement in computing power, whatever the technology used, will require that the gates be closer together and thus the whole computer smaller.

The extra programing power means you can get away with programing bloat. Which means you can add extra, unnecessary capabilities to the program. One example would by the "year 2K" disasters that didn't happen. Most TL6 programs used only two digits to identify years (55, 68, 74, etc) to save space in the data registers, and were unable to tell the difference between 00 (1900) and 00 (2000). In real world there were few problems because TL7 progrms were mostly written to store four digit numbers, because they ran on computers with more speed and memory. The older programs were easily rewritten because they now ran on more powerful machines.

And I haven't touched on how object oriented languages, modular design, and database use have changed programing. And computer intrusion has divided into hackers and script kiddies, white hats and black hats,

To make an analogy, it would be as if Traveller guns never made the jump to metallic cartridges at TL4. So TL5 small arms were 10 shot cap 'n ball revolvers and machine guns were heavy Gatlings loading paper cartridges with seperate caps. And higher TL used better propellants and lighter metals, but never quite got the hang of an all-in-one cartridge. Meanwhile, players who are gun nuts or military veterans wonder where their auto pistols and assault rifles are.

In brief,
At TL7+ computers, up to the limits of the technology, become trivial compared to the 20+ ton bridge slice. At higher TL the more powerful computers will not be bigger.

Programs at TL8 + are so sophisticated they are written by teams of programmers over months. And sufficiently generalized (to amortize over a large market) that they can work for a number of people in different places with only a change in a datafile. At higher TL computers will program themselves with limited human guidance.

Keeping the computer percentage and making it sensor enhancement keeps Book5 combat and the canon designs. The other proposals either do not address the underlying concerns or are band-aids. The GT and T4 fixes risk being out of date in a very few years, if they aren't already.

I admit I think a complete rewrite of the rules, trivialising computers and applying weight and cost penalties for military and scout sensors would be preferable, but that would break the cannon designs and still break Book2and Mayday combat.

 

[mike wightman]

CT computer tonnage = sensors.

Computer tonnage = negligable

Program complexity/spaces varies by TL.

You use the same CT computer table, you just split it up differently

 

[mike wightman]

CT computer tonnage = sensors.

Computer tonnage = negligable

Program complexity/spaces varies by TL.

You use the same CT computer table, you just split it up differently

 

[Random Goblin]

Agreed.

 

[Random Goblin]

Agreed.

 

[robject]

Bob, I'd rather agree with Dan and Mike than try to re-work Book 2 computer rules.

My main problem is that for each computer-rule reformer, there is a different solution. Thus there is no hint of consensus among house-rules. That leaves Traveller rules. If you don't like Book 2, then I would suggest the more realistic abstraction from T4's Central Supply Catalog.

Otherwise, we're spinning our wheels. There are a dozen people who can say "just do it my way".

 

[robject]

Bob, I'd rather agree with Dan and Mike than try to re-work Book 2 computer rules.

My main problem is that for each computer-rule reformer, there is a different solution. Thus there is no hint of consensus among house-rules. That leaves Traveller rules. If you don't like Book 2, then I would suggest the more realistic abstraction from T4's Central Supply Catalog.

Otherwise, we're spinning our wheels. There are a dozen people who can say "just do it my way".

 

[robject]

As for the computer program allotment. I see your points for a larger allowance, but in the words of the inimitable Mr. Lundberg, "I'm going to have to go ahead and disagree with you on that".

Actually, I don't disagree, but I'd rather kludge a solution by buying a backup computer. Another megacredit isn't going to hurt anyone, and that way you can have two programs running at the same time (yowza!)

Do you suppose there ought to be a program for detecting gas giants in nearby, uncharted systems? How big would this program be?

 

[robject]

As for the computer program allotment. I see your points for a larger allowance, but in the words of the inimitable Mr. Lundberg, "I'm going to have to go ahead and disagree with you on that".

Actually, I don't disagree, but I'd rather kludge a solution by buying a backup computer. Another megacredit isn't going to hurt anyone, and that way you can have two programs running at the same time (yowza!)

Do you suppose there ought to be a program for detecting gas giants in nearby, uncharted systems? How big would this program be?

 

[Jame]

T4's rules seem useful to me - maybe we should try to convince MWM to use a revision?

 

[Jame]

T4's rules seem useful to me - maybe we should try to convince MWM to use a revision?

 

[robject]

Emphatically Yes. I like the T4 computer rules, and they seem to accomodate Book-2 style use while feeling more modern. CT+ can adopt and adapt them handily.

I think T5 should inherit T4's computer rules.

 

[robject]

Emphatically Yes. I like the T4 computer rules, and they seem to accomodate Book-2 style use while feeling more modern. CT+ can adopt and adapt them handily.

I think T5 should inherit T4's computer rules.