If a Drone is slaved to a commlink would it use it's own response for tests or the PAN's response? Can I have page notations in any book with responses please. Thanks all!

All slaving does is pass attempts to connect to a slaved node on to the master. That's Unwired, page 55. What that means practically is that attempts to hack the slaved drone are seamlessly forwarded to the node setup as the master and attempts to hack the drone wirelessly must be carried out against the master first.

To answer your question directly; any tests the drone needs to make, or any programs it's running, are handled by the drone's hardware and software regardless of node configuration.

If you're looking to run more than the standard program load on a smaller drone you could try clustering a group of them. In theory at least any program they would have running would be available to all of them. However hacking one of them would hack the whole cluster, so it's a good idea to back that up by slaving the cluster to a decent security node.

Clustering makes multiple nodes into a *single* node. They wouldn't be sharing programs, they'd be the same node running one program. One node means one Pilot, which means *one* drone. :/

Drones use Pilot in place of System, the OS of a node. You could not have a drone or any device in the cluster without it running System/Pilot, so by your reasoning you can't cluster anything. System/Pilot must be treated as a matrix attribute first and a program second for this reason. So just like any commlinks or devices in a cluster retain their original operation, a drone does the same thing. In addition, any programs the cluster runs are effectively running on all the drones.

No, otakusensei. My point is that you've got one Pilot running three drones; precisely *because* Pilot is System. Frankly, I'm not of the opinion that clustered devices maintain their original operation in the first place. Clustering certainly doesn't let you get triple-duty out of one copy of a program. You can't have your cake and eat it, too.

Also while on the subject of response, there was a table at the end of the matrix chapter in the BBB (pg 240) that gave costs for updating response. That table seems to be vacant in 4a. Does anyone know if that information has changed or would it be safe to use the table from 4th.

Also while on the subject of response, there was a table at the end of the matrix chapter in the BBB (pg 240) that gave costs for updating response. That table seems to be vacant in 4a. Does anyone know if that information has changed or would it be safe to use the table from 4th?

I dunno if it changed, but it's under Hardware Upgrade in SR4a, p222. To upgrade more than Base+2, you need to also pay for Modular Electronics (or whatever it's called), which only exists in the Changes file. Sigh.

It's not exactly a best case setup, at least security wise. If you hack one drone in the cluster, you hack them all. Very dangerous when they are armed.

Also, why wouldn't clustered devises maintain their original functions? How do you figure out what functions they maintain? As there are no rules that state what a clustered node can or can't do in that sense, I assume that the configuration doesn't limit them. Other than your opinion, where does your reasoning come from?

I agree that the RAW is totally silent on what happens to the functions of clustered nodes. As far as I'm concerned, they retain none of their original *computing* functions. A fridge still refrigerates, and a motorcycle (probably) still drives (manually, anyway). I don't want to portray my position as RAW. My concerns are based first on fluff, second on balance.

That said, clustering is the repurposing of computing resources. It's intended for peripheral nodes, and it only makes sense that those nodes can't retain full (and often specialized) computing functions *and* fully contribute computing resources to the new unified node. TANSTAAFL.

It gets even messier if the nodes aren't geographically together, and messier still if they're independently-operating computer-controlled vehicles. Does the book even have rules for a single node having multiple Signal ratings in multiple locations? Is the unified node running multiple Pilot 'programs' (for potentially different vehicle types)? Is the unified node acting on multiple Initiative scores and different passes? Maybe it is, but it begins to stretch the limits of even SR-physics.

The balance issues are separate; I agree that clustering drones is less advisable for the reasons you mentioned. I reiterate that those weaknesses probably don't fairly balance back the abuse of 'sharing' expensive programs between 2 or more drones. One of the primary costs of drones is upgrading their various programs.

Aside from the context of clustering drones, balance is still a concern. Some Dumpshock users recommend clustering one's high-grade cyberware to get free high-rating nodes. While clustering has very specific and limiting rules, this still can present a balance problem. It seems unreasonable to assume that the designers balanced the game such that the Alphaware you already bought (including bone lacing, eyes, ears, whatever) can replace expensive computer gear: it's something for nothing.

Finally, I'm not saying that this is the only possible interpretation. Perhaps you could rule that out example drone cluster is indeed running the original multiple Pilot programs (now counting them as programs instead of System); perhaps they run multiple instances of the programs they need, as if they were different Personas using a Nexus. I just think my perspective is more abuse-limiting and enforces more trade-offs.

"We are legion, for we are one."

I seem to remember talking about an AI using a clustered node of like 11 drones for it's home node.

