Lets say I have a node with the following attributes:

Firewall: 5
Response: 4
Signal: 4
System: 5

It's persona limit is 5 and it's processor limit is 5, right?

Now let's say it's running an MCT Bloodhound rating 4 with Analyze and Track at all times. Does that count as three programs against the processor limit or can the Analyze and Track be run on the Bloodhound itself, since IC is sorta-kinda an agent? (or am I way off the beaten track with that idea)?

Now what happens when an alert triggers and the node launches an MCT Shinobi rating 4 (Black Out, Attack, & Armor). When it appears in a puff of smoke, do all of its programs apply against the processor rating as well, causing Response to drop to 3?

Thanks!

By node, I'm guessing you mean a nexus? Because only a nexus can have a persona limit above 1. Everything else has a persona limit of 1. This is also the only way the System can be higher than the response and still work at full effectiveness (see pg 222 SR4A).
Anyway, that doesn't really matter either way in your example since the persona limit only applies to actual people online.
Unless a piece of software has the ergonomic option, it counts against the processor limit of a node, even if it is loaded into an agent or IC. So in your example, the MCT Bloodhound plus it's software load counts as 3 programs running. Adding the MCT Shinobi adds 4 more to the processor limit so yes it would drop response to 3.
Easiest thing to do to prevent this is adding Ergonomic to the software. Or buying a better nexus.

no, a Commlink's Persona limit is always 1.

A Nexus has a seperate Persona Limit that is independent of the response.
It counts as 3 programs for the processor limit.
When you launch the Attack IC, then your response would drop to 3.
System cannot be higher than Response, so your system should be a 4, not a 5.

Persona limit is a stupid worthless stat.

An IC is basically just a specific kind of agent, and for the most part any rule that applies to an agent applies to an IC as well. As for if the programs run by an agent/IC count, I think that may have changed between printings at some point, so I'm not sure what the current state of things is. I'll leave that to someone with a more up-to-date book than I have.

Ah, I was thinking the persona limit was the same as system, but I also thought it actually mattered. but since you can still log onto a node without it coming into play, I'll probably just ignore it for the most part.

I found the bit about loading programs onto agents. You can load as many as you want on an agent or persona, but if they're run they'll count against the processor limit.

I didn't know about the Eronomic option. I'll add that. Thanks!

This is the node. It's the control node for a Mitsuhama StaySafe (i.e. MCT's version of the armored limo). How does it look?

Firewall, System, Response, & Signal: 5

Sculpting: Internal and external cameras ensure that the interior of the node looks the same as the interior of the car, though people who do not represent personas are translucent.

Hardware: Custom Commlink (internal to the vehicle and protected by its armor)

Authentication: Passcode (known by driver and primary passenger). This vehicle is part of a fleet belonging to the MCT towers in downtown Seattle. When a vehicle is checked out the passcode is chosen by the executive. It is wiped when the car is returned.

Privileges: All privileges moved to Admin

IC: MCT Bloodhound 4 (Analyze & Track, loaded), MCT Shinobi 4 (Blackout, Attack, each with Ergonomic)

Resident Programs: ECCM 5, Analyze 5, Track 5

ARC: Launch IC

Topology: Single node.

Spiders: One driver. He is not a hacker or cybercombatant, and if an unknown persona logs onto the node he will log off and begin driving manually.

I don't think you'd want to force everyone to have admin rights to do anything with the car.

For instance a limo would probably have all sorts of entertainment and informational subsystems that would probably run at user level. Further you'd probably want maintenance employees and even the driver at a lower level of privileges or it becomes too easy for the shadowrunners to target the driver while he's off duty.

If he's a VIP his security team will probably also want the ability to at least command the node and engage autopilots, etc.

If it's meant to be a secure base for a Johnson you might want to upgrade the signal a little as well. 1km range for signal means that in areas with light wireless backbone coverage the Johnson might be out of range for any overwatch from a rigger in a secure location.

Personally if I was designing a limo for highly valuable passengers I'd not only want the driver to be able to control the car but to also have a spider back at home base capable of jumping into the limo should a panic button be pushed.

I dunno. This is an armored security version, right? No entertainment. But security accounts make sense from a fluff POV, if not 'optimal hackproofing'.

