Decking, the SR3R way Options

[Kagetenshi]

Navigation:

SR3R Master Thread

Jon’s Glorious Karma Character Generation System (S3CKS)

Ranged Combat

Astral Space, Essence, and the Awakened

New Gear

Cyberware

Time, Pool, and the Flow of Combat

_________________________________________________
Decided:
(All of these are subject to reopening for discussion should there be any strong argument for a different path)
1) Too many operations. What can we combine?

System Operations Quick Reference
Operational Utilities Quick Reference
(Both pretty rough, apologies.)

[ Spoiler ]

<span style='font-size:13pt;line-height:100%'>Access</span>
Deception
Logon
Freeze Vanishing SAN
Graceful Logoff

Encrypt/decrypt

Extensibility: quite simple, really. If it's an Access operation that doesn't involve encrypting or decrypting, it uses Deception.

Commentary: You'll still be using Access as the TN to do things like crash the Access subsystem, but I don't consider that an Access operation per se (you aren't Accessing anything).

<span style='font-size:13pt;line-height:100%'>Control</span>
Analyze
Analyze Host
Analyze Icon
Analyze Process
Inject
Abort Host Shutdown
Block System Operation
Crash Host
Alter Icon*
Redirect
Decoy
Redirect Datatrail
Relocate Trace
Validate
Dump Log
Invalidate Account
Restrict Icon
Validate Account

Extensibility guidelines: if it involves analysis, stick it under Analyze. If it involves interfering with a running process, use Inject. If it involves falsifying data or otherwise confusing system monitors, Decoy. If it involves logs, user accounts, or using the system's own security systems to allow you to do something or disallow someone else from doing something, it's a Validate issue.

Commentary: Altering an icon at will seems similar enough to the idea of injecting arbitrary code that I stuck it in there with it. Opinion?

<span style='font-size:13pt;line-height:100%'>Index</span>
Browse
Locate System Resource
Trace MXP Address
Scanner
Locate Icon

Extensibility guidelines: If it's finding something that's a basic part of the system or can be considered a file, folder, subsystem, whatever rather than an active user (keeping in mind that processes can be users too), it goes under Browse. If it's finding something that has an icon, it goes under Scanner.

Or, to simplify it further: if it moves, it's Scanner. If it doesn't, it's Browse.

Commentary: Self-explanatory, I think. We'll need to define what a system resource is or come up with a better term, though.

<span style='font-size:13pt;line-height:100%'>Files</span>
Read/Write
Manipulate Data

Encrypt/Decrypt

Extensibility guideline: this one's really pretty basic. If it has to do with reading data from or writing data to something that isn't a slave or protected by special permissions (logs, user databases), it goes under Read/Write.

Commentary: something about Make Comcall being here doesn't sit right with me. Any thoughts for a better place to put it? Possibly combine Commlink and Triangulate and put them both under Slave? Update: Done.

<span style='font-size:13pt;line-height:100%'>Slave</span>
Spoof
Control Slave
Edit Slave
Monitor Slave
Commlink
Make Comcall
Triangulate

Encrypt/Decrypt

Extensibility Guideline: if it's a slave node, it falls under Spoof. This one's really easy as long as you don't try to make Slave do something that Slave shouldn't do.

Commentary: The exception is for cases like Triangulate. Is there another case someone can point out where additional information might be gleaned from a Slave that would need a program to calculate? Also, see Files commentary. Update: Triangulate no longer uses a separate utility.

<span style='font-size:13pt;line-height:100%'>Other</span>
Analyze
Analyze Subsystem
Inject
Crash Application
Purge
Disarm Data Bomb
Disinfect
Relevant worm
Infect
Sniffer
Intercept Data
Commlink
Tap Comcall
None
Swap Memory

Encrypt and Decrypt
Separate utilities, but it makes little sense to discuss them separately.

2) Validate makes the world obsolete.

Validate and Invalidate Account can only be performed on the main user database, which may be protected or on another host altogether and must be found first. Other functions of Validate may be used anywhere.

3) Program sizes: needed detail and balance, or needlessly complex? Moreover, do we need active memory? Does it need to be adjusted?

Program sizes are maintained, as is active memory.