This again? The rules are actually very clear on what happens to Clustered nodes. Its matrix attributes change a little,(System, Firewall, Response, Processor and Persona limits). It certainly doesn't delete loaded/stored programs or other data, or even need a reboot - all it even requires is a complex action and root rights to enable.

Clustering isn't some super-magical undoing of a nodes original functions. Its basically an instant on, instant off cloud computing switch. Which, when you consider the implications of a mass networked wireless mesh, really makes sense.

Clustering drones, while a fairly neat concept, is actually terrible in practice. You still need to burn a complex action each round controlling the vehicle, and, guess what, your pilot program suddenly has a handful more drones that need actions. It just flat out isn't practical.

Program sharing is a neat concept, and, frankly, works out of the box. Programs are still Loaded onto nodes, and Running on the big node instead of a smaller one. Don't really have a problem with that one. To be honest, I'd rather people bought programs at full price, instead of just pirating everything. Or, hell, taking a pirated-programs contact and talking their already super-low prices down with negotiation constantly.

There's also some dangers involved with running clusters over wi-fi: Anyone turns a jammer on in your direction, and it all falls apart. If its relying on another node for its programs, and can't connect to it, well, its now screwed. Also, a successfully spoofed reboot command will hit -everything- on the network. It has its advantages, but then again, it has its downsides. Also, a wi-fi cluster is basically -begging- to be Traffic Intercepted.

That was my point, Udoshi: you don't get multiple Pilots, etc.

I don't think you can support the idea that all programs remain in place by RAW, though. It becomes a new, single node.

Different Pilot programs are built for different drones. When you cluster them, what Pilot do you have now? The way I see it either 1) Pilots can't be clustered because of the fundamental differences in their operations, or 2) The individual Pilots movement functions are still intact and a single complex action is sufficient for the clustered gestalt Pilot to handle the drones in the cluster because the individual dedicated hardware supports those functions. The first one is out because the rules don't back it. The second one makes sense, basic functions and operations do not appear effected by the clustering.

