Most of the constraint terms in the addressing dialogs for a module, slat, pin or rack are attributes of effects. The standard meaning of a constraint of the form “Module restricted to single X” is that every effect fired from a specific module must have the same value for the attribute X, whatever X is — Size, Part Number, Position, etc. Loosely speaking, this standard meaning applies to all the constraint terms, but there are are few constraint terms that are not attributes of the effects or that work slightly differently. These are the “Special” constraint terms. They have meanings that are consistent with the standard meaning but require a customized implementation to do what people expect. These special terms are listed in Table 1.
Table 1 – “Special” constraint terms in the addressing dialogs
| Constraint | Meaning |
| Angle | Loosely speaking, this constraint requires that the effects have the same orientation. The orientation of an effect is defined by Euler angles Pan, Tilt, and Spin. All three Euler angles must be the same for the Angle constraint to be satisfied. |
| Angle-Or-Not | Loosely speaking, this constraint requires that effects are all straight up, or all angled, though the specific angles can vary. Ignoring Pan, an effect is considered to be “at an angle” if its Tilt or Spin Euler angle is non-zero. The constraint is satisfied for collections of effects that are either all at an angle or all not at an angle (independent of what the angle is). |
| Angle-Plus-Minus | Loosely speaking, this constraint requires that angles are leaning in one direction or the other or are straight up, though the specific angles can vary. The first Euler angle (Pan, Tilt or Spin) that has a non-zero value for an effect determines its “angle plus/minus/zero,” based on the sign of the angle. If all the Euler angles are zero, then the “angle plus/minus/zero” is zero. The “Angle-Plus-Minus” constraint is satisfied for a collection of effects if all of them have the same “angle plus/minus/zero.” |
| Chain | This constraint requires that all effects are in the same chain, or all effects are not in a chain. |
| Chain-Or-Not | This constraint requires that all effects are in chains (not necessarily the same chain), or all effects are not in a chain. |
| Custom Script Field, Custom Part Field, Custom Numeric Field, Custom Position Field | These constraints refer to properties displayed in the Script window for which blank values can be interpreted as wildcards (not including Rack Custom Field and Rack Custom Part Field, which are not displayed in the Script window). In the addressing dialog, if you select, “Treat blank values for custom fields as wildcards” then blank values for any of these properties will not constrain possible assignments. For example, if three events have Custom Script Fields of “A”, blank, and “B”, then a Custom Script Field constraint will prevent the “A” and “B” events from being assigned to the same module or slat or pin, but the event with a blank Custom Script Field could be assigned to the same module or slat or pin as either of the others.
The Custom Part Field refers to a property of the effect definition in the Effects window. The Custom Position Field refers to a property of the position in the Positions window. The Custom Script Field and Custom Numeric Field both refer to properties of the event in the Script window. |
| Event (If Single-Shot) | This constraint requires that either none of the effects are single-shots, or there is exactly one effect. If applied as a pin constraint, this condition is equivalent to limiting the max. e-matches per pin to 1, but only for single-shots, enabling you to have a different max. e-matches per pin limit for non-single-shots than for single-shots. The re-arrange effects option for single-shot racks requires a single e-match per effect in the rack, which can be accomplished with this constraint specifically for single-shots or with the max. e-matches per pin constraint for all effects. |
| Flight Count | A “flight count” is the number of devices at the same event time and same position. A chain of five, by itself, has a flight count of 5 for all five devices in the chain. Two chains of five shot together have a flight count of 10 for all ten devices. Five shells unchained but shot together also have a flight count of 5. The Flight constraint requires that effects have the same flight count. |
| Flight-Or-Not | This constraint requires that all effects have a flight count > 1, or all effects have a flight count = 1, though other than that the effects do not need to have the same flight count. |
| Group | This constraint relates to the Group attribute but also takes into consideration the Chain attribute and treats blank values unusually. The constraint is satisfied if all events are in the same group (and are in fact in a group!), or if all events are in the same chain (and are in fact in a chain!). The Group constraint is useful for manually specifying what effects are to be e-matched together. Adding the Group constraint to pins will prevent events from being e-matched together unless you specifically give them a group identifier, like “TOGETHER” for example. You don’t need to come up with unique identifiers for different groups of events because events can never be combined onto the same pin if they are at different times. |
| Module (If Rack < 25 Tubes) | This constraint on racks limits racks with fewer than 25 tubes to a single module, preventing racks that have just a few more tubes than the module from using a second module (leaving the tubes empty instead). Imagine addressing a position for Cobra modules that have 18 pins. The position contains racks with 20 tubes (holders) and racks with 36 tubes. You would want the 36 tube racks to use two modules, while limiting the 20 tube racks to a single module, leaving two of its tubes unused. This constraint accomplishes both goals simultaneously. |
| Module (If Single-Shot Rack) | This constraint on racks limits single-shot racks to a single module. Other kinds of racks are unaffected by this constraint. |
| One Single-Shot Rack | This constraint restricts a module, slat, or pin to: zero or more non-single-shot racks in combination with zero or one single-shot rack, i.e., it prevents the module, slat, or pin from being shared across multiple single-shot racks, without preventing anything else.
In combination with sorting single-shots first, this constraint is useful to allow the “extra” pins of modules that don’t match pre-wired pins of a rack to be used for other types of effects, like cakes. For example, if a module that has 32 pins is used for a pre-wired pin single-shot rack that has 30 holders bound to pins 1-30, the extra pins 31 and 32 could still be used for cakes. |
| Pair | This constraint requires that all effects have a flight count of 2. |
| Pair-Or-Not | This constraint requires that all effects have a flight count = 2, or all effects have a flight count != 2. |
| Rack | This constraint restricts a module, slat, or pin to serving a single rack. Applied to pins, it prevents chains (which consist of effects on the same pin and e-match) and flights (which consist of effects on the same pin), from splitting across racks as described in Cross-loading chains with angled shells or using fan-racks.
The constraint can also be used to restrict a module or slat to a single rack, but that is typically useful only for single-shot racks. To apply this restriction for modules or slats to single-shot racks but not mortar racks and other kinds of racks, use “Rack (If Single-Shot)” or “One Single-Shot Rack” instead. |
| Rack Cluster | Rack clusters are collections of racks in a position that are snapped together in the rack layout view. It is natural to constrain modules or slats or pins to rack clusters to avoid unwieldy wiring. A single rack by itself is also considered a rack cluster (of one rack) for the purpose of this constraint.
Applied to modules or slats, this constraint prevents wires between physical clusters of racks. Applied to pins, this constraint prevents chains (which consist of effects on the same pin and e-match) and flights (which consist of effects on the same pin), from splitting across multiple physical clusters of racks, as described in Cross-loading chains with angled shells or using fan-racks. If you want to restrict modules (or slats or pins) to groups of racks by your designation that aren’t necessarily snapped together, you can make “virtual rack clusters” by setting the Rack Custom Field to a virtual rack identifier that is the same for racks in the same group, and adding the constraint “Module restricted to single RACK CUSTOM FIELD”. |
| Rack (If Single-Shot) | This constraint restricts a module, slat, or pin to: a) a single single-shot rack or b) any number of non-single-shot racks. In other words, a module restricted with this constraint could NOT serve effects in a single-shot rack and also in a non-single-shot rack.
This constraint is useful for managing the allocation of modules across single-shot racks without affecting other types of effects. The similar constraint “One Single-Shot Rack” also prevents a module, slat, or pin from sharing across multiple single-shot racks, but allows sharing between a single-shot rack and non-single shot racks. |
| Rack Part Number, Rack Category, Rack Custom Part Field, Rack Custom Field | These constraints refer to properties of the rack used for the effect. The constraint “Module restricted to single RACK CUSTOM FIELD” means that every event fired from a specific module must use a rack with the same Custom Rack Field. The Custom Rack Field is a field in the Racks window that can be edited for every rack instance in the show. The constraint “Module restricted to single RACK CUSTOM PART FIELD” means that every event fired from a specific module must use a rack with the same Custom Part Field. The Custom Part Field for the rack is part of the rack’s definition, which is editable in the Effects window and which applies to all instances of the rack definition used in the show.
Effects also have a Custom Part Field in their definition in the Effects window, so there is a possibility of confusion. The constraint names are precise: the constraint Custom Part Field refers to the effect’s Custom Part Field; the Rack Custom Part Field constraint refers to the rack’s Custom Part Field — both in the Effects window. The constraint Custom Script Field refers to the effect’s Custom Script Field in the Script window; the Rack Custom Field refers to the rack’s Custom Rack Field in the Racks window. |
| Rack Type (Of Rack) | This constraint refers to the Rack Type property of the racks themselves, not of event rows in the script window. |
| Section | The module constraint row in the addressing dialogs includes the term “Section” as a required option, meaning that modules are never shared across different sections. It follows that slats and pins are also never shared across different sections, since it would be impossible to share a slat or pin without also sharing its associated module. There are a few other terms that modules implicitly cannot be shared across. The full list is: Universe, Firing System Type, Section, Addressing Blueprint, Start Module, and Module Type. See Sorting positions across multiple blueprints or sections for more information. |
| Slat (If Rack < 25 Tubes) | This constraint on racks limits racks with fewer than 25 tubes to a single slat, preventing racks that have just a few more tubes than the slat from using a second slat (leaving the tubes empty instead). Imagine addressing a position for fireTEK slats that have 16 pins. The position contains racks with 20 tubes (holders) and racks with 32 tubes. You would want the 32 tube racks to use two slats, while limiting the 20 tube racks to a single slat, leaving four of its tubes unused. This constraint accomplishes both goals simultaneously. |
| Slat (If Single-Shot Rack) | This constraint on racks limits single-shot racks to a single slat. Other kinds of racks are unaffected by this constraint. |
| Tube Index — Chain | The tube index constraint forces chains to load across racks, as described in Cross-loading chains with straight-up shells. Applied as an addressing constraint to pins, this constraint forces all the chain shells associated with the pin to occupy tubes at the same tube index, which means the chain shells will need to be spread out across multiple racks and will need to be at the same location within the racks: cross-loading!
The constraint “Tube Index — Chain” includes the phrase “– Chain” to indicate that the constraint only applies to chains. It does not apply to flights of independent shells ignited by the same pin. This distinction is a convenience that allows you to add the constraint for addressing in general without it affecting pairs of shells or flights. The “Tube Index — Chain” constraint also implicitly adds a “Chain Reference” constraint to the pin, which restricts the pin to a single chain (or non-chained shells), preventing multiple chains from being e-matched to the same pin. If multiple chains were e-matched to the same pin, then the “Tube Index — Chain” constraint would force all their shells to be at the same tube index, which would make for a very long row of racks. Lastly, the “Tube Index — Chain” constraint only applies to pins. Adding the constraint to the modules or slats does nothing because it doesn’t make any sense. |
| Tubes | This constraint refers the the Tubes property of the effects, not of the racks. For effects, the Tubes field can mean whatever the user wants it to mean, similar to the Custom Numeric Field. |