Other Language Statements - Revision history

Colen: /* "foreach actor in portfolio" */

2014-02-21T18:07:29Z

"foreach actor in portfolio"

← Older revision		Revision as of 18:07, 21 February 2014
Line 116:		Line 116:
	<pre>		<pre>
	foreach actor in portfolio where "group.tag"		foreach actor in portfolio where "group.tag"
	debug "name: " & eachpick.hero.~~name~~		debug "name: " & eachpick.hero.child[heroname].field[useredit].text
	nexteach		nexteach
	</pre>		</pre>

Rob: /* Perform Statement */

2009-03-09T11:11:27Z

Perform Statement

← Older revision		Revision as of 11:11, 9 March 2009
Line 12:		Line 12:
	</pre>		</pre>

	Declaring a variable in which to place a return value that you don't care about is unnecessary nuisance. So the scripting language provides the "perform" statement. The perform statement tells the compiler to invoke the operation that follows the statement and simply throw away the value returned. The above example changes to the code below when the "perform" statement is employed.		Declaring a variable in which to place a return value that you don't care about is an unnecessary nuisance. So the scripting language provides the "perform" statement. The perform statement tells the compiler to invoke the operation that follows the statement and simply throw away the value returned. The above example changes to the code below when the "perform" statement is employed.

	<pre>		<pre>

Rob: /* Debug Statements */

2009-03-09T11:08:35Z

Debug Statements

← Older revision		Revision as of 11:08, 9 March 2009
Line 38:		Line 38:
	</pre>		</pre>

	Using the debug statement requires that you utilize the info windows within HL. To view the debug output, go to the "~~Debug~~" menu within HL, select the "Floating Info Windows" option, and then select the "Show Debug Output" sub-option. This will display a window which contains the debug information that has been output from your scripts.		Using the debug statement requires that you utilize the info windows within HL. To view the debug output, go to the "Develop" menu within HL, select the "Floating Info Windows" option, and then select the "Show Debug Output" sub-option. This will display a window which contains the debug information that has been output from your scripts.

	As your scripts continue executing and the debug window fills up, the oldest information will be lost off the top to keep memory consumption to a minimum.		As your scripts continue executing and the debug window fills up, the oldest information will be lost off the top to keep memory consumption to a minimum.

Rob: /* Foreach Statement */

2009-02-20T00:31:53Z

Foreach Statement

← Older revision		Revision as of 00:31, 20 February 2009
Line 111:		Line 111:

	===="foreach actor in portfolio"====		===="foreach actor in portfolio"====

			This form of "foreach" iterates through the actors that exist within the portfolio, processing only those that satisfy the specified set of criteria. With this version, the "context" must always be the literal string "portfolio". The code within the "foreach" block is invoked for every actor in the portfolio that satisfies the optional tag expression. Within the "foreach" block, the current pick being iterated is always the "actor" pick for the current actor and can be accessed via the "eachpick." script context transition. The net result is that a typical use of this version of "foreach" looks like the code below.

			<pre>
			foreach actor in portfolio where "group.tag"
			debug "name: " & eachpick.hero.name
			nexteach
			</pre>

			The above code will iterate through all actors within the portfolio and identify all that possess the "group.tag" tag. The "debug" statement (see below) will then output the name of each actor that is processed by the "foreach" statement, since the "eachpick." script context specifies access to the current pick within the body of the loop and the parent actor is then used.

			{{note}}This mechanism is primarily intended for use within the Dashboard and Tactical Console, where all the actors must be managed appropriately.

	==Notify Statement==		==Notify Statement==

Rob: /* Foreach Statement */

2009-02-20T00:27:55Z

Foreach Statement

