Revise Summary Panels (Savage): Difference between revisions
No edit summary |
|||
(One intermediate revision by the same user not shown) | |||
Line 183: | Line 183: | ||
</layout> | </layout> | ||
</pre> | </pre> | ||
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. | |||
<pre> | |||
<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> | |||
</pre> | |||
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. | |||
<pre> | |||
<compset | |||
id="RaceAbil"> | |||
<compref component="RaceAbil"/> | |||
<compref component="Ability"/> | |||
<compref component="SpecialTab"/> | |||
</compset> | |||
</pre> | |||
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. | |||
<pre> | |||
<value id="RaceAbil" name="Racial Ability" order="60"/> | |||
</pre> | |||
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. | |||
===The Amory Panel=== | |||
Our third and final summary panel is for showing weapons and armor possessed by the character. Fortunately, we don't need to do much here. All of the handling for armor, melee weapons, and ranged weapons is already in place and working nicely. So all we need to do is add a table of special weapons at the bottom. | |||
As we've done previously, we can copy an existing table portal and adapt it easily. This yields the new portal below. | |||
<pre> | |||
<portal | |||
id="smSpecial" | |||
style="tblInvisSm"> | |||
<table_fixed | |||
component="WeapSpec" | |||
showtemplate="smWeapon" | |||
scrollable="no"> | |||
</table_fixed> | |||
</portal> | |||
</pre> | |||
All that's left is to add the table portal to the layout. We'll just append it at the end, resulting in the revised layout shown below. | |||
<pre> | |||
<layout | |||
id="smArmory"> | |||
<portalref portal="smDefense"/> | |||
<portalref portal="smRange"/> | |||
<portalref portal="smMelee"/> | |||
<portalref portal="smSpecial"/> | |||
<position><![CDATA[ | |||
~position and size the tables to span the full layout | |||
perform portal[smDefense].autoplace | |||
perform portal[smRange].autoplace[20] | |||
perform portal[smMelee].autoplace[20] | |||
perform portal[smSpecial].autoplace[20] | |||
]]></position> | |||
</layout> | |||
</pre> | |||
That's all there is to it. We've now got our final summary panel working as it should. |
Latest revision as of 23:26, 14 January 2009
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.
The Amory Panel
Our third and final summary panel is for showing weapons and armor possessed by the character. Fortunately, we don't need to do much here. All of the handling for armor, melee weapons, and ranged weapons is already in place and working nicely. So all we need to do is add a table of special weapons at the bottom.
As we've done previously, we can copy an existing table portal and adapt it easily. This yields the new portal below.
<portal id="smSpecial" style="tblInvisSm"> <table_fixed component="WeapSpec" showtemplate="smWeapon" scrollable="no"> </table_fixed> </portal>
All that's left is to add the table portal to the layout. We'll just append it at the end, resulting in the revised layout shown below.
<layout id="smArmory"> <portalref portal="smDefense"/> <portalref portal="smRange"/> <portalref portal="smMelee"/> <portalref portal="smSpecial"/> <position><![CDATA[ ~position and size the tables to span the full layout perform portal[smDefense].autoplace perform portal[smRange].autoplace[20] perform portal[smMelee].autoplace[20] perform portal[smSpecial].autoplace[20] ]]></position> </layout>
That's all there is to it. We've now got our final summary panel working as it should.