mkdocs-ify

.github/workflows/deploy.yaml

@@ -0,0 +1,19 @@
+name: deploy
+on:
+  push:
+    branches:
+      - master
+permissions:
+  contents: write
+jobs:
+  deploy:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v3
+      - uses: actions/setup-python@v4
+        with:
+          python-version: 3.x
+          cache: 'pip'
+      - run: |
+        pip install -r dependencies.txt
+        mkdocs gh-deploy --force

.gitignore

@@ -0,0 +1 @@
+.obsidian

dependencies.txt

@@ -0,0 +1,6 @@
+markdown>=3.4.4
+mkdocs>=1.5.2
+mkdocs-material>=9.2.7
+mkdocs-material-extensions>=1.1.1
+pygments>=2.16.1
+pymdown-extensions>=10.3

docs/about.md

@@ -0,0 +1,3 @@
+# About
+
+CleanroomMC is a GitHub/Discord-based organization that concentrates on ~~making the world a better place~~ maintaining existing mods, as well as innovating newer toolchains, mods and libraries to carry on the version of Minecraft 1.12.2.

docs/index.md

@@ -0,0 +1,7 @@
+Here you will find information on all of Cleanroom's **mods, libraries and toolchains.**
+
+As well as information on an ever-growing information database of **Minecraft 1.12.2 and its modding environment.**
+
+## ^^Contribution^^
+
+If you want to contribute to this wiki, please head towards our [:fontawesome-brands-github: GitHub Repository](https://github.com/CleanroomMC/Encyclopedia) and open up a Pull Request!

docs/mod-development/debugging.md

@@ -0,0 +1,15 @@
+
+![Depiction of Steps Taken to Debug](debugging_example.png){ width="550" align=right }
+
+<br></br>
+1. Run :material-menu-right:`Run Client` or :material-menu-right:`Run Server` in :material-bug:`Debug Mode`
+<br></br>
+2. Whenever you change parts of your code, use the :hammer:`Build Project` next to the dropdown menu for run configurations.
+
+<br></br>
+
+!!! info
+    When using either ForgeGradle 2.3 or RetroFuturaGradle. The steps are the same! Though, this may change once CleanroomGradle is released.
+
+!!! warning
+    This will not work for certain parts of the code, very noticeable checks (such as console log) in changed code are strongly advised!

mod_development/events/events.md → docs/mod-development/event/overview.md

@@ -1,7 +1,6 @@
-## Events
 - Events are the backbone of Forge's modding ecosystem, there are two major event types.
-	- FMLEvent
-	- Event
+	- `FMLEvent`
+	- `Event`
 
 - FMLEvents are events for different aspects of mod loading.
 	1. `FMLFingerprintViolationEvent`: fires when the mod that is running has mismatched fingerprints.
@@ -33,15 +32,90 @@
 - Different event types have their own ways of being listened to and unique ways of being posted.
 
 - FMLEvents are listened to by having the `@EventHandler` annotation on methods within `@Mod` annotated classes. These must be member methods. **These listeners are called reflectively**
+??? abstract "Example"
+	```java title="ExampleClass.java"
+	@Mod(modid = "modid", name = "Mod Name", version = "1.0")
+	public class ExampleClass {
+
+		@EventHandler
+		public void runOnPreInit(FMLPreInitializationEvent event) {
+			// This block of code will run when FMLPreInitializationEvent is happening
+		}
+
+	}
+	```
 - Other types of events are more flexible in how they're being registered. **These listeners are called natively**
 	1. Annotation Magic: `@EventBusSubscriber` class level annotation
 		- These classes must withhold from being loaded before annotations are processed.
 		- If it is annotated with `@Mod`, the `modid` argument isn't needed, otherwise it is needed for recognition sake.
 		- Any methods in here that wants to listen to an event **must** be static.
+		??? abstract "Example"
+			```java title="ExampleClass.java"
+			@EventBusSubscriber(modid = "modid")
+			public class ExampleClass {
+
+				@SubscribeEvent
+				public static void thisIsAEventListener(Event event) {
+					// This block of code will run when whichever Event is denoted in the argument
+				}
+
+			}
+			```
+
 	2. 	EVENT_BUS interaction:
 		- Events are ran on different event buses, Forge originally wanted to differentiate events properly, then realised that EventBuses are really confusing.
 		- All the EventBuses can be found in `MinecraftForge.class`, those being `EVENT_BUS`, `TERRAIN_GEN_BUS` and `ORE_GEN_BUS`.
-		- Technically a mod can implement their own buses, but I have never seen one.
+		- Technically a mod can implement their own buses, but there doesn't seem to be any in the wild.
 		- Call `register` on any EventBuses and pass through either a class or an object that you want the buses to fire events to. 
 			- **Class = static methods accepted only.**
+			??? abstract "Example"
+				```java title="StaticExample.java"
+				public class StaticExample {
+
+					public static void register() {
+						MinecraftForge.EVENT_BUS.register(EventListener.class);
+					}
+
+					public static class EventListener {
+
+						@SubscribeEvent
+						public static void thisListenerWillRun(Event event) {
+							// This method is static
+							// This block of code will run when whichever Event is denoted in the argument
+						}
+
+						@SubscribeEvent
+						public void thisListenerWillNeverRun(Event event) {
+							// This method is not static
+						}
+
+					}
+
+				}
+				```
 			- **Object = member methods accepted only.**
+			??? abstract "Example"
+				```java title="MemberExample.java"
+				public class MemberExample {
+
+					public static void register() {
+						MinecraftForge.EVENT_BUS.register(new EventListener());
+					}
+
+					public static class EventListener {
+
+						@SubscribeEvent
+						public void thisListenerWillRun(Event event) {
+							// This method is not static
+							// This block of code will run when whichever Event is denoted in the argument
+						}
+
+						@SubscribeEvent
+						public static void thisListenerWillNeverRun(Event event) {
+							// This method is static
+						}
+
+					}
+
+				}
+				```

mod_development/sounds/play_sound.md → docs/mod-development/game-object/sound/play.md

@@ -1,4 +1,3 @@
-## Playing Sounds
 - There are numerous of ways to play a sound within Minecraft.
 - The methods of doing so frequently get mixed up as the overload parameters are very alike.
 - They also differ depending on which logical side you are on, and how you want the sound to be perceived.

mod_development/sidedness.md → docs/mod-development/sidedness.md

@@ -1,42 +1,32 @@
-## Sidedness
-
-#### *Index:*
-
-0. Definitions & Explanations
-1. `@Mod` parameters: `clientSideOnly` and `serverSideOnly`
-2. `@SideOnly` Annotation
-3. `@NetworkCheckHandler` Annotation
-4. Credits
-
-#### 0. Introduction
+### ^^Introduction^^
 There are two ***sides*** in Minecraft, `client` and `server`. Not only are there two ***sides***, each ***side*** has a `physical` and `logical` differentiation.
 
 - `Physical Client`: The program that runs whenever you launch Minecraft. All threads and processes that run during the game’s graphical, interact-able lifetime are part of it.
 - `Physical Server`: Also known as the `Dedicated Server`, it is the program that runs whenever you launch the server executable that does not bring up a playable GUI.
 - `Logical Client`: Anything that happens in the `Client Thread`. It accepts inputs from the player and sends them to the `Server Thread`, it also accepts information from the `Server Thread` so it can display information corresponding to the game logic graphically for the player.
 - `Logical Server`: Anything that happens in the `Server Thread`. This thread will spawn on both the `Physical Client` and `Physical Server`. This thread deals with the game logic: mob spawning, weather, inventories, health and more.
 
-#### 1. `@Mod` parameters: `clientSideOnly` and `serverSideOnly`
-Does exactly what it says on the tin.
+### ^^`@Mod`^^
+The parameters for `@Mod`: `clientSideOnly` and `serverSideOnly` - does exactly what it says on the tin.
 
 This is by far the best way to control your mod from only loading on a specific **physical side**. As it does this at the very beginning of mod loading process.
 
 However, the mod will not show up on the mod list, if that is less than desired, you will have to check out the annotations below.
 
-#### 2. `@SideOnly` Annotation
+### ^^`@SideOnly`^^
 Annotation a class, field, method or constructor will tell Forge that this particular member should be **stripped** out of the loading process on the specified **physical side** (see: `net.minecraftforge.fml.common.asm.transformers.SideTransformer`).
 
 Usually only Minecraft and Forge code utilizes this. For Minecraft, Forge uses it to mark the members that Mojang's obfuscator had stripped out.
 
 You should only annotate `@SideOnly` when you are **100% sure** that the member isn't needed for a particular **physical side**.
 Misusing this annotation may bring up crashes that are extremely hard to read (especially during class transformation).
 
-#### 3. `@NetworkCheckHandler` Annotation
+### ^^`@NetworkCheckHandler`^^
 A somewhat obscure annotation that helps when you are creating a mod that needs to query **physical side** information.
 
 - Syntax: In your `@Mod` class, create a method of any name that takes in the parameters `(Map<String, String>, net.minecraftforge.fml.relauncher.Side)` and allow it to return a `boolean`.
 
 During handshaking, when the `Physical Client` loads into a `Physical Server`, two things happen. On the `Physical Server`, it calls the `@NetworkCheckHandler` annotated method (if present) to see if the player should be stopped from joining, and vice-versa on the `Physical Client`.
 
-#### 4. Credits
-- Thanks to [Forge Community Wiki](https://forge.gemwire.uk/wiki/Sides) for a fleshed out description.
+[^1]:
+    Thanks to [Forge Community Wiki](https://forge.gemwire.uk/wiki/Sides) for a fleshed out description.