Question about multi stat strength in racial template

[TorgSmith]

I am trying to create a racial template for the Traveller K’kree for 4th edition. I am using the Classic GURPS Traveller Alien Races 2 book as a reference. It is saying that the ST is +2/+20. The description is as follows.

K’kree have split strength, normally of 12/30. The lower number is for their torso area and arm damage will be based upon it. The higher number represents main body ST; kicking damage, encumbrance, and travel Fatigue will be based upon it.

I am not sure how to represent this in GCA. Could somebody suggest a way to handle this?

[sir_pudding]

RAW 4e doesn't really have Split ST, but rather prefers to use the Weak Arms limitation. Alternately (and slightly less RAW, in that nothing published does this), you could put TD: NFM on the extra ST.

[ericbsmith]

Yup. Essentially the K'kree would have the disadvantage Weak Arms (2 Arms) at the 1/2 ST level, which is a disadvantage built using the rules from the limitation of the same name under the Extra Arms advantage. It's in GCA, and has been for years.

That's RAW. Unfortunatley, IMO it seriously gimps "centaur" type characters, because the disadvantage value is small (only -5 points) and it requires them to buy their ST at full value; on top of that they have to buy two levels of ST to get one level worth of arm ST, which is what really screws them over. But that's RAW in 4e.

Personally, I'm not sure the best way to handle it. I'd probably just treat it as a limitation on ST - "Weak Arms, -40%." and "Weak Arm, -20%." This is the same cost as the NFM limitation, which seems fair to me, because while the price break is the same the character doesn't get the extra points from actually having NFM. Extra arms would be built using the normal rules for the Weak Arms limitation, and could exceed the normal arm ST.

[TorgSmith]

Yeah, I just decided to go with a +4 ST and call it good.

I had started going down the path of creating a Carrying ST that would default to 0 and cost 2 per point to raise. I charged 2 because the only stat it would affect was encumbrance. I had done a ReplaceTags on the Encumbrance stats adding in Carrying ST (although, I realized it should have added (Carrying ST * Carrying ST)/5 instead).

I think I had everything working when I went to test. The BL was not displaying how much could be carried because I did not want to modify that stat as the torso needed to be limited to that. I started looking into the Phoenix character sheet and realized I would have to modify it to display the different encumbrance stats. I did not want to do that as it would complicate updates.

[sir_pudding]

Originally Posted by ericbsmith

Personally, I'm not sure the best way to handle it. I'd probably just treat it as a limitation on ST - "Weak Arms, -40%." and "Weak Arm, -20%." This is the same cost as the NFM limitation, which seems fair to me, because while the price break is the same the character doesn't get the extra points from actually having NFM. Extra arms would be built using the normal rules for the Weak Arms limitation, and could exceed the normal arm ST.

Any reason why TD: NFM doesn't work? If foot manipulators are TD:No Legs and your prosthetic arm can have TD: Electrical, I don't see how this is different.

[TorgSmith]

One problem with NFM is that the Lifting Feats table shows the modified weight. The torso can’t lift that weight.

Now I had not considered the Lifting Feats table in my original work. I need the Lifting Feats table to show the weaker strength and the Basic in the Encumbrance table to show the greater strength. I originally wanted the Encumbrance Table to show both and it should not.

I may need to look at this again.

[ericbsmith]

Originally Posted by sir_pudding

Any reason why TD: NFM doesn't work? If foot manipulators are TD:No Legs and your prosthetic arm can have TD: Electrical, I don't see how this is different.

Well, for one thing you never actually suffer from the TD: NFM. When, you have TD: No Legs that means that, occasionally, you will have to sit down and lose the use of your legs as legs so that you can use them as arms. With TD: Electrical an EMP or bucket of water will actually cut off the use of your prosthetic limb.

With your proposed TD: NFM at no point do you ever actually lose the use of your manipulating appendages, thus you never actually suffer from NFM, even temporarily. When a Centaur is hauling around a 400 pound knight on his back he can still be swinging a sword or shooting a bow. So he really doesn't have a Temporary Disadvantage.

[sir_pudding]

Originally Posted by ericbsmith

With your proposed TD: NFM at no point do you ever actually lose the use of your manipulating appendages, thus you never actually suffer from NFM, even temporarily. So you really don't have a Temporary Disadvantage.

Every time you actually use that extra ST. You want to use it to lift something? Can't use your hands. Want to slam something? If you use a weapon to slam you can't use those extra HP in your Slam damage; just upper body.
EDIT:

Originally Posted by ericbsmith

When a Centaur is hauling around a 400 pound knight on his back he can still be swinging a sword or shooting a bow. So he really doesn't have a Temporary Disadvantage.

When a parrot is holding food in one foot it can be standing on the other, so it doesn't really have No Legs. When prosthetic arm-guy is hit by a EMP pulse only one arm is affected so he doesn't really have Electrical.

[TorgSmith]

Ok I redid it and Phoenix would need a change for it to work.

On the Encumbrance Table Thomas is recalculating the Basic row from Basic Lift as opposed to using the actual encumbrance values. He is using the actual encumbrance level to mark the current encumbrance level as I put a 100lbs item on the character and it was marked “None” on encumbrance table. By the values showing in the Basic row 100lbs should be “Med”. I added more 100lbs items to the character and the encumbrance level bumped up to “Light” so it looks like it is working.

I don’t know if Thomas would be willing to have the Basic row display the actual encumbrance level weights instead of recalculating them. I sent him an email.

FINAL EDIT: What I did if you are interested. This should be correct now.

************************************************************************************************************************
[ATTRIBUTES]
************************************************************************************************************************
Carrying ST, basevalue(0), step(1), maxscore(1000000), minscore(0), up(2), down(0), round(-1), display(No)
Basic Carry, basevalue(@if(ST:Carrying ST::score > 0 then @int(100 * (ST:Lifting ST + ST:Carrying ST) * (ST:Lifting ST + ST:Carrying ST) / @if(ST:Metric = 1 THEN 11 ELSE 5)/100) else ST:Basic Lift)), maxscore(1000000), minscore(0), round(@if(ST:Lifting ST::score + ST:Carrying ST::score <= 7 then 0 else 1))

#ReplaceTags in "ST:No Encumbrance" with "basevalue(ST:Basic Carry)"
#ReplaceTags in "ST:Light Encumbrance" with "basevalue(2 * ST:Basic Carry)"
#ReplaceTags in "ST:Medium Encumbrance" with "basevalue(3 * ST:Basic Carry)"
#ReplaceTags in "ST:Heavy Encumbrance" with "basevalue(6 * ST:Basic Carry)"
#ReplaceTags in "ST:X-Heavy Encumbrance" with "basevalue(10 * ST:Basic Carry)"

************************************************************************************************************************
[ADVANTAGES]
************************************************************************************************************************
<Attributes>
Carrying ST, 2/4, page(B14), gives(+1 to ST:Carrying ST), cat(Exotic, Physical), description(This modifier causes the Carrying ST advantage to affect the Encumbrance Table Basic row.)

[tmedwards]

Originally Posted by TorgSmith

On the Encumbrance Table Thomas is recalculating the Basic row from Basic Lift as opposed to using the actual encumbrance values.

There's a reason for that. Only two of the, four or five (yes, there's more than one), encumbrance lifting modes that Phoenix supports actually has traits for encumbrance, and one of those has only had them for the past couple years. The same code is used for all of the modes, so it had to work for all of them.

I'd rather not have a special case stuffed into the middle of that… but it's not an unreasonable request, so… let me think about it.