Revise Adjustments (Savage)

From HLKitWiki
Jump to: navigation, search

Context: HL KitAuthoring Examples … Savage Worlds Walk-Through 

Overview

With all of the basic building blocks for characters now in place, we can assess the various temporary and permanent adjustments that can be applied to characters. The Skeleton files provide a starting set that we can convert appropriately and expand upon for Savage Worlds.

Identify Nature and Context

The first step is to identify all of the different adjustments that users may want to apply to a character. Once the nature of each adjustment is determined, then the context in which that adjustment can be applied must be assessed. Each adjustment must be designated as being applicable permanently, temporarily, or both. Some adjustments only make sense in one context or the other, such as attribute points only being a permanent change, while weapon attack bonuses only being a temporary change. However, there are quite a few that can be applied in either context.

In the case of Savage Worlds, there are many adjustments that can be applied to a character. After scanning the rulebook, the following set of adjustments should be supported, along with the valid context(s) for each.

  • Attribute die type - permanent or temporary
  • Attribute roll - permanent or temporary
  • Skill die type - permanent or temporary
  • Skill roll - permanent or temporary
  • Derived trait - permanent or temporary
  • Weapon attack - temporary only
  • Number of advances authorized - permanent only
  • Number of edges granted - permanent only
  • Starting attribute points - permanent only
  • Starting skill points - permanent only
  • Number of arcane powers - permanent only
  • Number of arcane power points - permanent or temporary
  • Number of Bennies per game session - permanent

Define Adjustments

Once the list of adjustments is defined on paper, they can be implemented in the data files. Open the file "thing_adjustments.dat" and you'll find an assortment of adjustments provided by the Skeleton data files that we'll be modifying. There are a variety of tags and fields used by adjustments to appropriately configure the behavior of the adjustment. For each adjustment, the Eval script only applies its effects if the pick has been assigned the "Helper.Activated" tag. This tag is automatically assigned via a component script if the user activates the effects of adjustment. Permanent adjustments are implicitly activated, so their effects are always applied.

We'll examine two adjustments as examples. We'll start with the adjustment for the starting attribute points, since it doesn't involve the use of menu selection. The adjustment requires the user to manipulate its effects, so the "Helper.UserAdjust" tag is assigned. As part of that manipulation, an incrementer should be shown that allows the user to determine the modification to be applied, so the "AdjustShow.Increment" tag is assigned. Since attribute points only affect character creation, any adjustment to them is effectively permanent in nature, so we assign the "InPlay.PermOK" tag to indicate that this adjustment is suitable for selection as a permanent adjustment. The net result is something similar to the following.

<thing
  id="adjAttrPt"
  name="Attribute Points"
  compset="Adjustment"
  description="Select this adjustment to...">
  <tag group="AdjustShow" tag="Increment"/>
  <tag group="Helper" tag="UserAdjust"/>
  <tag group="InPlay" tag="PermOK"/>
  <eval phase="Setup" priority="8000">
    <before name="Calc trtFinal"/><![CDATA[
    if (tagis[Helper.Activated] <> 0) then
      #resmax[resAttrib] += field[adjUser].value
      endif
    ]]></eval>
  </thing>

Our second example is an adjustment for modifying the die type of an attribute. As with the example above, user manipulation is involved, so we use the "Helper.UserAdjust" tag. For manipulation, an incrementer is used to specify an amount and a menu is shown through which the user will select the attribute to be adjusted, so we have both the "Adjust.Increment" and "AdjustShow.Menu" tags. The behavior of the menu is controlled via two fields on the adjustment. The field "adjUsePick" dictates whether the menu should be selecting a thing or a pick, with a non-zero value indicating a pick. Since we want the user to select an attribute that is already added to the character, we specify a value of one. The field "adjCandid" specifies the tag expression to be used to identify the list of picks to display within the menu. Since we want to display all of the attributes, we use a value of "component.Attribute" for the field. Since an attribute adjustment might be either permanent or due to an in-game effort, we assign both tags to make it selectable as either a permanent or temporary effect. 

The last detail of note is that the attribute to be adjusted is selected via the menu, so we need to identify the proper attribute through the menu. We assume that the menu portal associates the selection with the "adjChosen" field on the adjustment. We can then access the field and obtain the pick chosen within it via the "chosen." script transition. Once we have the proper attribute, we can then access fields on it using the standard methods and apply the adjustment appropriately.

Putting it all together yields an adjustment thing that looks very similar to the one shown below.

<thing
  id="adjAttrD"
  name="Attribute Die"
  compset="Adjustment"
  description="Select this adjustment to...">
  <fieldval field="adjUsePick" value="1"/>
  <fieldval field="adjCandid" value="component.Attribute"/>
  <tag group="AdjustShow" tag="Increment"/>
  <tag group="AdjustShow" tag="Menu"/>
  <tag group="Helper" tag="UserAdjust"/>
  <tag group="InPlay" tag="PermOK"/>
  <tag group="InPlay" tag="TempOK"/>
  <eval phase="Setup" priority="8000">
    <before name="Calc trtFinal"/><![CDATA[
    if (tagis[Helper.Activated] <> 0) then
      field[adjChosen].chosen.field[trtInPlay].value += field[adjUser].value
      endif
    ]]></eval>
  </thing> 

Verify Behaviors

The last step is to go through and verify that all of the adjustments work as we intend. When we do this, we'll discover that the template being used for selecting the adjustments is cutting off the edge of the name of long adjustments. If we open up the file "tab_personal.dat" and look for the table portal for adding adjustments, we'll see that the "choosetemplate" specified is "LargeItem". Similarly, if we open the file "tab_inplay.dat" and look for the table portal used to add adjustments, we'll see the same usage.

Since the "LargeItem" template is used for a variety of purposes, we can't modify the width without changing it for every use. However, the "LargeItem" template has been designed with the same customization logic as the "SimpleItem" template that we leveraged earlier. This means that we can define a suitable component tag on the "Adjustment" component to cause the "LargeItem" template to use a larger width when showing adjustments for selection by the user. All we need to do is add the XML element below to the "Adjustment" component and everything should look the way we want.

<tag group="SimpleItem" tag="width250"/>