Possible issue: this may make it too easy to program necessary tools. This will be looked at again when programming is considered.

4) Link Utilities: do we need them?

No. Link utilities are now gone. The appropriate hardware is all that is required to use a wireless link.

5) Null Operations: what the hell do we do with this?

Nothing. Rules stay as is.

6) Sleaze+masking: keep or toss?

Sleaze has been dropped. Masking alone now determines Detection Factor. Modes are dropped until they can be examined in detail.

7) Combat Utilities: how are they going to work?

Attack utilities use decker's skill, with program rating determining attack Power. Killjoy and Black Hammer determine their damage level based on the host they're on; the explanation for this is that the utilities involve using the host's processing power against the opposing decker. The Power remains the rating of the utility.

8) Guardian: do we need it? Should it be software?

Guardian is now gone, and will be replaced by appropriate security hardware.

_________________________________________________
In progress:

9) Maneuvers

Beneficial? Overly complicated? Rarely useful? What needs to be changed about these?

10) Multiple Deckers

What the Sam Hill do we do with these? Possible solutions:

1: every user has their own security tally, which follows them as in canon SR3. The highest of all the tallies on a host is the one that determines IC, and only one copy of IC shows up.

Issues: too easy to mob and overpower IC with a decker pack.

2: tally is held by the host and follows deckers amongst security-linked systems, but not elsewhere. Tally is equal to the tally generated by all deckers on the host.

Issues: makes tally generated on a RTG not worth bothering about.

3: Both the user and the host have tally counts. Every point of tally gained on a system adds one to the tally of the user who triggered it and to the tally of the host itself. Anytime a decker joins a host that has less tally than he or she does, the host's tally rises to equal that of the decker.

Issues: involves the most bookkeeping.

_________________________________________________

Let's limit our scope. For right now, we're just going to be talking about the old-fashioned kind of deckers (we're not addressing Otaku yet), and addressing only basic system tests. No cybercombat, no writing programs, no types of connections, just straight-up skill and program and operation, plus the host. In fact, let's not even take deck attributes into account yet except for Storage Memory, Active Memory, and MPCP.

The way I plan to do this is to take the current system, pare it down as much as possible without losing anything important, and then see if it's playable alongside meat action by someone who is experienced but not a master of the relevant rules. If not, we start looking at more drastic action.

The most obvious possible issues

1) Too many Operations. What can we combine?

Currently, Logon to Host, Logon to LTG, and Logon to RTG are all Complex actions that use Deception to go against Access. The only possible reason I can think of for this is to balance the Codeslinger edge (and the Codeblock flaw); the clear answer is to eliminate that edge/flaw pairing and combine them into a single Logon operation.

Other combinations are more tricky. Edit Slave and Monitor Slave are both monitored operations that use Spoof against Slave, but they do different things and take different actions (Edit is Complex, Monitor is Simple). Do we combine them? If so, do we make them both Simple? Both Complex? Leave a note that one use is Simple and the other Complex? If so, why?

2) Validate makes the world obsolete.

Pretty much what it says. My idea is to either get rid of Validate entirely and introduce a suggested mechanic (probably just a glorified example) for including a user database in a host that players can edit over the course of a number of operations including Search, Read/Write, and possibly Decrypt. Alternately, Validate could continue to exist (allowing editing of user databases more easily), but it would still take at least a Search to find it. User databases could be kept on different hosts entirely, making it a valid decision whether or not to try for a fake account as opposed to a no-brainer on anything but the most jacked-Control hosts.

3) Program sizes: needed detail and balance, or needlessly complex? Moreover, do we need Active Memory?

I personally think that the current method is nicely balancing. However, I'm not sure it's balancing enough to be worth the extra work. Discuss.



Feel free to suggest other issues, but please keep all discussion on these three topics until I introduce additional topics for consideration. Ideally we'll have at least one, possibly two or all three with at least a preliminary solution before we move on to the next set of issues.

~J

[Fortune]

Are we assuming that the Matrix stay as it is already depicted in Shadowrun, and pretty much ignoring the advent of the WMI?

[Kagetenshi]

