Bootstraps - Revision history

Rob: /* Conditional Bootstraps */

2008-12-07T09:05:21Z

Conditional Bootstraps

← Older revision		Revision as of 09:05, 7 December 2008
Line 56:		Line 56:
	There is another potential wrinkle with bootstraps. Some things can be added to different containers or under different circumstances. Depending on the situation, you may want the bootstrap to be added in some cases but omitted in others. For example, a special ability that is selected directly by the user for an actor may behave one way, while that same ability being added as a power within a magic item may behave a bit differently.		There is another potential wrinkle with bootstraps. Some things can be added to different containers or under different circumstances. Depending on the situation, you may want the bootstrap to be added in some cases but omitted in others. For example, a special ability that is selected directly by the user for an actor may behave one way, while that same ability being added as a power within a magic item may behave a bit differently.

	To accommodate special cases like this, a [[Container Tag Expression\|~~Condition~~ tag expression]] may be specified. This tag expression is applied to the '''prospective container''' for the new pick. If the container satisfies the condition test, then the bootstrap is added normally. However, if the container does not satisfy the test, no bootstrap is added.		To accommodate special cases like this, a [[Container Tag Expression\|Container tag expression]] may be specified. This tag expression is applied to the '''prospective container''' for the new pick. If the container satisfies the condition test, then the bootstrap is added normally. However, if the container does not satisfy the test, no bootstrap is added.

	The Condition test on bootstraps works differently from the Match tag expression. In addition to focusing on the container, the test is applied against tags that are dynamically assigned to that container. This means that the Condition test must be scheduled at a specific phase and priority during the evaluation cycle. Any tags that you wish to test for within the container must be handled prior to the timing of the Condition test.		The Condition test on bootstraps works differently from the Match tag expression. In addition to focusing on the container, the test is applied against tags that are dynamically assigned to that container. This means that the Condition test must be scheduled at a specific phase and priority during the evaluation cycle. Any tags that you wish to test for within the container must be handled prior to the timing of the Condition test.

Rob: /* Conditional Bootstraps */

2008-12-07T09:05:05Z

Conditional Bootstraps

← Older revision		Revision as of 09:05, 7 December 2008
Line 56:		Line 56:
	There is another potential wrinkle with bootstraps. Some things can be added to different containers or under different circumstances. Depending on the situation, you may want the bootstrap to be added in some cases but omitted in others. For example, a special ability that is selected directly by the user for an actor may behave one way, while that same ability being added as a power within a magic item may behave a bit differently.		There is another potential wrinkle with bootstraps. Some things can be added to different containers or under different circumstances. Depending on the situation, you may want the bootstrap to be added in some cases but omitted in others. For example, a special ability that is selected directly by the user for an actor may behave one way, while that same ability being added as a power within a magic item may behave a bit differently.

	To accommodate special cases like this, a [[~~Condition~~ Tag Expression\|Condition tag expression]] may be specified. This tag expression is applied to the '''prospective container''' for the new pick. If the container satisfies the condition test, then the bootstrap is added normally. However, if the container does not satisfy the test, no bootstrap is added.		To accommodate special cases like this, a [[Container Tag Expression\|Condition tag expression]] may be specified. This tag expression is applied to the '''prospective container''' for the new pick. If the container satisfies the condition test, then the bootstrap is added normally. However, if the container does not satisfy the test, no bootstrap is added.

	The Condition test on bootstraps works differently from the Match tag expression. In addition to focusing on the container, the test is applied against tags that are dynamically assigned to that container. This means that the Condition test must be scheduled at a specific phase and priority during the evaluation cycle. Any tags that you wish to test for within the container must be handled prior to the timing of the Condition test.		The Condition test on bootstraps works differently from the Match tag expression. In addition to focusing on the container, the test is applied against tags that are dynamically assigned to that container. This means that the Condition test must be scheduled at a specific phase and priority during the evaluation cycle. Any tags that you wish to test for within the container must be handled prior to the timing of the Condition test.

Rob: /* The Mechanics of Bootstrapping */

2008-11-24T12:21:18Z

The Mechanics of Bootstrapping

