gcs icon indicating copy to clipboard operation
gcs copied to clipboard

Changing how Pool Attribute Threshold Operations Work

Open rinickolous opened this issue 3 years ago • 0 comments

In an effort to implement "The Last Gasp" rules from PY203:4, I'd like to see a change to the way Pool Attribute Threshold Operations are handled. To allow for the currently implemented Basic Set functionality (On "Tired", Halve ST, Halve Move, Halve Dodge; on "Reeling", Halve Move, Halve Dodge), as well as "The Last Gasp" functionality (After every 1/5 threshold of FP lost, -10% ST, -1 DX/IQ/HT, not affecting total HP/FP), I would like to suggest a move away from the checkboxes currently available for Pool Attribute Thresholds. The changes are as follows:

  • Implement a function similar to Features available under Thresholds. This could be limited to Attribute Bonuses, though it doesn't necessarily have to be. I don't know of a RAW use case for modifying things other than Attributes using Thresholds.
  • Allow the Attribute Bonus feature to increase/decrease the Attribute by a percentage of its current/total value, and/or allow it to be multiplied instead of added to/subtracted from. Either of these would work for the above use cases. I think the multiplier option would work better, taking into consideration the double-effect of, for example, Reeling and Tired from Basic Set, which currently divides the Move and Dodge values by 4 (halve, then halve again), instead of taking away 100% of the base value (-50% applied twice). Importantly, as I think is already being done with the way they currently work, these modifiers to Attributes should be applied after any other modifiers.
  • Separate the "base" values of Attributes (after all non-threshold modifiers) from their values after being affected by Thresholds. Adding damage and calc.current values to non-pool Attributes would be, in my opinion, the most consistent way to do it. In doing so, especially combined with the suggestion in #410, one could base, for example, Lifting/Striking/Throwing ST on $st.current, while HP is based on $st. This, I believe, would solve the issue of having to account for special cases where derived attributes should/shouldn't be affected by a change to their parent attribute, in a generic manner. In terms of appearance, I think the change in attributes effected by Threshold Features should be visually reflected on the character sheet. I know that currently, the value of ST does not appear to change when FP reaches its "Tired" threshold, while functions related to ST (like Basic Lift) are visually affected. To clearly indicate that an attribute has been affected by a Threshold, I think a change in the displayed color of the attribute, as well as a tooltip indicating the change, would visually communicate to the user that, no, they didn't accidentally halve their ST value, it's just a temporary thing.

rinickolous avatar Jan 22 '22 14:01 rinickolous