Are these hosts all within the same corporation? if so then the tally carries across... if they aren't then they would not carry across ... here is why..
once you are in a network, you would relog back onto the LTG as a user from that host that you just infultrated. when you log into host2 ... it appears that you came from host1 but you accessed them from the LTG2.

in Example 2 the tally would carry across because you are in a subsystem.

Exactly. Headware makes perfect sense adding to pools. Thus why Math SPUs and Encephalons add directly to pools. Why should an external deck add to hacking pool, when external decks (RCDs) don't add to Control Pool?

Yes they are. That wasn't clear from the diagram, and the paragraph(s) below explaining it?

...okay, clearly I did not explain the diagram well enough.

The stuff on the right of the diagram--the entire network connected to LTG2--is a corporate intranet--a PLTG, in other words--organized in the heirarchy shown with the arrows. The lines indicate what one host/grid is connected to. Host1, for instance, connects to LTG2 and Host2 ONLY; it doesn't directly connect to, say, Host3 or Host4. Thus, in that particular corporate network, only Host1--the firewall--is directly connected to the LTG; everything else has to go through the firewall to get there. It's a pretty basic setup; I guess I didn't explain it that well.

That's the wrong way of thinking about it. We decided to change this rule to make things less nonsensical, remember? Tally isn't held by a particular user. If you think about it that doesn't really make a whole lot of sense, does it; if you know *which* particular user is messing with the system--the *only* way Tally can come about in the old system--then the moment anyone picks up a single point of tally he should get firebombed to death, instantly. Sure, there's the idea that Masking and Evastion hide what connection you're using, but then how can the system so reliably tag your particular connection with a Tally attribute, but not with the "He's got Tally>0; kill him with fire!" attribute? It just doesn't make a whole lot of sense.

In the new ruleset, tally is a host-wide attribute, describing essentially the "defcon" status of that particular host. The thing is, Tally is a very nebulous thing for a host; it's not really tied to a connection, or a person, or even specific actions, but more like a general state of unease felt by the system itself. Because random bugs and glitches happen all the time, even the most infrequently-accessed server will have a few bits out of place here and there, and thus a small amount of security tally just sitting around, before you even go there, just because these are the times in which we live. Hosts have security tally all the time because they're twitchy little bastards; they have been ever since the first Crash.

Essentially, it comes down to: the host doesn't have tally just because you logged on; it has Tally because you're not the only user who was online today, and the host does other things in addition to catering to your every illegal whim.

Now the reason for the encephalon was its cognitive multitasking right? Does your comment regarding bypassing firewalls refer to logging in onsite to avoid the firewall/chokepoint?
If so, do the aforementioned host logons and access ratings along with chokepoints already represent the aim of tunnelling?

So many questions - hopefully this is constructive.

Yes, I should have been using "chokepoint" instead of firewall, and an intranet is, in SR terms, a PLTG. Unfortunately I seem to be mixing a lot of RL computer terminology in with my SR terms, mostly because it's been awhile since I've used the SR terms themselves.

Er, right. Sorry, I was already assuming that the Encephalon would be the new one, capable of sustaining a few Monitored Operations for you. Guess I was getting ahead of myself there.

Absolutely. When you go onsite you don't have to worry about Matrix chokepoints, as you can plug directly into the target host.

Yes; it's basically an additional penalty that you accrue as a result of having to go through the chokepoint instead of going directly to the target host in meatspace first. A reason for the decker to get out of the house, as Platinum put it.

My opinion is that maintaining a connection through a chokepoint should not be a free lunch. That is, if you're trying to deck a system that has a chokepoint between you and your target host, there should be some small amount of sacrifice going on to keep the chokepoint from detecting that you're essentially reaching your hands through its space to get at your target. Thus the Monitored Operation and introducing the idea of "tunneling".

Oh absolutely. I realize that I'm kinda getting ahead of myself alot of the time when I'm proposing ideas and talking about them. I don't think anyone wants to read a 30-page treatise on a proposed set of rules, so I try to condense things as much as possible, with the result that often what I'm saying isn't very clear. I apologize.

Absolutely. This is why I proposed the change here too...

You know, I need to number the proposed changes I put into that post, don't I? Okay:

