I was going to post this on the Chemistry thread, but there have been a few threads recently about the cumulative -1 rule and this is a general query on all of them, hence a new thread.

In SR4 pre-errata, there was an optional rule stating that you could only roll as many attempts on an Extended Test as you had dice in your pool. This was to stop PCs being able to accomplish anything given enough time and was invoked according to GM judgement. Post-errata (SR4A), this has been amended to say that your pool reduces by 1 on each attempt until you obviously stop at 0.

There have been some issues with whether this actually makes some things impossible where they should not be. One query was on the Chemistry skill for making explosives. Another (a bit more robust) was on the Data Search rules.

I worked out the following chances of success in Shadowrun (both extended and non-extended tests). I think they'll be useful for GM's to judge exactly what they're asking of their players.

http://knasser.me.uk/content/shadowrun/sr_..._by_knasser.pdf

I would like someone who knows their mathematics to confirm my numbers are correct, please.

If the numbers are correct, then I think the above shows a bit of a problem. Basically, with either the older 'maximum number of rolls = size of pool' or the new 'pool reduces by 1 each roll', you have a quite narrow band in the middle of the range of dice pools where there is uncertainty of outcome (chance of success in the range of 30-70%) and with dice pools above or below that middle band, the chance rapidly becomes either near certain failure or near certain success.

For example: A person with a dice pool of 8 trying for a threshold 12 test has a 56% chance of success. Take them to dice pool 9 and it jumps to 87%. Drop them down to dice pool 7 and it plummets to 19%.

That's awkward from both a playability and a realism point of view. Essentially, the more times you roll a dice, the more your results are going to descend on an average. Roll three dice and you might get 3 hits or you might get 0 or anything in between and no result will be surprising. But roll a hundred dice (which is how many you can roll with a dice pool of 14 reducing by 1 each roll) and you're very likely to come close to a third of your results being hits.

So two three questions:

One: Can anyone see anything wrong with my maths?

Two: Does anyone else find this a problem?

Three: What ways can we amend this to work better?

K.

I haven't checked the arithmetic, but it would appear from the tables that you don't take into account glitches and critical glitches. These should interfere with success... perhaps even, in the more serious case, cause outright failure.

So, in effect, glitches should reduce the chances of success that appear in your tables.

You're right - I have not taken into account either glitches or critical glitches. There are couple of reasons for this. Firstly, I'm not very good at mathematics.

Secondly, glitches are actually independent of success. If you succeed and glitch, you've still succeeded, and if you fail and glitch, you're still falling into the bounds of failure. So basically, we still have that narrow margin of uncertainty for success or failure. So addressing glitches separately...

You actually have a higher chance of glitching on an Extended Test than you do on a normal test due to repeated rolls. I'll work these out in a bit and add them to the results. It's of interest, but it doesn't actually change chances of success or failure.

I done some maths on this a while ago and whilst I don't have it here just now it looked pretty similar.

I suppose I didn't really see it as much of a problem. I'm not satisfied with either mechanism for limiting extended tests but understand that they have to be limited. I've rationalised it as "once you reach a certain level of ability you can reliably expect to succeed at a given level of task."

The kinds of things extended tests tend to be for it shouldn't impact your play experience too much. I find it unsatisfying mainly for things which should sometimes go horribly wrong like equipment availability, but overall it doesn't mess things up too bad.

What particular problems are you having with the mechanic?

There's a perfectly obvious reason for this "phenomenon." If you have 8 dice and you're rolling for an extended test you get N total dice, approximately a third of which will be successes. When using the optional rule, when your skill (dice pool) goes up by 1 you're in effect gaining exactly 9 dice. When you lose 1 point you're losing exactly 8 dice.
See:
1+2+3+4+5+6+7+8+9
1+2+3+4+5+6+7+8
1+2+3+4+5+6+7

That "first roll" ends up being about 20% of your total dice (9 is 20% of 45, 8 is 22% of 36, 7 is 25% of 28, as your dice pool decreases the first roll is worth more), so increasing your total pool by 1 is an increase of 20% more dice. So you're also losing or gaining 20% of your successes. If you're at even odds and lose 20% of your successes, you're no longer anywhere close to even odds. At 12 successes needed, you need an additional 2-3 successes on 8 fewer dice (that looks wrong, by saying you need 20% more on 20% less, but you need 20% more in order to lose 20% and still succeed).

