So, after all the talk about the shortcomings of the program degradation rules, I've cobbled together this houserule that I think might be a little less -severe- likely to make the players and the GM go 'WTF?!" with respect to certain types of programs such as Skillsofts and Common Use Programs such as Edit which are just not likely to be subject to SotA obsolescence on a bi-monthly schedule in some peoples' opinions.

Programs that do not have the Registration option (Cracked Programs / Self Written Programs / Open Source Programs) gain a new program option, "Bug Resistance," when first cracked/created. Like Registration and Copy Protection, it does not count against the limit on the number of program options that may be applied. Unlike other program options, the rating of Bug Resistance is not chosen. -Instead, the cracker makes an Edge + Hacking test (Programmers writing their own code use Edge + Software)- Instead the cracker/programmer makes an Edge + Software test, with the number of hits scored setting the rating of the program's Bug Resistance.

Subsequently, each time the unregistered program reaches its Degradation interval, instead of losing a rating point as in RAW, the end user of the program rolls an Edge + Bug Resistance test vs a threshold of the program's rating. Failing to meet the threshold results in the program developing the "Bug-Ridden" software bug (the GM may substitute the bug "Quirks" for skillsofts). Glitching the test results in the program developing the software bug "Deadlock", and critical glitches will result in either a "Resource Allocation Error" bug or "Fatal Flaw" bug.

Should a bug develop, it may be found and repaired with the standard procedure for patching bugs. (Yes, this does include Skillsofts, as both the bug and the patch are associated with the drivers that let the skillsoft interface with your skill wires, or the expert system that drives the skill choices that the soft makes, and not the actual simsense data used to make the body respond the way the expert system has chosen.)

So to sum up, when you crack your Pistols skillsoft to run off a copy for your little brother along with the Manhunter you've been shooting with that skillsoft for years, it's not mysteriously going to get less proficient with that same pistol two months down the road. That may be just long enough however, for the bug that was introduced by the last official update you received just before you cracked it (an update which was trying to correct some other bug for users who are running an entirely different brand of skillwire system) to manifest itself and start becoming a serious problem. Or it may take 4 months or 6 months or more if you and your brother are lucky. Who knows, such a bug might never manifest itself, but maybe by the time month 12 rolls around, the adaptive expert system that drives the skillsoft may have decided that shooting the target in the kneecaps is always the only correct option, something that the re-baselining performed by an official update would have fixed, but that you have to fix for your little brother yourself, since you gave him an illegal copy.

Huh. I've been trying to think of a way to less arbitrarily use bugs in the rules and this just might be the way I do it. Still a lot of extra rolls and book-keeping every month, but at least it feels less...invasive than the actual ratings being slowly ground down.

A few issues though. Not sure why it would be an Edge + Hacking roll for crackers. Unless there's something I missed in Unwired that changed it, it's a Software + Logic test to crack copy protection, so I'd think it'd be an Edge + Software for all people.

That said, how do you handle assigning a bug resistance rating to pirate net warez or open source and freeware downloads? Do they just get assigned an arbitrary number by the GM? Or do you have to add yet another roll with arbitrary NPC stats of the original coder or cracker? Something to think about.

All in all though, I'll have to give it some more thought. Might be a very nice house rule though.

To be honest, I'm not sure it's really less invasive -- under the system described above, most of the bugs you could develop require an Edge (1) test every time the piece of software is used. That's potentially a lot of extra dice. I know there's a Shadowrun themed motivational poster out there that asks "What other use would you have for 5 pounds of d6's?" but still, the extra roll could slow things down.

Point taken and rules amended to reflect.