Thanks! That makes a lot of sense. I was thinking of it just for this one guy, who has his own nice commlink for entertainment. I hadn't thought of the whole "ecosystem" around the car that keeps it running.

Why Not? Valid Access incurs no penalties. Individuals who are meant to maintain the vehicle will have the correct access. Hackers are FORCED to hack it at Admin Level for ANY Access whatsoever.

Because you don't want the mechanic to be able to delete other people's accounts and have all the various other admin level privileges. Both because trusting the mechanic (or anyone that you don't have to for that matter) that much is bad in and of itself, and also because the mechanic could be very easy to bribe. Yes, it is more secure from direct hacking, but it is much less secure to social engineering and spoofing, because now all you have to do is figure out the mechanic's access ID and you have total control of the limo.

As for the original limo post, I'm somewhat confused as to the point of having a driver if the limo will simply be using GridGuide unless hacked. It wouldn't be very difficult to mess with the GridGuide system itself and send the car fake info saying that red light up ahead is actually green.

I guess you trust everyone pretty well, then. (Ah, ninja'd by Ghost! I agree, anyway.)

Like I said, it's too bad the 'optimal' game mechanics pull you away from a fluffy or realistic setup.

I agree that layered Access is the best solution, but nothing requires it, and if you DO Trust those with access, what does it matter? Also, you CAN remove specific things completely, even from Admin, if you so desire. The ability to adversly edit the Log File is one mentioned in Unwired. Just because it is less than optinal does not mean that it is never used. I have seen this IRL at some locations in the past. And many companies still do stupid stuff like this, even today.

Good point: I meant 'realistically or fluffily *good*' setup.

Yeah, but if you set everything up so that it can only be accessed by admin accounts, and then limit certain admin accounts so that they basically only have the powers of old basic or security accounts, then what you've done is show that all hackers should always have to hack into admin accounts, because there is no point what-so-ever in actually having any non-admin accounts. It's a classic case of "Yes, you can do it, but as soon as you do, doing so becomes pointless." Kind of like emotitoys. Yes, you can get them, but as soon as you do, everyone else does, and all you've accomplished is that everyone spends 600 nuyen and carries around little toys, which means all you've accomplished is to make everyone in the world have a little toy. If you make non-admin accounts pointless, then there will never be non-admin accounts.

The driver is driving at all times, it's just that usually he's doing so via VR in the node. If a hacker pops in he'll use his next action to log out rather than risk getting hit by Blackout. From then on he'll be driving with AR and a steering wheel.

The car will be driving someone into a rougher neighborhood and so won't be on GridGuide a large part of the time.


I've seen some pretty stupid stuff too, but this is Mitsuhama. If they can't get it right, there ain't many people who can.

I suppose I don't see the benefit of driving via VR while actually in the car. I mean, I suppose if the driver has a control rig and other things to boost her VR driving skills, there might be some, but I'd think you'd want the driver driving manually normally, and switching to VR when there is danger to get the boost to skill. It also might be a good idea to simply block all incoming connections (or just not have wireless enabled at all while in use) to prevent hacking. Much simpler than having the driver switch driving styles, since wireless isn't required to drive the car via VR. Could use a fiberoptics cable, skinlink, or a network with such a low signal rating that it doesn't extend outside the car itself.

Yes, much simpler that way. Then you can have it be essentially unhackable and not go down the slippery 'all admin accounts' slope.

If the vehicle absolutely requires some kind of outside matrix link, you could have a second commlink which has no control over the vehicle at all (or even connection with it) and keep the vehicle's commlink connected only by fiberoptics/skinlink to the driver. I suppose this might create problems with no outside rigger being able to jump in and help out if the driver goes down for some reason, but you might have contingencies such as the driver having a vitals detector of some kind, and the vehicle's commlink switching to wireless mode if the driver is taken out so that a remote rigger can jump in to drive the client out of trouble.

You might get more IPs, for one thing. *shrug*

I, too, like the isolated systems approach. The untouchable system is the most secure, and it's fine when there's no need to touch.

because response 5 + driving skill + control rig + control rig nanite + vr is way easier to put together than agility+driving skill

Yeah, more IP, very likely. In which case I would think the driver would either 1) use the VR all the time and never have any reason to ever pull out of it while driving or 2) use RL driving when things are normal and switch to VR only when there is trouble.

