Automatically Adding Picks to Actors - Revision history

Rob at 12:37, 24 November 2008

2008-11-24T12:37:12Z

← Older revision		Revision as of 12:37, 24 November 2008
Line 7:		Line 7:
	So what about all of the various details that are a fundamental part of every actor? Every actor clearly needs to possess all of the basic attributes for the game system (e.g. strength, intelligence, etc.). In most games, the set of skills is pre-set, so those should be part of each actor, too. Every game system has its own unique set of things that should be a basic part of each actor. However, the Kit has no way of knowing what those particular things are for each game system.		So what about all of the various details that are a fundamental part of every actor? Every actor clearly needs to possess all of the basic attributes for the game system (e.g. strength, intelligence, etc.). In most games, the set of skills is pre-set, so those should be part of each actor, too. Every game system has its own unique set of things that should be a basic part of each actor. However, the Kit has no way of knowing what those particular things are for each game system.

	To deal with this, the Kit provides three separate mechanisms for specifying which things should be automatically added to every actor. Each mechanism works slightly differently and is intended for use ~~with~~ different ~~types of things~~. Together, they should make it easy for you to pre-configure every actor with all of the picks that is needs. The topics below describe each of these mechanisms.		To deal with this, the Kit provides three separate mechanisms for specifying which things should be automatically added to every actor. Each mechanism works slightly differently and is intended for use in different situations. Together, they should make it easy for you to pre-configure every actor with all of the picks that it needs. The topics below describe each of these mechanisms.

	~~==Bootstrapping Behaviors==~~

	Whenever you add a thing to a container automatically, the resulting pick is referred to as a "bootstrapped" pick. Correspondingly, the overall process is referred to as "bootstrapping", and there are a number of important implications associated with bootstrapping.

	You can bootstrap picks from a variety of situations. The most common situation will be when you have one thing bootstrap another. This will occur when the game system has an assortment of abilities that are conferred by a variety of sources. For example, consider the "low-light vision" ability within the d20 System. This ability is conferred by multiple different races. You could separately implement this ability for each race, but it would be much easier to define the ability once and have each race simply bootstrap that ability.

	When a pick is bootstrapped by another pick, the pick that does the bootstrapping is referred to as the "root" pick. The root pick has complete control control of the bootstrapped pick. If the root pick is deleted, the bootstrapped pick is also deleted. If the root pick goes non-live, so does the bootstrapped pick. The bootstrapped pick still has its own independent existence, but that state is wholly dependent upon the root pick as well.

	This raises the question of what happens when the same thing is bootstrapped multiple times by different root picks. The answer depends on whether the thing is [[Uniqueness of Things\|designated as being unique]]. If not, then separate, independent picks are added by each root, and their behaviors are not linked in any way. However, if the thing is designated as unique, then only one pick is ever added, and all of the bootstrap operations will reference the identical pick. As long as at least one of the root picks remains in existence, so will the bootstrapped pick.

	There are a number of other situations in which bootstrapping of things can be performed. These situations are outlined below. In each of these cases, the dependency relationships outlined above do not apply.

	*Things can be bootstrapped onto all actors when the actor is initially created.
	*Things can be bootstrapped onto entities as part of the entity's definition. The bootstrapped picks are part of every gizmo created from that entity.
	*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.

	==Adding Individual Things==		==Adding Individual Things==

	Each thing that needs to be automatically added to each actor can be explicitly ~~identified~~. This is accomplished via [[Bootstrap Element (Data)\|the "bootstrap" element]] within a structural file. This element allows you to specify the unique id of the specific thing to be added.		Each thing that needs to be automatically added to each actor can be explicitly specified. This is accomplished via [[Bootstrap Element (Data)\|the "bootstrap" element]] within a structural file. This element allows you to specify the unique id of the specific thing to be 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"~~.

	~~You can bootstrap picks from~~ a ~~variety~~ of ~~situations~~.		There are quite a few implications associated the bootstrapping a thing into an actor. If you have not yet done so, now would be an excellent time to familiarize yourself with all the particulars of [[Bootstraps\|bootstrapping things into containers]].

	==Adding Groups of Related Things==		==Adding Groups of Related Things==

