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

b213

Added some safety checks to the CalcApplicableModeTargetTagXXX(Mode, String) routines, because it is possible to try to use them without an actual mode set, and that is bad.

The special #note() directive for Select() list items has been improved. Displayed notes are now indented to make a more clear separation between the note and the general list items. Also, you can now use limited BBCode formatting in the note, and if you do that, you should use ‘[BB]’ or ‘[BBCode]’ as the first characters in the #note(); they will be stripped off, but tell GCA to use the BBCode engine to draw the text.

GCA will now remove packageupdater2.exe from the appdata folder during the startup process that cleans up after updates.

* SkillScore and Parry for Attacks

Most of the time, a bonus to an attack’s SkillScore is intended to raise the general use of the skill for the attack, including Parry for melee attacks. However, there are certain times where the bonus is intended to apply only to the attack usage, and not to the parry usage. The way to reflect that in the bonus was to subtract back out the bonus from the calculated Parry, and that was quite complex and confusing because it would get applied after all normal calculations for parry were already made. Here’s an example of that:

gives(+1 to owner::skillscore, 
      =-(@int($modetag(charskillscore)/2) - @int(($modetag(charskillscore) - $solver(me::level))/2)) to owner::parryscore$ _
)

I have now added a new bonus target for use during the calculation of ParryScore: preparryscore. This allows you to simply apply an adjustment to the version of charskillscore that will be used in the parryat() calculation, before the parryat() calculation is made. This means that you can now simply apply a negative version of the positive bonus going to ::skillscore to ::preparryscore to counter it out for parry purposes. Here’s an example:

gives(+1 to owner::skillscore, 
      -1 to owner::preparryscore _
)

This should be faster and easier for everyone.

* Ammo

I did all the code necessary to convert ammo() to charammo() and store charammounits() for reference. And then I discovered that Ultra-Tech uses ammo() for something completely different, which looks like letter codes of some kind. That’s obviously incompatible, so I’ve disabled the ammo() calc stuff until I can figure out what that’s all about and if I can move things around or if I’ll just have to ignore that for a while.

* Weights and unit conversions

GCA will now create two new calculated tags when calculating equipment items: baseweightconverted() and baseweightunconverted(). The value in baseweightunconverted() is the solved value of baseweight(), or the result of baseweightformula() if that is used, before any automatic unit conversion is performed. The value of baseweightconverted() is that value after automatic unit conversion is performed.

Now, when GCA processes a reference to ::baseweight or TagItem(“baseweight”) it will return the value from baseweightconverted() instead. If you really need the unconverted value, reference it explicitly.

This change comes about due to the discovery that all the calculations for items are using the units-converted value, but bonuses referencing ::baseweight would be getting the unconverted original tag value from GCA. So calculations proceeding from that point would include values using two different scales of units, and the final result would be incorrect.

If you’re not using unit conversion, then this should not affect any results, and all three values should be the same.

* Solver

Added a new function, @getnum(<text>) which returns the first numeric portion found in the given text, as best as it can determine. Note that special case substitutions and $ functions will be resolved before the function is called (that’s how the solver works), but embedded @ functions will not be resolved within this function because the purpose of the function is to get a number out of text, and if you need it solved, you don’t need this function.

The text is searched from left to right to find the first number. If it finds a – it will allow for a negative number, but only if the – is immediately to the left of the first numeric character. It will allow for decimal values if the decimal follows a number or is the first character of the text being checked and is followed by a number.

* TagDefs.xml

Added entries for baseweightconverted and baseweightunconverted.

b211

The RequestRunSpecificOptions system was not implemented for Print Previewing at all, and was incompletely implemented for Printing. I have fixed that. Note that this system is not available for Sheet View, or when printing from the print buttons on the Sheet View or Print Preview dialog because those buttons print the displayed sheet, they do not cause the sheet to go through the setup process again, which is required to enable RequestRunSpecificOptions. When Run Specific Options are available in a sheet, you will want to set them by using Print Preview or using a print option from GCA’s primary toolbar or menu system.

The default Sheet View sheet for the system was empty, so it would default to the first sheet in the list if not otherwise set. That has now been changed to the Official sheet.

* GM Control Sheet

Version 1.0 included.