Under the original rules (N tests using N dice) when you add and remove 1 from the skill the overall effect is mitigated, even though you're losing more dice and those dice constitute the same proportion of the total dice pool (DP 8 to DP 7 is about a 23% drop: 64 dice to 49), you simply have more dice towards the same threshold. 49 dice taken 1:4 is 12.25, you're already that 20% above needed, so losing 20% has little effect on the outcome.

I havn't examined the math in depth at all, but from a glance I think your numbers are right, at least in that they point out the problem. I have been working on a solution of my own, though i havn't implemented it yet and maybe you guys can give me your input on it.

Basically, my idea is to use a sort of tiered system for extended tests. Rather than limit the number of rolls in any way (don't cap rolls based on dice pool or apply -1 to each roll), instead set a minimum threshold as well as a threshold for completion. In order to make progress, you must reach at least the minimum threshold in order for it to count toward completing the test. I would use normal threshold rules, (1, 2, 3, 5) but would in most cases only use 1-3, using 5 only for excedingly high thresholds (creating rating 7+ hacking programs for example). For example, for a software test to write a rating 6 hacking program (12, 1 month), you could set the minimum threshold at 3, and after the first interval, the player would roll (software+logic+bonuses) which, in this case lets say its 14 dice total. On the first roll, player gets better than average, and gets 6 hits. Second interval, he rolls again (again at 14), and rolls slightly below average, gets 4 hits for a total of 10 (6 + 4). third interval, he rolls poorly, and only gets 2 hits. He makes no meaningful progress since he didn't get more than the minimum threshold. Final interval he gets 3 hits, the minimum threshold and finishes the program.

The minimum threshold provides the barrier from the old system where anyone with 1 rank in a skill could eventually do anything (assuming they don't horribly glitch). It also means that those with moderate dice pools can eventually succeed, but it will just take a hella lot longer. For the most part I think using a system like this will be better for story telling and makes a little more sense than limiting your rolls. It would however require a GM to be able to make a judgment call on the difficulty of extended tests.

For most extended tests, like climbing, I would set the minimum at 1, meaning if they get hits, it counts. With rules as they currently are, Climbing is an extended test, and with each combat round that passes, the character would get a -1 DP penalty. Meaning after about 30 seconds or so nobody could climb a tall ladder, or a tree, or do any sort of rock climbing because if their dice pool didn't get dropped to 0, it would still be low enough that they couldn't make any progress or they would glitch and fall off.

Well, tell me what you think anyway.

That's not a bad system, really. Geomancy already uses something like it. It's minimum TN is the BC of the area, there's no listed "maximum" its just you have to reach the TN a certain number of times (based on the BC again)

This is an interesting idea. I'll run some of your numbers when I get time and we'll see what sort of probability spread we get and what would be equivalent to the old system in difficulty (roughly). But I think you might have something workable. I dislike breaking from RAW unless I feel I must, so anything as a replacement, I place high value on simplicity.

K.

it also has the advantage of not producing an increasingly more likely critical glitch as you go further along, which would scuttle the entire attempt iirc.

You can also combine the two: if you don't get the minimum threshold then you lose one die.

Hmm, actually I would make it -2 when you don't get the minimum, that way it works with the try again rule. And if you spend an edge you can get your dice pool back up to the full amount.

I kinda like that, makes it a bit more complicated, but its an interesting idea.

Sum the Net Hits of a series of Threshold Tests instead of having some increasingly complex systems. If some things should be impossible, then just say "yeah, you aren't going to reasonably achieve this" instead of something that you only find out about after starting and ends up needing the solution of a minor mathematical puzzle if you want to understand why you failed.

I originally had a couple of paragraphes exhorting the benefits of the Sum of Net Hits system over increasingly complex systems, but really the principle of making things simple to understand works best as an argument for this. Your players already have enough to learn - let's keep this small part of the game as simple as possible.

The sum of a series of threshold tests is exactly what it is. And just like any threshold tests, if you fail, you can try again with a -2 to dice pool.

I fail to see the point, Heath. Sum of a series of thresholds.

6 + 4 + 3 = 13 > 12.

Yeah, very cryptic Mr. Robinson

If it were the sum of the Net Hits gained on a Threshold Test, then they would have subtracted 3 (the example Threshold) from the number of hits rolled (in order to determine the Net Hits). First the character rolls 6 hits - which is 3 Net Hits with the Threshold of 3. Further rolling 4 hits (1 Net Hit) would create a total of 4 (3 + 1), not 10 (6 + 4), hits towards completion.

Therefore, the system proposed by ZeroPoint is not Sum of Net Hits on Threshold Test, but something altogether weirder. It adds to the bulk you need to memorise.

seems to me the mechanic you propose is just as complicated if not more so.

Threshold is meant to indicate difficulty, and all difficulties in SR4 are subtractive if you use hits to determine effect strength (like spells). In fact, the approach I suggested is basically like casting a bunch of spells against Object Resistance, or summoning a bunch of spirits that buy successes on their resistance rolls. It's even similar to matrix perception iirc. Since the test is shared with other parts of the system, the marginal complexity is low.

But then what if someone meets the threshold without exceeding...in other words getting no net hits? Success tests in SR only require you meet the threshold, not exceed. Under your system, said person would need to get at least 4 hits in order to progress, and at a very slow rate at that...you would then have to modify existing thresholds to fall within the existing time parameters. For the example programming test, said person would have taken 4 months to code a rating 6 program under my system. Under yours, they would have spent 4 months and only got a third of the program done. If this were the trend, it would take him a year to code that program. The only way to reconcile that with the time frame that I think is intended for extended tests, would be to lower extended test thresholds considerably.

While I understand what your saying, and I think it would be a good system, using your system as is would require a more extensive change to all existing extended test thresholds. Comparatively, the system I proposed would work very much like traditional extended tests, only requiring that the players at least attain a certain level of competence which could be quickly ad hoced by a GM. Neither system is really as simple as the RAW systems of past or present or optional, but at least we are addressing the issue that many of us have noticed.

Its extremely late for me right now so if none of this makes any sense I apologize and I'll try to clarify later.

Hmm, what if instead you set a lower threshold, and instead said that the player needs x number of success before they get y number of failures, and apply net hits past the first as a bonus to your next test.

So lets say someone is doing some basic repair job, which is a logic+automotive mechanic(2, 3/2, 1 hour) test. First hour the player gets 4 successes. Second hour he gets one bonus die but only rolls 1 success. The third hour he gets zero successes and thus fails the extended test.

A little more complex, but would generate a difficulty curve that is more gentle.

I'm not sure I understand your example completely. Can you explain what the shorthand for the test is supposed to represent? Are you limiting the number of rolls? just not sure what's going on.

I can't say for certain since I don't understand completely, but from what I understand of it I like it. It seems like it would have the same problem that Heath's system would have, requiring you to recalculate how many of the tests work, including many of the athletics skills like climbing.

One thing to keep in mind is that if you make the mechanic too complicated, folks just won't use it. So trying to track more than one number from roll to roll seems like a mistake.

That leaves us two related suggestions. They both center on the idea that efforts that do not contribute noticeable success should not count at all. One counts all of the success if it counts any, and the other subtracts a fixed amount from the number of success of each roll (but flooring it at 0 per roll.)

I have three problems with these ideas.
Firstly, it seems counter to my view of how projects proceed in reality. One may spend days making small improvements in ones understanding and the framework of something (assuming it is difficult), and then when it comes together, all that earlier work comes together. (Ever watch an artist draw? A random line. Another random line. A few strokes. And then with the next few strokes there is suddenly a picture out of that chaos.) Another kind of project just requires steady effort. It has a lot of small steps, but if you do them, you get it done. Each hour you may get more or fewer steps done, but each step counts. Neither of these match that kind of per-roll thresholding.

The second problem is that this approach interacts very badly with the revised extended test rules. If the first two successes don't count, then as your number of dice gets down, even though the rules would indicate plenty of room to add some incremental success, these modifications would truncate the series. No, this is not a big deal, but it is bothersome.

Finally, one would have to refigure the target numbers for all of the significant extended tests. The difficulty of writing programs, crafting spells, writing focus or ally formulas, etc. All are calibrated to give a certain likelihood of success over a certain range of dice pools. While I do not think the game designers tuned that to the last decimal place, I do think that they looked at the rough chances, and asked themselves whether this was right. If you start discarding successes in any meaningful fashion, you are going to change this very heavily. I will admit that the change in the extended test (essentially halving the number of dice available for such activities) suggests that the earlier balance may not have been right. (Or maybe it was right and it is now already too high a threshold?)
Part of the problem here is that giving the GM an extra knob (the difficulty threshold per roll) is only actually useful if the GM has some understanding of what it will do if he changes that knob off of the 0 position.

Yours,
Joel

The math for the scalar difficulties looks solid. The margins I see altering the chart are mostly human, i.e. the DM's understanding of threshold and knowledge of player pools vs. party skill & knowledge. The difference comes into play in that a system designed to allow players to accomplish a goal (making explosives) will initially present accessible difficulties, while a system designed where every chump with a stove can't make enough c4 to level Seattle will make things harder. There are only to challenges I would posit to a hard mathematical interpretation of the rules: though I'm no statistician I do know that edge dice can turn any reasonable table on its head, and that sometimes d6s behave more like golf balls than random number generators.

the thing about extended tests are not so much about how easy or hard they are, but how long it will take to complete.

if you do one roll pr combat round, and you have a limited number of rounds to complete it (say getting a door open before a beast catches up with the group), you better well get it done in time.

so if the extended test tables had some info about the number of rolls needed to complete on average, it would be nice (tho i guess one can simply divide the pool by 3 and do a guesstimate based on that).

What I like about Zero Point's mechanic is that you can now adjust for the difficulty of the action. Most of the time the threshold would be 1. This works exactly like how extended tests work now. But you can adjust for the difficulty by increasing the threshold.

Take climbing, the number of successes needed is based on distance. There is nothing that differentiates a hard surface to climb opposed to an easy surface. Zero's mechanic allows for a difficult surface.

If you add in the Try Again rule, which already exists, then you have a mechanic where you can eventually get closer to failing, glitching and perhaps falling. As the climber looses dice from failing too many times, he can decide that the climb is too difficult.

Agreed.

Tersity demands the exclusion of any statement that would give bonus Hits to ensure that nominal success against the threshold always gives you some progress. I happen to like stating things in as few words as possible - a design is perfect when nothing more can be taken away.

Even your rules will also need GMs to tweak the number of Hits you need to complete the task, because not accumulating hits on certain rolls will affect the average number of hits you achieve, even if the Minimum Threshold is a few hits below the Expectation of your DP. I just ran the maths - it was a simple modification of my existing DP stats script.


I'm not sure I understand this. What revised Extended Test rules? The only thing changed in the latest reprint is the example mechanic they present in the GM's option section ("The Gamemaster can also ..." - my emphasis). Those rules have the effect of making some things out of reach of people - the rules I, and ZeroPoint, are presenting do this in a manner that is more honest (i.e. easier to realise that you can't win). This would also be my reason for refusing to use the "trying again" rules - that would be pointless duplication when the "excluding people with small DPs" feature is being handled through a different mechanism already.

Regarding Heath Robinson's question about about "what revised Extended Test rules?"
I was refering to the rules revision that said that for each successive roll in an extended test, the number of dice is reduced by one.

It is possible that Heath at least intended to ignore that part of SR4A in making his suggestion. Ignoring that modification does make his suggestion more tenable, and would remove the second of my three objections. (I would still have my first and third concerns.)

Essentially, I believe that without significant refiguring it is very difficult to widen the uncertainty region for extended tests. Under either the old suggestion (n tests if ones pool has n dice) or the rvised (lose one die for each test), the order of magnitude of the number of dice os n^2. This means that as one adds dice to the pool, the number of expecvted successes on a test goes up sharply. After the first few dice, it is very hard for the region where it is possible but not certain to succeed to overlap from one pool size to the next. (Going from 7 dice to 8, even under the new rules, is going from 28 effective dice to 36.)

Yes, Heath's suggestion (or, to a lesser degree, the earlier suggestion from zeropoint) reduce the effective size of the dice pool, slowing this rate and allowing better overlap.
But it introduces a problem wehreby the GM has to understand the tradeoff between the target number of success for the test and the separate threshold for individual successes. This is a hard combination to balance, and removing the equivalent of that tradeoff was, I thought, one of the nice effects of a fixed target number in the current system.

Yours,
Joel

I agree with that and I think that's part of the problem with extended tests...

Extended tests can be used in two situations:
1. Automatic success: There are some actions that, as long as you're halfway competent, you just can't fail if you spend long enough except if you glitch. The real question in those cases is the time it takes.
2. Long actions that take time and can fail: Here there's also the question of whether you're able to do it even if you're competent.

Without the cumulative -1, extended tests handled the first case nicely. They even consider the case where the character isn't competent (limiting the number of rolls to the size of the dice pool) and the glitches. The problem was with the second case, and the cumulative -1 might be a good solution (if you add something so that characters could fail, it's not surprising that character can fail).

I guess the best solution would be to consider each case separately and only apply the cumulative -1 when it's possible (and not unlikely) for the action to fail.

I think the important thing here is not necessarily the fix but the fact that this system clearly needs errata.

The numbers in the pdf clearly show the devastating effect this has on characters with moderate DP's. It also clearly shows that for characters with massive DP's the effect is zero.

I thought the point of these nerfs was to reduce the god-like power of high DP characters. Neither this nor the direct combat spell nerf do any such thing. They just make things more difficult for everyone else thus creating an incentive to drive your dice pools as high as possible.

These rules also bust the Arsenal 'mod' rules into tiny little pieces. Several mods have a threshold of 40 and one will go all the way up to 96. You need a DP of 15 to hit the first one, up from 11, and you can't hit the second because you need a dicepool of 24, up from 17.

edge?

First off, you need an Edge stat.

Second you need to spend Edge early in the process.

Third you will probably end up spending lots of it to significantly impact a test with a Threshold of 96.

For what its worth, I think this sort of thing is better handled by GM/player discussion in most cases, especially when you're trying to say modify a vehicle (per Arsenal) or code a program (per Unwired).

In cases where the character is rushing to finish the extended test, I'd probably use the older rules that limit the number of rolls allowed.

My apologies for being testy. I believe I have 2 internal classifications for mechanics: "rules" appears to refer solely to things that are mandatory, whilst "suggestions" and "X options" refer to things that aren't. When I see people referring to the rules as including the cumulative -1 I get rather annoyed. I'm a pedant, you see.

As for your first point; nothing prevents you from having a Threshold of 0 in the system I proposed, in which case the system functions exactly like the existing Extended Test rules. Some things, however, require much more knowledge of the subject area to make any progress on. For example, disassembling an engine in a manner that allows you to reassemble it is more than I could ever do without obscene luck. One can represent research by giving out the "has plans" modifier after the research, though having a schematic of the engine without knowing even the basics of engine mechanics will leave you almost exactly as puzzled as how to get anything done.

Frankly, 'most any modification to the way that Extended Tests run will require you to change the existing Thresholds. A short primer on how to modify these Thresholds is easy to produce. Select the minimum DP you want to have any chance at succeeding, and the DP you expect the average person attempting the task to have. Set the Minimum Threshold to one less than the Expectation of the minimum DP (the Expectation of an SR4 DP is one third the size of the DP). Find the expectation of the average DP and determine how long the average normal Extended Test will take under it, then find how many Net Hits it generates per test under the new system (this is easier for Sum of Net Hits) and set the number of Net Hits needed to succeed so that the number of Tests is equal in both.

Example:
An Exotic B/R Extended Test has a Threshold of 16+. We want a highly skilled person with an assistant or two to be able to do this very reasonably, but we want a highly skilled person by themselves to be able to make slow progress on it. For our work, highly skilled means a DP of about 12 (can be done with 4 skill, 4 stat, AR plans and some other modifiers) and the assistants gives you +2-4 (average of 15). So our basic DP is 12, leading to an Expectation of 4. The Min Threshold of an Exotic mod get sets to 3 for this example. Our average case has an Expectation of 5; meaning 4 tests under the normal Extended Tests. Since it generates an average of 2 Net Hits over our Minimum Threshold we multiply that by 4 (the number of tests it takes under the original rules) to get 8 for the number of Net Hits necessary to complete the B/R Test. A highly skilled mechanic working by themself would complete it in half that time.

The only gotcha in the system is that, actually, a person whose Expectation equals the Threshold generates half a Net Hit per test on average. You could set the Min Threshold to 4 and have exactly the same results, with the exception that you couldn't have a less skilled character progress at a quarter of the expected speed (they'd progress at a 20th by my calculations).



Errata for something that's not mandatory - a mere suggestion? Isn't that like errataing the fiction sections?

The cumulative -1 is not a mandatory part of the rules. Your GM can apply the cumulative modifier, but they can also apply the previous suggestion (limit number of tests to your skill or DP) or use any of the systems proposed here.

While not mandatory it is right there in the book in black and white. A GM is entitled to use it and his or her willingness to listen to discussion from the players about it's viability is not so mandatory.

If it can be mathematically demonstrated to be broken then it needs to be removed or altered with errata so that if a GM choses to use it for all Extended Tests he or she does not inadvertently ruin huge chunks of the game. We cannot all be expected to be game design experts or reasonable in the face of player objections.

I think I understand your point Heath. To confirm, let me paraphrase.
THere are tasks that are sufficiently hard that you can not even make progress on them unless you are good enough.

The way the SR tests are structured, taht is indeed hard to represent.
Given that the target number of the extended test is supposed to represent how hard it is, I think that Zeropoints proposal captures that somewhat better. If you are good enough, you will make good progress on the test. If you are not, you waon't.

Either is reasoanble, if you want to represent that issue.
Neither one matches my understanding of how tasks work in general. (Yes, you can model that by saying the threshold is normally 0. But even very hard tasks don't work that way.

The problem I have is that in general a really hard task requires a combination of
1) The right insights at some point in the process
2) Extreme care, if you are working past your level.

