Final Cleanup Continued (Savage) - Revision history

Rob: /* Next */

2009-02-12T12:30:37Z

← Older revision		Revision as of 12:30, 12 February 2009
Line 498:		Line 498:

	After a quick reload, our skill point calculations should be operating smoothly after advancement changes modify attributes.		After a quick reload, our skill point calculations should be operating smoothly after advancement changes modify attributes.

	~~===Next===~~

Rob: /* Buying Off Hindrances */

2009-02-11T21:11:50Z

Buying Off Hindrances

@@ Line 187: / Line 187: @@
 ===Buying Off Hindrances===
-All the various advancements appear to be working, but, there's one situation
+All the various advancements appear to be working, but, there's one situation we haven't dealt with yet. Although not in the official list of advancement options, the rules indicate that it is possible to spend an advance to "buy off" a hindrance. If a GM allows this option, we need to provide a way to handle it within the data files.
-*use an advancement to buy off a hindrance
+Unless the user adds a new advance, our validation logic will continue to report an error. So the easiest way to solve this is to add a new advance for the purpose of buying off a hindrance. This advance won't have any special behaviors, as it's really just a placeholder to consume a slot. However, we should allow the user to annotate the hindrance that was actually bought off and show it within the name of the advance.
 ===Injuries For NPCs===

Rob: /* Custom Domains for Hindrances */

2009-02-11T20:56:06Z

Custom Domains for Hindrances

← Older revision		Revision as of 20:56, 11 February 2009
Line 120:		Line 120:

	===Custom Domains for Hindrances===		===Custom Domains for Hindrances===

			There are quite a few hindrances that utilize domains, and the domain for each is quite a bit different from the others. We currently just use the label "Domain" for each hindrance, but it would be great to customize the term for each one. We already used the "DomainTerm" tag on the "Skills" component, but we can also use the tag on individual things.

			To support a varying domain term for each hindrance, all we need to do is modify the template that displays the hindrances and add the appropriate tag to each hindrance. Modifying the template simply requires us to change the "lbldomain" portal to use a Label script instead of a fixed string. If a "DomainTerm" tag is found, we use the term, else we default to the original "Domain:" label. The revised portal is shown below.

			<pre>
			<portal
			id="lbldomain"
			style="lblSecond">
			<label>
			<labeltext><![CDATA[
			if (tagis[DomainTerm.?] <> 0) then
			@text = tagnames[DomainTerm.?] & ":"
			else
			@text = "Domain:"
			endif
			]]></labeltext>
			</label>
			</portal>
			</pre>

			Since the "DomainTerm" tag group is dynamic, we don't need to define all the tags within the group. We can instead define them whenever we need them. So we can go through all the various hindrances and add a custom tag to each, which will then be used throughout HL. For example, the "Phobia" hindrance could be assigned a "Fear" domain term via the tag below.

			<pre>
			<tag group="DomainTerm" tag="Fear"/>
			</pre>

	===Edges Need Domain Support===		===Edges Need Domain Support===

Rob at 20:42, 11 February 2009

2009-02-11T20:42:01Z

← Older revision		Revision as of 20:42, 11 February 2009
Line 118:		Line 118:

	Since we've gone through and analyzed all these dependencies, we'll do one additional thing. Each of the various scripts we identified should be named. Then we can specify appropriate timing dependencies between these scripts. Now we can let the compiler safety check our timing dependencies for us all the time. If we need to adjust the timing of one of these scripts in the future, we can rely on the compiler to let us know if we messed something up.		Since we've gone through and analyzed all these dependencies, we'll do one additional thing. Each of the various scripts we identified should be named. Then we can specify appropriate timing dependencies between these scripts. Now we can let the compiler safety check our timing dependencies for us all the time. If we need to adjust the timing of one of these scripts in the future, we can rely on the compiler to let us know if we messed something up.

			===Custom Domains for Hindrances===

	===Edges Need Domain Support===		===Edges Need Domain Support===

Rob: /* Buying Off Hindrances */

2009-02-11T20:40:53Z

Buying Off Hindrances

← Older revision		Revision as of 20:40, 11 February 2009
Line 158:		Line 158:

	===Buying Off Hindrances===		===Buying Off Hindrances===

			All the various advancements appear to be working, but, there's one situation

	*use an advancement to buy off a hindrance		*use an advancement to buy off a hindrance

Rob: /* Overview */

2009-02-11T13:16:03Z

Overview

← Older revision		Revision as of 13:16, 11 February 2009
Line 2:		Line 2:

	===Overview===		===Overview===

			The testing and cleanup process continues....

	===Identify Hindrance Severity in Sheet Output===		===Identify Hindrance Severity in Sheet Output===

Rob: /* Next */

2009-02-11T13:13:12Z

@@ Line 381: / Line 381: @@
    nexteach
 </pre>
 ===Next===

Rob: /* Next */

2009-02-11T12:07:12Z

@@ Line 362: / Line 362: @@
    </template>
 </pre>
 ===Next===

Rob: /* Injuries For NPCs */

2009-02-11T11:51:17Z

Injuries For NPCs

@@ Line 207: / Line 207: @@
      </table_dynamic>
    </portal>
 </pre>

Rob: /* Injuries As Advancements */

2009-02-11T11:47:39Z

Injuries As Advancements

@@ Line 159: / Line 159: @@
 *use an advancement to buy off a hindrance
-===Injuries As Advancements===
+===Injuries For NPCs===
-When we first added support for injuries, treating them as advancements made perfect sense. Unfortunately, with the support of NPCs, that's not the case anymore. We need to allow injuries to be assigned to NPCs, but NPCs don't have access to the advancements mechanism. There's also the consideration that injuries require more effort to "heal" when handled as advancements.
+When we first added support for injuries, treating them as advancements made perfect sense. Unfortunately, with the support of NPCs, treating them as advancements doesn't work very well unless the character happens to be a PC. The reason for this is that advancements are not applicable to NPCs, so we hide the entire tab.
-We're going to change how injuries are dealt within by our data files. They will be treated as an independent mechanism internally. For the user, we'll manage them on the "Personal" tab. We can place them beneath the Gallery on the right, and we'll anchor them to the bottom, immediately above the permanent adjustments.
+We need to allow injuries to be assigned to NPCs via some mechanism. Since advancements are intended for the application of permanent injuries, it would also be helpful to provide a convenient way to apply temporary injuries to PCs.
 ===Hiding Equipment===