1. Security tally is held by the individual host, on the host level, not on an individual level. Think of security tally as a condition monitor attached to the host itself. Rather than measuring damage, however, it represents the level of suspicion of that host that something weird is going on, the "defcon" status in other words. As tally goes up, the host becomes more suspicious that something is going on, and allocates more resources to dealing with the problem.
2. RTGs don't pass tally RTGs, since they cover such a wide area, don't pass security tally or anything else down to "child" LTGs. Note in the example above there are no arrows, and thus no tally propogation, pointing from RTGs to LTGs, or vice versa.
3. LTGs do pass tally, but do not receive tally. Since an individual LTG does serve only a few blocks or so, do pass tally down to the hosts connected to them. Note that the LTG doesn't particularly care if one of the hosts connected to it is spazzing out; security tally does not propogate back to the LTG from any individual hosts or PLTGs attached to it. This is noted by the single-direction arrows in the diagram above.
   • 1 and 2 together serve to make RTGs actually different from LTGs in more than just name and coverage area.
4. PLTGs share tally and alert status between all internal hosts. Hosts linked together into a PLTG share security tally between them. In addition, a passive or active alert is passed along, so if a single host on the system goes to passive or active alert, they all do. This is indicated by the bidirectional arrows between the hosts in the diagram above.
5. Monitored Operations are now easier AND harder. It totally mystified me as to why it took a Free action every INITIATIVE PASS to keep a monitored operation going. Why should someone with four init passes have to spend four times as many actions over the same time period as the one init pass guy to do the same thing? So, this rule proposes that monitored operations require a SIMPLE action to maintain, but only once every COMBAT TURN, instead of init pass. I'd even be tempted to say a Free action every combat turn, but that might be too good.
6. Encephalons can help maintain operations for you. This one's actually going on over in the Cyberware thread, but it bears repeating here just as a reminder to everyone.
7. Connecting to a host via another host imposes penalties. This is meant to be a more sensible way to get the decker out of the basement and encourage him to come along on the actual run. There are two penalties involved here, but note that neither apply to going through an LTG or RTG. I figure those would be better designed to allow connections through them, and it would be far too harsh to impose three levels of penalties before even getting to the target system.
   1. A penalty to Matrix Reaction, determined by the security code of the host. Honestly I think the penalties are a bit harsh, and would limit it to Blue/Green=0, Orange= -1, Red= -2, but this is Platinum's idea so I left it as-is. Note that this applies regardless of the legality of the actions involved.
   2. A new "Tunnel Connection" operation. Connecting through a masked connection and maintaining that masking requires a bit of effort, or at least it should. This rule makes the act of maintaining masking through a tunneled connection--your deck connecting to a host through a connection you already have to another host--a Monitored Operation, which you have to spend extra actions to properly maintain.
8. Random default security tally. "You are not special. You are not a beautiful or unique snowflake. You are the same decaying organic matter as everything else." You are not the only one generating Security Tally. Security Tally can come from other criminals, sure, but it also comes from the random interaction of programs, minor glitches and buffer overruns, any number of other things that may or may not indicate someone's hacking the system! That last part is important, and is why all systems have a few low-level responses to tally before swarming the place with security deckers and black IC. So I added this:
   

Because of this, it's the busier networks--those with lots of programs interacting with each other--that have higher default tallies. It's the only way for Security Tally to make much sense as it is; otherwise the default should be: Tally 1: passive alert; send 100x Black IC. Tally 2: Active alert; send 100x superior-level security deckers. If you have a small amount of tally around just as background noise, then it makes more sense having different response levels like you see in the rules.Any I'm forgetting?

Sorry I skimmed the paragraph below and missed some of the interpretation.

I misunderstood ... since they are both on the same network, I am fine with them sharing a security tally.

I was wondering should there also be a mechanic every turn that allows an increase in tally? as other users goof around in there.

I think if this is the case ... then it would be in a decker's best interest to hack the host and work on resetting the security tally through admin access.

When I monitor attacks on my firewall, I usually watch ip's individually instead of global attacks. I think in general you can tie attacks to an individual ip. Sure there are bot nets that can cycle their attacks, but if someone does that they are usually very sophisticated. Distributed multiblock attacks are not very common place as of yet .. but that could change.

