From 6d037e6c1914f0bec3c166811e28fec457bd999d Mon Sep 17 00:00:00 2001 From: David Allemang Date: Fri, 26 Jun 2026 09:37:04 -0400 Subject: [PATCH] wip tileset explainer --- content/interference-fixes.typ | 104 ++++++++++++++++++++++++++++----- 1 file changed, 91 insertions(+), 13 deletions(-) diff --git a/content/interference-fixes.typ b/content/interference-fixes.typ index f8e43af..cf896d3 100644 --- a/content/interference-fixes.typ +++ b/content/interference-fixes.typ @@ -1,4 +1,4 @@ -#import "/lib.typ": todo +#import "/lib.typ": example, todo = Preventing Interference @@ -13,21 +13,99 @@ us to spawn transmission entities in that window. 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. #todo[link video] -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. +#todo[fix tileset naming. the tileset is the *structure*. the particular sequence is just one instance of that tileset] -// 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. +A *tileset* is a sequence of redstone components which all update in the tile tick phase. Components +later in the sequence have greater significance. To make the significance match our left-to-right +reading convention, we diagram them so the signal flows right-to-left. For example: + +#todo[screenshot of the same arbitrary tileset] + +``` +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 -The simplest tilesets are made entirely of comparators 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". +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 @@ -96,7 +174,7 @@ cmp rep rep cmp cmp rep rep === Lexicographic -=== Mixed Priority Jamming +=== Jamming == Block Event Delay