Hmm. I just scanned through that thread, and it seems to largely be discussions about what fancy tricks would work for protecting drones. I've been thinking about this a little myself, and here's what I've come up with that has a clear basis in the rules:

To protect against hacking:

• Upgrade the drone's Pilot and Firewall. Pilot is the equivalent of System on a drone, and thus it requires upgrading Response first. You can run Firewall 6 on any hardware, though.
• Run agent(s) to defend the node. In order to avoid a response decrease on the drone itself, you could buy extra commlinks and run the agents there, and then the agents log into the drone and watch for intruders.
• Encrypt the device. A hacker would have to successfully Decrypt the node before he could use the Command program to control the drone. This one isn't quite clear in the rules, but there's a thread with some clarifications here.

To protect against spoofing:

• Upgrade the drone's Pilot and Firewall (see above under hacking defense).
• Encrypt your connection to the drone, to make it harder for the attacker to determine your access ID.
• From the FAQ, "You can tell a Pilot to ignore certain commands or to only follow pre-specified commands", which limits the damage a spoofer can cause. For example, you could tell your drone to ignore orders to kick you off or transfer command to anyone else.
• The FAQ also mentions that the GM can "apply a dice pool modifier to the hacker for the Opposed Test equal to -3 for security privileges or -6 for admin privileges" for spoofing tests. You could configure your drone so that it only takes combat orders from an admin account. It's up to your GM, but you can try to convince him to go with the idea in the FAQ and impose a penalty on spoofing commands to your drones.

Finally, there are a few things that aren't really extra defensive measures, but you should make sure your GM takes them into account when hacking/spoofing your drones.

• Your drones will always be operating in hidden mode (unless you have some reason to broadcast their presence). This means that after an opposing hacker spots the drone, he still needs to make an Electronic Warfare + Scan (4) Test (p. 225 of the BBB) to find its node. He can't start his hacking attempt or try to send a spoofed command until then.
• Spoofing a drone requires that you impersonate someone who's currently controlling the drone. If no legitimate user is controlling the drone -- e.g. it's unsubscribed and operating on its own -- then it can't be spoofed (though it could still be hacked).
• From the BBB p.224, "In order to spoof orders, you must first complete a successful Matrix Perception Test on the persona you are impersonating in order to gain its acccess ID." I generally assume that you can make that perception test if you can listen to (decrypted) traffic coming from the controller, but it's not actually worded that way. If your GM wants to make spoofing harder, he could rule that you need to be logged into a node that the drone controller is also logged into in order to examine his persona. That makes spoofing essentially impossible without hacking first, assuming the drone controller has spoofed up a fresh, fake access ID right before the run.

[edit: removed references to System on a drone -- it only has Pilot]

not quite. pilot *is* system. depending on how you read it, the firewall must also be the same, since the pilot rating is also system (though that, at least, is a little more iffy).

as another thought, if you give drones area jammers and have them jam all frequencies except the one they operate on, that means the attacking hacker will likely need to be running fairly impressive ECCM to reach your drones, or figure out what frequency they use. of course, this has the drawback of being somewhat illegal, but presumably it forces the opposing hacker to figure out your frequency, which should take time (i'm not sure if it would be possible, but a jammer that has a strong effect which deteriorates quickly would be useful... anyone know enough to know if that's possible or not? if so, it would be a handy houseruled piece of equipment to have.)

The FAQ explicitly confirms that you can have Firewall higher than System.

You're right on System not being used in a drone, though -- it's only Pilot. I keep thinking of Pilot as equivalent to an agent program, rather than equivalent to System.

I don't think that would actually help. Or if it did help, it would increase the difficulty of detecting the drone's hidden node (up to GM discretion). Once you've detected the node, you presumably know the frequencies it's using, including following any frequency-hopping.

i think the best way of looking at it is that pilot is system with special agent code bolted on to control the drone body.