Rob: /* Pre-Selecting Things Within Tables and Choosers */

2008-11-24T10:00:34Z

Pre-Selecting Things Within Tables and Choosers

← Older revision		Revision as of 10:00, 24 November 2008
Line 46:		Line 46:
	==Pre-Selecting Things Within Tables and Choosers==		==Pre-Selecting Things Within Tables and Choosers==

	The above mechanisms allow you to add things to an actor on a fixed basis. This is perfect for attributes and skills, but it doesn't solve all situations. Throughout the interface you design, there will be various tables and choosers where you'll want to pre-select information for the user.		The above mechanisms allow you to add things to an actor on a fixed basis. This is perfect for attributes and skills, but it doesn't solve all situations. Throughout the interface you design, there will be various tables and choosers where you'll want to pre-select information for the user. In this situations, the user is free to delete or replace the default selection, but one is still provided.

	An obvious example is adding an empty character portrait on the Personal tab, since this visually prompts the user to select a portrait of his choice. Another possible situation is when you want to pre-select the contents of a chooser. For example, in the World of Darkness system, the vast majority of characters start out as standard humans, so it's appropriate to pre-select the characters size and speed traits as those of a human. The user is free to change the choices, but he doesn't have to always select them for each new character.		An obvious example is adding an empty character portrait on the Personal tab, since this visually prompts the user to select a portrait of his choice. Another possible situation is when you want to pre-select the contents of a chooser. For example, in the World of Darkness system, the vast majority of characters start out as standard humans, so it's appropriate to pre-select the characters size and speed traits as those of a human. The user is free to change the choices, but he doesn't have to always select them for each new character.

	When you come upon a situation where you want to pre-select a thing into a table or chooser, you can use [[AutoAdd Element (Data)\|the "autoadd" element]] within a structural file. This element allows you to specify both the unique id of the thing to be added and the unique id of the portal it is added to.		When you come upon a situation where you want to pre-select a thing into a table or chooser, you can use [[AutoAdd Element (Data)\|the "autoadd" element]] within a structural file. This element allows you to specify both the unique id of the thing to be added and the unique id of the portal it is added to.

			Any pick that is automatically added to a portal is solely subject to the behaviors for that portal. As such, the pick may not has any Condition tag expression associated with it. In addition, all auto-tags and conditions (e.g. Secondary and Existence) that are normally dictated by the portal are also applied to the pick.

Rob at 03:14, 24 November 2008

2008-11-24T03:14:07Z

← Older revision		Revision as of 03:14, 24 November 2008
Line 8:		Line 8:

	To deal with this, the Kit provides three separate mechanisms for specifying which things should be automatically added to every actor. Each mechanism works slightly differently and is intended for use with different types of things. Together, they should make it easy for you to pre-configure every actor with all of the picks that is needs. The topics below describe each of these mechanisms.		To deal with this, the Kit provides three separate mechanisms for specifying which things should be automatically added to every actor. Each mechanism works slightly differently and is intended for use with different types of things. Together, they should make it easy for you to pre-configure every actor with all of the picks that is needs. The topics below describe each of these mechanisms.

			==Bootstrapping Behaviors==

			Whenever you add a thing to a container automatically, the resulting pick is referred to as a "bootstrapped" pick. Correspondingly, the overall process is referred to as "bootstrapping", and there are a number of important implications associated with bootstrapping.

			You can bootstrap picks from a variety of situations. The most common situation will be when you have one thing bootstrap another. This will occur when the game system has an assortment of abilities that are conferred by a variety of sources. For example, consider the "low-light vision" ability within the d20 System. This ability is conferred by multiple different races. You could separately implement this ability for each race, but it would be much easier to define the ability once and have each race simply bootstrap that ability.

			When a pick is bootstrapped by another pick, the pick that does the bootstrapping is referred to as the "root" pick. The root pick has complete control control of the bootstrapped pick. If the root pick is deleted, the bootstrapped pick is also deleted. If the root pick goes non-live, so does the bootstrapped pick. The bootstrapped pick still has its own independent existence, but that state is wholly dependent upon the root pick as well.

			This raises the question of what happens when the same thing is bootstrapped multiple times by different root picks. The answer depends on whether the thing is [[Uniqueness of Things\|designated as being unique]]. If not, then separate, independent picks are added by each root, and their behaviors are not linked in any way. However, if the thing is designated as unique, then only one pick is ever added, and all of the bootstrap operations will reference the identical pick. As long as at least one of the root picks remains in existence, so will the bootstrapped pick.

			There are a number of other situations in which bootstrapping of things can be performed. These situations are outlined below. In each of these cases, the dependency relationships outlined above do not apply.

			*Things can be bootstrapped onto all actors when the actor is initially created.
			*Things can be bootstrapped onto entities as part of the entity's definition. The bootstrapped picks are part of every gizmo created from that entity.
			*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.

	==Adding Individual Things==		==Adding Individual Things==

