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

[Robots] Three more questions

“Which, incidentally, is why the only reason why you would build pseudo-bios is to have sex with them. Otherwise, they are rubbish.”

I disagree,

Assassins, receptionists, auto docs that look more like people, valet, discreet bodyguard lab assistant. Mostly they would be for aesthetic reasons but not always for sex.

I do believe that a high tech pseudo-bio could be made MUCH lighter. Consider the materials. I don’t need an armored hull and heavy duty gravlifters. By TL-15 lightweight materials tech will be light years beyond steel frames as a modern computer factory is to a 16th century grist mill.
 
“Which, incidentally, is why the only reason why you would build pseudo-bios is to have sex with them. Otherwise, they are rubbish.”

I disagree,

Assassins, receptionists, auto docs that look more like people, valet, discreet bodyguard lab assistant. Mostly they would be for aesthetic reasons but not always for sex.

I do believe that a high tech pseudo-bio could be made MUCH lighter. Consider the materials. I don’t need an armored hull and heavy duty gravlifters. By TL-15 lightweight materials tech will be light years beyond steel frames as a modern computer factory is to a 16th century grist mill.
 
Even using steel frames, you wouldn't build the thing to be massively heavy. You might not get a super-powerful robot, but you could get something that doesn't weigh half a ton. :(
 
Even using steel frames, you wouldn't build the thing to be massively heavy. You might not get a super-powerful robot, but you could get something that doesn't weigh half a ton. :(
 
Originally posted by Fritz88:
Even using steel frames, you wouldn't build the thing to be massively heavy. You might not get a super-powerful robot, but you could get something that doesn't weigh half a ton. :(
And in the 57th century, they won't be using "steel".

They will be constructing robots/androids using much lighter metals and polymers.... which happens to be far stronger than 21st century steel.

In Book8, one of the things MWM forgot was that at higher tech levels, robots SHOULD weigh relatively less, because the advanced metals/polymers/components will be used.... making the bots far lighter, and far more sturdy.
 
Originally posted by Fritz88:
Even using steel frames, you wouldn't build the thing to be massively heavy. You might not get a super-powerful robot, but you could get something that doesn't weigh half a ton. :(
And in the 57th century, they won't be using "steel".

They will be constructing robots/androids using much lighter metals and polymers.... which happens to be far stronger than 21st century steel.

In Book8, one of the things MWM forgot was that at higher tech levels, robots SHOULD weigh relatively less, because the advanced metals/polymers/components will be used.... making the bots far lighter, and far more sturdy.
 
Well, that is taken into account (sorta) by the presence of SD and BSD. Of course, those are denser than steel, not less so......
 
Well, that is taken into account (sorta) by the presence of SD and BSD. Of course, those are denser than steel, not less so......
 
Ptah and Fritz88, are you still working on the Robot Design Sequence?

On a second note, I was thinking about what was wrong with LBB8 in the eyes of most people. And that was, IIRC:

1) Unnescery over-complexity (too many parameters, too many steps, little of which gets to a useful end result).

2) Too long URP (you could drop the number of appendages, head size, number of applications and a few other things you could easily get from the short dexcriptive paragpraph).

3) Bad locomotion/suspension rules (solved by Hyphen IIRC).

4) Large number of typos and ommissions (especially the TLs of several items; partially solved by the errata).

5) Components too big, heavy and expensive by RL-equivalent standards (quite easy to solve by creating a new table).

6) Brain design completely unrealistic, and thus unnerves players with IT background.

7) Robots are overly expensive, especially if you want to design something simple (such as the turrets seen in the Director's Cut version of Aliens).

Robot configuration (other than contourted and pseudo-biological) could be ignored - no game effect that warrants the cost/weight. Either Weight or Volume could be ignored. The one ignored could then be guesstimated from the one not ignored (similar to the way you compute volume out of weight with Striker aircraft). The power plant could be combined with the Transmission system, with the (comparatively miniature) power requirements of non-energy-weapon, non-locomotion systems ignored; robots without energy weapons or locomotion would have a "basic power requirement" listed as a "stationary" in the locomotion table.

So my suggested design sequence (weight-limited) will be:
1) Choose Chassis Size (price/max weight, also determines volume)
2) Choose Armor (in absorbed damage dice, as in my combat system)
3) Choose Locomotion (Wheels, Tracks, Legs, ACV, Rotor/Ducked-Fan, Jet, Grav)
4) Choose Energy Weapons (if any)
5) Drop in Power Plant (Battery, Fuel-Cell, Fusion or Internal Combustion) to satisfy the needs of the Locomotion and and Energy Weapons.
6) Add "components" (appendages, heads, non-energy weapons, sensors, devices); all have a Weight and a Price; Weight cannot exceed the Chassis' Max Weight.
7) Design the Brain (CPU+RAM+Storage? I'm at loss here, as IT science is a weak spot for me)
8) Add Software (start with OS (combine Logic and Command into a single program); then add applications).
 
Ptah and Fritz88, are you still working on the Robot Design Sequence?

