Software Documentation

Software Documentation

Firing System AddressingDocumentation

Intermediate Last updated: February 10, 2024

29 Sorting positions across multiple blueprints or sections

Addressing functions like “Addressing > Address show…” and “Addressing > Address show using blueprints assigned to positions” assign addresses according to sorting criteria you specify in the addressing dialog or addressing blueprint. One of the most common sorting criteria that almost everybody uses is Position, to create module and pin number addresses that start with the alphabetically first position and count upwards.

If the addressing function applies to all of the positions of the show together, then the sorting criteria you specify — in particular the Position criterion — will apply to all the positions in the show. Addresses will be assigned exactly as you expect, beginning with the alphabetically first position if your sorting criteria begin with Position.

However, if the addressing function applies to groups of positions independently of each other, as it will if you use multiple blueprints or sections for example, then the groups are sorted relative to each other first. The addressing function begins with the first group of positions and assigns addresses to the shots at those positions, then advances to the next group of positions and assigns addresses to them, then advances to the third group, and so it. For each group of positions, the addressing function applies the sorting criteria you have specified that is applicable to that group. In the simple case of “Addressing > Address show…”, the sorting criteria are the same for every group. If you are addressing using “Addressing > Address show using blueprints assigned to positions”, then the sorting criteria may be different for each group; it depends on what blueprint applies to the positions of the group.

Although it may sound like addressing by groups of positions independently wouldn’t affect the way positions are sorted, it usually does. Consider, for example, two groups of positions. The first group has positions 01 and 04. The second group has positions 02 and 03. Even if both groups have sorting criteria that sort by position, and even if the groups are sorted relative to each other according to their alphabetically first position, the result of addressing by groups of positions independently will not be the same as globally sorting the positions alphabetically. With the 01/04 group being sorted first, the addresses would be assigned to positions in the order of position 01, 04, 02, 03.

 

Addressing groups

Assuming you want positions sorted alphabetically for addressing, and assuming you are using multiple blueprints or sections or some other position property that causes addressing to be applied to groups of positions independently, then you can get what you want by using the Section property of positions if you understand how addressing groups work.

An Addressing Group is a set of positions that have the same Universe, Firing System Type, Section, Addressing Blueprint, Start Module, Pre-Assigned Rails, and Module Type (see Addressing groups and The Start Module, and Pre-Assigned Rails fields on positions for more about addressing groups).  Perhaps you’ve never used some of these position properties or you don’t care about them.  If you just use “Addressing > Address show…” to address the show and you never explicitly set any of these six properties on the positions, then the addressing group is the whole show and you don’t need to read any further.

If you are reading this section, you are probably puzzling over why positions aren’t globally sorting alphabetically, and the answer is almost certainly that you’ve assigned one or more of these six properties differently to some of your positions, which divides the show into addressing groups that are addressed independently, producing the unexpected result.

The specific sorting procedure for addressing groups is:

  1. The show is first divided into partitions having the same Universe and Firing System Type.  These partitions are sorted by Universe, then Firing System Type, lexicographically.   The addressing function applies to each of the partitions separately in accordance with Step 2-3.
  2. Each partition is divided into addressing groups of positions having the same Section, Addressing Blueprint, Start Module and Module Type.  The addressing groups are sorted relative to each other by their lexicographically first constituent position (alphabetically first position in the group).  For example, the addressing group containing positions 01 and 04 would sort before a group containing positions 02 and 03, because 01 precedes 02 lexicographically.   The one rare exception to this rule is that if all addressing groups use a “Reverse Position” sort (which is rarely used) then the groups are sorted relative to each other by their last constituent position.
  3. The addressing function applies to the sorted addressing groups in sequence.  For each addressing group, the sorting criteria from the addressing dialog or addressing blueprint assigned to the positions applies for sorting the positions and other factors within the addressing group.

 

Okay, so what do I do?

Coming back to the assumption that you want positions to sort alphabetically across the whole show, one way that you can get that result is to assign each position to its own unique section.  According to Step 2, that will put each position into its own addressing group, and the addressing groups will be sorted alphabetically.

The only reason you might not be able to do that is if you were using the Section field for some other purpose, or if you were trying to share modules, slats, or pins across multiple positions having the same section.  If you read the module constraint paragraph of the addressing dialog or addressing blueprint dialog carefully, you’ll see that modules are always restricted to a single section.  Since modules cannot be shared across different sections, dividing the show up into one section per position will prevent any module sharing across positions.

So you may not be able to assign every position to its own section, but you can still use the Section field to make most of the positions sort correctly.  If there are any remaining problems, then within the sections that contains multiple positions, you will need to rename your positions so that their sequestration does not interfere with the global sort.

 

Example

The positions window, which you can open from the “Window” menu, shows all the information that relates to the sorting of positions. Figure 1 shows an example in which the user has put four positions into section “5”. Two of the positions use “blueprintA” and two use “blueprintB”. The user expected that the positions within section 5 would sort according to the position name, but as shown in Figure 2, the address assignments didn’t correspond to sorted position names. Why?

Figure 1 – The four positions in section 5 use two different blueprint (the column on the right).

 

The issue in Figure 1 is that even though all four of those positions are in the same section, that section is split into two addressing groups because an addressing group is defined as a group of positions having the same properties — including the same blueprint!  So the two positions in section 5 using blueprintA comprise one addressing group, and the two positions using blueprint B comprise a second addressing group.

 

Figure 2 – Addressing group with positions 050 and 053 sorts first, so the first two addresses go to 050 and 053 (not 050 and 051).

 

The addressing group with the alphabetically first position name (050) sorts first, and its two positions therefore get the first addresses, 050, 053. The next group, having positions 051 and o52 is addressed next. The complete sequence of address assignments is 050, 053, 051, 052, as you can see in Figure 2 if you look at the positions corresponding to rail addresses 00, 01, 02, and 03.