when it comes to rules pilot == system, no question about it imho...

system and firewall are two separate programs. pilot and pilot are not. it's at least open to discussion. it's not terribly likely to be a problem balance-wise though, so either interpretation should do fine.

"Pilot is used in place of System for vehicles, drones, and agents, but otherwise has the same function as System."

Sounds to me like it's explicitly replacing System and not Firewall. Also, from the description of agents:

"Agents have their own built-in Firewall attribute, equal to their Pilot rating."

Agents are called out as having a special Firewall rating in addition to their Pilot rating, implying that normal Pilot programs don't come with a Firewall attribute.

hmmmmm.... well, at a quick glance, you appear to be right... i had missed that. presumably i had read the part on agents and assumed it was a general rule, not a specific one

which sounds just fine to, i'm certainly in favor of making it tougher to swipe drones

well, a headjammer might help protect you from weaker signals at least. but anyone with a strong signal is gonna cut through even the strongest headjammer with ease, but then i guess that just makes it easier for the controlling rigger to set the jammer to full frequency jam and cut through the traffic using ECCM on both ends. (after all, most drones will have 3+ signal by default, which means the default 3 pilot should be able to run ECCM 3, which is not less than the best headjammer rating possible. furthermore, i wouldn't think it's too uncommon for a drone that you expect to be autonomous to have response/pilot 4 or 5, even as early as chargen, which means it could run ECCM 4 for an effective signal of 8. (incidentally, imo a headjammer should be able to pack more oomph than a mere rating 6, but whatever).

additionally, i would say it only makes sense that direction radio should be a possibility, and as such would rule that you could program your drone (given appropriate software... prob electronic warfare at any rating, maybe add in scan) to simply track your location vs it's location, and use a relatively narrow radio transmission for communication.

cute, real cute.

your not helping the confusion by stating that nodes have attributes. nodes do not have attributes, comlinks and similar have. nodes are just a logical construct on the matrix to help locate and interact with the comlink or other hardware device.

maybe its clearer to me because i have a interest in computers and networking and see that for the first time in ages, the SR matrix rules are, at least in concept, close to the logic of how a real world network functions.

all your problems appear because you assume that pilot is a extra attribute alongside system. its not. just check the pilot entry in the matrix jargon sidebar on page 216.

sure, its under the agent/ic/pilot entry in the price list. but thats because it costs extra to have the decision code added.

sometimes i wonder if not your trying to create the appearance of extra complexity in the matrix rules so that you can flog your pdfs and say "look everyone, the savior is here with his revised religious text" or something like that.

basically, i have yet to find one post from you about drones or matrix rules thats the least bit helpful. more often then not they rather add to the confusion.

...

Would you please answer the points raised instead of being childish? Or would you want to be taken for a child?

I quote them again so you may anser the questions:

-------

It really does not matter to me how you define nodes. I am talking about the thing that has matrix attributes and can run agents and personae. Call it how you wish. It does not change the argument.

Rules should work without background knowledge. But I congratulate you to your knowledge.

Wrong, all the questions in this thread arise, because a pilot is not an agent but an OS. If there was no problem, this thread would not contain these questions. It does, so the problem is there. And there are enough other threads about exactly this topic. You cant ignore that.

Furthermore:

So an Agent needs a Pilot which is System? Well, have fun explaining this . . .

Your interpretation. If that is what is intended its even more confusing and should be errated.

I dont have to, the fact that people ask questions about it and discuss it is enough.

You are free to ignore them.

thanks, i guess. problem is that given how new the SR4 matrix system is, it could fill a book the size of SR4 alone if one where to try and impart a detailed description of all the concepts and other stuff floating around in the text.

huh? what is there to explain? ok, so there is a bit of circular logic in that agents are running on top of system. but if one envision the agent as a kind of virtual computer. or maybe a better ingame comparison is a virtual drone the issue goes away

maybe added was the wrong word to use. maybe i should have written included. you say potato, i say potato

yes, but your not helping to contain the debates by presenting a highly alternate take on the rules. and more often then not the questions could be answered if only the threads from the time around the release of SR4 had been stickied.

people seems to avoid searching, or reading threads that are below the first page or so (the latter not being helped by people accusing them of thread necromancy if they happens to post on a old thread).

so having a stickied forum faq would be highly helpful (any of the moderators watching this?).

the number of threads on a subject do not equal the severity of the problem imo. mostly its people looking to confirm if their take on the text at hand is the "correct" one.

then people like you come flogging their alternate views and presto confusion sets in and a debate starts.

hell, the original starter of this thread is long gone. when looking back, we are into a third layer of debate at least

believe me i try. but that could be seen as agreeing with your take on the rules, something i do not.

THIS is a valid concern.

But then, I make it very clear, that this is my view and not RAW. So there should be no problem.

Would you please now answer my question number 1?

Why do you need the additional entity of pilot (however it is defined) when the entity of agent is already defined, that does exactly what the entity pilot does with existing rule mechanics?

BTW: I could add another link in my sig to a page saying "Hobgoblin does not agree with this" if that would make you happy.

It's the other way round:

Agents are Pilots not running on hardware directly and having an integrated Firewall.
Basic case of inheritance...

No. That's why Agents have a Pilot rating - not Pilots having an Agent rating.

..get some sleep, man.

We are talking about Drone Pilots which are a combination of agent plus OS. Not about Pilot Rating. So, I'm afraid, agent is the basic entity.

If you were right, agents would, like pilots, have a system rating and be, like pilots, an OS. But they dont. Please consult the relevant rules.

No relevant comments? Maybe you should wake up?

a drone's pilot rating is part of the OS. therefore it does not draw on the OS's resources.

additionally, it also means that the drone's pilot cannot move from device to device, but is rather stuck in place.

there you have it; differences between a pilot program and an agent.

No. There is no such term as 'Drone Pilot', and Pilots are defined as a decision making versions of System. Then Agents are defined as independent Programs with Pilots...

Where did you made this up from?

RTFM.
Agents are Nodes themselves and can load (and run) Programs. They can even stora Data within them.
By the rules, you need System to run Programs - so Agents clearly have System... as they have Pilot, and Pilot is defined... yaddayadda. See the picture?

The relevant, though not really polite comment would be:
Stop pulling general assumptions out of you ass about understanding:
The only thing that is obvious from this thread is: You don't understand neither Pilots nor Agents.

--------------

Agents are nodes??? Maybe you should rethink this assumptions pulling thing.
Please see the definition of nodes further up in this thread or page 216 of SR4.

Q.E.D. - no such game-term as 'Pilot Rating'.
Indeed, Pilot is an Attribute, and, as the rule you quoted states, Agents are derived from Pilots.

Yes. They feature Firewall and Pilot(=System), and thus are accessible.
That's what you call a virtual machine.

Let's see...

As Pilot replaces System... yaddayadda.

Agents don't have their own hardware attributes, but they do have the software ones.
Of course, some are limited on Response...

Make it pilot attribute then. What I mean is that it explicitly mean something else instead of the whole pilot.

If Agents are derived from Pilots, I really wonder how Pilots can be a "special type of OS" (SR4 p. 216) . Agents are not described as OS at all.

You can say what you want, but the picture is lacking somewhere.

And again, I am talking not about any background knowledge (concerning your virtual machine example, which might be valid). I am talking purely about rules consistency and understandability.
If agents were virtual machines (and thus node like) this would have to be indicated somewhere in the rules, but it isnt. And there would have to be rules how a virtual node was handled (whoch dont exist). Again I can only point to the confusion in this thread as an example.

When agents were nodes (and they are definitely no nodes as defined by SR4), another question would arise: Why are personae without an agent rating not nodes? Why do personae use the ratings of the nodes they are running on and agents dont? What is the difference except that the "intelligence" part is a brain on the one hand and a software program, on the other?

I can see that the interpretation of agents as virtual nodes makes sense, but the open questions that arise (why doesnt pilot have firewall if an agent has? are you able to hack the virtual node directly, or do you have to hack the mother node first? can you upgrade the virtual nodes system independently from its pilot rating?) are not handled by RAW at all. The concept is in my opinion to complex to be intended for a basic rulebook.

..what do you mean by 'the whole Pilot'?
It's nothing more than Pilot.

Yet they have an OS to run Programs on.

There is no persona without node.

Uh... it's exactly that way for agents.

Because the rules say so and use Device ratings for the rest.

Sounds like hopping nodes to me.

You can't, as the only remaining attribute for Agents (Firewall) is set to an automated value.

I mean Pilot without OS

Once could equally well say, the programs run on the nodes OS, but are only managed by the agent.

No. As you tried to explain, agents have their own independent system and firewall. A persona uses the system and firewall ratings of the node they are running on. Agents dont.

A Persona running on a system 5 node would have system 5. A rating 3 agent would have system 3. Thats a difference.

In an agrument about rules, the phrase "because rules say so" is not really a reason.

Yes, it would, if thought through. But still, there is nothing about that even remotely indicated in the rulebook.

Not System, too? As you explained?

Your node interpretation can be evolved into a consistent explanation. But the rulebook does not support it. If the node interpretation was the intention than it did a really really bad job. (Even worse than I now think it does).

Thank you for the easy to follow list, and in fact that I avoided the other thread was it seemed to be a place for special tricks and other things not accounted for or authorized by the rules. Not that that's a bad thing, but my GM is somewhat of a stickler. Anyway, thanks again.

That's a nice theory, but Pilot is defined as OS+decisionmaking...

One could say that the sky is pink, too:
That would render Agents useless - I leave it up to your understanding to find out why that is the case.

The point is - where does the Persona run, where does the Agent?

Nice one - there is no need for a 'reason'.
It's defined that way and one could assume that it was done for the same reason as Device ratings.

As hopping nodes is defined broad enough, it is.

Well, once more: Pilot replacing System, yaddayadda.

It is consistend enough for the part that is supportted by the book to be used.

How generous of you.

That may be Rob's houserule, but not the RAW.
Per RAW, Pilot can run on devices if those are desired to make decisions, and has no mechanical shortcomings to System.

System, on the other hand, when installed on a vehicle, may not allow the vehicle to steer itself, but otherwise does not has any drawbacks concerning (remote) control, etc.

1) I don't believe Serbitar is missing anything. Pilot is a separate type of System (that follows slightly different rules) that replaces System in the case of Drones. Why have a special case just for drones? Tradition? Why not have special cases for other stuff? (Hacking cyberwear, for example, cries out for more 'special rules' than drones do.) I don't think he's denying that Pilot is different from System, just that it's different without necessity. It might have been cleaner and smoother to have a special type of Agent (with piloting capability) that could have been put on any system, from cars to automatic doors and sprinkler systems. We already have IC as a type of agent, making Pilot into a type of agent would have opened the doors for all kinds of specialized Systems.

