it seems silly that there aren't rules for creating the programs which run drones, robots, and other rigger stuff. ergo:

creating an autonav is equivalent to writing a program with a rating equal to (autonav rating)*2. the multiplier for autonav programs is 10. creating the program plan requires the Autonav Program Design knowledge skill.

creating the program to run a drone is equivalent to writing a program with a rating equal to (drone rating)^2. the multiplier for drone programs is 20. creating the program plan requires the Drone Program Design knowledge skill.

creating the program to run a robot is equivalent to writing a program with a rating equal to (robot rating)^4. robot options add (option rating)^2 to the effective program rating for programming and size purposes. creating the program requires the Robot Program Design knowledge skill.

I really question whether it is feasible for an individual to do this sort of thing.

~J

As opposed to programming frames and agents? They're basically the autonavs and drones of the Matrix.

By his rules, noone can program them anyway. Rating 3 drone pilots require 9 computer skill, 4 takes 16! and 5 takes 25! This where a skill of 8 is supposed to be world class. Robots are only codable at rating 1, where they are still only diff 1, but a rating 2 requires 16 skill.

Ok then, since you point that out I'll say that maybe his rules do make sense.

Frames and Agents have all of their information in a format that is already understandable by them. They never have to deal with the difference between a muddy road and a six-foot-deep pool with a thin skim of mud on top of it.

~J

i know what the book says about skill ratings, but in a game where any starting character can start off with several specializations at 7, 8 certainly isn't world-class.

moonwolf has a point, though. drones, at least, shouldn't be that hard. how about this:

autosofts are equal to (rating)*2.

drone pilots are (rating)*3.

robots are (rating)*4.

more doable? that still puts the high-end robots pretty well out of reach--but, i figure most of those came from the Arco, anyway.

I say that yes, drones really should be that hard. A rating 3 Pilot program will direct a vehicle with the same level of proficiency as an average-skilled person, and will be able to interpret stimuli with the same efficiency as an average-intelligence person. IMO, they're only as cheap as they are because a single program can be used across entire production lines; I do not think that it should be anywhere near within the ability of a single user to program anything higher than Rating 1 Pilot, which is included free anyway.

~J

yeah, but if drones--which are basically S-Ks in a box--are that cheap, why isn't every other program on the market also cheap?

I disagree. Today, we're a lot closer to having vehicles that can make intelligent decisions and drive themselves than we are to programs that can hack the internet on their own with any level of human competence. That seems to suggestion that it is quite a bit easier to do the former, especially considering that there's a lot more people who can program the latter over the former.

Frames and agents are every bit as "intelligent" as their drone counterparts at the same level. I don't see any reason for your suggestion that the Matrix is easier to maneuver in for a program than a highway is. Both are equally unpredictable, and both require the same type of output to control their actions (one just talks to software while the other talks to the hardware that controls the vehicle; a 'turn right' direction is still the same regardless).

Funny, the new vacuum my grandmother bought as a toy seems to work fairly well as it wanders around the house on its own. I'm pretty sure she didn't set up any sensor grids or painted the house with white stripes... but I could be mistaking there.

Also, you keep neglecting the fact that in the next 60 years, there's going to be plenty of advances in software. Interpreting data from sensors is the most mild aspect of drone programming there is (and you *can* program an autosoft that does it even better -- see the Clearsight autosoft for more details). The "hard" part about programming either drones or frames is the decision-making and independant thinking aspects, both of which are similar in nature. Frames get their input from *their* sensors just like a drone does, and both rely on secondary software for that for the most part. How they interpret the input and decide what to do is where the real programming comes in and, again, it's similar in both cases.

What's more, we're almost *definiately* going to have vehicles that can drive like a competent driver way before we have computer programs that can hack the internet on their own. And again, that suggests that the former is a lot easier to do than the latter. The processing of input is going to be a relatively minor aspect of programming either one. It's the decision-making aspects that are tough.

Ok, I'm going to need more time to think out a response to the rest of your post, but regarding the vacuum, that can be done with basic collision-avoidance sensors. You don't even need detailed proximity, just a basic "is there something in front of me?" It's not very applicable to driving as a whole, and certainly doesn't suggest that we'll be able to say to our cars "stay here and if someone comes out with a firearm, accelerate and run them over", which is a perfectly possible application of SR drones, though it might take a few Sensor successes to carry it out.

You're starting to possibly convince me on the autonav, but not on the pilot and most certainly not even close on the robot.

~J

If I can find the article I will post it. Some college has a "robot" that can recognize faces and use that info to interact with these people. So far it can only hold 23 people in its hardware. Why 23? I don't know but I suppose it can be upgraded when nessecery. So of the newer Military auto navs can work with out painted lines.

Autonavs should be pretty easy by the 2060's, Drone pilot systems harder yes, but not infinatly harder, and robotic navigation should still be a dedicated task for an individual. Of course things will be so much easier for groups of people rather then 1 guy in his basement, but that is also true for deckers, look at the programming team rules.

well, robots are basically S-Ks in a can. not something i see an individual doing, given that an S-K takes a team of 6 programmers with 12 skill and a Red-10 host, minimum.

1)
Take a look at the rules:
Drones are smart-frames and robots are agents. I see nothing with the capabilities of an SK in there.

