The Cumulative -1 Rule, Or Khadim tries to do Mathematics Options

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