Robot (Book 8) rule questions
- Thread starter Golan2072
- Start date
Fritz_Brown
Super Moderator
I have now reached Hyphen's site, and printed his robot fixes to examine. (Yeah, I'm back at this robot thing....) Robots should be a wonderful thing for gearheading Travellers, but instead, they seem to be "harder than it has to be" - the unofficial US Army motto, BTW.
Fritz_Brown
Super Moderator
I have now reached Hyphen's site, and printed his robot fixes to examine. (Yeah, I'm back at this robot thing....) Robots should be a wonderful thing for gearheading Travellers, but instead, they seem to be "harder than it has to be" - the unofficial US Army motto, BTW.
A new system should be devised for CT robots, that's for sure - and unlike vehicles, they weren't even adressed in Striker (the number one gearheading resource for CT). While ship computer cumbersomeness could be circumvented by claiming that the "computer" tonnage/price is actually 95% sensors, robots are another issue.
What I might try to work at (help welcome) is a simple robotics "component" system, ala LBB2 (or Shadowrun's 3rd edition's vehicle design system), to adress robots in a generic fasion and produce a user-readable design rather than the URP.
What I might try to work at (help welcome) is a simple robotics "component" system, ala LBB2 (or Shadowrun's 3rd edition's vehicle design system), to adress robots in a generic fasion and produce a user-readable design rather than the URP.
A new system should be devised for CT robots, that's for sure - and unlike vehicles, they weren't even adressed in Striker (the number one gearheading resource for CT). While ship computer cumbersomeness could be circumvented by claiming that the "computer" tonnage/price is actually 95% sensors, robots are another issue.
What I might try to work at (help welcome) is a simple robotics "component" system, ala LBB2 (or Shadowrun's 3rd edition's vehicle design system), to adress robots in a generic fasion and produce a user-readable design rather than the URP.
What I might try to work at (help welcome) is a simple robotics "component" system, ala LBB2 (or Shadowrun's 3rd edition's vehicle design system), to adress robots in a generic fasion and produce a user-readable design rather than the URP.
Fritz_Brown
Super Moderator
Well, except for the transmission/suspension thing, most all of LBB8 is modular. How big do you want it, and will it fit in there? Well, except for all the things that you don't have any idea on their size.... 
(And, the bit about multiplying entire weight and price for pseudo-bio and up-armoring.)
The basic problem with the URP is its length. Otherwise, its just like all the other "digit strings" in Traveller.
One other item, though, that could use some revision would be the applications. I don't mind the "size" and cost factors, except they should have two "size" factors: CPU and Storage. Why? Because things like Mechanical require knowledge and skill. The skill part is how much CPU space is required, and the knowledge part is how much storage space is required. Think of a game... The game loads a certain amount of data - the AI, drivers, some basic rendering stuff - then waits for you to begin a game before it loads the specific info - a particular map, precise enemy OB, etc. So, the Mechanical application is running, taking 1 space (per skill level) in the CPU, but taking another 1 in storage (it takes 2 CPU to run in LBB8). If it gets loaded out of CPU because its no longer needed, then it would take the full 2 in storage. (Though we don't really delete the program off the drive when we load it - that would be truly scary in a Microsoft world!)
(And, the bit about multiplying entire weight and price for pseudo-bio and up-armoring.)The basic problem with the URP is its length. Otherwise, its just like all the other "digit strings" in Traveller.
One other item, though, that could use some revision would be the applications. I don't mind the "size" and cost factors, except they should have two "size" factors: CPU and Storage. Why? Because things like Mechanical require knowledge and skill. The skill part is how much CPU space is required, and the knowledge part is how much storage space is required. Think of a game... The game loads a certain amount of data - the AI, drivers, some basic rendering stuff - then waits for you to begin a game before it loads the specific info - a particular map, precise enemy OB, etc. So, the Mechanical application is running, taking 1 space (per skill level) in the CPU, but taking another 1 in storage (it takes 2 CPU to run in LBB8). If it gets loaded out of CPU because its no longer needed, then it would take the full 2 in storage. (Though we don't really delete the program off the drive when we load it - that would be truly scary in a Microsoft world!)
Fritz_Brown
Super Moderator
Well, except for the transmission/suspension thing, most all of LBB8 is modular. How big do you want it, and will it fit in there? Well, except for all the things that you don't have any idea on their size.... (And, the bit about multiplying entire weight and price for pseudo-bio and up-armoring.)
The basic problem with the URP is its length. Otherwise, its just like all the other "digit strings" in Traveller.
One other item, though, that could use some revision would be the applications. I don't mind the "size" and cost factors, except they should have two "size" factors: CPU and Storage. Why? Because things like Mechanical require knowledge and skill. The skill part is how much CPU space is required, and the knowledge part is how much storage space is required. Think of a game... The game loads a certain amount of data - the AI, drivers, some basic rendering stuff - then waits for you to begin a game before it loads the specific info - a particular map, precise enemy OB, etc. So, the Mechanical application is running, taking 1 space (per skill level) in the CPU, but taking another 1 in storage (it takes 2 CPU to run in LBB8). If it gets loaded out of CPU because its no longer needed, then it would take the full 2 in storage. (Though we don't really delete the program off the drive when we load it - that would be truly scary in a Microsoft world!)
(And, the bit about multiplying entire weight and price for pseudo-bio and up-armoring.)The basic problem with the URP is its length. Otherwise, its just like all the other "digit strings" in Traveller.
One other item, though, that could use some revision would be the applications. I don't mind the "size" and cost factors, except they should have two "size" factors: CPU and Storage. Why? Because things like Mechanical require knowledge and skill. The skill part is how much CPU space is required, and the knowledge part is how much storage space is required. Think of a game... The game loads a certain amount of data - the AI, drivers, some basic rendering stuff - then waits for you to begin a game before it loads the specific info - a particular map, precise enemy OB, etc. So, the Mechanical application is running, taking 1 space (per skill level) in the CPU, but taking another 1 in storage (it takes 2 CPU to run in LBB8). If it gets loaded out of CPU because its no longer needed, then it would take the full 2 in storage. (Though we don't really delete the program off the drive when we load it - that would be truly scary in a Microsoft world!)
