wip interference rewording

content/interference-fixes.typ

@@ -1,4 +1,4 @@
-#import "/lib.typ": example, todo
+#import "/lib.typ": todo
 
 = Preventing Interference <timing>
 
@@ -8,104 +8,35 @@ measurement item with too much delay, and some unexpected entity (or entities) s
 mitigate interference, then, we need that window to be *as short as possible* while still allowing
 us to spawn transmission entities in that window.
 
-== Tilesets
+== Tilesets <tileset>
 
-The fundamental principle here is to use tile-tick priority (TTP) to set a global order. See
+A _tileset_ is a sequence of redstone components which update in the tile tick phase. We diagram
-Charlie's great video on TTP for details. #todo[link video]
+them so the data signal flows through the sequence right-to-left, which makes the significance of
+the components match our left-to-right reading convention and makes it easier to read them.
 
-#todo[fix tileset naming. the tileset is the *structure*. the particular sequence is just one instance of that tileset]
+The core principal is that repeaters have higher priority than other components. For example, if a
+repeater and comparator are scheduled to activate in the same tick, the repeater always (with one
+exception, if the comparator faces into a diode and the repeater does not) activates before the
+comparator does. By choosing a regular building pattern, we can avoid this exception entirely.
 
-A *tileset* is a sequence of redstone components which all update in the tile tick phase. Components
+// Among repeaters, they activate in the order in which they were scheduled. And among comparators,
-later in the sequence have greater significance. To make the significance match our left-to-right
+// they activate in the order in which they are scheduled. But every repeater activates before any
-reading convention, we diagram them so the signal flows right-to-left. For example:
+// comparator (aside from that one exception). This gives us a *stable sort* which we can use to
+// globally define update order with arbitrary precision.
 
-#todo[screenshot of the same arbitrary tileset]
+=== Lexicographic Tilesets
 
-```
+#todo[I think remove this, and just make it inline. It shouldn't really be called out.]
-cmp 1rep 2rep obs 1rep
-<---------------------
-```
-
-This section will cover how to read and construct tilesets that enforce a *global* ordering for
-wireless redstone.
-
-=== The Tile Tick Priority Queue
-
-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.
-
-#todo[the priority table
-
-  call out here that basic comparators and all other components, so from here on out we're just
-  going to use comparators for simplicity.
-]
-
-Components with different priority always update in priority order, but components with equal
-priority update in scheduled order.
-
-#todo[rephrase or remove
-
-  The core principal is that repeaters have higher priority than other components. For example, if a
-  repeater and comparator are scheduled to activate in the same tick, the repeater always (with one
-  exception, if the comparator faces into a diode and the repeater does not) activates before the
-  comparator does. By choosing a regular building pattern, we can avoid this exception entirely.
-
-  // Among repeaters, they activate in the order in which they were scheduled. And among
-  // comparators, they activate in the order in which they are scheduled. But every repeater
-  // activates before any comparator (aside from that one exception). This gives us a *stable sort*
-  // which we can use to globally define update order with arbitrary precision.
-
-]
-
-#example[
-  #todo[this explanation is so janky]
-
-  Say these three tilesets are started in the same gametick, `t=0`.
-
-  ```
-    <------
-  1 rep cmp  ab
-  2 cmp rep  cd
-  3 2rep     e
-    <------
-  ```
-
-  Once `b`, `d`, and `e` are scheduled, the priority queue looks like this:
-
-  ```
-  t=2 [d] [b]
-  t=4 [e]
-  ```
-
-  Now at `t=2`, we process the queue in order.
-
-  - `d` activates and schedules `c`.
-  - `b` activates and schedules `a`.
-
-  ```
-  t=4 [e a] [c]
-  ```
-
-  Now at `t=4`, the end of the tileset, the lanes will always update in order `3 1 2`
-
-]
-
-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.
 
 === Permutation Tilesets
 
-#todo[describe the mixed delay permutation tilesets and the alphabetization procedure]
+=== Binary Tilesets
 
 === Binary
 
-The simplest tilesets are made entirely of comparators and 2gt repeaters (alternatively: observers
+The simplest tilesets are made entirely of comparators and 2gt repeaters. Repeaters activate before
-and 2gt repeaters). Repeaters activate before comparators, so if we think of it like sorting words
+comparators, so if we think of it like sorting words alphabetically, we can identify repeaters with
-alphabetically, we can identify repeaters with "A" and comparators with "B".
+"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
@@ -113,8 +44,8 @@ short tileset, that seems trivial; things get more interesting as we add more el
 
 ```
 <--
-cmp  (B)
 rep  (A)
+cmp  (B)
 ```
 
 Now let's use 2 components for a 4gt tileset. There are now four options, AA, AB, BA, BB. We can
@@ -122,10 +53,10 @@ alphabetize these and see the order.
 
 ```
 <------
-cmp cmp (BB)
-cmp rep (BA)
-rep cmp (AB)
 rep rep (AA)
+rep cmp (AB)
+cmp rep (BA)
+cmp cmp (BB)
 ```
 
 To break this down: the bottom two (AA, AB) end in repeaters, so they must come first. Among those,
@@ -174,7 +105,7 @@ cmp rep rep cmp cmp rep rep
 
 === Lexicographic
 
-=== Jamming
+=== Mixed Priority Jamming
 
 == Block Event Delay