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. In the addressing dialog, if you select, “Treat blank values for script 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. |
| Flight | 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. |
| 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 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.
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 — 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. |
| 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. |
| 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. |
| 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. |