Revise Summary Panels (Savage)

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

Overview

Everything is finally coming together nicely with our data files. At this point, it's probably a good idea to switch our focus over to the various summary panels that are displayed.

Assess the Contents

When is comes to the summary panels, the first thing we need to do is assess what information needs to be shown within the panels. This is most easily accomplished by simply making a list of the various pieces of information that should be included. A useful approach is to look at each of the main tabs within the interface and identify items that the user will likely want to refer to while looking at other tabs. After giving it some thought, the following list probably makes the most sense.

• Attributes
• Derived Attributes
• Status Info (e.g. Encumbrance)
• Skills
• Edges
• Hindrances
• Racial Abilities
• Armor
• Hand Weapons
• Ranged Weapons
• Special Weapons

Organize the Information

The next step is to break the above list into logic groupings that will generally fit into a single summary panel. An important consideration during this step is that you need to create your data files with a small 800x600 display in mind. Even if you are using a huge display and keep the HL application at maximum size, your data files will also be used by some people on a small 800x600 display. So it's important that you keep each summary panel reasonably compact, if at all possible.

After you break things up, you can then decide on the appropriate sequence in which to show each set of information. For example, should hand weapons go above ranged weapons, or vice versa? When looking at the list of contents we identified above, there are a variety of suitable organizations, and the final determination really comes down to what you think works best. For our purposes, we'll settle on three separate summary panels that are organized as shown below.

• Basics
  • Attributes
  • Derived Attributes
  • Status Info (e.g. Encumbrance)
• Abilities
  • Edges
  • Hindrances
  • Racial Abilities
  • Skills
• Armory
  • Armor
  • Hand Weapons
  • Ranged Weapons
  • Special Weapons

The Basics Panel

We can now set about configuring the first summary panel that contains all the basics of the character. We'll use the existing "Basics" panel, which can be found in the file "summ_basics.dat". There is already a table of attributes and another table of derived traits, so we don't need to add those. However, we do need a table in which to display the encumbrance and other status information.

Adding the new table starts with cloning one of the existing two tables. Once we clone it, we can then modify it for showing status information. We can look at the "baStatus" table used on the Basics tab for guidance regarding how to setup the new table. Since the format of the output will be different from standard traits, we'll also need to create a new template, which we'll name appropriately. The new table portal should look similar to the one below.

<portal
  id="smStatus"
  style="tblInvisSm">
  <table_fixed
    component="Resource"
    showtemplate="smResource"
    showsortset="explicit"
    scrollable="no">
    <list>Helper.Status</list>
    </table_fixed>
  </portal>

With the table in place, we now need to define a suitable template. We can clone the "smTrait" template and adapt it for our needs. We need to change the component set reference and the field which shows the value. We also need to give ourselves significantly more space for the value field, which can be done within the Position script. This yields a new template that looks like the following.

<template
  id="smResource"
  name="Summary Resource Pick"
  compset="Resource">

  <portal
    id="value"
    style="lblSummary">
    <label
      field="resShort">
      </label>
    </portal>

  <portal
    id="name"
    style="lblSummary">
    <label
      field="name">
      </label>
    </portal>

  <position><![CDATA[
    ~set up our height based on our tallest portal
    height = portal[name].height

    ~if this is a "sizing" calculation, we're done
    if (issizing <> 0) then
      done
      endif

    ~position the value on the left in a limited span and the name on the right
    portal[value].width = 55
    perform portal[name].alignrel[ltor,value,5]
    ]]></position>
  </template>

The final step is to add the new table portal into the layout. We'll place it beneath the existing two tables, so all we need to do is add the portal reference to the layout and then add an appropriate placement statement to the Position script. The resulting layout should look like the following.

<layout
  id="smBasics">
  <portalref portal="smAttrib"/>
  <portalref portal="smDerived"/>
  <portalref portal="smStatus"/>

  <position><![CDATA[
    ~position and size the tables to span the full layout
    perform portal[smAttrib].autoplace
    perform portal[smDerived].autoplace[20]
    perform portal[smStatus].autoplace[20]
    ]]></position>

  </layout>

We can now reload everything and see the results. The first thing we see is that the list of attributes includes our hidden attribute for super powers. We also see that the list of derived traits include various traits that should be hidden. So we need to add a suitable List tag expression to the two tables that limits the items that are shown. We can refer to the tables used on the Basics tab for how to handle this, at which point we'll determine that the two List tag expressions should be the ones shown below.

<list>!Hide.Attribute</list>

<list>!Hide.Trait</list>

Looking more closely at the lists of attributes and derived traits, we'll also realize that the information being shown is incorrect. The "trtFinal" field is being shown instead of the proper "trtDisplay" field. So we can fix this within the "value" portal of the "smTrait" template.