You use "disassembling an engine, so it can be put together again." I may well not be able to disassemble an engine at all.
But if I can (some degree of skill, not tremendous), then I can do the task very slowly and carefully and use cameras and notes to be able to reverse the process afterwards.
If I am doing a really hard programming task, the key is the insights necessary to understand the task. After that, it is a LOT of careful, detailed, programming and testing. So even though you can not succeed without significant skill, the progress per unit time, other than that, is fairly simple.

To some degree this can be done by splitting things into design and implementation tests. Or even an "idea" test, a design test, and an implementaiton test. The idea test would be a 1 day, high threshold, repeatable test. Not cumulative.

But hekc, this is just how I look at things. Your mileage may, and probably does, differ.

Yours,
Joel

With regard to the extended tests and the -1 die per trial, the way this is described in the changes document is veyr different from the way it was in the base rules. In the base rules, the <tries limited to size of die pool> was an optional rule.
In the SR4A changes, it states the -1 per try as a change to the extended test rules.
I do not have the full SR4A, but that does not look like an optional rule, or a suggestion. It looks like they changed the rules.

joel

You've got my point correct.

Without experience, we don't know what to look for when evaluating our work for correctness. For example, without having the Software skill I wouldn't know to look for deadlocks or concurrent modification problems. Even if I knew to look for them, I might not know what one looks like without the meagre experience I have. Even should I spot them, without experience I wouldn't necessarily know how to patch the problem and make the module usable again.

