Validate Script - Revision history

Rob: /* Technical Details */

2009-02-20T08:45:22Z

Technical Details

← Older revision		Revision as of 08:45, 20 February 2009
Line 15:		Line 15:
	\|Where Used:		\|Where Used:
	\|[[Component Element (Data)\|Components]], [[Thing Element (Data)\|Things]]		\|[[Component Element (Data)\|Components]], [[Thing Element (Data)\|Things]]
			\|-
			\|Procedure Use:
			\|"validate" type, "pick" context
	\|-		\|-
	\|}		\|}

Rob at 00:08, 16 December 2008

2008-12-16T00:08:46Z

← Older revision		Revision as of 00:08, 16 December 2008
Line 12:		Line 12:
	\|Fields Finalized?		\|Fields Finalized?
	\|Yes		\|Yes
			\|-
			\|Where Used:
			\|[[Component Element (Data)\|Components]], [[Thing Element (Data)\|Things]]
	\|-		\|-
	\|}		\|}

Rob at 12:22, 15 December 2008

2008-12-15T12:22:03Z

← Older revision		Revision as of 12:22, 15 December 2008
Line 19:		Line 19:
	:{\| class="infotable"		:{\| class="infotable"
	\|class="leftnormal"\|valid		\|class="leftnormal"\|valid
	\|Entry: Assumes the pre-requisite is '''not''' satisfied with a value of zero.<br>		\|(Number) Entry: Assumes the pre-requisite is '''not''' satisfied with a value of zero.<br>
	Exit: Indicates whether the pre-requisite is satisfied (non-zero) or not satisfied (zero).		Exit: Indicates whether the pre-requisite is satisfied (non-zero) or not satisfied (zero).
	\|-		\|-
	\|message		\|message
	\|Entry: Contains the default message text if the pre-requisite is not satisfied.<br>		\|(String) Entry: Contains the default message text if the pre-requisite is not satisfied.<br>
	Exit: Contains the final message text to display if the pre-requisite is not satisfied. The text may contain [[Encoded Text\|encoding]].		Exit: Contains the final message text to display if the pre-requisite is not satisfied. The text may contain [[Encoded Text\|encoding]].
	\|-		\|-
	\|ispick		\|ispick
	\|Entry: Indicates whether the pre-requisite is being applied to a pick (non-zero) or thing (zero).<br>		\|(Number) Entry: Indicates whether the pre-requisite is being applied to a pick (non-zero) or thing (zero).<br>
	Exit: Ignored.		Exit: Ignored.
	\|-		\|-

Rob at 12:12, 15 December 2008

2008-12-15T12:12:44Z

← Older revision		Revision as of 12:12, 15 December 2008
Line 24:		Line 24:
	\|message		\|message
	\|Entry: Contains the default message text if the pre-requisite is not satisfied.<br>		\|Entry: Contains the default message text if the pre-requisite is not satisfied.<br>
	Exit: Contains the final message text to display if the pre-requisite is not satisfied.		Exit: Contains the final message text to display if the pre-requisite is not satisfied. The text may contain [[Encoded Text\|encoding]].
	\|-		\|-
	\|ispick		\|ispick

Rob: /* Description */

2008-12-14T13:00:18Z

Description

← Older revision		Revision as of 13:00, 14 December 2008
Line 42:		Line 42:
	When invoked, a Validate script starts with the container as its initial context. If the object is a pick, the container is the one the pick resides within. If the object is a thing, the container is the prospective container to which the thing will potentially be added. The reason for the container as the initial context is that the pre-requisite test is defined on the thing. Consequently, the thing will know about itself and will typically be looking to verify that the prospective container satisfies the needs of the thing.		When invoked, a Validate script starts with the container as its initial context. If the object is a pick, the container is the one the pick resides within. If the object is a thing, the container is the prospective container to which the thing will potentially be added. The reason for the container as the initial context is that the pre-requisite test is defined on the thing. Consequently, the thing will know about itself and will typically be looking to verify that the prospective container satisfies the needs of the thing.

	For those situations where you also need to access characteristics of the pick or thing, the Validate script provides an alternate context. This context will always be the pick or thing, as appropriate. You can use the "ispick" special symbol to determine whether the pre-requisite is being applied to a pick or a thing.		For those situations where you also need to access characteristics of the pick or thing, the Validate script provides an alternate context. This context will always be the pick or thing, as appropriate. You can use the "ispick" special symbol to determine whether the pre-requisite is being applied to a pick or a thing. After that, you can use the "altpick" or "altthing" context to access the object.

	{{note}}The use of pre-requisites with a Validate script is generally only needed in more complex situations. The "pickreq" and "exprreq" mechanisms are much simpler to use and maintain, and they should cover 90% of the situations where you need to establish a pre-requisite.		{{note}}The use of pre-requisites with a Validate script is generally only needed in more complex situations. The "pickreq" and "exprreq" mechanisms are much simpler to use and maintain, and they should cover 90% of the situations where you need to establish a pre-requisite.

Rob at 10:06, 14 December 2008

2008-12-14T10:06:48Z

← Older revision		Revision as of 10:06, 14 December 2008
Line 38:		Line 38:
	The pre-requisite test can be anything you want, provided only the object and the container are considered by the test. The requirement is always either satisfied or not satisfied. This is determined by the "valid" special symbol. The symbol starts out as zero, indicating that the requirement is not satisfied. At any point during the script, you can set the symbol to non-zero, thereby indicating that the requirement '''is''' satisfied. The only value that matters is the final value when the script ends, where a non-zero value indicates the pre-requisite is satisfied.		The pre-requisite test can be anything you want, provided only the object and the container are considered by the test. The requirement is always either satisfied or not satisfied. This is determined by the "valid" special symbol. The symbol starts out as zero, indicating that the requirement is not satisfied. At any point during the script, you can set the symbol to non-zero, thereby indicating that the requirement '''is''' satisfied. The only value that matters is the final value when the script ends, where a non-zero value indicates the pre-requisite is satisfied.

	~~Since an EvalRule script~~ is ~~equivalent to an Eval script~~, it ~~'''~~is~~''' possible to apply changes throughout~~ the ~~structural hierarchy via the script~~. ~~However,~~ it is ~~generally a bad idea to do that, since~~ the ~~purpose of an EvalRule script is~~ to ~~validate~~ a ~~rule~~ - not ~~effect change~~. ~~We therefore recommend that you avoid applying changes within EvalRule scripts~~.		Each pre-requisite is associated with a particular thing. If a pre-requisite is defined for a component, then it is inherited by the things which derive from that component. The pre-requisites are checked for every thing when it is presented as an option for the user to add via a table or chooser. If one or more pre-requisites are not satisfied, the thing is designated as invalid and the failed requirements are shown in the description information for the thing. If the thing is added by the user in spite of the failed pre-requisites, then all the pre-requisites are applied to the pick at the end of every evaluation cycle.

	~~Since~~ the ~~message and summary are typically static requirements (e~~.g. ~~an attribute must be~~ a ~~value of X or more)~~, ~~you will rarely need~~ to ~~modify them. However, there~~ will be ~~cases where you want to tailor~~ the ~~message and/or summary to provide more detailed information based~~ on ~~dynamic information~~. ~~When this situations arise~~, ~~simply set~~ the ~~"message"~~ and~~/or "summary" special values~~ to the ~~desired contents and they will be used~~.		When invoked, a Validate script starts with the container as its initial context. If the object is a pick, the container is the one the pick resides within. If the object is a thing, the container is the prospective container to which the thing will potentially be added. The reason for the container as the initial context is that the pre-requisite test is defined on the thing. Consequently, the thing will know about itself and will typically be looking to verify that the prospective container satisfies the needs of the thing.

			For those situations where you also need to access characteristics of the pick or thing, the Validate script provides an alternate context. This context will always be the pick or thing, as appropriate. You can use the "ispick" special symbol to determine whether the pre-requisite is being applied to a pick or a thing.

	~~Like an Eval script, every EvalRule script is associated~~ with a ~~particular thing. If an EvalRule~~ script is ~~defined for component, then it is inherited by the things which derive from that component~~. ~~When a thing is added to a container, it becomes a pick,~~ and ~~new instances of every EvalRule script for that thing~~ are ~~created~~ and ~~managed by HL. You associate all of the validation rules with each pick via the EvalRule scripts defined for the underlying thing.~~		{{note}}The use of pre-requisites with a Validate script is generally only needed in more complex situations. The "pickreq" and "exprreq" mechanisms are much simpler to use and maintain, and they should cover 90% of the situations where you need to establish a pre-requisite.

	~~When invoked~~, ~~an Eval script starts with its associated pick as its initial context. You are free to navigate through the hierarchy~~ and ~~test the state~~ of ~~anything that impacts the rule. However, a given EvalRule script should will typically either pertain to~~ the ~~associated pick or pertain~~ to ~~the actor as~~ a ~~whole~~.

	==Example==		==Example==

	~~An EvalRule script can be used~~ to ~~test virtually anything~~. ~~Within the Sample data files,~~ a ~~rule is used to ensure~~ that ~~pieces of gear are not both equipped and held within~~ a ~~container~~ (~~e.g.~~ a ~~sword being equipped and stored in a backpack). The rule below will verify this condition~~.		A simple pre-requisite might establish a dependency on an attribute value being at least equal to some number. The example below shows a Validate script that tests whether the container has a child pick (strength) that has a final value of at least 13.

	<pre>		<pre>
	~~~if not both equipped and held within a container, we're valid~~		if (child[attrStr].field[trtFinal].value >= 13) then
	if (field[~~grIsEquip~~].value ~~+ isgearheld < 2~~) then
	@valid = 1		@valid = 1
	~~done~~
	endif		endif

	~~~mark the tab as invalid~~
	~~linkvalid = 0~~
	</pre>		</pre>

Rob at 09:43, 14 December 2008

2008-12-14T09:43:43Z

← Older revision		Revision as of 09:43, 14 December 2008
Line 34:		Line 34:
	==Description==		==Description==

	The ~~EvalRule~~ script is ~~very similar~~ to ~~an [[Eval Script\|Eval script]]~~, ~~with~~ the ~~primary distinction being that the EvalRule script verifies a rule~~ is ~~observed instead of applying changes~~. ~~This script~~ is ~~scheduled during~~ the ~~evaluation cycle~~, ~~so it allows you to check~~ the ~~state of an actor at intermediate points in addition to at~~ the ~~end of evaluation. Intermediate checks make it possible to verify values before they are further modified by other aspects of~~ the ~~character~~.		The Validate script is exclusively used within pre-requisite tests. The script verifies that a specific pick or thing satisfies a particular pre-requisite relative to its container. If the requirement is not satisfied, then the object is designated as invalid. If the object is a pick that has already been added to the portfolio, the specified message is displayed within the validation report for the actor.

	~~An EvalRule script shares all the same behaviors of an Eval script, plus it adds the rule to be validated.~~ The ~~rule~~ can be anything you want~~. However~~, the ~~rule~~ is always either satisfied or not satisfied. This is determined by the "valid" special symbol. The symbol starts out as zero, indicating that the ~~rule~~ is not satisfied. At any point during the script, you can set the symbol to non-zero, thereby indicating that the ~~rule~~ '''is''' satisfied~~. You can also change the symbol value throughout the script if you want~~. The only value that matters is the final value when the script ends, where a non-zero value indicates the ~~script~~ is satisfied.		The pre-requisite test can be anything you want, provided only the object and the container are considered by the test. The requirement is always either satisfied or not satisfied. This is determined by the "valid" special symbol. The symbol starts out as zero, indicating that the requirement is not satisfied. At any point during the script, you can set the symbol to non-zero, thereby indicating that the requirement '''is''' satisfied. The only value that matters is the final value when the script ends, where a non-zero value indicates the pre-requisite is satisfied.

	If the ~~validation test~~ is ~~not satisfied~~, the ~~message and summary for the~~ rule ~~are displayed~~ within ~~the validation report and validation summary for the actor, respectively~~. Since the message and summary are typically static requirements (e.g. an attribute must be a value of X or more), you will rarely need to modify them. However, there will be cases where you want to tailor the message and/or summary to provide more detailed information based on dynamic information. When this situations arise, simply set the "message" and/or "summary" special values to the desired contents and they will be used.		Since an EvalRule script is equivalent to an Eval script, it '''is''' possible to apply changes throughout the structural hierarchy via the script. However, it is generally a bad idea to do that, since the purpose of an EvalRule script is to validate a rule - not effect change. We therefore recommend that you avoid applying changes within EvalRule scripts.

			Since the message and summary are typically static requirements (e.g. an attribute must be a value of X or more), you will rarely need to modify them. However, there will be cases where you want to tailor the message and/or summary to provide more detailed information based on dynamic information. When this situations arise, simply set the "message" and/or "summary" special values to the desired contents and they will be used.

	Since an EvalRule script is equivalent to an Eval script, it '''is''' possible to apply changes throughout the structural hierarchy via the script. However, it is generally a bad idea to do that, since the purpose of an EvalRule script is to validate a rule - not effect change. We therefore recommend that you avoid applying changes within EvalRule scripts.

	Like an Eval script, every EvalRule script is associated with a particular thing. If an EvalRule script is defined for component, then it is inherited by the things which derive from that component. When a thing is added to a container, it becomes a pick, and new instances of every EvalRule script for that thing are created and managed by HL. You associate all of the validation rules with each pick via the EvalRule scripts defined for the underlying thing.		Like an Eval script, every EvalRule script is associated with a particular thing. If an EvalRule script is defined for component, then it is inherited by the things which derive from that component. When a thing is added to a container, it becomes a pick, and new instances of every EvalRule script for that thing are created and managed by HL. You associate all of the validation rules with each pick via the EvalRule scripts defined for the underlying thing.

Rob at 09:34, 14 December 2008

2008-12-14T09:34:35Z

← Older revision		Revision as of 09:34, 14 December 2008
Line 5:		Line 5:
	:{\| class="scripttable"		:{\| class="scripttable"
	\|class="leftnormal"\|Initial Context:		\|class="leftnormal"\|Initial Context:
	\|[[~~Pick~~ Context\|~~Pick~~]]		\|[[Container Context\|Container]]
	\|-		\|-
	\|Alternate Context:		\|Alternate Context:
	\|~~None~~		\|[[Pick Context\|Pick]] or [[Thing Context\|Thing]]
	\|-		\|-
	\|Fields Finalized?		\|Fields Finalized?
	\|No		\|Yes
	\|-		\|-
	\|}		\|}

	The ~~EvalRule~~ script utilizes the following special symbols:		The Validate script utilizes the following special symbols:

	:{\| class="infotable"		:{\| class="infotable"
	\|class="leftnormal"\|valid		\|class="leftnormal"\|valid
	\|Entry: ~~Assumed~~ the ~~rule~~ is '''not''' satisfied with a value of zero.<br>		\|Entry: Assumes the pre-requisite is '''not''' satisfied with a value of zero.<br>
	Exit: Indicates whether the ~~rule~~ is satisfied (non-zero) or not satisfied (zero).		Exit: Indicates whether the pre-requisite is satisfied (non-zero) or not satisfied (zero).
	\|-		\|-
	\|message		\|message
	\|Entry: Contains the default message text if the ~~rule~~ is not satisfied.<br>		\|Entry: Contains the default message text if the pre-requisite is not satisfied.<br>
	Exit: Contains the final message text to display if the ~~rule~~ is not satisfied.		Exit: Contains the final message text to display if the pre-requisite is not satisfied.
	\|-		\|-
	\|~~summary~~		\|ispick
	\|Entry: ~~Contains~~ the ~~default summary text if the rule~~ is ~~not satisfied~~.<br>		\|Entry: Indicates whether the pre-requisite is being applied to a pick (non-zero) or thing (zero).<br>
	Exit: ~~Contains the final summary text to display if the rule is not satisfied~~.		Exit: Ignored.
	\|-		\|-
	\|}		\|}

Rob: New page: {{context|Kit Reference|Script Types}} ==Technical Details== :{| class="scripttable" |class="leftnormal"|Initial Context: |Pick |- |Alternate Context: |None |- |Fields F...

2008-12-14T09:25:51Z

New page: {{context|Kit Reference|Script Types}} ==Technical Details== :{| class="scripttable" |class="leftnormal"|Initial Context: |Pick |- |Alternate Context: |None |- |Fields F...

New page

{{context|Kit Reference|Script Types}}

==Technical Details==

:{| class="scripttable"
|class="leftnormal"|Initial Context:
|[[Pick Context|Pick]]
|-
|Alternate Context:
|None
|-
|Fields Finalized?
|No
|-
|}

The EvalRule script utilizes the following special symbols:

:{| class="infotable"
|class="leftnormal"|valid
|Entry: Assumed the rule is '''not''' satisfied with a value of zero.<br>
Exit: Indicates whether the rule is satisfied (non-zero) or not satisfied (zero).
|-
|message
|Entry: Contains the default message text if the rule is not satisfied.<br>
Exit: Contains the final message text to display if the rule is not satisfied.
|-
|summary
|Entry: Contains the default summary text if the rule is not satisfied.<br>
Exit: Contains the final summary text to display if the rule is not satisfied.
|-
|}

==Description==

The EvalRule script is very similar to an [[Eval Script|Eval script]], with the primary distinction being that the EvalRule script verifies a rule is observed instead of applying changes. This script is scheduled during the evaluation cycle, so it allows you to check the state of an actor at intermediate points in addition to at the end of evaluation. Intermediate checks make it possible to verify values before they are further modified by other aspects of the character.

An EvalRule script shares all the same behaviors of an Eval script, plus it adds the rule to be validated. The rule can be anything you want. However, the rule is always either satisfied or not satisfied. This is determined by the "valid" special symbol. The symbol starts out as zero, indicating that the rule is not satisfied. At any point during the script, you can set the symbol to non-zero, thereby indicating that the rule '''is''' satisfied. You can also change the symbol value throughout the script if you want. The only value that matters is the final value when the script ends, where a non-zero value indicates the script is satisfied.

If the validation test is not satisfied, the message and summary for the rule are displayed within the validation report and validation summary for the actor, respectively. Since the message and summary are typically static requirements (e.g. an attribute must be a value of X or more), you will rarely need to modify them. However, there will be cases where you want to tailor the message and/or summary to provide more detailed information based on dynamic information. When this situations arise, simply set the "message" and/or "summary" special values to the desired contents and they will be used.

Since an EvalRule script is equivalent to an Eval script, it '''is''' possible to apply changes throughout the structural hierarchy via the script. However, it is generally a bad idea to do that, since the purpose of an EvalRule script is to validate a rule - not effect change. We therefore recommend that you avoid applying changes within EvalRule scripts.

Like an Eval script, every EvalRule script is associated with a particular thing. If an EvalRule script is defined for component, then it is inherited by the things which derive from that component. When a thing is added to a container, it becomes a pick, and new instances of every EvalRule script for that thing are created and managed by HL. You associate all of the validation rules with each pick via the EvalRule scripts defined for the underlying thing.

When invoked, an Eval script starts with its associated pick as its initial context. You are free to navigate through the hierarchy and test the state of anything that impacts the rule. However, a given EvalRule script should will typically either pertain to the associated pick or pertain to the actor as a whole.

==Example==

An EvalRule script can be used to test virtually anything. Within the Sample data files, a rule is used to ensure that pieces of gear are not both equipped and held within a container (e.g. a sword being equipped and stored in a backpack). The rule below will verify this condition.

<pre>
~if not both equipped and held within a container, we're valid
if (field[grIsEquip].value + isgearheld < 2) then
@valid = 1
done
endif

~mark the tab as invalid
linkvalid = 0
</pre>