On a second note, I was thinking about what was wrong with LBB8 in the eyes of most people. And that was, IIRC:

1) Unnescery over-complexity (too many parameters, too many steps, little of which gets to a useful end result).

2) Too long URP (you could drop the number of appendages, head size, number of applications and a few other things you could easily get from the short dexcriptive paragpraph).

3) Bad locomotion/suspension rules (solved by Hyphen IIRC).

4) Large number of typos and ommissions (especially the TLs of several items; partially solved by the errata).

5) Components too big, heavy and expensive by RL-equivalent standards (quite easy to solve by creating a new table).

6) Brain design completely unrealistic, and thus unnerves players with IT background.

7) Robots are overly expensive, especially if you want to design something simple (such as the turrets seen in the Director's Cut version of Aliens).

Robot configuration (other than contourted and pseudo-biological) could be ignored - no game effect that warrants the cost/weight. Either Weight or Volume could be ignored. The one ignored could then be guesstimated from the one not ignored (similar to the way you compute volume out of weight with Striker aircraft). The power plant could be combined with the Transmission system, with the (comparatively miniature) power requirements of non-energy-weapon, non-locomotion systems ignored; robots without energy weapons or locomotion would have a "basic power requirement" listed as a "stationary" in the locomotion table.

So my suggested design sequence (weight-limited) will be:
1) Choose Chassis Size (price/max weight, also determines volume)
2) Choose Armor (in absorbed damage dice, as in my combat system)
3) Choose Locomotion (Wheels, Tracks, Legs, ACV, Rotor/Ducked-Fan, Jet, Grav)
4) Choose Energy Weapons (if any)
5) Drop in Power Plant (Battery, Fuel-Cell, Fusion or Internal Combustion) to satisfy the needs of the Locomotion and and Energy Weapons.
6) Add "components" (appendages, heads, non-energy weapons, sensors, devices); all have a Weight and a Price; Weight cannot exceed the Chassis' Max Weight.
7) Design the Brain (CPU+RAM+Storage? I'm at loss here, as IT science is a weak spot for me)
8) Add Software (start with OS (combine Logic and Command into a single program); then add applications).
 
I finished off a component based design (but not volume constrained) proof of concept but didn't get to adding on the armor part. The idea being you pick the performance you want and the tables tell you the size of the compoenent you need for that performance vs. picking a volume, fitting things in and then calculating performance. In the end the robot/vehicle is described the same just designed a different way.

I found it a little trickier with armor if one armors the power source/drive train as one adds armor, you need to increase the power source to maintain same performance, but then it is bigger needs more armor, etc. One could probably set up an equation and take a limit. I also think it's doable with a few assumptions and/or letting perfomance degrade some. Anyway that's where I left it.
 
I finished off a component based design (but not volume constrained) proof of concept but didn't get to adding on the armor part. The idea being you pick the performance you want and the tables tell you the size of the compoenent you need for that performance vs. picking a volume, fitting things in and then calculating performance. In the end the robot/vehicle is described the same just designed a different way.

I found it a little trickier with armor if one armors the power source/drive train as one adds armor, you need to increase the power source to maintain same performance, but then it is bigger needs more armor, etc. One could probably set up an equation and take a limit. I also think it's doable with a few assumptions and/or letting perfomance degrade some. Anyway that's where I left it.
 
2-4601, I have put that on hold for a bit as RL intervenes (and some T5 stuff). It is still something which I will work on, however.

Ptah, if you require the uparmor before choosing the power source, your problem is solved. There isn't a single one of these design sequences that isn't done iteratively (if done properly).
 
2-4601, I have put that on hold for a bit as RL intervenes (and some T5 stuff). It is still something which I will work on, however.

Ptah, if you require the uparmor before choosing the power source, your problem is solved. There isn't a single one of these design sequences that isn't done iteratively (if done properly).
 
Originally posted by Fritz88:
2-4601, I have put that on hold for a bit as RL intervenes (and some T5 stuff). It is still something which I will work on, however.

Ptah, if you require the uparmor before choosing the power source, your problem is solved. There isn't a single one of these design sequences that isn't done iteratively (if done properly).
Fritz, I see what you are saying (about the RL stuff as well). If no armor is added to the power source volume (but everything else), no iteration required to get the performance you want. I agree though, interation is fundamentally unavoidable. It may better to e-mail it to you. Anyway, actually still at work...but about to head home.

E 2-4601, thanks for the ping on this, maybe I will pick it back up here.
 
Originally posted by Fritz88:
2-4601, I have put that on hold for a bit as RL intervenes (and some T5 stuff). It is still something which I will work on, however.

Ptah, if you require the uparmor before choosing the power source, your problem is solved. There isn't a single one of these design sequences that isn't done iteratively (if done properly).
Fritz, I see what you are saying (about the RL stuff as well). If no armor is added to the power source volume (but everything else), no iteration required to get the performance you want. I agree though, interation is fundamentally unavoidable. It may better to e-mail it to you. Anyway, actually still at work...but about to head home.

E 2-4601, thanks for the ping on this, maybe I will pick it back up here.
 
Back
Top