Without being able to spot these problems we might proceed and then discover at a later date that the system is unsustainably buggy.

crizh,
You've made your point. It does need to be replaced.

Not to be a buzzkill, but this seems way to complicated for something that should occupy less than a few minutes of real game time...

Using the Option in SR4A makes things a little more complicated (in that they might fail), but I have yet to actually fail at something with reasonable thresholds (Less than 24) using a dicepool of only 12... which as someone said earlier is 4 Stat, 4 Skil, a specialty and quality tools/AR Assists above what might be reasonably required..

I don't know, maybe I just don't get why we want to make the roll so much more difficult and time consuming...

Keep the Faith

Just a quick note here... without the Software Skill (Using your example above), you CANNOT even make the Test to begin with... this seems to be lost on a lot of individuals... there are a fair number of skills that you are not even allowed to attempt UNLESS you have at least a rank in the skill...

Are you kidding? I see people without the any software skill attempt to program all the time.

"Whats the difference" (page 2), "My 'save' thing doesn't work," and "Basic Movement AS2" (page 2) being notable examples.

Nope... Not Kidding...
By RAW... You cannot default to Software... so no skill, no programming... and we are talking about a game, not real life...
Besides, I would like to see someone with no programming experience program the Operating System for any major OS on the market... Not going to happen

