The Cumulative -1 Rule, Or Khadim tries to do Mathematics Options Track this topic Email this topic Print this topic Download this topic Subscribe to this forum Display Modes Switch to: Outline Standard Switch to: Linear+

[knasser]

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.

[pbangarth]

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.

[knasser]

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. (IMG:style_emoticons/default/wink.gif)

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.

[ShaunClinton]

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?

[Draco18s]

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%.

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.

[ZeroPoint]

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.

[Draco18s]

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)

[knasser]

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.

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.

[Jaid]

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.

[The Monk]

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

[The Monk]

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.

[ZeroPoint]

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

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

[Heath Robinson]

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 Monk]

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.

[Heath Robinson]

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.

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.

[Draco18s]

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

6 + 4 + 3 = 13 > 12.

[The Monk]

Yeah, very cryptic Mr. Robinson

[Heath 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.

[The Monk]

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

[Heath Robinson]

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.

[ZeroPoint]

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.

[TheOOB]

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.

[ZeroPoint]

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.

[JoelHalpern]

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

[Darklordofbunnie...]

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.

[hobgoblin]

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).

[The Monk]

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.

[Draco18s]

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.

[Heath Robinson]

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.

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.

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.

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.

[JoelHalpern]

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

[Blade]

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

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.

[crizh]

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.

[hobgoblin]

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?

[crizh]

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.

[Johnny Hammersti...]

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.

[Heath Robinson]

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.)

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).

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

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.

[crizh]

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.

[JoelHalpern]

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

[JoelHalpern]

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

[Heath Robinson]

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.

[Tymeaus Jalynsfe...]

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.

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

[Tymeaus Jalynsfe...]

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.

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...

[Draco18s]

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.

[Tymeaus Jalynsfe...]

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

[ZeroPoint]

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.

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

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.

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.

[Draco18s]

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

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

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...

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).

[Heath Robinson]

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...

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.

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.

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.

[Heroes4Ghosts]

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.

[The Monk]

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.

[ZeroPoint]

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.

[Heath Robinson]

The systems that Zeropoint and I present are simple repeated Success tests. You make a Success Test, then count either the Hits or the Net Hits if you succeeded against the Minimum Threshold. You then compare the sum of all previous results to a GM adjudicated value. For comparison, in the current Extended Test you make a Success Test (Threshold 0) then count the Hits. You then compare the sum of all previous results to a GM adjudicated value.

How is that complicated? One extra "if" and, in the case of the system I present, a different count. That's all, people. That is all.


Any system that changes the DP between tests requires that you track the modifier to your DP, or your modified DP. That's easy when the tests are sequential in play, but not all tests work like that. The Extended Software test practically requires that you to go through entire runs between individual rolls.

"Sure," you say. "They just need to write stuff down for those things." People make mistakes, and increasing the amount of information they have to record increases the likelihood of those mistakes. Not only does it make mistakes more likely, but it makes it more difficult to reconstruct the information from memories.

[ZeroPoint]

The systems that Zeropoint and I present are simple repeated Success tests. You make a Success Test, then count either the Hits or the Net Hits if you succeeded against the Minimum Threshold. You then compare the sum of all previous results to a GM adjudicated value. For comparison, in the current Extended Test you make a Success Test (Threshold 0) then count the Hits. You then compare the sum of all previous results to a GM adjudicated value.

How is that complicated? One extra "if" and, in the case of the system I present, a different count. That's all, people. That is all.


Any system that changes the DP between tests requires that you track the modifier to your DP, or your modified DP. That's easy when the tests are sequential in play, but not all tests work like that. The Extended Software test practically requires that you to go through entire runs between individual rolls.

"Sure," you say. "They just need to write stuff down for those things." People make mistakes, and increasing the amount of information they have to record increases the likelihood of those mistakes. Not only does it make mistakes more likely, but it makes it more difficult to reconstruct the information from memories.

I pretty much agree with everything you say here. As is, I have a player trying to write a new high level OS for our tacnet. with a 6 month interval, It's going to be a while. In fact, I don't know if it will ever see play. Havning to record all the modifiers he has and record his progress on the creation for long periods of time...I have enough roleplaying experience to know that the info will probably get lost.

So yeah, I'm gonna be switching to my system and I'll see how it plays out. If anybody else tries it or Heath's system, let us know how it goes and what you think.

My only advice is that if you use this idea, you will probably want to lower many of the thresholds in arsenal to something a little more reasonable and use higher difficulties instead.

[DireRadiant]

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

This is what extended tests are for. To determine how long it takes someone to succeed, not whether or not they will. In that case there are more dimensions then simply meeting the threshold.

Meeting the threshold after the bomb has gone off is pointless.
Getting that vital piece of gear for the run after the deadline is pointless.

