OK everybody, I've got a question for you: What counts as a device when clustering cyberware? I can see this problem with the clustering rule:

Problem 1: Cyber eyes with one or more pieces of 'ware built in. Each separate piece of eye mod can be a stand alone cyberware system. Rules lawyers and munchkins might say each mod counts as a separate item and get insane levels of computing power

My answer to Problem 1: Cyber eyes and cyber ears count as one node a piece no matter how many mods you put into either one.


Problem 2: Now if someone has a cyber limb and they throw doodads into them then what counts for the node?

My answer to Problem 2: Cyber limbs count each item that is put in as a separate node because those items are not integral to the cyber limb's function, unlike vision &/or audio mods. So if you have a cyber hand with a nanohive, datajack and a Orientation system then that counts as 4 nodes for clustering purposes.


Here's how I see it: You can use the nanohive without having to use the hand it's housed in, but to use thermographic vision you need to use the eye it's housed in.

================================================================

House rule proposal for Sensor Software: You add the level of the software to the response rating (pg 214 of the BBB) of the device running it. For example, you have a Security camera (rating 4 from the chart) running weapon watcher 4 then you have a total of 8 dice to notice weapons. This allows those software packages to actually be worth something.

I see your point, and I know I don't know as much about this as most of you, but....
Even if the ware wasn't built into the limb from the beginning, we humans tend to like to optimize our stuff, I would expect most additions to be a kind of "plug-n-play" system that integrated into the limb's established control runs, and a downloadable program to run it off of the same processor. But, hey, that's just me.

There will apparently be some upgrades to the cluster rules in the next Unwired errata (highly anticipated on my end). You might want to wait for those.

- I would agree with solution 1&2.
I interpret cybereyes/ears as highly integrated, so anything that goes into their capacity slots is part of one device. All subsystems use central hardware for shared functions, so there is little to no redundancy. The same goes for cyberlimbs, unless the subsystem in question would be standalone outside the cyberlimb.

- As far as your houserule is concerned, be very careful with that. Some of those perception tests are already pretty dangerous for your runners.

For cybereyes with vision enhancements I see them as being a couple of additional components plugged into the cybereye; it's cheaper and easier to make them an extension of the capabilities of the eye rather than a separate piece of computing hardware. You plug in some extra filters and flash a new program to the hardware to control it. It saves the manufacturer the costs of an additional computer to control the whole thing.

For cyberarms things that aren't stat enhancers will be separate nodes because there's no way for the manufacturer to predict what kind of functionality they need. The programmer for a cyberarm OS isn't going to want to have to deal with building a lot of code to control every single device that could potentially be added to the cyberarm; they'd integrate the enhancements because they're being used for the core functionality of the arm and let people access the other devices as separate nodes.

As a rule of thumb; if the additions affect the core functionality of the implant then they're integrated into the implant's node. If they serve a purpose that is completely different they act as separate nodes.


Adding Response to the rating is a pretty good solution to the Sensor Software uselessness issue.

As far as the clustering I would go with the integration theory line of thought.

Not understanding the response increase solution, how would response affect the perception test? Rating of the sensor software already adding to sensor test. A stand alone camera I'd rate at 1 with say a pilot of 1 keeping track of it and rating for 4 software gives ya 6 dice for perception test. drones,vehicles and spyders even better dice pools.

I can't wait for that either.



Not really. Figure security cameras would have a Response of 4 and therefore only able to run programs (vision specific) up to Rating 4. This would give an automated dice pool of 8 dice. Now a runner should at least have Infiltration of at least 2 and Agility of 3. This right here gives 5 dice to counter. Now add in concealing holsters and lined coats and that add 4 more dice bringing the dice pool to 9. If you want to be even more ninja like then your Infiltration skill should be at 4 and agility at 4. You quickly out pace the automated security of any building.

My house rule would make it so that runners would WANT to get those programs because they can help. As they sit right now, those programs (other than Empathy) are completely worthless.



Security cameras are rated at 4 (pg 214 of the BBB) as they are complex devices. Also I don't see where a pilot program can use the sensor software to boost perception tests. Could you please point out the page number(s) that I can read that?

Assume that all runners have 10 dice for stealth (not all will, but just assume).

Dp 6 perception rolls have a chance of about 16,5% to detect a stealth-10 opponent. Against a group of four such runners, that´s already a detection chance of about 51%. Even one die more changes the odds to 22% against a single runner / 63% against the team of four.

(Some groups will laugh about a stealth pool of 10, and those will like to add something to sensor pools; some won´t. Be careful is all I said )