As for your examples, is that really programming, or program manipulation? 2 very different things...
Did not see them, but it looks like My Search Fu on the programming pages provided is off a bit... will look and read when I find them...

EDIT: After finding the topic, it looks like the poster has SOME knowledge of programming (probably equivalent to a Rank 1 in Shadowrun), but not a lot of it...

Keep the Peace

I think a key point to remember is that in shadowrun, you only have 3 kinda of tests: success tests, opposed tests, and extended tests

My fix basically turns extended tests into success tests. That is an important part of my idea because as a GM you will be determining the difficulty of a task all the time and should be getting a pretty good idea of whether a task is hard or not or just time consuming. So tasks that you think should be easy and anyone could do it with time, set a threshold of 1. Otherwise, increase



I think this helps make my point. As a programmer myself, I remember from my earlier days of coding staring at a screen and trying to figure out how I was going to make my program do what i wanted it to do. The problem was that I didn't have the "insights necessary to understand the task." I didn't have a proper understanding of the way arrays and other more advanced data structures functioned. While I made some progress, it was severely hampered and might as well have not counted at all. When I learned a little bit more and attained the necessary understanding, it was completed quickly, and not in a linear fashion. That level of understanding functioned as a ceiling as to what I could accomplish. Once I got above that ceiling, all of the time I put into it was used much more efficiently. I guess that is part of the reason I'm not a big fan of Heath's solution. Most of the time you put into a project is wasted time if you don't understand what your doing. If you do understand, it goes a lot faster. And in heath's system, that time is still wasted even if you understand it.