In these cases the rate at which someone approaches the threshold, and the time intervals involved are for more critical then whether or not they will succeed eventually.

Will the person with Demolitions 4 and Logic 4 disarm the bomb in less then three combat turns if the threshold is 8? If they were allowed all the rolls without the time limit they would succeed eventually, but the fact the number of combat turns matters makes a difference here.

Simple Tests, Opposed Tests, and Extended Tests are all tools for the GM to use to create drama and tension. Use the right tool for the job.

[Rotbart van Dain...]

This is what extended tests are for. To determine how long it takes someone to succeed, not whether or not they will.

Actually, they are for both.

[StealthSigma]

I pretty much agree with everything you say here. As is, I have a player trying to write a new high level OS for our tacnet. with a 6 month interval, It's going to be a while. In fact, I don't know if it will ever see play. Havning to record all the modifiers he has and record his progress on the creation for long periods of time...I have enough roleplaying experience to know that the info will probably get lost.

So yeah, I'm gonna be switching to my system and I'll see how it plays out. If anybody else tries it or Heath's system, let us know how it goes and what you think.

My only advice is that if you use this idea, you will probably want to lower many of the thresholds in arsenal to something a little more reasonable and use higher difficulties instead.

I am looking for reasons for my character to suggest buying one...... considering his background, it may not take long to find one depending on how combat goes with the team.... Yes he doesn't know it's being worked on, but that doesn't mean he doesn't have exposure to them (he very likely does, and I doubt you would disagree) and know their benefits. I imagine that if he sees or notices a deficiency that would be improve by the tacsoft, he would propose to use it.

Zero, my biggest issue with the initially proposed system is that by raising the "To make progress" threshold, you make it impossible to progress at lower hits, unless you use net hits. If the progress threshold is 3, then it is impossible to make progress at anything less than 3 successes. If anything, it feels like raising the progress threshold is an intent to slow how quickly an extended test is performed, but it doesn't slow it if the player can consistently make that number and all hits count towards progress. Net Hits + 1 would be more appropriate to facility the slowing down. That was if you need 3 hits to progress, and you roll 5 hits, you only get a 3 hits towards the extended test rather than 5 hits.

Right now the RAW rules provide 3 knobs to adjust extended test. You increase the threshold to succeed, you increase the interval, or you take the -1 cumulative rule. I agree that the -1 rule seems too harsh, and the interval adjustment is bulky at best. Increasing the threshold to achieve success is really the only viable option for fine tweaking in RAW. Using a progress threshold creates the finest control.

[ZeroPoint]

Zero, my biggest issue with the initially proposed system is that by raising the "To make progress" threshold, you make it impossible to progress at lower hits, unless you use net hits. If the progress threshold is 3, then it is impossible to make progress at anything less than 3 successes. If anything, it feels like raising the progress threshold is an intent to slow how quickly an extended test is performed, but it doesn't slow it if the player can consistently make that number and all hits count towards progress. Net Hits + 1 would be more appropriate to facility the slowing down. That was if you need 3 hits to progress, and you roll 5 hits, you only get a 3 hits towards the extended test rather than 5 hits.

While that would certainly work, it would also be more complicated and my intention isn't really to slow them down. My intention is to provide a barrier against people with a DP of 5 doing something that they shouldn't be able to do, even if given a large amount of time without at the same time destroying how many extended tests work. And as I said, using anything 3 or higher would be reserved for difficult tasks, not time consuming. Unfortunately, many of the tasks in the books are given with a higher threshold in order to represent being more time consuming, not more difficult. So you will have tasks with high thresholds and lower difficulty thresholds or progress thresholds however you want to call it.

[The Monk]

Any system that changes the DP between tests requires that you track the modifier to your DP, or your modified DP. That's easy when the tests are sequential in play, but not all tests work like that. The Extended Software test practically requires that you to go through entire runs between individual rolls.

"Sure," you say. "They just need to write stuff down for those things." People make mistakes, and increasing the amount of information they have to record increases the likelihood of those mistakes. Not only does it make mistakes more likely, but it makes it more difficult to reconstruct the information from memories.

Don't you have to keep track of the amount of successes you have accumulated and the threshold which you are making the tests at? What's all that difficult about also writing down how many negatives to dice pool you have accumulated as well? Or do you let your players recall how many successes they have rolled so far from memory?

[Heath Robinson]

Don't you have to keep track of the amount of successes you have accumulated and the threshold which you are making the tests at? What's all that difficult about also writing down how many negatives to dice pool you have accumulated as well? Or do you let your players recall how many successes they have rolled so far from memory?

The Threshold information can be stored in multiple places more easily than the negative modifier because it does not change. A changing value should be stored in as few places as possible to minimise the cost of updating it, but a number that never changes can be copied 5 (or 50, 500, 5 000, etc) times without concern.

