Difference between revisions of "Secondary Tag Expression"
| Line 3: | Line 3: | ||
The role of the Secondary tag expression is very different from most other tag expressions. 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 Secondary 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 role of the Secondary tag expression is very different from most other tag expressions. 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 Secondary 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 Secondary tag expression behaves just like a [[Container Tag Expression|Container tag expression]]. In fact, the name of the mechanism derives from its use, as it becomes a secondary container tag expression. | + | Once added to the pick, the Secondary tag expression behaves just like a [[Container Tag Expression|Container tag expression]]. In fact, the name of the mechanism derives from its use, as it becomes a secondary container tag expression. The Secondary tag expression must be satisfied in order for the pick to remain "live". If the tag expression stops being satisfied, the pick becomes non-live and is treated as if it no longer exists within the container. |
| + | The Secondary 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 Secondary tag expression is invoked every evaluation cycle at the timing specified. This means that the pick can transition between live and non-live in dynamic fashion, depending on changes that occur with the container. | ||
| + | |||
| + | It's also valid to omit the timing for a Secondary 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 Secondary tag expression within the [[Behavior Element (Data)|definition file]]. | ||
As a concrete example, consider the D&D 4th Edition game system. If the character selects the appropriate feats to multi-class, he may then choose powers from the new class. However, after those powers are added, what happens if the user deletes the multi-class feat? The separate table for selecting the additional powers disappears, so there is no way for the user to delete the powers. The easy solution is to assign a Secondary tag expression to the table of multi-class powers that ensures all powers added require that the character be multi-classed. This way, if the multi-class feat is deleted, all of those powers that rely on the feat will fail the Secondary tag expression and be treated as if they were never selected. | As a concrete example, consider the D&D 4th Edition game system. If the character selects the appropriate feats to multi-class, he may then choose powers from the new class. However, after those powers are added, what happens if the user deletes the multi-class feat? The separate table for selecting the additional powers disappears, so there is no way for the user to delete the powers. The easy solution is to assign a Secondary tag expression to the table of multi-class powers that ensures all powers added require that the character be multi-classed. This way, if the multi-class feat is deleted, all of those powers that rely on the feat will fail the Secondary tag expression and be treated as if they were never selected. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Latest revision as of 04:39, 7 December 2008
Context: HL Kit … Kit Reference … Tag Expression Types
The role of the Secondary tag expression is very different from most other tag expressions. 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 Secondary 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 Secondary tag expression behaves just like a Container tag expression. In fact, the name of the mechanism derives from its use, as it becomes a secondary container tag expression. The Secondary tag expression must be satisfied in order for the pick to remain "live". If the tag expression stops being satisfied, the pick becomes non-live and is treated as if it no longer exists within the container.
The Secondary 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 Secondary tag expression is invoked every evaluation cycle at the timing specified. This means that the pick can transition between live and non-live in dynamic fashion, depending on changes that occur with the container.
It's also valid to omit the timing for a Secondary 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 Secondary tag expression within the definition file.
As a concrete example, consider the D&D 4th Edition game system. If the character selects the appropriate feats to multi-class, he may then choose powers from the new class. However, after those powers are added, what happens if the user deletes the multi-class feat? The separate table for selecting the additional powers disappears, so there is no way for the user to delete the powers. The easy solution is to assign a Secondary tag expression to the table of multi-class powers that ensures all powers added require that the character be multi-classed. This way, if the multi-class feat is deleted, all of those powers that rely on the feat will fail the Secondary tag expression and be treated as if they were never selected.
