Miscellaneous Cleanup (Savage): Difference between revisions
Line 66: | Line 66: | ||
===Simplify Encumbrance 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. | |||
<pre> | |||
~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 | |||
</pre> | |||
===Fix Encumbrance of Stacked Items=== |
Revision as of 08:54, 22 January 2009
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