I was leaning to arbitrary number assigned by the GM, since many of the other things dealing with obtaining software through pirate channels (such as whether or not the program's available, or when the private network gets busted and shutdown) are also GM discretion. It also lets the GM flesh out the online world some. One group of open source programmers could have a repuation for poor project managment, as evidenced by consistant Bug Resistance Ratings in the ones and twos. A particular cracker may have the reputation as the go-to-girl for cracked hacking software, never getting below a 5 for her Bug Resistance, with a fanbase that follows her from private pirate network to private pirate network while she tries to stay one step ahead of the authorities.

So your plan to reduce micromanagement is to have all Hacker players roll Edge + Software against a threshold of 6 thirty times at the end of every month?

-Frank

No, my plan to reduce the bad taste left in people's mouths over the fact that their program has lost a point of rating, is having all players who use unregistered software roll Edge + Bug Resistance against a threshold of program rating thirty times at the end of the month, and if they end up with a program that developed a bug, deciding whether they want to take their chances with it, try to patch the bug or get the hacker to patch it for them, or just hunt down a different free, cracked copy through the same channels as the original.

And since I'm a nice GM, I may even use my laptop's dice roller behind my GM screen and do their 30 rolls for them, and only tell them when they've gotten a bug.

Just pointing out that for the combat hacker, the difference between making this test to see if you get a bug and just getting bugs automatically is practically nonexistent. How many people have an Edge + Software pool of 15 dice (the pool required to get 6 hits approximately half he time)?

You're looking at characters with a dicepool of something like 8 and asking them to get 5 or 6 hits. That just isn't going to happen very often. Above and beyond the fact that it's a pain in the ass, it's precious little different from just giving them the bugs and telling them to like it.

-Frank

Yeah, I'm with Frank on this one. I like the rule, but I think the DP of the roll for the hacker needs to be increased. Maybe Edge + Software + Bug Resistance? Something to give them a slightly better chance of hitting a threshold of 5 or 6. Alternatively, maybe making the threshold Rating/2? Then, a DP made up of Edge + Bug Resistance would be more appropriate.

That's intentional. I want this system to say "If you are going to use cracked software, the higher the rating you want, the more work you're going to have to do to keep up with it. Would a lower rating program that's less prone to fall apart if it's not getting constant regular updates better suit your needs? Instead of Global-Themo-Nuclear-War, wouldn't you prefer a nice game of Chess?"

If a character is getting a whole suite of rating 6 software for free, I want him to have to work hard to keep it that way.

I'm currently toying with ways to drop the number of edge rolls down, but the design goals will remain the same.

I don't really get how edge is appropriate. My software didn't degrade because I'm more lucky? However, my hacker buddy's software did because he's not so lucky? What if we're running the same version because I gave it to him or he gave it to me? Whose roll is most applicable?

There's no degradation in this setup (unless I missed it above). The luck comes in based on the moment that the bugs inherent in the code rear their ugly little heads blue-screening your VR feed at that oh-so-inopportune moment.

Who even knew when the two of you went to the store and both bought seemingly identical model MCT Datacruncher commlinks that you ended up with the last unit the store had that was based off of RevA of the reference design, and he got the first unit the store sold that was based off of RevB? Luck of the Draw, chummer.

The use of Edge is shorthand for "Modern Software and Computers are highly complex, and in the 2070s are insanely complex, with countless factors that could cause a bug to show up for a select subset of users."

Fixing bugs might not be as complex as patching software (I assume this is why you went this route), but this appears to be relatively complex a system that even when actually used can be ignored.

I copy my software to all my friends commlinks, plus a couple on the side... So at the end of the month maybe 4 of these are buggy. We delete their programs and copy our programs. Or maybe I'm wrong on this... I don't think it would be that easy, because you don't know if you have a bug, until it shows up...

So it goes like this, the GM rolls for every individual player, and individual software. Then notes which ones are buggy. Then the hacker (actually this should be the GM as well, so the hacker doesn't know how many hits he got) has to roll Analyze on each individual program (Unwired pg 109) threshold 4 to find the bug. Once he finds one that he "thinks" is clean (remember he shouldn't know whether he got 4 hits or not), he can copy it to everyones commlink. Then if he just thought it was clean because he didn't get the necessary 4 hits, he might copy buggy software to everyone. Either that or he can analyze every single program, and only replace the ones that definatly come up buggy.

So this is basically ignorable, or even more bookkeeping.

EDIT: Adding a question [Unwired pg 119]
Table: Bugs (finding/repairing) Theshold 12+, 1 week
Paragraph: Finding/Repairing Threshold 16, 1 hour
Table in back of book matches original table

So if the tables are correct it looks like you went from a Threshold 1, 1 week per program
to a Thresold 12+, 1 week per program.

If he wants to be proactive about it, yes. Note that if he's the type of hacker to regularly verify his programs, he should already be aware of the Bug Resistance ratings of all his programs, and will know which programs he has to worry the most about. For those who prefer standup fights to bug-hunts, just waiting until any potential bugs manifest themselves is another option.

Just because it analyzes clean for his specific hardware setup, doesn't mean that it'll run clean when copied to someone else's hardware setup. The bug test is per end user, so when that month old cracked hacking program or two month old common use program is copied to his buddy's gear, that buddy has to roll his own test to see if it's bug free on his rig.


I'd noticed that one too. And neither lines up with what's spelled out on p.109 for using the program verification process to detect bugs. I figure p.109 only tells you "Yes there are bugs / No there aren't." but you have to go through the find/repair process to actually isolate them.

The talk of analyzing the programs kind of made me wonder if there's some way realistically that this could be handled as a single "preventative maintenance" roll per month. Some kind of day interval test that for every hit X number of programs are free from developing bugs that month as you've kind of shored up the common problems or confirmed the common bugs aren't taking over.

I dunno, just trying to think of some way to cut down on all the rolls somehow, but eh.

Here's what I've come up with along those lines so far: The initial Cracker/Programmer rolls Logic + Edge + Software, with number of hits setting the Bug Resistance Rating, capped at a max of Program Rating - 1.

Then each month, the end user rolls a single Edge + Software test. That single test is then compared to a threshold for each program coming due that month, the threshold equal to Program Rating - Bug Resistance. Any programs that fail to have their threshold met may develop a bug at the GM's discretion. If the character has access to a Software + Analyze Dicepool of at least 4 dice (either their own dice, or another PC or contact that would be willing and able to do program verification for them) then they automatically know when they've gotten a bug.

As a tangent I was also thinking of throwing in some program lifecyle management into this system. When a program is first released (either as a corporate release with the Registration option, or as an open source release) the phases of its lifecycle are measured in a number of Degradation/Patching Intervals (1 month for hacking/malware, 2 months for everything else) equal to the program's rating. For the first [Rating] number of intervals after release, nearly all patches needed are bugfixes. From [Rating] to [Rating x 2] intervals, patches to fix exploits are just as common as patches to fix bugs. After the program has been out for longer than [Rating x 2] intervals, nearly all patches needed are to plug up exploits. When a program has been in release for [Rating x 3] intervals, Registered software usually gets a new version released. Registered users may upgrade to the new release at 10% the price of buying new, although the cost of upgrades may instead be subsumed into monthly lifestyle costs (Squatters get Rating 1-2 free, Low gets up to Rating 3, Medium gets Rating 4 or lower, High gets free upgrades up to Level 5, and those leading the life of Luxury may upgrade free on Ratings 1-6).

Simple. It was said about a dozen times in the main degredation argument thread. Calculate the cost of buying illegal patches for all programs and add to the lifestyle cost without any rolls.

Yeah, but the book only lists the cost for patches that restore a degraded rating. Patches to fix bugs typcially have higher thresholds but shorter invervals -- should they cost more, the same, or less?

Personally, I would only use bugs that NEED fixing when someone rolls a critical glitch: Then one possibility may be that you found a bug and no way to repair it on the fly A normal glitch could be a small bug that can be worked-around somehow.

Just as personally, I would have saved a Rating-Degradation style of SotA tracking for a select few hacking and anti-hacking programs.