Misc section

docs/misc/components.md

@@ -1,5 +1,7 @@
-Text Components
-==================
+---
+sidebar_position: 6
+title: Text Components
+---
 
 A `Component` is a holder for text which can be formatted and chained with other components via its subtype `MutableComponent`. A component can be created using one of the available static helpers:
 
@@ -16,8 +18,7 @@ A `Component` is a holder for text which can be formatted and chained with other
 
 A component's text contents are represented by `ComponentContents`. Notably, the subtype `TranslatableContents` not only supports [localization][internalization] but also [text formatting][formatting].
 
-Applying Style
---------------
+## Applying Style
 
 Components can be formatted (e.g., bold, click actions, color) via `Style`s. `Style`s are immutable, creating a new `Style` each time when modified. The empty style `Style#EMPTY` can be used as a base for configuration.
 
@@ -55,8 +56,7 @@ text.withStyle(red).withStyle(bold).withStyle(doubleLines);
 This creates a red, bold text with two lines:
 ![red_hello]
 
-Chaining Components
--------------------
+## Chaining Components
 
 `MutableComponent#append` can chain multiple components together. Chained components can be retrieved with `MutableComponent#getSiblings`.
 
@@ -86,8 +86,7 @@ bold.append(fourth).append(fifth).append(sixth);
 ```
 ![style_annotated]
 
-Text Formatting
----------------
+## Text Formatting
 
 Text formatting is the process of inserting data as text into predefined larger text. It can be used for displaying coordinates, showing unit measurements, etc. **Format specifiers** are used for indicating where a text can be inserted.
 

docs/misc/config.md

@@ -1,10 +1,11 @@
-Configuration
-=============
+---
+sidebar_position: 1
+title: Configuration
+---
 
 Configurations define settings and consumer preferences that can be applied to a mod instance. Forge uses a configuration system using [TOML][toml] files and read with [NightConfig][nightconfig].
 
-Creating a Configuration
-------------------------
+## Creating a Configuration
 
 A configuration can be created using a subtype of `IConfigSpec`. Forge implements the type via `ForgeConfigSpec` and enables its construction through `ForgeConfigSpec$Builder`. The builder can separate the config values into sections via `Builder#push` to create a section and `Builder#pop` to leave a section. Afterwards, the configuration can be built using one of two methods:
 
@@ -102,8 +103,7 @@ The values themselves can be obtained using `ConfigValue#get`. The values are ad
     * Class Type: `Boolean`
     * Method Name: `#define`
 
-Registering a Configuration
----------------------------
+## Registering a Configuration
 
 Once a `ForgeConfigSpec` has been built, it must be registered to allow Forge to load, track, and sync the configuration settings as required. Configurations should be registered in the mod constructor via `ModLoadingContext#registerConfig`. A configuration can be registered with a given type representing the side the config belongs to, the `ForgeConfigSpec`, and optionally a specific file name for the configuration.
 
@@ -124,8 +124,7 @@ SERVER | Server Side Only | Yes              | `.minecraft/saves/<level_name>/se
 Forge documents the [config types][type] within their codebase.
 :::
 
-Configuration Events
---------------------
+## Configuration Events
 
 Operations that occur whenever a config is loaded or reloaded can be done using the `ModConfigEvent$Loading` and `ModConfigEvent$Reloading` events. The events must be [registered][events] to the mod event bus.
 

docs/misc/debugprofiler.md

@@ -1,4 +1,7 @@
-# Debug Profiler
+---
+sidebar_position: 5
+title: Debug Profiler
+---
 
 Minecraft provides a Debug Profiler that provides system data, current game settings, JVM data, level data, and sided tick information to find time consuming code. Considering things like `TickEvent`s and ticking `BlockEntities`, this can be very useful for modders and server owners that want to find a lag source.
 

docs/misc/gametest.mdx

@@ -1,10 +1,11 @@
-Game Tests
-==========
+---
+sidebar_position: 3
+title: Game Tests
+---
 
 Game Tests are a way to run in-game unit tests. The system was designed to be scalable and in parallel to run large numbers of different tests efficiently. Testing object interactions and behaviors are simply a few of the many applications of this framework.
 
-Creating a Game Test
---------------------
+## Creating a Game Test
 
 A standard Game Test follows three basic steps:
 
@@ -128,8 +129,7 @@ public class ExampleGameTests {
 }
 ```
 