I am fine with the lower adjustments you made ... it was just kind of a suggestion.
You can just make it a flat -1 per hop, to reflect the relay effect. the more bouncing the slower things get. It also helps to offset the really high reactions we will allow, evening the score with ic. Also encourages people to deck onsite or close.

I was just thinking there should be something, and that high level systems would require a little more maintenance, but if you make the tweak to add tunneling, where you have to dedicate a simple action once every combat turn to maintaining the tunnel, I like that a lot. (maintenance can be handled by and encephalon) it also encourages people to hack more satellites because it's 1 hop to cross the country to another ltg and not 4-5.

I am really liking these tweaks.

I agree with the free action/turn. The idea with monitored ops is just to keep your attention, otherwise a 1 action/turn decker would be severely impaired - using a simple action would preclude complex actions.
There was an idea on the forums that an encephalon allow 2 free actions per phase in a similar fashion to an adept power from SOTA 64- its name escapes me.

Or decrease the tally, as the host resolves some issue unrelated to our decker.

On Tunnelling; would it matter how many hosts you pass through or just the chokepoint. A defence to deckers would be to string out many hosts.
I'm think the addition of tunnelling, while well thought out, may complicate decking rules for an effect that can be achieved by increasing the access rating and adding IC to a chokepoint. But I guess it's all optional and it's a modular rule you can add or not.

This could be a new host trick; "Firewall IC"(?) that's found on chokepoint hosts. It penalises deckers reaction but using the "Tunnelling" monitored operation would can reduce the penalty assisted by your "Wombat" utility. 'Cause, ya know, wombats live in burrows down under

Yeah, so what? So a lowgrade idiot can't maintain a monitored operation and work on another at the same time in a combat turn. He'll just have to finish what he's doing before he tries to do the next task. I don't see a problem with that. Besides, despite this even the most lowgrade computer user running pure DNI will have INT+2d6 initiative, meaning everyone will have the possibility of two init passes in a Turn.

Don't let my challenging the idea discourage you btw; I'd actually be perfectly fine either way. I just think this route may be more balanced, as well as help make the encephalon worthwhile.

As to the Encephalon adding free actions, yeah, that was an idea I had too. Well, someone else might have come up with it before that.

Possible, but Matrix work involves a lot of behind the scenes dicework as it is. Rolling for random tally every turn or something seems like extra work for not enough real benefit.

Well the idea is to create a continuing problem. As it stands, once you've passed a chokepoint that's it; the chokepoint doesn't affect you anymore. I like the idea that the chokepoint is still causing problems; even though you're through it, it's still there, gnawing at the back of your mind.

Riiight.

Not at all; to be honest I could care less that deckers have to lay themselves out while decking. Mages do it while projecting and riggers while jumping into vehicles; dealing with a comatose body isn't a problem unique to deckers. Though fully implementing AR would probably solve the problem, I doubt that a full implementation as presented in SR4 would be wise or within the scope of this project.

(Edit): This is not to say that I don't think that AR is not already implied in the rules. Look at the virtual dashboard that you get while jacked into a vehicle, even a non-rigger-adapted one. If you can get an HUD pumped into your brain while driving--in other words, not laying yourself out--to get a bonus to driving, then gatting an HUD while jacked into a computer to get similar bonuses for said computer use should be allowed as well.

What I'm getting at with number 1 is that the sculped systems that are supposed to be everywhere in SR3 decking are a major distraction, and are one of the primary reasons most games insist that the decker is an NPC character. Outside a run, while everyone is doing legwork and such, it's perfectly fine for the GM to go into detail about what this new system looks like, and the details of how to interact with it. But, whenever the decker jumps in during a run, the GM is forced into the awkward position of having to describe a completely seperate visual metaphor for the decker, while feeding the rest of the team the visuals associated with the actual run location. Because of this, there should be an option in the rules that makes it a good idea to not bother with seperate metaphors during an actual run, to keep the focus on the decker helping the team rather than the decker being off on some sidequest.


Even worse, most decker characters need some major DF-twinkage to stay functional in a host for the total length of a run (2). This encourages a hit-and-run mentality for decker characters, making them functionally unavailable for the majority of the run, save for a few small episodes where he completely interrupts the flow of events to zip around his own little sidequest. Put these together, and it's no wonder most people don't want to run deckers.

