More Cleanup (Savage) - Revision history

Rob: /* Customizable Abilities */

2009-02-12T04:37:42Z

Customizable Abilities

← Older revision		Revision as of 04:37, 12 February 2009
Line 362:		Line 362:
	perform hero.child[wpUnarmed].setfocus		perform hero.child[wpUnarmed].setfocus
	focus.field[livename].text = field[name].text		focus.field[livename].text = field[name].text

			~get our ability text; if we have none, assume "Str"
			~Note: This handles the case of a natural weapon with no additional die.
			var ability as string
			ability = field[abilText].text
			if (empty(ability) <> 0) then
			ability = "Str"
			endif

	~if we don't have a weapon die, assign the damage text		~if we don't have a weapon die, assign the damage text
	if (tagis[WeaponDie.?] = 0) then		if (tagis[WeaponDie.?] = 0) then
	focus.field[wpDamage].text = ~~field[abilText].text~~		focus.field[wpDamage].text = ability
	endif		endif

Line 379:		Line 387:
	field[livename].text &= " (Str+d" & die & ")"		field[livename].text &= " (Str+d" & die & ")"
	else		else
	field[livename].text &= " (" & ~~field[abilText].text~~ & ")"		field[livename].text &= " (" & ability & ")"
	endif		endif
	]]></eval>		]]></eval>

Rob: /* Customizable Abilities */

2009-02-11T23:16:05Z

Customizable Abilities