Yes. We can add on rules for the WMI as needed later; at the moment, I am assuming that the Matrix works like it does in SR3, and that if the WMI exists it's just another method of accessing it. I don't know about you, but I think this whole project is ambitious enough without creating an entirely new paradigm for the Matrix from scratch if we can help it :)

~J

[Fortune]

I just figured it was something that should be clarified right from the start.

[Kagetenshi]

Good catch, thanks.

~J

[Elfie]

I'll take a stab at the questions you listed. Of course this is just all running from opinion.

1) All the logon's are there for a reason, but there never was a rule saying a GM had to use them all. If I'm sitting at a wireless point in a city, lets say, and I want to hack in to the government's matrix, first I'd have to get access to the matrix in general, then get access to the government's matrix. Yes it's an extra action, but the TN's can be drastically different (getting into FreeSat versus getting into Aztechnology for example). And all those attempts to get in racks up your security tally.

Monitor slave does just that, it lets you see through the slave's eyes, so to speak. You don't exert any control over it, making an easier task than trying to take total control of the slave. The simple versus complex actions are geared more towards what the decker can do while in combat. If the decker is under attack by the IC, while he's controlling the security turrets so they don't shoot up the team, he faces a dilemna. Fight off the IC and lose control of the turrets, or keep control of the turrets and try to avoid the IC using his other lesser actions. Now if the decker was just keeping an eye on the security cameras, that action is easier to do while in in combat than actually manipulating them.

2) I agree that Validate is too powerful a tool. Granted the TN's are high to achieve super-user access, but once you have that, it takes all the fun out of being a decker. The only real way to counter that is for the GM to have more live security deckers in the grid, since the IC will ignore the PC decker. This could make life a lot harder on the PC and could drag out Matrix combat, but that's GM discrection I guess. If you were to allow Validate to exist for the purpose of editing databases, that would take the fun out of Read/Write operations.

Validate is a toss-up. Either make the TN so high that any decker will ring up a sizeable security tally trying to make himself a password (keep in mind that there's a time limit on how long he stays valid depending on number of successes) or toss it completely and make deckers work for their pay. After using Validate in my past games, I'm actually leaning towards tossing the utility altogether.

3) Program sizes are needed. They're not that complex, its just simple math with multipliers. While they might not exactly work from a real-life standpoint, it's more of a game balancing issue. The PC decker could have more than twice as many rating 3 programs running in Active Memory as he could have rating 6 programs. I think that's more game balance than anything else.

Active and passive memory should be kept around, also. Again, it's more for worrying about what to do while in combat. If you have all stealth programs running in active memory and get jumped by an IC, you can't just turn around and blast it with your Attack utility. You'd have to spend an action (or a partial action depending on the size of the utility and your I/O speed) getting your Attack, Armor, etc. Utilities on-line to defend yourself. If you never see combat, then the point of switching programs into Active memory is just about moot. Also, given enough money and time, a decker can buy/program every utility at rating 10, but how could he possibly run all the programs at once?

[Eyeless Blond]

One thing I'd like to do is trim the fat when it comes to programs, particularly operational utilities. You could easily get away with exactly five, corresponding to ACIFS, rather like the Otaku's Channels. The cost multipliers would be boosted to compensate: say Access would have a modifier of 4, Index 3, File and Slave maybe 5, and Control 7 to compensate cost- and size-wise. This would vastly simplify decking from the end-user side, as you would only have to worry about naming the subsystem involved in any particular test.

Also, get rid of Sleaze and have the whole DF thing based on Masking. The only reason that Sleaze exists is to screw over a player with Tar IC, which is really cheap IMO.

In the same vein, get rid of Link utilities for wireless (and Maser) access devices. If you plug it into an FUP, it should damn well be Universal. Raise prices on the device itself to compensate.

Note that most of the above doesn't significantly change balance issues so much as lessen the glut of bookkeepping that make deckers a pain in the ass to play, and prevent them from spending much time designing frames and agents which are by far more interesting programs than operational utilities, and should occupy a correspondingly more significant fraction of the utility list. Even if that happens by compressing the operational utility side of the list. :)