Well, so far all the rules we've presented that actually impact tally would effectively increase it. Random default tally, penalties for going through firewalls, getting rid of Masking Mode. The only rule we've proposed so far that would limit tally would actually just delay or limit the effects it has on the decker, and that's the notion that IC has to successfully locate the intruder before attacking*. Ideas that would reduce tally would be stuff like these:

1. Opposed rolls made by IC don't increase your tally. Not succeeding in an action against a hostile program is bad enough; no need to compound it by
2. System Operations involving the Index subsystem (Browse, Scanner utilities) don't increase your tally. Especially Scanner, as you're not even really doing anything to the host when you're looking at an icon.
3. System Operations involving the Analyze utility don't increase your tally. Analyze operations are typically information-gathering, and are thus usually not as potent as say a Spoof action. Analyze actions still cost you time and actions; maybe that's enough.
4. Maybe there should be a system operation you can do to lower your tally? Really unsure about this one, but I figure we can throw it out there.

These are all separate from the idea above of making the Reality Filter more common, even making it a default include for all cyberdecks and even some cyberterminals, having it work all the time, and not having it affect Matrix Initiative. I still have no idea how we can balance that to make it something you'd only choose to activate during a run, however.

*While we're on the subject, I think that we should get rid of the table giving TNs for hitting a legitimate icon, and instead make the TN equal to the icon's Evasion rating (or IC rating, as the case may be). Anything that gets rid of a table, especially a table that you have to refer to in the middle of combat, is IMO a good idea.


As for AR, I agree with people who say it should exist, but I also agree with people saying it should not be appropriate for someone who plans on seriously decking. You want to do a little typing, check your email, use a calculator, look up the scores for last night's football game, all while walking down the street or driving your car? Sure (though the later will make an accident more likely). You want to hack into an Orange-hard system and steal a new prototype nuclear warhead or trick the security cameras into thinking your buddy is invisible? No way.

We may want to do that too, if it turns out that the above fixes still don't completely solve the problem. Something else that II, and III do*, however, is help to restore the balance between actions. I mean, clearly Analyze Icon is not as far-reaching or cinematically important a test as Control Slave, but under the current rules both give the system the same amount of power to detect the decker's intrusion. I really think that, like Perception Tests in meatspace, Analyze operations should be essentially "free", save for the actions required to use them. Keep in mind that, under the new "default tally" rule, there will likely be at least one piece of IC out on a given system almost all the time, so spending all day sitting around gawking at everything is a dangerous waste of valuable time and resources.

The same, essentially, for Browse-enabled operations, though admittedly the case is a bit weaker there. I just don't think that Locating an access node should give the system the same power to detect you as screwing with file data.

*-I just noticed that point I is already true, but it really needs to be spelled out in the rules better IMO.

By-the-by, I reiterate my support for the idea of using Evasion (or the IC's Rating) as the TN for cybercombat tests, and the makeup of the IC's Attack program for its damage, rather than the table on page 224. Any time a book table has to be referred to in the middle of combat is a serious design problem IMO and should be remedied immediately.

Well, that's the problem with SR3 decking: none of it at all corresponds in any way to the concepts we are familiar with when it comes to computer use. Most things that are completely and totally impossible, not just merely counterintuitive, in the real world are allowed in SR3, simply for the sake of balance and fun. Most of what happens and what's reasonable in real-world computing and cracking have no place in SR3, and thus should have no place in SR3R unless we plan on fundamentally altering the entire system from the ground up.

There are four priorities here, as I see it. The decking rules should be: 1) Fun and intuitive, 2) Balanced, 3) True to SR3's original flavor and 4) Streamlined as much as is practical. Note that none of these have anything to do with being amenable to RL logic and ideas about computing; most of that goes right out the window when we're talking about stuff that responds to the first three goals, and even the fourth--SR3's own flavor text--is mostly directly contradicts what is sensible in the real world.