2) I believe the idea is that Pilot is an OS with an Agent built in, not an extra program that takes additional system resources. Otherwise you run into this weird situation where the system is taking away the system's resources. Which I don't really have a problem with, but doesn't seem to be the intent of the rules.

3) Agents are not nodes. Nodes are not agents. Nodes are kind of the virtual locations where virtual agents reside and carry out their functions. That being said, the dividing line where one node ends and another begins is non-existent in the rulebook. We all know that commlinks are their own nodes and that this node extends to other devices besides the user's commlink in an interconnected network. At first I ruled that Pilots were their own nodes and required their own firewalls and such, but after playing I decided to treat it as part of the same node as the primary owner's commlink. So the commlink firewall, response, and system applies to all of a user's commlinks, cyberwear, weapons, drones, and other devices. If a drone or other device is encountered outside the signal range of the owner's commlink, it creates its own node automatically (because it can't function without one) using its own hacking stats or device rating and any applicable programs installed (which can be assumed to be copied over by the owner before leaving range or becoming disconnected, if desired). (Agents must reside on one node and cannot be copied. I don't know why - it just seemed in the spirit of the rules.)

4) Reading the rulebook with an open mind is generally good advice, but I fear it won't help much. In this case, I think the rulebook is requiring the GM to make certain judgment calls (read "assumptions") such as when one node ends and another begins, and all parties involved here are working off their basic assumptions. The rulebook fairly clearly outlined WHAT can be done and what can't; I think this debate is on the WHY.

