From 42b8d1da0fda897fc47b4e9ba4a99603a7145ca8 Mon Sep 17 00:00:00 2001 From: RDW Date: Mon, 18 Mar 2024 23:06:48 +0100 Subject: [PATCH] Docs: Fix a number of broken MDX footnote references Not sure if they worked previously, but they likely broke due to upgrading to Docusaurus v3 otherwise. Oddly enough, some older pages use the right syntax... maybe it was just an oversight on my part. --- docs/file-formats/GAT.md | 2 +- docs/file-formats/GND.md | 2 +- docs/game-mechanics/03-movement-and-pathfinding.md | 4 ++-- docs/rendering/02-coordinate-systems.md | 4 ++-- docs/rendering/animation-systems.md | 4 ++-- 5 files changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/file-formats/GAT.md b/docs/file-formats/GAT.md index 9d2145fe..c2509dab 100644 --- a/docs/file-formats/GAT.md +++ b/docs/file-formats/GAT.md @@ -29,7 +29,7 @@ The vast majority of maps in the RO client use this version, including those fou | `Height` | 10 | 4 | `int` | The vertical size of the map, given in tiles | | `Tiles` | 14+ | 20 | `array` | Contains the navigation properties for `Width * Height` tiles | -[^1] Technically, old versions have a zero-byte prefix shifting the layout. It's still GAT 1.2 otherwise. +[^1]: Technically, old versions have a zero-byte prefix shifting the layout. It's still GAT 1.2 otherwise. #### Tile Properties diff --git a/docs/file-formats/GND.md b/docs/file-formats/GND.md index 16557029..d7ce9cac 100644 --- a/docs/file-formats/GND.md +++ b/docs/file-formats/GND.md @@ -96,7 +96,7 @@ The lightmap and ambient occlusion textures are split into small bitmaps: | `ShadowmapPixels` | 16 | 64 | `array` | `Width * Height` ambient occlusion texture pixels (intensity values) | | `LightmapPixels` | 16 | 192 | `array` | `Width * Height` lightmap texture pixels (specularity values) | -[^1] _This value appears to be ignored; the actual pixel format should always be 8-bit RGBA (stored as ARGB)._ +[^1]: _This value appears to be ignored; the actual pixel format should always be 8-bit RGBA (stored as ARGB)._ #### Textured Surfaces diff --git a/docs/game-mechanics/03-movement-and-pathfinding.md b/docs/game-mechanics/03-movement-and-pathfinding.md index 8e713532..24fc7c4f 100644 --- a/docs/game-mechanics/03-movement-and-pathfinding.md +++ b/docs/game-mechanics/03-movement-and-pathfinding.md @@ -34,7 +34,7 @@ _Source: Kokotewa (no direct link available)_ | Osiris | 100 | Very fast | | Treasure Box | 0 | Cannot move at all | -[^1] Immobile creatures can still technically move (at their configured speed), but this is almost certainly a bug. +[^1]: Immobile creatures can still technically move (at their configured speed), but this is almost certainly a bug. ### Statistics @@ -58,4 +58,4 @@ This section is a placeholder. If you know anything about the topic, please help When damaged, actors usually [^2] cannot move for a brief period of time, effectively "stunning" them when they suffer a "hit". Afterwards, movement commences on the precomputed path unless their position has been altered via knockback effects. -[^2] Certain auras, like Endure, can make them immune to this mechanic. +[^2]: Certain auras, like Endure, can make them immune to this mechanic. diff --git a/docs/rendering/02-coordinate-systems.md b/docs/rendering/02-coordinate-systems.md index 3fc3b11a..a7b48e0c 100644 --- a/docs/rendering/02-coordinate-systems.md +++ b/docs/rendering/02-coordinate-systems.md @@ -18,9 +18,9 @@ There are multiple different coordinate systems to account for when it comes to | RSM Coordinates | 3D | RSM and RSM2 files | Origin of the model editor's coordinate system[^2] | | GR2 Coordinates | 3D | GR2 files | Origin of the model editor's coordinate system[^2] | -[^1] Alternatively, you could call them "GAT Coordinates" because that's effectively what they are. +[^1]: Alternatively, you could call them "GAT Coordinates" because that's effectively what they are. -[^2] Whatever software the artists used works with a different local origin, which needs to be transformed to world space. +[^2]: Whatever software the artists used works with a different local origin, which needs to be transformed to world space. ## World Coordinates diff --git a/docs/rendering/animation-systems.md b/docs/rendering/animation-systems.md index ec60871c..6d19f74f 100644 --- a/docs/rendering/animation-systems.md +++ b/docs/rendering/animation-systems.md @@ -34,9 +34,9 @@ In order to answer the first question, a bit of guesswork is needed. There's of If one assumes the existence of one or several timers that update the animation state machines, operating at a fixed clock speed, it wouldn't be as far-fetched to describe frame display times in terms of full cycles on this clock. In fact, there is some evidence that other systems (e.g., particles) do indeed involve such self-clocking mechanisms to compute their own time deltas. -This might seem like a peculiar design choice compared to a global delta time (the "standard" approach). However, it's clear that there are several different animation systems working to animate objects such as the Granny3D models, water surfaces, particle systems, and RSM(2) models[^*]. In light of this, adding one more for sprites to the mix doesn't seem particularly strange. +This might seem like a peculiar design choice compared to a global delta time (the "standard" approach). However, it's clear that there are several different animation systems working to animate objects such as the Granny3D models, water surfaces, particle systems, and RSM(2) models[^2]. In light of this, adding one more for sprites to the mix doesn't seem particularly strange. -[^*] This is obvious since they all use different units of measurement; Also, GR2 models were added much later in development. +[^2]: This is obvious since they all use different units of measurement; Also, GR2 models were added much later in development. ### Predicting Animation Times