No the common sense says that the devices rating is what the device rating table says it is.

For that to be Common Sense, it would first have to make Sense.

It doesn't.

An increase in device rating on the device rating table shows an increase in overall complexity and (looking at the hardware upgrade costs table) a steep curve in prices.

An increase in the rating of a device shows an increase in specific effectiveness for the focus of the device and a flat rate increase in price.

For example, the cost of response is:
1 250¥
2 750¥ (+500)
3 1,250¥ (+500)
4 2,000¥ (+750)
5 4,000¥ (+2000)
6 8,000¥ (+4000)

The cost of an smart jammer is:
1 1000
2 2000
3 3000
4 4000
5 5000
6 6000

The two patterns are completely different. There is a distinctive curve on device rating costs across the board and flat line increases on the rating of a piece of equipment across the board. Claiming that the two are the same doesn't make sense and therefore can't correctly be called "common sense".

Yes, I think the idea of 'Device Rating' versus, shall we call it, 'Equipment rating' is a settled question (if indeed it ever was a question). Device Rating would benefit from a less confusing name, though: Node Rating? Bleh. In any case, there's obviously a Device Rating that refers to the 4 Matrix Attributes of the gadget, and then there's the 'equipment rating' that refers to the other function(s) of the gadget (Rating 3 Visual Enhancement, etc.). We know they're not the same, for many reasons.

SR4A, page 222, under The Wireless World>Networking>Devices

"Device Rating" is really only used on devices that do not have actual Matrix attributes assigned. It is shorthand to refer to the four Matrix attributes as a whole. It has nothing to do with the actual function of the device.

Like a clock only has a Device Rating of 1, meaning that it has System, Response, Firewall, and Signal all equal to 1. (It's probably also only a Peripheral Node, but that's aside from the subject)

That same clock might have a rating of 6 for how loud it is when it's alarm goes off, but that is a separate function from the Device Rating.

If a device has actual Matrix attributes broken out, "Device Rating" should not be used, really. In any case, it is the System Rating that determines how high a rating of programs that can be run on the device, not the Device Rating. The System Rating just happens to be PART of the Device Rating.



-karma

I prefer "Matrix Rating" to refer to the four Matrix attributes.

States right on the tin what the rating is about.



-karma

After all a Rating 6 medkit is not some super commlink for 1/10th the price.

Ha, I nearly wrote 'Matrix Rating' instead of Node Rating, but though it still might be confusing. (IMG:style_emoticons/default/smile.gif)

Incidentally, what happens when you run a Rating 4 program on a rating 1 Response device, even if it has System 4? Anything? I guess nothing that matters…

Response goes to 0
You better not have any cybercombat in that node.

I mean, technically all that matters it the number of programs you're running, not their rating. (This is wrong, but I think it's RAW?)

Right, sabs, but if it's a peripheral node, no one's using it. It just bothers me that this works this way, I guess. (IMG:style_emoticons/default/smile.gif) Response affects Matrix Initiative, Cybercombat dodge… if Response hits 0, the node keeps happily running Sensor software? :/

I dunno, I'd get more confused with Node Rating. Matrix Rating for Matrix Attributes is what I was thinking.



If it's a Peripheral Node, the Response doesn't matter. The program runs at whatever System Rating the device has.

If it's a regular Node, then the program runs at Rating 1.



-karma

That's what I thought. I can see some Dumpshockers abusing that. (IMG:style_emoticons/default/smile.gif) 'House rule to fix' time.

So, peripheral nodes explicitly have a processor limit equal to their System. What happens when you run a dozen programs on one? Does anything happen after Response 0? At the very least, I'd rule that everything turns to molasses at 0. :/

it would be nice if response had more of an impact.

*thinks*
You can't do max hits = response, because we're already doing max hits = logic.

What about:
Rating of Program - Response Rating = interval modifier

for every difference the interval goes up by 1.

Lets say you're VR slow Hacking Interval on that is 1 hour..
If you're using a Rating 6 exploit program on a response 4 system the interval goes up to 1 week.
That's weak, you could just use a rating 4, and not care about losing 2 dice when your interval is so much less.

I suspect that the only fair way to do it is that Max Rating of Program = Response + Optimization Rating.

You can even cascade it.. as a sort of 'chess game'

ergonomic: max dice from program = max response
Exploit
Biofeedback Filter
Stealth
Analyze
Armor
Disarm

Response 6 max dice from prgram = 6
Browse
Attack
Decrypt
Reality Filter
Medic

Response 5 - max dice from program = 5 + optimization rating of program
ECCM
Track
Scan
Encrypt
spoof

Response 4 - max dice from program = 4
what ever

If you only have a 5 response commlink, you shift everything down 1, and only allow 4 programs per category.

Whats' going on is that the Ergonomic and the first 5 programs are given priority on the 'cpu' and the other programs behave like they're on a slower commlink.

This gives you a good reason to pick up somethings as ergonomic, and optimized.
I would allow for a simple action a hacker to change the priority on a pair of programs.

IE:
For a simple action, Hacker swaps Decrypt for Encrypt. If the encrypt program was rating 6, then it would suddenly get 6 dice, instead of 5, and decrypt would drop down to getting 5 dice.

Commlinks already have a Response limit rules in play. It's peripheral nodes that seem to be a problem.

