Miscellaneous Cleanup (Savage)

Context: HL Kit … Authoring Examples … Savage Worlds Walk-Through 

Overview

Based on our status assessment, we've got a lot of little things to tweak, so we might as well get them all handled and removed from our list.

Power Points Tracker

The "Power Points" tracker is always appearing on the "In-Play" tab, regardless of whether the character possesses an arcane background. We need to ensure that it only appears when a suitable arcane background is possessed. That would be any arcane background except for "Weird Science", since gizmos each have their own power points to be tracked.

There are three steps in applying this fix. The first is to modify the "ipTracker" portal that shows trackers to use a List tag expression. The Skeleton files pre-define a "Hide.Tracker" tag that we can use, so we change the tag expression to exclude any trackers that are expressly hidden.

The second step is to assign the "Hide.Tracker" tag to the "trkPower" thing. This will ensure that the tracker never appears in the table unless we specifically make it visible. We can make it visible by deleting the tag.

The final step is to modify the "Arcane" component to delete the tag. Since we want to delete the tag for all arcane backgrounds, we'll delete the tag within an Eval script on the component. That way, all arcane backgrounds inherit the behavior. We actually want to suppress the tracker for the "Weird Science" background, which we can identify via the "Arcane.WeirdSci" tag, so we'll have a special exception. This results in the script below.

<eval index="3" phase="Render" priority="5000"><![CDATA[
  if (tagis[Arcane.WeirdSci] = 0) then
    perform hero.child[trkPower].delete[Hide.Tracker]
    endif
  ]]></eval>

The tracker should now be hidden unless an appropriate arcane background is selected.

Abilities on "Special" Tab

The "Special" tab contains a list of all facets of the character that are designated for inclusion on the tab. After the name of an entry, the nature of that entry is shown within parentheses. For the various special abilities, they show two different natures. For example, edges will show both "Edge" and "Ability", while hindrances will show both "Hindrance" and "Ability". They should only be showing a single nature, and the "Ability" designation is extraneous.

If we take a look at the way the "Special" tab contents are handled, there is a "source" portal within the template. This portal uses the "tagnames" target reference and requests all tags belonging to the "SpecialTab" tag group. So the problem is that all of our abilities are being assigned two different "SpecialTab" tags.

When we modified the "Ability" component to be shared among the three different component sets (edges, hindrances, and racial abilities), we overlooked this behavior. Since the "Ability" component is shared, it should not possess its own "SpecialTab" tag. So the solution is to delete the "SpecialTab.Ability" tag from the file "tags.1st" and then modify the "Ability" component to no longer possess the tag. Once we make these two changes, abilities on the "Special" tab appear with only a single nature associated.

Names of Tracked Resources

We can now return to the "In-Play" tab to look at the presentation of tracked resources within the "ipTracker" template. Each resource is shown with its full name in a bold font. Many of the items shown in the resource list have names that are longer than will fit, so we need to handle them appropriately to maximize the chance that they do fit.

There are two different techniques that we can use, and there's no reason why we can't use both. The first thing is to realize that the majority of the items shown within the resource table possess a shorter name via the "shortname" field. Not all of them have this field, but we'll use it if it exists. This can be integrated by change the "name" portal to use a Label script, wherein the script checks for the presence of the "shortname" component and uses the field if available. The revised portal is shown below.

<portal
  id="name"
  style="lblNormal">
  <label>
    <labeltext><![CDATA[
      if (tagis[component.shortname] <> 0) then
        @text = field[shortname].text
      else
        @text = field[name].text
        endif
      ]]></labeltext>
    </label>
  </portal>

The second change is that we can shrink the font used for the name if the name doesn't fit. This entails using the "sizetofit" target reference on the portal, after which we must re-center the portal. The script code shown below can be added at the end of the Position script to accomplish this.

~shrink the name portal if it doesn't fit, then re-center after the shrink
perform portal[name].sizetofit[32]
perform portal[name].centervert

At this point, we'll be doing the best job we can of squeezing resources into the table for display.

Simplify Encumbrance Display

Another item on our task list is to modify the display of encumbrance. If the character has items that have a fractional weight, the total encumbrance shown has up to two decimal places, which just looks wrong. What we need is to show the encumbrance as a simple integer value.

If we show an integer value, the first instinct would be to round the value off normally. That would mean that a value of 14.4 would be rounded off to 14 and a value of 14.5 would become 15. While this works great in concept, it fails in a very important way. If the character maximum load is 40 and the character has gear totaling 40.1 pounds of weight, the encumbrance exceeds the limit and will be flagged as a problem, but the total encumbrance will be shown as 40 with normal rounding. To avoid problems like this, we need to always round the value upwards, so a value of 40.1 becomes 41 when rounded.

