Countering Hindrances (Savage) - Revision history

Rob: /* Adding the Rewards */

2009-02-09T02:58:23Z

Adding the Rewards

← Older revision		Revision as of 02:58, 9 February 2009
Line 76:		Line 76:
	<thing		<thing
	id="rewCash"		id="rewCash"
	name="~~Double~~ Starting Cash"		name="Additional Starting Cash"
	compset="Reward"		compset="Reward"
	description="Description goes here">		description="Description goes here">

Rob: /* Adding the Rewards */

2009-02-09T02:56:00Z

Adding the Rewards

← Older revision		Revision as of 02:56, 9 February 2009
Line 81:		Line 81:
	<fieldval field="rewPoints" value="1"/>		<fieldval field="rewPoints" value="1"/>
	<eval index="1" phase="Setup" priority="5000"><![CDATA[		<eval index="1" phase="Setup" priority="5000"><![CDATA[
	herofield[acCashMult].value *= 2		herofield[acCashMult].value += 1
	]]></eval>		]]></eval>
	</thing>		</thing>
	</pre>		</pre>

Rob: Countering Hindrances (Skeleton) moved to Countering Hindrances (Savage)

2008-12-18T04:13:28Z

Countering Hindrances (Skeleton) moved to Countering Hindrances (Savage)

← Older revision	Revision as of 04:13, 18 December 2008
(No difference)

Rob: /* Component and Component Set */

2008-12-17T23:30:52Z

Component and Component Set

← Older revision		Revision as of 23:30, 17 December 2008
Line 16:		Line 16:
	name="Reward for Hindrances"		name="Reward for Hindrances"
	autocompset="no"		autocompset="no"
	panellink="~~edges~~">		panellink="abilities">
	<field		<field
	id="rewPoints"		id="rewPoints"

Rob at 13:19, 17 December 2008

2008-12-17T13:19:15Z

← Older revision		Revision as of 13:19, 17 December 2008
Line 22:		Line 22:
	type="static">		type="static">
	</field>		</field>
	<eval ~~value~~="1" phase="Setup" priority="5000"><![CDATA[		<eval index="1" phase="Setup" priority="5000"><![CDATA[
	#resspent[resHinder] += field[rewPoints].value		#resspent[resHinder] += field[rewPoints].value
	]]></eval>		]]></eval>
Line 30:		Line 30:
	id="Reward"		id="Reward"
	forceunique="no">		forceunique="no">
	<compref component="Reward~~" primary="yes~~"/>		<compref component="Reward"/>
	</compset>		</compset>
	</pre>		</pre>
Line 45:		Line 45:
	description="Description goes here">		description="Description goes here">
	<fieldval field="rewPoints" value="2"/>		<fieldval field="rewPoints" value="2"/>
	<eval ~~value~~="1" phase="Setup" priority="5000"><![CDATA[		<eval index="1" phase="Setup" priority="5000"><![CDATA[
	#resmax[resAttrib] += 1		#resmax[resAttrib] += 1
	]]></eval>		]]></eval>
Line 51:		Line 51:
	</pre>		</pre>

	The fourth reward doubles the character's starting cash, which is easy in concept but currently cannot be handled by the data files. There is a field on the "Actor" component for tracking the character's starting cash, but this is a user-controlled field. As such, if we double this value in a script, we'll physically change the value that the user can specify. In addition, we'll keep doubling the value again every time that ~~Hero Lab~~ needs to re-evaluate everything. So we need to keep the effects of this reward decoupled from the user-controlled starting cash field.		The fourth reward doubles the character's starting cash, which is easy in concept but currently cannot be handled by the data files. There is a field on the "Actor" component for tracking the character's starting cash, but this is a user-controlled field. As such, if we double this value in a script, we'll physically change the value that the user can specify. In addition, we'll keep doubling the value again every time that HL needs to re-evaluate everything. So we need to keep the effects of this reward decoupled from the user-controlled starting cash field.

	One simple solution would be to revise the Eval script within the "Actor" component that calculates the total cash possessed by the character. We could check for the existence of the "double cash" reward and multiply the starting cash by two if it's found. This could entail defining a tag that the reward could assign to the hero, or the Eval script could explicitly look for the specific reward. While this would work, it would be exclusively tied to this one reward. Given that this is a role-playing game, it's quite likely that some GMs (or potentially some official supplements) will introduce other cases that can influence the character's starting cash. So we should come up with a more generalized solution.		One simple solution would be to revise the Eval script within the "Actor" component that calculates the total cash possessed by the character. We could check for the existence of the "double cash" reward and multiply the starting cash by two if it's found. This could entail defining a tag that the reward could assign to the hero, or the Eval script could explicitly look for the specific reward. While this would work, it would be exclusively tied to this one reward. Given that this is a role-playing game, it's quite likely that some GMs (or potentially some official supplements) will introduce other cases that can influence the character's starting cash. So we should come up with a more generalized solution.

	A solid, generalized solution ~~might~~ take the form of adding a new field to the "Actor" component. This new field would track a starting cash multiplier that would default to one. For the reward that doubles the starting cash, the value could be multiplied by two. For another effect that decreases starting cash by 10%, the value could be multiplied by 0.9. The final value of this field could then be integrated into the Eval script that calculates the net cash ~~possesses~~ by the character. Putting it together, the new field and revised Eval script would look like those presented below.		A solid, generalized solution would take the form of adding a new field to the "Actor" component. This new field would track a starting cash multiplier that would default to one. For the reward that doubles the starting cash, the value could be multiplied by two. For another effect that decreases starting cash by 10%, the value could be multiplied by 0.9. The final value of this field could then be integrated into the Eval script that calculates the net cash possessed by the character. Putting it together, the new field and revised Eval script would look like those presented below.

	<pre>		<pre>