I'm a little fuzzy on the issue of peripheral nodes. Since all they can do is run the software they're meant to run, it's not like you can:
1) Add more software to them.
2) Improve the software on them.

You simply can't run a Rating 4 program on a rating 1 Response peripheral device because it's not meant to run on that peripheral node.

Or am I missing something?

Find me in the book where that's true.




the default reading of the RAW states that.

if I'm running 18 Rating 6 programs on a Response 6 Commlink with a System 6
My response is a 3, but the programs are all running at a rating of 6.
Even if I ran 36 programs and dropped my response to a 0, by RAW everything woudl still run properly.
My system is still a 6, since it's limited by the BASE Response.
I just, better not get into cybercombat. (or try to drive)

Sabs, he's referring to the rules that state that Peripheral Nodes don't have their System Rating limited by their Response Rating.

But since Peripheral Nodes can only run software that they're designed to run, that should not be a problem.



-karma

He said Commlinks already have a response rule in play.

And I said: that response rule is pretty damn weak.

Peripherals are actually NO different then commlinks in that regard.

Where the peripherals differ is that even though they're R1 device rating (meaning they have a firewall, system, response, and signal of 1) It can still run R6 Hoozit Software that it was designed to use. Even though it's SYSTEM is only a 1, so technically it should only be allowed to run R1 software.

interesting tidbit


only place i've seen mentioned what happens @ response 0

suoq, I agree. I'm just exploring what I know people will try to abuse. (IMG:style_emoticons/default/smile.gif) You'd have to rule that no sensor software can run on any peripheral device, which is perhaps too draconian.

Actually what are you calling "sensor software?"

Sensor Software. It's a category.

People are talking about running sensor software on the sensors themselves (peripheral devices). While personally I think it makes sense to hook the sensor to a commlink, and run the software on that commlink, I can see the argument than a camera could (theoretically) run a built-in copy of Weapon Watcher, etc. Someone mentioned the Canon software hack that exists today (it's pretty cool, google it), so 2070 might well have software running on the sensors themselves. This would fall *within* the 'peripheral devices only run intended programs' rule, see?

This opens up the problem of peripheral nodes having the system for something, but not the response. It's not a huge deal, but it's something worth (perhaps only briefly) considering. (IMG:style_emoticons/default/smile.gif)

My cybermage just upgraded the Response and System on his alpha cybereyes and loaded the Empathy software there.

(IMG:style_emoticons/default/wobble.gif)






-karma

Yeah. I think it's a fair interpretation to let video-based Sensor Software to run on those peripheral devices (video sensors themselves). One could argue that the limitations of peripheral devices don't allow a software 'upgrade' like that, but having spent the money for Response and System, it seems plenty fair to me. You're not 'cheating' by arguing that you don't have to upgrade Response; I'd disallow such a sneaky move. (IMG:style_emoticons/default/smile.gif)

Personally, I draw the line at *unrelated* peripheral devices: your cyberarm is not a free processing unit. (IMG:style_emoticons/default/biggrin.gif)

The very fact that there is Sensor Software and that you can't add software to peripheral devices indicated to me that sensors were not necessarily peripheral devices. Now I agree that a Security Camera is listed under peripheral nodes but I considered a security camera as a camera meant to be slaved to a larger system. A sensor meant as a stand alone unit wouldn't be a peripheral device. (If it does, the name doesn't make a lot of sense to me.)

Devices like binoculars and imaging scopes are built to have sensors and an interface with immediate feedback. (i.e. controls and a display). An argument can be made that they're unmodifiable (peripheral nodes) just like a cell phone. Likewise, an argument can be made that they're modifiable, just like a smart phone (android, blackberry, iPhone).

I don't have a problem with a houserule such as "all sensors are peripheral devices". I'm just not seeing where the rules say that.

Edit: As the above example, cybereyes are a stand-alone unit. They're not meant to be "peripheral" devices (devices that operate separately from a main unit but are connected to it). They are the main device.

suoq, there's no reason that Sensor Software runs *on* sensors. I'm saying that I could maybe see allowing directly-related sensors to run some Sensor software. *Maybe*. The default would be 'no'. You take a sensor feed and run it through a commlink (or other standard node) to use sensor software on it.

All stand-alone sensors are peripheral nodes; there is no such thing as 'just a sensor' in SR4. Either it's in a sensor package on a drone/vehicle, or it's in a portable 'stand-alone' sensor package, or it's in a cyberlimb/eye/ear. A camera, for example, might be the only sensor in a sensor package, but it's still in one.

Peripheral nodes in SR4 are not 'peripherals', like a keyboard. Nothing about their definition means 'not stand-alone', and there's no 'main device' distinction. It means 'not a standard commlink-style node'. Cellphones are the canonical *standard* commlink nodes. Standard nodes are the general-purpose computers of SR4, including commlinks, home (=household) nodes, nexi, etc. Peripheral nodes are anything that is not a general-purpose computer, intended to run any program and support Matrix Personas; the fridge, a camera, a smartgun (these are explicitly examples of Peripheral Nodes, Unwired p48).

I was doing searches on sensor software, looking for cases where the device (such as a cybereye) would contain both the visual input and visual output and as such the best place to run the sensor software would be within the device to include the software results in the visual output.

Then I hit this in Unwired:



I'll take that line as saying you're completely right and sensors are Peripheral nodes.