Bootstraps

From HLKitWiki
Revision as of 03:30, 24 November 2008 by Rob (talk | contribs) (New page: {{context|Advanced Authoring Concepts}} There will be many situations where you want to add a pick to a container automatically. For example, you'll need to make sure that every actor sta...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Context: HL Kit … Advanced Authoring Concepts 

There will be many situations where you want to add a pick to a container automatically. For example, you'll need to make sure that every actor starts out with all of the attributes possessed by characters. You'll also want to re-use abilities, so you'll need to have one thing automatically add another thing.

Within the Kit, this process is referred to as "bootstrapping". Correspondingly, when you add a thing to a container automatically, the resulting pick is referred to as a "bootstrapped" pick. There are a number of important implications associated with bootstrapping, which are discussed in the topics below.

Things Bootstrapping Other Things

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.

Situations Where You Can Bootstrap

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.

Bootstrapping the Same Thing Multiple Times

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 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.

The Mechanics of Bootstrapping

Each thing that needs to be automatically added to each actor can be explicitly identified. This is accomplished via 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".