Now for the more controversial stuff. Get rid of Response Increase. You heard me. Instead, increases to mental initiative are handled with cyberware, the same way increases to rigger initiative and physical (sammie) initiative are. In fact, they already have a perfectly good piece of 'ware whose flavor text fits perfectly with the idea of increasing mental initiative: the Encephalon. Get rid of the damn Task Pool and virtual Int increase for the Encephalon, and instead have each level add +2+d6 to mental (ASIST-based) Initiative. You'll need a third level that costs 2.25 Essence and 200,000Y, but that's okay as well.

While we're on the subject, the rigger's VCR should be reduced in Essence cost and remove the boost to mental initiative; again that will come from the Encephalon--but that's more for the Rigger thread.

[Hitomi]

[Moon-Hawk]

In response to Eyeless Blond:
First off, let me say that I really like the direction this is going. Also, I include the caveat that I really don't think the Matrix rules are all that bad. But I do agree they need improvement.
Operational Utilities: I agree that they need to be trimmed, but going down to 5 may be too far. (edit: I like condensing Logon, for example)
Sleaze: That's not the ONLY reason. It's so that there are hardware and software components to DF. You may be right about this, but I'm not 100% convinced. I like the hardware/software aspects of DF, but you may be right in that it's just not worth the bookkeeping.
Link Utilities: They're total crap. I totally agree.
Initiative based on modified encephalon: Sounds nifty. I like it. However maybe there should still be some kind of limit based on the deck. A rating 3 encephalon is only worth so much if you're trying to deck through a TI-85. Keep the DNI bonuses & such, but maybe say that you can't get more than +2+1d6 per 2 points of MPCP or something like that.

[Eyeless Blond]

[Elfie]

Now I get to put back the part I edited out of my first response:

Yes, there are a ton of utilities, but that's no different than looking at the amount of spells mages get. Mages get a ton of spells but only end up actually learning a handful, and some spells rarely if ever get used at all. Does that mean we need to trim down all the mage spells as well? Also, there are a ton of different utilities because not every decker is the same. If we cut utilities down to only a handful, then everyone will be playing a cookie-cutter hacker and what's the fun of that? A combat decker might not worry about programs like sleaze, camo, etc, but would load up on attack, armor, and medic utilities. A stealthy decker wouldn't worry about a lot of combat utilities and get more operational utilities.

Again, sure there's a ton of utilities, but there are also a ton of magic spells, and that's both for the same reason. People are individuals. If we cut them down to a handful of utilities, we might as well introduce a DnD class-based character generation system because all deckers will then be roughly the same in the matrix.

I agree with Link utilities being somewhat useless, but that depends on the style of game you play. If you're characters are paranoid because your GM takes every kind of tracking into consideration, then maybe land-line jackpoints are a very bad idea. So if a decker wants to laser, maser, or sat-deck, he needs some extra equipment and utilities. The majority of players can just ignore them, but they shouldn't be just deleted altogether.

[Kagetenshi]

Ok, I'm going to expand the scope of Issue 1 to apply to Operational Utilities as well. Let's take a look at what we have for operations and utilities; we'll start with:

Access

Decrypt Access
Encrypt Access
Freeze Vanishing SAN
Graceful Logoff
Logon to Host
Logon to LTG
Logon to RTG

Out of these, the Logon operations will be combined. That leaves us with five operations, which are governed by four utilities: Decrypt, Encrypt, Doorstop, and Deception. The question is, do any of these make sense to get rid of? The only one that I think could make sense would be Doorstop, but what would we replace it with? Deception again? It's already a powerful utility, but could reducing the utility count make it worth it?

The big problem with powering up Deception is that it's the siné qua non of Decking. I'd be against increasing the multiplier, personally. The question is, is adding freezing vanishing SANs to its list of powers unbalancing without kicking cost? I think not, but I'd like to get other opinions.

~J

[Eyeless Blond]

The thing about operational utilities is that they're not optional like magic spells. If you don't have, say, Levitate then you'll have to find another way to get over that wall. Maybe you'll climb, maybe you'll borrow a helicopter, maybe you'll have your troll friend throw you over. :) The point is you have options other than using the Levitate spell to do a specific task. A decker without Deception simply cannot log onto any meaningful host. It's a barrier to entry rather than an option.

It's like if a sam had to pay cash for the ability to be able to open doors, or the mage for the ability to ever have LOS with anything.