I think the second solution might be more common due to a combination of appearance for sake of the client, and comfort of the driver herself. If reactions are heightened thanks to VR, that 1 hour drive is going to seem like a 3+ hour drive as far as the boredom/distraction factor is concerned.

Still, 1 could certainly be possible, depending on just how dedicated the driver is and just what kind of personality she has.

Note that the Untouchable system means no Gridguide. Whatever path Gridguide is using to get to your VR/AR is a hackable path.

Right, we're talking about the driver driving. GridGuide is GridGuide driving, right?

As the poster said, will be operating without gridguide, so that isn't really a problem. And if you need directions to a place, well, that is what the second commlink is for. It is possible that the directions could thus be hacked (not to mention giving away the destination of the limo) but the limo itself would remain quite unhackable.

You cannot be told what The Matrix is, you can only experience it for yourself...

Gridguide doesn't drive. Gridguide gives bonuses to the driver. That driver can be the pilot program but it can also be a character. Pg102 Arsenal.

While I'm not aware of anywhere where being on gridguide is mandatory, it wouldn't surprise me one bit if such an area existed. I can easily see (as an example) Manhattan require Gridguide for all traffic. (I can think of any number of reasons why it would and none why it wouldn't.)

It occurs to me that for driving in traffic, if you're really worried about your car being hacked and make it unhackable, all the hacker has to do is start hacking the cars around you. I'd just start beating you up with other cars and since you're NOT on the gridguide, I can possibly use the hacked car's connection to report you as the cause of the collision.

Which is bound to have no end of exceptions to it (government vehicles for example), and could easily be tricked by the use of that second commlink I suggested. You have it hooked up to gridguide, so you meet the requirement, but you don't actually need to use it.

That appears to be a 'GM discretion' optional effect, but okay. I always had the impression it was autodrive: "Tuesday hopped into the driver’s seat again, cutting the GridGuide controls and driving manually." SR4A p39

If GridGuide is just OnStar, then we don't really care at all. Hacking it wouldn't matter. I can see how isolating GridGuide data from the VR driving node could be tricky, but I don't think it's impossible. The easiest thing would be to lie and screw GridGuide.

As for the rest… so? There are literally infinite options for the aggressor. *shrug*

GridGuide is like a GPS mixed with live (mm accurate) traffic and other things such as the condition of lights and so on, what makes it special in SR is that it can interact directly with the pilot. Thus if you are running the vehicle on pilot and using GridGuide so it knows where it is going, the GridGuide could be hacked to tell the car it needs to go another direction, or that a stop sign isn't there, or that a stop light is green instead of red, or that there is a turn where that building is, or that there aren't any cars on the road and the speed limit is 200 and various other things that could cause the limited AI of a pilot to crash the vehicle. Even people could react instinctively to the ultra-precise directions of GridGuide and turn when they shouldn't before they notice that anything is amiss.

So no, hacking GridGuide doesn't give direct control over the car, but can potentially give you significant control over it.

Not with a driver. And I don't think that's what suoq meant. I think he meant you had to have wireless active to use it, that's all. I still say a creative security professional could either get no-GridGuide clearance, or fool it.

It could likely fool to some extent an unskilled/distracted driver, but it works best on the pilot for that. And like I said, that is why you have a second commlink that has wireless access, but doesn't have any access to the vehicle itself. Thus you run gridguide on the dummy commlink to fool any kind of law, but don't actually pay any attention to it. Also, I agree that it is quite likely an armored limo would likely be able to get no gridguide clearance for zones that require it.

You'd also need sensor feeds, etc. But that's just details.

Does GridGuide require sensor feeds? I mean, I know it does to give you AR overlays and such, but I wouldn't figure it would need them just to access the service (What if you like retro/antique cars?).

It does. If your car is old, it must be upgraded. No doubt anyone could use the GPS and traffic data, but we're discussing areas that require GridGuide for tracking/safety reasons. You'd need to send the data, or in some way pretend.

Neo-Tokyo requires all cars to be on gridguide, because they do super-controlled traffic patterns.
My understanding is that gridguide controls the flow of cars (so they don't need traffic lights)

GridGuide uses algorithms based on fish schools and bird flocks to try to coordinate overall traffic so everyone gets to their destination as fast as possible. So it requires people to inform GridGuide of their destination, in order to optimize traffic routing.

Since there actually exist spoof chips for GridGuide, I think it's pretty close to being mandatory. Not using GridGuide will draw police attention, I think - it's considered unsafe and antisocial, because you're inhibiting the optimization of everyone else's driving patterns.

As for driving in VR: in VR the thresholds for driving tests are reduced by 1 - a pretty sweet bonus.

---

Of course, this is MCT. I'm sure their armored limos will have spoof chips; they'll deny it publicly, but they'll use them if necessary. They can afford to pay the fine for a traffic violation.

And I'll agree with that.

If you're getting the no-grid clearance. no issues.

If you're fooling the GridGuide every time you take out the limo you've added a hassle factor (If you're not successful, the limo passengers are not going to be happy) and either an additional employee per run (the security professional) or a very talented multi-skilled driver played by Jason Statham.

When the state monitors people, an expensive vehicle that is taking steps to avoid being monitored is going to attract attention. Yes, you can run the vehicle on a second wireless system, send false data feeds, but at some point, one of these things is not like the others. Ignoring rules and going for logic for the sake of an example, you could even set up an entire second sensor array for the gridguide node to help avoid detection but at some point it becomes clear that this is getting expensive and complicated for very little benefit.

Actually, that's exactly one of your options. You're already building an armored limo, so money isn't the issue. An extra node with the basic GG sensors is very cheap. Not dirt cheap, but hardly mucho.

VR is being used for the -1 threshold.

Wireless is enabled for a couple of reasons. One, it's the law in many neighborhoods they'll drive through, and turning it on or off all the time is a pain (plus you're screwed if you forget to turn it back on). Two, the hacker/rigger just joined the game and I want to give him options. He'll probably spend the whole chase driving, but getting into the car will most easily be done by hacking (no external handles/locks, though there are hidden maglocked safety catches if they want to go the manual route).

Well, problem one is solved by the second commlink, but I understand if you want it to be at least somewhat vulnerable for the sake of the player being able to get into it more easily.

I assume it's a lot easier to just have your car connected to GridGuide then try to convince GridGuide that your commlink is a car. But honestly, this is a Mitsuhama vehicle. They're the GridGuide company. If I wanted one of their cars to be off it undetectably I'd just use some handwavium and make it happen.

They have ways of being 'on grid guide' without being 'on grid guide' they use backdoor codes that let them have all the benefits of gridguide, without any of the messy logging of where I am going™.

A second sensor array? Sensor arrays and drones make this confusing with things like the improved sensor array that's required to increase the number of sensors you can mount on a drone to another arbitrary limit with no explanation behind the limit. I can't figure out how, within the rules, a second sensor array attached to a second node is an option. Within logic, yes, but the drone sensor rules found logic in a back alley and beat him senseless.


The total investment should always be an issue. The more that car costs, the more one has to charge for an equal return on the investment.

For my clarity, who owns the car and is this a custom car they they've modified or is this the standard version of that car from the manufacturer?

Well, in real life, Limousines are all custom. So I think an Armored Limo would be custom as well.

Duct tape.

Man, with all the discussion going about this thing, I hope this limo is going to be an AWESOME part of the plot.

Designing security systems in the fictional future is always hard because we're left to make significant guesses as to just how secure something should be, and just what that entails.

If I were you, I'd just design a single-node limo, connect it to grid-guide, but have the driver override and disconnect and drive manually if there's any hacking attempts. That allows the PC's to have plenty of options, and you don't have to get into a bunch of arguments over what would or wouldn't be an option.

Hillbilly Armour Ala Early Afghanistan?

Nope. It's just another piece of equipment in a scene that might not even happen? At least in game. Out of game it's a way for me to exercise my minor skills at matrix security.



That's basically what I did except that the driver is driving via VR because that's the kinda guy he is.