← Older revision		Revision as of 12:21, 24 November 2008
Line 40:		Line 40:
	==The Mechanics of Bootstrapping==		==The Mechanics of Bootstrapping==

	The process of bootstrapping a thing is accomplished via ~~the~~ [[Bootstrap Element (Data)\|the "bootstrap" element]]. Since there are a variety of places where bootstrapping can be performed, this element is re-used throughout the Kit.		The process of bootstrapping a thing is typically accomplished via [[Bootstrap Element (Data)\|the "bootstrap" element]]. Since there are a variety of places where bootstrapping can be performed, this element is re-used throughout the Kit.

	~~At a minimum,~~ the "~~bootstrap~~" element ~~requires you to specify~~ the ~~unique id~~ of ~~the specific thing to be added. You may also specify tags that will be automatically assigned to the pick when it is added~~.		You can also bootstrap things via [[AutoAdd Element (Data)\|the "autoadd" element]] and [[EnMasse Element (Data)\|the "enmasse" element]]. Both of those elements are exclusively used within structural files.

	==Component Bootstraps==		==Component Bootstraps==

Rob: /* Conditional Bootstraps */

2008-11-24T10:41:57Z

Conditional Bootstraps

← Older revision		Revision as of 10:41, 24 November 2008
Line 58:		Line 58:
	To accommodate special cases like this, a [[Condition Tag Expression\|Condition tag expression]] may be specified. This tag expression is applied to the '''prospective container''' for the new pick. If the container satisfies the condition test, then the bootstrap is added normally. However, if the container does not satisfy the test, no bootstrap is added.		To accommodate special cases like this, a [[Condition Tag Expression\|Condition tag expression]] may be specified. This tag expression is applied to the '''prospective container''' for the new pick. If the container satisfies the condition test, then the bootstrap is added normally. However, if the container does not satisfy the test, no bootstrap is added.

	The Condition test on bootstraps works differently from the Match tag expression. In addition to focusing on the container, the test is applied against tags that are dynamically assigned to that container. This means that the Condition test must be scheduled at a specific phase and priority during the evaluation cycle.		The Condition test on bootstraps works differently from the Match tag expression. In addition to focusing on the container, the test is applied against tags that are dynamically assigned to that container. This means that the Condition test must be scheduled at a specific phase and priority during the evaluation cycle. Any tags that you wish to test for within the container must be handled prior to the timing of the Condition test.

			{{important}}All tasks that operate upon a pick must occur '''after''' any bootstrap Condition tests for the pick. This includes all component scripts. If a task is determined to be scheduled prior to the Condition test, an error will be reported.

			{{important}}Within the Condition test, it is valid to test field values, but the source from which these field values are retrieved will vary. The handling of each possible situation is outlined below.
	~~-The "live"~~ test ~~performed for a bootstrap provides~~ the ~~reference pick~~ of the		*If the bootstrap is being added by another pick, all field value tests are applied to the root pick that is performing the bootstrap.
	bootstrap ~~for use in testing field values within the tagexpr~~		*If the bootstrap is being added by a gizmo, then all field value tests are applied to the anchor pick that attaches the gizmo.
	~~-All~~ field value tests ~~in the tagexpr~~ are applied to the ~~reference~~ pick that		*If the bootstrap is added by a minion, the field value tests are applied to the master pick that attaches the minion.
	~~chains to~~ the ~~pick whose live state~~ is being ~~updated~~		*For global bootstraps that are applied to every actor, no field value tests may be utilized, as there is nothing to compare against.
	~~-The author is responsible for ensuring~~ field ~~values~~ are ~~only tested for picks~~		*In all cases, the author is responsible for ensuring that only field values that properly exist are tested, since attempts to access missing fields will result in an error being reported.
	~~that actually have reference picks, since global bootstraps possess no~~
	~~reference pick and attempts~~ to ~~access missing fields will report an error~~

	~~-The "live" tag expression of bootstraps is special for gizmos and minions~~
	~~-The "live" tagexpr normally uses the reference pick that attaches bootstrap,~~
	~~but gizmos and minions don't have a normal reference pick~~
	~~-Gizmos use~~ the pick that attaches the gizmo ~~as a special bootstrap reference~~
	~~-Minions use~~ the ~~anchor/master pick as a special~~ bootstrap ~~reference~~
	~~-Provides~~ a ~~suitable target for use of "fieldval" within bootstrap tagexpr~~

	~~-The timing of all bootstrap condition tests is properly factored into~~ the
	~~determination of the "latest" condition timing for each thing~~
	~~-If a bootstrap condition test occurs latest than other condition~~ tests ~~for~~
	~~a given thing,~~ the ~~"latest" timing for~~ that ~~thing uses~~ the ~~new timing~~
	~~-Ensures~~ that ~~the final condition test~~ is ~~scheduled late enough~~ to ~~properly~~
	~~incorporate~~ the ~~effects of all bootstrap condition tests~~
	~~-Ensures~~ that ~~any scripts scheduled to be processed earlier than bootstrap~~
	~~condition tests are~~ properly ~~flagged as a conflict during compilation~~

	~~-Condition tests~~ are ~~not allowed for bootstraps on entities and rulesets~~

