Up a bit, down a bit (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.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.