We should also provide more space for the display of the various trait values. If a trait is something especially wide like "d12+2", it will be cut off. So we can modify the Position script to double the width of the "value" portal to 40.

At this point, it looks like our summary panel is ready to go.

The Abilities Panel

The next summary panel is where we'll show all the various abilities for the character. As we did above, we'll adapt the existing "Abilities" panel, which can be found in the file "summ_abilities.dat".

The current panel contains two tables, one for skills and one for abilities. We want to re-use the skills and we'll adapt the abilities table for showing racial abilities. So that leaves us two tables short, as we need additional tables for showing edges and hindrances. This can be readily handled by copying the existing "smAbility" portal twice and revising each into the tables we need. Since edges and hindrances both derive from the "Ability" component, we can also share the same template across all three tables. This results in two new tables like the ones below.

<portal
  id="smEdge"
  style="tblInvisSm">
  <table_fixed
    component="Edge"
    showtemplate="smAbility"
    scrollable="no">
    </table_fixed>
  </portal>

<portal
  id="smHinder"
  style="tblInvisSm">
  <table_fixed
    component="Hindrance"
    showtemplate="smAbility"
    scrollable="no">
    </table_fixed>
  </portal>

We must now add the two table portals into the layout. We'll position the edges at the top, with the hindrances beneath it. Racial abilities and skills be follow. We'll also shrink the spacing between each grouping for this summary panel. This yields a revised layout that looks like the one below.

<layout
  id="smAbility">
  <portalref portal="smEdge"/>
  <portalref portal="smHinder"/>
  <portalref portal="smAbility"/>
  <portalref portal="smSkill"/>

  <position><![CDATA[
    ~position and size the tables to span the full layout
    perform portal[smEdge].autoplace
    perform portal[smHinder].autoplace[10]
    perform portal[smAbility].autoplace[10]
    perform portal[smSkill].autoplace[10]
    ]]></position>

  </layout>

When we reload everything and take a look at the results, we'll notice that the edges and hindrances are also listed in the table of abilities. Looking more closely at everything, we'll discover that the racial abilities use the "Ability" component, but edges and hindrances also derive from that component. Since the table shows all picks that derive from the "Ability" component, it makes sense that they would be included.

At this point, we have a couple of options regarding how to proceed. The expedient solution is to add a List tag expression to the table portal that omits all edges and hindrances. However, that not necessarily the best solution. Let's consider how racial abilities compare with edges and hindrances. If racial abilities were a more generalized grouping of edges and hindrances, then the current structure would make sense. Unfortunately, racial abilities are actually a completely separate concept from edges and hindrances. So what we really need is a separate component and component set for racial abilities. Then we can have all three different object types share the general mechanisms provided by the "Ability" component.

Open the file "traits.str" and locate the "Hindrance" component. Our new racial abilities component will work very similarly to hindrances, so we'll start by copying the "Hindrance" component. We can now assign a new id like "RaceAbil", and we'll need both the identity tag group and a "SpecialTab" tag. We also need to copy the racial ability to the actor. The other two scripts are specific to hindrances, so we can delete them. This leaves us with a new component the looks like the following.

<component
  id="RaceAbil"
  name="Racial Ability"
  autocompset="no">

  <identity group="RaceAbil"/>

  <tag group="SpecialTab" tag="RaceAbil"/>

  <eval index="1" phase="Setup" priority="5000"><![CDATA[
    perform forward[RaceAbil.?]
    ]]></eval>

  </component>

Now that the new component is in place, we can define a suitable component set. Racial abilities rely on the common mechanisms of the "Ability" component, the new "RaceAbil" component, and the mechanisms provided by the "SpecialTab" component. This yields a new component set like the one below.

<compset
  id="RaceAbil">
  <compref component="RaceAbil"/>
  <compref component="Ability"/>
  <compref component="SpecialTab"/>
  </compset>

There is one thing that we're forgetting, though. We've reference a new tag within the "SpecialTab" group, but that tag hasn't been defined yet. Open the file "tags.1st" and locate the "SpecialTab" tag group. Add a new tag for racial abilities, which should look like the example below.

<value id="RaceAbil" name="Racial Ability" order="60"/>

Since we've defined a new component set for racial abilities, we now need to go through all our racial ability things and change them appropriately. All of them are defined in the file "thing_races.dat", so open that file. We can do a global search and replace operation on the file to change all things with the component set "Ability" to "RaceAbil". Once that's done, everything should compile again.

The final step is to return to the table within the summary panel. For the "smAbility" table portal we created earlier, change the component to "RaceAbil". This will limit the table to only show racial abilities.

Reload the files and assess how everything is behaving. Unless there was a mistake somewhere, it should all be working as we intended now.