As such, flavor arguments should simply hold no water here. The flavor will eventually come to reflect the mechanics, within the SR3 frame of mind, rather than the other way around. I mean, it's not like anyone expects magic to follow RL preconceptions, why should decking when, in all likelihood, computing will be fundamentally different in the next few decades. Hell, quantum computers are already starting to find their way into the commercial sector, though the technology is as clunky as vacuum tubes were back in the day. This means essentially we're one transistor-sized revolution away from quantum computers that can sit on our desk--or, more pointedly, in a small box the size of a keyboard with a port for a datajack.

So let's not get hung up on our late 20th-early 21st century concepts of what a computer is and can do. By 2030-2040 all that's gonna be long gone anyway. The fact that Q-computing will make RSA Encryption obsolete, for example, will simply be the most obvious of our concerns.


Let me give you a bit of counter-flavor, in case you can't possibly conceive of a way Analyze could be different from Manipulate Data:

The term "icon" in SR3 is essentially a small memory address space/processing space that the host has ceded control of to a foreign program, or even computer in the case of user-generated icons. Analyze Icon works by analyzing the allocated memory/processing space of the target icon, a process which isn't protected by the host machine because scanning foreign icons is the primary way in which icons interact. Higher-rating Sensor packages go further than the normal scan, following links into other memory spaces the target icon has linked to, which may be attempts to Mask itself.

Totally contrary to modern-day computing "common sense"? Sure. Plausible in an insane future world where all NP-complete problems can be solved in a flash? Sure, why not?

Personally I don't have a problem with the decker himself being a little (but significant) fish in what sometimes can be a very big pond. We're talking about servers here with hundreds, thousands, even in RTG cases millions of simultaneous users, potentially billions of processes and transactions going on in a second. It's in this nebulous anonymity that security tally, tiny anomalous blips in the overwhelming crush of calculation float to the surface where the system just happens to catch them.

Sure, sometimes there's a decker or virus trying to compromise the system, but if we want the idea of security tally as it currently stands to make even a shred of sense, most of the time tally should be a false alarm. If the only time you ever see a tally above a certain number X, then common sense would dictate that number X be the number that the system auto-destructs at. See where I'm getting at with this? It's for this reason that, far from lowering the random tally table idea, I'm even considering that maybe the dice should have exploding 6s. I have no problem with the decker popping into a system, seeing it's currently having a fit because of a random unrelated glitch, and have to either bug out because the system's too hot or have to power through because he's either unlucky or overconfident, and decides to take it on anyway.

That said, how does that above proposed rule for Null Ops sound?

Heh, all right. Change made to my post to reflect this.

Good point. "Rating + Analyze" is SR4 rules, remember; in SR3 utilities decrease TNs rather than adding to the test. There's already a Locate Decker operation in SR3, p.217, but the rules are kinda odd (hey, look, I found another Open Test!). In fact this kinda brings to the surface another problem with the decking rules:


X) Take the Combine System Operations idea further. Eliminate as many corner cases and special rules for each different system operation as possible, especially the weird ones, like how Locate Slave has a pseudo-Threshold of 3 while Locate Files is 4, or how Analyze Icon lowers the TN by Sensor and the Analyze utility, rather than just a utility. This could take awhile, but will be worth it in play.

Indeed. This also creates the problem that it completely changes the dynamic of deckers from being primarily cash-based to primarily skill-based, which would mean we'd be forced to lower the prices on decks or risk deckers being incompetent long into their careers. I'm not entirely against the idea, especially since SR4 managed to pull it off so well, and we're just about redesigning the decking rules from the ground up as it is, but it may be a bit too much of a fundamental divergence.

Still, it may be a good idea to specify Stationary IC as guarding specific system resources, rather than just "everyone passing by". Movement doesn't really mean anything in the Matrix, so "passing" someone doesn't either.

Good catch, and especially with a rating 6 IC, that can be huge. However I don't think analyze should decrease the decker's Detection Rating, since it'll generally be in the 7-10 range, and a rating 5 analyze program would decimate that, nor does it make sense that analyze work against the Host's Index value, because that would just be sort of silly, making the host work against itself. Perhaps it would be simpler just to use the Locate Decker operation and replace it with an Analyze test vs. a TN of the Detection Factor?


Your 'X' I tucked in at C, since there's space there. Hope that isn't a problem.

I did make that specification. I know I tend to forget about the Matrix's odd sense of reality and physical layout.