5) Yes, my previous post wasn't talking about house rules. It's on the RAW that System represents your OS and Pilot replaces System, therefore Pilot is a type of OS. Within the game rules, the OS (read "System" or "Pilot") is considered software, but isn't considered a program and Agents are clearly programs installed into a node (which is established by the System or Pilot [read "Operating System"]). In fact, for the purposes of this argument, I'd almost agree with Node = OS, except I think the OS is what makes the Node and Pilot or System is the OS. (Therefore you can't have more than one System [and/or Pilot] rating on a Node, and you need a System [and/or] Pilot on the node.

6) Completely off-topic, almost: For those of you (no names) who are thinking about making your own Wireless World chapter replacements, I'm thinking of reverting back to Mp might be better than using Response. Response doesn't seem to be helping anyone that I can see. I think tracking the Mp cost to run a particular program would be easier for the GM to calculate current Mp available, make more sense for everyone, and really appeal to players who like tweaking numbers like these. It's ridiculous to say that we don't have to track memory because of tech advances in 2070, but then have an abstract Response attribute that dwindles to nothing as more and more requests are made on the System/Pilot (OS).

Who's Rob?

My precise issue is, that I would not add the desicion making part of SR4 Pilot and the OS part of SR4 Pilot together. It is much easier to have a reductionistic approach and let agents be simple programms, and everytime you wnt intelligence, you just let this program run, leaving all the other rules as they are.