2)
Auto-pilots are not as hard to program as some of you like to make them (they aren't easy either, just not as impossible as stated in here). I did some simple programming for autonomous navigation as part of my studies. It was basically what SR describes as a level-1-autonav and we did that in a beginner's course.

3)
Someone stated above, that the software is so expensive because it is illegal:
Think again: those price-multipliers are applied to any software all throughout the SR publications.

Auto-pilots should be much more expensive compared to the rest of SR-tech, but they aren't because all the vehicle-rules were created without references to the rest of SR technology. (which explains all those incompatible rules - it's basically very easy to program very sophisticated software but even simple mods on vehicles require ridiculous investments into tools and parts).

the most famous facial recognition robot is COG at the MIT lab. as for the difficulty of programing robotic controls. the inherent difficulty of robots/drones over a frame/agent is that as you have said a computer only responds in a preformatted computer language response drones must interpret sensor information about the world around them. this means that even though a higher function processor for drones and frames could be similar the drone is always operating on second hand information interpreted from raw sensor data. however as time goes on and more sensor data is accumulated and cataloged the sensor interpretation programs will become more clear and efficient and the data aquired through sensors will produce a more clear and easily understood language for the drone to precive it's surroundings. a car with a voice activated control menu and some memory can idle in one spot and move on command, with an infered sensor and information libary the car can detect and verify the existance of a person with in its view, with and x-ray and a file of firearm data (in x-ray format) the vehicle could confirm the presence of a weapon, with a second sensor of either of the 2 types listed above mounted to the vehicle a program could crossreference their data to provide a 3D map of it's surroundings (just like the human eyes), if the vehicle has been programed to understand the act of running somthing over it is a simple act to have the vechile to steer and move in the direction of the target untill it has been run down adjusting to the sensor input of the targets location all the while (as any type of homing missle). all of this technology exists today in one form or another but is not effective enough to be combined to these ends now. that is why shadowrun is 60 years into the future.

you can buy an agent with a core rating of 2 for 4,000 nuyen. a rating 2 robot pilot costs 40,000, before factoring in the chassis markup and vehicle class modifiers. you can buy a smart frame with a core rating of 5 for 30,000 nuyen; a rating 5 drone pilot costs 2.5 million nuyen. obviously, it's more difficult to produce a drone or robot than it is a smart frame or agent; ergo drones and robots are not smart frames or agents.

Autopilot-5 != Smartframe-5

It's more like a Rating-10 Smartframe, with pilot-rating of 5, a rating-5
"vehicle-operations"-utility/autosoft, "sensor-interpretation"-5, "special-equipment operation"-5, gunnery-5 and some more things, I just forgot to include ("vehicle-combat tactics"-5 e.g.), along with hardware equivalent of an MPCP-10 to run that thing.

You are comparing the price of a more or less useless pile of MP's (a naked framecore) to that of a fully operational control system, with both hardware and additional software.

hmmm, that's an interesting route to go. how about just using the autosofts? to design a typical drone/robot, you'd need to program the core, as well as one of each type of autosoft at a rating equal to the core.

how about this: programming and designing a drone or robot core is equivalent to programming and designing a Matrix program with a rating equal to (rating*rating*0.5), round down. drones have a multiplier of 10; robots, 20. the core is basically functionless unless autosoft programs of a rating greater than or equal to the core rating are linked to it. running a drone requires a computer with Mp equal to the drone's total size *50; running a robot requires total size *100 (i'll check my books when i get off work, and adjust the Mp multipliers to more accurately reflect the prices for drones and robots in R3).

this handily explains several things. first, it explains why there aren't drones or robots around with ratings of 6+: they're simply impossible to design. a computer (proramming) skill of 18--the minimum skill required to create a drone/robot core rating 6--is simply rarer than hen's teeth, and none of the handful of programmers in the world capable of designing a robot/drone rating 6 core have gotten around to actually doing it (with the obvious exception of Deus). autosofts, however, are much simpler to create, which is why you can find them at higher ratings.

obviously, this also helps to explain the ridiculously high price of a high-rating drone or robot; not only are you paying for the core program, you're paying for four equal-rated autosofts, plus a computer to run it on.

You wouldn't get an autosoft higher than Rating 5, as autosofts are capped by the Pilot rating.

~J

ah, right. hm, in that case, it's silly to go through and figure up the ratings and Mp size of those, every time someone decides to whip up a drone or robot. be better to just increase the program size multiplier. i'll tinker with it tonight, and post some numbers tomorrow.

any opinions on how much of the cost for a drone/robot should be for software, and how much for hardware? 50/50? 25/75? maybe an increasing or decreasing ratio, like 1:(rating) or (rating):1?

i think i've got a workable formula for drones. haven't mathed it out to see if it works for robots.

Drone: Program Rating = (Drone Rating^3*0.1), round up; multiplier =(rating+9).

Drone 1
Program: 1; 10Mp; 1000Y
Diff: -1000Y

Drone 2
Program: 1; 11Mp; 1100Y
Diff: 3900Y

Drone 3
Program: 3; 108Mp; 10800Y
Diff: 14200Y

Drone 4
Program: 7; 637Mp; 318500Y
Diff: 181500Y

Drone 5
Program: 13; 2535; 2366000Y
Diff: 134000Y

edit: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!

will someone please tell me why the base cost for a rating 4 robot is cheaper than a rating 4 drone?

er, no. that hardware could just as easily be a regular computer with enough memory to hold the completed drone or robot.