add table of contents

book.toml

@@ -7,3 +7,6 @@ title = "NaxGCC Documentation"
 
 [preprocessor.katex]
 after = ["links"]
+
+[preprocessor.toc]
+marker = "[[_TOC_]]"

flake.nix

@@ -36,7 +36,7 @@
 
       devShells.default = pkgs.mkShell {
         nativeBuildInputs = builtins.attrValues {
-          inherit (pkgs) mdbook mdbook-katex;
+          inherit (pkgs) mdbook mdbook-katex mdbook-toc;
         };
       };
     });

src/configuration.md

@@ -2,16 +2,7 @@
 
 This page contains all the information needed for configuring & calibrating your controller. Click on any of the links below to quickly navigate to a given section.
 
-1. [Initial Calibration](#initial-calibration)
-2. [Configuration Options](#configuration-options)
-   - [Stick Calibration](#stick-calibration)
-   - [Smart Snapback Adjustment](#smart-snapback-adjustment)
-   - [Waveshaping Adjustment](#waveshaping-adjustment)
-   - [Stick Scaling Adjustment](#stick-scaling-adjustment)
-   - [Cardinal Snapping Adjustment](#cardinal-snapping-adjustment)
-   - [Axis Smoothing Adjustment](#axis-smoothing-adjustment)
-   - [Input Consistency Mode Toggle](#input-consistency-mode-toggle)
-   - [Display Values](#display-values)
+[[_TOC_]]
 
 # Initial Calibration
 

src/input-consistency.md

@@ -4,6 +4,8 @@ This is a rather technical document about USB polling, input latency, and the is
 
 > **NOTE:** "Input consistency" and "input integrity" are used interchangeably in this document.
 
+[[_TOC_]]
+
 ## General Info
 
 The vast majority of human interface devices (HIDs) transmit their states over USB using a technique known as "polling". Essentially, these devices (clients) advertise themselves as supporting a certain polling interval/frequency to whatever device they're attached to (hosts). The host then polls the client at the desired frequency, or at a lower one (= not as often, = more slowly) if the host doesn't support the client's desired frequency.
@@ -38,7 +40,7 @@ Again in plain English, if you have multiple polling rates, the frame window in
 
 This is how it is when you're playing with a PhobGCC (the best GCC currently available) on a _first party_ GCC adapter from Nintendo. Note that third party adapters may very well be much worse than this, because they could poll the GCC at an even lower frequency (= more slowly).
 
-**BONUS QUESTION:** What if the sum of all polling intervals is larger than the frame time window, i.e. $\sum_{i=1}^nT_i > T_f$ ? That's right, in this case your inputs are _always_ RNG! (good thing that's not the case here though)
+> **BONUS QUESTION:** What if the sum of all polling intervals is larger than the frame time window, i.e. $\sum_{i=1}^nT_i > T_f$ ? That's right, in this case your inputs are _always_ RNG! (good thing that's not the case here though)
 
 ## The Solution
 
@@ -75,7 +77,7 @@ In consistency mode, the NaxGCC introduces a variable delay in order to wait res
 
 ### "Super Hack" Mode
 
-In "super hack" mode, the NaxGCC avoids responding to the console's poll requests until the controller state has changed, _and_ at least $8.\overline{3}\mathrm{ms}$ have elapsed since the last poll request. This ensures that, for inputs made more than $8.\overline{3}\mathrm{ms}$ apart, the latency is minimized, since the state is immediately dispatched to, and interpreted by, the console, at a slight cost to input integrity for inputs made less than $8.\overline{3}\mathrm{ms}$ apart.
+In "super hack" mode, the NaxGCC abstains from responding to the console's poll requests until the controller state has changed, _and_ at least $8.\overline{3}\mathrm{ms}$ have elapsed since the last poll request. This ensures that, for inputs made more than $8.\overline{3}\mathrm{ms}$ apart, the latency is minimized, since the state is immediately dispatched to, and interpreted by, the console, at a slight cost to input integrity for inputs made less than $8.\overline{3}\mathrm{ms}$ apart.
 
 > **WARNING:** This mode is currently experimental, as it is still undergoing extensive testing, and is currently **not** recommended for tournament play.
 

src/introduction.md

@@ -22,7 +22,7 @@ Because the NaxGCC connects directly to the console via USB, it already outperfo
 
 Further, the NaxGCC has a special "input consistency" mode (enabled by default), which ensures a $\gt 98\%$ input accuracy, compared to $\lt 75\%$ for any other controller (worse if there is an adapter in the mix, with the exception of the Lossless Adapter).
 
-For details on how it works, have a look at our wiki.
+For details on how it works, have a look at the [Input Consistency Modes](./input-consistency.md#input-consistency-modes).
 
 </details>
 

src/jlcpcb-parts-ordering.md

@@ -2,6 +2,8 @@
 
 This is an illustrated guide to ordering NaxGCC PCBs via the JLCPCB Board House.
 
+[[_TOC_]]
+
 ## JLC Ordering Process Overview
 
 This is very important, or else you will get nonfunctional boards.