This is a good point. I know in the game you can't make the roll.



It's not really program manipulation when you're scripting, you're actually writing your own programs. It's easier, but you still have to know what scope is and how to save and restore a read-only variable (7th post up as of now).

Calculating the Net Hits off a Success Test is "way too complicated"?

If you were referring to the section entitled "example" in that post, then you're mistaking the long-winded explanation of converting a Threshold from the original system to the Sum of Net Hits system for an example of it in play. The process detailed needs to be done once and once alone. I could be induced to throw out a set of converted thresholds so that such effort never need be levied upon a GM using the system.



I'm not sure what you're talking about. You seem to be conflating Hits with time, but Hits are an arbitrary resource created and constrained entirely by a game system.

The relative gain per dice is higher where the Expectation is low; and it is the relative gain that is important for the relationship between the number of tests (and thus time) it takes to achieve N Hits and the DP is N / Expectation( DP). Double the Expectation and you halve the time. Ergo, where Expectation( DP) = 1, 3 bonus dice will halve the time taken. With higher DPs the gain tails off; lowering the Expectation by some fixed amount ensures that DPs slightly higher than our Expected DP have the non-linear improvement you speak of.

It's all sounding terribly complicated to my poor sleep deprived mind! How about something simple like...

If you're rolling an extended test and fail to get any hits, only then do you get the -1 penalty for each failed roll. If you do get at least one hit, then happily continue.