We only need to worry about the rounding for the value that is actually displayed to the user. The internal value should be maintained with maximum accuracy. The value displayed is synthesized within the second Eval script for the thing "resEncumb". We can revise this script to round the value before displaying it, which looks like the following.

~show the total weight carried and the maximum for the current load level
var spent as number
spent = round(field[resSpent].value,0,1)
field[resShort].text = spent & " / " & field[resMax].value

Encumbrance of Stacked Items

The mechanism for tallying encumbrance appears to have a problem. Items that possess a quantity of one are being added correctly to the overall encumbrance total. However, an item with a quantity greater than one is only adding its weight a single time. If the quantity is greater than one, the total accrued weight must be the individual weight of the item times the total quantity possessed.

The accrual of weight for encumbrance is handled within the second Eval script for the "Gear" component. Fixing this problem entails properly recognizing when the quantity is more than one and multiplying by the quantity. This can be resolved by modifying the Eval script to the one shown below.

~if this piece of gear is held by something else, ignore it - we'll get it below
if (isgearheld <> 0) then
  done
  endif

~if this piece of gear is a topmost holder, ignore it - it's not on the character
if (tagis[thing.holder_top] <> 0) then
  done
  endif

~determine the net weight of the gear, being sure to multiply by the quantity
var weight as number
weight = field[gearNet].value
if (stackable <> 0) then
  if (field[stackQty].value <> 1) then
    weight *= field[stackQty].value
    endif
  endif

~accrue the net weight of this piece of gear into the encumbrance resource
perform #resspent[resEncumb,+,weight,field[name].text]

Verify Trappings Are Changed

Each arcane power begins with trappings that list assorted possibilities from the rulebook. The user is expected to edit the trappings and specify the actual behaviors for each power. At present, there is no check in place for verifying it has been changed.

While we can't verify that the trappings are valid (it's arbitrary text), we can verify that the user has at least modified the field from its original contents. This is achieved via use of the "ischanged" target reference on the field.

The best way to handle this is by defining a new Eval Rule. If the rule is not satisfied, then a suitable error message can be output to the validation report. To ensure that the rule is applied equally to all arcane powers, we'll add the rule to the "Power" component. This results in the new Eval Rule below being defined.

<evalrule index="1" phase="Validate" priority="5000" 
    message="Trappings must be specified for the power"><![CDATA[
  if (field[powTraps].ischanged <> 0) then
    @valid = 1
    endif
  ]]></evalrule>

Names Within Summary Panels

There are a number of places within the summary panels where the names shown extend past the edge of the panel. It would be much better if the names were to fit fully within the available space. One option would be to widen the summary panels, but that would reduce the number of visible panels to one, so that's not a good idea. Many of the items shown within the summary panels have been converted to support "short names". As such, a better solution would be to make use of the shorter name within the summary panels whenever one is available.

Switching to the "shortname" field is quick and easy within the summary panels. There are four templates that can be switched. These templates show abilities, traits, weapons, and defensive equipment. Since all of these different items support "short names", we can safely change each of the templates to reference the "shortname" field instead of the "name" field. After that, the shorter name will be shown whenever one exists.

Knowledge Skills in Summary Panels

Within the "Abilities" summary panel, skills are shown with the appropriate name. However, skills that require a domain, such as "Knowledge", do not include the actual domain. It's important that the domain be included.

The first consideration we face is that the name of the "Knowledge" skill virtually fills the width of the summary panel when at its narrowest. Even if we appended the domain, it would be of no practical value to the user. We need to shorten the name that is displayed. Fortunately, this can be achieved if we utilize the "short names" mechanism that is already specified for traits. If we specify a "shortname" of "Knw", then we can readily include the domain within the name displayed.

The second issue is actually handling the domain properly. The "smTrait" template is used for attributes, derived traits, and skills. So we can't just assume that a domain may be present. We have to test for both the presence of a skill and the use of a domain. Only if both criteria are satisfied should we append the domain to the name. We need to use a Label script to synthesize the proper results, so we'll change the "name" portal within the template to the following.

<portal
  id="name"
  style="lblSummary">
  <label>
    <labeltext><![CDATA[
      @text &= field[shortname].text
      if (tagis[component.Skill] + tagis[User.NeedDomain] >= 2) then
        @text &= ": " & field[domDomain].text
        endif
      ]]></labeltext>
    </label>
  <mouseinfo/>
  </portal>