Creature Specification (Savage) - Revision history

Rob at 04:22, 11 February 2009

2009-02-11T04:22:39Z

Rob: /* User Manipulation of Derived Traits */

2009-02-11T03:43:48Z

User Manipulation of Derived Traits

← Older revision		Revision as of 03:43, 11 February 2009
Line 418:		Line 418:
	style="incrSimple">		style="incrSimple">
	<incrementer		<incrementer
	field="~~trtUser~~">		field="trtUserCre">
	</incrementer>		</incrementer>
	<mouseinfo><![CDATA[		<mouseinfo><![CDATA[
Line 441:		Line 441:
	</pre>		</pre>

	We're now ready to give our changes a try. When we create a new creature, our incrementers show up where they should~~, except~~ that ~~there is no value shown~~. ~~The problem is that the "trtUser"~~ field ~~relies~~ on the ~~"trtIncr" field to tell it what~~ to ~~display for its contents~~. We ~~can setup that field appropriately within the Eval script that generates the~~ "~~trtDisplay~~" ~~field for the~~ "~~Derived~~" ~~component. Since we want to show the same contents as the~~ "~~trtDisplay~~" ~~field~~, we'll ~~set it~~ to the ~~same thing by adding the lines of code below at the end of the script~~.		We're now ready to give our changes a try. When we create a new creature, our incrementers show up where they should and have appropriate initial values displayed. Let's put our changes to the test with an actual creature that applies adjustments.

			We'll modify our sample creature for this purpose. We can assign a few field values on the creature to apply our adjustments. We'll assign a "Pace" of "5" and a "Parry" adjustment of "1". To do this, we'll add the following XML elements to the creature's definition.

	<pre>		<pre>
	~~~if case we have a creature, we need to show the final~~ value ~~appropriately~~		<fieldval field="crePace" value="5"/>
	field~~[trtIncr].text~~ = ~~field[trtDisplay].text~~		<fieldval field="creParry" value="1"/>
	</pre>		</pre>

	~~Our incrementers are now showing us values, but they are all two points higher than they should be. This is because~~ the ~~"trtUser" field always starts out with~~ a ~~value of "2", which is being added to the final value~~. ~~We need to force~~ the ~~field value to always start as zero for creatures. This is an easy fix. The~~ default ~~value~~ for the ~~"trtUser" field is given as "2" and we can change it to "0"~~. ~~Since~~ the ~~minimum value will automatically force a value of "0" to "2"~~, ~~everything should continue to work perfectly for normal characters after this change.~~		Reload the data files and create a creature. Take a look at the default values shown for the derived traits. From the chooser, select our test creature. The "Pace" value should immediately change to "5", and the "Parry" value should change from "2" to "3". Our derived traits are working smoothly now.

	~~Let's put~~ our ~~changes to the~~ test ~~with an actual~~ creature ~~that applies adjustments~~. ~~We'll modify our sample creature for this purpose. We can assign a few field values on the creature to apply our adjustments. We'll assign a~~ "Pace" of "5" and a "Parry" ~~adjustment of~~ "3". ~~To do this, we'll add the following XML elements to the creature's definition~~.

	~~<pre>~~		Let's attempt to adjust the derived traits. Decreasing Parry stops us at "2", since we set that up as our absolute floor. However, we can increase Parry a total of three notches. Our Toughness defaults to "4" and has the same behaviors. Our Pace is limited to a range of "2" to "8". Everything checks out.
	~~<fieldval field=~~"~~crePace~~" ~~value=~~"5"/>
	~~<fieldval field=~~"~~creParry~~" ~~value=~~"3"/>
	~~</pre>~~

	~~Reload~~ the ~~data files~~ and ~~create a creature. Take a look at~~ the ~~default values shown~~ for ~~the derived traits~~. ~~From~~ the ~~chooser, select our test creature. The "Pace"~~ value ~~should immediately change to~~ "5", and ~~the~~ "~~Parry~~" value ~~should change from "2"~~ to "5". ~~Our derived~~ traits are ~~working smoothly now~~.		We should also verify our delta is working properly. Click within the incrementer showing the Parry and it should show the current value for editing. Enter the new value "4" and everything appears to work fine. Now try entering a value of "9". The new value is automatically bounded to the maximum we established of "6" (i.e. our initial value of 3 plus and additional 3). Derived traits are fully operational.

	===Assigning Gear===		===Assigning Gear===

Rob: /* Assigning Derived Traits */

2009-02-11T03:33:36Z

Assigning Derived Traits

← Older revision		Revision as of 03:33, 11 February 2009
Line 231:		Line 231:

	The problem is that derived traits are always calculated in the end. We need to handle them in a way that will smoothly integrate with their calculated nature. Unfortunately, there is no clean way of doing that by having the derived trait value be specified explicitly for a creature. The only way to reasonably accomplish it is to utilize an adjustment that gets incorporated into the calculated final value.		The problem is that derived traits are always calculated in the end. We need to handle them in a way that will smoothly integrate with their calculated nature. Unfortunately, there is no clean way of doing that by having the derived trait value be specified explicitly for a creature. The only way to reasonably accomplish it is to utilize an adjustment that gets incorporated into the calculated final value.

			====Specifying the Derived Traits Values====

	This means that we need to define four new fields for the "Creature" component. We need one field apiece for the four derived traits, where each field specifies an adjustment from the standard calculated value. If a field is not specified, then no extra adjustment will be applied for that trait.		This means that we need to define four new fields for the "Creature" component. We need one field apiece for the four derived traits, where each field specifies an adjustment from the standard calculated value. If a field is not specified, then no extra adjustment will be applied for that trait.
Line 273:		Line 275:
	</field>		</field>
	</pre>		</pre>

			====Supporting User Adjustment====

	Integrating these new fields into the calculation is relatively simple. All we need is an Eval script that applies the adjustment values to the traits via the "traitadjust" script macro. If we do that, then the adjustment included in the standard calculation of the derived trait, without any special handling.		Integrating these new fields into the calculation is relatively simple. All we need is an Eval script that applies the adjustment values to the traits via the "traitadjust" script macro. If we do that, then the adjustment included in the standard calculation of the derived trait, without any special handling.
Line 286:		Line 290:
	Unfortunately, there's a critical hole in this approach. It's a subtle timing issue that comes into play with the bounding of the user value. Since the "trtUser" field is also used for normal (i.e. non-derived) traits, the bounding logic needs to be changed for our purposes. That can be handled, but the bounding must be performed '''''before''''' the initial calculation of "trtFinal" within the "Traits" component. For our purposes, we need to access the net values calculated for our derived traits in order to do proper bounding. For example, the Toughness trait must be calculated so that we know what the bounding range can be. This means we'll need to do the bounding '''''after''''' "trtFinal" is calculated. We have a chicken-and-egg problem.		Unfortunately, there's a critical hole in this approach. It's a subtle timing issue that comes into play with the bounding of the user value. Since the "trtUser" field is also used for normal (i.e. non-derived) traits, the bounding logic needs to be changed for our purposes. That can be handled, but the bounding must be performed '''''before''''' the initial calculation of "trtFinal" within the "Traits" component. For our purposes, we need to access the net values calculated for our derived traits in order to do proper bounding. For example, the Toughness trait must be calculated so that we know what the bounding range can be. This means we'll need to do the bounding '''''after''''' "trtFinal" is calculated. We have a chicken-and-egg problem.

	The timing of the Bound script for the "trtUser" field is fixed. If we could schedule it at one time for normal traits and a different time for derived traits, we could make this work. Sadly, it must always be invoked at the same time for all traits. This means we can't use the "trtUser" field for our purposes. The good news is that we can simply create a '''''different''''' field for our needs and proceed with our original plan.		The timing of the Bound script for the "trtUser" field is fixed. If we could schedule it at one time for normal traits and a different time for derived traits, we could make this work. Sadly, it must always be invoked at the same time for all traits. This means we can't use the "trtUser" field for our purposes.

			====Alternate Field for User Adjustment====

			The good news is that we can simply create a '''''different''''' field for our needs and proceed with our original plan. Our new field will behave very similarly to "trtUser", so we start by cloning it. The field is only needed for derived traits, so we'll add it to the "Derived" component.

	~~Our new field will behave very similarly to "trtUser", so we start by cloning it. The field is only needed for derived traits, so we'll add it to the "Derived" component.~~ We can re-use the "trtMinimum" and "trtMaximum" fields for bounding, and we won't need to do any special handling of the bounds. We want to display the final value within the incrementer, which we can pull from the "trtDisplay" field. Lastly, we want to allow the user to edit that value directly, so we'll include delta handling for our field. Our resulting field should look like the following.		We can re-use the "trtMinimum" and "trtMaximum" fields for bounding, and we won't need to do any special handling of the bounds. We want to display the final value within the incrementer, which we can pull from the "trtDisplay" field. Lastly, we want to allow the user to edit that value directly, so we'll include delta handling for our field. Our resulting field should look like the following.

	<pre>		<pre>
Line 329:		Line 337:
	endif		endif
	</pre>		</pre>

			====Bounding the Derived Traits====

	At this point, we've got a user-modifiable value that will be setup properly and factored into the final adjustment calculation. The final piece we're missing is the bounding. We need to setup appropriate value for "trtMinimum" and "trtMaximum" so that the user can adjust the starting value within reason. In order to bound the value, we need to know the original starting value, since we'll establish our limits relative to that value. We also need to know what the absolute minimum value is for a given trait (i.e. its "floor" value). This value differs for each derived trait, since Charisma can go negative, Pace can't drop below one, and the others can't drop below two.		At this point, we've got a user-modifiable value that will be setup properly and factored into the final adjustment calculation. The final piece we're missing is the bounding. We need to setup appropriate value for "trtMinimum" and "trtMaximum" so that the user can adjust the starting value within reason. In order to bound the value, we need to know the original starting value, since we'll establish our limits relative to that value. We also need to know what the absolute minimum value is for a given trait (i.e. its "floor" value). This value differs for each derived trait, since Charisma can go negative, Pace can't drop below one, and the others can't drop below two.
Line 384:		Line 394:
	]]></eval>		]]></eval>
	</pre>		</pre>

			====Setup the Delta====

	All of our behaviors are in place, except for one. Derived trait values are simple numbers and not die types. Consequently, we want to let the user edit the value directly within the incrementer where they are shown. However, we want the user to edit a value that makes sense to him (i.e. the final result) instead of the adjustment. To do this, we need to set the "delta" for the "trtUserCre" field to the difference between the actual user value and the value the user will see. Once that's done, HL will handle the rest for us. The new Eval script should look like the following.		All of our behaviors are in place, except for one. Derived trait values are simple numbers and not die types. Consequently, we want to let the user edit the value directly within the incrementer where they are shown. However, we want the user to edit a value that makes sense to him (i.e. the final result) instead of the adjustment. To do this, we need to set the "delta" for the "trtUserCre" field to the difference between the actual user value and the value the user will see. Once that's done, HL will handle the rest for us. The new Eval script should look like the following.