← Older revision		Revision as of 00:27, 20 February 2009
Line 97:		Line 97:

	===="foreach bootstrap in entity"====		===="foreach bootstrap in entity"====

			This form of "foreach" iterates through all things that are directly bootstrapped by an entity and satisfy any additional criteria. The "context" must always be the literal string "entity", and it limits this statement to use within things that possess a child entity. The code within the "foreach" block is invoked for every thing that is directly bootstrapped by the child entity that also satisfies the optional tag expression. This includes both bootstraps defined on the entity definition and via the "child" element that attaches the entity. Within the "foreach" block, the current bootstrap thing being iterated can be accessed via the "eachthing." script context transition. The net result is that a typical use of this version of "foreach" looks like the code below.

			<pre>
			foreach bootstrap in entity where "group.tag"
			debug "id: " & eachthing.idstring
			nexteach
			</pre>

			The above code iterates through all things that are bootstrapped by the child entity of the current thing/pick context and that possess the "group.tag" tag. The "debug" statement outputs the unique id of each thing that is processed by the "foreach" statement.

			{{note}}This mechanism is primarily intended for use within scripts that synthesize description text for a thing.

	===="foreach actor in portfolio"====		===="foreach actor in portfolio"====

Rob: /* Foreach Statement */

2009-02-20T00:24:07Z

Foreach Statement

@@ Line 71: / Line 71: @@
 ===="foreach thing in component"====
 ===="foreach bootstrap in thing"====
 ===="foreach bootstrap in entity"====

Rob at 00:10, 20 February 2009

2009-02-20T00:10:49Z

@@ Line 19: / Line 19: @@
 The net result is simpler, shorter, and clearer scripting code.
 ==Foreach Statement==
@@ Line 55: / Line 77: @@
 ===="foreach actor in portfolio"====
 ==Notify Statement==

Rob: /* Foreach Statement */

2009-02-20T00:09:57Z

Foreach Statement

← Older revision		Revision as of 00:09, 20 February 2009
Line 24:		Line 24:
	There will be times when you need to iterate through a collection of objects, separately processing each individual object within the collection. For example, you might want to iterate through all the weapons possessed by the character to determine how many "hands" worth of weapons are equipped by the character.		There will be times when you need to iterate through a collection of objects, separately processing each individual object within the collection. For example, you might want to iterate through all the weapons possessed by the character to determine how many "hands" worth of weapons are equipped by the character.

	In situations like this, the "foreach" statement provides the perfect solution. The foreach statement requires that you specify something to iterate over. The loop is terminated by the "nexteach" statement, resulting in the code within the foreach/nexteach block being invoked for every instance that satisfies the foreach criteria.		In situations like this, the "foreach" statement provides the perfect solution. The foreach statement requires that you specify something to iterate over. The loop is terminated by the "nexteach" statement, resulting in the code within the foreach/nexteach block being invoked for every instance that satisfies the foreach criteria. The net result is that a typical use of a foreach/nexteach block looks like the code below.

	~~Only~~ a ~~single form~~ of "foreach" statement ~~is currently~~ supported, and it iterates through the picks that have been added to a container, processing only those that satisfy a specified set of criteria. ~~This is accomplished by specifying a~~ container to be ~~processed and a tag expression~~ that identifies ~~the picks within the~~ container ~~to be processed~~. ~~A loop is generated that iterates through each pick within the container that satisfies the tag expression, resulting in the~~ code within the foreach~~/nexteach~~ block ~~being~~ invoked for every pick in the container that satisfies the tag expression. Within the foreach~~/nexteach~~ block, the current pick can be accessed via the "eachpick." script context. The net result is that a typical foreach~~/nexteach block~~ looks like the code below.		<pre>
			foreach item in context where tagexpr sortas sortset
			~code goes here
			nexteach
			</pre>

			In the above code, the "foreach" statement stipulates what type of object is to be iterated ("item"), followed by the "in" designation and an appropriate context to search within ("context"). An optional tag expression can be specified that restricts the set of items iterated through by specifying the "where" clause and a string that contains the tag expression ("tagexpr"). The list of items can also be sorted via use of the "sortas" clause that specifies the unique id of the sort set to be used ("sortset").

			There are multiple versions of the "foreach" statement that are supported. All versions work similarly, although each version iterates through a different assortment of items and context. The various versions are detailed in the sections below.

			===="foreach pick in container"====

			This form of "foreach" iterates through the picks that have been added to a container, processing only those that satisfy the specified set of criteria. With this version, the "context" must specify the container, which can be any valid context transition that identifies a container (e.g. "hero" or "child[pickid].gizmo"). The code within the "foreach" block is invoked for every pick in the container that satisfies the optional tag expression. Within the "foreach" block, the current pick being iterated can be accessed via the "eachpick." script context transition. The net result is that a typical use of this version of "foreach" looks like the code below.

	<pre>		<pre>