← Older revision		Revision as of 23:16, 11 February 2009
Line 313:		Line 313:
	description="">		description="">
	<bootstrap thing="armNatural"/>		<bootstrap thing="armNatural"/>
	<eval index="1" phase="~~Initialize~~" priority="~~1000~~">		<eval index="1" phase="Effects" priority="5000">
	<before name="Calc trtFinal"/><![CDATA[		<before name="Calc trtFinal"/><![CDATA[
	~set the defensive value for the armor		~set the defensive value for the armor
Line 340:		Line 340:
	</pre>		</pre>

	We can define a similar special ability for use as a natural weapon. The "Unarmed Attack" weapon is always bootstrapped to every actor, so we don't need to bootstrap anything here. Instead, we simply customize the already existing weapon to suit our needs. The damage associated with the natural weapon can be specified in two different ways. In general, it will be assigned via the appropriate "WeaponDie" tag, but it can also be specified via the "abilText" field. The damage will be appended to both the weapon damage and the name of the ability. We handle it this way so that the ability name shows the extra damage, but the weapon entry itself omits the extra damage from the name. This yields the following special ability.		We can define a similar special ability for use as a natural weapon. The "Unarmed Attack" weapon is always bootstrapped to every actor, so we don't need to bootstrap anything here. Instead, we simply customize the already existing weapon to suit our needs. The damage associated with the natural weapon can be specified in two different ways. In general, it will be assigned via the appropriate "WeaponDie" tag, but it can also be specified via the "abilText" field. The damage will be appended to both the weapon damage and the name of the ability. We handle it this way so that the ability name shows the extra damage, but the weapon entry itself omits the extra damage from the name.

			There is a critical detail we have to be careful about here. The "WeaponDie" tag is used at a timing of Initialize/5000 to setup the damage properly for the weapon. This means that we must forward the tag to the "Unarmed Attack" weapon before then. However, all of the other logic should be performed later, such as within the Effects phase. Consequently, we need to define two separate Eval scripts, with each doing different pieces of the handling. This yields the following special ability.

	<pre>		<pre>
Line 349:		Line 351:
	isunique="yes"		isunique="yes"
	description="">		description="">
	<eval index="1" phase="Initialize" priority="~~1000~~"><![CDATA[		<eval index="1" phase="Initialize" priority="2000"><![CDATA[
			~if we have a weapon die, we must forward it immediately (before it's used)
			if (tagis[WeaponDie.?] <> 0) then
			perform hero.child[wpUnarmed].pushtags[WeaponDie.?]
			endif
			]]></eval>
			<eval index="2" phase="Effects" priority="5000"><![CDATA[
	~customize the Unarmed Attack pick with the appropriate name		~customize the Unarmed Attack pick with the appropriate name
	~Note: Do this BEFORE modifying our name below to use an undecorated name.		~Note: Do this BEFORE modifying our name below to use an undecorated name.
Line 355:		Line 363:
	focus.field[livename].text = field[name].text		focus.field[livename].text = field[name].text

	~if we have a weapon die, ~~forward it, else~~ assign the damage text		~if we don't have a weapon die, assign the damage text
	if (tagis[WeaponDie.?] <> 0) then		if (tagis[WeaponDie.?] = 0) then
	~~perform~~ focus.~~pushtags~~[~~WeaponDie~~.?]		focus.field[wpDamage].text = field[abilText].text
	~~else~~		endif
	~~focus.~~field[~~wpDamage~~].text = ~~"Str" &~~ field[~~abilText~~].text
			~if our live name is currently empty, use our default name
			if (field[livename].isempty <> 0) then
			field[livename].text = field[name].text
	endif		endif

Rob: /* Customizable Abilities */

2009-02-10T05:15:02Z

Customizable Abilities

← Older revision		Revision as of 05:15, 10 February 2009
Line 280:		Line 280:
	===Customizable Abilities===		===Customizable Abilities===

	There are ~~only a handful of~~ races defined in the core rulebook. However, there are many ~~more~~ defined in ~~all~~ the various supplements. Abilities will also be used with all the various creatures throughout the core rulebook and supplements. Many of the special abilities are basically the same thing with slight variations. For example, different races and creatures possess natural weapons and/or natural armor.		There are no races actually defined in the core rulebook (other than Humans). However, there are many races defined in the various supplements. Abilities will also be used with all the various creatures throughout the core rulebook and supplements. Many of the special abilities are basically the same thing with slight variations. For example, different races and creatures possess natural weapons and/or natural armor.

	The names and bonuses of these special abilities often differ, but the mechanics are all the same. This results in the need to define lots of very similar abilities. It would be much easier if we simply provided some customizable special abilities that could be easily re-used and adapted.		The names and bonuses of these special abilities often differ, but the mechanics are all the same. This results in the need to define lots of very similar abilities. It would be much easier if we simply provided some customizable special abilities that could be easily re-used and adapted.

	Let's take a look at the types of customization that we need~~. For natural weapons, we need to modify the name (e.g. "Bite", "Claw", etc.) and specify an appropriate bonus for the attack as text (e.g. "+d6")~~. For natural armor, we need to modify the name (e.g. "Carapace") and specify the numeric armor rating to be used (e.g. "2"). If we scan through the various creature abilities, the "Size" ability requires a numeric rating, so it can be handled the same way as natural armor.		Let's take a look at the types of customization that we need. For natural armor, we need to modify the name (e.g. "Carapace") and specify the numeric armor rating to be used (e.g. "2"). If we scan through the various creature abilities, the "Size" ability requires a numeric rating, so it can be handled the same way as natural armor. For natural weapons, we need to modify the name (e.g. "Bite", "Claw", etc.) and specify the appropriate damage the attack. This may need to be done as a weapon die or as text for odd situations (e.g. "2d6"). We also need to handle situation like weaknesses and immunities for creatures, which need to specify custom text with the details.

	This leaves us with the need for three separate fields that can be used to customize a special ability. ~~However~~, we can already modify the name via use of the "livename" field. So we really only need two customization fields - a value and a string. We'll add these to the "RaceAbil" component as shown below.		This leaves us with the need for three separate fields that can be used to customize a special ability. For the weapon die, we'll use the existing tag mechanism that is already in place. We can already modify the name via use of the "livename" field. So we really only need two new customization fields - a value and a string. We'll add these to the "RaceAbil" component as shown below.

	<pre>		<pre>
Line 311:		Line 311:
	compset="RaceAbil"		compset="RaceAbil"
	isunique="yes"		isunique="yes"
	description="~~Description goes here~~">		description="">
	<bootstrap thing="armNatural"/>		<bootstrap thing="armNatural"/>
	<eval index="1" phase="~~PreTraits~~" priority="~~5000~~">		<eval index="1" phase="Initialize" priority="1000">
	<before name="Calc trtFinal"/><![CDATA[		<before name="Calc trtFinal"/><![CDATA[
	~set the defensive value for the armor		~set the defensive value for the armor
	hero.child[armNatural].field[defDefense].value = field[abilValue].value		perform hero.child[armNatural].setfocus
			focus.field[defDefense].value = field[abilValue].value

	~append the value to ~~the name~~		~if we've been assigned a custom name, assign it to the armor
			if (empty(field[livename].text) = 0) then
			focus.field[livename].text = field[livename].text
			endif

			~append the value to both names
	field[livename].text = field[name].text & " " & signed(field[abilValue].value)		field[livename].text = field[name].text & " " & signed(field[abilValue].value)
			focus.field[livename].text = focus.field[name].text & " " & signed(field[abilValue].value)
	]]></eval>		]]></eval>
	</thing>		</thing>
Line 333:		Line 340:
	</pre>		</pre>

	We can define a similar special ability for use as natural ~~weapons~~. The "Unarmed Attack" weapon is always bootstrapped to every actor, so we don't need to bootstrap anything here. Instead, we simply customize the already existing weapon to suit our needs. The ~~extra~~ damage associated with the natural weapon is specified via the "abilText" field~~, and this field is~~ appended to both the weapon damage and the name of the ability. We handle it this way so that the ability name shows the extra damage, but the weapon entry itself omits the extra damage from the name. This yields the following special ability.		We can define a similar special ability for use as a natural weapon. The "Unarmed Attack" weapon is always bootstrapped to every actor, so we don't need to bootstrap anything here. Instead, we simply customize the already existing weapon to suit our needs. The damage associated with the natural weapon can be specified in two different ways. In general, it will be assigned via the appropriate "WeaponDie" tag, but it can also be specified via the "abilText" field. The damage will be appended to both the weapon damage and the name of the ability. We handle it this way so that the ability name shows the extra damage, but the weapon entry itself omits the extra damage from the name. This yields the following special ability.

	<pre>		<pre>
Line 341:		Line 348:
	compset="RaceAbil"		compset="RaceAbil"
	isunique="yes"		isunique="yes"
	description="~~Description goes here~~">		description="">
	<eval index="1" phase="~~Traits~~" priority="~~10000~~"><![CDATA[		<eval index="1" phase="Initialize" priority="1000"><![CDATA[
	~customize the Unarmed Attack pick with the appropriate name ~~and damage~~		~customize the Unarmed Attack pick with the appropriate name
			~Note: Do this BEFORE modifying our name below to use an undecorated name.
	perform hero.child[wpUnarmed].setfocus		perform hero.child[wpUnarmed].setfocus
	focus.field[livename].text = field[name].text		focus.field[livename].text = field[name].text
	~~focus.field[wpDamage].text = "Str" & field[abilText].text~~

	~~~append~~ the ~~extra~~ text to our name		~if we have a weapon die, forward it, else assign the damage text
	~~~Note: Do this AFTER modifying weapon name above to use an undecorated name~~.		if (tagis[WeaponDie.?] <> 0) then
	field[livename].text &= " " & field[abilText].text		perform focus.pushtags[WeaponDie.?]
			else
			focus.field[wpDamage].text = "Str" & field[abilText].text
			endif

			~update our name appropriately for display
			if (tagis[WeaponDie.?] <> 0) then
			var die as number
			die = tagvalue[WeaponDie.?] * 2
			field[livename].text &= " (Str+d" & die & ")"
			else
			field[livename].text &= " (" & field[abilText].text & ")"
			endif
	]]></eval>		]]></eval>
	</thing>		</thing>
	</pre>		</pre>

	Putting our new special ability to use is very simple. We bootstrap the ability onto the actor ~~and~~ customize ~~both the~~ "~~abilText~~" and ~~"livename" fields~~. The example below shows a natural weapon that is called a "Bite" and ~~confers an extra~~ "+d6" damage.		Putting our new special ability to use is very simple. Using the "WeaponDie" method, we bootstrap the ability onto the actor, customize "livename" field, and assign the proper tag. The example below shows a natural weapon that is called a "Bite" and does "Str+d6" damage.

	<pre>		<pre>
	<bootstrap thing="abWeapon">		<bootstrap thing="abWeapon">
			<autotag group="WeaponDie" tag="3"/>
	<assignval field="livename" value="Bite"/>		<assignval field="livename" value="Bite"/>
	<assignval field="abilText" value="~~+d6~~"/>		</bootstrap>
			</pre>

			If the damage were something non-standard, we would use the alternate method. We would bootstrap the ability onto the actor and customize both the "abilText" and "livename" fields. The example below shows a natural weapon that is called a "Non-Standard" and confers "2d6" damage.

			<pre>
			<bootstrap thing="abWeapon">
			<assignval field="livename" value="Non-Standard"/>
			<assignval field="abilText" value="2d6"/>
	</bootstrap>		</bootstrap>
	</pre>		</pre>

Rob: /* Overview */

2009-02-09T14:49:33Z

Overview

← Older revision		Revision as of 14:49, 9 February 2009
Line 3:		Line 3:
	===Overview===		===Overview===

	~~Our list~~ of ~~things~~ we came up with previously ~~is almost fully~~ addressed. Let's take this opportunity to do another round of testing everything and see if there's anything we missed last time. Then we can knock off the remaining little things on our list. The sections below identify the various issues we can spot and the fixes that we need to make.		Many of the tasks we came up with previously have been addressed. Let's take this opportunity to do another round of testing everything and see if there's anything we missed last time. Then we can knock off most of the remaining little things on our list. The sections below identify the various issues we can spot and the fixes that we need to make.

	===Damage and Non-Wildcards===		===Damage and Non-Wildcards===

Rob: /* Centralize Rank Name Handling */

2009-02-08T07:09:56Z

Centralize Rank Name Handling

← Older revision		Revision as of 07:09, 8 February 2009
Line 472:		Line 472:
	</pre>		</pre>

	A suitable field is now in place on the actor. We can go through all calls to the "RankName" procedure and change most of them to retrieve the new field instead of calling the procedure itself. The first instance is in the		A suitable field is now in place on the actor. We can go through all calls to the "RankName" procedure and change most of them to retrieve the new field instead of calling the procedure itself. The first instance is in the "Actor" component itself, within the Eval script that synthesizes the recap summary for allies. We can replace the code that invokes the procedure with a single line, as shown below.

			<pre>
			recap &= field[acRankName].text & " (" & field[acFinalXP].value & " XP)"
			</pre>

			The next instance is in the LeadSummary script within the definition file. As we did above, we can replace the block of code with a single line shown below.

			<pre>
			@text &= " - " & herofield[acRankName].text & " - " & herofield[acFinalXP].value & " XP"
			</pre>

			The instance we come across is in the "MinRank" component, where the rank is referenced within the pre-requisite test. This time, we are determining the displayed rank based on the requirement specified instead of the actual rank of the actor. So there is nothing to change here.

			There are two separate tabs where the rank name is displayed, and both need to be changed. On the "Basics" tab, the "baRank" portal can be replaced with a single line of code, just like we did above. On the "Journal" tab, the synthesis of the info shown across the top and eliminate the procedure call and simply reference the field.

			The remaining two places are within the character sheet output. Both on the first sheet and the second sheet, the rank name is included in the output. As we did above, both instances can be swapped out for a single line of code.

Rob: /* Centralize Rank Name Handling */

2009-02-08T06:52:53Z

Centralize Rank Name Handling

← Older revision		Revision as of 06:52, 8 February 2009
Line 445:		Line 445:

	===Centralize Rank Name Handling===		===Centralize Rank Name Handling===

			There are more than a half-dozen places where the "RankName" procedure is called to convert the rank as a value to the corresponding name for display. In all but one of these places, the rank value being used is the rank of the current actor. There is no reason for us to go through the logic of setting up to call the procedure each time.

			Instead, we can simplify everything by adding a new field to the "Actor" component where we can synthesize and store the rank name a single time. Then we can have each of these places simply retrieve the field from the hero. Our new field should look similar to the one below.

			<pre>
			<field
			id="acRankName"
			name="Current Rank as Name"
			type="derived"
			maxlength="15">
			</field>
			</pre>

			We can then add a new Eval script to the component that will synthesize and save the name properly. We need to schedule this script after the value is determine, and it must be done before we need to reference the field. The new script should look like below.

			<pre>
			<eval index="8" phase="Render" priority="1000"><![CDATA[
			~convert our current rank value to the corresponding name and save it
			var rankvalue as number
			var ranktext as string
			rankvalue = field[acRank].value
			call RankName
			field[acRankName].text = ranktext
			]]></eval>
			</pre>

			A suitable field is now in place on the actor. We can go through all calls to the "RankName" procedure and change most of them to retrieve the new field instead of calling the procedure itself. The first instance is in the

Rob at 06:40, 8 February 2009

2009-02-08T06:40:53Z

← Older revision		Revision as of 06:40, 8 February 2009
Line 443:		Line 443:
	<fieldval field="adjCandid" value="component.Derived & !Hide.Trait"/>		<fieldval field="adjCandid" value="component.Derived & !Hide.Trait"/>
	</pre>		</pre>

			===Centralize Rank Name Handling===

Rob at 01:09, 8 February 2009

2009-02-08T01:09:19Z

← Older revision		Revision as of 01:09, 8 February 2009
Line 443:		Line 443:
	<fieldval field="adjCandid" value="component.Derived & !Hide.Trait"/>		<fieldval field="adjCandid" value="component.Derived & !Hide.Trait"/>
	</pre>		</pre>

	~~===Next===~~

Rob: /* Starting Bennies */

2009-02-07T14:33:30Z

Starting Bennies

← Older revision		Revision as of 14:33, 7 February 2009
Line 112:		Line 112:

	<pre>		<pre>
	<eval index="1" phase="Initialize" priority="~~5000~~"><![CDATA[		<eval index="1" phase="Initialize" priority="6000"><![CDATA[
	~if we're not a wildcard, we get zero starting Bennies		~if we're not a wildcard, we get zero starting Bennies
	if (herofield[acIsWild].value = 0) then		if (herofield[acIsWild].value = 0) then

Rob: /* Starting Bennies */

2009-02-07T14:15:49Z

Starting Bennies

← Older revision		Revision as of 14:15, 7 February 2009
Line 112:		Line 112:

	<pre>		<pre>
	<eval index="1" phase="Initialize" priority="~~2000~~"><![CDATA[		<eval index="1" phase="Initialize" priority="5000"><![CDATA[
	~if we're not a wildcard, we get zero starting Bennies		~if we're not a wildcard, we get zero starting Bennies
	if (herofield[acIsWild].value = 0) then		if (herofield[acIsWild].value = 0) then