-Registering a Game Test
------------------------
+## Registering a Game Test
 
 A Game Test must be registered to be ran in-game. There are two methods of doing so: via the `@GameTestHolder` annotation or `RegisterGameTestsEvent`. Both registration methods still require the test methods to be annotated with either `@GameTest`, `@GameTestGenerator`, `@BeforeBatch`, or `@AfterBatch`.
 
@@ -165,8 +165,7 @@ public static void exampleTest3(GameTestHelper helper) {
 The value supplied to `GameTestHolder#value` and `GameTest#templateNamespace` can be different from the current mod id. The configuration within the [buildscript][namespaces] would need to be changed.
 :::
 
-Structure Templates
--------------------
+## Structure Templates
 
 Game Tests are performed within scenes loaded by structures, or templates. All templates define the dimensions of the scene and the initial data (blocks and entities) that will be loaded. The template must be stored as an `.nbt` file within `data/<namespace>/structures`.
 
@@ -215,8 +214,7 @@ public class ExampleGameTests {
 }
 ```
 
-Running Game Tests
-------------------
+## Running Game Tests
 
 Game Tests can be run using the `/test` command. The `test` command is highly configurable; however, only a few are of importance to running tests:
 
@@ -232,8 +230,7 @@ Subcommand  | Description
 Subcommands follow the test command: `/test <subcommand>`.
 :::
 
-Buildscript Configurations
---------------------------
+## Buildscript Configurations
 
 Game Tests provide additional configuration settings within a buildscript (the `build.gradle` file) to run and integrate into different settings.
 

docs/misc/keymappings.md

@@ -1,4 +1,7 @@
-# Key Mappings
+---
+sidebar_position: 2
+title: Key Mappings
+---
 
 A key mapping, or key binding, defines a particular action that should be tied to an input: mouse click, key press, etc. Each action defined by a key mapping can be checked whenever the client can take an input. Furthermore, each key mapping can be assigned to any input through the [Controls option menu][controls].
 

docs/misc/updatechecker.md

@@ -1,15 +1,15 @@
-Forge Update Checker
-====================
+---
+sidebar_position: 4
+title: Forge Update Checker
+---
 
 Forge provides a very lightweight, opt-in, update-checking framework. If any mods have an available update, it will show a flashing icon on the 'Mods' button of the main menu and mod list along with the respective changelogs. It *does not* download updates automatically.
 
-Getting Started
----------------
+## Getting Started
 
 The first thing you want to do is specify the `updateJSONURL` parameter in your `mods.toml` file. The value of this parameter should be a valid URL pointing to an update JSON file. This file can be hosted on your own web server, GitHub, or wherever you want as long as it can be reliably reached by all users of your mod.
 
-Update JSON format
-------------------
+## Update JSON format
 
 The JSON itself has a relatively simple format as follows:
 
@@ -40,8 +40,7 @@ This is fairly self-explanatory, but some notes:
 
 - Some examples can be found here for [nocubes][], [Corail Tombstone][corail] and [Chisels & Bits 2][chisel].
 
-Retrieving Update Check Results
--------------------------------
+## Retrieving Update Check Results
 
 You can retrieve the results of the Forge Update Checker using `VersionChecker#getResult(IModInfo)`. You can obtain your `IModInfo` via `ModContainer#getModInfo`. You can get your `ModContainer` using `ModLoadingContext.get().getActiveContainer()` inside your constructor, `ModList.get().getModContainerById(<your modId>)`, or `ModList.get().getModContainerByObject(<your mod instance>)`. You can obtain any other mod's `ModContainer` using `ModList.get().getModContainerById(<modId>)`. The returned object has a method `#status` which indicates the status of the version check.