Hm, maybe. I don't like how Detection Factor is used for everything, however, maybe instead...

Y) Extensibility guidelines for Matrix Attributes: what's the difference between Evasion and Masking?
Y1) Evasion is your Matrix agility. It is the ability of your deck to keep out of sight of other Icons, out of Matrix combat, and other things. Evasion is the TN for targeted attacks made against you.
Y1-i) Interception Factor (IF) starts at Evasion*2 (Rating*2 for IC)
Y1-ii) Interception Factor is the TN that Trace IC uses to lock onto you.
Y1-ii) Interception Factor is the TN that other Icons use to find your Icon in the first place.
Y1-iii) Maybe Evasion isn't illegal at low levels? Defined like this Evasion sounds something like a spam filter, rather than something aggressive.

Y2) Masking is your Matrix stealth. It is the ability of your deck to keep the host from noticing what changes you make to it, and the internal functions of your Icon.
Y2-i) Detection Factor (DF) starts at Masking*2 (Rating*2 for IC)
Y2-ii) Detection Factor is the TN the host uses when resisting any changes you attempt to make to it.
Y2-iii) Detection Factor is the TN that other Icons (such as ID or security deckers) use to Analyze your icon for anomalies.

Y3) Two types of scans for other Icons: (clarifying page 209)
Y3-i) Simple Scanning is a Free Action, something your deck does almost by default. Unlike most Matrix operations, this uses your Sensor rating.
Y3-ii) Deep Scanning is a Complex Action. It uses your Computer skill, plus any Hacking Pool you choose to use.
Y3-iii) Either type of scan targets every other Icon on the host. The TN is equal to the target Icon's IF - your Scanner utility.
-1 success: You detect the Icon.
-2 successes: You get a basic idea of the Icon's type (decker, foreign Agent program, IC)
-3 successes: You learn the Icon's Rating.
-4+ successes: For each additional success you learn the type and rating of one random program in the Icon's active memory.
Y3-iv) Successes are not cumulative; each time you run a Scan, the success counter is reset from zero, meaning you can actually know less about an Icon in a subsequent Scan.
Y3-v) "Mobile" IC (see below) use Deep Scans, then Analyze each Icon it detects in random order, looking for anomalies.

Y4) Obscure Icon: Expend actions to increase your IF? Something like make a System test vs. TN of Index-Evasion, successes add to IF for the next X minutes? Not sure about this one.

Y5) Distract Icon: Basically the new Evade Detection; an opposed test of your skill vs TN of enemy's Sensor/Rating, countered by enemy's skill/Rating vs. TN of your Evasion/Rating. Net successes counters scanning Icon's successes, kinda like counterspelling for Scans.

Y5) Analyze Icon
Y5-i) Analyze targets a single Icon, TN of DF minus Analyze utility:
-1 success: You get a basic idea of the Icon's type (decker, foreign Agent program, IC)
-2 successes: You learn the Icon's Rating/MPCP Rating
-3 successes: You learn the Icon's Bod and Sensor ratings, as well as its MXP address.
-4+ successes: For each additional success you choose to either learn an anomaly the Icon has (if any), such as:
--whether or not the Icon has a Masking or Evasion chip, and its rating
--whether or not the Icon is responsible for any tally increase on this host.
--whether there are no anomalies.
or you learn the types and rating of 2 programs the Icon has in Active Memory.
Y5-ii) Successes are cumulative; each time you Analyze an Icon, the success counter increases, and you learn more.
Y5-iii) "Mobile" IC (see below) Analyze each Icon it detects in random order, looking for anomalies.

Y6) Deceive Icon. No idea how this would work. Something like Distract Icon? *shrug* Something along the lines of you can give the Analyzing Icon a "faked" result for one or more of the above Analyze results.


And another:

Z) As it stands, IC has effective Persona Attributes equal to its Rating, while a decker has, effectively, adjustible attributes equal to, on average, 3/4*MPCP rating. Is this okay, or should we consider revising it?

C, eh? Okay then.

Indeed; the way "Stationary IC" were defined before could in fact be the same as your "moving" Guard IC. Distance, and therefore closeness, in the Matrix are determined by the results of Sensor tests--the better your Sensor test, the "closer" something is, and the better you can "see" it--so activated searching IC could very well be represented as a stationary bouncer, watching (Scanning) the icons "near" him.

