If I Daisy-Chain six drones, slaving them to a rating 3 device (say a commlink with 3s for all stats), and then slave the device to my real commlink, am I getting one or seven subscriptions?

What are you trying to achieve?

I think the answer could be seven, provided your real commlink accepts the connection attempts forwarded to it (Slaving rules are on pg. 55 of Unwired). Once slaved to your real commlink, the unreal commlink won´t accept the drone subscriptions.

Trying to figure out how to have less connections. If it was just one, that'd solve a lot. If it's seven, it's meaningless to do it.

Lump the drones into a single team of six and you have only one subscription. The consequence is that all six drones now all follow the same commands. Can't remember if this is listed in the core book (SR4 or SR4a) or one of the expansions (like Unwired). I've tried looking for the entry, but can't seem to find it at the moment.

Also, per Unwired page 55, any subscriptions you have in excess of (System x 2) count as additional running programs. A commlink with a System of 2 can independently handle the subscriptions of six individual drones at once, but at a -1 to Response, and that's not counting any other software you've got running, like Command, ECCM, and Analyze.

Issue Command (The Precious pg. 229) has the option of sending one command to multiple nodes, Issuing Commands in the drones section (pg. 245, also the Precious) tells you you don´t even need to be subscribed.

add a nexis the the smiley van.

Well, I found where I had thought I read that you could lump a mess of drones into a single subscription, SR4 page 238. Not sure why that part on controlling drones was completely rewritten for SR4a.

There's also a part in that same section that says you could have a pack of drones subscribe to each other to share data and coordinate their actions. I love the thought of a pack of Dobermans, Steel Lynxes, or any other armed drones coordinating a crossfire onto their designated target(s).

I assume it has to do with a subscription being a 1:1 connection between two nodes, instead of a 1:N connection.

The way the wording was changed permits the number of controlled drones and the limitations of control to stay (mostly) the same, while removing the internal inconsistency.

Don't use the insanity that are the subscription rules.

Why? They have worked out pretty well for me... Care to elaborate?

Keep the Faith

AFAIK, the answer above is right: what you're describing is controlling multiple drones with a single Issue Command action. Combining their subscriptions wouldn't make sense anyway, because that's for things like VR rigging. (Edit: Er, that is, things that are different for each drone.)

The point of scatternets is that devices handle the whole linkup and routing themselves. And while all this is assumed to work nice and fine between different PANs, LANs and larger networks, inside your own PAN you suddenly have to specify exactly which device is connected where. Not just that it doesn't make any sense, it also does not add anything to the game or is required to avoid blatant rule exploits...

Like I said Sengir, I am not trying to start something...

But specification of Subscriptions is painless and quick, even if you are connecting to multyiple nets...
I am still not sure what the problem is... I explicitly specify my internal PAN Connections as well as teh large number of Subscriptions outside of the PAN... I don't know, maybe I like that complexity (which, honestly, only takes about 2 minutes to delineate IF I specify each and every connection that could exist)... for the most part, I assign permanent Links within the PAN, and then dynamically assign to my external links when necessary...

Not sure why that is so difficult, but hey, not a problem...

Keep the Faith

If you play how we do it, you can assume that the "interesting nodes only" list, nodes where stuff might happen, will always make for a short subscription list. Clusters plus Slaving (Unwired pg. 55) remove the need for considering the subscription limits unless you are working on coordinated matrix assaults.

Since checking all gear for subscription needs takes time even with proper organisation - as you have to consider different situations - we forego subscriptions until something the hacker wants to do sounds iffy.

Indeed... My subscription list remains very small until, and unless, I decide to go at my objective with all cylinders running... doing so, however, is not a subtle thing, so I do not do it unless I have an absolute need to do so...

Keep the Faith

Even if you could daisy chain the drones (by which I assume you mean have Drone A subscribe to Drone B, B to C, until Drone F actually subscribes to you) then you have the problem of how to issue orders quickly and efficiently across the chain. I think this puts you in the same boat as the easily understood "One subscription, many drones, all following the same commands" rule.

The problem is needless complexity - more rules overhead and zero gain. For players who know the matrix rules it's nothing but a nuisance to manage the lists, for players who don't know them it's yet another reason to be scared of the big, bad, unwieldy matrix stuff.

...Or did I miss something which actually profits from those rules?


PS:

It doesn't matter how many hops are between you and the target node, unless one of those hops involves a satlink

Yes. If you want to play with a detailed matrix for style reasons, the number of target nodes a player wants to monitor can grow fast. Cyberware, team mates, vehicle, three important drones, your home, the safehouse, target commlink, target home... it offers some depth to decide which issues are most important. Subscription limits can force hackers to focus on specific nodes, removing the option of being in every node they own at once, leaving room for surprises.

See, that's what I meant with insanity:

