Difference between revisions of "Existence Tag Expression"

From HLKitWiki
Jump to: navigation, search
(New page: {{context|Kit Reference|Tag Expression Types}} The role of the Restriction tag expression is to further limit the set of things or picks that are made available for selection through a po...)
 
Line 1: Line 1:
 
{{context|Kit Reference|Tag Expression Types}}
 
{{context|Kit Reference|Tag Expression Types}}
  
The role of the Restriction tag expression is to further limit the set of things or picks that are made available for selection through a portal. It is always used in conjunction with a [[Candidate Tag Expression|Candidate tag expression]] and ensures that an item is only ever added to a table a single time. The Restriction tag expression is tested against all objects that are valid candidates for selection. If any of those objects also satisfies the Restriction tag expression '''and''' already exists as a pick within the target container, they are precluded from being added a second time and dropped from the selection list. This makes it possible to limit the user to only add an item once without having to designate the thing as unique.
+
The role of the Existence tag expression is very similar to the [[Secondary Tag Expression|Secondary tag expression]]. It is always used in conjunction with a portal that adds a pick to a container, such as a dynamic table or chooser. Instead of being processed as part of the portal, the tag expression is attached to the pick. When the pick is selected and added to the container, the Existence tag expression is also added to the new pick. At that point, the tag expression becomes part of the pick for the rest of the pick's existence.
  
The Restriction tag expression is always applied against the pick/thing itself. The tag expression is compared against all of the tags possessed by the object. For picks, this includes the effects of all dynamically assigned and deleted tags. The Restriction tag expression is only invoked when the user triggers the portal to display the list of options to choose from. Consequently, the tags used for picks are the final set of tags after evaluation completes. This also means that picks can dynamically change their state and change whether they appear as valid choices within a given portal.
+
Once added to the pick, the Existence tag expression governs whether the pick continues to exist within its container (hence the name). The Existence tag expression must be satisfied in order for the pick to continue its existence and avoid being automatically deleted. If the tag expression stops being satisfied, the pick is immediately deleted from the container, just as if the user had deleted it. This is a much more severe action than the Secondary tag expression, which simply causes the pick to go non-live. However, it is sometimes the better choice.
  
The best example of where the Restriction tag expression comes in handy is with the d20 System. In d20, many feats can be added via multiple mechanisms. There is the standard list of feats, plus various classes provide bonus feat selections. If a feat is added via one mechanism, then it needs to be precluded from being added via the other mechanisms. By using the Restriction tag expression, feats can be easily dropped from the other lists if they've already been added via any of the mechanisms.
+
The Existence tag expression is always applied against the container to which the pick was added. The tag expression is compared against all of the tags possessed by the container, which includes the effects of all dynamically assigned and deleted tags. The Existence tag expression is invoked every evaluation cycle at the timing specified. This means that the pick can fail the tag expression at any time, depending on changes that occur with the container. Once that occurs, the pick is automatically deleted in its entirety.
 +
 
 +
It's also valid to omit the timing for an Existence tag expression and use default timing. The default timing is Setup/5000. However, you can setup whatever you want as the default timing for the Existence tag expression within the [[Behavior Element (Data)|definition file]].

Revision as of 04:45, 7 December 2008

Context: HL KitKit Reference … Tag Expression Types 

The role of the Existence tag expression is very similar to the Secondary tag expression. It is always used in conjunction with a portal that adds a pick to a container, such as a dynamic table or chooser. Instead of being processed as part of the portal, the tag expression is attached to the pick. When the pick is selected and added to the container, the Existence tag expression is also added to the new pick. At that point, the tag expression becomes part of the pick for the rest of the pick's existence.

Once added to the pick, the Existence tag expression governs whether the pick continues to exist within its container (hence the name). The Existence tag expression must be satisfied in order for the pick to continue its existence and avoid being automatically deleted. If the tag expression stops being satisfied, the pick is immediately deleted from the container, just as if the user had deleted it. This is a much more severe action than the Secondary tag expression, which simply causes the pick to go non-live. However, it is sometimes the better choice.

The Existence tag expression is always applied against the container to which the pick was added. The tag expression is compared against all of the tags possessed by the container, which includes the effects of all dynamically assigned and deleted tags. The Existence tag expression is invoked every evaluation cycle at the timing specified. This means that the pick can fail the tag expression at any time, depending on changes that occur with the container. Once that occurs, the pick is automatically deleted in its entirety.

It's also valid to omit the timing for an Existence tag expression and use default timing. The default timing is Setup/5000. However, you can setup whatever you want as the default timing for the Existence tag expression within the definition file.