[Kagetenshi]

Deception is a barrier to entry, sure, but if you can't Edit Slave to mess up the security cameras you could Intercept Data or locate and alter the destination or even crash the host.

Actually, that's an idea. I'm not going to get into it extensively until some of the current issues have been addressed, but how would you feel about all objects (datastores, SPUs, SANs, Slave nodes) being attackable in cybercombat? I'm not sure if it's a good idea or not, but it gives yet another way to do things.

~J

[SirBedevere]

As per your original post:

1) Both actions control the slave node; one is putting data in, one pulling data out. For ease of use I would combine them with a single Complex action 'Control Slave Node' or some such name. I think the action should be complex just for simplicity.

2) Validate - chuck it!

3) Programme sizes: My wife likes to play deckers but doesn't like the maths involved. I think it could be simplified to say: rating squared times N, but as the player involved usually does the calculations out of game time, I wouldn't complain if variable programme sizes were kept. I'm just trying to get out of doing the maths for her :D

I was going to say that by the 2060+'s (can you say that?) memory would be memory and we don't need active and storage memory. Then I read Elfie's excellent point about choices in combat. Keep the different memory types.

Link utilities - IMO chuck them. I agree about raising the device prices to compensate.

[Kagetenshi]

4) Link Utilities

In my opinion, we can drop these. The question is, what happens to the links? Do they become automatic? What replaces the link utility for the connection roll?

~J

[Eldritch]

I duuno, I know we're trying to simplify things But I think I'd keep the edit/moniter as complex/simple. A decker in combat may still be able to moniter a node by giving up an action to check on his team. Or not in combat could moniter and still perform another action.


And I'd keep response increase. That represents an investment in hardware that improves the perfromance of the machine. A decker with all the headware in the world running a Radio Shack deck is still limited by the speed of the deck. Just look at some of the machies years ago. A user could type and get ahead of the machine. Now adays you can't even get close. (Unless some other process is bogging you down)

Links - let's not eliminate them, but possibley just make one.

Or get rid of them completely - assume the software comes with the hardware (Makes more sense I guess that way - Drivers included!)

[Kagetenshi]

That is one possibility: ratings on the physical hardware. Problem is, then you've got the issue of needing ratings on both sides…

~J

[Eldritch]

I'll sit down and really go through my matrix book - But I don't think (off the top of my pointy little head) that anything needs to be done with the Hardware rules. I know a lot of peeps complain about the decker rules, but I don't think it's the deck building/mods/programming that a lot of people have a problem with - it's implementation of the rules in a game session. That's what really needs to be 'streamlined'

[Kagetenshi]

I was referring to the hardware for wireless links. The physical deck hardware is a long way away from being addressed.

~J

[Eldritch]

:D Sorry - that's what I get for trying to post in this discussion and work at the same time.


Err..


Yeah, rating link Hardware works. And makes more sense with the rest of the comm gear all having ratings.

[mfb]

the easiest way to counter Validate is to introduce rules for tracking decker trails after the decker has logged off. if you're using a valid account, you're no longer covering your tracks. therefore, while Validate makes it relatively easy to pwn a system, it also makes it relatively likely that LS is going to kick down your door and shoot you in the face. er, i mean, arrest you.

more directly pertinent to shadowrunning, being able to track what a decker did allows a host admin to lessen the damage a decker may have done. for instance, all paydata on a host on which a decker used a valid account should be less valuable, by at least half. the admins can check the logs, see what was copied, and then make that data less valuable (reallocate resources that were mentioned, pull out covert operatives that were named, move sensitive data referenced by the paydata, etcetera). this could easily apply to regular runs, as well--"steal data X" runs would be the most obvious example. even overwatch jobs could run up against problems with Validate. if trouble starts, all an admin has to do is check the activities of active users to find the runners that the decker is providing overwatch for, and then use Block Operation operations to kill the decker's overwatch capabilities while the guards mop up the helpless runners.

[Kagetenshi]

Though that certainly makes things better, a root account still ought to be able to wipe the logs, so it doesn't entirely solve the problem (just pushes it to lower-rating hosts or higher-Utility Deckers).

~J

[hahnsoo]

[blakkie]