Rob: /* Component Bootstraps */

2008-11-24T10:24:31Z

Component Bootstraps

← Older revision		Revision as of 10:24, 24 November 2008
Line 49:		Line 49:

	In these situations, a [[Match Tag Expression\|Match tag expression]] can be specified with the bootstrap. This tag expression is applied to each '''thing''' derived from the component. Only the things that satisfy the tag expression are assigned the bootstrap. Note that the tag expression is tested against the tags possessed by each thing, so each thing uniquely controls whether it does or does not receive the bootstrap. This also means that only the initial tags each thing possesses are tested.		In these situations, a [[Match Tag Expression\|Match tag expression]] can be specified with the bootstrap. This tag expression is applied to each '''thing''' derived from the component. Only the things that satisfy the tag expression are assigned the bootstrap. Note that the tag expression is tested against the tags possessed by each thing, so each thing uniquely controls whether it does or does not receive the bootstrap. This also means that only the initial tags each thing possesses are tested.

			{{important}}If a component bootstrap does '''not''' specify a Match tag expression, the bootstrap is automatically considered a match to all things derived from the component and assigned to all of them.

	==Conditional Bootstraps==		==Conditional Bootstraps==

Rob: /* Conditional Bootstraps */

2008-11-24T10:23:17Z

Conditional Bootstraps

← Older revision		Revision as of 10:23, 24 November 2008
Line 59:		Line 59:



	~~-Bootstrap tagexprs are now properly handled for all picks~~
	~~-Condition test is performed at the specified phase/priority~~
	~~-Condition test is ignored when specified on rulesets and entities~~
	~~-Condition test is performed against tags on the container~~

	~~-Bootstraps can be defined for components~~
	~~-Inherited by all things that derive from the component~~
	~~-Specify a "match" tagexpr that restricts which things the bootstrap is applied to~~

	-The "live" test performed for a bootstrap provides the reference pick of the		-The "live" test performed for a bootstrap provides the reference pick of the
Line 76:		Line 67:
	that actually have reference picks, since global bootstraps possess no		that actually have reference picks, since global bootstraps possess no
	reference pick and attempts to access missing fields will report an error		reference pick and attempts to access missing fields will report an error
	~~-If no 'match' test is present on component bootstraps, the bootstrap is now~~
	~~applied. This is a change from the previous behaviour, where it was not~~
	~~applied.~~

	-The "live" tag expression of bootstraps is special for gizmos and minions		-The "live" tag expression of bootstraps is special for gizmos and minions

Rob at 10:21, 24 November 2008

2008-11-24T10:21:40Z

← Older revision		Revision as of 10:21, 24 November 2008
Line 43:		Line 43:

	At a minimum, the "bootstrap" element requires you to specify the unique id of the specific thing to be added. You may also specify tags that will be automatically assigned to the pick when it is added.		At a minimum, the "bootstrap" element requires you to specify the unique id of the specific thing to be added. You may also specify tags that will be automatically assigned to the pick when it is added.

			==Component Bootstraps==

			The vast majority of bootstraps are simple. The bootstrap is always performed for the source context it is defined within. However, bootstraps on components are sometimes an exception. A bootstrap definition on a component will be inherited by all things derived from that component. However, you may only want the bootstrap to be applied to '''most''' of those things, with some not having the bootstrap.

			In these situations, a [[Match Tag Expression\|Match tag expression]] can be specified with the bootstrap. This tag expression is applied to each '''thing''' derived from the component. Only the things that satisfy the tag expression are assigned the bootstrap. Note that the tag expression is tested against the tags possessed by each thing, so each thing uniquely controls whether it does or does not receive the bootstrap. This also means that only the initial tags each thing possesses are tested.

	==Conditional Bootstraps==		==Conditional Bootstraps==

	~~==Component Bootstraps==~~		There is another potential wrinkle with bootstraps. Some things can be added to different containers or under different circumstances. Depending on the situation, you may want the bootstrap to be added in some cases but omitted in others. For example, a special ability that is selected directly by the user for an actor may behave one way, while that same ability being added as a power within a magic item may behave a bit differently.

	The vast majority of bootstraps are simple. The bootstrap is always performed for the source context it is defined within. However, there are some situations where you want the bootstrap to only be applicable under certain circumstances. For example, a ~~bootstrap definition on a component will~~ be ~~inherited by all things derived from that component~~. ~~However, you may only want the bootstrap to be~~ applied to '''~~most~~''' ~~of those things~~, ~~with some~~ not ~~having~~ the bootstrap.		To accommodate special cases like this, a [[Condition Tag Expression\|Condition tag expression]] may be specified. This tag expression is applied to the '''prospective container''' for the new pick. If the container satisfies the condition test, then the bootstrap is added normally. However, if the container does not satisfy the test, no bootstrap is added.

	In ~~these situations~~, ~~a [[Condition Tag Expression\|~~Condition ~~tag expression]] may~~ be ~~specified~~.		The Condition test on bootstraps works differently from the Match tag expression. In addition to focusing on the container, the test is applied against tags that are dynamically assigned to that container. This means that the Condition test must be scheduled at a specific phase and priority during the evaluation cycle.

	~~phase and priority for condition test~~

	~~match tagexpr~~

	-Bootstrap tagexprs are now properly handled for all picks		-Bootstrap tagexprs are now properly handled for all picks

