The protocols as described are very sensitive to the exact timing that the EID counter is incremented. The fundamental cause for all types of interference is that we spawn a reference and measurement item with too much delay, and some unexpected entity (or entities) spawn in-between. To mitigate interference, then, we need that window to be as short as possible while still allowing us to spawn transmission entities in that window.
A tile sequence is a chain of redstone components that all update in the tile tick phase. The fundamental principle here is to use tile-tick priority (TTP) to set a global order. See Charlie’s great video on TTP for details.
A tile set is a system of constructing tile sequences that enforces a particular global ordering.
Components that activate later in the sequence have a stronger effect on the order, so to match our left-to-right reading convention, we diagram tile sequences so the signal flows right-to-left.
The game schedules tile updates through a priority queue; different components have different priority, so each stage of the tileset iteratively refines the global order. Across the full tileset, we can enforce an arbitrary global ordering.
Components with different priority always update in priority order, but components with equal priority update in scheduled order.
So the full picture involves arbitrary components and priorities. As long as all the tilesets have the same total delay and end at the same time, we can determine a global ordering. However the general picture is hard to reason about, we basically have to simulate the priority queue to make predictions. If we restrict the design of the tilesets a bit, there are two simplifications we could take to make things easier to reason about.
The simplest tilesets are made entirely of comparators and 2gt repeaters (alternatively: observers and 2gt repeaters). Repeaters activate before comparators, so if we think of it like sorting words alphabetically, we can identify repeaters with “A” and comparators with “B”.
So, suppose we have a “binary tileset” that is 2gt long. There are two options, A and B. If we alphabetize these, we see the A (repeater) always executes before the B (comparator). With such a short tileset, that seems trivial; things get more interesting as we add more elements.
<--
cmp (B)
rep (A)Now let’s use 2 components for a 4gt tileset. There are now four options, AA, AB, BA, BB. We can alphabetize these and see the order.
<------
cmp cmp (BB)
cmp rep (BA)
rep cmp (AB)
rep rep (AA)To break this down: the bottom two (AA, AB) end in repeaters, so they must come first. Among those, (AA) comes first. Among the top two (BA, BB), (BA) comes first. It’s standard alphabetizing. Just as the order of the alphabet creates an ordering over all words, the ordering of the comparator and repeater creates an ordering of all tilesets.
The 6gt tileset. There are now eight options.
<---------
...As the tilesets get larger, it’s less useful to lay out the entire tileset and more useful to find the next and previous lanes.
For example, take this 7-diode tileset.
cmp rep rep cmp rep cmp cmp
<--------------------------
B A A B A B BWe can easily find the next lane by thinking of this not as a word but as a number. We have two options, and one is greater than the other.
cmp rep rep cmp rep cmp cmp
<--------------------------
B A A B A B B
1 0 0 1 0 1 1We can think of this tileset as a 7-bit binary number, in this case the value 75. We can find the next lane by simply incrementing by one.
1 0 0 1 0 1 1 (75)
+ 1
1 0 0 1 1 0 0 (76)
<--------------------------
cmp rep rep cmp cmp rep rep