Line 34:		Line 46:
	</pre>		</pre>

	~~In the~~ above code, the "~~foreach~~" statement ~~stipulates what type~~ of ~~object is to be iterated (~~"~~pick~~"), ~~followed by~~ the "in" ~~designation and a valid container~~ script context ~~("hero"). The container context can be anything that is valid~~ within the ~~initial script context, so it can be "hero" or it could also be something like "child[pickid]~~.~~gizmo~~"~~. Once the container is given, the literal~~ "~~where" must be given, followed by a string expression that is treated as a tag expression and evaluated when the~~ "foreach" ~~statement is evaluated.~~		The above code will iterate through all picks within the hero and identify all that possess the "group.tag" tag. The "debug" statement (see below) will then output the unique id of each of the picks that are processed by the "foreach" statement, since the "eachpick." script context specifies access to the current pick within the body of the loop.

			===="foreach thing in component"====

			===="foreach bootstrap in thing"====

	~~The above code will iterate through all picks within the hero and identify all that possess the~~ "~~group.tag~~" ~~tag. The "debug" statement (see below) will then output the unique id of each of the picks that are processed by the~~ "foreach" ~~statement, since the "eachpick." script context specifies access to the current pick within the body of the loop.~~		===="foreach bootstrap in entity"====

			===="foreach actor in portfolio"====

	==Debug Statements==		==Debug Statements==

Rob: /* Trustme Statement */

2008-12-14T10:34:32Z

Trustme Statement

← Older revision		Revision as of 10:34, 14 December 2008
Line 103:		Line 103:

	{{important}}Whenever you think that you need to utilize the trustme statement, look closely at your script and what you're trying to do. It is rare that you should actually need to use trustme, and your data files probably can be better structured to eliminate the need for directly modifying a user field.		{{important}}Whenever you think that you need to utilize the trustme statement, look closely at your script and what you're trying to do. It is rare that you should actually need to use trustme, and your data files probably can be better structured to eliminate the need for directly modifying a user field.

			{{important}}The following script types are automatically designated as "trusted". This is because their general nature is such that you'll often be needing to modify user fields.

			*[[Trigger Script]]
			*[[Creation Script]]
			*[[TransactSetup Script]]
			*[[TransactBuy Script]]
			*[[TransactSell Script]]
			*[[Merge Script]]
			*[[Split Script]]
			*[[NewCombat Script]]
			*[[NewTurn Script]]
			*[[Integrate Script]]
			*[[Initiative Script]]
			*[[LoadFixup Script]]

Rob at 23:47, 13 December 2008

2008-12-13T23:47:03Z

← Older revision		Revision as of 23:47, 13 December 2008
Line 91:		Line 91:

	==Trustme Statement==		==Trustme Statement==

			As a general rule, scripts should not be directly modifying the contents of "user" fields. Those fields are intended for access only by the user, so attempts to modify them via scripts are inherently considered an error by the compiler. However, as with any rule, there are always the exceptions.

			When a script needs to modify the value of a user field, the "trustme" statement can be used. This tells the compiler that you know what you're doing and can be trusted to not do things inappropriately. Once specified within a script, the script becomes trusted and the compiler stops checking for code that modifies user fields.

			The syntax of the trustme statement is trivial. Simply place the statement on its own line within the script. There are no parameters, so it looks like below.

			<pre>
			trustme
			</pre>

			{{important}}Whenever you think that you need to utilize the trustme statement, look closely at your script and what you're trying to do. It is rare that you should actually need to use trustme, and your data files probably can be better structured to eliminate the need for directly modifying a user field.