Most of that is covered by Data Requests – and enforcing it otherwise leads us straight to Post #1.
The real fun about that is the tree shaped madness slaved security cameras create.

What I mean is, you still need to be giving "subscription level" orders to all 6 drones; it doesn't matter if you're sending 6 times as much information on a single actual link, you should still need to devote 6 times as many system resources to do it.

...Which brings up the inherent problem with a drone and a chatroom theoretically taking the same number of systems resources to connect to, but we won't discuss that.

Run with multiple commlinks clustered. You can then get the number of subscriptions that you need without having to give the same orders to all the drones.

Okay, I can give you that... for me, the overhead and complexity is non-existent, for all intents and purposes... I perform the tasks as second nature, so I can see that if someone is unfamiliar with the many rules and options, then yes, it could be mind boggling...

I tend to forget that sometimes... But I really do like the complexity and flavor of a fully detailed matrix architecture... even if a lot of folks think that it is needless or too complex...

Having said that, I really prefer the Matrix of 2070 to the Matrix versions that came before... it is a bit more freeform in my opinion, so I don't have to get bogged down in the minutia... with the way it works now, many of the tasks associated with Matrix "maintenance" are attended to almost automatically, which means that I can focus on the real meat of the situation, whatever that may be...

Keep the Faith

Only if the hacker does not daisy-chain subscriptions or install a nexus in the rigger van. Subscription rules don't limit anything.

What do you gain from having a daisy-chained subscription? Your persona is only present in nodes your commlink is subscribed to. You can only use programs in nodes you are subscribed to.

In Unwired, Subscription is a parameter defined for a Persona, not a node. You can't use a second commlink as a hub to have additionnal Subscriptions because your second commlink dosen't have subscription by itself.

You only need subscriptions when you need a fast two-way connexion (as it's said in Unwired), for slaving and crypted communication, so it must be an important parameter for a rigger.

The "crypted communication" part is what truely makes it an insanity.

Why? Please explain...

Keep the Faith

Your icon, the persona is the firmware program inside your 'link which generates your icon(s). Yes, this distinction is important, because your persona stays on your commlink while your icon travels into other nodes

Now, since every commlink has a persona, including the secondary one in your pocket, every commlink can subscribe to other devices and project an icon there. And thanks to the wonders of node scripts you can easily turn a commlink into a switch for drone commands, or tell it to display all data streams it receives to all subscribed users...for example I got one node that is modeled like a CCTV central, with lots of monitor icons representing each connected device.

The persona is a user interface with the matrix, so a commlink doesn't have a persona, it can run a persona, it's not the same. Your secondary commlink doesn't give you additional subscriptions by itself.

If you run the persona on your secondary commlink, this persona may have subscriptions, but you can't control a the same time your main persona and your secondary one (because you only have one head), you could just switch from one persona to the other one.

Your icon is a representation of your persona. Icons are generally representations of matrix stuff.


In a strictly mechanical sense, you are not permited by RAW to take data out of a subscription, put it somewhere else, and still call it a subscription. You can transmit data indirectly with a loss of functionality, IE that you don´t get to roll your own matrix perception against intruders on unsubscribed nodes.

The persona is part of the commlink firmware and runs on the device used to access the matrix. Why should a secondary commlink lose its user interface just because you carry it around in your pocket after subscribing it to some stuff?


@Ryu: Hmmm, I just saw that this is missing in the 4A rules...the original 4th ed rules said that tests in nodes you are not currently active in simply use the program/hardware rating without skill, seemed like a good representation of the fact that the user's mind is focused elsewhere. And of course a GM can and should apply dice penalties if too much stuff is going on at once. Again, nothing you need subscription rules for. If a player is in a real CCTV central with 50 monitors you don't need a rule like "a player can only look at 2xLOG monitors at once" to tell that he can't have a detailed look on all monitors at once.

I'd like to note that this means Subscriptions are a pretty valid -aggressive- tactic, especially for drones burdened down with autosofts, tacnets, ECCM, and a base response of 4(security drones). By opening up network connections - say, to the drones smartgun, which its already authorized to talk to(so a basic account should do) - you can lag its Response(and its dodge pool) down to nothing.

Its not a -great- tactic, but if your Agent doesn't have anything better to do, spam can chip away at peoples response.

My previous message means that your secondary commlink can run its associated persona but the commlink doesn't have a brain so it can't give order to its subscripted devices.

Indeed, a running persona is useless if you don't control it with interface devices (datajack, trodes, RA gloves and glasses...), and you can't control two persona at the same time ("Because no matter how many commlinks you have, you only have one brain. All of the data is going in there, and if you try to use two commlinks at once you’ll get a splitting headache, multisensory hallucinations, and your icons will try to do the same thing on both commlinks at once." unwired page 91).