Rob: /* Assigning Derived Traits */

2009-02-11T03:27:54Z

Assigning Derived Traits

@@ Line 348: / Line 348: @@
 </pre>
-There is another detail we need to address. The minimum and maximum values for the "trtUser" field are defined within the "Trait" component. The bounds specified are intended for use with attributes and skills. Since we're tracking an adjustment value for derived traits, we need to support a range that is very different. We want a value that can range from negative to positive, and a suitable range is probably rather wide. However, we generally don't want to allow the user to specify a negative trait value (except for Charisma), so we need to ensure that our minimum never goes low enough to yield a net negative result.
+<pre>
-This uncovers a nasty problem, though. The issue is that the bounding of the user value must occur at the same time for all picks
+<pre>
-To accomplish this, we need to define our own Eval script within the "Derived" component that overrides the default bounds assigned to all traits. If our new script occurs after the one that sets the default values, our new values will be used instead. Our new Eval script should look like the one shown below.
+  ~now setup a maximum at 3 above the starting value
 <pre>
-<eval index="3" phase="Final" priority="1000"><![CDATA[
+<eval index="4" phase="Render" priority="5000"><![CDATA[
-   ~we only employ the "trtUser" field for derived traits with creatures, where we
+   if (hero.tagis[Hero.Creature] <> 0) then
-  ~want the user value to be a custom adjustment to the default calculated values,
+    field[trtUserCre].delta = field[trtBonus].value + field[trtInPlay].value + herofield[acNetPenal].value
-  ~so setup an appropriately wide range
+    endif
    ]]></eval>
 </pre>
 ===User Manipulation of Derived Traits===

Rob: /* Assigning Derived Traits */

2009-02-11T03:15:41Z

Assigning Derived Traits

← Older revision		Revision as of 03:15, 11 February 2009
Line 286:		Line 286:
	Unfortunately, there's a critical hole in this approach. It's a subtle timing issue that comes into play with the bounding of the user value. Since the "trtUser" field is also used for normal (i.e. non-derived) traits, the bounding logic needs to be changed for our purposes. That can be handled, but the bounding must be performed '''''before''''' the initial calculation of "trtFinal" within the "Traits" component. For our purposes, we need to access the net values calculated for our derived traits in order to do proper bounding. For example, the Toughness trait must be calculated so that we know what the bounding range can be. This means we'll need to do the bounding '''''after''''' "trtFinal" is calculated. We have a chicken-and-egg problem.		Unfortunately, there's a critical hole in this approach. It's a subtle timing issue that comes into play with the bounding of the user value. Since the "trtUser" field is also used for normal (i.e. non-derived) traits, the bounding logic needs to be changed for our purposes. That can be handled, but the bounding must be performed '''''before''''' the initial calculation of "trtFinal" within the "Traits" component. For our purposes, we need to access the net values calculated for our derived traits in order to do proper bounding. For example, the Toughness trait must be calculated so that we know what the bounding range can be. This means we'll need to do the bounding '''''after''''' "trtFinal" is calculated. We have a chicken-and-egg problem.

	The timing of the Bound script for the "trtUser" field is fixed. If we could schedule it at one time for normal traits and a different time for derived traits, we~~'d be fine~~. Sadly, it must always be invoked at the same time for all traits. This means we can't use the "trtUser" field for our purposes. The good news is that we can simply create a '''''different''''' field for our needs and proceed with our original plan.		The timing of the Bound script for the "trtUser" field is fixed. If we could schedule it at one time for normal traits and a different time for derived traits, we could make this work. Sadly, it must always be invoked at the same time for all traits. This means we can't use the "trtUser" field for our purposes. The good news is that we can simply create a '''''different''''' field for our needs and proceed with our original plan.

	Our new field will behave very similarly to "trtUser", so we start by cloning it. The field is only needed for derived traits, so we'll add it to the "Derived" component. We can re-use the "trtMinimum" and "trtMaximum" fields for bounding, and we ~~don~~'t need any delta handling for our ~~value~~.		Our new field will behave very similarly to "trtUser", so we start by cloning it. The field is only needed for derived traits, so we'll add it to the "Derived" component. We can re-use the "trtMinimum" and "trtMaximum" fields for bounding, and we won't need to do any special handling of the bounds. We want to display the final value within the incrementer, which we can pull from the "trtDisplay" field. Lastly, we want to allow the user to edit that value directly, so we'll include delta handling for our field. Our resulting field should look like the following.

	<pre>		<pre>
Line 296:		Line 296:
	type="user"		type="user"
	defvalue="0"		defvalue="0"
			usedelta="yes"
	maxfinal="50">		maxfinal="50">
	<!-- Bound the user value to the limits established for the trait -->		<!-- Bound the user value to the limits established for the trait -->
	<bound phase="Traits" priority="~~6500~~" name="Bound trtUserCre">		<bound phase="Traits" priority="5500" name="Bound trtUserCre">
	<before name="Derived trtFinal"/><![CDATA[		<before name="Derived trtFinal"/><![CDATA[
	@minimum = field[trtMinimum].value		@minimum = field[trtMinimum].value
Line 310:		Line 311:
	</pre>		</pre>

			With the field in place, we need to set it up properly. To accomplish this, we'll revise the Creation script for the "Creature" component. In addition to setting up the attributes, we must also assign the initial user values for the derived traits. This consists of adding the following lines of code to the script.
	~~The first thing~~ we need to ~~do is~~ revise the Creation script for the "Creature" component. In addition to setting up the attributes, we must also assign the ~~adjustment~~ values for derived traits. This consists of adding the following lines of code to the script.

	<pre>		<pre>
	~assign the appropriate adjustment values to derived traits		~assign the appropriate adjustment values to derived traits
	~~#traituser~~[trPace] = field[crePace].value		hero.child[trPace].field[trtUserCre].value = field[crePace].value
	~~#traituser~~[trParry] = field[creParry].value		hero.child[trParry].field[trtUserCre].value = field[creParry].value
	~~#traituser~~[trTough] = field[creTough].value		hero.child[trTough].field[trtUserCre].value = field[creTough].value
	~~#traituser~~[trCharisma] = field[creCharis].value		hero.child[trCharisma].field[trtUserCre].value = field[creCharis].value
	</pre>		</pre>

	The next step is to include the "~~trtUser~~" field value in the calculation of the final value. For this, we need to modify the Eval script that calculates "trtFinal" within the "Derived" component. After the value is calculated normally, we can add the lines of code below to factor in the "~~trtUser~~" field for creatures.		The next step is to include the "trtUserCre" field value in the calculation of the final value. For this, we need to modify the Eval script that calculates "trtFinal" within the "Derived" component. After the value is calculated normally, we can add the lines of code below to factor in the "trtUserCre" field for creatures.

	<pre>		<pre>
	~if this is a creature, we need to add the user value as a custom adjustment		~if this is a creature, we need to add the user value as a custom adjustment
	if (hero.tagis[Hero.Creature] <> 0) then		if (hero.tagis[Hero.Creature] <> 0) then
	field[trtFinal].value += field[~~trtUser~~].value		field[trtFinal].value += field[trtUserCre].value
	endif		endif
	</pre>		</pre>

			At this point, we've got a user-modifiable value that will be setup properly and factored into the final adjustment calculation. The final piece we're missing is the bounding. We need to setup appropriate value for "trtMinimum" and "trtMaximum" so that the user can adjust the starting value within reason. In order to bound the value, we need to know the original starting value, since we'll establish our limits relative to that value. We also need to know what the absolute minimum value is for a given trait (i.e. its "floor" value). This value differs for each derived trait, since Charisma can go negative, Pace can't drop below one, and the others can't drop below two.

			We need to introduce two new fields on the "Derived" component to track these values. Both of these values will be setup appropriately by the creature, so they are simple derived values. The two fields should look like below.

			<pre>
			<field
			id="trtCreatur"
			name="Creature Start"
			type="derived">
			</field>

			<field
			id="trtFloor"
			name="Creature Floor"
			type="derived">
			</field>
			</pre>


	There is another detail we need to address. The minimum and maximum values for the "trtUser" field are defined within the "Trait" component. The bounds specified are intended for use with attributes and skills. Since we're tracking an adjustment value for derived traits, we need to support a range that is very different. We want a value that can range from negative to positive, and a suitable range is probably rather wide. However, we generally don't want to allow the user to specify a negative trait value (except for Charisma), so we need to ensure that our minimum never goes low enough to yield a net negative result.		There is another detail we need to address. The minimum and maximum values for the "trtUser" field are defined within the "Trait" component. The bounds specified are intended for use with attributes and skills. Since we're tracking an adjustment value for derived traits, we need to support a range that is very different. We want a value that can range from negative to positive, and a suitable range is probably rather wide. However, we generally don't want to allow the user to specify a negative trait value (except for Charisma), so we need to ensure that our minimum never goes low enough to yield a net negative result.

Rob: /* Assigning Derived Traits */

2009-02-11T00:22:33Z

Assigning Derived Traits

@@ Line 246: / Line 246: @@
 </pre>
-We'll end up with four fields, where the Pace indicates the actual starting value to use and the others indicate an adjustment. Our new fields should looks like the following.
+With the change in place, we can shift back to the fields on the "Creature" component. We'll end up with four fields, where the Pace indicates the actual starting value to use and the others indicate an adjustment. Our new fields should looks like the following.
 <pre>
@@ Line 278: / Line 278: @@
 Unfortunately, there is a serious limitation with this approach. The user will not be able to directly modify the values for derived traits. We've made sure that the user can easily adjust the values for attributes and skills via the standard incrementers. What we need is a similar solution for derived traits, and applying the adjustments via an Eval script won't get it done.
-If we use the same basic approach as attributes and skills, then the user can adjust the values freely. That would entail assigning the adjustment value to the "trtUser" field for each derived trait. But that field is unused for those traits. We're going to need to change that behavior and use the "trtUser" field for derived traits on creatures.
+If we use the same basic approach as attributes and skills, then the user can adjust the values freely. That would entail assigning the adjustment value to the "trtUser" field for each derived trait. But that field is not used for those traits. We're going to need to change that behavior and use the "trtUser" field for derived traits on creatures.
 The first thing we need to do is revise the Creation script for the "Creature" component. In addition to setting up the attributes, we must also assign the adjustment values for derived traits. This consists of adding the following lines of code to the script.

Rob: /* Assigning Derived Traits */

2009-02-10T23:46:17Z

Assigning Derived Traits

← Older revision		Revision as of 23:46, 10 February 2009
Line 230:		Line 230:
	Derived traits work quite differently from attributes and skills for normal characters. That's because they are 100% derived from facets of the character. For creatures, though, we need to handle them differently. Various creatures have values assigned for certain derived traits that are not purely derived. The most common trait is "Pace", but other traits vary as well.		Derived traits work quite differently from attributes and skills for normal characters. That's because they are 100% derived from facets of the character. For creatures, though, we need to handle them differently. Various creatures have values assigned for certain derived traits that are not purely derived. The most common trait is "Pace", but other traits vary as well.

	The problem is that derived traits are always calculated in the end. We need to handle them in a way that will smoothly integrate with their calculated nature. Unfortunately, there is no clean way of doing that by having the derived trait value be specified explicitly for a creature. The only way to reasonably accomplish it is to utilize ~~a delta~~ that gets incorporated into the calculated final value.		The problem is that derived traits are always calculated in the end. We need to handle them in a way that will smoothly integrate with their calculated nature. Unfortunately, there is no clean way of doing that by having the derived trait value be specified explicitly for a creature. The only way to reasonably accomplish it is to utilize an adjustment that gets incorporated into the calculated final value.

	This means that we need to define four new fields for the "Creature" component. We need one field apiece for the four derived traits, where each field specifies an adjustment from the standard calculated value. If a field is not specified, then the default ~~calculation applies~~ for that trait. Our new fields should looks like the following.		This means that we need to define four new fields for the "Creature" component. We need one field apiece for the four derived traits, where each field specifies an adjustment from the standard calculated value. If a field is not specified, then no extra adjustment will be applied for that trait.

			From a usage standpoint, the problem with this approach centers on Pace. Virtually all creatures have a custom Pace, so we should really assume that Pace has a starting value of zero instead of the current six. That way, the actual Pace can be specified instead of an adjustment. Since the other derived traits rarely differ from the calculated value, requiring an adjustment to the calculated value is perfectly reasonable.

			In order to specify the Pace as an explicit value, we need to modify the trait itself. The "trPace" trait currently assumes a default value of six for the "trtBonus" field. We need to override that behavior when we have a creature. So we'll define the following Eval script on the trait to apply the special handling.

			<pre>
			<eval index="2" phase="Initialize" priority="3000"><![CDATA[
			if (hero.tagis[Hero.Creature] <> 0) then
			field[trtBonus].value = 0
			endif
			]]></eval>
			</pre>

			We'll end up with four fields, where the Pace indicates the actual starting value to use and the others indicate an adjustment. Our new fields should looks like the following.

	<pre>		<pre>

Rob: /* Assigning Derived Traits */

2009-02-10T13:31:09Z

Assigning Derived Traits

← Older revision		Revision as of 13:31, 10 February 2009
Line 287:		Line 287:
	</pre>		</pre>

	There is another detail we need to address. The minimum and maximum values for the "trtUser" field are defined within the "Trait" component. The bounds specified are intended for use with attributes and skills. Since we're tracking an adjustment value for derived traits, we need to support a range that is very different. We want a value that can range from negative to positive, and a suitable range is probably ~~from -20 to +20~~. However, we don't want to allow the user to specify a negative trait value, so we need to ensure that our minimum never goes ~~beyond a value that will~~ yield a ~~zero~~ result.		There is another detail we need to address. The minimum and maximum values for the "trtUser" field are defined within the "Trait" component. The bounds specified are intended for use with attributes and skills. Since we're tracking an adjustment value for derived traits, we need to support a range that is very different. We want a value that can range from negative to positive, and a suitable range is probably rather wide. However, we generally don't want to allow the user to specify a negative trait value (except for Charisma), so we need to ensure that our minimum never goes low enough to yield a net negative result.

			This uncovers a nasty problem, though. The issue is that the bounding of the user value must occur at the same time for all picks

	To accomplish this, we need to define our own Eval script within the "Derived" component that overrides the default bounds assigned to all traits. If our new script occurs after the one that sets the default values, our new values will be used instead. Our new Eval script should look like the one shown below.		To accomplish this, we need to define our own Eval script within the "Derived" component that overrides the default bounds assigned to all traits. If our new script occurs after the one that sets the default values, our new values will be used instead. Our new Eval script should look like the one shown below.

Rob: /* Assigning Derived Traits */

2009-02-10T13:23:40Z

Assigning Derived Traits

← Older revision		Revision as of 13:23, 10 February 2009
Line 302:		Line 302:
	]]></eval>		]]></eval>
	</pre>		</pre>

			===User Manipulation of Derived Traits===

	At this point, we have the internal workings in place and need to expose the field value for change by the user. This entails modifying the "baTrtPick" template that is used to show derived traits on the "Basics" tab. If we want the user to modify the value, we need to add a new incrementer portal. We can use a simple incrementer style that is provided by the Skeleton files, which results in the new portal shown below.		At this point, we have the internal workings in place and need to expose the field value for change by the user. This entails modifying the "baTrtPick" template that is used to show derived traits on the "Basics" tab. If we want the user to modify the value, we need to add a new incrementer portal. We can use a simple incrementer style that is provided by the Skeleton files, which results in the new portal shown below.
Line 342:		Line 344:
	Our incrementers are now showing us values, but they are all two points higher than they should be. This is because the "trtUser" field always starts out with a value of "2", which is being added to the final value. We need to force the field value to always start as zero for creatures. This is an easy fix. The default value for the "trtUser" field is given as "2" and we can change it to "0". Since the minimum value will automatically force a value of "0" to "2", everything should continue to work perfectly for normal characters after this change.		Our incrementers are now showing us values, but they are all two points higher than they should be. This is because the "trtUser" field always starts out with a value of "2", which is being added to the final value. We need to force the field value to always start as zero for creatures. This is an easy fix. The default value for the "trtUser" field is given as "2" and we can change it to "0". Since the minimum value will automatically force a value of "0" to "2", everything should continue to work perfectly for normal characters after this change.

	Let's put our changes to the test with an actual creature that applies adjustments. We'll modify our sample creature for this purpose. We can assign a few field values on the creature to apply our adjustments. We'll assign a "Pace" ~~adjustment~~ of "-2" and a "Parry" adjustment of "3". To do this, we'll add the following XML elements to the creature's definition.		Let's put our changes to the test with an actual creature that applies adjustments. We'll modify our sample creature for this purpose. We can assign a few field values on the creature to apply our adjustments. We'll assign a "Pace" of "5" and a "Parry" adjustment of "3". To do this, we'll add the following XML elements to the creature's definition.

	<pre>		<pre>
	<fieldval field="crePace" value="-2"/>		<fieldval field="crePace" value="5"/>
	<fieldval field="creParry" value="3"/>		<fieldval field="creParry" value="3"/>
	</pre>		</pre>

	Reload the data files and create a creature. Take a look at the default values shown for the derived traits. From the chooser, select our test creature. The "Pace" value should immediately change ~~from "6"~~ to "4", and the "Parry" value should change from "2" to "5". Our derived traits are working smoothly now.		Reload the data files and create a creature. Take a look at the default values shown for the derived traits. From the chooser, select our test creature. The "Pace" value should immediately change to "5", and the "Parry" value should change from "2" to "5". Our derived traits are working smoothly now.

	===Assigning Gear===		===Assigning Gear===

Rob: /* Assigning Derived Traits */

2009-02-07T23:16:43Z

Assigning Derived Traits

← Older revision		Revision as of 23:16, 7 February 2009
Line 340:		Line 340:
	</pre>		</pre>

	Our incrementers are now showing us values, but they are all two points higher than they should be. This is because the "trtUser" field always starts out with a value of "2", which is being added to the final value. We need to force the field value to always start as zero for creatures. This is an easy fix. The default value for the "trtUser" field is given as "2" and we can change it to "0". Since the minimum value will automatically force a value of "0" to "2", everything ~~will~~ continue to work perfectly for normal characters after this change.		Our incrementers are now showing us values, but they are all two points higher than they should be. This is because the "trtUser" field always starts out with a value of "2", which is being added to the final value. We need to force the field value to always start as zero for creatures. This is an easy fix. The default value for the "trtUser" field is given as "2" and we can change it to "0". Since the minimum value will automatically force a value of "0" to "2", everything should continue to work perfectly for normal characters after this change.

	Let's put our changes to the test with an actual creature that applies adjustments. We'll modify our sample creature for this purpose. We can assign a few field values on the creature to apply our adjustments. We'll assign a "Pace" adjustment of "-2" and a "Parry" adjustment of "3". To do this, we'll add the following XML elements to the creature's definition.		Let's put our changes to the test with an actual creature that applies adjustments. We'll modify our sample creature for this purpose. We can assign a few field values on the creature to apply our adjustments. We'll assign a "Pace" adjustment of "-2" and a "Parry" adjustment of "3". To do this, we'll add the following XML elements to the creature's definition.