It really isn't that uber at all, and attempts to put restrictions on it just adds more unwritten rules. It's just resource sharing. In fact, this interpretation fixes the problem high level devices being clustered to make a free top end commlink. If you consider that a commlink is a commlink because it has those functions associated with one, and a device (regardless of it's ratings) only has it's own functions (say, those of bone lacing); then clustering them would only give you access to those functions you had before.

So if you did cluster a bunch of high grade cyberware you wouldn't get a platform to hack from, it wouldn't even be able to accept a comm call. But you could add a commlink in, and then it would. Of course the commlink would have to have decent stats or you end up lowering the stats of the rest of the cluster. Now you have a player who must purchase that expensive commlink, and for his trouble he gets to run more programs. It's better than just having a commlink, just as expensive and honestly non-technomancer hackers need every break they can get. If they want to load every program at once, let them. The technomancer is still going to thread Stealth out the ass and root kit the poor hacker's cyberware cluster. I hope the Move-by-wire system wasn't in there.

I like the idea of the cloud computing on/off switch. The question is, if flipping that switch causes the original functions of the individual nodes to disappear. And because they need to act individually to join the cloud, and can individually leave the cloud; and because the rules don't state that they loose those basic functions, I say they don't.

If you look at process sharing, cloud computing programs today, each individual node is still able to act on it's own, but the resources are shared. It's different from what you think of when you think of a cluster today, but that's mostly terminology and if you look at the book function, perhaps the commlink mode should have been called Resource Linking?

I'm not aware that drones have dedicated Pilot hardware.

While I appreciate you looking for limitations, I feel like the explicit purpose of clustering is to turn peripheral nodes into a jury-rigged commlink.

I understand that one valid perspective is that the devices are sharing 'surplus' computing resources; as if they had SETI@home installed. My perspective is that the devices are repurposed into a new and different function.

You can't take a Pilot program written for one type of drone and load it on another. They talk about that in Arsenal.

The key is not to think about a System, Pilot or Device Rating as a commlink. All those things have matrix stats, but that doesn't mean they provide the functions of a commlink. A commlink does that and it's why people don't just take phone calls on their jackets. They could, with the right hardware and software, but by that point you have a commlink anyway.

It doesn't make much sense to think of clustering as a repurposing. For one the rules don't explicitly support it. For two it seems more like resource sharing. You can run it however you want at your table, it's just that the original question was asking for specifics and page numbers, so I figure we should stick to what the rules say and clearly label our own interpretations and additions as such.

Indeed. I made it very clear that the RAW isn't my position, and that the RAW actually is totally silent on the issue. That's not the same as contradicting my view, but we do indeed assume that nothing happens unless the rules say so.

I know that Pilot *software* is vehicle specific; I was addressing your comment that the drones had 'dedicated hardware' that would let them keep Piloting themselves.

I agree that Peripheral nodes do not have the same capabilities as 'Standard' (commlink-like) nodes. That's *why* clustering exists: to allow a Standard node to be assembled out of Peripheral nodes.

The Pilot "hardware" is in the Pilot Upgrade accessory in Arsenal. Because the Pilot rating of a drone is it's device rating, the upgrade appears to be a combo System software and Response hardware bundle. As that is the only way listed to increase those stats for a drone, I assume that all drones and vehicles use the same type of bundled setup.

When you create a clustered node using, say, commlinks; you get a single node with the persona capacity of all the nodes in the cluster added together. That tells me that the basic functions of the nodes,(in the case of commlinks their ability to interact with a user) are not taken off line or limited. Instead all the nodes in the cluster adjust their matrix attributes and can now share processing power for programs while performing their original functions.

A drone doesn't allow you to log onto the matrix, but it does follow orders and pilot itself. Therefore it makes sense that drones in a cluster would be able to pilot themselves and follow orders.

I see your position, but I don't think those two very distinct things are logically equivalent. Persona is software (firmware, specifically, but still), and the ability to support multiple Personas is a known quantity (nexi). Pilot is also software (100% non-hardware), but it's System; the ability to run multiple Systems is not known.

When you cluster Peripheral devices, you also get multiple Persona support—even though the original devices didn't have Persona support themselves. The clustering rules don't appear to support a 'sum of the parts' interpretation.

Aside: "Note that Pilot rating is listed separately, and is not considered part of the Device rating." In addition, the Pilot Upgrade you reference refers specifically to software only. Response is pretty easy to upgrade, and I wouldn't consider that 'dedicated hardware'.

So a device that does not allow you an interactive connection to the matrix does not add the function of doing so to the cluster and does not increase the cluster's ability to do so.

Where is the quote form your aside from? It's familiar but I can't place it offhand. I'll admit I may be off on my thinking about bundles, but I also think you are getting too hung up on treating Pilot as a program.

It is software, it can be written and copied, but it doesn't function like a common use program or an autosoft. It is the basic functional part of the device, the OS and instruct set. The part that tells the system it can be part of the cluster, tells the system what it is. It doesn't count toward the total number of program a node or cluster can run, for all intents and purposes of matrix stats it is part of the node. The point we disagree on is this:

I believe that when those nodes are clustered the ratings change, but their ability to function independently does not. I think this is backed up by the description of clustering for the very reason that it only allows a number of persona (the generating of which is the primary purpose of a commlink) to be generated by the cluster equal to number it's constituent parts can generate. By that definition it is a 'sum of the parts' interpretation. For purposes of matrix interactions the stats change, but the functions of the devices do not and thus a clustered drones ability to pilot itself individually with the stats it currently has.

I know. Peripheral devices have a listed Persona limit of 1, but they can't actually support a Persona. I can only deduce that it's (1) for the purposes of clustering.

It's from Arsenal.

I'm not treating Pilot like a program, and I never have. I've repeatedly said this: Pilot *is* System, and the cluster has only *one* System. Yet, each drone requires its own distinct Pilot.

My counterexample for 'sum of the parts' was the fact that Peripheral devices can't support any Personas, while a cluster of them can.

One program for purposes of sharing, you're assuming that the System/Pilot rating of the cluster is one entity. I contend that they are a gestalt, a whole with the capabilities of the parts but the resources shared according to the rules in Unwired. I don't see why the rules would limit a cluster of drones as to their number of actions per round.

Where is the persona limit listed for peripheral devices?

It's in Unwired, under the Peripheral Devices section (IIRC). But SR4A specifically says they don't actually support Personas on their own (as they shouldn't).

I am indeed assuming the Pilot/System of the cluster is one thing, because the rules say it's one node. Your position is also possible. I believe that things in a game system should be tradeoffs, that's all.

Consider this possibility: the drone cluster results in a unified 'gestalt' Pilot, which treats all the drones as one disconnected body (appendages). It controls the new cluster-body as a cluster-Pilot, which means it gets the normal number of IPs and actions to use on all appendages. This hypothetical allows for the Pilot to be the sum of its parts, but also to be limited by the unification.

I think i pointed this out above. Pilots get 3 ips, spread across Y nodes. Makes sense, right?

Each vehicle still needs a complex action each turn to control, per the usual rules, or risk crashing.

Suddenly, it really isn't feasable within the rules. 3 actions between two 'appendages' still only leave 1 action left to split between two drone bodies.

I agree.