Rob: /* Adding Individual Things */

2008-11-24T02:43:53Z

Adding Individual Things

← Older revision		Revision as of 02:43, 24 November 2008
Line 12:		Line 12:

	Each thing that needs to be automatically added to each actor can be explicitly identified. This is accomplished via [[Bootstrap Element (Data)\|the "bootstrap" element]] within a structural file. This element allows you to specify the unique id of the specific thing to be added.		Each thing that needs to be automatically added to each actor can be explicitly identified. This is accomplished via [[Bootstrap Element (Data)\|the "bootstrap" element]] within a structural file. This element allows you to specify the unique id of the specific thing to be 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".

			You can bootstrap picks from a variety of situations.

	==Adding Groups of Related Things==		==Adding Groups of Related Things==

Rob at 01:44, 24 November 2008

2008-11-24T01:44:25Z

← Older revision		Revision as of 01:44, 24 November 2008
Line 8:		Line 8:

	To deal with this, the Kit provides three separate mechanisms for specifying which things should be automatically added to every actor. Each mechanism works slightly differently and is intended for use with different types of things. Together, they should make it easy for you to pre-configure every actor with all of the picks that is needs. The topics below describe each of these mechanisms.		To deal with this, the Kit provides three separate mechanisms for specifying which things should be automatically added to every actor. Each mechanism works slightly differently and is intended for use with different types of things. Together, they should make it easy for you to pre-configure every actor with all of the picks that is needs. The topics below describe each of these mechanisms.

			==Adding Individual Things==

			Each thing that needs to be automatically added to each actor can be explicitly identified. This is accomplished via [[Bootstrap Element (Data)\|the "bootstrap" element]] within a structural file. This element allows you to specify the unique id of the specific thing to be added.

	==Adding Groups of Related Things==		==Adding Groups of Related Things==
Line 13:		Line 17:
	As mentioned above, each game has groups of things that should all be added to each actor. Attributes, skills, saving throws, and other traits are perfect examples. Adding these things individually would be both tedious and error prone. It would also make it more difficult for others to extend the data files by adding their own custom traits, because they would have to manually add any new things they defined.		As mentioned above, each game has groups of things that should all be added to each actor. Attributes, skills, saving throws, and other traits are perfect examples. Adding these things individually would be both tedious and error prone. It would also make it more difficult for others to extend the data files by adding their own custom traits, because they would have to manually add any new things they defined.

	As long as a group of things can be readily identified by tags they share in common, you have them all automatically added ~~via~~ a single operation. Since all related traits typically derive from the same component, and since every thing possesses a tag for each component it derives from, this requirement is usually a non-issue.		As long as a group of things can be readily identified by tags they share in common, you have them all automatically added in a single operation. Since all related traits typically derive from the same component, and since every thing possesses a tag for each component it derives from, this requirement is usually a non-issue.

	To specify a group of related ~~tags~~ that should be added to every actor, use [[EnMasse Element (Data)\|the "enmasse" element]] within a structural file.		To specify a group of related things that should be added to every actor, use [[EnMasse Element (Data)\|the "enmasse" element]] within a structural file. This element allows you to specify a tag expression that will identify the related things to be added.

			You can also specify tags that will be automatically assigned to each added pick. While rarely needed, this can be useful when the same thing can be also added to the actor additional times by the user.

	**Enmasse		==Pre-Selecting Things Within Tables and Choosers==

	==~~Adding Individual~~ Things==

	**Bootstrap		The above mechanisms allow you to add things to an actor on a fixed basis. This is perfect for attributes and skills, but it doesn't solve all situations. Throughout the interface you design, there will be various tables and choosers where you'll want to pre-select information for the user.

	~~==Pre~~-~~Selecting Things Within Choosers==~~		An obvious example is adding an empty character portrait on the Personal tab, since this visually prompts the user to select a portrait of his choice. Another possible situation is when you want to pre-select the contents of a chooser. For example, in the World of Darkness system, the vast majority of characters start out as standard humans, so it's appropriate to pre-select the characters size and speed traits as those of a human. The user is free to change the choices, but he doesn't have to always select them for each new character.

	**Auto-~~add~~		When you come upon a situation where you want to pre-select a thing into a table or chooser, you can use [[AutoAdd Element (Data)\|the "autoadd" element]] within a structural file. This element allows you to specify both the unique id of the thing to be added and the unique id of the portal it is added to.