Rob at 10:04, 24 November 2008

2008-11-24T10:04:28Z

@@ Line 19: / Line 19: @@
 *Things can be bootstrapped onto entities when they are attached. The bootstrapped picks are only included on gizmos created by that thing.
 *Things can be bootstrapped onto minions when they are attached. The bootstrapped picks are only included on minions created by that thing.
 ==Bootstrapping the Same Thing Multiple Times==
@@ Line 37: / Line 43: @@
 At a minimum, the "bootstrap" element requires you to specify the unique id of the specific thing to be added. You may also specify tags that will be automatically assigned to the pick when it is added.
 The vast majority of bootstraps are simple. The bootstrap is always performed for the source context it is defined within. However, there are some situations where you want the bootstrap to only be applicable under certain circumstances. For example, a bootstrap definition on a component will be inherited by all things derived from that component. However, you may only want the bootstrap to be applied to '''most''' of those things, with some not having the bootstrap.
@@ Line 45: / Line 55: @@
 match tagexpr
 -Bootstrap tagexprs are now properly handled for all picks
@@ Line 63: / Line 60: @@
      -Condition test is ignored when specified on rulesets and entities
      -Condition test is performed against tags on the container
 -Bootstraps can be defined for components

Rob: /* The Mechanics of Bootstrapping */

2008-11-24T09:45:50Z

The Mechanics of Bootstrapping

@@ Line 40: / Line 40: @@
 The vast majority of bootstraps are simple. The bootstrap is always performed for the source context it is defined within. However, there are some situations where you want the bootstrap to only be applicable under certain circumstances. For example, a bootstrap definition on a component will be inherited by all things derived from that component. However, you may only want the bootstrap to be applied to '''most''' of those things, with some not having the bootstrap.
-In these situations, a Condition tag expression may be specified.
+In these situations, a [[Condition Tag Expression|Condition tag expression]] may be specified.
 phase and priority for condition test
 match tagexpr

Rob: /* The Mechanics of Bootstrapping */

2008-11-24T04:29:27Z

The Mechanics of Bootstrapping

← Older revision		Revision as of 04:29, 24 November 2008
Line 38:		Line 38:
	At a minimum, the "bootstrap" element requires you to specify the unique id of the specific thing to be added. You may also specify tags that will be automatically assigned to the pick when it is added.		At a minimum, the "bootstrap" element requires you to specify the unique id of the specific thing to be added. You may also specify tags that will be automatically assigned to the pick when it is added.

	~~When~~ you ~~add a thing~~ to a ~~container via~~ a "bootstrap~~" element~~, the ~~resulting pick is referred to as a "bootstrapped" pick~~. ~~Correspondingly~~, ~~the overall process is referred to as "bootstrapping"~~.		The vast majority of bootstraps are simple. The bootstrap is always performed for the source context it is defined within. However, there are some situations where you want the bootstrap to only be applicable under certain circumstances. For example, a bootstrap definition on a component will be inherited by all things derived from that component. However, you may only want the bootstrap to be applied to '''most''' of those things, with some not having the bootstrap.

			In these situations, a Condition tag expression may be specified.

			phase and priority for condition test

			match tagexpr