Line 65:		Line 65:
	</field>		</field>

	<eval ~~value~~="3" phase="Effects" priority="5000"><![CDATA[		<eval index="3" phase="Effects" priority="5000"><![CDATA[
	~our net cash is our configured starting cash plus our accrued cash		~our net cash is our configured starting cash plus our accrued cash
	field[acCashNet].value = field[acCashCfg].value * field[acCashMult].value + hero.usagepool[TotalCash].value		field[acCashNet].value = field[acCashCfg].value * field[acCashMult].value + hero.usagepool[TotalCash].value
Line 80:		Line 80:
	description="Description goes here">		description="Description goes here">
	<fieldval field="rewPoints" value="1"/>		<fieldval field="rewPoints" value="1"/>
	<eval ~~value~~="1" phase="Setup" priority="5000"><![CDATA[		<eval index="1" phase="Setup" priority="5000"><![CDATA[
	herofield[acCashMult].value *= 2		herofield[acCashMult].value *= 2
	]]></eval>		]]></eval>
	</thing>		</thing>
	</pre>		</pre>

Rob: New page: {{context|Authoring Examples|Savage Worlds Walk-Through}} ===Overview=== When a user selects hindrances for a character, that character gains benefits to offset those hindrances. The hin...

2008-12-17T03:31:43Z

New page: {{context|Authoring Examples|Savage Worlds Walk-Through}} ===Overview=== When a user selects hindrances for a character, that character gains benefits to offset those hindrances. The hin...

New page

{{context|Authoring Examples|Savage Worlds Walk-Through}}

===Overview===

When a user selects hindrances for a character, that character gains benefits to offset those hindrances. The hindrance points are accrued, and the user must now redeem those hindrance points.

===Component and Component Set===

Within the Savage Worlds game system, there are four choices for how to spend the accrued hindrance points, so we need a way to mange this. This entails adding a new component and component set, and we'll refer to each of these options as a "Reward". Each reward is extremely simple, with a field specifying how many hindrance points are redeemed for the reward and all other details being managed through an Eval script.

An appropriate implementation of the component and component set are presented below. Note that the same reward can be selected multiple times, so it's important that rewards not be designated as unique.

<pre>
<component
id="Reward"
name="Reward for Hindrances"
autocompset="no"
panellink="edges">
<field
id="rewPoints"
name="Hindrance Points"
type="static">
</field>
<eval value="1" phase="Setup" priority="5000"><![CDATA[
#resspent[resHinder] += field[rewPoints].value
]]></eval>
</component>

<compset
id="Reward"
forceunique="no">
<compref component="Reward" primary="yes"/>
</compset>
</pre>

===Adding the Rewards===

We'll add all of our rewards into a new file named "thing_rewards.dat", thereby keeping them all together in a convenient location. Three of the rewards entail merely adjusting the maximum value for a resource to confer the benefit. For example, the reward that grants an extra attribute point is shown below. Remember that the same reward can be selected multiple times, so rewards must not be unique.

<pre>
<thing
id="rewAttrib"
name="+1 Attribute Point"
compset="Reward"
description="Description goes here">
<fieldval field="rewPoints" value="2"/>
<eval value="1" phase="Setup" priority="5000"><![CDATA[
#resmax[resAttrib] += 1
]]></eval>
</thing>
</pre>

The fourth reward doubles the character's starting cash, which is easy in concept but currently cannot be handled by the data files. There is a field on the "Actor" component for tracking the character's starting cash, but this is a user-controlled field. As such, if we double this value in a script, we'll physically change the value that the user can specify. In addition, we'll keep doubling the value again every time that Hero Lab needs to re-evaluate everything. So we need to keep the effects of this reward decoupled from the user-controlled starting cash field.

One simple solution would be to revise the Eval script within the "Actor" component that calculates the total cash possessed by the character. We could check for the existence of the "double cash" reward and multiply the starting cash by two if it's found. This could entail defining a tag that the reward could assign to the hero, or the Eval script could explicitly look for the specific reward. While this would work, it would be exclusively tied to this one reward. Given that this is a role-playing game, it's quite likely that some GMs (or potentially some official supplements) will introduce other cases that can influence the character's starting cash. So we should come up with a more generalized solution.

A solid, generalized solution might take the form of adding a new field to the "Actor" component. This new field would track a starting cash multiplier that would default to one. For the reward that doubles the starting cash, the value could be multiplied by two. For another effect that decreases starting cash by 10%, the value could be multiplied by 0.9. The final value of this field could then be integrated into the Eval script that calculates the net cash possesses by the character. Putting it together, the new field and revised Eval script would look like those presented below.

<pre>
<field
id="acCashMult"
name="Starting Cash Multiplier"
type="derived"
defvalue="1">
</field>

<eval value="3" phase="Effects" priority="5000"><![CDATA[
~our net cash is our configured starting cash plus our accrued cash
field[acCashNet].value = field[acCashCfg].value * field[acCashMult].value + hero.usagepool[TotalCash].value
]]></eval>
</pre>

Once the above mechanics are in place, we can add the fourth reward, and it should look similar to the example shown below.

<pre>
<thing
id="rewCash"
name="Double Starting Cash"
compset="Reward"
description="Description goes here">
<fieldval field="rewPoints" value="1"/>
<eval value="1" phase="Setup" priority="5000"><![CDATA[
herofield[acCashMult].value *= 2
]]></eval>
</thing>
</pre>