More Cleanup (Savage)

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

Overview

Our list of things we came up with previously is almost fully addressed. Let's take this opportunity to do another round of testing everything and see if there's anything we missed last time. Then we can knock off the remaining little things on our list.

Another Assessment

-red X next to dead things on taccon

-add menu tracking and selection for Scholar and Profesional/Expert/Master edges

   -add to character sheet

-Parry must handle a Fighting stat of "d12+X", which adds half of X, rounded down

-Toughness must handle a Vigor stat of "d12+X" the same way

-build in editor support for users to add custom material

-cleanup of all unused mechanisms from Skeleton files

-delete stuff from files that is not needed for SW

-add all creatures from the bestiary as a stock portfolio - see page 125

-If a linked skill does not exist (e.g. Shooting), must apply -2 adjustment for weapon

-superpower skill names are too long to fit in skills list on character sheet

       -move them down with domain-based skills

-name on skills tab must use the "thingname" else domain is included in name

-title above attriubtes on Basics tab needs to include amount spent

-foreign gizmos are being counted towards total number of arcane powers chosen

-add arcane powers resource onto Basics tab only when an arcane edge is taken

Damage and Non-Wildcards

On the "In-Play" tab, we make the assumption that all characters can take four levels of damage. However, this only applies to wildcards. Non-wildcards take one hit and go down. After looking into this a little bit further, it seems that we've made this assumption through the data files. We need to properly handle the situation where a character has a different maximum number of wounds based on the wildcard designation.

The first thing we need to do is setup a new field into which we can save the appropriate maximum number of wounds. Since the field value is based solely on the wildcard state of the character, we can use a Calculate script on the field to easily determine the value. We need to be sure to schedule the script early, since other scripts will rely on this value. This yields a field that looks like the following.

<field
  id="acMaxWound"
  name="Maximum Wounds"
  type="derived">
  <calculate phase="Initialize" priority="1000"><![CDATA[
    ~if we're a wildcard, we can take 4 wounds, else only one
    if (field[acIsWild].value <> 0) then
      @value = 4
    else
      @value = 1
      endif
    ]]></calculate>
  </field>

With the field in place, we can now go through the data files and identify places where the field needs to be utilized. We'll do a search for references to the "acWounds" field to locate places where a change may be needed. It turns out there are two places within the "Actor" component and another two places within the "In-Play" tab.

The Finalize script for the "acDmgSumm" field uses a hard-coded value of four when determining whether to show the wounds as "Inc". We can replace the four with a reference to the "acMaxWound" field. The new line of code should look like below.

if (wounds <= -field[acMaxWound].value) then

Similar logic is utilized within the Finalize script for the "acDmgTac" field. Again, we replace the four with a reference to the field.

Shifting our focus to the "In-Play" tab, both the "wounds" and "wndsustain" portals reference a hard-coded value of four. Both of these references need to be replaced with the field. The new line of code for the Label script in the "wounds" portal is shown below.

if (wounds > -field[acMaxWound].value) then

All of the handling for wounds is now properly differentiating between wildcards and non-wildcards.

Lead Summary Script

When a lead character is saved out to a portfolio, a summary of that character is synthesized and stored in the portfolio. This summary is displayed along with the name when the user attempts to import characters from that portfolio. The summary is synthesized via the LoadSummary script, whose purpose is to provide a brief (but useful) synopsis of the character.

The LoadSummary script is defined in the file "definition.def", and the Skeleton files provide us with a basic implementation. We'll adapt the one provided for Savage Worlds. The question is what information we should include. Savage Worlds characters have no clear role (such as classes), so there's really nothing definitive we can say about a character beyond its race and rank/XP. This leaves us with a script implementation that looks like the following.

~start with the race
var txt as string
txt = hero.firstchild["Race.?"].field[name].text
if (empty(txt) <> 0) then
  txt = "No Race"
  endif
@text &= txt

~append the rank and XP
var rankvalue as number
var ranktext as string
rankvalue = herofield[acRank].value
call RankName
@text &= " - " & ranktext & " - " & herofield[acFinalXP].value & " XP"

Arcane Power Totals

If a character with an arcane background adds a foreign gizmo on the "Gear" tab, that gizmo is being counted towards the total number of arcane powers selected by that character. Foreign gizmos need to be ignored when tallying up the number of powers chosen for the character.

The tallying of each arcane power is performed within an Eval script on the "Power" copmonent. This script always consumes one power slot for each power. We need to modify the script to skip any power with the "Helper.Foreign" tag. The revised script should look like below.

if (tagis[Helper.Foreign] = 0) then
  perform #resspent[resPowers,+,1,field[name].text]
  endif

Show Arcane Powers Resource

The "Basics" tab contains all of the various resources that a user will want to monitor during character creation, except for one. If the character has an arcane background, the list of resources does not include the one for arcane powers.

We can add the resource to the list by assigning it the "Helper.Creation" tag. We can then control its position in the list by assigning it an appropriate "explicit" tag. We'll put it at the end, after "Skills", so we'll assign it the tag "explicit.6".

The only problem now is that the resource shows up for characters with no arcane background. What we want is for the resource to only show up when an arcane background is possessed. There are a number of ways we can solve this, but the best is to recognize that the resource serves no purpose unless we an arcane background is selected. As such, we can use the same approach as with the "Advances" resource, except that pre-condition changes. We can assign a ContainerReq test to the "resPowers" resource and make the thing dependent upon the hero possessing any tag from the "Arcane" group, which will assigned if any arcane background is chosen. This results in the revised "resPowers" thing below.

<thing
  id="resPowers"
  name="Arcane Powers"
  compset="Resource">
  <fieldval field="resObject" value="Arcane Power"/>
  <tag group="Helper" tag="Bootstrap"/>
  <tag group="Helper" tag="Creation"/>
  <tag group="explicit" tag="6"/>

  <containerreq phase="Initialize" priority="2000">
    Arcane.?
    </containerreq>

  </thing>