Rob at 01:13, 24 November 2008

2008-11-24T01:13:39Z

← Older revision		Revision as of 01:13, 24 November 2008
Line 9:		Line 9:
	To deal with this, the Kit provides three separate mechanisms for specifying which things should be automatically added to every actor. Each mechanism works slightly differently and is intended for use with different types of things. Together, they should make it easy for you to pre-configure every actor with all of the picks that is needs. The topics below describe each of these mechanisms.		To deal with this, the Kit provides three separate mechanisms for specifying which things should be automatically added to every actor. Each mechanism works slightly differently and is intended for use with different types of things. Together, they should make it easy for you to pre-configure every actor with all of the picks that is needs. The topics below describe each of these mechanisms.

	==Adding Groups of Related ~~Picks~~==		==Adding Groups of Related Things==

			As mentioned above, each game has groups of things that should all be added to each actor. Attributes, skills, saving throws, and other traits are perfect examples. Adding these things individually would be both tedious and error prone. It would also make it more difficult for others to extend the data files by adding their own custom traits, because they would have to manually add any new things they defined.

			As long as a group of things can be readily identified by tags they share in common, you have them all automatically added via a single operation. Since all related traits typically derive from the same component, and since every thing possesses a tag for each component it derives from, this requirement is usually a non-issue.

			To specify a group of related tags that should be added to every actor, use [[EnMasse Element (Data)\|the "enmasse" element]] within a structural file.


	**Enmasse		**Enmasse

	==Adding Individual ~~Picks~~==		==Adding Individual Things==

	**Bootstrap		**Bootstrap

	==Pre-Selecting ~~Picks~~ Within Choosers==		==Pre-Selecting Things Within Choosers==

	**Auto-add		**Auto-add

Rob: New page: {{context|Advanced Authoring Concepts}} ==Overview== When a new actor is created, it is a virtually empty container. Exactly one thing is automatically added to each actor. It's the "act...

2008-11-24T01:04:07Z

New page: {{context|Advanced Authoring Concepts}} ==Overview== When a new actor is created, it is a virtually empty container. Exactly one thing is automatically added to each actor. It's the "act...

New page

{{context|Advanced Authoring Concepts}}

==Overview==

When a new actor is created, it is a virtually empty container. Exactly one thing is automatically added to each actor. It's the "actor" thing that is automatically created for you by the Kit. Other than that, an actor is empty.

So what about all of the various details that are a fundamental part of every actor? Every actor clearly needs to possess all of the basic attributes for the game system (e.g. strength, intelligence, etc.). In most games, the set of skills is pre-set, so those should be part of each actor, too. Every game system has its own unique set of things that should be a basic part of each actor. However, the Kit has no way of knowing what those particular things are for each game system.

To deal with this, the Kit provides three separate mechanisms for specifying which things should be automatically added to every actor. Each mechanism works slightly differently and is intended for use with different types of things. Together, they should make it easy for you to pre-configure every actor with all of the picks that is needs. The topics below describe each of these mechanisms.

==Adding Groups of Related Picks==

**Enmasse

==Adding Individual Picks==

**Bootstrap

==Pre-Selecting Picks Within Choosers==

**Auto-add