Daisy-Chain and Subscriptions Options

[AndyZ]

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?

[Ryu]

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.

[AndyZ]

What are you trying to achieve?

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.

[SpellBinder]

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.

[Ryu]

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.

[Triggvi]

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.

add a nexis the the smiley van.

[SpellBinder]

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

[Ryu]

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.

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.

[Rotbart van Dain...]

Trying to figure out how to have less connections.

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

[Tymeaus Jalynsfe...]

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

[Yerameyahu]

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

[Sengir]

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

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

[Tymeaus Jalynsfe...]

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

[Ryu]

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.

[Tymeaus Jalynsfe...]

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 want´s 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

[Minchandre]

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.

[Sengir]

I am still not sure what the problem is...

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:

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.

It doesn't matter how many hops are between you and the target node, unless one of those hops involves a satlink (IMG:style_emoticons/default/wink.gif)

[Ryu]

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

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.

[Rotbart van Dain...]

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.

[Minchandre]

It doesn't matter how many hops are between you and the target node, unless one of those hops involves a satlink (IMG:style_emoticons/default/wink.gif)

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.

[KCKitsune]

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.

[Tymeaus Jalynsfe...]

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?

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

[Sengir]

Subscription limits can force hackers to focus on specific nodes

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

[Ryu]

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.

[Valerian]

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.