There, simple - it penalises those with lower dice pools as they're less skilled and more likely to give in on a task.

Anyhow, sorry if this was actually mentioned but I'm currently incapable of thought.

To me the simplest solution to Extended Tests is to use the -2 "try again" rule when you get no successes, and impose die pool penalties for harder tasks. Keep everything else the same.

To me, that is one of the strangest things about extended tests, especially since arsenal came out with its extended tests for modifications.
Someone else above said something like this before I know. But to further explain what I mean, this is what I think is wrong with them as they are.
Extended tests have two factors: difficulty and time. Difficulty was supposed to be represented as the threshold, whereas Time was represented by the interval. The problem came where increasing the threshold was used to increase time rather than increasing the interval.

And you have so many tests that vary in time of how many tests they take where even with a sufficiently high skill, some may only take one interval to complete (like lockpicking), and others will take 10 or more (like Large Mod fire selection change).

And so with SR4A optional rules they tried to bring the threshold back to being the difficulty marker by applying the -1 penalty. But this to just makes too many things work very badly. As I've stated before Climbing for one, and simple repairs are another example.
Lets take your average contract repairman, Joe Plumber, who is slightly better than average as we've already determined by I think it was Knasser's thread that the average stat/skill is actually 2, so lets say Joe has 3 skill and 3 stat a total DP of 6. Doing his repair job with the -1 rule means that most hits he can get will be 5. Any job that has a threshold of 5, he will not be able to complete without assistance. Which is stupid.
It also doesn't make a lot of role playing sense. Why would someone get worse at a job the longer they are working on it? Usually the opposite happens.


I think the problem lies in extremely high thresholds that should either instead have higher intervals or have some method of checking difficulty.