Except the System rating of Peripheral Nodes is NOT limited by Response.




-karma

Where do you get that from?

"Since the operating systems of peripheral nodes are far more limited and focused, their System rating is not restricted by the Response rating, as is the case with standard nodes. In other words, the System rating of peripheral nodes may exceed Response rating without penalty." - Unwired pg.48




-karma

Once you've clustered them, they're not a peripheral node, and that would mean Response limits System, as far as I'm concerned. You can't get the benefits of both without the penalties of either.

OK. But I still don't see your point.

1) "Since the operating systems of peripheral nodes are far more limited and focused"

So you can have as high a System you want on your credstick, it still does not allow it to run an Empathy software.

2) I don't see the link with clustering.

You're right, about PNodes: "They are only able to run a single persona and can only run programs they are designed to use."

Also, re-reading the rules on Clustering Peripheral Nodes, why would anyone ever WANT to do it?

The core book implied that you can Cluster a bunch of tiny peripheral nodes to make a more powerful distributed computer. Presumably so you can run bigger stuff on such a system.

But looking at Unwired, I see this: They manifestly DON'T get more powerful, the cluster runs at the lowset System rating and will generally have a Response of 1 or 2.

You literally don't get any benefit that you wouldn't get just running them seperately.



-karma

That quote is for peripheral nodes. Clustering makes peripheral nodes into a standard node, sort of. Multiple personas, more programs.
It's not supposed to get stronger, really. But, if you were just dying to MacGuyver up a commlink-equivalent, you could cluster the fridge with the toaster.

Okay. I was envisioning from the SR4A description that'd it be some frankenstein uber-computer, but the actual rules in Unwired are a little underwhelming.

The simplest way of running Empathy 6 software is just upgrading an Alpha Cybereye or camera-linked Commlink to System/Response 6, I guess.




-karma

Actually, the point you just quoted also applies to cameras, so you should not need to upgrade the Response, System is enough.

and noone has Tried to explain how Emotitoys Work then since they dont have a response 6

I did. I misspoke, though. I said Ergonomic, but I meant Optimized. It's stated use is avoiding the System limit, but it's essentially the same thing. The emotitoy is specifically designed to run that software at the stated rating. That is the inviolable truth. *How* it works is totally secondary.

By a desinger fiat
One very good basis for dissallowing them is that they go against pretty much all apliable rules in the books.

Edit: ofcource the best answer would have been "They don't"

Emotitoys are an example of a cool concept that's not really backed up by the rules.

The way you would build such a thing would be two fold:

1) you would have optimized circuitry built specifically to run both the empathy software and the personafix software.
2) Your software would be written/compiled to run specifically on those chips.

This would allow you to hit both your price point and your usage point.

Using the matrix rules we have:
Response 1
Hardware Optimization 3: Empathy Software
Hardware Optimization 2: personafix
System 1
Optimization 2: Empathy Software
Optimization 1: persona fix

So while it's only a response 1, system 1 node
it can run rating 6 empathy software and rating 4 personafix

Right. I don't see anything outlandish about that. Dedicated hardware chips are a widely-used concept. The Empathy software in an emotitoy might even be hardware or firmware itself, which would keep you from copying it for use on other devices, *and* force you to use the emotitoy's sensors. That means, of course, that you have to carry it around: perfect for balance.

Right. I don't see anything outlandish about that. Dedicated hardware chips are a widely-used concept. The Empathy software in an emotitoy might even be hardware or firmware itself, which would keep you from copying it for use on other devices, *and* force you to use the emotitoy's sensors. That means, of course, that you have to carry it around: perfect for balance.

Sadly the concept of hardwired software, and firmware are lost in the abstractions of matrix 3.0

To me it seems reasonable to simply have emotitoys at rating one and the mobile emotitoys at rating 1-2. At that rate it's 100:nuyen: for Empathy 1, which is a huge, but believable discount. At that rate, I'd be tempted to hang one off a jacket too.

(Ok. So it's unprofessional. I'm considering having a dragonfly with gecko tips and an improved sensor array (Ultrawideband Radar) sitting on my shoulder and feeding data to the tac net. That's just as cheesy as an emotitoy 1, just more expensive. Once the emotitoy and medkit debates are settled, I expect battles over Ultrawideband Radar.)

sabs, it doesn't matter. The unit works, so theoretically that's one way that it does.

You can, of course, simply velcro sensor packages to your shoulders/arms/chest/whatever.

UWB radar is the best, yay!

Well it matters, because I think they would add an interesting layer to hacking.
One of the things that's missing is gadgetry. Little doodads, that do cool things.

And yes UWB radar is /awesome/

Yeah, remember the crazy Russian military hardware cracker unit from Burning Chrome?

but by this statement alone you are breaking the "Device Rating 6 required" that everyone has agreed with ....

oh and keep in mind ... that by these arguments .... Emotitoys are as advanced as deltaware and certified credsticks

Nope. The book says that the toys have "built in" empathy software, and that they function at the rating of the toy (1-6). Those are both true, done. It doesn't say 'they run rating X Empathy Software'; it says, book fiat, that they have that rating. It works, and we can speculate as to how.

All *other* Empathy software has to follow the rules. Emotitoys are a specific exception that works in a way we aren't told. Nothing about 'advanced as deltaware'. This isn't a tough concept.

The matrix 3.0 Rules are a frustrating mix of abstraction and weird detail that blend horribly together.

It's better than the burger and pizzas for yore. But it's still very frustrating.

The stats do not even remotely support the fiction.
Slamm-O! runs across a firewall he's having issues with, and so he goes to some black market on the matrix, and trades his super special black hammer program, for a nice and tasty mitsuhama stealth cloak, which he wraps around his persona and then has an easier time hacking through said firewall.

BUt, Slamm-O! already has rating 6 everything software. That cloak makes no sense for him to get.
The degradation rules mean that a serious hacker has a minimum of a 15K a month software habit.
What other archetype has to spend 15k a month just to maintain their current power level.
And that's not including drones, agents, pilots, ammunition.

the Matrix rules need 4 things
A clear seperation between Matrix Running and Facility Running
Interesting legwork for the Hacker to do to, that will allow him to hack the secure facility
a more reasonable cash/karma balance
Stats need to matter (this is addressed with the optional rule of Logic=max hits)

See, I would personally say that his Mitsuhama Super StealthCloak Software Package, that he traded his Super Special Black Hammer Program for, is not Rating 6, but something a bit more robust than that, say Rating 7 or 8, or thereabouts...

But that is just me...

You keep saying that, but I don't see any page references backing this up. Common sense says that rating of a device = Device Rating.

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.

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

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








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

Personally, I draw the line at *unrelated* peripheral devices: your cyberarm is not a free processing unit.

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.