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