For any probability of bad storage, increasing the number of things we have to store increases the probability that something goes wrong. Duplication, meanwhile, reduces the probability of a number being stored wrong. A good system will attempt to minimise the probability of stuff going wrong, and that means minimising the number of things we store in only a single place.

[McAllister]

I suspect The Monk's assertion is that the number of hits rolled so far is a changing value. If you can store one changing value, why not store two?

[Heath Robinson]

I suspect The Monk's assertion is that the number of hits rolled so far is a changing value. If you can store one changing value, why not store two?

For any probability of bad storage, increasing the number of things we have to store increases the probability that something goes wrong. Duplication, meanwhile, reduces the probability of a number being stored wrong. A good system will attempt to minimise the probability of stuff going wrong, and that means minimising the number of things we store in only a single place.

If you store 2 things, you have [1 - P' * P'] probability of at least one number being stored wrong. That number is higher than [1 - P'] pretty much by definition (P < 1 :. P' = 1 - P < 1 :. P' * P' < P'). So we only store one changing value, because it's less likely to go wrong and, if it does go wrong, the state is easier to recover from memory because we only have one important number - memory has the same characteristics with regards to number storage and recall.

[ZeroPoint]

I...I don't really care, but what I meant by my comment was that anything you record no matter how many times or where you think you put it, it always seems to have disappeared when the time comes that you need it in game. the person that was supposed to record it forgot to write it down, left their notebook at home, you left your notebook at home, don't remember where you wrote it, cat ate it, etc.

So I have that trouble no matter what system you use. But when there are less numbers involved, and fewer numbers that change then I'm more likely to remember them when the above situation happens.

[Tymeaus Jalynsfe...]

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.

Not sure where you are getting your maximum number of successes = to 5...

He will roll 6+5+4+3+2+1 Dice for a total of 21 Dice over the course of the extended test... He will obtain a range of 0 successes (no dice come up as a success) to 21 successes (All Dice come up as a success), Average Successes assumming complete equality is 7 Successes...

This is NOT a maximum of 5...
Keep the Faith

[Tymeaus Jalynsfe...]

The systems that Zeropoint and I present are simple repeated Success tests. You make a Success Test, then count either the Hits or the Net Hits if you succeeded against the Minimum Threshold. You then compare the sum of all previous results to a GM adjudicated value. For comparison, in the current Extended Test you make a Success Test (Threshold 0) then count the Hits. You then compare the sum of all previous results to a GM adjudicated value.

How is that complicated? One extra "if" and, in the case of the system I present, a different count. That's all, people. That is all.


Any system that changes the DP between tests requires that you track the modifier to your DP, or your modified DP. That's easy when the tests are sequential in play, but not all tests work like that. The Extended Software test practically requires that you to go through entire runs between individual rolls.

"Sure," you say. "They just need to write stuff down for those things." People make mistakes, and increasing the amount of information they have to record increases the likelihood of those mistakes. Not only does it make mistakes more likely, but it makes it more difficult to reconstruct the information from memories.

I have always just tallied my results on the character sheet per interval... subtract the number of dice equal to the number of rolls on the sheet tally... Simple...

Example... Tally looks like this... 3,0,2... Next roll subtract 3 from your Pool (for the 3 Previous rolls)
Nothing comlicated about that... Absolutely no tracking of any modifiers whatsoever required...

[Tymeaus Jalynsfe...]

While that would certainly work, it would also be more complicated and my intention isn't really to slow them down. My intention is to provide a barrier against people with a DP of 5 doing something that they shouldn't be able to do, even if given a large amount of time without at the same time destroying how many extended tests work. And as I said, using anything 3 or higher would be reserved for difficult tasks, not time consuming. Unfortunately, many of the tasks in the books are given with a higher threshold in order to represent being more time consuming, not more difficult. So you will have tasks with high thresholds and lower difficulty thresholds or progress thresholds however you want to call it.

But that makes the assumptin that the person with the DP of 5 is incompetant in some way... Skill 3 and stat 2 gives 5 dice... the average Mechanic would probably have these stats... are you saying that the average mechanic shold be unable to fix the cars brought into his shop, or are you saying that it should take a while... I am saying it should probably take a while, but he will eventually succeed...

The real question here is whether it is IMPORTANT for you to test this to begin with... if you have all the time in the world, who cares ... it only really matters when there is a time constraint in place that might make a difference whether he succeeds or fails... this is the instance in which he should actually roll to test...

[Tymeaus Jalynsfe...]

I...I don't really care, but what I meant by my comment was that anything you record no matter how many times or where you think you put it, it always seems to have disappeared when the time comes that you need it in game. the person that was supposed to record it forgot to write it down, left their notebook at home, you left your notebook at home, don't remember where you wrote it, cat ate it, etc.

So I have that trouble no matter what system you use. But when there are less numbers involved, and fewer numbers that change then I'm more likely to remember them when the above situation happens.

But here is the point... if you are storing a hundred numbers or only 1 nuimber, if you have "lost" the storage medium, it does not really matter any more... the data is still gone...

Barring crazy loss of data... if you have the one critical number at hand, you will also have the remaning other critical data at hand...

[Heath Robinson]

I have always just tallied my results on the character sheet per interval... subtract the number of dice equal to the number of rolls on the sheet tally... Simple...

Example... Tally looks like this... 3,0,2... Next roll subtract 3 from your Pool (for the 3 Previous rolls)
Nothing comlicated about that... Absolutely no tracking of any modifiers whatsoever required...

You're implicitly storing the modifier, in a manner most inefficient (in all possible ways, too). Not only do you occupy more space with numbers that matter only as a sum, but you've got an O( N) operation to calculate both your negative modifier and your current Hit total. Storing that many numbers is non-optimal for enabling the recall of important numbers should you lose that sheet. All in all, that method is downright deficient except for the update speed - but for every update you must make a corresponding modifier calculation and total check, so you've chosen a false economy.

But here is the point... if you are storing a hundred numbers or only 1 nuimber, if you have "lost" the storage medium, it does not really matter any more... the data is still gone...

Barring crazy loss of data... if you have the one critical number at hand, you will also have the remaning other critical data at hand...

Are you unfamiliar with Murphy's law? Risk minimisation is a principle that should be inherent to all design activities!

[ZeroPoint]

so many replies and pretty much all of them misunderstandings or my fault for being lazy.

Not sure where you are getting your maximum number of successes = to 5...

He will roll 6+5+4+3+2+1 Dice for a total of 21 Dice over the course of the extended test... He will obtain a range of 0 successes (no dice come up as a success) to 21 successes (All Dice come up as a success), Average Successes assumming complete equality is 7 Successes...

This is NOT a maximum of 5...
Keep the Faith

On the first. I didn't say maximum, I meant to say average, but i can definitely see how that was misconstrued. And yes I did make a mathematical mistake in that I calculated the average of each seperate roll as opposed to the combined number of dice. I realized that after posting but the point still stands. According to RAW, an 'easy' extended test should be 6, whereas an average extended test would be 12. In that case, the standard mechanic would "most likely" not succeed at doing anything greater than an oil change. He might be able to do a break change (which is relatively simple) but he could fail.

But that makes the assumptin that the person with the DP of 5 is incompetant in some way... Skill 3 and stat 2 gives 5 dice... the average Mechanic would probably have these stats... are you saying that the average mechanic shold be unable to fix the cars brought into his shop, or are you saying that it should take a while... I am saying it should probably take a while, but he will eventually succeed...

Well, in most cases the repair jobs coming in wouldn't be too difficult. with a success threshold of 2, on average they will will get the 2 hits and continue to progress. I'm no mechanic, but i've done my share of auto-repair in my life and one could assume that I might have a DP of 4-6 in SR. I've done some repair jobs that no matter how long I worked on it I couldn't fix and was eventually forced to junk the vehicles (cost of full engine replacement greater than that of the vehicle). Yes, some repair jobs can be over the head of the person attempting the repair. At every autoshop you have the guys that do the work, and know how to do the work, and then you have the guys that know exactly what work needs to be done. The second are the reason you don't always have cars coming out of the shop that work. The first guys mostly just do what the other guys say needs to be done.

On a side note, one thing that a lot of people don't realize is that the most important part of doing any sort of repair is diagnoses. If you have a problem, and you try to fix it by doing the wrong thing, then you didn't fix it right. I think that is a big part of what comes from higher difficulty repair jobs (diagnosing WHY the engine won't start). Once you know exactly what's wrong, doing the actual repair is cake.

On the subject of storing numbers. Doesn't matter. Only reason why I personally don't like having more than one changing value is because I'm horribly disorganized, and will frequently forget where I stored the numbers and have to rely on memory. In that case its easier to remember one number than 2.

[The Monk]

If there is one thing I ask of all my players its to be organized. Shadowrun is so full of accounting and recording. How many bullets do I have in my clip, how many clips do I have? How many patches do I have, how much charge do I have, how much longer can my drone operate. Wound modifiers from last game, it goes on and on.

If you can't keep track of two numbers, you're lost.

[ZeroPoint]

There's a difference in long term and short term data recording.

However, I was simply making a joke. Part of the reason I'm disorganized is due because D&D has instilled in me some bad habits. Its much less important to remember lots of little details that aren't already going to be written on character sheets somewhere as compared to SR where you should record almost everything because it will probably be important at some point in time. I have become a great deal more organized since playing SR.

But now we are getting completely off topic. In the scheme of things, whether its easier to record or not, or likely to be forgotten has little bearing on whether the system is useful or accurate, or if there is a better way of doing it. Perhaps the best way to do it would just be with original SR4 version, without limiting rolls at all. I think for many situations, limiting the number of rolls that can be used to complete a task just doesn't make sense.

[McAllister]

I've been following this, and I'm having trouble keeping track of who disagrees with whom about which aspect of what rules. I propose we take a moment to summarize. If you agree, please provide the following.

1. A working name for a given system of extended test rules.

2. A step-by-step evaluation of how to make an extended test using those rules.

3. Your personal opinion of the advantages and disadvantages of using those rules.

And for the love of all things six-sided and covered in pips, let's try to give different suggested systems differentiable but consistent names? I'm so confused...

[ZeroPoint]

Amen! I have to say though that I havn't really disagreed with anybody so far. Everyone has made valid points that have made me think of how I could change my concept or other systems that could be used instead, weighing the merits of them versus other concepts. bleh, my head hurts so I'm going to bed for tonight. If the thread doesn't die by tomorrow, I'll post my thoughts then.

[Tymeaus Jalynsfe...]

You're implicitly storing the modifier, in a manner most inefficient (in all possible ways, too). Not only do you occupy more space with numbers that matter only as a sum, but you've got an O( N) operation to calculate both your negative modifier and your current Hit total. Storing that many numbers is non-optimal for enabling the recall of important numbers should you lose that sheet. All in all, that method is downright deficient except for the update speed - but for every update you must make a corresponding modifier calculation and total check, so you've chosen a false economy.


Are you unfamiliar with Murphy's law? Risk minimisation is a principle that should be inherent to all design activities!

First... I dont write modifiers down... I strructure my activities such that I start with a basic pool... say 12... Then i begin to roll... Note the first value... next roll I add next value (i do not ssum tehm on page, as I am reliably competent at math in the head), the number fo rolls is the negative modifier for the next roll... easy peasy... no false economy there as far as I am concerned and it takes all of 3 seconds to tally and perform, each and every time...

Yes... And Yes... Which is why I have copies of my character sheets on Computer files, on teh off chance that Murphy does indeed strike... If I lose he character Sheet AND the Computer file, then the character has a fatal accident and I just tend to make a new character anyway... Null Perspiration...

Keep the Faith

[Heath Robinson]

If there is one thing I ask of all my players its to be organized. Shadowrun is so full of accounting and recording. How many bullets do I have in my clip, how many clips do I have? How many patches do I have, how much charge do I have, how much longer can my drone operate. Wound modifiers from last game, it goes on and on.

If you can't keep track of two numbers, you're lost.

"Don't worry - he's been stabbed and shot quite a lot already - I'm sure one more knife won't hurt!"

I've been following this, and I'm having trouble keeping track of who disagrees with whom about which aspect of what rules. I propose we take a moment to summarize. If you agree, please provide the following.

1. A working name for a given system of extended test rules.

2. A step-by-step evaluation of how to make an extended test using those rules.

3. Your personal opinion of the advantages and disadvantages of using those rules.

And for the love of all things six-sided and covered in pips, let's try to give different suggested systems differentiable but consistent names? I'm so confused...

I've continued through to refer to my system as the Sum of Net Hits system, or as "the system I present". However, sure, I'll take it.

1. Sum of Net Hits
2. You have a running total and a Minimum Threshold (named so to distinguish from the Threshold in the normal Extended Test system), an Interval, and a Length (i.e. once your total reaches this value, you've completed the task). You roll a Success Test against the Minimum Threshold and add the Net Hits (i.e. Hits above the Minimum Threshold) to your running total then you may make another test after the Interval has passed. Once you've reached or exceded the Length with your running total the task is complete.
3. Pros
   • Easy to determine what tasks you can reasonably complete using the DP/3 rule of thumb
   • Similarities to existing tests in SR4 such as casting a spell against Object Resistance (where Net Hits determine the strength of the effect), or shooting people (which adds Net Hits to damage)
   • Smaller numbers (easier to remember and add)
   Cons
   • Not compatible with existing published thresholds

EDIT: Update!

V1.1

1. Sum of Net Hits
2. You have a running total and a Progress Threshold (named so to distinguish from the Threshold in the normal Extended Test system), an Interval, and a Success Threshold (i.e. once your total reaches this value, you've completed the task). You roll a Success Test against the Progress Threshold and add the Net Hits (i.e. Hits above the Progress Threshold) to your running total. Then you may make another test after the Interval has passed. Once you've reached or exceded the Success Threshold with your running total the task is complete.
3. Pros
   • Easy to determine what tasks you can reasonably complete using the DP/3 rule of thumb
   • Similarities to existing tests in SR4 such as casting a spell against Object Resistance (where Net Hits determine the strength of the effect), or shooting people (which adds Net Hits to damage)
   • Smaller numbers (easier to remember and add)
   Cons
   • Not compatible with existing published thresholds
   • Gotcha: meeting the Progress Threshold does not make any progress
   • Gotcha: extra dice can significantly increase progress rate when DP is near ProgressThreshold*3

First... I dont write modifiers down... I strructure my activities such that I start with a basic pool... say 12... Then i begin to roll... Note the first value... next roll I add next value (i do not ssum tehm on page, as I am reliably competent at math in the head), the number fo rolls is the negative modifier for the next roll... easy peasy... no false economy there as far as I am concerned and it takes all of 3 seconds to tally and perform, each and every time...

Yes... And Yes... Which is why I have copies of my character sheets on Computer files, on teh off chance that Murphy does indeed strike... If I lose he character Sheet AND the Computer file, then the character has a fatal accident and I just tend to make a new character anyway... Null Perspiration...

Definition of "implicit": "implied though not directly expressed; inherent in the nature of something". Things that you store implicitly are also stored. Just because you don't have a field labeled something does not mean it isn't stored. Counting does not magically make information disappear.

The 3 seconds you take to calculate these values is more than the half a second it takes to read 2 numbers. It's more than the quarter of a second it takes to read 1 number.

Not every player is you, so I don't see why I should care how reliable you are, anyway. I could be the Oracle of Delphi and it wouldn't matter one iota that I could predict every dice roll - dice are still a good randomisation method in 99.99999998333...% of the circumstances. The plural of anecdote is not data, the singular sure as hell isn't either.

[Tymeaus Jalynsfe...]

Definition of "implicit": "implied though not directly expressed; inherent in the nature of something". Things that you store implicitly are also stored. Just because you don't have a field labeled something does not mean it isn't stored. Counting does not magically make information disappear.

The 3 seconds you take to calculate these values is more than the half a second it takes to read 2 numbers. It's more than the quarter of a second it takes to read 1 number.

Not every player is you, so I don't see why I should care how reliable you are, anyway. I could be the Oracle of Delphi and it wouldn't matter one iota that I could predict every dice roll - dice are still a good randomisation method in 99.99999998333...% of the circumstances. The plural of anecdote is not data, the singular sure as hell isn't either.

Actually it is the 3 seconds to read, calculate and roll dice, tally successes and write additional data... all told, no time at all...
Not a matter of reliablity... it is a matter of complexity...I have 2 sets of data to remember/record and a single comparison (Success ro fail)... that is all... according to your description, you have 5 "sets" of data, and 2 comparisons... Seems a lot more complicated than roll, tally and compare...

Just me I guess, but since I only roll Extended tests when it really matters, it has never presented a problem for me to accomplish the tasks represented by Extended Tests...

I will ask it again, if it is not dramatically relevant to the story at hand, why even roll?

[McAllister]

I will ask it again, if it is not dramatically relevant to the story at hand, why even roll?

Perhaps you'll think I'm a dick, it wouldn't be the first time I've heard it (and I'm sure you'd be more polite than to put it so bluntly), but I've definitely been at tables where I was unsatisfied with the GM's glossing over undramatic situations. Perhaps it's true that I focus more on rolls than roles (not exclusively, maybe 60-40 or 65-35), but I like to see that putting my points in non-combat skills like Armorer is resulting in pips on the table, even if I know I can easily complete the task.

[McAllister]

I've continued through to refer to my system as the Sum of Net Hits system, or as "the system I present". However, sure, I'll take it.

1. Sum of Net Hits
2. You have a running total and a Minimum Threshold (named so to distinguish from the Threshold in the normal Extended Test system), an Interval, and a Length (i.e. once your total reaches this value, you've completed the task). You roll a Success Test against the Minimum Threshold and add the Net Hits (i.e. Hits above the Minimum Threshold) to your running total then you may make another test after the Interval has passed. Once you've reached or exceded the Length with your running total the task is complete.
3. Pros
   • Easy to determine what tasks you can reasonably complete using the DP/3 rule of thumb
   • Similarities to existing tests in SR4 such as casting a spell against Object Resistance (where Net Hits determine the strength of the effect), or shooting people (which adds Net Hits to damage)
   • Smaller numbers (easier to remember and add)
   Cons
   • Not compatible with existing published thresholds

Thank you for helping me, Heath! I like your system. Am I correct that one of the key points of contention is whether to add ALL HITS to the Length Threshold (therefore presenting the Minimum Threshold as a "you must be this tall to ride" sort of bar) or to add the NET HITS to the Length Threshold (therefore resulting in higher Minimum Thresholds causing tasks to take longer)? If so, it's an interesting question. If I were GM, I might even go so far as classifying extended tests as "hard" (where you only add NET HITS) or "easy" (where you add ALL HITS).

And of course, making the Minimum Threshold = 0 would leave us, essentially with RAW, uncooked Extended Tests.

[ZeroPoint]

I've been following this, and I'm having trouble keeping track of who disagrees with whom about which aspect of what rules. I propose we take a moment to summarize. If you agree, please provide the following.

1. A working name for a given system of extended test rules.

2. A step-by-step evaluation of how to make an extended test using those rules.

3. Your personal opinion of the advantages and disadvantages of using those rules.

And for the love of all things six-sided and covered in pips, let's try to give different suggested systems differentiable but consistent names? I'm so confused...

1. Minimum Threshold

2. Given any extended test with its Completion Threshold and Interval, there is also a Minimum threshold. When the test is made, the GM assigns a difficulty to the test (using standard success test thresholds). If the test meets or exceeds the Minimum Threshold, then ALL HITS are added to reach the final product.

3. Pros: Provides a barrier against characters with inadequate dice pools making High threshold extended tests, without limiting the number of rolls.
Little different from Current extended tests.
Can use current extended test thresholds.
Using a Minimum Threshold of 1 (for easy tasks) works like current extended tests (without any of the optional rules that limit rolls)
Cons: may be difficult for GMs to assign a difficulty to some tasks.
May be appropriate to reduce some Completion thresholds with high values, creating further complication

[ZeroPoint]

Cons
Not compatible with existing published thresholds

Another Con I've just noticed with this (Sum of Net Hits system), though you may not find it to be one is that a person that gets 2 net hits gets twice as much progress as a person that only gets 1 net Hit, even if their number of hits were 5 and 4 respectively.

An oddity of the mathematics involved.

A similar argument could be made against both of our systems additionally since a person that gets 1 hit less than required to make progress will unfortunately make no progress at all, but such is the case with success tests as is. So that argument is somewhat diminished.

Edit: Clarifications

[McAllister]

1. Minimum Threshold

2. Given any extended test with its Completion Threshold and Interval, there is also a Minimum threshold. When the test is made, the GM assigns a difficulty to the test (using standard success test thresholds). If the test meets or exceeds the Minimum Threshold, then ALL HITS are added to reach the final product.

3. Pros: Provides a barrier against characters with inadequate dice pools making High threshold extended tests, without limiting the number of rolls.
Little different from Current extended tests.
Can use current extended test thresholds.
Using a Minimum Threshold of 1 (for easy tasks) works like current extended tests (without any of the optional rules that limit rolls)
Cons: may be difficult for GMs to assign a difficulty to some tasks.
May be appropriate to reduce some Completion thresholds with high values, creating further complication

Ah, thank you for your cooperation! Clarity descends like a glittering rain of... oh, wait, THERE'S my last scrap of dignity. Better hold on to that, before I start making flamingly overwrought similes.

[Draco18s]

Another Con I've just noticed with this (Sum of Net Hits system), though you may not find it to be one is that a person that gets 2 net hits gets twice as much progress as a person that only gets 1 net Hit, even if their number of hits were 5 and 4 respectively.

Another con is that someone who meets the threshold, but has no net hits, makes no progress.

[The Monk]

I've been following this, and I'm having trouble keeping track of who disagrees with whom about which aspect of what rules. I propose we take a moment to summarize. If you agree, please provide the following.

1. A working name for a given system of extended test rules.

2. A step-by-step evaluation of how to make an extended test using those rules.

3. Your personal opinion of the advantages and disadvantages of using those rules.

And for the love of all things six-sided and covered in pips, let's try to give different suggested systems differentiable but consistent names? I'm so confused...

1. extended test with try again rule.

2. extended tests work pretty much the way it works by RAW. However anytime you roll a test and do not get any successes you suffer the "Try Again" rule on page 59 SR4 (note that I don't have the SR4a version, because I'm waiting for the LE version and I am lame). The try again rule simply subtracts 2 from your dice pool. This is accumulative (so if you fail twice to get any successes you take -4 to dice pool).

3. This does not introduce any new or optional rule. All of these mechanics already exists. This does not require you to redo anything (like # of successes you need time interval, etc). It also allows small dice pools to succeed if you role well, and doesn't guarantee success to large dice pools. The disadvantage is that you will have to record the negative modifier to your dice pool for extended tests that span multiple games.

[StealthSigma]

1. You have a running total and a Minimum Threshold (named so to distinguish from the Threshold in the normal Extended Test system), an Interval, and a Length (i.e. once your total reaches this value, you've completed the task). You roll a Success Test against the Minimum Threshold and add the Net Hits (i.e. Hits above the Minimum Threshold) to your running total then you may make another test after the Interval has passed. Once you've reached or exceded the Length with your running total the task is complete.

I recommend the terms "Progress Threshold" and "Success Threshold". Progress Threshold is more clear in meaning than minimum threshold. It's the threshold you have to make in order to progress in the task.

--

Another con is that someone who meets the threshold, but has no net hits, makes no progress.

I believe it should be (1 + Net Hits) to avoid that issue. However the system as proposed is essentially an extended opposed test, which would give credence to the progress threshold being met resulting in no progress since the defender always wins (correct me if I'm wrong), and the progress threshold would constitute the defender.

[Draco18s]

an extended opposed test

No its not. There is no opposer throwing dice (yes, I did just make up that word).
It's an extended success test: Each throw is just like a non-extended test, only your Net Hits accumulate towards a larger goal rather than being used to gauge how amazingly well you accomplished the task. In such a test 0 Net Hits is the minimum required to succeed.

[StealthSigma]

No its not. There is no opposer throwing dice (yes, I did just make up that word).
It's an extended success test: Each throw is just like a non-extended test, only your Net Hits accumulate towards a larger goal rather than being used to gauge how amazingly well you accomplished the task. In such a test 0 Net Hits is the minimum required to succeed.

I wasn't clear. When I said it functions like an extended opposed test, I was commenting on the fact that you don't actually make progress until you exceed the progress threshold if you only get net hits added towards reaching the extended test threshold. You succeeded in making progress, by reaching the threshold, but you didn't make progress since you didn't exceed the threshold. See what I'm getting at? Most tests require you to meet the threshold to succeed, opposed tests require the individual considered the "attacker" has to exceed the "defender" in order to succeed, not just match the defender. The defender doesn't need to roll any dice, the GM could arbitrarily set the number. It's a matter of what defines success that makes progress in the mechanic.

Mechanically, each individual progress test functions like opposed tests in order to make progress towards succeeding at the extended test. That's why I say it should be 1 + net hits.

[Heath Robinson]

I recommend the terms "Progress Threshold" and "Success Threshold". Progress Threshold is more clear in meaning than minimum threshold. It's the threshold you have to make in order to progress in the task.

Thanks, this terminology looks better.

Another Con I've just noticed with this (Sum of Net Hits system), though you may not find it to be one is that a person that gets 2 net hits gets twice as much progress as a person that only gets 1 net Hit, even if their number of hits were 5 and 4 respectively.

An oddity of the mathematics involved.

It was a desired property, but it can also be a Con. I did not include it in the Pro and Con lists for this reason.

The desire for this property originated from reading observations documented in a number of places (such as "The Mythical Man Month") that there's a difference in magnitude between the productivity of a "good" worker and a "mediocre" worker. Implementing this observation in SR4's system required pushing the contributions to progress per roll down to the point where the extra hit in the Expectation from 3 extra dice was a significant relative benefit. Hence the Net Hits and Progress Threshold (shiny new term!). It dovetailed with my understanding that even long-term tasks are sometimes too difficult for some people to make much progress on.

Another con is that someone who meets the threshold, but has no net hits, makes no progress.

Aye, this is probably better documented as a "Gotcha" but it's true.

---

Update:

V1.1

1. Sum of Net Hits
2. You have a running total and a Progress Threshold (named so to distinguish from the Threshold in the normal Extended Test system), an Interval, and a Success Threshold (i.e. once your total reaches this value, you've completed the task). You roll a Success Test against the Progress Threshold and add the Net Hits (i.e. Hits above the Progress Threshold) to your running total. Then you may make another test after the Interval has passed. Once you've reached or exceded the Success Threshold with your running total the task is complete.
3. Pros
   • Easy to determine what tasks you can reasonably complete using the DP/3 rule of thumb
   • Similarities to existing tests in SR4 such as casting a spell against Object Resistance (where Net Hits determine the strength of the effect), or shooting people (which adds Net Hits to damage)
   • Smaller numbers (easier to remember and add)
   Cons
   • Not compatible with existing published thresholds
   • Gotcha: meeting the Progress Threshold does not make any progress
   • Gotcha: extra dice can significantly increase progress rate when DP is near ProgressThreshold*3

[Tymeaus Jalynsfe...]

Perhaps you'll think I'm a dick, it wouldn't be the first time I've heard it (and I'm sure you'd be more polite than to put it so bluntly), but I've definitely been at tables where I was unsatisfied with the GM's glossing over undramatic situations. Perhaps it's true that I focus more on rolls than roles (not exclusively, maybe 60-40 or 65-35), but I like to see that putting my points in non-combat skills like Armorer is resulting in pips on the table, even if I know I can easily complete the task.

That is a good point...

It is Something that I don't tend to worry about all that much myself. I Tend to evaluate the skills (and DP), relevant to the difficulty and if it is not dramatic to make you roll extended tests, then I just adjudicate... for the most part, you will succeed given enough time... for those things/tasks that have a dramatic impact upon the game, then you get to roll...

Pretty simple, but not everyone likes to play that way at their table...

Keep the Faith...