So, to clarify, we now have two "modes" for IC operation:

-"Mobile" IC- the ones that randomly scan all icons on the host that they can locate, latching onto ones that they detect as problematic. These are the type that are activated by security tally trigger steps. Despite the name, the dominant representation for such IC is that of a stationary "guard" unit, warily scanning the vicinity with his "eyes".
-and "non-Mobile" or "Trap" IC- IC that is always active, but only "guards" a limited number of areas. Say a Trap IC unit is assigned to watch a set of security cameras. Anyone who attempts to access those cameras will be subject to an Analyze Icon by the IC, on the IC's next action, of course.

In that vein, proposed add-ons to rule O:
O-7) User databases will always have non-Mobile IC guarding them, perhaps several, and usually high-rating Grey or Black IC. This'll help solve the "Validate makes the world obsolete" problem without smaller companies having to make separate hosts for user databases.
O- (mostly flavor issue) Hosts can have a maximum number of total IC equal to the security rating times the security level (blue=1, green=2, orange=3, red=4), but can only support one-fourth that amount of Trap IC.

7 - I think this would be determined by the host, not a set rule. It's 'best practices', but not something that is mandated and automatically installed on every host commercially produced.

8 - I'm not huge on this one. It adds complexity without clear benefits. If a GM wants to have 10 or 20 probe IC running around on a blue host, he should be able to. The limitation is processing power. Most hosts have a cap on how much IC they put on because they need the processing power for other things, but hypothetically someone could have a host that does nothing but run IC (like say a host in use by people who develop IC programs), in which case the maximum number of IC run would be different.


I think we have different ideas of movement in distance in the matrix. To a degree, I still think similar to SR2. Even if you have a senor rating of 20, you may not be able to access the User database, video cameras and Joe's water club spreadsheet all at the same time. In my mind, a host isn't just a huge pile of stuff you sort through, interacting only with what you can see, but with everything available at your fingertips if you look for it. It isn't a dump truck. A matrix host is a series of tubes. If you're using the camera system and you need to check on Joe's water club spreadsheet, you need to disassociate yourself with the camera program, search for the spreadsheet and somehow 'go to' that spreadsheet, which may involve passing through other things on the way. If you think about a modern folder hierarchy, except... less heirarchical, that's what I have in mind. I don't think my view is contrary to what is in the rules, and I suspect I"m not the only one who holds it. So the defining things like mobility is a touchy subject.


Added "Z" as "E", since that's now clear. And my answer is no, it shouldn't. The current method is nice and simple, no reason to muddy it up. A persona attribute can still be boosted through software though. An interesting note, a legitimate user, someone who does not have masking, has only three persona attributes and therefore each attribute is, by default, equal to the MPCP rating on his deck. It's only by adding the fourth attribute, masking, that we found our decks somehow 'underpowered'.


Ugh... Your huge 'Y' thing I shouldn't have saved this one for last, it's huge!

This is actually filed under V, since I tucked V in another empty spot. Thank goodness, now I won't have to look at two pages of notes every time I glance at decking.


I've written your stuff out, although I changed the format slightly. The bulk of it goes under V, since that's the next available letter. I thought the deep vs. shallow scanning was different enough that it fell under Y, so even if V dies, the idea of shallow vs. deep scanning can be examined by its own merits. Finally, one of the ideas (Deceive Icon) was already touched upon, so I cross referenced, since again, I think that is its own issue.

So I typed it out as such:

L) The decker should be able to directly deceive the IC, not JUST the host
1. Decker should be able to 'repaint' himself and other Icons, possibly confusing the host as to which icon is bad

U) Evasion or IC rating should be the TN for cybercombat tests, IC's attack program for damage

