Full Version: Decking
Keep the active memory and canon program sizes. I don't see any benefit that is great enough to warrant the cost of reworking a bunch of rules simply for the sake of reworking program sizes.
What about the fact that we have less than half the original number of programs? Do we up their sizes somehow, or leave well enough alone?
~J
~J
| QUOTE (Kagetenshi) |
| What about the fact that we have less than half the original number of programs? Do we up their sizes somehow, or leave well enough alone? ~J |
Leave well enough alone, I think. Remember, most of that added bulk came from "Matrix", and they didn't adjust Active Memory to compensate. ATM, all cyberdecks above a Novatech-6 need memory upgrades to have a decent spread of programs up to the max rating.
Any other opinions?
~J
~J
I agree with hahnsoo, keep programme sizes and active memory as they are.
My 2 
is to keep it the way it is
is to keep it the way it is
That was my preference too. Unless a better argument comes up somewhere, it is so.
More soon.
~J
More soon.
~J
I was going to do a recap today, but stuff came up and I'm on a deadline, so I'll toss out a few more issues and do the recap tomorrow.
Does anyone think anything needs to be changed with Compressor? I've never seen it used, but that doesn't mean it's necessarily broken…
9) Maneuvers
Beneficial? Overly complicated? Rarely useful? What needs to be changed about these?
~J
Does anyone think anything needs to be changed with Compressor? I've never seen it used, but that doesn't mean it's necessarily broken…
9) Maneuvers
Beneficial? Overly complicated? Rarely useful? What needs to be changed about these?
~J
Sorry for dragging this back out of the tar pit it's seems to be in.
Compressor, though i think something like this should exsist i think the Data Compactor cyberware fills that roll very well. if someone is wanting to "Zip" thier files then just allow a none Cyberware piece of hardware. I don't think it is in the realm of Utilities, anymore then OS's are. they exsist oh yeah, but how many Deckers characters you see with an OS listed in their Active memory??
Maneuvers.
Evade Detection is the one i've seen as the most used, so i wouldn't like that to go. Parry Attack is almost as common as Evade Detection so again would be good to keep it. However if we did keep it then we would need to either keep Postion Attack, or change it to 1 per 2 Success's. Because Postion Attack can come back and bite you, i tend to find that it's not used all that much unless against things they know they can win against, which in that case they proberly don't need it.
Compressor, though i think something like this should exsist i think the Data Compactor cyberware fills that roll very well. if someone is wanting to "Zip" thier files then just allow a none Cyberware piece of hardware. I don't think it is in the realm of Utilities, anymore then OS's are. they exsist oh yeah, but how many Deckers characters you see with an OS listed in their Active memory??
Maneuvers.
Evade Detection is the one i've seen as the most used, so i wouldn't like that to go. Parry Attack is almost as common as Evade Detection so again would be good to keep it. However if we did keep it then we would need to either keep Postion Attack, or change it to 1 per 2 Success's. Because Postion Attack can come back and bite you, i tend to find that it's not used all that much unless against things they know they can win against, which in that case they proberly don't need it.
Bah, no apologies needed. I needed a swift kick in the arse about it anyway (and a break from coding!).
I'm going to draw up that long-overdue perspective of our current changes. Are there any other concerns directly relevant to non-cybercombat decking (leaving aside jackpoints, for the moment)?
Oh yes, that's a big one.
10) Multiple Deckers
What the Sam Hill do we do with these? Possible solutions:
Everyone gets their own security tally no matter what. This raises the question: will there be multiple copies of IC? How would we treat system alerts? Can deckers find and combat IC that they have not triggered? If so, isn't that somewhat broken? If not, why not?
Security tally is a property of the host. This raises the question of whether we continue passing tally to hosts people go to and, if we don't, how we balance that newfound versatility. Possibly including a "security linked" flag that cause certain hosts to have their security value shared with other specific hosts?
~J
I'm going to draw up that long-overdue perspective of our current changes. Are there any other concerns directly relevant to non-cybercombat decking (leaving aside jackpoints, for the moment)?
Oh yes, that's a big one.
10) Multiple Deckers
What the Sam Hill do we do with these? Possible solutions:
Everyone gets their own security tally no matter what. This raises the question: will there be multiple copies of IC? How would we treat system alerts? Can deckers find and combat IC that they have not triggered? If so, isn't that somewhat broken? If not, why not?
Security tally is a property of the host. This raises the question of whether we continue passing tally to hosts people go to and, if we don't, how we balance that newfound versatility. Possibly including a "security linked" flag that cause certain hosts to have their security value shared with other specific hosts?
~J
| QUOTE (Kagetenshi @ Apr 29 2005, 10:35 PM) |
| Bah, no apologies needed. I needed a swift kick in the arse about it anyway (and a break from coding!). I'm going to draw up that long-overdue perspective of our current changes. Are there any other concerns directly relevant to non-cybercombat decking (leaving aside jackpoints, for the moment)? |
Did we touch on programming and the Languages?
| QUOTE |
| 10) Multiple Deckers What the Sam Hill do we do with these? Possible solutions: Everyone gets their own security tally no matter what. This raises the question: will there be multiple copies of IC? How would we treat system alerts? Can deckers find and combat IC that they have not triggered? If so, isn't that somewhat broken? If not, why not? |
I'm inclined to go with this option as a Host should easy have enough processing power to bring up multiple copys.
But it's only "fair" that you can (try to) see other Deckers triggered IC and help deal with them. But it does make a little too easy on the Deckers. But appart from making IC tougher which i think is a bad idea. what can we do?
I also like the idea that the host has one Alert Value, and everyone suffers cos of it. but then you would need a rule to trigger multiple copys of IC. Perhaps something like a Opposed Security value/ Detection factor, with a Host win sending out a copy of that trigger value to deal with you?
Dunno just ideas
My problem with multiple copies is as follows: if the host can run multiple copies, why doesn't it run those multiple copies against the first detected intruder?
~J
~J
Overkill?? 
| QUOTE (Shockwave_IIc) |
| Did we touch on programming and the Languages? |
Programming rules can pretty much stay as they are. I don't like the Design Test necessary for a Program Plan (it effectively doubles the amount of rolls and table lookups you have to make), but that step can be conveniently ignored or used as an optional rule.
The Programming Languages are definitely in the realm of optional rules (I think they are even stated that way in Matrix), as they deal with Bugs in Decker programming. People should be free to use them if they want to deal with handling the Bug rules as an added complication.
What I'm trying to do now is get these rules to a point where we can playtest a no-connection, no-cybercombat decking run. After that I'll be bringing cybercombat into the mix (I've already opened some of the issues, but the direction is a lot more muddied there). After we've got rules that work, make sense, are balanced, and are easy to learn and use, then we'll get to the add-ons to those rules.
~J
~J
When things start getting more finalized, will the playtest rules be posted in it's entirety somewhere? If so, where?
I'll be posting interim rules collections in each individual thread as well as summaries in the main thread. I may as we progress either create another thread solely for final rulesets or toss up some pages on SotSW for the purpose.
~J
~J
| QUOTE (Kagetenshi) |
| My problem with multiple copies is as follows: if the host can run multiple copies, why doesn't it run those multiple copies against the first detected intruder? |
This is a good point. It's not like the host itself has some sort of "Game Balance" state variable telling it not to throw lots of effort against a known intrusion or something. I think the "best" solution here is to just ditch independent tallies altogether, and make the number a general Anamoly Awareness number--basically global security tally representing how many times the host has "suspected" that something's up. It's a global number, so any decker that ups the tally has it apply to everyone. IC that's triggered only has one instance triggered at a time, so a group of deckers can double-team a set of IC if so desired, keeping in mind things will be balanced by the tally jumping up roughly twice as fast and thus getting to lethal levels/Active alerts sooner.
Having a single number makes it easier to track. Also it's exactly the same with only one decker. With multiple deckers you get one of two effects:
1) The two deckers are sharing information (via Comlink?), effectively acting as one decker acting twice as fast. In general this will help you: though usually you'll be triggering the same amount of IC you now have two people to deal with it. Generally this is fine: teamwork should have a benefit.
2) THe two deckers are not sharing, either because they don't know each other or they're enemies. Anomoly Awareness (Security Tally) will jump up much faster as both deckers Analyze the system seperately, Browse the system seperately, etc. IC will trigger left and right, each one flipping a coin (basically; really they'd be making Sensor tests opposing Evasion or whatever it is you use to notice deckers) to see which decker the IC "finds" first. In the end each decker will find about the same amount of IC as they would alone, though the spread will be much more lethal and the Passive/Active alerts will trigger more quickly. Again, this seems to make sense to me.
Of course Anomoly Awareness will go back down the same way Sec Tally goes down now, and you get fewer weird rules related to Sec Tally applying differently to different people.
What do you think? Too much of a departure?
Oh, that reminds me: cyberterminal construction rules have to change. Currently it's cheaper to, for instance, both buy an MPCP and pay to have it installed than it is to just buy the MPCP chip by itself and install it on your own; about one-tenth the cost, in fact. This of course makes no sense whatsoever. Upgrading memory and installing certain types of easy hardware are fairly easy (though it really shouldn't take several hours to slot a Storage Memory OMC into your deck, but whatever), so that part's fine, but most of the actually interesting things are pretty ridiculous in terms of either cost or time involved, unless you purchase it pre-installed when it magically becomes a small fraction of the cost.
@ Eyeless, i like what you've said about the tally, the only thing conserning me is being the decker with the crap ratings and being the one the IC ALWAYS goes for. Hence why i was thinking the same test versus everyone because the slightly more sneaker one would get at least some ice for himself instead of the poor weeflerunner being the only one getting any of it.
Yeah, I kinda mentioned that. It'd the same test that the IC normally uses, against whatever TN that you're supposed to have. The IC makes the same test against every decker, and goes after the one he can find the easiest (eg gets the most successes against).
| QUOTE (Eyeless Blond) |
| I think the "best" solution here is to just ditch independent tallies altogether, and make the number a general Anamoly Awareness number--basically global security tally representing how many times the host has "suspected" that something's up. It's a global number, so any decker that ups the tally has it apply to everyone. |
This sort of thing has been suggested many times in the past. The question that's come up each time is how to handle the following situation:
- some annoying script-kiddie decker has somehow made it past the perimeter defense, and has done enough stupid things to get the system's defenses up to the Black IC level
- the system dispatches the brat
- the next turn the Vice President of the Manufacturing Division logs onto the Accounting Node, and tries to sneak a peek at the budget forecast files that the accounting department hasn't released to the general company yet, in hopes of getting some inside information to be ready for the next upper-level staff meeting
Is the VP doing something he shouldn't? Yes, but just because he happened to be doing it while the system was still on point from a separate security threat, he gets a response disproportionate to the crime.
In the past, attempts to implement global tallies have had to closely examine settings assumptions:
- How prevalent is script-kiddie decker wannabe level matrix vandalism? A system connected to the global matrix essentially makes itself a target of every bored teenager on the planet. Would the development of IC really be enough to curb such activities to the point where they wouldn't be a nuisance? Or would systems have to heavily tailor their system response to prevent a productivity-sapping constant state of alert?
- In current day times, a significant amount of security issues come from "insider activities", employees of the company doing things with the company's network that is against company policy. In SR time, for the systems that use the nastier forms of IC, would this type of activity be severely curtailed, or at least confined to tortoise logins, where the effects of IC are much more limited? For employees who can't do their job via tortoise, and require full immersion, is there any level of assurance that they won't get their brains fried if their connection happens to glitch in the middle of a security alert?
| QUOTE (RunnerPaul) |
| Is the VP doing something he shouldn't? Yes, but just because he happened to be doing it while the system was still on point from a separate security threat, he gets a response disproportionate to the crime. |
A fact that is still true today. Take a look at the current rules for security tallies; whenever a previous user jacks out the sec tally for any new user starts at the level of the highest one that left. This prevents deckers from logging out and logging back in one round later to reset their tally, but it also does exactly what you describe. Making tally global doesn't change this problem, as it's one that already exists.
Besides, I don't think it's really a problem. Ya pays yer money, and ya takes yer chances.
| QUOTE |
In the past, attempts to implement global tallies have had to closely examine settings assumptions:
|
I'd say the first three or four script kiddies that get their asses fried/get traced and get their doors kicked in by a HRT squad at their parents' expense will drive this practise underground a little more, to the otaku tribes and the truly "l33t" who can get around them because they're just better.
| QUOTE |
|
Well, first off keep in mind that hot ASIST--the only kind of ASIST where IC has actually lethal or permenant effects--is also described as being hyper-realistic, an insane gambit where you're red-lining the interface to squeeze a little more performance out of your wetware. No casual user would ever bother exposing themselves unless the risk was worth the gain; doing a little innocent after-hours snooping usually isn't worth it unless you're drek-hot. Further, hot ASIST is already illegal without a permit, so having it on means you're probably breaking the law already. Just like when you're breaking into someone's home and the owner shoots you in the face responding lethally to an illegal trespassing attempt is not in itself illegal; you're just protecting yourself.
Umm, the guys a freaking VP (even if its of a different division) you would think the guy would have legit, legal access from his terminal, even if he is snooping deeper than he should be, IMO he would still be safe. I know it says in matrix, that even on highest alerts, legal users of the systems generally won't even know something's going on...
Well, the assumption was that he's doing something illegal, that he doesn't *have* permission to do. And honestly you'd be surprised how little access the average VP has to the system; most are surprisingly at the mercy of the IT department, either through ignorance, lack of explicit access, or oftentimes both.
I would expect VP's to have ATLEAST security grade access on their hosts, and, if there are only a handful of them, or they happen to particularly savvy, they might even have (or hacked) superuser access.
| QUOTE (Matrix page 38) |
| ... Security accounts are typically given to senior management and the mid-level technical staff... |
| QUOTE (Eyeless Blond) |
| The IC makes the same test against every decker, and goes after the one he can find the easiest (eg gets the most successes against). |
Im more inclined to make it an opposed test(if it's not already), and a copy getting sent after everyone it wins against.
| QUOTE (Shockwave_IIc @ May 1 2005, 09:51 AM) | ||
Im more inclined to make it an opposed test(if it's not already), and a copy getting sent after everyone it wins against. |
See then you get into the problem of, if the host can make multiple copies of a given IC program, why it doesn't just send ten copies after each decker? Or twenty? The idea of a static Sec Tally is that the system only activates as much IC as it thinks it needs, and thus only one per trigger step.
And I don't much like Opposed Tests, unless both ratings are being rolled against static TNs rather than TNs based on the ratings being rolled, as they make the tested ratings doubly important. A Rating 5 in an Opposed Test with a Rating 6 is almost certain to lose.
| QUOTE (Eyeless Blond) |
| See then you get into the problem of, if the host can make multiple copies of a given IC program, why it doesn't just send ten copies after each decker? Or twenty? The idea of a static Sec Tally is that the system only activates as much IC as it thinks it needs, and thus only one per trigger step. |
Yes hence the attempts at detecting everyone, then it release IC against the only threats it thinks it has. And as for not releasing 20 in one go, processing power, no sys op wants to run the host at redline ALL the time
| QUOTE |
| And I don't much like Opposed Tests, unless both ratings are being rolled against static TNs rather than TNs based on the ratings being rolled, as they make the tested ratings doubly important. A Rating 5 in an Opposed Test with a Rating 6 is almost certain to lose. |
I understand and agree. Once the Rating used get over 5 (ish) it becomes Very Difficult to get success either way.
Just look in SR3 and found that perhaps the reason we can't remember what test IC use to find Deckers is because there is no test, Theres one for Deckers to detect IC but not the other way around.
Perhaps, a Security Value Vs (Masking/2 rnd down) for the host and a Sensors Vs (IC Rating/2 rnd down) for the decker. Keeps the Tn's down but still important.
| QUOTE (Shockwave_IIc) |
| Yes hence the attempts at detecting everyone, then it release IC against the only threats it thinks it has. And as for not releasing 20 in one go, processing power, no sys op wants to run the host at redline ALL the time |
Okay, maybe I'm not explainning myself properly here. As presented in the books, hosts themselves cannot actually detect active intruders. What they dectect is security tally: how much the system has been altered or attempted to be altered in the past X amount of time. If the host itself could detect a decker on its own it wouldn't need IC; it'd just short out the decker's connection on its own. This is what makes individual security tally so stupid and wrong-headed; it goes against the whole model. It's somewhat like saying that magic is subtle and difficult to notice, basing a game world around that subelty and then outlining rules that make it easier to notice a spell being cast than a gunshot going off in your face--oh wait, they do that too. 
That's what IC is for, essentially: they're a host's internal troubleshooting safeguards. It's the IC that sets out to find the source of the anomolies (the decker), not the host; all the host does is detect that something's up and activate the IC to deal with the problem. The host won't be activating multiple copies of IC to respond to multiple intruding deckers because it isn't the entity that's actually detecting the intruding icons; that's the IC's job.
That's what IC is for, essentially: they're a host's internal troubleshooting safeguards. It's the IC that sets out to find the source of the anomolies (the decker), not the host; all the host does is detect that something's up and activate the IC to deal with the problem. The host won't be activating multiple copies of IC to respond to multiple intruding deckers because it isn't the entity that's actually detecting the intruding icons; that's the IC's job.
| QUOTE |
| Perhaps, a Security Value Vs (Masking/2 rnd down) for the host and a Sensors Vs (IC Rating/2 rnd down) for the decker. Keeps the Tn's down but still important. |
Why not Evasion instead of Masking at least? Evasion seems to be the stat for avoiding active searches; Masking is more for keeping your own actions from being detected.
Here's another explanation that doesn't require any rewrites of the rules: The security tally represents the awareness of the system resources against an individual decker. The IC are always at least partially active (like sleeping giants or royal guards that are motionlessly standing at the front gate), but more experienced deckers learn to sidestep the obvious ones and thus don't bring up the security tally as much. In effect, the IC are always patrolling and guarding, and the decker is sneaking around those sentries, and the security tally is a "random encounter" table. IC aren't individual pieces of software, but instead represent one copy (out of many) that the system can replicate as needed, limited by hardware. In this case, we assume that deckers are smart enough to evade IC, tactically getting themselves into situations where they can fight IC one at a time (unless faced with custom code).
Passive and Active Alerts are affect all deckers, as they are klaxons to mobilize resources security-wise. The IC kick up into high gear and start to actively chase around any possible intruders.
Passive and Active Alerts are affect all deckers, as they are klaxons to mobilize resources security-wise. The IC kick up into high gear and start to actively chase around any possible intruders.
Decking Revised: A Retrospective
Here's what we have now. Some issues are tagged "further discussion welcomed"—in a strict sense this is true for everything, but the ones noted as such are particularly still up in the air.
Assumptions:
The WMI does not exist, or if it does it does not use rules meaningfully different from those currently used for wireless links (see #4, Link Utilities).
The Matrix does not crash and is not replaced by something meaningfully different in the timespan currently being focused on.
1) Too many operations. What can we combine?
Access
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).
Control
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?
Index
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.
Files
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.
Slave
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.
Other
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.
Tentative: Validate and Invalidate Account can only be performed on the main user database, which may be protected or on another host altogether. Other functions of Validate may be used anywhere. Discussion welcomed.
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?
Tentatively keep both. Further discussion welcomed.
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.
9) Maneuvers: do they add anything? Do they need to be trimmed or altered, or removed completely?
More discussion needed.
10) Multiple Deckers: how do we deal with them? Multiple copies of IC or single? User-generated tally or host-global? Does tally follow users?
More discussion needed. Three suggestions:
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.
Thoughts?
~J
Here's what we have now. Some issues are tagged "further discussion welcomed"—in a strict sense this is true for everything, but the ones noted as such are particularly still up in the air.
Assumptions:
The WMI does not exist, or if it does it does not use rules meaningfully different from those currently used for wireless links (see #4, Link Utilities).
The Matrix does not crash and is not replaced by something meaningfully different in the timespan currently being focused on.
1) Too many operations. What can we combine?
Access
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).
Control
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?
Index
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.
Files
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.
Slave
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.
Other
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.
Tentative: Validate and Invalidate Account can only be performed on the main user database, which may be protected or on another host altogether. Other functions of Validate may be used anywhere. Discussion welcomed.
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?
Tentatively keep both. Further discussion welcomed.
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.
9) Maneuvers: do they add anything? Do they need to be trimmed or altered, or removed completely?
More discussion needed.
10) Multiple Deckers: how do we deal with them? Multiple copies of IC or single? User-generated tally or host-global? Does tally follow users?
More discussion needed. Three suggestions:
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.
Thoughts?
~J
I'm still in favor of ditching Sleaze altogether and having DF just be dependent on the firmware in the Masking chip. It's not like Sleaze is used for anything other than increasing DF: why *wouldn't* that piece of the software be hardwired into the Masking chip, which does the same exact thing?
As for tally accumulation, I perfer option 2. Since tally never accrues when jumping from RTG to RTG anyway it's already pretty easy to just keep bouncing from RTG to RTG until you don't get any before logging into your target host. Plus while you're doing so you can Redirect Datatrail a few dozen times preventing traces from ever looking at you. Consider it a simplifying assumption that all competent deckers are going to do this anyway, and there is essentially no difference between Options 1 and 2 except the system no longer looks like it was specifically designed to give deckers a challenge while still letting them get away with whatever they want.
As for tally accumulation, I perfer option 2. Since tally never accrues when jumping from RTG to RTG anyway it's already pretty easy to just keep bouncing from RTG to RTG until you don't get any before logging into your target host. Plus while you're doing so you can Redirect Datatrail a few dozen times preventing traces from ever looking at you. Consider it a simplifying assumption that all competent deckers are going to do this anyway, and there is essentially no difference between Options 1 and 2 except the system no longer looks like it was specifically designed to give deckers a challenge while still letting them get away with whatever they want.
On the issue of multiple deckers:
I am in favor of option two because it balances the increased security tally increase rate of multiple deckers against the greater ease of suppressing IC. Further, it requires minimal bookkeeping and streamlines runs by cutting out the RTG level (which I've always felt to be largely frivolous and inconvenient).
On the issue of maneuvers:
In my experience all are valuable (evade detection far and away the most valuable though) and none are unbalanced.
On the issue of sleaze:
Drop it and have the software represented as a component of the persona attribute (call it a driver ... or something else if I'm wrong). This keeps the necessary number of utilities down and reduces the number of special utilities, which makes utility function more uniform.
I am in favor of option two because it balances the increased security tally increase rate of multiple deckers against the greater ease of suppressing IC. Further, it requires minimal bookkeeping and streamlines runs by cutting out the RTG level (which I've always felt to be largely frivolous and inconvenient).
On the issue of maneuvers:
In my experience all are valuable (evade detection far and away the most valuable though) and none are unbalanced.
On the issue of sleaze:
Drop it and have the software represented as a component of the persona attribute (call it a driver ... or something else if I'm wrong). This keeps the necessary number of utilities down and reduces the number of special utilities, which makes utility function more uniform.
Okay so that's two votes for dropping Sleaze and two for Option 2 for Tally Accumulation (tally is a static number held by host and activates IC as it grows; multiple deckers share tally and tally increases) Any other votes?
To that option 2 for tally accumulation, maybe there could be rules for variable proliferation of tally from parent RTG to child LTGs. What I mean is you *can* have tally inherited from the parent RTG, as the RTG issues sort of systemwide "alerts" or something, but it's not going to be complete as it would be from within an LTG/PLTG and possibly be variable, as the main RTG is probably always giving off systemwide alerts of some kind or another from all the idiots doing stupid stuff to the grid.
To that option 2 for tally accumulation, maybe there could be rules for variable proliferation of tally from parent RTG to child LTGs. What I mean is you *can* have tally inherited from the parent RTG, as the RTG issues sort of systemwide "alerts" or something, but it's not going to be complete as it would be from within an LTG/PLTG and possibly be variable, as the main RTG is probably always giving off systemwide alerts of some kind or another from all the idiots doing stupid stuff to the grid.
As Sleaze only affects Masking, yes I think Sleaze should be dropped as well.
As for tally I do agree that option #2 seems the easiest to work with. Go for it.
As for tally I do agree that option #2 seems the easiest to work with. Go for it.
Security tally: Option 2 implemented.
Sleaze: tentatively dropped.
Does anyone see other issues that need fixing right now, or do we go to a round of playtesting to identify issues?
~J
Sleaze: tentatively dropped.
Does anyone see other issues that need fixing right now, or do we go to a round of playtesting to identify issues?
~J
If i remember correctly i votes for Sleaze to be dropped a way back.
Since there are no other issues being proposed at the moment, I need a few volunteers for playtesting.
Where: Welcome to the Shadows, this thread. Directions are there.
~J
Where: Welcome to the Shadows, this thread. Directions are there.
~J
About #10, multiple deckers.
I like solution 1 the best, and it makes sense in my mind. Distributed Denial of Service attacks are some of the worst on the web right now (Read: a buttload of computers mobbing the host)
the solution to limiting the number of deckers on a host is limiting the amount of programs and personas the host can handle along with normal traffic, before flatlining itself, or deleting the largest unesssecary proccesses (the ones without hard-coded priority)
Include IC in this count, and throw in a random dice modifer to determine current legit traffic. any excess gets hardware resources taken away, and the programs will crash. this may mean that the host will stop functioning to legit users as the matrix battle gets underway, or it may mean that the decker's hot new attack program fails to load.
I apologize if I've flogged the dead horse here. I just walked into this thread and I think it's a damn good idea after looking at all the negativity floating around the SR4 forum.
I like solution 1 the best, and it makes sense in my mind. Distributed Denial of Service attacks are some of the worst on the web right now (Read: a buttload of computers mobbing the host)
the solution to limiting the number of deckers on a host is limiting the amount of programs and personas the host can handle along with normal traffic, before flatlining itself, or deleting the largest unesssecary proccesses (the ones without hard-coded priority)
Include IC in this count, and throw in a random dice modifer to determine current legit traffic. any excess gets hardware resources taken away, and the programs will crash. this may mean that the host will stop functioning to legit users as the matrix battle gets underway, or it may mean that the decker's hot new attack program fails to load.
I apologize if I've flogged the dead horse here. I just walked into this thread and I think it's a damn good idea after looking at all the negativity floating around the SR4 forum.
No problem, unless something truly gets beyond the point of there being anything new being said by anyone, revisiting old topics is just fine. We'll toss in a round or three of Solution 1 in playtesting just to see how it shakes out in comparison.
~J
~J
Very interesting. I can see I'll need to keep up with this thread, having often been the frustrated decker of my group
As an alternative way of handling the multiple deckers/pack attack problem;
When a piece of IC is triggered, it goes after the decker that caused the triggering event and attempts to locate them.
On finding them, it does it's normal task. (validating their presence, logging them, attacking them, etc)
Any decker (or other entity) that commits an act that COULD raise security tally while the IC is present (by using a non-authorised system command, initiating cybercombat against the IC, etc) will add itself to the IC's list of unengaged threats.
The IC can, as a free action, at the start of any cybercombat round if combat is already taking place make a system call to clone itself, assigning the clone to deal with the first entity on it's 'unengaged threats' list and moving that entity to it's 'engaged threats' list to prevent it spawning any more copies for that entity.
This would allow decker teams the advantage if they move fast. It only spawns IC for identified threats (so is not wasting resources) and doesn't increase the tally independantly of the security rules. It gives the system a chance to avoid the pack attack problem if the deckers aren't on their toes, or if they are unlucky.
Wolfen.
As an alternative way of handling the multiple deckers/pack attack problem;
When a piece of IC is triggered, it goes after the decker that caused the triggering event and attempts to locate them.
On finding them, it does it's normal task. (validating their presence, logging them, attacking them, etc)
Any decker (or other entity) that commits an act that COULD raise security tally while the IC is present (by using a non-authorised system command, initiating cybercombat against the IC, etc) will add itself to the IC's list of unengaged threats.
The IC can, as a free action, at the start of any cybercombat round if combat is already taking place make a system call to clone itself, assigning the clone to deal with the first entity on it's 'unengaged threats' list and moving that entity to it's 'engaged threats' list to prevent it spawning any more copies for that entity.
This would allow decker teams the advantage if they move fast. It only spawns IC for identified threats (so is not wasting resources) and doesn't increase the tally independantly of the security rules. It gives the system a chance to avoid the pack attack problem if the deckers aren't on their toes, or if they are unlucky.
Wolfen.
I am currently creating for a game I'm running soon "Gigabit Decking". Basically, there is no Decker in the group, it's an Otaku. As such, I can massively streamline the entire ruleset. So far:
*Thanks to an intimate knowledge of computer programming learned from my CAP dad and the simplicity of the Channels system, I've managed to cut the entire system of programs down to nigh-on nothing. Example: you want to run a search to find a datastream on the LTG on a subject you are interested in. To do so, you create a search program; the Channel is Index (you're searching, so bypassing the Index rating is your first priority), difficulty as normal. Once this done, you have the search function program; now to make it work. Obviously, you need to access Files next; TN as encryption level of data (if data is just the latest news or some other freely available details, the difficulty is 4 to find a good source that's actually reliable...). After that, if successful you have the file. Voila. Accessing systems is even easier, as it's just a matter of rolling Access...
*Current biggest problem? Combat. Currently thinking it should be like the Astral Combat, but I'll have to adapt Combat Programs to be like spells. Currently I'm thinking that Combat Programs will have to be "preprogrammed", ie made in advance. I'm thinking maybe an Otaku could "store" such programs in their Mp; however, I was kind of hoping to get round the entire concept of Mp, so maybe you can hold back CPs equal in Rating to your Willpower (so Willpower 6 = 1 Rating 6 CP, or 3 R2 CPs, etc...? Thoughts anyone on how to do this one?
*The final problem left, then, is what happens when I don't HAVE an Otaku. The entire system needs porting to Deckers, and that means adapting cyberdecks too... Erk.
So, any help would be much appreciated, as after all I will be the only person who even knows the game properly and as such I can't rely on their aid either...
*Thanks to an intimate knowledge of computer programming learned from my CAP dad and the simplicity of the Channels system, I've managed to cut the entire system of programs down to nigh-on nothing. Example: you want to run a search to find a datastream on the LTG on a subject you are interested in. To do so, you create a search program; the Channel is Index (you're searching, so bypassing the Index rating is your first priority), difficulty as normal. Once this done, you have the search function program; now to make it work. Obviously, you need to access Files next; TN as encryption level of data (if data is just the latest news or some other freely available details, the difficulty is 4 to find a good source that's actually reliable...). After that, if successful you have the file. Voila. Accessing systems is even easier, as it's just a matter of rolling Access...
*Current biggest problem? Combat. Currently thinking it should be like the Astral Combat, but I'll have to adapt Combat Programs to be like spells. Currently I'm thinking that Combat Programs will have to be "preprogrammed", ie made in advance. I'm thinking maybe an Otaku could "store" such programs in their Mp; however, I was kind of hoping to get round the entire concept of Mp, so maybe you can hold back CPs equal in Rating to your Willpower (so Willpower 6 = 1 Rating 6 CP, or 3 R2 CPs, etc...? Thoughts anyone on how to do this one?
*The final problem left, then, is what happens when I don't HAVE an Otaku. The entire system needs porting to Deckers, and that means adapting cyberdecks too... Erk.
So, any help would be much appreciated, as after all I will be the only person who even knows the game properly and as such I can't rely on their aid either...
Wow. Some people have put a LOT of thought into all this. I applaud it.
Personally, whenever I think about jacking into the Matrix in Shadowrun, I (and my friends, after I mentioned it to them,) start hearkening back to The Matrix. Y'know, the one with Keanu Reeves.
And I agree that having a "fair play" variable on a system is dumb. Personally, I would think of any system as being like the secured building from The Matrix. As soon as you confirm an attack underway, you send absoloutely everything you have out to deal with the threat. Not only spawn one IC instance for any individual Decker.
Errrr, 'scuse my rambling. Anyway, I'd go for Option 2, personally. IC has, I believe, waay too much chance of pwnz0ring a single decker, but if the deckers start teaming up, it should be another story. The balancing factor is that the security tally is going way up because you have more than one who're doing this stuff. This means things escalate, rapidly. Which, really, is cool if you have a decker-heavy game. I'd imagine if you had three Deckers working together, you could get more heavily into the Matrix, and it's sculpting and such. So as opposed to rolling your Computer Use dice and just calling out damage, you could start to describe more.....
Okay, I've lost myself and I'm rambling. I am of course an idiot, but maybe you can understand what I mean through all that drek?
Personally, whenever I think about jacking into the Matrix in Shadowrun, I (and my friends, after I mentioned it to them,) start hearkening back to The Matrix. Y'know, the one with Keanu Reeves.
And I agree that having a "fair play" variable on a system is dumb. Personally, I would think of any system as being like the secured building from The Matrix. As soon as you confirm an attack underway, you send absoloutely everything you have out to deal with the threat. Not only spawn one IC instance for any individual Decker.
Errrr, 'scuse my rambling. Anyway, I'd go for Option 2, personally. IC has, I believe, waay too much chance of pwnz0ring a single decker, but if the deckers start teaming up, it should be another story. The balancing factor is that the security tally is going way up because you have more than one who're doing this stuff. This means things escalate, rapidly. Which, really, is cool if you have a decker-heavy game. I'd imagine if you had three Deckers working together, you could get more heavily into the Matrix, and it's sculpting and such. So as opposed to rolling your Computer Use dice and just calling out damage, you could start to describe more.....
Okay, I've lost myself and I'm rambling. I am of course an idiot, but maybe you can understand what I mean through all that drek?
That system I'm coming up with is sort-of based on the film, especially in the depth of realism present. As for how programs would appear... think origami. You fold the paper into a dove, the dove flies away (search); you fold it into a key, which you put into the lock (access); you fold it into a sword (combat); and so on.
As such, IC will appear like security, and their levels reflected in the seriousness; Black IC will look like the military, for example.
Still got to work out combat...
As such, IC will appear like security, and their levels reflected in the seriousness; Black IC will look like the military, for example.
Still got to work out combat...
Sanctus, that sounds awesome.
Me?
I'd put it at (for standardized places, something like the Renraku system might have different iconology,):
White IC: Police
Grey IC: SWAT
Black IC: Military
Beyond Black (I think it's UV IC, but I'm not sure... well, you know what's coming next,): Agents.
I like your origami idea, though I'd personally go with a "pulling things out of my pocket with a splash-burst of those fly Matrix symbols".
Me?
I'd put it at (for standardized places, something like the Renraku system might have different iconology,):
White IC: Police
Grey IC: SWAT
Black IC: Military
Beyond Black (I think it's UV IC, but I'm not sure... well, you know what's coming next,): Agents.
I like your origami idea, though I'd personally go with a "pulling things out of my pocket with a splash-burst of those fly Matrix symbols".
It's for the subtle approach; if someone watches you work, they're less likely to report a paper-folder than the man who pulls an AK out of his pocket...
I'd forgotten there was a beyond black... FBI does seem a good enough comparison for skin.
I think I've got round the combat issue - 2 types of program, prewritten and on the fly. Prewritten represented by a sheet of paper with fold lines drawn on, on the fly blank paper and pen. System terms, a decker can carry Mp worth of pre-mades, size dictated by Rating x50Mp. Seems the Mp issue won't go away, so I guess they're for keeps... I suppose an Otaku could have "remembered programs" that require a Computer (Programming) test to call up, TN of Rating and Rating dependant on difference it makes to damage dealt.
So, Daemons next. Hoo boy.
I'd forgotten there was a beyond black... FBI does seem a good enough comparison for skin.
I think I've got round the combat issue - 2 types of program, prewritten and on the fly. Prewritten represented by a sheet of paper with fold lines drawn on, on the fly blank paper and pen. System terms, a decker can carry Mp worth of pre-mades, size dictated by Rating x50Mp. Seems the Mp issue won't go away, so I guess they're for keeps... I suppose an Otaku could have "remembered programs" that require a Computer (Programming) test to call up, TN of Rating and Rating dependant on difference it makes to damage dealt.
So, Daemons next. Hoo boy.
| QUOTE |
White IC: Police Grey IC: SWAT Black IC: Military Beyond Black (I think it's UV IC, but I'm not sure... well, you know what's coming next,): Agents |
White IC attacks the icon
Grey IC attacks the deck, though can cause bleed through to the decker
Black IC attacks the decker directly.
No such thing as 'beyond black' or 'UV' IC.
Edit: Black IC types
Cerebropathic
Lethal
Non Lethal
Psychotropic (The stuff that messes with said decker's mind)
Well, I may add a further level of IC anyhow; something to make players immediately evacuate an area.
So, anyone else got any ideas? I suppose Daemons won't be too hard, but do you think the combat system will work?
So, anyone else got any ideas? I suppose Daemons won't be too hard, but do you think the combat system will work?
I... actually have no idea what you're going on about. Sounds to me like you're completely scraping the current (SR3) decking rules and making up something completely different, based around the magic and otaku rules. If so then you're in the wrong thread; this one is about revising the current SR3 rules so they 1) make sense, 2) are internally consistent, 3) eliminate "special case" scenarios as much as possible, such as (I presume) Open Tests, the Maneuver Score, weird "exception" programs like Sleaze, and various other rules oddities that have cropped up.
I suggest you start a new thread if you're after a complete toss-and-rewrite; you'll even get more people reading your thread than this one as most of the important stuff here is in the testing stages, so the thread is somewhat less-than-active.
I suggest you start a new thread if you're after a complete toss-and-rewrite; you'll even get more people reading your thread than this one as most of the important stuff here is in the testing stages, so the thread is somewhat less-than-active.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.