But I already said that a couple of times.

Exactly.

But as I mentioned above, the ideal case would be to not intermix the AI part of Pilot/Agent with the System part at all! It is not necessary. Just take your normal node, put a normal agent on it (that uses the nodes System and Firewall ratings just like every other persona does) and let it take the place of the rigger/hacker.

The agent rating only replaces the riggers/hackers attributes. Everything else stays the same.

Thats as easy as it can get. No extra rules needed.

No replacing of System by the agent, no replacing of Firewall, no replacement of anything except the riggers/hackers attributes and skills.

..you know, the times when you had to worry about memory allocation ended with the DOS era.

Perhaps a topic for another thread, but I'll address it briefly. It's often a staple of most cyberpunk literature that I've seen (not that I've seen that much) that included VR Matrix-like interactions, that users always seem to have to make these choices, shutting off one program to replace it with another. In VR, these requirements make sense, as you shut down your 'Book' or 'Phone' program to replace it with your 'Sword' program. So we can presume that software eventually 'catches up' with hardware. And they always seem to turn off programs that they're not using right now (as opposed to having books and swords floating in the air next to them, available for reach at any time).

I'm picturing an idea where available programs for use are limited by the amount of memory taken up on a commlink. Perhaps memory is equal to Response * 100. Programs, on average, would take up Rating * 20 with Agents probably taking up quite a bit more. If you need more memory, you can "allocate it", reducing System by 1 to gain 100 more memory (or perhaps Response * 50). Just messing with the idea though; still thinking about it. I'm also considering making Firewall just another utility program. Thus, an "active alert" is simply an allocation of memory to load a higher rating firewall program.