The meaning of “Module restricted to single X” is that every effect fired from the module must have the same value for X, whatever X is. For example, if you select X = Position, then the meaning is that every effect fired from a given module must be at the same position. That’s usually what you want, because usually you don’t want effects at different positions fired by the same module, because that would require e-matches or scab wire running between the positions. Except for a few special values (see Special constraints), the possibilities for X are just the attributes of the effects being addressed.
If you add a second constraint, like “Module restricted to single Size” then not only will the module’s wires be restricted to a single position, they will also be restricted to effects with the same size. This constraint might be useful if your racks for different size effects were far apart, and you didn’t want wires running between the different size racks.
If you want eliminate wires between arbitrary groups of racks (“Rack Clusters”), then you can add a Rack Cluster constraint to the modules, as described here: restricting to racks.
In addition to the module constraint options on the addressing dialogs, there is an implicit constraint that always applies: “Module restricted to single section”. An Addressing Group is any group of positions that has the same Start Module Number, Blueprint, Module Type, Section, and Universe — all of which can be set on the position by right clicking the position and doing “Edit position properties” from the context menu. The section constraint refers to the addressing group, preventing modules, slats or pins from being shared across positions that are different with respect to Section or any of the other addressing group terms. If you want to share modules across positions, the positions involved must have the same values for these properties. See Using the Section field in position properties.
The constraints on slats and pins have the same meaning as the constraints on modules, but they apply to the slats and pins. If the firing system doesn’t use slats, then you can ignore the constraints on slats. At first blush, you might wonder what the meaning of the constraints on pins is. In fact, constraints on pins only matters if you allow multiple e-matches on the same pin, which means that you’ve changed the default “Max e-matches per pin” on the addressing dialog from 1 to some number larger than one. If you do that, then the constraint adds restrictions on the effects shot from the same pin, analogously to the restrictions on the effects shot from the same module. For example if you add the constraint “Pin restricted to single Size”, then you will never have effects of different sizes being e-matched to the same firing system pin.
If you use slats at different positions that are connected to the same module, then the constraint options are required to restrict each slat to a single position whilst NOT restricting the module to a single position. The “normal” constraints for using slats at different positions connected to the same module are shown in Table 1:
Table 1 – “Normal Slats” blueprint for sharing modules with non-piggy back slats
|Modules constrained to same||(no constraint)|
|Slats constrained to same||Position|
This table does NOT include a Position constraint on the module, because if it did, then the same module couldn’t feed the slats at the different positions. The positions do share the modules; they do not share the slats.
If the firing system uses piggyback slats, then a different set of constraints is required, as described here: piggyback slats
One final observation about constraints may make them easier to remember: If you add a constraint X to the module, then it is redundant and unnecessary to add it to the slat or pin. The reason is, any effect fired from a slat or pin is also being fired by the module to which the slat or pin is connected, so that module’s constraints will apply. If would be impossible to have two effects of different sizes e-matched to the same pin, for example, if the module was constrained to a single Size, even though the pin didn’t have any explicit constraints on it.