Converting Enhancements to Limitations and Vice Versa

[Kelly Pedersen]

The thing is, though, your objection seems to be based on the idea that Rev. Pee Kitty was proposing his solution as some sort of general rule of reversing limitations into enhancements, when he clearly wasn't. The proposal in the thread you linked had a clear context, of trying to build an advantage that's limited, but with a way of getting around that limitation. It was simply a demonstration of how the math works for Either/Or Limitations builds.

Certainly, in the case of trying to remove an inherent limitation of an advantage with an enhancement, this method isn't useful. You have to work out how much extra utility the enhancement adds and base the modifier on that. It's true that you couldn't say "Well, this enhancement turns this 70-point advantage into something more like a 100-point advantage, so therefor this must be a +30% enhancement". But no one was suggesting that in the first place, so this seems like a bunch of complaining about nothing.

[David Johnston2]

Originally Posted by kdtipa

100 points is the balanced price for jumper without having to arrive naked.

Bah. It isn't "balanced" against anything. It's just a nice even number that is big enough that you need superheroic point levels to afford it. It could easily be 90 points or 110 points without making a significant difference in it's affordability. But pretty much everything after 50 points is a multiple of 50 points for ease of calculation.

[Varyon]

Originally Posted by Curmudgeon

But when you need to convert a known Limitation into an unknown Enhancement, reversing the sign doesn't work.

Ah, you're talking about basically taking a Limitation that is on some other Advantage (or is generic), taking an Advantage that already has the same effect as for the Limitation by default, then working out an Enhancement to negate that part. For example, many abilities have a built-in FP cost, so you'd want to work out (note we're assuming Reduced Fatigue isn't already an available Enhancement for this example) a way to reduce or eliminate that cost.

In that case, there are actually two things that need to be worked out. The minimum is, as you note, the fact that you really need to boost the absolute value to make the math work out right - -5% (as for Costs FP) would reduce the price of the theoretical original Advantage to 95%, or 19/20, so for an Enhancement to boost this to 100%, it would need to be 20/19, or +5.26%. In this case, rounding down to +5% is probably alright, simply due to the small numbers involved - but as you note, a -30% - dropping price to 14/20 - would need to become +42.9% (20/14), which you might want to round up to +45%.

The other is much more subjective. Basically, GURPS design purposefully skews prices a bit, under-refunding for Disadvantages (and Limitations) and over-charging for Advantages (and Enhancements). This isn't always the case - Vulnerability and IT:DR have prices that negate each other perfectly, for example - but is often in play. The reasoning is that the character/player can purposefully engineer and manipulate the situation to minimize the impact of Disadvantages/Limitations and maximize the impact of Advantages/Enhancements. When all you have is a hammer, you find ways to treat every problem as a nail - a character who has special abilities at night time (Dark/Night Vision, Advantages Limited with Night Only, etc) will do their adventuring at night and handle the less dangerous but still important bits (sleeping, packing, researching, etc) during the day, while one who is weaker at night (Night Blindness, Nyctophobia, Advantages Limited with Day Only, etc) will do just the opposite. This is a big part of why Reduced Fatigue costs so much more than the +5% we calculated above.

[Donny Brook]

Originally Posted by Varyon

Shockingly, it turns out the GURPS Assistant Line Editor actually has some idea of what he's talking about. Things get different if you use Multiplicative Modifiers, but that's an optional rule, and one that essentially no other rules are based on.

The quote you provide is not germane to his objection.

Mathematically, when you start from 70 points as PK's method has you do at one point, it takes more than +30% to get to 100.

[David Johnston2]

Originally Posted by Donny Brook

The quote you provide is not germane to his objection.

Mathematically, when you start from 70 points as PK's method has you do at one point, it takes more than +30% to get to 100.

And it doesn't have to because GURPS advantages aren't built like that.

[Kelly Pedersen]

Originally Posted by Donny Brook

Mathematically, when you start from 70 points as PK's method has you do at one point, it takes more than +30% to get to 100.

PK's method never suggests you apply the modifiers he lists to 70 points, which is easy to demonstrate if you do the math. He mentions that his hypothetical "Not Naked but Preparation Required" enhancement is +21%, then gives the cost of Jumper with it as 91 points. If he was applying it to the 70 point cost of Jumper, it would be 85 points. Instead, he's doing the absolutely standard GURPS modifier math, of adding all modifier values together, then applying the result to the base cost of the advantage. Naked, -30%, plus "Not Naked With Preparation Required", +21%, works out to -9%, which is applied to the base cost of Jumper, 100, for a final result of 91 points. Which is exactly what he said in the example.

[evileeyore]

Originally Posted by David Johnston2

Bah. It isn't "balanced" against anything. It's just a nice even number that is big enough that you need superheroic point levels to afford it.

Exactly, I ran a campaign once with Jumper costing only 20 points because I wanted it available without having to give the Players loads of points.

[malloyd]

Originally Posted by Curmudgeon

This has been bothering me for a long time. Changing the sign in front of the percentage value to convert a Limitation into an Enhancement or vice versa, doesn’t yield the results it should.

You have essentially rediscovered that the additive and multiplicative identity elements are not equal. That is 0 is not equal to 1.

Everybody knows that the way GURPS figures enhancements and limitations is mathematically weird in exchange for being simple. It's not fixable - change the values to something that works "right" for your example and then apply them in the other order to something that has the other starting default, and hey look the value is wrong again....

Really though, if you think applying modifiers is a fine tuned mathematical algorithm that should always give perfect results, you're missing a key point. They really are quick GM guidelines. The jumping through hoops to build complex traits from them we routinely do here, which is then touted as giving the "correct" value is in fact a pretty terrible way to use them in actual play.

I strongly recommend that anything that has more than two modifiers stuck on it be looked at very carefully. Price it arbitrarily by feel from the (non-rules speak) description of the effect, and if your guess there comes significantly different from the result you got from applying the rules, don't just go with the RAW version.