b214

* Miscellaneous

Made a fix to how GCA returns baseweightconverted() for baseweight(). It should now work properly and more safely.

For backward compatibility reasons there were two different but nearly identical versions of the damage special-case substitution handling routine. I have now updated one to just call the other.

* Mode-Specific Calculations

People often lose track of the context required for bonuses to modes and the use of mode-specific values. It’s not possible for GCA to get or use the value of a mode-tag from outside of the calculation of that mode. That’s why bonuses that make use of mode-specific values, such as ‘chareffectivest’ or ‘charskillscore’ have to be done as bonuses to ::damage$. Bonuses to ::damage$ are simply aggregated with the existing damage() tag and then calculated all together, along with normal bonuses. This allows GCA to have on hand the values needed for mode-specific requests made with $modetag().

This is very easy to lose track of, and can be confusing, I know, but it’s just not possible for a bonus to know the values of the mode it’s being applied to in advance, when there are so many possible modes to which it might apply..

In the existing data files, this necessary context was lost for some bonuses, causing them to return inaccurate or non-context-sensitive results.

In light of this, and to render those bonuses functional again, I added some new features which should address the issue.

First, I have added support for a Mode to return BaseSwDice and BaseThDice for itself. It does this by checking to see if it has a ‘chareffectivest’ value, and if so uses that with the @BaseSWDice() or @BaseTHDice() function of the Solver and returns the result; otherwise it returns the BaseSWDice or BaseTHDice from the Character.

Second, I have added some new special case damage substitutions. If the damage text being calculated contains ‘owner::basethdice’ or ‘me::basethdice’, GCA will replace that text with the Mode’s new BaseThDice result. Likewise, if the damage string contains ‘owner::baseswdice’ or ‘me::baseswdice’, GCA will replace that text with the Mode’s new BaseSwDice result. Note that this is because owner:: is only used from modifiers, and isn’t applicable in a late-resolution bonus string such as those to ::damage$, so it’s assumed that it’s intended to be the target item’s score, the same as me:: would be.

Note that you can now also use $modetag(basethdice) or $modetag(baseswdice) to get those mode-specific results, even though they aren’t technically mode tags, and using this construction is preferable to owner::baseXXdice for clarity.

These changes together with those in Special Damage Text section below should fix the known problems with these bonuses, in place, without users having to make changes to existing character data.

* Special Damage Text

There are sometimes problems calculating certain specialty damage types. For example, calculating something like ‘slam+3’ and granting it bonuses might result in ‘slam+3+lots of nonsense code’ or such, usually because of the hoops that need to be jumped through to do mode-specific adjustments to damages. On the other hand, something like an affliction with damage() of ‘HT-$solver(me::level – 1)’ correctly returns HT+X, but if it too gets a bonus, it might also return ugly unhelpful results.

My previous attempt at addressing this incorrectly resulted in damage for afflictions and some weapons returning empty damages, because I didn’t realize the full impact at the time.

My new attempt tries to work around the issue by recognizing that some damages are based on a ‘prefix’ such as ‘slam’ or ‘HT’ and calculating the stuff that isn’t the prefix, then returning it at the end recombined with the prefix.

This new method includes support for user-specified prefixes simply by enclosing them in square brackets [] as the very first part of the damage() tag for that mode. Support for ‘slam’ is built in without needing the brackets, and for things like afflictions you shouldn’t need to use it unless you’re adding bonuses and don’t like the resulting HT+X+Y that may occur. But if you do change it to ‘[HT]+$solver(me::level – 1)’, then GCA should use the new method to return a more pleasing HT+X result with the combined values.

Currently, if the calcs result in a prefix+0, that +0 will still be shown, it will not be dropped. In addition, if the prefix isn’t explicitly specified (or built-in like ‘slam’), then it may be lost if a damage bonus includes some number of dice, and then you’ll need to add brackets around the prefix, such as in the affliction example above..