V) Detection factor is overused. Define difference between Evasion and Masking
1. Evasion is Matrix agility, ability to keep out of sight and out of combat.
- TN to hit your icon in matrix combat is based off Evasion
- Interception Factor (IF) starts at Evasion*2 (Rating*2 for IC)
i IF serves as TN for Trace IC to lock on
ii IF affects how other icons can find your icon
iii At low levels, IF is legal, like a spam filter
2. Masking is matrix stealth, the ability of your deck to keep the host from noticing changes made
- DF is Masking*2 (Rating*2 for IC)
- DF is the TN the host uses to RESIST any changes you attempt to make
- DF is the TN other Icons use for Analyze functions
3. Obscure Icon - Complex action, System test vs. TN of Index - Evasion, successes add to IF for X time
4. Distract Icon - opposed test of Skill vs. enemy's Sensor, enemies skill vs. your Evasion. Net successes counter enemy's scanning successes
5. Analyze Icon, like Deep scanning, except successes are cumulative
6. (See also L)

Y) Break scanning into two types
1. Simple scanning, free action, done by default, uses Sensor rating
2. Deep Scanning, complex action, uses Computer Skill + Hacking Pool
3. Both types target all icons on the host, TN equal to Targets IF - Scanner utility, level of success like normal perception test (1 - you see something, 2 - type, etc.) Successes are not cumulative
4. "Mobile" IC would use deep scans, searching icons in apparently random order.


To go over them... I still like L. I liked it when I suggested it. The ability to play tricks like that gives us a wider span of tools to use, and can result in some very cool action scenes, sending the IC off on a false trail.

U was already suggested, but it bears repeating. I still agree.

V I think is a good idea. So far Detection Factor really is the ONLY attribute that really, really matters. Otherwise you get mobbed and wiped in no time. That said, we're hitting into a bit of the issue with IF. In general, our matrix TNs fall into two categories; 4-6, when no utility is used to reduce it, and 8-14, when a utility is basically required. Host statistics are 10-14. Detection Factor is 4-6 (remember, it's an average of the two).

If IF is going to be 2*Evasion, it's in the 8-14 range, and so we need to assume that everyone countering it will be using some utility. What does Trace IC use to reduce IF from 16 to something reasonable? How do other icons ever find your icon?

"DF is the TN the host uses to RESIST any changes you attempt to make" - is this a change from normal, or are you just stating it for completeness?


V1-iii is a given. It's already legal, it should continue to be legal, at any level. Evasion is purely defensive. It's like a firewall.

V3,4 I'm considering. I'd want to see how everything else pans out. I think we're setting it up so at low levels on the tally, it's basically guaranteed you can evade any IC, but once there are multiple pieces of IC after you, you're in trouble. Could be very climactic. Could be a bad idea. Not sure yet. Since both of them allow for Hacking pool to be used though, it definitely favors the hacker, even an average hacker, and means that mid to low level IC are basically laughable except to force you to waste actions.

Please clarify V5. Reading through, they seemed identical except for the note I made.


Y... Neat idea. I think Simple Scanning should be done by default as well as a free action. In addition, I think any icon not trying to hide itself (icons can either have a masking rating, or perhaps can use some other number to hide itself from unauthorized users. No reason to let Joe Blow see your .ini files, even if he can't access them.) But we get into a problem. With your view of the matrix, scanning basically dumps EVERY icon on the host into your field of view. If there are 250 users and 50,000 slave nodes or files, your view is instantly cluttered. Even with filters, it sounds complex.

I'm starting to think that my above mentioned question of space in the matrix is a real debate. If we go with yours, all the icons are in a heap and the tough part isn't finding them, but sorting between useful and useless ones. Mobile IC scans randomly for bad stuff. In mine, the tough part isn't in sorting, but in actual finding and getting to, since you need to know the "folder" or node the thing is in, and you need to actually travel to it. Meanwhile, mobile IC isn't random, since there's actually a node or resource it can start with, and it moves out from there, with everything having some sort of logical position in relation to each other.

Checking the book, I think the problem is because there's a description of a sculpted system. There are buildings, passageways and people, with files and slaves represented by actual items that you have to walk to. Presumably there is an alternative to a sculpted system, but no description seems to exist in the book. So in my mind, when you step out of a sculpted system, you just enter a wire frame version, still with its own topology and relational distances (although not necessarily following euclidean geometry), and it just looks like how we've seen the matrix in innumerable movies. It sounds like you imagine it as a single control panel or even a command line, where everything is at your finger tips and you simply select what you want.

Thoughts? Does this need to be better defined?