diff --git a/docusaurus.config.js b/docusaurus.config.js
index 1196920f..befefbf4 100644
--- a/docusaurus.config.js
+++ b/docusaurus.config.js
@@ -47,6 +47,9 @@ const config = {
           includeCurrentVersion: true,
           versions: {
             current: {
+              label: "1.21.4",
+            },
+            "1.21.3": {
               label: "1.21.2 - 1.21.3",
             },
             "1.21.1": {
diff --git a/versioned_docs/version-1.21.3/advanced/_category_.json b/versioned_docs/version-1.21.3/advanced/_category_.json
new file mode 100644
index 00000000..2161114e
--- /dev/null
+++ b/versioned_docs/version-1.21.3/advanced/_category_.json
@@ -0,0 +1,4 @@
+{
+    "label": "Advanced Topics",
+    "position": 12
+}
\ No newline at end of file
diff --git a/versioned_docs/version-1.21.3/advanced/accesstransformers.md b/versioned_docs/version-1.21.3/advanced/accesstransformers.md
new file mode 100644
index 00000000..838b759d
--- /dev/null
+++ b/versioned_docs/version-1.21.3/advanced/accesstransformers.md
@@ -0,0 +1,147 @@
+# Access Transformers
+
+Access Transformers (ATs for short) allow for widening the visibility and modifying the `final` flags of classes, methods, and fields. They allow modders to access and modify otherwise inaccessible members in classes outside their control.
+
+The [specification document][specs] can be viewed on the NeoForged GitHub.
+
+## Adding ATs
+
+Adding an Access Transformer to your mod project is as simple as adding a single line into your `build.gradle`:
+
+Access Transformers need to be declared in `build.gradle`. AT files can be specified anywhere as long as they are copied to the `resources` output directory on compilation.
+
+```groovy
+// In build.gradle:
+// This block is where your mappings version is also specified
+minecraft {
+    accessTransformers {
+        file('src/main/resources/META-INF/accesstransformer.cfg')
+    }
+}
+```
+
+By default, NeoForge will search for `META-INF/accesstransformer.cfg`. If the `build.gradle` specifies access transformers in any other location, then their location needs to be defined within `neoforge.mods.toml`:
+
+```toml
+# In neoforge.mods.toml:
+[[accessTransformers]]
+## The file is relative to the output directory of the resources, or the root path inside the jar when compiled
+## The 'resources' directory represents the root output directory of the resources
+file="META-INF/accesstransformer.cfg"
+```
+
+Additionally, multiple AT files can be specified and will be applied in order. This can be useful for larger mods with multiple packages.
+
+```groovy
+// In build.gradle:
+minecraft {
+    accessTransformers {
+        file('src/main/resources/accesstransformer_main.cfg')
+        file('src/additions/resources/accesstransformer_additions.cfg')
+    }
+}
+```
+
+```toml
+# In neoforge.mods.toml
+[[accessTransformers]]
+file="accesstransformer_main.cfg"
+
+[[accessTransformers]]
+file="accesstransformer_additions.cfg"
+```
+
+After adding or modifying any Access Transformer, the Gradle project must be refreshed for the transformations to take effect.
+
+## The Access Transformer Specification
+
+### Comments
+
+All text after a `#` until the end of the line will be treated as a comment and will not be parsed.
+
+### Access Modifiers
+
+Access modifiers specify to what new member visibility the given target will be transformed to. In decreasing order of visibility:
+
+- `public` - visible to all classes inside and outside its package
+- `protected` - visible only to classes inside the package and subclasses
+- `default` - visible only to classes inside the package
+- `private` - visible only to inside the class
+
+A special modifier `+f` and `-f` can be appended to the aforementioned modifiers to either add or remove respectively the `final` modifier, which prevents subclassing, method overriding, or field modification when applied.
+
+:::danger
+Directives only modify the method they directly reference; any overriding methods will not be access-transformed. It is advised to ensure transformed methods do not have non-transformed overrides that restrict the visibility, which will result in the JVM throwing an error.
+
+Examples of methods that can be safely transformed are `private` methods, `final` methods (or methods in `final` classes), and `static` methods.
+:::
+
+### Targets and Directives
+
+#### Classes
+
+To target classes:
+
+```
+<access modifier> <fully qualified class name>
+```
+
+Inner classes are denoted by combining the fully qualified name of the outer class and the name of the inner class with a `$` as separator.
+
+#### Fields
+
+To target fields:
+
+```
+<access modifier> <fully qualified class name> <field name>
+```
+
+#### Methods
+
+Targeting methods require a special syntax to denote the method parameters and return type:
+
+```
+<access modifier> <fully qualified class name> <method name>(<parameter types>)<return type>
+```
+
+##### Specifying Types
+
+Also called "descriptors": see the [Java Virtual Machine Specification, SE 21, sections 4.3.2 and 4.3.3][jvmdescriptors] for more technical details.
+
+- `B` - `byte`, a signed byte
+- `C` - `char`, a Unicode character code point in UTF-16
+- `D` - `double`, a double-precision floating-point value
+- `F` - `float`, a single-precision floating-point value
+- `I` - `integer`, a 32-bit integer
+- `J` - `long`, a 64-bit integer
+- `S` - `short`, a signed short
+- `Z` - `boolean`, a `true` or `false` value
+- `[` - references one dimension of an array
+    - Example: `[[S` refers to `short[][]`
+- `L<class name>;` - references a reference type
+    - Example: `Ljava/lang/String;` refers to `java.lang.String` reference type _(note the use of slashes instead of periods)_
+- `(` - references a method descriptor, parameters should be supplied here or nothing if no parameters are present
+    - Example: `<method>(I)Z` refers to a method that requires an integer argument and returns a boolean
+- `V` - indicates a method returns no value, can only be used at the end of a method descriptor
+    - Example: `<method>()V` refers to a method that has no arguments and returns nothing
+
+### Examples
+
+```
+# Makes public the ByteArrayToKeyFunction interface in Crypt
+public net.minecraft.util.Crypt$ByteArrayToKeyFunction
+
+# Makes protected and removes the final modifier from 'random' in MinecraftServer
+protected-f net.minecraft.server.MinecraftServer random
+
+# Makes public the 'makeExecutor' method in Util,
+# accepting a String and returns a TracingExecutor
+public net.minecraft.Util makeExecutor(Ljava/lang/String;)Lnet/minecraft/TracingExecutor;
+
+# Makes public the 'leastMostToIntArray' method in UUIDUtil,
+# accepting two longs and returning an int[]
+public net.minecraft.core.UUIDUtil leastMostToIntArray(JJ)[I
+```
+
+[specs]: https://github.com/NeoForged/AccessTransformers/blob/main/FMLAT.md
+[jvmdescriptors]: https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.3.2
diff --git a/versioned_docs/version-1.21.3/advanced/extensibleenums.md b/versioned_docs/version-1.21.3/advanced/extensibleenums.md
new file mode 100644
index 00000000..d3532304
--- /dev/null
+++ b/versioned_docs/version-1.21.3/advanced/extensibleenums.md
@@ -0,0 +1,148 @@
+# Extensible Enums
+
+Extensible Enums are an enhancement of specific Vanilla enums to allow new entries to be added. This is done by modifying the compiled bytecode of the enum at runtime to add the elements.
+
+## `IExtensibleEnum`
+
+All enums that can have new entries implement the `IExtensibleEnum` interface. This interface acts as a marker to allow the `RuntimeEnumExtender` launch plugin service to know what enums should be transformed.
+
+:::warning
+You should **not** be implementing this interface on your own enums. Use maps or registries instead depending on your usecase.  
+Enums which are not patched to implement the interface cannot have the interface added to them via mixins or coremods due to the order the transformers run in.
+:::
+
+### Creating an Enum Entry
+
+To create new enum entries, a JSON file needs to be created and referenced in the `neoforge.mods.toml` with the `enumExtensions` entry of a `[[mods]]` block. The specified path must be relative to the `resources` directory:
+```toml
+# In neoforge.mods.toml:
+[[mods]]
+## The file is relative to the output directory of the resources, or the root path inside the jar when compiled
+## The 'resources' directory represents the root output directory of the resources
+enumExtensions="META-INF/enumextensions.json"
+```
+
+The definition of the entry consists of the target enum's class name, the new field's name (must be prefixed with the mod ID), the descriptor of the constructor to use for constructing the entry and the parameters to be passed to said constructor.
+
+```json5
+{
+    "entries": [
+        {
+            // The enum class the entry should be added to
+            "enum": "net/minecraft/world/item/ItemDisplayContext",
+            // The field name of the new entry, must be prefixed with the mod ID
+            "name": "EXAMPLEMOD_STANDING",
+            // The constructor to be used
+            "constructor": "(ILjava/lang/String;Ljava/lang/String;)V",
+            // Constant parameters provided directly.
+            "parameters": [ -1, "examplemod:standing", null ]
+        },
+        {
+            "enum": "net/minecraft/world/item/Rarity",
+            "name": "EXAMPLEMOD_CUSTOM",
+            "constructor": "(ILjava/lang/String;Ljava/util/function/UnaryOperator;)V",
+            // The parameters to be used, provided as a reference to an EnumProxy<Rarity> field in the given class
+            "parameters": {
+                "class": "example/examplemod/MyEnumParams",
+                "field": "CUSTOM_RARITY_ENUM_PROXY"
+            }
+        },
+        {
+            "enum": "net/minecraft/world/damagesource/DamageEffects",
+            "name": "EXAMPLEMOD_TEST",
+            "constructor": "(Ljava/lang/String;Ljava/util/function/Supplier;)V",
+            // The parameters to be used, provided as a reference to a method in the given class
+            "parameters": {
+                "class": "example/examplemod/MyEnumParams",
+                "method": "getTestDamageEffectsParameter"
+            }
+        }
+    ]
+}
+```
+
+```java
+public class MyEnumParams {
+    public static final EnumProxy<Rarity> CUSTOM_RARITY_ENUM_PROXY = new EnumProxy<>(
+            Rarity.class, -1, "examplemod:custom", (UnaryOperator<Style>) style -> style.withItalic(true)
+    );
+    
+    public static Object getTestDamageEffectsParameter(int idx, Class<?> type) {
+        return type.cast(switch (idx) {
+            case 0 -> "examplemod:test";
+            case 1 -> (Supplier<SoundEvent>) () -> SoundEvents.DONKEY_ANGRY;
+            default -> throw new IllegalArgumentException("Unexpected parameter index: " + idx);
+        });
+    }
+}
+```
+
+#### Constructor
+
+The constructor must be specified as a [method descriptor][jvmdescriptors] and must only contain the parameters visible in the source code, omitting the hidden constant name and ordinal parameters.  
+If a constructor is marked with the `@ReservedConstructor` annotation, then it cannot be used for modded enum constants.
+
+#### Parameters
+
+The parameters can be specified in three ways with limitations depending on the parameter types:
+
+- Inline in the JSON file as an array of constants (only allowed for primitive values, Strings and for passing null to any reference type)
+- As a reference to a field of type `EnumProxy<TheEnum>` in a class from the mod (see `EnumProxy` example above)
+    - The first parameter specifies the target enum and the subsequent parameters are the ones to be passed to the enum constructor
+- As a reference to a method returning `Object`, where the return value is the parameter value to use. The method must have exactly two parameters of type `int` (index of the parameter) and `Class<?>` (expected type of the parameter)
+    - The `Class<?>` object should be used to cast (`Class#cast()`) the return value in order to keep `ClassCastException`s in mod code.
+
+:::warning
+The fields and/or methods used as sources for parameter values should be in a separate class to avoid unintentionally loading mod classes too early.
+:::
+
+Certain parameters have additional rules:
+
+- If the parameter is an int ID parameter related to a `@IndexedEnum` annotation on the enum, then it is ignored and replaced by the entry's ordinal. If said parameter is specified inline in the JSON, then it must be specified as `-1`, otherwise an exception is thrown.
+- If the parameter is a String name parameter related to a `@NamedEnum` annotation on the enum, then it must be prefixed by the mod ID in the `namespace:path` format known from `ResourceLocation`s, otherwise an exception is thrown.
+
+#### Retrieving the Generated Constant
+
+The generated enum constant can be retrieved via `TheEnum.valueOf(String)`. If a field reference is used to provide the parameters, then the constant can also be retrieved from the `EnumProxy` object via `EnumProxy#getValue()`.
+
+## Contributing to NeoForge
+
+To add a new extensible enum to NeoForge, there are at least two required things to do:
+
+- Make the enum implement `IExtensibleEnum` to mark that this enum should be transformed via the `RuntimeEnumExtender`.
+- Add a `getExtensionInfo` method that returns `ExtensionInfo.nonExtended(TheEnum.class)`.
+
+Further action is required depending on specific details about the enum:
+
+- If the enum has an int ID parameter which should match the entry's ordinal, then the enum should be annotated with `@NumberedEnum` with the ID's parameter index as the annotation's value if it's not the first parameter
+- If the enum has a String name parameter which is used for serialization and should therefore be namespaced, then the enum should be annotated with `@NamedEnum` with the name's parameter index as the annotation's value if it's not the first parameter
+- If the enum is sent over the network, then it should be annotated with `@NetworkedEnum` with the annotation's parameter specifying in which direction the values may be sent (clientbound, serverbound or bidirectional)
+- If the enum has constructors which are not usable by mods (i.e. because they require registry objects on an enum that may be initialized before modded registration runs), then they should be annotated with `@ReservedConstructor`
+
+:::note
+The `getExtensionInfo` method will be transformed at runtime to provide a dynamically generated `ExtensionInfo` if the enum actually had any entries added to it.
+:::
+
+```java
+// This is an example, not an actual enum within Vanilla
+public enum ExampleEnum implements net.neoforged.fml.common.asm.enumextension.IExtensibleEnum {
+    // VALUE_1 represents the name parameter here
+    VALUE_1(0, "value_1", false),
+    VALUE_2(1, "value_2", true),
+    VALUE_3(2, "value_3");
+
+    ExampleEnum(int arg1, String arg2, boolean arg3) {
+        // ...
+    }
+
+    ExampleEnum(int arg1, String arg2) {
+        this(arg1, arg2, false);
+    }
+
+    public static net.neoforged.fml.common.asm.enumextension.ExtensionInfo getExtensionInfo() {
+        return net.neoforged.fml.common.asm.enumextension.ExtensionInfo.nonExtended(ExampleEnum.class);
+    }
+}
+```
+
+[jvmdescriptors]: https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.3.2
diff --git a/versioned_docs/version-1.21.3/advanced/featureflags.md b/versioned_docs/version-1.21.3/advanced/featureflags.md
new file mode 100644
index 00000000..d6d72a76
--- /dev/null
+++ b/versioned_docs/version-1.21.3/advanced/featureflags.md
@@ -0,0 +1,287 @@
+# Feature Flags
+
+Feature flags are a system that allows developers to gate a set of features behind some set of required flags, that being registered elements, gameplay mechanics, data pack entries or some other unique system to your mod.
+
+A common use case would be gating experimental features/elements behind a experimental flag, allowing users to easily switch them on and play around with them before they are finalized.
+
+:::tip
+You are not forced to add your own flags. If you find a vanilla flag which would fit your use case, feel free to flag your blocks/items/entities/etc. with said flag.
+
+For example in `1.21.3` if you were to add to the set of Pale Oak wood blocks, you'd only want those to show up if the `WINTER_DROP` flag is enabled.
+:::
+
+## Creating a Feature Flag
+
+To create new Feature flags, a JSON file needs to be created and referenced in your `neoforge.mods.toml` file with the `featureFlags` entry inside of your `[[mods]]` block. The specified path must be relative to the `resources` directory:
+
+```toml
+# In neoforge.mods.toml:
+[[mods]]
+    # The file is relative to the output directory of the resources, or the root path inside the jar when compiled
+    # The 'resources' directory represents the root output directory of the resources
+    featureFlags="META-INF/feature_flags.json"
+```
+
+The definition of the entry consists of a list of Feature flag names, which will be loaded and registered during game initialization.
+
+```json5
+{
+    "flags": [
+        // Identifier of a Feature flag to be registered
+        "examplemod:experimental"
+    ]
+}
+```
+
+## Retrieving the Feature Flag
+
+The registered Feature flag can be retrieved via `FeatureFlagRegistry.getFlag(ResourceLocation)`. This can be done at any time during your mod's initialization and is recommended to be stored somewhere for future use, rather than looking up the registry each time you require your flag.
+
+```java
+// Look up the 'examplemod:experimental' Feature flag
+public static final FeatureFlag EXPERIMENTAL = FeatureFlags.REGISTRY.getFlag(ResourceLocation.fromNamespaceAndPath("examplemod", "experimental"));
+```
+
+## Feature Elements
+
+`FeatureElement`s are registry values which can be given a set of required flags. These values are only made available to players when the respective required flags match the flags enabled in the level.
+
+When a feature element is disabled, it is fully hidden from the player's view, and all interactions will be skipped. Do note that these disabled elements will still exist in the registry and are merely functionally unusable.
+
+The following is a complete list of all registries which directly implement the `FeatureElement` system:
+
+- Item
+- Block
+- EntityType
+- MenuType
+- Potion
+- MobEffect
+
+### Flagging Elements
+
+In order to flag a given `FeatureElement` as requiring your Feature flag, you simply pass it and any other desired flags into the respective registration method:
+
+- `Item`: `Item.Properties#requiredFeatures`
+- `Block`: `BlockBehaviour.Properties#requiredFeatures`
+- `EntityType`: `EntityType.Builder#requiredFeatures`
+- `MenuType`: `MenuType#new`
+- `Potion`: `Potion#requiredFeatures`
+- `MobEffect`: `MobEffect#requiredFeatures`
+
+```java
+// These elements will only become available once the 'EXPERIMENTAL' flag is enabled
+
+// Item
+DeferredRegister.Items ITEMS = DeferredRegister.createItems("examplemod");
+DeferredItem<Item> EXPERIMENTAL_ITEM = ITEMS.registerSimpleItem("experimental", new Item.Properties()
+    .requiredFeatures(EXPERIMENTAL) // mark as requiring the 'EXPERIMENTAL' flag
+);
+
+// Block
+DeferredRegister.Blocks BLOCKS = DeferredRegister.createBlocks("examplemod");
+// Do note that BlockBehaviour.Properties#ofFullCopy and BlockBehaviour.Properties#ofLegacyCopy will copy over the required features.
+// This means that in 1.21.3, using BlockBehaviour.Properties.ofFullCopy(Blocks.PALE_OAK_WOOD) would have your block require the 'WINTER_DROP' flag.
+DeferredBlock<Block> EXPERIMENTAL_BLOCK = BLOCKS.registerSimpleBlock("experimental", BlockBehaviour.Properties.of()
+    .requiredFeatures(EXPERIMENTAL) // mark as requiring the 'EXPERIMENTAL' flag
+);
+
+// BlockItems are special in that the required features are inherited from their respective Blocks.
+// The same is also true for spawn eggs and their respective EntityTypes.
+DeferredItem<BlockItem> EXPERIMENTAL_BLOCK_ITEM = ITEMS.registerSimpleBlockItem(EXPERIMENTAL_BLOCK);
+
+// EntityType
+DeferredRegister<EntityType<?>> ENTITY_TYPES = DeferredRegister.create(Registries.ENTITY_TYPE, "examplemod");
+DeferredHolder<EntityType<?>, EntityType<ExperimentalEntity>> EXPERIMENTAL_ENTITY = ENTITY_TYPES.register("experimental", registryName -> EntityType.Builder.of(ExperimentalEntity::new, MobCategory.AMBIENT)
+    .requiredFeatures(EXPERIMENTAL) // mark as requiring the 'EXPERIMENTAL' flag
+    .build(ResourceKey.create(Registries.ENTITY_TYPE, registryName))
+);
+
+// MenuType
+DeferredRegister<MenuType<?>> MENU_TYPES = DeferredRegister.create(Registries.MENU, "examplemod");
+DeferredHolder<MenuType<?>, MenuType<ExperimentalMenu>> EXPERIMENTAL_MENU = MENU_TYPES.register("experimental", () -> new MenuType<>(
+    // Using vanilla's MenuSupplier:
+    // This is used when your menu is not encoding complex data during `player.openMenu`. Example:
+    // (windowId, inventory) -> new ExperimentalMenu(windowId, inventory),
+
+    // Using NeoForge's IContainerFactory:
+    // This is used when you wish to read complex data encoded during `player.openMenu`.
+    // Casting is important here, as `MenuType` specifically expects a `MenuSupplier`.
+    (IContainerFactory<ExperimentalMenu>) (windowId, inventory, buffer) -> new ExperimentalMenu(windowId, inventory, buffer),
+    
+    FeatureFlagSet.of(EXPERIMENTAL) // mark as requiring the 'EXPERIMENTAL' flag
+));
+
+// MobEffect
+DeferredRegister<MobEffect> MOB_EFFECTS = DeferredRegister.create(Registries.MOB_EFFECT, "examplemod");
+DeferredHolder<MobEffect, ExperimentalMobEffect> EXPERIMENTAL_MOB_EEFECT = MOB_EFFECTS.register("experimental", registryName -> new ExperimentalMobEffect(MobEffectCategory.NEUTRAL, CommonColors.WHITE)
+    .requiredFeatures(EXPERIMENTAL) // mark as requiring the 'EXPERIMENTAL' flag
+);
+
+// Potion
+DeferredRegister<Potion> POTIONS = DeferredRegister.create(Registries.POTION, "examplemod");
+DeferredHolder<Potion, ExperimentalPotion> EXPERIMENTAL_POTION = POTIONS.register("experimental", registryName -> new ExperimentalPotion(registryName.toString(), new MobEffectInstance(EXPERIMENTAL_MOB_EEFECT))
+    .requiredFeatures(EXPERIMENTAL) // mark as requiring the 'EXPERIMENTAL' flag
+);
+```
+
+### Validating Enabled Status
+
+In order to validate if features should be enabled or not, you must first acquire the set of enabled features. This can be done in a variety of ways, but the common and recommended method is `LevelReader#enabledFeatures`.  
+
+```java
+level.enabledFeatures(); // from a 'LevelReader' instance
+entity.level().enabledFeatures(); // from a 'Entity' instance
+
+// Client Side
+minecraft.getConnection().enabledFeatures();
+
+// Server Side
+server.getWorldData().enabledFeatures();
+```
+
+To validate if any `FeatureFlagSet` is enabled, you can pass the enabled features to `FeatureFlagSet#isSubsetOf`, and for validating if a specific `FeatureElement` is enabled, you can invoke `FeatureElement#isEnabled`.
+
+:::note
+`ItemStack` has a special `isItemEnabled(FeatureFlagSet)` method. This is so that empty stacks are treated as enabled even if the required features for the backing `Item` do not match the enabled features. It is recommended to prefer this method over `Item#isEnabled` where possible.
+:::
+
+```java
+requiredFeatures.isSubsetOf(enabledFeatures);
+featureElement.isEnabled(enabledFeatures);
+itemStack.isItemEnabled(enabledFeatures);
+```
+
+## Feature Packs
+
+_See also: [Resource Packs](../resources/index.md#assets), [Data Packs](../resources/index.md#data) and [Pack.mcmeta](../resources/index.md#packmcmeta)_
+
+Feature packs are a type of pack that not only loads resources and/or data, but also has the ability to toggle on a given set of feature flags. These flags are defined in the `pack.mcmeta` JSON file at the root of this pack, which follows the below format:
+
+:::note
+This file differs from the one in your mod's `resources/` directory. This file defines a brand new feature pack and thus must be in its own folder.
+:::
+
+```json5
+{
+    "features": {
+        "enabled": [
+            // Identifier of a Feature flag to be enabled
+            // Must be a valid registered flag
+            "examplemod:experimental"
+        ]
+    },
+    "pack": { /*...*/ }
+}
+```
+
+There are a couple of ways for users to obtain a feature pack, namely installing them from an external source as a datapack, or downloading a mod that has a built-in feature pack. Both of these then need to be installed differently depending on the [physical side](../concepts/sides.md).
+
+### Built-In
+
+Built-in packs are bundled with your mod and are made available to the game using the `AddPackFindersEvent` event.
+
+```java
+@SubscribeEvent
+public static void addFeaturePacks(final AddPackFindersEvent event) {
+    event.addPackFinders(
+            // Path relative to your mods 'resources' pointing towards this pack
+            // Take note this also defines your packs id using the following format
+            // mod/<namespace>:<path>`, e.g. `mod/examplemod:data/examplemod/datapacks/experimental`
+            ResourceLocation.fromNamespaceAndPath("examplemod", "data/examplemod/datapacks/experimental"),
+            
+            // What kind of resources are contained within this pack
+            // 'CLIENT_RESOURCES' for packs with client assets (resource packs)
+            // 'SERVER_DATA' for packs with server data (data packs)
+            PackType.SERVER_DATA,
+            
+            // Display name shown in the Experiments screen
+            Component.literal("ExampleMod: Experiments"),
+            
+            // In order for this pack to load and enable feature flags, this MUST be 'FEATURE',
+            // any other PackSource type is invalid here
+            PackSource.FEATURE,
+            
+            // If this is true, the pack is always active and cannot be disabled, should always be false for feature packs
+            false,
+            
+            // Priority to load resources from this pack in
+            // 'TOP' this pack will be prioritized over other packs
+            // 'BOTTOM' other packs will be prioritized over this pack 
+            Pack.Position.TOP
+    );
+}
+```
+
+#### Enabling in Singleplayer
+
+1. Create a new world.
+2. Navigate to the Experiments screen.
+3. Toggle on the desired packs.
+4. Confirm changes by clicking `Done`.
+
+#### Enabling in Multiplayer
+
+1. Open your server's `server.properties` file.
+2. Add the feature pack id to `initial-enabled-packs`, separating each pack by a `,`. The pack id is defined during registering your pack finder, as seen above.
+
+### External
+
+External packs are provided to your users in datapack form.
+
+#### Installation in Singleplayer
+
+1. Create a new world.
+2. Navigate to the datapack selection screen.
+3. Drag and drop the datapack zip file onto the game window.
+4. Move the newly available datapack over to the `Selected` packs list.
+5. Confirm changes by clicking `Done`.
+
+The game will now warn you about any newly selected experimental features, potential bugs, issues and crashes. You can confirm these changes by clicking `Proceed` or `Details` to see an extensive list of all selected packs and which features they would enable.
+
+:::note
+External feature packs do not show up in the Experiments screen. The Experiments screen will only show built-in feature packs.
+
+To disable external feature packs after enabling them, navigate back into the datapacks screen and move the external packs back into `Available` from `Selected`.
+:::
+
+#### Installation in Multiplayer
+
+Enabling Feature Packs can only be done during initial world creation, and they cannot be disabled once enabled.
+
+1. Create the directory `./world/datapacks`
+2. Upload the datapack zip file into the newly created directory
+3. Open your server's `server.properties` file
+4. Add the datapack zip file name (excluding `.zip`) to `initial-enabled-packs` (separating each pack by a `,`)
+   - Example: The zip `examplemod-experimental.zip` would be added like so `initial-enabled-packs=vanilla,examplemod-experimental`
+
+### Data Generation
+
+_See also: [Datagen](../resources/index.md#data-generation)_
+
+Feature packs can be generated during regular mod datagen. This is best used in combination with built-in packs, but it is also possible to zip up the generated result and share it as an external pack. Just choose one, i.e. don't provide it as an external pack and also bundle it as a built-in pack.
+
+```java
+@SubscribeEvent
+public static void gatherData(final GatherDataEvent event) {
+    DataGenerator generator = event.getGenerator();
+    
+    // To generate a feature pack, you must first obtain a pack generator instance for the desired pack.
+    // generator.getBuiltinDatapack(<shouldGenerate>, <namespace>, <path>);
+    // This will generate the feature pack into the following path:
+    // ./data/<namespace>/datapacks/<path>
+    PackGenerator featurePack = generator.getBuiltinDatapack(true, "examplemod", "experimental");
+        
+    // Register a provider to generate the `pack.mcmeta` file.
+    featurePack.addProvider(output -> PackMetadataGenerator.forFeaturePack(
+            output,
+            
+            // Description displayed in the Experiments screen
+            Component.literal("Enabled experimental features for ExampleMod"),
+            
+            // Set of Feature flags this pack should enable
+            FeatureFlagSet.of(EXPERIMENTAL)
+    ));
+    
+    // Register additional providers (recipes, loot tables) to `featurePack` to write any generated resources into this pack, rather than the root pack.
+}
+```
diff --git a/versioned_docs/version-1.21.3/blockentities/_category_.json b/versioned_docs/version-1.21.3/blockentities/_category_.json
new file mode 100644
index 00000000..3b6467c0
--- /dev/null
+++ b/versioned_docs/version-1.21.3/blockentities/_category_.json
@@ -0,0 +1,4 @@
+{
+    "label": "Block Entities",
+    "position": 6
+}
\ No newline at end of file
diff --git a/versioned_docs/version-1.21.3/blockentities/ber.md b/versioned_docs/version-1.21.3/blockentities/ber.md
new file mode 100644
index 00000000..ef0d8262
--- /dev/null
+++ b/versioned_docs/version-1.21.3/blockentities/ber.md
@@ -0,0 +1,133 @@
+# BlockEntityRenderer
+
+A `BlockEntityRenderer`, often abbreviated as BER, is used to render [blocks][block] in a way that cannot be represented with a [static baked model][model] (JSON, OBJ, others). For example, this could be used to dynamically render container contents of a chest-like block. A block entity renderer requires the block to have a [`BlockEntity`][blockentity], even if the block does not store any data otherwise.
+
+To create a BER, create a class that inherits from `BlockEntityRenderer`. It takes a generic argument specifying the block's `BlockEntity` class, which is used as a parameter type in the BER's `render` method.
+
+```java
+// Assumes the existence of MyBlockEntity as a subclass of BlockEntity.
+public class MyBlockEntityRenderer implements BlockEntityRenderer<MyBlockEntity> {
+    // Add the constructor parameter for the lambda below. You may also use it to get some context
+    // to be stored in local fields, such as the entity renderer dispatcher, if needed.
+    public MyBlockEntityRenderer(BlockEntityRendererProvider.Context context) {
+    }
+    
+    // This method is called every frame in order to render the block entity. Parameters are:
+    // - blockEntity:   The block entity instance being rendered. Uses the generic type passed to the super interface.
+    // - partialTick:   The amount of time, in fractions of a tick (0.0 to 1.0), that has passed since the last tick.
+    // - poseStack:     The pose stack to render to.
+    // - bufferSource:  The buffer source to get vertex buffers from.
+    // - packedLight:   The light value of the block entity.
+    // - packedOverlay: The current overlay value of the block entity, usually OverlayTexture.NO_OVERLAY.
+    @Override
+    public void render(MyBlockEntity blockEntity, float partialTick, PoseStack stack, MultiBufferSource bufferSource, int packedLight, int packedOverlay) {
+        // Do the rendering here.
+    }
+}
+```
+
+Only one BER may exist for a given `BlockEntityType<?>`. Therefore, values that are specific to a single block entity instance should be stored in that block entity instance, rather than the BER itself.
+
+When you have created your BER, you must also register it to `EntityRenderersEvent.RegisterRenderers`, an [event] fired on the [mod event bus][eventbus]:
+
+```java
+@SubscribeEvent
+public static void registerEntityRenderers(EntityRenderersEvent.RegisterRenderers event) {
+    event.registerBlockEntityRenderer(
+            // The block entity type to register the renderer for.
+            MyBlockEntities.MY_BLOCK_ENTITY.get(),
+            // A function of BlockEntityRendererProvider.Context to BlockEntityRenderer.
+            MyBlockEntityRenderer::new
+    );
+}
+```
+
+In the event that you do not need the BER provider context in your BER, you can also remove the constructor:
+
+```java
+public class MyBlockEntityRenderer implements BlockEntityRenderer<MyBlockEntity> {
+    @Override
+    public void render( /* ... */ ) { /* ... */ }
+}
+
+// In your event handler class
+@SubscribeEvent
+public static void registerEntityRenderers(EntityRenderersEvent.RegisterRenderers event) {
+    event.registerBlockEntityRenderer(MyBlockEntities.MY_BLOCK_ENTITY.get(),
+            // Pass the context to an empty (default) constructor call
+            context -> new MyBlockEntityRenderer()
+    );
+}
+```
+
+## `BlockEntityWithoutLevelRenderer`
+
+`BlockEntityWithoutLevelRenderer`, colloquially known as BEWLR, is an adaptation of the regular `BlockEntityRenderer` for special [item] rendering (hence "without level", as items do not have level context). Its overall purpose is the same: do special rendering for cases where static models aren't enough.
+
+To add a BEWLR, create a class that extends `BlockEntityWithoutLevelRenderer` and overrides `#renderByItem`. It also requires some additional constructor setup:
+
+```java
+public class MyBlockEntityWithoutLevelRenderer extends BlockEntityWithoutLevelRenderer {
+    // We need some boilerplate in the constructor, telling the superclass where to find the central block entity and entity renderers.
+    public MyBlockEntityWithoutLevelRenderer() {
+        super(Minecraft.getInstance().getBlockEntityRenderDispatcher(), Minecraft.getInstance().getEntityModels());
+    }
+    
+    @Override
+    public void renderByItem(ItemStack stack, ItemDisplayContext transform, PoseStack poseStack, MultiBufferSource bufferSource, int packedLight, int packedOverlay) {
+        // Do the rendering here.
+    }
+}
+```
+
+Keep in mind that, like with BERs, there is only one instance of your BEWLR. Stack-specific properties should therefore be stored in the stack, not the BEWLR.
+
+Unlike BERs, we do not register BEWLRs directly. Instead, we register an instance of `IClientItemExtensions` to the `RegisterClientExtensionsEvent`. `IClientItemExtensions` is an interface that allows us to specify a number of rendering-related behaviors on items, such as (but not limited to) a BEWLR. As such, our implementation of that interface could look like so:
+
+```java
+public class MyClientItemExtensions implements IClientItemExtensions {
+    // Cache our BEWLR in a field.
+    private final MyBlockEntityWithoutLevelRenderer myBEWLR = new MyBlockEntityWithoutLevelRenderer();
+
+    // Return our BEWLR here.
+    @Override
+    public BlockEntityWithoutLevelRenderer getCustomRenderer() {
+        return myBEWLR;
+    }
+}
+```
+
+And then, we can register our `IClientItemExtensions` to the event:
+
+```java
+@SubscribeEvent
+public static void registerClientExtensions(RegisterClientExtensionsEvent event) {
+    event.registerItem(
+            // The only instance of our IClientItemExtensions, and as such, the only instance of our BEWLR.
+            new MyClientItemExtensions(),
+            // A vararg list of items that use this BEWLR.
+            MyItems.ITEM_1, MyItems.ITEM_2
+    );
+}
+```
+
+:::info
+`IClientItemExtensions` are generally expected to be treated as singletons. Do not construct them outside `RegisterClientExtensionsEvent`!
+:::
+
+Finally, the item has to know that it should use the BEWLR for its rendering. This is done by having the final [`BakedModel`][bakedmodel] return true for `#isCustomRenderer`. The easiest way to do this is to have the [item model JSON][model] with a `parent` of `minecraft:builtin/entity`:
+
+```json5
+// In some item model file assets/<mod_id>/models/item/<registry_name>.json
+{
+    "parent": "minecraft: builtin/entity",
+    // ...
+}
+```
+
+[block]: ../blocks/index.md
+[blockentity]: index.md
+[event]: ../concepts/events.md#registering-an-event-handler
+[eventbus]: ../concepts/events.md#event-buses
+[item]: ../items/index.md
+[model]: ../resources/client/models/index.md
diff --git a/versioned_docs/version-1.21.3/blockentities/container.md b/versioned_docs/version-1.21.3/blockentities/container.md
new file mode 100644
index 00000000..4b07dda7
--- /dev/null
+++ b/versioned_docs/version-1.21.3/blockentities/container.md
@@ -0,0 +1,312 @@
+# Containers
+
+A popular use case of [block entities][blockentity] is to store items of some kind. Some of the most essential [blocks][block] in Minecraft, such as the furnace or the chest, use block entities for this purpose. To store items on something, Minecraft uses `Container`s.
+
+The `Container` interface defines methods such as `#getItem`, `#setItem` and `#removeItem` that can be used to query and update the container. Since it is an interface, it does not actually contain a backing list or other data structure, that is up to the implementing system.
+
+Due to this, `Container`s can not only be implemented on block entities, but any other class as well. Notable examples include entity inventories, as well as common modded [items][item] such as backpacks.
+
+:::warning
+NeoForge provides the `ItemStackHandler` class as a replacement for `Container`s in many places. It should be used wherever possible in favor of `Container`, as it allows for cleaner interaction with other `Container`s/`ItemStackHandler`s.
+
+The main reason this article exists is for reference in vanilla code, or if you are developing mods on multiple loaders. Always use `ItemStackHandler` in your own code if possible! Docs on that are a work in progress.
+:::
+
+## Basic Container Implementation
+
+Containers can be implemented in any way you like, so long as you satisfy the dictated methods (as with any other interface in Java). However, it is common to use a `NonNullList<ItemStack>` with a fixed length as a backing structure. Single-slot containers may also simply use an `ItemStack` field instead.
+
+For example, a basic implementation of `Container` with a size of 27 slots (one chest) could look like this:
+
+```java
+public class MyContainer implements Container {
+    private final NonNullList<ItemStack> items = NonNullList.withSize(
+            // The size of the list, i.e. the amount of slots in our container.
+            27,
+            // The default value to be used in place of where you'd use null in normal lists.
+            ItemStack.EMPTY
+    );
+
+    // The amount of slots in our container.
+    @Override
+    public int getContainerSize() {
+        return 27;
+    }
+
+    // Whether the container is considered empty.
+    @Override
+    public boolean isEmpty() {
+        return this.items.stream().allMatch(ItemStack::isEmpty);
+    }
+
+    // Return the item stack in the specified slot.
+    @Override
+    public ItemStack getItem(int slot) {
+        return this.items.get(slot);
+    }
+
+    // Call this when changes are done to the container, i.e. when item stacks are added, modified, or removed.
+    // For example, you could call BlockEntity#setChanged here.
+    @Override
+    public void setChanged() {
+
+    }
+
+    // Remove the specified amount of items from the given slot, returning the stack that was just removed.
+    // We defer to ContainerHelper here, which does this as expected for us.
+    // However, we must call #setChanged manually.
+    @Override
+    public ItemStack removeItem(int slot, int amount) {
+        ItemStack stack = ContainerHelper.removeItem(this.items, slot, amount);
+        this.setChanged();
+        return stack;
+    }
+
+    // Remove all items from the specified slot, returning the stack that was just removed.
+    // We again defer to ContainerHelper here, and we again have to call #setChanged manually.
+    @Override
+    public ItemStack removeItemNoUpdate(int slot) {
+        ItemStack stack = ContainerHelper.takeItem(this.items, slot);
+        this.setChanged();
+        return stack;
+    }
+
+    // Set the given item stack in the given slot. Limit to the max stack size of the container first.
+    @Override
+    public void setItem(int slot, ItemStack stack) {
+        stack.limitSize(this.getMaxStackSize(stack));
+        this.items.set(slot, stack);
+        this.setChanged();
+    }
+
+    // Whether the container is considered "still valid" for the given player. For example, chests and
+    // similar blocks check if the player is still within a given distance of the block here.
+    @Override
+    public boolean stillValid(Player player) {
+        return true;
+    }
+
+    // Clear the internal storage, setting all slots to empty again.
+    @Override
+    public void clearContent() {
+        items.clear();
+        this.setChanged();
+    }
+}
+```
+
+### `SimpleContainer`
+
+The `SimpleContainer` class is a basic implementation of a container with some sprinkles on top, such as the ability to add `ContainerListener`s. It can be used if you need a container implementation that doesn't have any special requirements.
+
+### `BaseContainerBlockEntity`
+
+The `BaseContainerBlockEntity` class is the base class of many important block entities in Minecraft, such as chests and chest-like blocks, the various furnace types, hoppers, dispensers, droppers, brewing stands and a few others.
+
+Aside from `Container`, it also implements the `MenuProvider` and `Nameable` interfaces:
+
+- `Nameable` defines a few methods related to setting (custom) names and, aside from many block entities, is implemented by classes such as `Entity`. This uses the [`Component` system][component].
+- `MenuProvider`, on the other hand, defines the `#createMenu` method, which allows an [`AbstractContainerMenu`][menu] to be constructed from the container. This means that using this class is not desirable if you want a container without an associated GUI, for example in jukeboxes.
+
+`BaseContainerBlockEntity` bundles all calls we would normally make to our `NonNullList<ItemStack>` through two methods `#getItems` and `#setItems`, drastically reducing the amount of boilerplate we need to write. An example implementation of a `BaseContainerBlockEntity` could look like this:
+
+```java
+public class MyBlockEntity extends BaseContainerBlockEntity {
+    // The container size. This can of course be any value you want.
+    public static final int SIZE = 9;
+    // Our item stack list. This is not final due to #setItems existing.
+    private NonNullList<ItemStack> items = NonNullList.withSize(SIZE, ItemStack.EMPTY);
+
+    // The constructor, like before.
+    public MyBlockEntity(BlockPos pos, BlockState blockState) {
+        super(MY_BLOCK_ENTITY.get(), pos, blockState);
+    }
+
+    // The container size, like before.
+    @Override
+    public int getContainerSize() {
+        return SIZE;
+    }
+
+    // The getter for our item stack list.
+    @Override
+    protected NonNullList<ItemStack> getItems() {
+        return items;
+    }
+
+    // The setter for our item stack list.
+    @Override
+    protected void setItems(NonNullList<ItemStack> items) {
+        this.items = items;
+    }
+
+    // The display name of the menu. Don't forget to add a translation!
+    @Override
+    protected Component getDefaultName() {
+        return Component.translatable("container.examplemod.myblockentity");
+    }
+
+    // The menu to create from this container. See below for what to return here.
+    @Override
+    protected AbstractContainerMenu createMenu(int containerId, Inventory inventory) {
+        return null;
+    }
+}
+```
+
+Keep in mind that this class is a `BlockEntity` and a `Container` at the same time. This means that you can use the class as a supertype for your block entity to get a functioning block entity with a pre-implemented container.
+
+### `WorldlyContainer`
+
+`WorldlyContainer` is a sub-interface of `Container` that allows accessing slots of the given `Container` by `Direction`. It is mainly intended for block entities that only expose parts of their container to a particular side. For example, this could be used by a machine that outputs to one side and takes inputs from all other sides, or vice-versa. A simple implementation of the interface could look like this:
+
+```java
+// See BaseContainerBlockEntity methods above. You can of course extend BlockEntity directly
+// and implement Container yourself if needed.
+public class MyBlockEntity extends BaseContainerBlockEntity implements WorldlyContainer {
+    // other stuff here
+    
+    // Assume that slot 0 is our output and slots 1-8 are our inputs.
+    // Further assume that we output to the top and take inputs from all other sides.
+    private static final int[] OUTPUTS = new int[]{0};
+    private static final int[] INPUTS = new int[]{1, 2, 3, 4, 5, 6, 7, 8};
+
+    // Return an array of exposed slot indices based on the passed Direction.
+    @Override
+    public int[] getSlotsForFace(Direction side) {
+        return side == Direction.UP ? OUTPUTS : INPUTS;
+    }
+
+    // Whether items can be placed through the given side at the given slot.
+    // For our example, we return true only if we're not inputing from above and are in the index range [1, 8].
+    @Override
+    public boolean canPlaceItemThroughFace(int index, ItemStack itemStack, @Nullable Direction direction) {
+        return direction != Direction.UP && index > 0 && index < 9;
+    }
+
+    // Whether items can be taken from the given side and the given slot.
+    // For our example, we return true only if we're pulling from above and from slot index 0.
+    @Override
+    public boolean canTakeItemThroughFace(int index, ItemStack stack, Direction direction) {
+        return direction == Direction.UP && index == 0;
+    }
+}
+```
+
+## Using Containers
+
+Now that we have created containers, let's use them!
+
+Since there is a considerable overlap between `Container`s and `BlockEntity`s, containers are best retrieved by casting the block entity to `Container` if possible:
+
+```java
+if (blockEntity instanceof Container container) {
+    // do something with the container
+}
+```
+
+The container can then use the methods we mentioned before, for example:
+
+```java
+// Get the first item in the container.
+ItemStack stack = container.getItem(0);
+
+// Set the first item in the container to dirt.
+container.setItem(0, new ItemStack(Items.DIRT));
+
+// Removes a quantity of (up to) 16 from the third slot.
+container.removeItem(2, 16);
+```
+
+:::warning
+A container may throw an exception if trying to access a slot that is beyond its container size. Alternatively, they may return `ItemStack.EMPTY`, as is the case with (for example) `SimpleContainer`.
+:::
+
+## `Container`s on `ItemStack`s
+
+Until now, we mainly discussed `Container`s on `BlockEntity`s. However, they can also be applied to [`ItemStack`s][itemstack] using the `minecraft:container` [data component][datacomponent]:
+
+```java
+// We use SimpleContainer as the superclass here so we don't have to reimplement the item handling logic ourselves.
+// Due to implementation details of SimpleContainer, this may lead to race conditions if multiple parties
+// can access the container at the same time, so we're just going to assume our mod doesn't allow that.
+// You may of course use a different implementation of Container (or implement Container yourself) if needed.
+public class MyBackpackContainer extends SimpleContainer {
+    // The item stack this container is for. Passed into and set in the constructor.
+    private final ItemStack stack;
+    
+    public MyBackpackContainer(ItemStack stack) {
+        // We call super with our desired container size.
+        super(27);
+        // Setting the stack field.
+        this.stack = stack;
+        // We load the container contents from the data component (if present), which is represented
+        // by the ItemContainerContents class. If absent, we use ItemContainerContents.EMPTY.
+        ItemContainerContents contents = stack.getOrDefault(DataComponents.CONTAINER, ItemContainerContents.EMPTY);
+        // Copy the data component contents into our item stack list.
+        contents.copyInto(this.getItems());
+    }
+
+    // When the contents are changed, we save the data component on the stack.
+    @Override
+    public void setChanged() {
+        super.setChanged();
+        this.stack.set(DataComponents.CONTAINER, ItemContainerContents.fromItems(this.getItems()));
+    }
+}
+```
+
+And voilà, you have created an item-backed container! Call `new MyBackpackContainer(stack)` to create a container for a menu or other use case.
+
+:::warning
+Be aware that menus that directly interface with `Container`s must `#copy()` their `ItemStack`s when modifying them, as otherwise the immutability contract on data components is broken. To do this, NeoForge provides the `StackCopySlot` class for you.
+:::
+
+## `Container`s on `Entity`s
+
+`Container`s on `Entity`s are finicky: whether an entity has a container or not cannot be universally determined. It all depends on what entity you are handling, and as such can require a lot of special-casing.
+
+If you are creating an entity yourself, there is nothing stopping you from implementing `Container` on it directly, though be aware that you will not be able to use superclasses such as `SimpleContainer` (since `Entity` is the superclass).
+
+### `Container`s on `Mob`s
+
+`Mob`s do not implement `Container`, but they implement the `EquipmentUser` interface (among others). This interface defines the methods `#setItemSlot(EquipmentSlot, ItemStack)`, `#getItemBySlot(EquipmentSlot)` and `#setDropChance(EquipmentSlot, float)`. While not related to `Container` code-wise, the functionality is quite similar: we associate slots, in this case equipment slots, with `ItemStack`s.
+
+The most notable difference to `Container` is that there is no list-like order (though `Mob` uses `NonNullList<ItemStack>`s in the background). Access does not work through slot indices, but rather through the seven `EquipmentSlot` enum values: `MAINHAND`, `OFFHAND`, `FEET`, `LEGS`, `CHEST`, `HEAD`, and `BODY` (where `BODY` is used for horse and dog armor).
+
+An example of interaction with the mob's "slots" would look something like this:
+
+```java
+// Get the item stack in the HEAD (helmet) slot.
+ItemStack helmet = mob.getItemBySlot(EquipmentSlot.HEAD);
+
+// Put bedrock into the mob's FEET (boots) slot.
+mob.setItemSlot(EquipmentSlot.FEET, new ItemStack(Items.BEDROCK));
+
+// Enable that bedrock to always drop if the mob is killed.
+mob.setDropChance(EquipmentSlot.FEET, 1f);
+```
+
+### `InventoryCarrier`
+
+`InventoryCarrier` is an interface implemented by some living entities, such as villagers. It declares a method `#getInventory`, which returns a `SimpleContainer`. This interface is used by non-player entities that need an actual inventory instead of just the equipment slots provided by `EquipmentUser`.
+
+### `Container`s on `Player`s (Player Inventory)
+
+The player's inventory is implemented through the `Inventory` class, a class implementing `Container` as well as the `Nameable` interface mentioned earlier. An instance of that `Inventory` is then stored as a field named `inventory` on the `Player`, accessible via `Player#getInventory`. The inventory can be interacted with like any other container.
+
+The inventory contents are stored in three `public final NonNullList<ItemStack>`s:
+
+- The `items` list covers the 36 main inventory slots, including the nine hotbar slots (indices 0-8).
+- The `armor` list is a list of length 4, containing armor for the `FEET`, `LEGS`, `CHEST`, and `HEAD`, in that order. This list uses `EquipmentSlot` accessors, similar to `Mob`s (see above).
+- The `offhand` list contains only the offhand slot, i.e. has a length of 1.
+
+When iterating over the inventory contents, it is recommended to iterate over `items`, then over `armor` and then over `offhand`, to be consistent with vanilla behavior.
+
+[block]: ../blocks/index.md
+[blockentity]: index.md
+[component]: ../resources/client/i18n.md#components
+[datacomponent]: ../items/datacomponents.md
+[item]: ../items/index.md
+[itemstack]: ../items/index.md#itemstacks
+[menu]: ../gui/menus.md
diff --git a/versioned_docs/version-1.21.3/blockentities/index.md b/versioned_docs/version-1.21.3/blockentities/index.md
new file mode 100644
index 00000000..d8c0c2ca
--- /dev/null
+++ b/versioned_docs/version-1.21.3/blockentities/index.md
@@ -0,0 +1,244 @@
+# Block Entities
+
+Block entities allow the storage of data on [blocks][block] in cases where [block states][blockstate] are not suitable. This is especially the case for data with a non-finite amount of options, such as inventories. Block entities are stationary and bound to a block, but otherwise share many similarities with entities, hence the name.
+
+:::note
+If you have a finite and reasonably small amount (= a few hundred at most) of possible states for your block, you might want to consider using [block states][blockstate] instead.
+:::
+
+## Creating and Registering Block Entities
+
+Like entities and unlike blocks, the `BlockEntity` class represents the block entity instance, not the [registered][registration] singleton object. The singleton is expressed through the `BlockEntityType<?>` class instead. We will need both to create a new block entity.
+
+Let's begin by creating our block entity class:
+
+```java
+public class MyBlockEntity extends BlockEntity {
+    public MyBlockEntity(BlockPos pos, BlockState state) {
+        super(type, pos, state);
+    }
+}
+```
+
+As you may have noticed, we pass an undefined variable `type` to the super constructor. Let's leave that undefined variable there for a moment and instead move to registration.
+
+[Registration][registration] happens in a similar fashion to entities. We create an instance of the associated singleton class `BlockEntityType<?>` and register it to the block entity type registry, like so:
+
+```java
+public static final DeferredRegister<BlockEntityType<?>> BLOCK_ENTITY_TYPES =
+        DeferredRegister.create(Registries.BLOCK_ENTITY_TYPE, ExampleMod.MOD_ID);
+
+public static final Supplier<BlockEntityType<MyBlockEntity>> MY_BLOCK_ENTITY = BLOCK_ENTITY_TYPES.register(
+        "my_block_entity",
+        // The block entity type.
+        () -> new BlockEntityType<>(
+                // The supplier to use for constructing the block entity instances.
+                MyBlockEntity::new,
+                // A vararg of blocks that can have this block entity.
+                // This assumes the existence of the referenced blocks as DeferredBlock<Block>s.
+                MyBlocks.MY_BLOCK_1.get(), MyBlocks.MY_BLOCK_2.get()
+        )
+);
+```
+
+:::note
+Remember that the `DeferredRegister` must be registered to the [mod event bus][modbus]!
+:::
+
+Now that we have our block entity type, we can use it in place of the `type` variable we left earlier:
+
+```java
+public class MyBlockEntity extends BlockEntity {
+    public MyBlockEntity(BlockPos pos, BlockState state) {
+        super(MY_BLOCK_ENTITY.get(), pos, state);
+    }
+}
+```
+
+:::info
+The reason for this rather confusing setup process is that `BlockEntityType` expects a `BlockEntityType.BlockEntitySupplier<T extends BlockEntity>`, which is basically a `BiFunction<BlockPos, BlockState, T extends BlockEntity>`. As such, having a constructor we can directly reference using `::new` is highly beneficial. However, we also need to provide the constructed block entity type to the default and only constructor of `BlockEntity`, so we need to pass references around a bit.
+:::
+
+Finally, we need to modify the block class associated with the block entity. This means that we will not be able to attach block entities to simple instances of `Block`, instead, we need a subclass:
+
+```java
+// The important part is implementing the EntityBlock interface and overriding the #newBlockEntity method.
+public class MyEntityBlock extends Block implements EntityBlock {
+    // Constructor deferring to super.
+    public MyEntityBlock(BlockBehaviour.Properties properties) {
+        super(properties);
+    }
+
+    // Return a new instance of our block entity here.
+    @Override
+    public BlockEntity newBlockEntity(BlockPos pos, BlockState state) {
+        return new MyBlockEntity(pos, state);
+    }
+}
+```
+
+And then, you of course need to use this class as the type in your [block registration][blockreg]:
+
+```java
+public static final DeferredBlock<MyEntityBlock> MY_BLOCK_1 =
+        BLOCKS.register("my_block_1", () -> new MyEntityBlock( /* ... */ ));
+public static final DeferredBlock<MyEntityBlock> MY_BLOCK_2 =
+        BLOCKS.register("my_block_2", () -> new MyEntityBlock( /* ... */ ));
+```
+
+## Storing Data
+
+One of the main purposes of `BlockEntity`s is to store data. Data storage on block entities can happen in two ways: directly reading and writing [NBT][nbt], or using [data attachments][dataattachments]. This section will cover reading and writing NBT directly; for data attachments, please refer to the linked article.
+
+:::info
+The main purpose of data attachments is, as the name suggests, attaching data to existing block entities, such as those provided by vanilla or other mods. For your own mod's block entities, saving and loading directly to and from NBT is preferred.
+:::
+
+Data can be read from and written to a `CompoundTag` using the `#loadAdditional` and `#saveAdditional` methods, respectively. These methods are called when the block entity is synced to disk or over the network.
+
+```java
+public class MyBlockEntity extends BlockEntity {
+    // This can be any value of any type you want, so long as you can somehow serialize it to NBT.
+    // We will use an int for the sake of example.
+    private int value;
+
+    public MyBlockEntity(BlockPos pos, BlockState state) {
+        super(MY_BLOCK_ENTITY.get(), pos, state);
+    }
+
+    // Read values from the passed CompoundTag here.
+    @Override
+    public void loadAdditional(CompoundTag tag, HolderLookup.Provider registries) {
+        super.loadAdditional(tag, registries);
+        // Will default to 0 if absent. See the NBT article for more information.
+        this.value = tag.getInt("value");
+    }
+
+    // Save values into the passed CompoundTag here.
+    @Override
+    public void saveAdditional(CompoundTag tag, HolderLookup.Provider registries) {
+        super.saveAdditional(tag, registries);
+        tag.putInt("value", this.value);
+    }
+}
+```
+
+In both methods, it is important that you call super, as that adds basic information such as the position. The tag names `id`, `x`, `y`, `z`, `NeoForgeData` and `neoforge:attachments` are reserved by the super methods, and as such, you should not use them yourself.
+
+Of course, you will want to set other values and not just work with defaults. You can do so freely, like with any other field. However, if you want the game to save those changes, you must call `#setChanged()` afterward, which marks the block entity's chunk as dirty (= in need of being saved). If you do not call that method, the block entity might get skipped during saving, as Minecraft's saving system only saves chunks that have been marked as dirty.
+
+## Tickers
+
+Another very common use of block entities, often in combination with some stored data, is ticking. Ticking means executing some code every game tick. This is done by overriding `EntityBlock#getTicker` and returning a `BlockEntityTicker`, which is basically a consumer with four arguments (level, position, blockstate and block entity), like so:
+
+```java
+// Note: The ticker is defined in the block, not the block entity. However, it is good practice to
+// keep the ticking logic in the block entity in some way, for example by defining a static #tick method.
+public class MyEntityBlock extends Block implements EntityBlock {
+    // other stuff here
+
+    @SuppressWarnings("unchecked") // Due to generics, an unchecked cast is necessary here.
+    @Override
+    public <T extends BlockEntity> BlockEntityTicker<T> getTicker(Level level, BlockState state, BlockEntityType<T> type) {
+        // You can return different tickers here, depending on whatever factors you want. A common use case would be
+        // to return different tickers on the client or server, only tick one side to begin with,
+        // or only return a ticker for some blockstates (e.g. when using a "my machine is working" blockstate property).
+        return type == MY_BLOCK_ENTITY.get() ? (BlockEntityTicker<T>) MyBlockEntity::tick : null;
+    }
+}
+
+public class MyBlockEntity extends BlockEntity {
+    // other stuff here
+
+    // The signature of this method matches the signature of the BlockEntityTicker functional interface.
+    public static void tick(Level level, BlockPos pos, BlockState state, MyBlockEntity blockEntity) {
+        // Whatever you want to do during ticking.
+        // For example, you could change a crafting progress value or consume power here.
+    }
+}
+```
+
+Be aware that the `#tick` method is actually called every tick. Due to this, you should avoid doing a lot of complex calculations in here if you can, for example by only calculating things every X ticks, or by caching the results.
+
+## Syncing
+
+Block entity logic is usually run on the server. As such, we need to tell the client what we are doing. There are three ways to do just that: on chunk load, on block update, or by using a custom packet. You should generally only sync information when it is necessary, to not needlessly clog up the network. 
+
+### Syncing on Chunk Load
+
+A chunk is loaded (and by extension, this method is utilized) each time it is read from either network or disk. To send your data here, you need to override the following methods:
+
+```java
+public class MyBlockEntity extends BlockEntity {
+    // ...
+
+    // Create an update tag here. For block entities with only a few fields, this can just call #saveAdditional.
+    @Override
+    public CompoundTag getUpdateTag(HolderLookup.Provider registries) {
+        CompoundTag tag = new CompoundTag();
+        saveAdditional(tag, registries);
+        return tag;
+    }
+
+    // Handle a received update tag here. The default implementation calls #loadAdditional here,
+    // so you do not need to override this method if you don't plan to do anything beyond that.
+    @Override
+    public void handleUpdateTag(CompoundTag tag, HolderLookup.Provider registries) {
+        super.handleUpdateTag(tag, registries);
+    }
+}
+```
+
+### Syncing on Block Update
+
+This method is used whenever a block update occurs. Block updates must be triggered manually, but are generally processed faster than chunk syncing.
+
+```java
+public class MyBlockEntity extends BlockEntity {
+    // ...
+
+    // Create an update tag here, like above.
+    @Override
+    public CompoundTag getUpdateTag(HolderLookup.Provider registries) {
+        CompoundTag tag = new CompoundTag();
+        saveAdditional(tag, registries);
+        return tag;
+    }
+
+    // Return our packet here. This method returning a non-null result tells the game to use this packet for syncing.
+    @Override
+    public Packet<ClientGamePacketListener> getUpdatePacket() {
+        // The packet uses the CompoundTag returned by #getUpdateTag. An alternative overload of #create exists
+        // that allows you to specify a custom update tag, including the ability to omit data the client might not need.
+        return ClientboundBlockEntityDataPacket.create(this);
+    }
+
+    // Optionally: Run some custom logic when the packet is received.
+    // The super/default implementation forwards to #loadAdditional.
+    @Override
+    public void onDataPacket(Connection connection, ClientboundBlockEntityDataPacket packet, HolderLookup.Provider registries) {
+        super.onDataPacket(connection, packet, registries);
+        // Do whatever you need to do here.
+    }
+}
+```
+
+To actually send the packet, an update notification must be triggered on the server by calling `Level#sendBlockUpdated(BlockPos pos, BlockState oldState, BlockState newState, int flags)`. The position should be the block entity's position, obtainable via `BlockEntity#getBlockPos`. Both blockstate parameters can be the blockstate at the block entity's position, obtainable via `BlockEntity#getBlockState`. Finally, the `flags` parameter is an update mask, as used in [`Level#setBlock`][setblock].
+
+### Using a Custom Packet
+
+By using a dedicated update packet, you can send packets yourself whenever you need to. This is the most versatile, but also the most complex variant, as it requires setting up a network handler. You can send a packet to all players tracking the block entity by using `PacketDistrubtor#sendToPlayersTrackingChunk`. Please see the [Networking][networking] section for more information.
+
+:::caution
+It is important that you do safety checks, as the `BlockEntity` might already be destroyed/replaced when the message arrives at the player. You should also check if the chunk is loaded via `Level#hasChunkAt`.
+:::
+
+[block]: ../blocks/index.md
+[blockreg]: ../blocks/index.md#basic-blocks
+[blockstate]: ../blocks/states.md
+[dataattachments]: ../datastorage/attachments.md
+[modbus]: ../concepts/events.md#event-buses
+[nbt]: ../datastorage/nbt.md
+[networking]: ../networking/index.md
+[registration]: ../concepts/registries.md#methods-for-registering
+[setblock]: ../blocks/states.md#levelsetblock
diff --git a/versioned_docs/version-1.21.3/blocks/_category_.json b/versioned_docs/version-1.21.3/blocks/_category_.json
new file mode 100644
index 00000000..610778fe
--- /dev/null
+++ b/versioned_docs/version-1.21.3/blocks/_category_.json
@@ -0,0 +1,4 @@
+{
+    "label": "Blocks",
+    "position": 3
+}
\ No newline at end of file
diff --git a/versioned_docs/version-1.21.3/blocks/index.md b/versioned_docs/version-1.21.3/blocks/index.md
new file mode 100644
index 00000000..2d5353bb
--- /dev/null
+++ b/versioned_docs/version-1.21.3/blocks/index.md
@@ -0,0 +1,324 @@
+# Blocks
+
+Blocks are essential to the Minecraft world. They make up all the terrain, structures, and machines. Chances are if you are interested in making a mod, then you will want to add some blocks. This page will guide you through the creation of blocks, and some of the things you can do with them.
+
+## One Block to Rule Them All
+
+Before we get started, it is important to understand that there is only ever one of each block in the game. A world consists of thousands of references to that one block in different locations. In other words, the same block is just displayed a lot of times.
+
+Due to this, a block should only ever be instantiated once, and that is during [registration]. Once the block is registered, you can then use the registered reference as needed.
+
+Unlike most other registries, blocks can use a specialized version of `DeferredRegister`, called `DeferredRegister.Blocks`. `DeferredRegister.Blocks` acts basically like a `DeferredRegister<Block>`, but with some minor differences:
+
+- They are created via `DeferredRegister.createBlocks("yourmodid")` instead of the regular `DeferredRegister.create(...)` method.
+- `#register` returns a `DeferredBlock<T extends Block>`, which extends `DeferredHolder<Block, T>`. `T` is the type of the class of the block we are registering.
+- There are a few helper methods for registering block. See [below] for more details.
+
+So now, let's register our blocks:
+
+```java
+//BLOCKS is a DeferredRegister.Blocks
+public static final DeferredBlock<Block> MY_BLOCK = BLOCKS.register("my_block", registryName -> new Block(...));
+```
+
+After registering the block, all references to the new `my_block` should use this constant. For example, if you want to check if the block at a given position is `my_block`, the code for that would look something like this:
+
+```java
+level.getBlockState(position) // returns the blockstate placed in the given level (world) at the given position
+        //highlight-next-line
+        .is(MyBlockRegistrationClass.MY_BLOCK);
+```
+
+This approach also has the convenient effect that `block1 == block2` works and can be used instead of Java's `equals` method (using `equals` still works, of course, but is pointless since it compares by reference anyway).
+
+:::danger
+Do not call `new Block()` outside registration! As soon as you do that, things can and will break:
+
+- Blocks must be created while registries are unfrozen. NeoForge unfreezes registries for you and freezes them later, so registration is your time window to create blocks.
+- If you try to create and/or register a block when registries are frozen again, the game will crash and report a `null` block, which can be very confusing.
+- If you still manage to have a dangling block instance, the game will not recognize it while syncing and saving, and replace it with air.
+:::
+
+## Creating Blocks
+
+As discussed before, we start by creating our `DeferredRegister.Blocks`:
+
+```java
+public static final DeferredRegister.Blocks BLOCKS = DeferredRegister.createBlocks("yourmodid");
+```
+
+### Basic Blocks
+
+For simple blocks which need no special functionality (think cobblestone, wooden planks, etc.), the `Block` class can be used directly. To do so, during registration, instantiate `Block` with a `BlockBehaviour.Properties` parameter. This `BlockBehaviour.Properties` parameter can be created using `BlockBehaviour.Properties#of`, and it can be customized by calling its methods. The most important methods for this are:
+
+- `setId` - Sets the resource key of the block.
+    - This **must** be set on every block; otherwise, an exception will be thrown.
+- `destroyTime` - Determines the time the block needs to be destroyed.
+    - Stone has a destroy time of 1.5, dirt has 0.5, obsidian has 50, and bedrock has -1 (unbreakable).
+- `explosionResistance` - Determines the explosion resistance of the block.
+    - Stone has an explosion resistance of 6.0, dirt has 0.5, obsidian has 1,200, and bedrock has 3,600,000.
+- `sound` - Sets the sound the block makes when it is punched, broken, or placed.
+    - The default value is `SoundType.STONE`. See the [Sounds page][sounds] for more details.
+- `lightLevel` - Sets the light emission of the block. Accepts a function with a `BlockState` parameter that returns a value between 0 and 15.
+    - For example, glowstone uses `state -> 15`, and torches use `state -> 14`.
+- `friction` - Sets the friction (slipperiness) of the block.
+    - Default value is 0.6. Ice uses 0.98.
+
+So for example, a simple implementation would look something like this:
+
+```java
+//BLOCKS is a DeferredRegister.Blocks
+public static final DeferredBlock<Block> MY_BETTER_BLOCK = BLOCKS.register(
+        "my_better_block", 
+        registryName -> new Block(BlockBehaviour.Properties.of()
+                //highlight-start
+                .setId(ResourceKey.create(Registries.BLOCK, registryName))
+                .destroyTime(2.0f)
+                .explosionResistance(10.0f)
+                .sound(SoundType.GRAVEL)
+                .lightLevel(state -> 7)
+                //highlight-end
+        ));
+```
+
+For further documentation, see the source code of `BlockBehaviour.Properties`. For more examples, or to look at the values used by Minecraft, have a look at the `Blocks` class.
+
+:::note
+It is important to understand that a block in the world is not the same thing as in an inventory. What looks like a block in an inventory is actually a `BlockItem`, a special type of [item] that places a block when used. This also means that things like the creative tab or the max stack size are handled by the corresponding `BlockItem`.
+
+A `BlockItem` must be registered separately from the block. This is because a block does not necessarily need an item, for example if it is not meant to be collected (as is the case with fire, for example).
+:::
+
+### More Functionality
+
+Directly using `Block` only allows for very basic blocks. If you want to add functionality, like player interaction or a different hitbox, a custom class that extends `Block` is required. The `Block` class has many methods that can be overridden to do different things; see the classes `Block`, `BlockBehaviour` and `IBlockExtension` for more information. See also the [Using blocks][usingblocks] section below for some of the most common use cases for blocks.
+
+If you want to make a block that has different variants (think a slab that has a bottom, top, and double variant), you should use [blockstates]. And finally, if you want a block that stores additional data (think a chest that stores its inventory), a [block entity][blockentities] should be used. The rule of thumb here is that if you have a finite and reasonably small amount of states (= a few hundred states at most), use blockstates, and if you have an infinite or near-infinite amount of states, use a block entity.
+
+#### Block Types
+
+Block types are [`MapCodec`s][codec] used to serialize and deserialize a block object. This `MapCodec` is set via `BlockBehaviour#codec` and [registered][registration] to the block type registry. Currently, its only use is when the block list report is being generated. A block type should be created once for every subclass of `Block`. For example, `FlowerBlock#CODEC` represents the block type for most flowers while its subclass `WitherRoseBlock` has a separate block type.
+
+If the block subclass only takes in the `BlockBehaviour.Properties`, then `BlockBehaviour#simpleCodec` can be used to create the `MapCodec`.
+
+```java
+// For some block subclass
+public class SimpleBlock extends Block {
+
+    public SimpleBlock(BlockBehavior.Properties properties) {
+        // ...
+    }
+
+    @Override
+    public MapCodec<SimpleBlock> codec() {
+        return SIMPLE_CODEC.get();
+    }
+}
+
+// In some registration class
+public static final DeferredRegister<MapCodec<? extends Block>> REGISTRAR = DeferredRegister.create(BuiltInRegistries.BLOCK_TYPE, "yourmodid");
+
+public static final Supplier<MapCodec<SimpleBlock>> SIMPLE_CODEC = REGISTRAR.register(
+    "simple",
+    () -> simpleCodec(SimpleBlock::new)
+);
+```
+
+If the block subclass contains more parameters, then [`RecordCodecBuilder#mapCodec`][codec] should be used to create the `MapCodec`, passing in `BlockBehaviour#propertiesCodec` for the `BlockBehaviour.Properties` parameter.
+
+```java
+// For some block subclass
+public class ComplexBlock extends Block {
+
+    public ComplexBlock(int value, BlockBehavior.Properties properties) {
+        // ...
+    }
+
+    @Override
+    public MapCodec<ComplexBlock> codec() {
+        return COMPLEX_CODEC.get();
+    }
+
+    public int getValue() {
+        return this.value;
+    }
+}
+
+// In some registration class
+public static final DeferredRegister<MapCodec<? extends Block>> REGISTRAR = DeferredRegister.create(BuiltInRegistries.BLOCK_TYPE, "yourmodid");
+
+public static final Supplier<MapCodec<ComplexBlock>> COMPLEX_CODEC = REGISTRAR.register(
+    "simple",
+    () -> RecordCodecBuilder.mapCodec(instance ->
+        instance.group(
+            Codec.INT.fieldOf("value").forGetter(ComplexBlock::getValue),
+            BlockBehaviour.propertiesCodec() // represents the BlockBehavior.Properties parameter
+        ).apply(instance, ComplexBlock::new)
+    )
+);
+```
+
+:::note
+Although block types are basically unused at the moment, it is expected to become more important in the future as Mojang continues moving towards a codec-centered structure.
+:::
+
+### `DeferredRegister.Blocks` helpers
+
+We already discussed how to create a `DeferredRegister.Blocks` [above], as well as that it returns `DeferredBlock`s. Now, let's have a look at what other utilities the specialized `DeferredRegister` has to offer. Let's start with `#registerBlock`:
+
+```java
+public static final DeferredRegister.Blocks BLOCKS = DeferredRegister.createBlocks("yourmodid");
+
+public static final DeferredBlock<Block> EXAMPLE_BLOCK = BLOCKS.register(
+        "example_block", registryName -> new Block(
+            BlockBehaviour.Properties.of()
+                // The ID must be set on the block
+                .setId(ResourceKey.create(Registries.BLOCK, registryName))
+        )
+);
+
+// Same as above, except that the block properties are constructed eagerly.
+// setId is also called internally on the properties object.
+public static final DeferredBlock<Block> EXAMPLE_BLOCK = BLOCKS.registerBlock(
+        "example_block",
+        Block::new, // The factory that the properties will be passed into.
+        BlockBehaviour.Properties.of() // The properties to use.
+);
+```
+
+If you want to use `Block::new`, you can leave out the factory entirely:
+
+```java
+public static final DeferredBlock<Block> EXAMPLE_BLOCK = BLOCKS.registerSimpleBlock(
+        "example_block",
+        BlockBehaviour.Properties.of() // The properties to use.
+);
+```
+
+This does the exact same as the previous example, but is slightly shorter. Of course, if you want to use a subclass of `Block` and not `Block` itself, you will have to use the previous method instead.
+
+### Resources
+
+If you register your block and place it in the world, you will find it to be missing things like a texture. This is because [textures], among others, are handled by Minecraft's resource system. To apply the texture to the block, you must provide a [model] and a [blockstate file][bsfile] that associates the block with the texture and a shape. Give the linked articles a read for more information.
+
+## Using Blocks
+
+Blocks are very rarely directly used to do things. In fact, probably two of the most common operations in all of Minecraft - getting the block at a position, and setting a block at a position - use blockstates, not blocks. The general design approach is to have the block define behavior, but have the behavior actually run through blockstates. Due to this, `BlockState`s are often passed to methods of `Block` as a parameter. For more information on how blockstates are used, and on how to get one from a block, see [Using Blockstates][usingblockstates].
+
+In several situations, multiple methods of `Block` are used at different times. The following subsections list the most common block-related pipelines. Unless specified otherwise, all methods are called on both logical sides and should return the same result on both sides.
+
+### Placing a Block
+
+Block placement logic is called from `BlockItem#useOn` (or some subclass's implementation thereof, such as in `PlaceOnWaterBlockItem`, which is used for lily pads). For more information on how the game gets there, see the [Interaction Pipeline][interactionpipeline]. In practice, this means that as soon as a `BlockItem` is right-clicked (for example a cobblestone item), this behavior is called.
+
+- Several prerequisites are checked, for example that you are not in spectator mode, that all required feature flags for the block are enabled or that the target position is not outside the world border. If at least one of these checks fails, the pipeline ends.
+- `BlockBehaviour#canBeReplaced` is called for the block currently at the position where the block is attempted to be placed. If it returns `false`, the pipeline ends. Prominent cases that return `true` here are tall grass or snow layers.
+- `Block#getStateForPlacement` is called. This is where, depending on the context (which includes information like the position, the rotation and the side the block is placed on), different block states can be returned. This is useful for example for blocks that can be placed in different directions.
+- `BlockBehaviour#canSurvive` is called with the blockstate obtained in the previous step. If it returns `false`, the pipeline ends.
+- The blockstate is set into the level via a `Level#setBlock` call.
+    - In that `Level#setBlock` call, `BlockBehaviour#onPlace` is called.
+- `Block#setPlacedBy` is called.
+
+### Breaking a Block
+
+Breaking a block is a bit more complex, as it requires time. The process can be roughly divided into three stages: "initiating", "mining" and "actually breaking".
+
+- When the left mouse button is clicked, the "initiating" stage is entered. 
+- Now, the left mouse button needs to be held down, entering the "mining" stage. **This stage's methods are called every tick.**
+- If the "continuing" stage is not interrupted (by releasing the left mouse button) and the block is broken, the "actually breaking" stage is entered.
+
+Or for those who prefer pseudocode:
+
+```java
+leftClick();
+initiatingStage();
+while (leftClickIsBeingHeld()) {
+    miningStage();
+    if (blockIsBroken()) {
+        actuallyBreakingStage();
+        break;
+    }
+}
+```
+
+The following subsections further break down these stages into actual method calls.
+
+#### The "Initiating" Stage
+
+- Client-only: `InputEvent.InteractionKeyMappingTriggered` is fired with the left mouse button and the main hand. If the event is canceled, the pipeline ends.
+- Several prerequisites are checked, for example that you are not in spectator mode, that all required feature flags for the `ItemStack` in your main hand are enabled or that the block in question is not outside the world border. If at least one of these checks fails, the pipeline ends.
+- `PlayerInteractEvent.LeftClickBlock` is fired. If the event is canceled, the pipeline ends.
+    - Note that when the event is canceled on the client, no packets are sent to the server and thus no logic runs on the server.
+    - However, canceling this event on the server will still cause client code to run, which can lead to desyncs!
+- `Block#attack` is called.
+
+#### The "Mining" Stage
+
+- `PlayerInteractEvent.LeftClickBlock` is fired. If the event is canceled, the pipeline moves to the "finishing" stage.
+    - Note that when the event is canceled on the client, no packets are sent to the server and thus no logic runs on the server.
+    - However, canceling this event on the server will still cause client code to run, which can lead to desyncs!
+- `Block#getDestroyProgress` is called and added to the internal destroy progress counter.
+    - `Block#getDestroyProgress` returns a float value between 0 and 1, representing how much the destroy progress counter should be increased every tick.
+- The progress overlay (cracking texture) is updated accordingly.
+- If the destroy progress is greater than 1.0 (i.e. completed, i.e. the block should be broken), the "mining" stage is exited and the "actually breaking" stage is entered.
+
+#### The "Actually Breaking" Stage
+
+- `Item#canAttackBlock` is called. If it returns `false` (determining that the block should not be broken), the pipeline moves to the "finishing" stage.
+- `Player#canUseGameMasterBlocks` is called if the block is an instance of `GameMasterBlock`. This determines whether the player has the ability to destroy creative-only blocks. If `false`, the pipeline moves to the "finishing" stage.
+- Server-only: `Player#blockActionRestricted` is called. This determines whether the current player cannot break the block. If `true`, the pipeline moves to the "finishing" stage.
+- Server-only: `BlockEvent.BreakEvent` is fired. If canceled or `getExpToDrop` returns -1, the pipeline moves to the "finishing" stage. The initial canceled state is determined by the above three methods.
+    - Server-only: `PlayerEvent.HarvestCheck` is fired. If `canHarvest` returns `false` or the `BlockState` passed into the break event is null, then the initial exp for the event will be 0.
+    - Server-only: `IBlockExtension#getExpDrop` is called if `PlayerEvent.HarvestCheck#canHarvest` returns `true`. This value is passed to `BlockEvent.BreakEvent#getExpToDrop` to be used later in the pipeline.
+- Server-only: `IBlockExtension#canHarvestBlock` is called. This determines whether the block can be harvested, i.e. broken with drops.
+- `IBlockExtension#onDestroyedByPlayer` is called. If it returns `false`, the pipeline moves to the "finishing" stage. In that `IBlockExtension#onDestroyedByPlayer` call:
+    - `Block#playerWillDestroy` is called.
+    - The blockstate is removed from the level via a `Level#setBlock` call with `Blocks.AIR.defaultBlockState()` as the blockstate parameter.
+        - In that `Level#setBlock` call, `Block#onRemove` is called.
+- `Block#destroy` is called.
+- Server-only: If the previous call to `IBlockExtension#canHarvestBlock` returned `true`, `Block#playerDestroy` is called.
+    - Server-only: `Block#dropResources` is called. This determines what drops from the block when mined.
+        - Server-only: `BlockDropsEvent` is fired. If the event is canceled, then nothing is dropped when the block breaks. Otherwise, every `ItemEntity` in `BlockDropsEvent#getDrops` is added to the current level.
+- Server-only: `Block#popExperience` is called with the result of the previous `IBlockExtension#getExpDrop` call, if that call returned a value greater than 0.
+
+### Ticking
+
+Ticking is a mechanism that updates (ticks) parts of the game every 1 / 20 seconds, or 50 milliseconds ("one tick"). Blocks provide different ticking methods that are called in different ways.
+
+#### Server Ticking and Tick Scheduling
+
+`BlockBehaviour#tick` is called in two occasions: either through default [random ticking][randomtick] (see below), or through scheduled ticks. Scheduled ticks can be created through `Level#scheduleTick(BlockPos, Block, int)`, where the `int` denotes a delay. This is used in various places by vanilla, for example, the tilting mechanism of big dripleaves heavily relies on this system. Other prominent users are various redstone components.
+
+#### Client Ticking
+
+`Block#animateTick` is called exclusively on the client, every frame. This is where client-only behavior, for example the torch particle spawning, happens.
+
+#### Weather Ticking
+
+Weather ticking is handled by `Block#handlePrecipitation` and runs independent of regular ticking. It is called only on the server, only when it is raining in some form, with a 1 in 16 chance. This is used for example by cauldrons that fill during rain or snowfall.
+
+#### Random Ticking
+
+The random tick system runs independent of regular ticking. Random ticks must be enabled through the `BlockBehaviour.Properties` of the block by calling the `BlockBehaviour.Properties#randomTicks()` method. This enables the block to be part of the random ticking mechanic.
+
+Random ticks occur every tick for a set amount of blocks in a chunk. That set amount is defined through the `randomTickSpeed` gamerule. With its default value of 3, every tick, 3 random blocks from the chunk are chosen. If these blocks have random ticking enabled, then their respective `BlockBehaviour#randomTick` methods are called.
+
+Random ticking is used by a wide range of mechanics in Minecraft, such as plant growth, ice and snow melting, or copper oxidizing.
+
+[above]: #one-block-to-rule-them-all
+[below]: #deferredregisterblocks-helpers
+[blockentities]: ../blockentities/index.md
+[blockstates]: states.md
+[bsfile]: ../resources/client/models/index.md#blockstate-files
+[codec]: ../datastorage/codecs.md#records
+[events]: ../concepts/events.md
+[interactionpipeline]: ../items/interactionpipeline.md
+[item]: ../items/index.md
+[model]: ../resources/client/models/index.md
+[randomtick]: #random-ticking
+[registration]: ../concepts/registries.md#methods-for-registering
+[resources]: ../resources/index.md#assets
+[sounds]: ../resources/client/sounds.md
+[textures]: ../resources/client/textures.md
+[usingblocks]: #using-blocks
+[usingblockstates]: states.md#using-blockstates
diff --git a/versioned_docs/version-1.21.3/blocks/states.md b/versioned_docs/version-1.21.3/blocks/states.md
new file mode 100644
index 00000000..9dabb504
--- /dev/null
+++ b/versioned_docs/version-1.21.3/blocks/states.md
@@ -0,0 +1,145 @@
+# Blockstates
+
+Often, you will find yourself in a situation where you want different states of a block. For example, a wheat crop has eight growth stages, and making a separate block for each stage feels wrong. Or you have a slab or slab-like block - one bottom state, one top state, and one state that has both.
+
+This is where blockstates come into play. Blockstates are an easy way to represent the different states a block can have, like a growth stage or a slab placement type.
+
+## Blockstate Properties
+
+Blockstates use a system of properties. A block can have multiple properties of multiple types. For example, an end portal frame has two properties: whether it has an eye (`eye`, 2 options) and which direction it is placed in (`facing`, 4 options). So in total, the end portal frame has 8 (2 * 4) different blockstates:
+
+```
+minecraft:end_portal_frame[facing=north,eye=false]
+minecraft:end_portal_frame[facing=east,eye=false]
+minecraft:end_portal_frame[facing=south,eye=false]
+minecraft:end_portal_frame[facing=west,eye=false]
+minecraft:end_portal_frame[facing=north,eye=true]
+minecraft:end_portal_frame[facing=east,eye=true]
+minecraft:end_portal_frame[facing=south,eye=true]
+minecraft:end_portal_frame[facing=west,eye=true]
+```
+
+The notation `blockid[property1=value1,property2=value,...]` is the standardized way of representing a blockstate in text form, and is used in some locations in vanilla, for example in commands.
+
+If your block does not have any blockstate properties defined, it still has exactly one blockstate - that is the one without any properties, since there are no properties to specify. This can be denoted as `minecraft:oak_planks[]` or simply `minecraft:oak_planks`.
+
+As with blocks, every `BlockState` exists exactly once in memory. This means that `==` can and should be used to compare `BlockState`s. `BlockState` is also a final class, meaning it cannot be extended. **Any functionality goes in the corresponding [Block][block] class!**
+
+## When to Use Blockstates
+
+### Blockstates vs. Separate Blocks
+
+A good rule of thumb is: **if it has a different name, it should be a separate block**. An example is making chair blocks: the direction of the chair should be a property, while the different types of wood should be separated into different blocks. So you'd have one chair block for each wood type, and each chair block has four blockstates (one for each direction).
+
+### Blockstates vs. [Block Entities][blockentity]
+
+Here, the rule of thumb is: **if you have a finite amount of states, use a blockstate, if you have an infinite or near-infinite amount of states, use a block entity.** Block entities can store arbitrary amounts of data, but are slower than blockstates.
+
+Blockstates and block entities can be used in conjunction with one another. For example, the chest uses blockstate properties for things like the direction, whether it is waterlogged or not, or becoming a double chest, while storing the inventory, whether it is currently open or not, or interacting with hoppers is handled by a block entity.
+
+There is no definitive answer to the question "How many states are too much for a blockstate?", but we recommend that if you need more than 8-9 bits of data (i.e. more than a few hundred states), you should use a block entity instead.
+
+## Implementing Blockstates
+
+To implement a blockstate property, in your block class, create or reference a `public static final Property<?>` constant. While you are free to make your own `Property<?>` implementations, the vanilla code provides several convenience implementations that should cover most use cases:
+
+- `IntegerProperty`
+    - Implements `Property<Integer>`. Defines a property that holds an integer value. Note that negative values are not supported.
+    - Created by calling `IntegerProperty#create(String propertyName, int minimum, int maximum)`.
+- `BooleanProperty`
+    - Implements `Property<Boolean>`. Defines a property that holds a `true` or `false` value.
+    - Created by calling `BooleanProperty#create(String propertyName)`.
+- `EnumProperty<E extends Enum<E>>`
+    - Implements `Property<E>`. Defines a property that can take on the values of an Enum class.
+    - Created by calling `EnumProperty#create(String propertyName, Class<E> enumClass)`.
+    - It is also possible to use only a subset of the Enum values (e.g. 4 out of 16 `DyeColor`s), see the overloads of `EnumProperty#create`.
+
+The class `BlockStateProperties` contains shared vanilla properties which should be used or referenced whenever possible, in place of creating your own properties.
+
+Once you have your property constant, override `Block#createBlockStateDefinition(StateDefinition$Builder)` in your block class. In that method, call `StateDefinition.Builder#add(YOUR_PROPERTY);`. `StateDefinition.Builder#add` has a vararg parameter, so if you have multiple properties, you can add them all in one go.
+
+Every block will also have a default state. If nothing else is specified, the default state uses the default value of every property. You can change the default state by calling the `Block#registerDefaultState(BlockState)` method from your constructor.
+
+If you wish to change which `BlockState` is used when placing your block, override `Block#getStateForPlacement(BlockPlaceContext)`. This can be used to, for example, set the direction of your block depending on where the player is standing or looking when they place it.
+
+To further illustrate this, this is what the relevant bits of the `EndPortalFrameBlock` class look like:
+
+```java
+public class EndPortalFrameBlock extends Block {
+    // Note: It is possible to directly use the values in BlockStateProperties instead of referencing them here again.
+    // However, for the sake of simplicity and readability, it is recommended to add constants like this.
+    public static final EnumProperty<Direction> FACING = BlockStateProperties.FACING;
+    public static final BooleanProperty EYE = BlockStateProperties.EYE;
+
+    public EndPortalFrameBlock(BlockBehaviour.Properties pProperties) {
+        super(pProperties);
+        // stateDefinition.any() returns a random BlockState from an internal set,
+        // we don't care because we're setting all values ourselves anyway
+        registerDefaultState(stateDefinition.any()
+                .setValue(FACING, Direction.NORTH)
+                .setValue(EYE, false)
+        );
+    }
+
+    @Override
+    protected void createBlockStateDefinition(StateDefinition.Builder<Block, BlockState> pBuilder) {
+        // this is where the properties are actually added to the state
+        pBuilder.add(FACING, EYE);
+    }
+
+    @Override
+    @Nullable
+    public BlockState getStateForPlacement(BlockPlaceContext pContext) {
+        // code that determines which state will be used when
+        // placing down this block, depending on the BlockPlaceContext
+    }
+}
+```
+
+## Using Blockstates
+
+To go from `Block` to `BlockState`, call `Block#defaultBlockState()`. The default blockstate can be changed through `Block#registerDefaultState`, as described above.
+
+You can get the value of a property by calling `BlockState#getValue(Property<?>)`, passing it the property you want to get the value of. Reusing our end portal frame example, this would look something like this:
+
+```java
+// EndPortalFrameBlock.FACING is an EnumPropery<Direction> and thus can be used to obtain a Direction from the BlockState
+Direction direction = endPortalFrameBlockState.getValue(EndPortalFrameBlock.FACING);
+```
+
+If you want to get a `BlockState` with a different set of values, simply call `BlockState#setValue(Property<T>, T)` on an existing block state with the property and its value. With our lever, this goes something like this:
+
+```java
+endPortalFrameBlockState = endPortalFrameBlockState.setValue(EndPortalFrameBlock.FACING, Direction.SOUTH);
+```
+
+:::note
+`BlockState`s are immutable. This means that when you call `#setValue(Property<T>, T)`, you are not actually modifying the blockstate. Instead, a lookup is performed internally, and you are given the blockstate object you requested, which is the one and only object that exists with these exact property values. This also means that just calling `state#setValue` without saving it into a variable (for example back into `state`) does nothing.
+:::
+
+To get a `BlockState` from the level, use `Level#getBlockState(BlockPos)`.
+
+### `Level#setBlock`
+
+To set a `BlockState` in the level, use `Level#setBlock(BlockPos, BlockState, int)`.
+
+The `int` parameter deserves some extra explanation, as its meaning is not immediately obvious. It denotes what is known as update flags.
+
+To help setting the update flags correctly, there are a number of `int` constants in `Block`, prefixed with `UPDATE_`. These constants can be bitwise-ORed together (for example `Block.UPDATE_NEIGHBORS | Block.UPDATE_CLIENTS`) if you wish to combine them.
+
+- `Block.UPDATE_NEIGHBORS` sends an update to the neighboring blocks. More specifically, it calls `Block#neighborChanged`, which calls a number of methods, most of which are redstone-related in some way.
+- `Block.UPDATE_CLIENTS` syncs the block update to the client.
+- `Block.UPDATE_INVISIBLE` explicitly does not update on the client. This also overrules `Block.UPDATE_CLIENTS`, causing the update to not be synced. The block is always updated on the server.
+- `Block.UPDATE_IMMEDIATE` forces a re-render on the client's main thread.
+- `Block.UPDATE_KNOWN_SHAPE` stops neighbor update recursion.
+- `Block.UPDATE_SUPPRESS_DROPS` disables block drops for the old block at that position.
+- `Block.UPDATE_MOVE_BY_PISTON` is only used by piston code to signal that the block was moved by a piston. This is mainly responsible for delaying light engine updates.
+- `Block.UPDATE_SKIP_SHAPE_UPDATE_ON_WIRE` is used by the `ExperimentalRedstoneWireEvaluator` to signal if the shape should be skipped. This is set only when the power strength is changed from not a placement or that the original source on the signal is not the current wire.
+- `Block.UPDATE_ALL` is an alias for `Block.UPDATE_NEIGHBORS | Block.UPDATE_CLIENTS`.
+- `Block.UPDATE_ALL_IMMEDIATE` is an alias for `Block.UPDATE_NEIGHBORS | Block.UPDATE_CLIENTS | Block.UPDATE_IMMEDIATE`.
+- `Block.UPDATE_NONE` is an alias for `Block.UPDATE_INVISIBLE`.
+
+There is also a convenience method `Level#setBlockAndUpdate(BlockPos pos, BlockState state)` that calls `setBlock(pos, state, Block.UPDATE_ALL)` internally.
+
+[block]: index.md
+[blockentity]: ../blockentities/index.md
diff --git a/versioned_docs/version-1.21.3/concepts/_category_.json b/versioned_docs/version-1.21.3/concepts/_category_.json
new file mode 100644
index 00000000..149a5089
--- /dev/null
+++ b/versioned_docs/version-1.21.3/concepts/_category_.json
@@ -0,0 +1,4 @@
+{
+    "label": "Concepts",
+    "position": 2
+}
\ No newline at end of file
diff --git a/versioned_docs/version-1.21.3/concepts/events.md b/versioned_docs/version-1.21.3/concepts/events.md
new file mode 100644
index 00000000..75dfb038
--- /dev/null
+++ b/versioned_docs/version-1.21.3/concepts/events.md
@@ -0,0 +1,212 @@
+---
+sidebar_position: 3
+---
+# Events
+
+One of NeoForge's main features is the event system. Events are fired for various things that happen in the game. For example, there are events for when the player right clicks, when a player or another entity jumps, when blocks are rendered, when the game is loaded, etc. A modder can subscribe event handlers to each of these events, and then perform their desired behavior inside these event handlers.
+
+Events are fired on their respective event bus. The most important bus is `NeoForge.EVENT_BUS`, also known as the **game** bus. Besides that, during startup, a mod bus is spawned for each loaded mod and passed into the mod's constructor. Many mod bus events are fired in parallel (as opposed to main bus events that always run on the same thread), dramatically increasing startup speed. See [below][modbus] for more information.
+
+## Registering an Event Handler
+
+There are multiple ways to register event handlers. Common for all of those ways is that every event handler is a method with a single event parameter and no result (i.e. return type `void`).
+
+### `IEventBus#addListener`
+
+The simplest way to register method handlers is by registering their method reference, like so:
+
+```java
+@Mod("yourmodid")
+public class YourMod {
+    public YourMod(IEventBus modBus) {
+        NeoForge.EVENT_BUS.addListener(YourMod::onLivingJump);
+    }
+
+    // Heals an entity by half a heart every time they jump.
+    private static void onLivingJump(LivingEvent.LivingJumpEvent event) {
+        LivingEntity entity = event.getEntity();
+        // Only heal on the server side
+        if (!entity.level().isClientSide()) {
+            entity.heal(1);
+        }
+    }
+}
+```
+
+### `@SubscribeEvent`
+
+Alternatively, event handlers can be annotation-driven by creating an event handler method and annotating it with `@SubscribeEvent`. Then, you can pass an instance of the encompassing class to the event bus, registering all `@SubscribeEvent`-annotated event handlers of that instance:
+
+```java
+public class EventHandler {
+    @SubscribeEvent
+    public void onLivingJump(LivingEvent.LivingJumpEvent event) {
+        LivingEntity entity = event.getEntity();
+        if (!entity.level().isClientSide()) {
+            entity.heal(1);
+        }
+    }
+}
+
+@Mod("yourmodid")
+public class YourMod {
+    public YourMod(IEventBus modBus) {
+        NeoForge.EVENT_BUS.register(new EventHandler());
+    }
+}
+```
+
+You can also do it statically. Simply make all event handlers static, and instead of a class instance, pass in the class itself:
+
+```java
+public class EventHandler {
+	@SubscribeEvent
+    public static void onLivingJump(LivingEvent.LivingJumpEvent event) {
+        LivingEntity entity = event.getEntity();
+        if (!entity.level().isClientSide()) {
+            entity.heal(1);
+        }
+    }
+}
+
+@Mod("yourmodid")
+public class YourMod {
+    public YourMod(IEventBus modBus) {
+        NeoForge.EVENT_BUS.register(EventHandler.class);
+    }
+}
+```
+
+### `@EventBusSubscriber`
+
+We can go one step further and also annotate the event handler class with `@EventBusSubscriber`. This annotation is discovered automatically by NeoForge, allowing you to remove all event-related code from the mod constructor. In essence, it is equivalent to calling `NeoForge.EVENT_BUS.register(EventHandler.class)` at the end of the mod constructor. This means that all handlers must be static, too.
+
+While not required, it is highly recommended to specify the `modid` parameter in the annotation, in order to make debugging easier (especially when it comes to mod conflicts).
+
+```java
+@EventBusSubscriber(modid = "yourmodid")
+public class EventHandler {
+    @SubscribeEvent
+    public static void onLivingJump(LivingEvent.LivingJumpEvent event) {
+        LivingEntity entity = event.getEntity();
+        if (!entity.level().isClientSide()) {
+            entity.heal(1);
+        }
+    }
+}
+```
+
+## Event Options
+
+### Fields and Methods
+
+Fields and methods are probably the most obvious part of an event. Most events contain context for the event handler to use, such as an entity causing the event or a level the event occurs in.
+
+### Hierarchy
+
+In order to use the advantages of inheritance, some events do not directly extend `Event`, but one of its subclasses, for example `BlockEvent` (which contains block context for block-related events) or `EntityEvent` (which similarly contains entity context) and its subclasses `LivingEvent` (for `LivingEntity`-specific context) and `PlayerEvent` (for `Player`-specific context). These context-providing super events are `abstract` and cannot be listened to.
+
+:::danger
+If you listen to an `abstract` event, your game will crash, as this is never what you want. You always want to listen to one of the subevents instead.
+:::
+
+```mermaid
+graph TD;
+    Event-->BlockEvent;
+    BlockEvent-->BlockDropsEvent;
+    Event-->EntityEvent;
+    EntityEvent-->LivingEvent;
+    LivingEvent-->PlayerEvent;
+    PlayerEvent-->CanPlayerSleepEvent;
+
+    class Event,BlockEvent,EntityEvent,LivingEvent,PlayerEvent red;
+```
+
+### Cancellable Events
+
+Some events implement the `ICancellableEvent` interface. These events can be cancelled using `#setCanceled(boolean canceled)`, and the cancellation status can be checked using `#isCanceled()`. If an event is cancelled, other event handlers for this event will not run, and some kind of behavior that is associated with "cancelling" is enabled. For example, cancelling `LivingChangeTargetEvent` will prevent the entity's target entity from changing.
+
+Event handlers can opt to explicitly receive cancelled events. This is done by setting the `receiveCanceled` boolean parameter in `IEventBus#addListener` (or `@SubscribeEvent`, depending on your way of attaching the event handlers) to true.
+
+### TriStates and Results
+
+Some events have three potential return states represented by `TriState`, or a `Result` enum directly on the event class. The return states can typically either cancel the action the event is handling (`TriState#FALSE`), force the action to run (`TriState#TRUE`), or execute default Vanilla behavior (`TriState#DEFAULT`).
+
+An event with three potential return states has some `set*` method to set the desired outcome.
+
+```java
+// In some class where the listeners are subscribed to the game event bus
+
+@SubscribeEvent
+public void renderNameTag(RenderNameTagEvent.CanRender event) {
+    // Uses TriState to set the return state
+    event.setCanRender(TriState.FALSE);
+}
+
+@SubscribeEvent
+public void mobDespawn(MobDespawnEvent event) {
+    // Uses a Result enum to set the return state
+    event.setResult(MobDespawnEvent.Result.DENY);
+}
+```
+
+### Priority
+
+Event handlers can optionally get assigned a priority. The `EventPriority` enum contains five values: `HIGHEST`, `HIGH`, `NORMAL` (default), `LOW` and `LOWEST`. Event handlers are executed from highest to lowest priority. If they have the same priority, they fire in registration order on the main bus, which is roughly related to mod load order, and in exact mod load order on the mod bus (see below).
+
+Priorities can be defined by setting the `priority` parameter in `IEventBus#addListener` or `@SubscribeEvent`, depending on how you attach event handlers. Note that priorities are ignored for events that are fired in parallel.
+
+### Sided Events
+
+Some events are only fired on one [side][side]. Common examples include the various render events, which are only fired on the client. Since client-only events generally need to access other client-only parts of the Minecraft codebase, they need to be registered accordingly.
+
+Event handlers that use `IEventBus#addListener()` should check the current physical side via `FMLEnvironment.dist` or the `Dist` parameter in your made mod constructor and add the listener in a separate client-only class, as outlined in the article on [sides][side].
+
+Event handlers that use `@EventBusSubscriber` can specify the side as the `value` parameter of the annotation, for example `@EventBusSubscriber(value = Dist.CLIENT, modid = "yourmodid")`.
+
+## Event Buses
+
+While most events are posted on the `NeoForge.EVENT_BUS`, some events are posted on the mod event bus instead. These are generally called mod bus events. Mod bus events can be distinguished from regular events by their superinterface `IModBusEvent`.
+
+The mod event bus is passed to you as a parameter in the mod constructor, and you can then subscribe mod bus events to it. If you use `@EventBusSubscriber`, you can also set the bus as an annotation parameter, like so: `@EventBusSubscriber(bus = Bus.MOD, modid = "yourmodid")`. The default bus is `Bus.GAME`.
+
+### The Mod Lifecycle
+
+Most mod bus events are what is known as lifecycle events. Lifecycle events run once in every mod's lifecycle during startup. Many of them are fired in parallel by subclassing `ParallelDispatchEvent`; if you want to run code from one of these events on the main thread, enqueue them using `#enqueueWork(Runnable runnable)`.
+
+The lifecycle generally follows the following order:
+
+- The mod constructor is called. Register your event handlers here, or in the next step.
+- All `@EventBusSubscriber`s are called.
+- `FMLConstructModEvent` is fired.
+- The registry events are fired, these include [`NewRegistryEvent`][newregistry], [`DataPackRegistryEvent.NewRegistry`][newdatapackregistry] and, for each registry, [`RegisterEvent`][registerevent].
+- `FMLCommonSetupEvent` is fired. This is where various miscellaneous setup happens.
+- The [sided][side] setup is fired: `FMLClientSetupEvent` if on a physical client, and `FMLDedicatedServerSetupEvent` if on a physical server.
+- `InterModComms` are handled (see below).
+- `FMLLoadCompleteEvent` is fired.
+
+#### `InterModComms`
+
+`InterModComms` is a system that allows modders to send messages to other mods for compatibility features. The class holds the messages for mods, all methods are thread-safe to call. The system is mainly driven by two events: `InterModEnqueueEvent` and `InterModProcessEvent`.
+
+During `InterModEnqueueEvent`, you can use `InterModComms#sendTo` to send messages to other mods. These methods accept the id of the mod to send the message to, the key associated with the message data (to distinguish between different messages), and a `Supplier` holding the message data. The sender can be optionally specified as well.
+
+Then, during `InterModProcessEvent`, you can use `InterModComms#getMessages` to get a stream of all received messages as `IMCMessage` objects. These hold the sender of the data, the intended receiver of the data, the data key, and the supplier for the actual data.
+
+### Other Mod Bus Events
+
+Next to the lifecycle events, there are a few miscellaneous events that are fired on the mod event bus, mostly for legacy reasons. These are generally events where you can register, set up, or initialize various things. Most of these events are not ran in parallel in contrast to the lifecycle events. A few examples:
+
+- `RegisterColorHandlersEvent.Block`, `.Item`, `.ColorResolvers` 
+- `ModelEvent.BakingCompleted`
+- `TextureAtlasStitchedEvent`
+
+:::warning
+Most of these events are planned to be moved to the main event bus in a future version.
+:::
+
+[modbus]: #event-buses
+[newdatapackregistry]: registries.md#custom-datapack-registries
+[newregistry]: registries.md#custom-registries
+[registerevent]: registries.md#registerevent
+[side]: sides.md
diff --git a/versioned_docs/version-1.21.3/concepts/registries.md b/versioned_docs/version-1.21.3/concepts/registries.md
new file mode 100644
index 00000000..34d0e82d
--- /dev/null
+++ b/versioned_docs/version-1.21.3/concepts/registries.md
@@ -0,0 +1,346 @@
+---
+sidebar_position: 1
+---
+# Registries
+
+Registration is the process of taking the objects of a mod (such as [items][item], [blocks][block], entities, etc.) and making them known to the game. Registering things is important, as without registration the game will simply not know about these objects, which will cause unexplainable behaviors and crashes.
+
+A registry is, simply put, a wrapper around a map that maps registry names (read on) to registered objects, often called registry entries. Registry names must be unique within the same registry, but the same registry name may be present in multiple registries. The most common example for this are blocks (in the `BLOCKS` registry) that have an item form with the same registry name (in the `ITEMS` registry).
+
+Every registered object has a unique name, called its registry name. The name is represented as a [`ResourceLocation`][resloc]. For example, the registry name of the dirt block is `minecraft:dirt`, and the registry name of the zombie is `minecraft:zombie`. Modded objects will of course not use the `minecraft` namespace; their mod id will be used instead.
+
+## Vanilla vs. Modded
+
+To understand some of the design decisions that were made in NeoForge's registry system, we will first look at how Minecraft does this. We will use the block registry as an example, as most other registries work the same way.
+
+Registries generally register [singletons][singleton]. This means that all registry entries exist exactly once. For example, all stone blocks you see throughout the game are actually the same stone block, displayed many times. If you need the stone block, you can get it by referencing the registered block instance.
+
+Minecraft registers all blocks in the `Blocks` class. Through the `register` method, `Registry#register()` is called, with the block registry at `BuiltInRegistries.BLOCK` being the first parameter. After all blocks are registered, Minecraft performs various checks based on the list of blocks, for example the self check that verifies that all blocks have a model loaded.
+
+The main reason all of this works is that `Blocks` is classloaded early enough by Minecraft. Mods are not automatically classloaded by Minecraft, and thus workarounds are needed.
+
+## Methods for Registering
+
+NeoForge offers two ways to register objects: the `DeferredRegister` class, and the `RegisterEvent`. Note that the former is a wrapper around the latter, and is recommended in order to prevent mistakes.
+
+### `DeferredRegister`
+
+We begin by creating our `DeferredRegister`:
+
+```java
+public static final DeferredRegister<Block> BLOCKS = DeferredRegister.create(
+        // The registry we want to use.
+        // Minecraft's registries can be found in BuiltInRegistries, NeoForge's registries can be found in NeoForgeRegistries.
+        // Mods may also add their own registries, refer to the individual mod's documentation or source code for where to find them.
+        BuiltInRegistries.BLOCKS,
+        // Our mod id.
+        ExampleMod.MOD_ID
+);
+```
+
+We can then add our registry entries as static final fields using one of the following methods (see [the article on Blocks][block] for what parameters to add in `new Block()`):
+
+```java
+public static final DeferredHolder<Block, Block> EXAMPLE_BLOCK_1 = BLOCKS.register(
+        // Our registry name.
+        "example_block" 
+        // A supplier of the object we want to register.
+        () -> new Block(...)
+);
+
+public static final DeferredHolder<Block, SlabBlock> EXAMPLE_BLOCK_2 = BLOCKS.register(
+        // Our registry name.
+        "example_block" 
+        // A function creating the object we want to register
+        // given its registry name as a ResourceLocation.
+        registryName -> new SlabBlock(...)
+);
+```
+
+The class `DeferredHolder<R, T extends R>` holds our object. The type parameter `R` is the type of the registry we are registering to (in our case `Block`). The type parameter `T` is the type of our supplier. Since we directly register a `Block` in the first example, we provide `Block` as the second parameter. If we were to register an object of a subclass of `Block`, for example `SlabBlock` (as shown in the second example), we would provide `SlabBlock` here instead.
+
+`DeferredHolder<R, T extends R>` is a subclass of `Supplier<T>`. To get our registered object when we need it, we can call `DeferredHolder#get()`. The fact that `DeferredHolder` extends `Supplier` also allows us to use `Supplier` as the type of our field. That way, the above code block becomes the following:
+
+```java
+public static final Supplier<Block> EXAMPLE_BLOCK_1 = BLOCKS.register(
+        // Our registry name.
+        "example_block" 
+        // A supplier of the object we want to register.
+        () -> new Block(...)
+);
+
+public static final Supplier<SlabBlock> EXAMPLE_BLOCK_2 = BLOCKS.register(
+        // Our registry name.
+        "example_block" 
+        // A function creating the object we want to register
+        // given its registry name as a ResourceLocation.
+        registryName -> new SlabBlock(...)
+);
+```
+
+:::note
+Be aware that a few places explicitly require a `Holder` or `DeferredHolder` and will not just accept any `Supplier`. If you need either of those two, it is best to change the type of your `Supplier` back to `Holder` or `DeferredHolder` as necessary.
+:::
+
+Finally, since the entire system is a wrapper around registry events, we need to tell the `DeferredRegister` to attach itself to the registry events as needed:
+
+```java
+//This is our mod constructor
+public ExampleMod(IEventBus modBus) {
+    //highlight-next-line
+    ExampleBlocksClass.BLOCKS.register(modBus);
+    //Other stuff here
+}
+```
+
+:::info
+There are specialized variants of `DeferredRegister`s for blocks, items, and data components that provide helper methods: [`DeferredRegister.Blocks`][defregblocks], [`DeferredRegister.Items`][defregitems], and [`DeferredRegister.DataComponents`][defregcomp], respectively.
+:::
+
+### `RegisterEvent`
+
+`RegisterEvent` is the second way to register objects. This [event][event] is fired for each registry, after the mod constructors (since those are where `DeferredRegister`s register their internal event handlers) and before the loading of configs. `RegisterEvent` is fired on the mod event bus.
+
+```java
+@SubscribeEvent
+public void register(RegisterEvent event) {
+    event.register(
+            // This is the registry key of the registry.
+            // Get these from BuiltInRegistries for vanilla registries,
+            // or from NeoForgeRegistries.Keys for NeoForge registries.
+            BuiltInRegistries.BLOCKS,
+            // Register your objects here.
+            registry -> {
+                registry.register(ResourceLocation.fromNamespaceAndPath(MODID, "example_block_1"), new Block(...));
+                registry.register(ResourceLocation.fromNamespaceAndPath(MODID, "example_block_2"), new Block(...));
+                registry.register(ResourceLocation.fromNamespaceAndPath(MODID, "example_block_3"), new Block(...));
+            }
+    );
+}
+```
+
+## Querying Registries
+
+Sometimes, you will find yourself in situations where you want to get a registered object by a given id. Or, you want to get the id of a certain registered object. Since registries are basically maps of ids (`ResourceLocation`s) to distinct objects, i.e. a reversible map, both of these operations work:
+
+```java
+BuiltInRegistries.BLOCKS.getValue(ResourceLocation.fromNamespaceAndPath("minecraft", "dirt")); // returns the dirt block
+BuiltInRegistries.BLOCKS.getKey(Blocks.DIRT); // returns the resource location "minecraft:dirt"
+
+// Assume that ExampleBlocksClass.EXAMPLE_BLOCK.get() is a Supplier<Block> with the id "yourmodid:example_block"
+BuiltInRegistries.BLOCKS.getValue(ResourceLocation.fromNamespaceAndPath("yourmodid", "example_block")); // returns the example block
+BuiltInRegistries.BLOCKS.getKey(ExampleBlocksClass.EXAMPLE_BLOCK.get()); // returns the resource location "yourmodid:example_block"
+```
+
+If you just want to check for the presence of an object, this is also possible, though only with keys:
+
+```java
+BuiltInRegistries.BLOCKS.containsKey(ResourceLocation.fromNamespaceAndPath("minecraft", "dirt")); // true
+BuiltInRegistries.BLOCKS.containsKey(ResourceLocation.fromNamespaceAndPath("create", "brass_ingot")); // true only if Create is installed
+```
+
+As the last example shows, this is possible with any mod id, and thus a perfect way to check if a certain item from another mod exists.
+
+Finally, we can also iterate over all entries in a registry, either over the keys or over the entries (entries use the Java `Map.Entry` type):
+
+```java
+for (ResourceLocation id : BuiltInRegistries.BLOCKS.keySet()) {
+    // ...
+}
+for (Map.Entry<ResourceKey<Block>, Block> entry : BuiltInRegistries.BLOCKS.entrySet()) {
+    // ...
+}
+```
+
+:::note
+Query operations always use vanilla `Registry`s, not `DeferredRegister`s. This is because `DeferredRegister`s are merely registration utilities.
+:::
+
+:::danger
+Query operations are only safe to use after registration has finished. **DO NOT QUERY REGISTRIES WHILE REGISTRATION IS STILL ONGOING!**
+:::
+
+## Custom Registries
+
+Custom registries allow you to specify additional systems that addon mods for your mod may want to plug into. For example, if your mod were to add spells, you could make the spells a registry and thus allow other mods to add spells to your mod, without you having to do anything else. It also allows you to do some things, such as syncing the entries, automatically.
+
+Let's start by creating the [registry key][resourcekey] and the registry itself:
+
+```java
+// We use spells as an example for the registry here, without any details about what a spell actually is (as it doesn't matter).
+// Of course, all mentions of spells can and should be replaced with whatever your registry actually is.
+public static final ResourceKey<Registry<Spell>> SPELL_REGISTRY_KEY = ResourceKey.createRegistryKey(ResourceLocation.fromNamespaceAndPath("yourmodid", "spells"));
+public static final Registry<YourRegistryContents> SPELL_REGISTRY = new RegistryBuilder<>(SPELL_REGISTRY_KEY)
+        // If you want to enable integer id syncing, for networking.
+        // These should only be used in networking contexts, for example in packets or purely networking-related NBT data.
+        .sync(true)
+        // The default key. Similar to minecraft:air for blocks. This is optional.
+        .defaultKey(ResourceLocation.fromNamespaceAndPath("yourmodid", "empty"))
+        // Effectively limits the max count. Generally discouraged, but may make sense in settings such as networking.
+        .maxId(256)
+        // Build the registry.
+        .create();
+```
+
+Then, tell the game that the registry exists by registering them to the root registry in `NewRegistryEvent`:
+
+```java
+@SubscribeEvent
+static void registerRegistries(NewRegistryEvent event) {
+    event.register(SPELL_REGISTRY);
+}
+```
+
+You can now register new registry contents like with any other registry, through both `DeferredRegister` and `RegisterEvent`:
+
+```java
+public static final DeferredRegister<Spell> SPELLS = DeferredRegister.create(SPELL_REGISTRY, "yourmodid");
+public static final Supplier<Spell> EXAMPLE_SPELL = SPELLS.register("example_spell", () -> new Spell(...));
+
+// Alternatively:
+@SubscribeEvent
+public static void register(RegisterEvent event) {
+    event.register(SPELL_REGISTRY_KEY, registry -> {
+        registry.register(ResourceLocation.fromNamespaceAndPath("yourmodid", "example_spell"), () -> new Spell(...));
+    });
+}
+```
+
+## Datapack Registries
+
+A datapack registry (also known as a dynamic registry or, after its main use case, worldgen registry) is a special kind of registry that loads data from [datapack][datapack] JSONs (hence the name) at world load, instead of loading them when the game starts. Default datapack registries most notably include most worldgen registries, among a few others.
+
+Datapack registries allow their contents to be specified in JSON files. This means that no code (other than [datagen][datagen] if you don't want to write the JSON files yourself) is necessary. Every datapack registry has a [`Codec`][codec] associated with it, which is used for serialization, and each registry's id determines its datapack path:
+
+- Minecraft's datapack registries use the format `data/yourmodid/registrypath` (for example `data/yourmodid/worldgen/biome`, where `worldgen/biome` is the registry path).
+- All other datapack registries (NeoForge or modded) use the format `data/yourmodid/registrynamespace/registrypath` (for example `data/yourmodid/neoforge/biome_modifier`, where `neoforge` is the registry namespace and `biome_modifier` is the registry path).
+
+Datapack registries can be obtained from a `RegistryAccess`. This `RegistryAccess` can be retrieved by calling `ServerLevel#registryAccess()` if on the server, or `Minecraft.getInstance().getConnection()#registryAccess()` if on the client (the latter only works if you are actually connected to a world, as otherwise the connection will be null). The result of these calls can then be used like any other registry to get specific elements, or to iterate over the contents.
+
+### Custom Datapack Registries
+
+Custom datapack registries do not require a `Registry` to be constructed. Instead, they just need a registry key and at least one [`Codec`][codec] to (de-)serialize its contents. Reiterating on the spells example from before, registering our spell registry as a datapack registry looks something like this:
+
+```java
+public static final ResourceKey<Registry<Spell>> SPELL_REGISTRY_KEY = ResourceKey.createRegistryKey(ResourceLocation.fromNamespaceAndPath("yourmodid", "spells"));
+
+@SubscribeEvent
+public static void registerDatapackRegistries(DataPackRegistryEvent.NewRegistry event) {
+    event.dataPackRegistry(
+            // The registry key.
+            SPELL_REGISTRY_KEY,
+            // The codec of the registry contents.
+            Spell.CODEC,
+            // The network codec of the registry contents. Often identical to the normal codec.
+            // May be a reduced variant of the normal codec that omits data that is not needed on the client.
+            // May be null. If null, registry entries will not be synced to the client at all.
+            // May be omitted, which is functionally identical to passing null (a method overload
+            // with two parameters is called that passes null to the normal three parameter method).
+            Spell.CODEC
+    );
+}
+```
+
+### Data Generation for Datapack Registries
+
+Since writing all the JSON files by hand is both tedious and error-prone, NeoForge provides a [data provider][datagenindex] to generate the JSON files for you. This works for both built-in and your own datapack registries.
+
+First, we create a `RegistrySetBuilder` and add our entries to it (one `RegistrySetBuilder` can hold entries for multiple registries):
+
+```java
+new RegistrySetBuilder()
+    .add(Registries.CONFIGURED_FEATURE, bootstrap -> {
+        // Register configured features through the bootstrap context (see below)
+    })
+    .add(Registries.PLACED_FEATURE, bootstrap -> {
+        // Register placed features through the bootstrap context (see below)
+    });
+```
+
+The `bootstrap` lambda parameter is what we actually use to register our objects. It has the type `BootstrapContext`. To register an object, we call `#register` on it, like so:
+
+```java
+// The resource key of our object.
+public static final ResourceKey<ConfiguredFeature<?, ?>> EXAMPLE_CONFIGURED_FEATURE = ResourceKey.create(
+    Registries.CONFIGURED_FEATURE,
+    ResourceLocation.fromNamespaceAndPath(MOD_ID, "example_configured_feature")
+);
+
+new RegistrySetBuilder()
+    .add(Registries.CONFIGURED_FEATURE, bootstrap -> {
+        bootstrap.register(
+            // The resource key of our configured feature.
+            EXAMPLE_CONFIGURED_FEATURE,
+            // The actual configured feature.
+            new ConfiguredFeature<>(Feature.ORE, new OreConfiguration(...))
+        );
+    })
+    .add(Registries.PLACED_FEATURE, bootstrap -> {
+        // ...
+    });
+```
+
+The `BootstrapContext` can also be used to lookup entries from another registry if needed:
+
+```java
+public static final ResourceKey<ConfiguredFeature<?, ?>> EXAMPLE_CONFIGURED_FEATURE = ResourceKey.create(
+    Registries.CONFIGURED_FEATURE,
+    ResourceLocation.fromNamespaceAndPath(MOD_ID, "example_configured_feature")
+);
+public static final ResourceKey<PlacedFeature> EXAMPLE_PLACED_FEATURE = ResourceKey.create(
+    Registries.PLACED_FEATURE,
+    ResourceLocation.fromNamespaceAndPath(MOD_ID, "example_placed_feature")
+);
+
+new RegistrySetBuilder()
+    .add(Registries.CONFIGURED_FEATURE, bootstrap -> {
+        bootstrap.register(EXAMPLE_CONFIGURED_FEATURE, ...);
+    })
+    .add(Registries.PLACED_FEATURE, bootstrap -> {
+        HolderGetter<ConfiguredFeature<?, ?>> otherRegistry = bootstrap.lookup(Registries.CONFIGURED_FEATURE);
+        bootstrap.register(EXAMPLE_PLACED_FEATURE, new PlacedFeature(
+            otherRegistry.getOrThrow(EXAMPLE_CONFIGURED_FEATURE), // Get the configured feature
+            List.of() // No-op when placement happens - replace with whatever your placement parameters are
+        ));
+    });
+```
+
+Finally, we use our `RegistrySetBuilder` in an actual data provider, and register that data provider to the event:
+
+```java
+@SubscribeEvent
+public static void onGatherData(GatherDataEvent event) {
+    CompletableFuture<HolderLookup.Provider> lookupProvider = event.getGenerator().addProvider(
+        // Only run datapack generation when server data is being generated
+        event.includeServer(),
+        // Create the provider
+        output -> new DatapackBuiltinEntriesProvider(
+            output,
+            event.getLookupProvider(),
+            // Our registry set builder to generate the data from.
+            new RegistrySetBuilder().add(...),
+            // A set of mod ids we are generating. Usually only your own mod id.
+            Set.of("yourmodid")
+        )
+    ).getRegistryProvider();
+    
+    // Use the lookup provider generated from your datapack entries as input
+    //   to all other data providers.
+    // ...
+}
+```
+
+[block]: ../blocks/index.md
+[blockentity]: ../blockentities/index.md
+[codec]: ../datastorage/codecs.md
+[datagen]: #data-generation-for-datapack-registries
+[datagenindex]: ../resources/index.md#data-generation
+[datapack]: ../resources/index.md#data
+[defregblocks]: ../blocks/index.md#deferredregisterblocks-helpers
+[defregcomp]: ../items/datacomponents.md#creating-custom-data-components
+[defregitems]: ../items/index.md#deferredregisteritems
+[event]: events.md
+[item]: ../items/index.md
+[resloc]: ../misc/resourcelocation.md
+[resourcekey]: ../misc/resourcelocation.md#resourcekeys
+[singleton]: https://en.wikipedia.org/wiki/Singleton_pattern
diff --git a/versioned_docs/version-1.21.3/concepts/sides.md b/versioned_docs/version-1.21.3/concepts/sides.md
new file mode 100644
index 00000000..3cd62898
--- /dev/null
+++ b/versioned_docs/version-1.21.3/concepts/sides.md
@@ -0,0 +1,89 @@
+---
+sidebar_position: 2
+---
+# Sides
+
+Like many other programs, Minecraft follows a client-server concept, where the client is responsible for displaying the data, while the server is responsible for updating them. When using these terms, we have a fairly intuitive understanding of what we mean... right?
+
+Turns out, not so much. A lot of the confusion stems from Minecraft having two different concepts of sides, depending on the context: the physical and the logical side.
+
+## Logical vs. Physical Side
+
+### The Physical Side
+
+When you open your Minecraft launcher, select a Minecraft installation and press play, you boot up a **physical client**. The word "physical" is used here in the sense of "this is a client program". This especially means that client-side functionality, such as all the rendering stuff, is available here and can be used as needed. In contrast, the **physical server**, also known as dedicated server, is what opens when you launch a Minecraft server JAR. While the Minecraft server comes with a rudimentary GUI, it is missing all client-only functionality. Most notably, this means that various client classes are missing from the server JAR. Calling these classes on the physical server will lead to missing class errors, i.e. crashes, so we need to safeguard against this.
+
+### The Logical Side
+
+The logical side is mainly focused on the internal program structure of Minecraft. The **logical server** is where the game logic runs. Things like time and weather changing, entity ticking, entity spawning, etc. all run on the server. All kinds of data, such as inventory contents, are the server's responsibility as well. The **logical client**, on the other hand, is responsible for displaying everything there is to display. Minecraft keeps all the client code in an isolated `net.minecraft.client` package, and runs it in a separate thread called the Render Thread, while everything else is considered common (i.e. client and server) code.
+
+### What's the Difference?
+
+The difference between physical and logical sides is best exemplified by two scenarios:
+
+- The player joins a **multiplayer** world. This is fairly straightforward: The player's physical (and logical) client connects to a physical (and logical) server somewhere else - the player does not care where; so long as they can connect, that's all the client knows of, and all the client needs to know.
+- The player joins a **singleplayer** world. This is where things get interesting. The player's physical client spins up a logical server and then, now in the role of the logical client, connects to that logical server on the same machine. If you are familiar with networking, you can think of it as a connection to `localhost` (only conceptually; there are no actual sockets or similar involved).
+
+These two scenarios also show the main problem with this: If a logical server can work with your code, that alone doesn't guarantee that a physical server will be able to work with as well. This is why you should always test with dedicated servers to check for unexpected behavior. `NoClassDefFoundError`s and `ClassNotFoundException`s due to incorrect client and server separation are among the most common errors there are in modding. Another common mistake is working with static fields and accessing them from both logical sides; this is particularly tricky because there's usually no indication that something is wrong.
+
+:::tip
+If you need to transfer data from one side to another, you must [send a packet][networking].
+:::
+
+In the NeoForge codebase, the physical side is represented by an enum called `Dist`, while the logical side is represented by an enum called `LogicalSide`.
+
+:::info
+Historically, server JARs have had classes the client did not. This is not the case anymore in modern versions; physical servers are a subset of physical clients, if you will.
+:::
+
+## Performing Side-Specific Operations
+
+### `Level#isClientSide()`
+
+This boolean check will be your most used way to check sides. Querying this field on a `Level` object establishes the  **logical** side the level belongs to: If this field is `true`, the level is running on the logical client. If the field is `false`, the level is running on the logical server. It follows that the physical server will always contain `false` in this field, but we cannot assume that `false` implies a physical server, since this field can also be `false` for the logical server inside a physical client (i.e. a singleplayer world).
+
+Use this check whenever you need to determine if game logic and other mechanics should be run. For example, if you want to damage the player every time they click your block, or have your machine process dirt into diamonds, you should only do so after ensuring `#isClientSide` is `false`. Applying game logic to the logical client can cause desynchronization (ghost entities, desynchronized stats, etc.) in the best case, and crashes in the worst case.
+
+:::tip
+This check should be used as your go-to default. Whenever you have a `Level` available, use this check.
+:::
+
+### `FMLEnvironment.dist`
+
+`FMLEnvironment.dist` is the **physical** counterpart to a `Level#isClientSide()` check. If this field is `Dist.CLIENT`, you are on a physical client. If the field is `Dist.DEDICATED_SERVER`, you are on a physical server.
+
+
+#### `@Mod`
+
+Checking the physical environment is important when dealing with client-only classes. The recommended way to separate code that should only be executed on one physical client is by specifying a separate [`@Mod` annotation][mod], setting the `dist` parameter to the physical side the mod class should be loaded on:
+
+```java
+@Mod("examplemod")
+public class ExampleMod {
+    public ExampleMod(IEventBus modBus) {
+        // Perform logic in that should be executed on both sides
+    }
+}
+
+@Mod(value = "examplemod", dist = Dist.CLIENT) 
+public class ExampleModClient {
+    public ExampleModClient(IEventBus modBus) {
+        // Perform logic in that should only be executed on the physical client
+        Minecraft.getInstance().whatever();
+    }
+}
+
+@Mod(value = "examplemod", dist = Dist.DEDICATED_SERVER) 
+public class ExampleModDedicatedServer {
+    public ExampleModDedicatedServer(IEventBus modBus) {
+        // Perform logic in that should only be executed on the physical server
+    }
+}
+```
+
+:::tip
+Mods are generally expected to work on either side. This especially means that if you are developing a client-only mod, you should verify that the mod actually runs on a physical client, and no-op in the event that it does not.
+:::
+
+[networking]: ../networking/index.md
+[mod]: ../gettingstarted/modfiles.md#javafml-and-mod
diff --git a/versioned_docs/version-1.21.3/datastorage/_category_.json b/versioned_docs/version-1.21.3/datastorage/_category_.json
new file mode 100644
index 00000000..a04f0955
--- /dev/null
+++ b/versioned_docs/version-1.21.3/datastorage/_category_.json
@@ -0,0 +1,4 @@
+{
+    "label": "Data Storage",
+    "position": 8
+}
\ No newline at end of file
diff --git a/versioned_docs/version-1.21.3/datastorage/attachments.md b/versioned_docs/version-1.21.3/datastorage/attachments.md
new file mode 100644
index 00000000..13562c28
--- /dev/null
+++ b/versioned_docs/version-1.21.3/datastorage/attachments.md
@@ -0,0 +1,118 @@
+---
+sidebar_position: 3
+---
+# Data Attachments
+
+The data attachment system allows mods to attach and store additional data on block entities, chunks, and entities.
+
+_To store additional level data, you can use [SavedData][saveddata]._
+
+:::note
+Data attachments for item stacks have been superceeded by vanilla's [data components][datacomponents].
+:::
+
+## Creating an attachment type
+
+To use the system, you need to register an `AttachmentType`. The attachment type contains the following configuration:
+
+- A default value supplier to create the instance when the data is first accessed.
+- An optional serializer if the attachment should be persisted.
+- (If a serializer was configured) The `copyOnDeath` flag to automatically copy entity data on death (see below).
+
+:::tip
+If you don't want your attachment to persist, do not provide a serializer.
+:::
+
+There are a few ways to provide an attachment serializer: directly implementing `IAttachmentSerializer`, implementing `INBTSerializable` and using the static `AttachmentType#serializable` method to create the builder, or providing a codec to the builder.
+
+In any case, the attachment **must be registered** to the `NeoForgeRegistries.ATTACHMENT_TYPES` registry. Here is an example:
+
+```java
+// Create the DeferredRegister for attachment types
+private static final DeferredRegister<AttachmentType<?>> ATTACHMENT_TYPES = DeferredRegister.create(NeoForgeRegistries.ATTACHMENT_TYPES, MOD_ID);
+
+// Serialization via INBTSerializable
+private static final Supplier<AttachmentType<ItemStackHandler>> HANDLER = ATTACHMENT_TYPES.register(
+    "handler", () -> AttachmentType.serializable(() -> new ItemStackHandler(1)).build()
+);
+// Serialization via codec
+private static final Supplier<AttachmentType<Integer>> MANA = ATTACHMENT_TYPES.register(
+    "mana", () -> AttachmentType.builder(() -> 0).serialize(Codec.INT).build()
+);
+// No serialization
+private static final Supplier<AttachmentType<SomeCache>> SOME_CACHE = ATTACHMENT_TYPES.register(
+    "some_cache", () -> AttachmentType.builder(() -> new SomeCache()).build()
+);
+
+// In your mod constructor, don't forget to register the DeferredRegister to your mod bus:
+ATTACHMENT_TYPES.register(modBus);
+```
+
+## Using the attachment type
+
+Once the attachment type is registered, it can be used on any holder object. Calling `getData` if no data is present will attach a new default instance.
+
+```java
+// Get the ItemStackHandler if it already exists, else attach a new one:
+ItemStackHandler stackHandler = chunk.getData(HANDLER);
+// Get the current player mana if it is available, else attach 0:
+int playerMana = player.getData(MANA);
+// And so on...
+```
+
+If attaching a default instance is not desired, a `hasData` check can be added:
+
+```java
+// Check if the chunk has the HANDLER attachment before doing anything.
+if (chunk.hasData(HANDLER)) {
+    ItemStackHandler stackHandler = chunk.getData(HANDLER);
+    // Do something with chunk.getData(HANDLER).
+}
+```
+
+The data can also be updated with `setData`:
+
+```java
+// Increment mana by 10.
+player.setData(MANA, player.getData(MANA) + 10);
+```
+
+:::important
+Usually, block entities and chunks need to be marked as dirty when they are modified (with `setChanged` and `setUnsaved(true)`). This is done automatically for calls to `setData`:
+
+```java
+chunk.setData(MANA, chunk.getData(MANA) + 10); // will call setUnsaved automatically
+```
+
+but if you modify some data that you obtained from `getData` (including a newly created default instance) then you must mark block entities and chunks as dirty explicitly:
+
+```java
+var mana = chunk.getData(MUTABLE_MANA);
+mana.set(10);
+chunk.setUnsaved(true); // must be done manually because we did not use setData
+```
+:::
+
+## Sharing data with the client
+
+To sync block entity, chunk, or entity attachments to a client, you need to [send a packet to the client][network] yourself. For chunks, you can use `ChunkWatchEvent.Sent` to know when to send chunk data to a player.
+
+## Copying data on player death
+
+By default, entity data attachments are not copied on player death. To automatically copy an attachment on player death, set `copyOnDeath` in the attachment builder.
+
+More complex handling can be implemented via `PlayerEvent.Clone` by reading the data from the original entity and assigning it to the new entity. In this event, the `#isWasDeath` method can be used to distinguish between respawning after death and returning from the End. This is important because the data will already exist when returning from the End, so care has to be taken to not duplicate values in this case.
+
+For example:
+
+```java
+NeoForge.EVENT_BUS.register(PlayerEvent.Clone.class, event -> {
+    if (event.isWasDeath() && event.getOriginal().hasData(MY_DATA)) {
+        event.getEntity().getData(MY_DATA).fieldToCopy = event.getOriginal().getData(MY_DATA).fieldToCopy;
+    }
+});
+```
+
+[saveddata]: saveddata.md
+[datacomponents]: ../items/datacomponents.md
+[network]: ../networking/index.md
diff --git a/versioned_docs/version-1.21.3/datastorage/capabilities.md b/versioned_docs/version-1.21.3/datastorage/capabilities.md
new file mode 100644
index 00000000..9bf34195
--- /dev/null
+++ b/versioned_docs/version-1.21.3/datastorage/capabilities.md
@@ -0,0 +1,340 @@
+---
+sidebar_position: 5
+---
+# Capabilities
+
+Capabilities allow exposing features in a dynamic and flexible way without having to resort to directly implementing many interfaces.
+
+In general terms, each capability provides a feature in the form of an interface.
+
+NeoForge adds capability support to blocks, entities, and item stacks. This will be explained in more detail in the following sections.
+
+## Why Use Capabilities?
+
+Capabilities are designed to separate **what** a block, entity or item stack can do from **how** it does it. If you are wondering whether capabilities are the right tool for a job, ask yourself the following questions:
+
+1. Do I only care about **what** a block, entity or item stack can do, but not about **how** it does it?
+1. Is the **what**, the behavior, only available for some blocks, entities, or item stacks, but not all of them?
+1. Is the **how**, the implementation of that behavior, dependent on the specific block, entity or item stack?
+
+Here are a few examples of good capability usage:
+
+- *"I want my fluid container to be compatible with fluid containers from other mods, but I don't know the specifics of each fluid container."* - Yes, use the `IFluidHandler` capability.
+- *"I want to count how many items are in some entity, but I do not know how the entity might store them."* - Yes, use the `IItemHandler` capability.
+- *"I want to fill some item stack with power, but I do not know how the item stack might store it."* - Yes, use the `IEnergyStorage` capability.
+- *"I want to apply some color to whatever block a player is currently targeting, but I do not know how the block will be transformed."* - Yes. NeoForge does not provide a capability to color blocks, but you can implement one yourself.
+
+Here is an example of discouraged capability usage:
+
+- *"I want to check if an entity is within the range of my machine."* - No, use a helper method instead.
+
+## NeoForge-provided capabilities
+
+NeoForge provides capabilities for the following three interfaces: `IItemHandler`, `IFluidHandler` and `IEnergyStorage`.
+
+`IItemHandler` exposes an interface for handling inventory slots. The capabilities of type `IItemHandler` are:
+
+- `Capabilities.ItemHandler.BLOCK`: automation-accessible inventory of a block (for chests, machines, etc).
+- `Capabilities.ItemHandler.ENTITY`: inventory contents of an entity (extra player slots, mob/creature inventories/bags).
+- `Capabilities.ItemHandler.ENTITY_AUTOMATION`: automation-accessible inventory of an entity (boats, minecarts, etc).
+- `Capabilities.ItemHandler.ITEM`: contents of an item stack (portable backpacks and such).
+
+`IFluidHandler` exposes an interface for handling fluid inventories. The capabilities of type `IFluidHandler` are:
+
+- `Capabilities.FluidHandler.BLOCK`: automation-accessible fluid inventory of a block.
+- `Capabilities.FluidHandler.ENTITY`: fluid inventory of an entity.
+- `Capabilities.FluidHandler.ITEM`: fluid inventory of an item stack.
+This capability is of the special `IFluidHandlerItem` type due to the way buckets hold fluids.
+
+`IEnergyStorage` exposes an interface for handling energy containers. It is based on the RedstoneFlux API by TeamCoFH. The capabilities of type `IEnergyStorage` are:
+
+- `Capabilities.EnergyStorage.BLOCK`: energy contained inside a block.
+- `Capabilities.EnergyStorage.ENTITY`: energy containing inside an entity.
+- `Capabilities.EnergyStorage.ITEM`: energy contained inside an item stack.
+
+## Creating a capability
+
+NeoForge supports capabilities for blocks, entities, and item stacks.
+
+Capabilities allow looking up implementations of some APIs with some dispatching logic. The following kinds of capabilities are implemented in NeoForge:
+
+- `BlockCapability`: capabilities for blocks and block entities; behavior depends on the specific `Block`.
+- `EntityCapability`: capabilities for entities: behavior dependends on the specific `EntityType`.
+- `ItemCapability`: capabilities for item stacks: behavior depends on the specific `Item`.
+
+:::tip
+For compatibility with other mods, we recommend using the capabilities provided by NeoForge in the `Capabilities` class if possible. Otherwise, you can create your own as described in this section.
+:::
+
+Creating a capability is a single function call, and the resulting object should be stored in a `static final` field. The following parameters must be provided:
+
+- The name of the capability.
+    - Creating a capability with the same name multiple times will always return the same object.
+    - Capabilities with different names are **completely independent**, and can be used for different purposes.
+- The behavior type that is being queried. This is the `T` type parameter.
+- The type for additional context in the query. This is the `C` type parameter.
+
+For example, here is how a capability for side-aware block `IItemHandler`s might be declared:
+
+```java
+public static final BlockCapability<IItemHandler, @Nullable Direction> ITEM_HANDLER_BLOCK =
+    BlockCapability.create(
+        // Provide a name to uniquely identify the capability.
+        ResourceLocation.fromNamespaceAndPath("mymod", "item_handler"),
+        // Provide the queried type. Here, we want to look up `IItemHandler` instances.
+        IItemHandler.class,
+        // Provide the context type. We will allow the query to receive an extra `Direction side` parameter.
+        Direction.class);
+```
+
+A `@Nullable Direction` is so common for blocks that there is a dedicated helper:
+
+```java
+public static final BlockCapability<IItemHandler, @Nullable Direction> ITEM_HANDLER_BLOCK =
+    BlockCapability.createSided(
+        // Provide a name to uniquely identify the capability.
+        ResourceLocation.fromNamespaceAndPath("mymod", "item_handler"),
+        // Provide the queried type. Here, we want to look up `IItemHandler` instances.
+        IItemHandler.class);
+```
+
+If no context is required, `Void` should be used. There is also a dedicated helper for context-less capabilities:
+
+```java
+public static final BlockCapability<IItemHandler, Void> ITEM_HANDLER_NO_CONTEXT =
+    BlockCapability.createVoid(
+        // Provide a name to uniquely identify the capability.
+        ResourceLocation.fromNamespaceAndPath("mymod", "item_handler_no_context"),
+        // Provide the queried type. Here, we want to look up `IItemHandler` instances.
+        IItemHandler.class);
+```
+
+For entities and item stacks, similar methods exist in `EntityCapability` and `ItemCapability` respectively.
+
+## Querying capabilities
+
+Once we have our `BlockCapability`, `EntityCapability`, or `ItemCapability` object in a static field, we can query a capability.
+
+For entities and item stacks, we can try to find implementations of a capability with `getCapability`. If the result is `null`, there no implementation is available.
+
+For example:
+
+```java
+var object = entity.getCapability(CAP, context);
+if (object != null) {
+    // Use object
+}
+```
+
+```java
+var object = stack.getCapability(CAP, context);
+if (object != null) {
+    // Use object
+}
+```
+
+Block capabilities are used a bit differently because blocks without a block entity can have capabilities as well. The query is now performed on a `level`, with the `pos`ition that we are looking for as an additional parameter:
+
+```java
+var object = level.getCapability(CAP, pos, context);
+if (object != null) {
+    // Use object
+}
+```
+
+If the block entity and/or the block state is known, they can be passed to save on query time:
+
+```java
+var object = level.getCapability(CAP, pos, blockState, blockEntity, context);
+if (object != null) {
+    // Use object
+}
+```
+
+To give a more concrete example, here is how one might query an `IItemHandler` capability for a block, from the `Direction.NORTH` side:
+
+```java
+IItemHandler handler = level.getCapability(Capabilities.ItemHandler.BLOCK, pos, Direction.NORTH);
+if (handler != null) {
+    // Use the handler for some item-related operation.
+}
+```
+
+## Block capability caching
+
+When a capability is looked up, the system will perform the following steps under the hood:
+
+1. Fetch block entity and block state if they were not supplied.
+1. Fetch registered capability providers. (More on this below).
+1. Iterate the providers and ask them if they can provide the capability.
+1. One of the providers will return a capability instance, potentially allocating a new object.
+
+The implementation is rather efficient, but for queries that are performed frequently, for example every game tick, these steps can take a significant amount of server time. The `BlockCapabilityCache` system provides a dramatic speedup for capabilities that are frequently queried at a given position.
+
+:::tip
+Generally, a `BlockCapabilityCache` will be created once and then stored in a field of the object performing frequent capability queries. When and where exactly you store the cache is up to you.
+:::
+
+To create a cache, call `BlockCapabilityCache.create` with the capability to query, the level, the position, and the query context.
+
+```java
+// Declare the field:
+private BlockCapabilityCache<IItemHandler, @Nullable Direction> capCache;
+
+// Later, for example in `onLoad` for a block entity:
+this.capCache = BlockCapabilityCache.create(
+    Capabilities.ItemHandler.BLOCK, // capability to cache
+    level, // level
+    pos, // target position
+    Direction.NORTH // context
+);
+```
+
+Querying the cache is then done with `getCapability()`:
+
+```java
+IItemHandler handler = this.capCache.getCapability();
+if (handler != null) {
+    // Use the handler for some item-related operation.
+}
+```
+
+**The cache is automatically cleared by the garbage collector, there is no need to unregister it.**
+
+It is also possible to receive notifications when the capability object changes! This includes capabilities changing (`oldHandler != newHandler`), becoming unavailable (`null`) or becoming available again (not `null` anymore).
+
+The cache then needs to be created with two additional parameters:
+
+- A validity check, that is used to determine if the cache is still valid.
+    - In the simplest usage as a block entity field, `() -> !this.isRemoved()` will do.
+- An invalidation listener, that is called when the capability changes.
+    - This is where you can react to capability changes, removals, or appearances.
+
+```java
+// With optional invalidation listener:
+this.capCache = BlockCapabilityCache.create(
+    Capabilities.ItemHandler.BLOCK, // capability to cache
+    level, // level
+    pos, // target position
+    Direction.NORTH, // context
+    () -> !this.isRemoved(), // validity check (because the cache might outlive the object it belongs to)
+    () -> onCapInvalidate() // invalidation listener
+);
+```
+
+## Block capability invalidation
+
+:::info
+Invalidation is exclusive to block capabilities. Entity and item stack capabilities cannot be cached and do not need to be invalidated.
+:::
+
+To make sure that caches can correctly update their stored capability, **modders must call `level.invalidateCapabilities(pos)` whenever a capability changes, appears, or disappears**.
+
+```java
+// whenever a capability changes, appears, or disappears:
+level.invalidateCapabilities(pos);
+```
+
+NeoForge already handles common cases such as chunk load/unloads and block entity creation/removal, but other cases need to be handled explicitly by modders. For example, modders must invalidate capabilities in the following cases:
+
+- If a previously returned capability is no longer valid.
+- If a capability-providing block (without a block entity) is placed or changes state, by overriding `onPlace`.
+- If a capability-providing block (without a block entity) is removed, by overriding `onRemove`.
+
+For a plain block example, refer to the `ComposterBlock.java` file.
+
+For more information, refer to the javadoc of [`IBlockCapabilityProvider`][block-cap-provider].
+
+## Registering capabilities
+
+A capability _provider_ is what ultimately supplies a capability. A capability provider is a function that can either return a capability instance, or `null` if it cannot provide the capability. Providers are specific to:
+
+- the given capability that they are providing for, and
+- the block instance, block entity type, entity type, or item instance that they are providing for.
+
+They need to be registered in the `RegisterCapabilitiesEvent`.
+
+Block providers are registered with `registerBlock`. For example:
+
+```java
+private static void registerCapabilities(RegisterCapabilitiesEvent event) {
+    event.registerBlock(
+        Capabilities.ItemHandler.BLOCK, // capability to register for
+        (level, pos, state, be, side) -> <return the IItemHandler>,
+        // blocks to register for
+        MY_ITEM_HANDLER_BLOCK,
+        MY_OTHER_ITEM_HANDLER_BLOCK
+    );
+}
+```
+
+In general, registration will be specific to some block entity types, so the `registerBlockEntity` helper method is provided as well:
+
+```java
+event.registerBlockEntity(
+    Capabilities.ItemHandler.BLOCK, // capability to register for
+    MY_BLOCK_ENTITY_TYPE, // block entity type to register for
+    (myBlockEntity, side) -> myBlockEntity.myIItemHandlerForTheGivenSide
+);
+```
+
+:::danger
+If the capability previously returned by a block or block entity provider is no longer valid, *you must invalidate the caches** by calling `level.invalidateCapabilities(pos)`. Refer to the [invalidation section][invalidation] above for more information.
+:::
+
+Entity registration is similar, using `registerEntity`:
+
+```java
+event.registerEntity(
+    Capabilities.ItemHandler.ENTITY, // capability to register for
+    MY_ENTITY_TYPE, // entity type to register for
+    (myEntity, context) -> myEntity.myIItemHandlerForTheGivenContext
+);
+```
+
+Item registration is similar too. Note that the provider receives the stack:
+
+```java
+event.registerItem(
+    Capabilities.ItemHandler.ITEM, // capability to register for
+    (itemStack, context) -> <return the IItemHandler for the itemStack>,
+    // items to register for
+    MY_ITEM,
+    MY_OTHER_ITEM
+);
+```
+
+## Registering capabilities for all objects
+
+If for some reason you need to register a provider for all blocks, entities, or items, you will need to iterate the corresponding registry and register the provider for each object.
+
+For example, NeoForge uses this system to register a fluid handler capability for all `BucketItem`s (excluding subclasses):
+
+```java
+// For reference, you can find this code in the `CapabilityHooks` class.
+for (Item item : BuiltInRegistries.ITEM) {
+    if (item.getClass() == BucketItem.class) {
+        event.registerItem(Capabilities.FluidHandler.ITEM, (stack, ctx) -> new FluidBucketWrapper(stack), item);
+    }
+}
+```
+
+Providers are asked for a capability in the order that they are registered. Should you want to run before a provider that NeoForge already registers for one of your objects, register your `RegisterCapabilitiesEvent` handler with a higher priority.
+
+For example:
+
+```java
+modBus.addListener(RegisterCapabilitiesEvent.class, event -> {
+    event.registerItem(
+        Capabilities.FluidHandler.ITEM,
+        (stack, ctx) -> new MyCustomFluidBucketWrapper(stack),
+        // blocks to register for
+        MY_CUSTOM_BUCKET);
+}, EventPriority.HIGH); // use HIGH priority to register before NeoForge!
+```
+
+See [`CapabilityHooks`][capability-hooks] for a list of the providers registered by NeoForge itself.
+
+[block-cap-provider]: https://github.com/neoforged/NeoForge/blob/1.21.x/src/main/java/net/neoforged/neoforge/capabilities/IBlockCapabilityProvider.java
+[capability-hooks]: https://github.com/neoforged/NeoForge/blob/1.21.x/src/main/java/net/neoforged/neoforge/capabilities/CapabilityHooks.java
+[invalidation]: #block-capability-invalidation
diff --git a/versioned_docs/version-1.21.3/datastorage/codecs.md b/versioned_docs/version-1.21.3/datastorage/codecs.md
new file mode 100644
index 00000000..82f56b7a
--- /dev/null
+++ b/versioned_docs/version-1.21.3/datastorage/codecs.md
@@ -0,0 +1,593 @@
+---
+sidebar_position: 2
+---
+# Codecs
+
+Codecs are a serialization tool from Mojang's [DataFixerUpper] used to describe how objects can be transformed between different formats, such as `JsonElement`s for JSON and `Tag`s for NBT.
+
+## Using Codecs
+
+Codecs are primarily used to encode, or serialize, Java objects to some data format type and decode, or deserialize, formatted data objects back to its associated Java type. This is typically accomplished using `Codec#encodeStart` and `Codec#parse`, respectively.
+
+### DynamicOps
+
+To determine what intermediate file format to encode and decode to, both `#encodeStart` and `#parse` require a `DynamicOps` instance to define the data within that format.
+
+The [DataFixerUpper] library contains `JsonOps` to codec JSON data stored in [`Gson`'s][gson] `JsonElement` instances. `JsonOps` supports two versions of `JsonElement` serialization: `JsonOps#INSTANCE` which defines a standard JSON file, and `JsonOps#COMPRESSED` which allows data to be compressed into a single string.
+
+```java
+// Let exampleCodec represent a Codec<ExampleJavaObject>
+// Let exampleObject be a ExampleJavaObject
+// Let exampleJson be a JsonElement
+
+// Encode Java object to regular JsonElement
+exampleCodec.encodeStart(JsonOps.INSTANCE, exampleObject);
+
+// Encode Java object to compressed JsonElement
+exampleCodec.encodeStart(JsonOps.COMPRESSED, exampleObject);
+
+// Decode JsonElement into Java object
+// Assume JsonElement was parsed normally
+exampleCodec.parse(JsonOps.INSTANCE, exampleJson);
+```
+
+Minecraft also provides `NbtOps` to codec NBT data stored in `Tag` instances. This can be referenced using `NbtOps#INSTANCE`.
+
+```java
+// Let exampleCodec represent a Codec<ExampleJavaObject>
+// Let exampleObject be a ExampleJavaObject
+// Let exampleNbt be a Tag
+
+// Encode Java object to Tag
+exampleCodec.encodeStart(NbtOps.INSTANCE, exampleObject);
+
+// Decode Tag into Java object
+exampleCodec.parse(NbtOps.INSTANCE, exampleNbt);
+```
+
+To handle registry entries, Minecraft provides `RegistryOps`, which contains a lookup provider to get available registry elements. These can be created by `RegistryOps#create` that takes in the `DynamicOps` with the specific type to store the data within and the lookup provider containing access to the available registries. NeoForge extends `RegistryOps` to create `ConditionalOps`: a registry codec lookup that can handle [conditions to load the entry][conditions].
+
+```java
+// Let lookupProvider be a HolderLookup.Provider
+// Let exampleCodec represent a Codec<ExampleJavaObject>
+// Let exampleObject be a ExampleJavaObject
+// Let exampleJson be a JsonElement
+
+// Get the registry ops for JsonElement
+RegistryOps<JsonElement> ops = RegistryOps.create(JsonOps.INSTANCE, lookupProvider);
+
+// Encode Java object to JsonElement
+exampleCodec.encodeStart(ops, exampleObject);
+
+// Decode JsonElement into Java object
+exampleCodec.parse(ops, exampleJson);
+```
+
+#### Format Conversion
+
+`DynamicOps` can also be used separately to convert between two different encoded formats. This can be done using `#convertTo` and supplying the `DynamicOps` format and the encoded object to convert.
+
+```java
+// Convert Tag to JsonElement
+// Let exampleTag be a Tag
+JsonElement convertedJson = NbtOps.INSTANCE.convertTo(JsonOps.INSTANCE, exampleTag);
+```
+
+### DataResult
+
+Encoded or decoded data using codecs return a `DataResult` which holds the converted instance or some error data depending on whether the conversion was successful. When the conversion is successful, the `Optional` supplied by `#result` will contain the successfully converted object. If the conversion fails, the `Optional` supplied by `#error` will contain the `PartialResult`, which holds the error message and a partially converted object depending on the codec.
+
+Additionally, there are many methods on `DataResult` that can be used to transform the result or error into the desired format. For example, `#resultOrPartial` will return an `Optional` containing the result on success, and the partially converted object on failure. The method takes in a string consumer to determine how to report the error message if present.
+
+```java
+// Let exampleCodec represent a Codec<ExampleJavaObject>
+// Let exampleJson be a JsonElement
+
+// Decode JsonElement into Java object
+DataResult<ExampleJavaObject> result = exampleCodec.parse(JsonOps.INSTANCE, exampleJson);
+
+result
+    // Get result or partial on error, report error message
+    .resultOrPartial(errorMessage -> /* Do something with error message */)
+    // If result or partial is present, do something
+    .ifPresent(decodedObject -> /* Do something with decoded object */);
+```
+
+## Existing Codecs
+
+### Primitives
+
+The `Codec` class contains static instances of codecs for certain defined primitives.
+
+Codec         | Java Type
+:---:         | :---
+`BOOL`        | `Boolean`
+`BYTE`        | `Byte`
+`SHORT`       | `Short`
+`INT`         | `Integer`
+`LONG`        | `Long`
+`FLOAT`       | `Float`
+`DOUBLE`      | `Double`
+`STRING`      | `String`\*
+`BYTE_BUFFER` | `ByteBuffer`
+`INT_STREAM`  | `IntStream`
+`LONG_STREAM` | `LongStream`
+`PASSTHROUGH` | `Dynamic<?>`\*\*
+`EMPTY`       | `Unit`\*\*\*
+
+\* `String` can be limited to a certain number of characters via `Codec#string` or `Codec#sizeLimitedString`.
+
+\*\* `Dynamic` is an object which holds a value encoded in a supported `DynamicOps` format. These are typically used to convert encoded object formats into other encoded object formats.
+
+\*\*\* `Unit` is an object used to represent `null` objects.
+
+### Vanilla and NeoForge
+
+Minecraft and NeoForge define many codecs for objects that are frequently encoded and decoded. Some examples include `ResourceLocation#CODEC` for `ResourceLocation`s, `ExtraCodecs#INSTANT_ISO8601` for `Instant`s in the `DateTimeFormatter#ISO_INSTANT` format, and `CompoundTag#CODEC` for `CompoundTag`s.
+
+:::caution
+`CompoundTag`s cannot decode lists of numbers from JSON using `JsonOps`. `JsonOps`, when converting, sets a number to its most narrow type. `ListTag`s force a specific type for its data, so numbers with different types (e.g. `64` would be `byte`, `384` would be `short`) will throw an error on conversion.
+:::
+
+Vanilla and NeoForge registries also have codecs for the type of object the registry contains (e.g. `BuiltInRegistries#BLOCK` have a `Codec<Block>`). `Registry#byNameCodec` will encode the registry object to their registry name. Vanilla registries also have a `Registry#holderByNameCodec` which encodes to a registry name and decodes to the registry object wrapped in a `Holder`.
+
+## Creating Codecs
+
+Codecs can be created for encoding and decoding any object. For understanding purposes, the equivalent encoded JSON will be shown.
+
+### Records
+
+Codecs can define objects through the use of records. Each record codec defines any object with explicit named fields. There are many ways to create a record codec, but the simplest is via `RecordCodecBuilder#create`.
+
+`RecordCodecBuilder#create` takes in a function which defines an `Instance` and returns an application (`App`) of the object. A correlation can be drawn to creating a class *instance* and the constructors used to *apply* the class to the constructed object.
+
+```java
+// Some object to create a codec for
+public class SomeObject {
+
+    public SomeObject(String s, int i, boolean b) { /* ... */ }
+
+    public String s() { /* ... */ }
+
+    public int i() { /* ... */ }
+
+    public boolean b() { /* ... */ }
+}
+```
+
+#### Fields
+
+An `Instance` can define up to 16 fields using `#group`. Each field must be an application defining the instance the object is being made for and the type of the object. The simplest way to meet this requirement is by taking a `Codec`, setting the name of the field to decode from, and setting the getter used to encode the field.
+
+A field can be created from a `Codec` using `#fieldOf`, if the field is required, or `#optionalFieldOf`, if the field is wrapped in an `Optional` or defaulted. Either method requires a string containing the name of the field in the encoded object. The getter used to encode the field can then be set using `#forGetter`, taking in a function which given the object, returns the field data.
+
+:::warning
+`#optionalFieldOf` will throw an error if there is an element that throws an error when parsing. If the error should be consumed, use `#lenientOptionalFieldOf` instead.
+:::
+
+From there, the resulting product can be applied via `#apply` to define how the instance should construct the object for the application. For ease of convenience, the grouped fields should be listed in the same order they appear in the constructor such that the function can simply be a constructor method reference.
+
+```java
+public static final Codec<SomeObject> RECORD_CODEC = RecordCodecBuilder.create(instance -> // Given an instance
+    instance.group( // Define the fields within the instance
+        Codec.STRING.fieldOf("s").forGetter(SomeObject::s), // String
+        Codec.INT.optionalFieldOf("i", 0).forGetter(SomeObject::i), // Integer, defaults to 0 if field not present
+        Codec.BOOL.fieldOf("b").forGetter(SomeObject::b) // Boolean
+    ).apply(instance, SomeObject::new) // Define how to create the object
+);
+```
+
+```json5
+// Encoded SomeObject
+{
+    "s": "value",
+    "i": 5,
+    "b": false
+}
+
+// Another encoded SomeObject
+{
+    "s": "value2",
+    // i is omitted, defaults to 0
+    "b": true
+}
+
+// Another encoded SomeObject
+{
+    "s": "value2",
+    // Will throw an error as lenientOptionalFieldOf is not used
+    "i": "bad_value",
+    "b": true
+}
+```
+
+### Transformers
+
+Codecs can be transformed into equivalent, or partially equivalent, representations through mapping methods. Each mapping method takes in two functions: one to transform the current type into the new type, and one to transform the new type back to the current type. This is done through the `#xmap` function.
+
+```java
+// A class
+public class ClassA {
+
+    public ClassB toB() { /* ... */ }
+}
+
+// Another equivalent class
+public class ClassB {
+
+    public ClassA toA() { /* ... */ }
+}
+
+// Assume there is some codec A_CODEC
+public static final Codec<ClassB> B_CODEC = A_CODEC.xmap(ClassA::toB, ClassB::toA);
+```
+
+If a type is partially equivalent, meaning that there are some restrictions during conversion, there are mapping functions which return a `DataResult` which can be used to return an error state whenever an exception or invalid state is reached.
+
+Is A Fully Equivalent to B | Is B Fully Equivalent to A | Transform Method
+:---:                      | :---:                      | :---
+Yes                        | Yes                        | `#xmap`
+Yes                        | No                         | `#flatComapMap`
+No                         | Yes                        | `#comapFlatMap`
+No                         | No                         | `#flatXMap`
+
+```java
+// Given an string codec to convert to a integer
+// Not all strings can become integers (A is not fully equivalent to B)
+// All integers can become strings (B is fully equivalent to A)
+public static final Codec<Integer> INT_CODEC = Codec.STRING.comapFlatMap(
+    s -> { // Return data result containing error on failure
+        try {
+            return DataResult.success(Integer.valueOf(s));
+        } catch (NumberFormatException e) {
+            return DataResult.error(s + " is not an integer.");
+        }
+    },
+    Integer::toString // Regular function
+);
+```
+
+```json5
+// Will return 5
+"5"
+
+// Will error, not an integer
+"value"
+```
+
+#### Range Codecs
+
+Range codecs are an implementation of `#flatXMap` which returns an error `DataResult` if the value is not inclusively between the set minimum and maximum. The value is still provided as a partial result if outside the bounds. There are implementations for integers, floats, and doubles via `#intRange`, `#floatRange`, and `#doubleRange` respectively.
+
+```java
+public static final Codec<Integer> RANGE_CODEC = Codec.intRange(0, 4); 
+```
+
+```json5
+// Will be valid, inside [0, 4]
+4
+
+// Will error, outside [0, 4]
+5
+```
+
+#### String Resolver
+
+`Codec#stringResolver` is an implementation of `flatXmap` which maps a string to some kind of object.
+
+```java
+public record StringResolverObject(String name) { /* ... */ }
+
+// Assume there is some Map<String, StringResolverObject> OBJECT_MAP
+public static final Codec<StringResolverObject> STRING_RESOLVER_CODEC = Codec.stringResolver(StringResolverObject::name, OBJECT_MAP::get);
+```
+
+```json5
+// Will map this string to its associated object
+"example_name"
+```
+
+### Defaults
+
+If the result of encoding or decoding fails, a default value can be supplied instead via `Codec#orElse` or `Codec#orElseGet`.
+
+```java
+public static final Codec<Integer> DEFAULT_CODEC = Codec.INT.orElse(
+    errorMessage -> /* Do something with the error message */,
+    0 // Can also be a supplied value via #orElseGet
+); 
+```
+
+```json5
+// Not an integer, defaults to 0
+"value"
+```
+
+### Unit
+
+A codec which supplies an in-code value and encodes to nothing can be represented using `Codec#unit`. This is useful if a codec uses a non-encodable entry within the data object.
+
+```java
+public static final Codec<IEventBus> UNIT_CODEC = Codec.unit(
+    () -> NeoForge.EVENT_BUS // Can also be a raw value
+);
+```
+
+```json5
+// Nothing here, will return the NeoForge event bus
+```
+
+### Lazy Initialized
+
+Sometimes, a codec may rely on data that is not present when it is constructed. In these situations `Codec#lazyInitialized` can be used to for a codec to construct itself on first encoding/decoding. The method takes in a supplied codec.
+
+```java
+public static final Codec<IEventBus> LAZY_CODEC = Codec.lazyInitialized(
+    () -> Codec.Unit(NeoForge.EVENT_BUS)
+);
+```
+
+```json5
+// Nothing here, will return the NeoForge event bus
+// Encodes/decodes the same way as the normal codec
+```
+
+### List
+
+A codec for a list of objects can be generated from an object codec via `Codec#listOf`. `listOf` can also take in integers representing the minimum and maximum size of the list. `sizeLimitedListOf` does the same but only specifies a maximum bound.
+
+```java
+// BlockPos#CODEC is a Codec<BlockPos>
+public static final Codec<List<BlockPos>> LIST_CODEC = BlockPos.CODEC.listOf();
+```
+
+```json5
+// Encoded List<BlockPos>
+[
+    [1, 2, 3], // BlockPos(1, 2, 3)
+    [4, 5, 6], // BlockPos(4, 5, 6)
+    [7, 8, 9]  // BlockPos(7, 8, 9)
+]
+```
+
+List objects decoded using a list codec are stored in an **immutable** list. If a mutable list is needed, a [transformer] should be applied to the list codec.
+
+### Map
+
+A codec for a map of keys and value objects can be generated from two codecs via `Codec#unboundedMap`. Unbounded maps can specify any string-based or string-transformed value to be a key.
+
+```java
+// BlockPos#CODEC is a Codec<BlockPos>
+public static final Codec<Map<String, BlockPos>> MAP_CODEC = Codec.unboundedMap(Codec.STRING, BlockPos.CODEC);
+```
+
+```json5
+// Encoded Map<String, BlockPos>
+{
+    "key1": [1, 2, 3], // key1 -> BlockPos(1, 2, 3)
+    "key2": [4, 5, 6], // key2 -> BlockPos(4, 5, 6)
+    "key3": [7, 8, 9]  // key3 -> BlockPos(7, 8, 9)
+}
+```
+
+Map objects decoded using a unbounded map codec are stored in an **immutable** map. If a mutable map is needed, a [transformer] should be applied to the map codec.
+
+:::caution
+Unbounded maps only support keys that encode/decode to/from strings. A key-value [pair] list codec can be used to get around this restriction.
+:::
+
+### Pair
+
+A codec for pairs of objects can be generated from two codecs via `Codec#pair`.
+
+A pair codec decodes objects by first decoding the left object in the pair, then taking the remaining part of the encoded object and decodes the right object from that. As such, the codecs must either express something about the encoded object after decoding (such as [records]), or they have to be augmented into a `MapCodec` and transformed into a regular codec via `#codec`. This can typically done by making the codec a [field] of some object.
+
+```java
+public static final Codec<Pair<Integer, String>> PAIR_CODEC = Codec.pair(
+    Codec.INT.fieldOf("left").codec(),
+    Codec.STRING.fieldOf("right").codec()
+);
+```
+
+```json5
+// Encoded Pair<Integer, String>
+{
+    "left": 5,       // fieldOf looks up 'left' key for left object
+    "right": "value" // fieldOf looks up 'right' key for right object
+}
+```
+
+:::tip
+A map codec with a non-string key can be encoded/decoded using a list of key-value pairs applied with a [transformer].
+:::
+
+### Either
+
+A codec for two different methods of encoding/decoding some object data can be generated from two codecs via `Codec#either`.
+
+An either codec attempts to decode the object using the first codec. If it fails, it attempts to decode using the second codec. If that also fails, then the `DataResult` will only contain the error from the second codec failure.
+
+```java
+public static final Codec<Either<Integer, String>> EITHER_CODEC = Codec.either(
+    Codec.INT,
+    Codec.STRING
+);
+```
+
+```json5
+// Encoded Either.Left<Integer, String>
+5
+
+// Encoded Either.Right<Integer, String>
+"value"
+```
+
+:::tip
+This can be used in conjunction with a [transformer] to get a specific object from two different methods of encoding.
+:::
+
+#### Xor
+
+`Codec#xor` is a special case of the [either] codec where a result is only successful if one of the two methods are processed successfully. If both codecs can be processed, then an error is thrown instead.
+
+```java
+public static final Codec<Either<Integer, String>> XOR_CODEC = Codec.xor(
+    Codec.INT.fieldOf("number").codec(),
+    Codec.STRING.fieldOf("text").codec()
+);
+```
+
+```json5
+// Encoded Either.Left<Integer, String>
+{
+    "number": 4
+}
+
+// Encoded Either.Right<Integer, String>
+{
+    "text": "value"
+}
+
+// Throws an error as both can be decoded
+{
+    "number": 4,
+    "text": "value"
+}
+```
+
+#### Alternative
+
+`Codec#withAlternative` is a special case of the [either] codec where both codecs are trying to decode the same object, but stored in a different format. The first, or primary, codec will attempt to decode the object. On failure, the second codec will be used instead. Encoding will always use the primary codec.
+
+```java
+public static final Codec<BlockPos> ALTERNATIVE_CODEC = Codec.withAlternative(
+    BlockPos.CODEC,
+    RecordCodecBuilder.create(instance -> instance.group(
+        Codec.INT.fieldOf("x").forGetter(BlockPos::getX),
+        Codec.INT.fieldOf("y").forGetter(BlockPos::getY),
+        Codec.INT.fieldOf("z").forGetter(BlockPos::getZ)
+    ), BlockPos::new)
+);
+```
+
+```json5
+// Normal method to decode BlockPos
+[ 1, 2, 3 ]
+
+// Alternative method to decode BlockPos
+{
+    "x": 1,
+    "y": 2,
+    "z": 3
+}
+```
+
+### Recursive
+
+Sometimes, an object may reference an object of the same type as a field. For example, `EntityPredicate` takes in an `EntityPredicate` for the vehicle, passenger, and targeted entity. In this case, `Codec#recursive` can be used to supply the codec as part of a function to create the codec.
+
+```java
+// Define our recursive object
+public record RecursiveObject(Optional<RecursiveObject> inner) { /* ... */ }
+
+public static final Codec<RecursiveObject> RECURSIVE_CODEC = Codec.recursive(
+    RecursiveObject.class.getSimpleName(), // This is for the toString method
+    recursedCodec -> RecordCodecBuilder.create(instance -> instance.group(
+        recursedCodec.optionalFieldOf("inner").forGetter(RecursiveObject::inner)
+    ).apply(instance, RecursiveObject::new))
+);
+```
+
+```json5
+// An encoded recursive object
+{
+    "inner": {
+        "inner": {}
+    }
+}
+```
+
+### Dispatch
+
+Codecs can have subcodecs which can decode a particular object based upon some specified type via `Codec#dispatch`. This is typically used in registries which contain codecs, such as rule tests or block placers.
+
+A dispatch codec first attempts to get the encoded type from some string key (usually `type`). From there, the type is decoded, calling a getter for the specific codec used to decode the actual object. If the `DynamicOps` used to decode the object compresses its maps, or the object codec itself is not augmented into a `MapCodec` (such as records or fielded primitives), then the object needs to be stored within a `value` key. Otherwise, the object is decoded at the same level as the rest of the data.
+
+```java
+// Define our object
+public abstract class ExampleObject {
+
+    // Define the method used to specify the object type for encoding
+    public abstract MapCodec<? extends ExampleObject> type();
+}
+
+// Create simple object which stores a string
+public class StringObject extends ExampleObject {
+
+    public StringObject(String s) { /* ... */ }
+
+    public String s() { /* ... */ }
+
+    public MapCodec<? extends ExampleObject> type() {
+        // A registered registry object
+        // "string":
+        //   Codec.STRING.xmap(StringObject::new, StringObject::s).fieldOf("string")
+        return STRING_OBJECT_CODEC.get();
+    }
+}
+
+// Create complex object which stores a string and integer
+public class ComplexObject extends ExampleObject {
+
+    public ComplexObject(String s, int i) { /* ... */ }
+
+    public String s() { /* ... */ }
+
+    public int i() { /* ... */ }
+
+    public MapCodec<? extends ExampleObject> type() {
+        // A registered registry object
+        // "complex":
+        //   RecordCodecBuilder.mapCodec(instance ->
+        //     instance.group(
+        //       Codec.STRING.fieldOf("s").forGetter(ComplexObject::s),
+        //       Codec.INT.fieldOf("i").forGetter(ComplexObject::i)
+        //     ).apply(instance, ComplexObject::new)
+        //   )
+        return COMPLEX_OBJECT_CODEC.get();
+    }
+}
+
+// Assume there is an Registry<MapCodec<? extends ExampleObject>> DISPATCH
+public static final Codec<ExampleObject> = DISPATCH.byNameCodec() // Gets Codec<MapCodec<? extends ExampleObject>>
+    .dispatch(
+        ExampleObject::type, // Get the codec from the specific object
+        Function.identity() // Get the codec from the registry
+    );
+```
+
+```json5
+// Simple object
+{
+    "type": "string", // For StringObject
+    "value": "value" // Codec type is not augmented from MapCodec, needs field
+}
+
+// Complex object
+{
+    "type": "complex", // For ComplexObject
+
+    // Codec type is augmented from MapCodec, can be inlined
+    "s": "value",
+    "i": 0
+}
+```
+
+[DataFixerUpper]: https://github.com/Mojang/DataFixerUpper
+[gson]: https://github.com/google/gson
+[conditions]: ../resources/server/conditions.md
+[transformer]: #transformer-codecs
+[pair]: #pair
+[records]: #records
+[field]: #fields
+[either]: #either
diff --git a/versioned_docs/version-1.21.3/datastorage/nbt.md b/versioned_docs/version-1.21.3/datastorage/nbt.md
new file mode 100644
index 00000000..4532cf06
--- /dev/null
+++ b/versioned_docs/version-1.21.3/datastorage/nbt.md
@@ -0,0 +1,105 @@
+---
+sidebar_position: 1
+---
+# Named Binary Tag (NBT)
+
+NBT is a format introduced in the earliest days of Minecraft, written by Notch himself. It is widely used throughout the Minecraft codebase for data storage.
+
+## Specification
+
+The NBT spec is similar to the JSON spec, with a few differences:
+
+- Distinct types for bytes, shorts, longs and floats exist, suffixed by `b`, `s`, `l` and `f`, respectively, similar to how they would be represented in Java code.
+    - Doubles may also be suffixed with `d`, but this is not required, similar to Java code. The optional `i` suffix available in Java for integers is not permitted.
+    - The suffixes are not case-sensitive. So for example, `64b` is the same as `64B`, and `0.5F` is the same as `0.5f`.
+- Booleans do not exist, they are instead represented by bytes. `true` becomes `1b`, `false` becomes `0b`.
+    - The current implementation treats all non-zero values as `true`, so `2b` would be treated as `true` as well.
+- There is no `null` equivalent in NBT.
+- Quotes around keys are optional. So a JSON property `"duration": 20` can become both `duration: 20` and `"duration": 20` in NBT.
+- What is known in JSON as a sub-object is known in NBT as a **compound tag** (or just compound).
+- NBT lists cannot mix and match types, unlike in JSON. The list type is determined by the first element, or defined in code.
+    - However, lists of lists can mix and match different list types. So a list of two lists, where the first one is a list of strings and the second one is a list of bytes, is allowed.
+- There are special **array** types that are different from lists, but follow their scheme of containing elements in square brackets. There are three array types:
+    - Byte arrays, denoted by a `B;` at the beginning of the array. Example: `[B;0b,30b]`
+    - Integer arrays, denoted by a `I;` at the beginning of the array. Example: `[I;0,-300]`
+    - Long arrays, denoted by an `L;` at the beginning of the array. Example: `[L;0l,240l]`
+- Trailing commas in lists, arrays and compound tags are allowed.
+
+## NBT Files
+
+Minecraft uses `.nbt` files extensively, for example for structure files in [datapacks][datapack]. Region files (`.mca`) that contain the contents of a region (i.e. a collection of chunks), as well as the various `.dat` files used in different places by the game, are NBT files as well.
+
+NBT files are typically compressed with GZip. As such, they are binary files and cannot be edited directly.
+
+## NBT in Code
+
+Like in JSON, all NBT objects are children of an enclosing object. So let's create one:
+
+```java
+CompoundTag tag = new CompoundTag();
+```
+
+We can now put our data into that tag:
+
+```java
+tag.putInt("Color", 0xffffff);
+tag.putString("Level", "minecraft:overworld");
+tag.putDouble("IAmRunningOutOfIdeasForNamesHere", 1d);
+```
+
+Several helpers exist here, for example, `putIntArray` also has a convenience method that takes a `List<Integer>` in addition to the standard variant that takes an `int[]`.
+
+Of course, we can also get values from that tag:
+
+```java
+int color = tag.getInt("Color");
+String level = tag.getString("Level");
+double d = tag.getDouble("IAmRunningOutOfIdeasForNamesHere");
+```
+
+Number types will return 0 if absent. Strings will return `""` if absent. More complex types (lists, arrays, compounds) will throw an exception if absent.
+
+As such, we want to safeguard by checking if a tag element exists:
+
+```java
+boolean hasColor = tag.contains("Color");
+boolean hasColorMoreExplicitly = tag.contains("Color", Tag.TAG_INT);
+```
+
+The `TAG_INT` constant is defined in `Tag`, which is the super interface for all tag types. Most tag types besides `CompoundTag` are mostly internal, for example `ByteTag` or `StringTag`, though the direct `CompoundTag#get` and `#put` methods can work with them if you ever stumble across some.
+
+There is one obvious exception, though: `ListTag`s. Working with these is special because when getting a list tag through `CompoundTag#getList`, you must also specify the list type. So getting a list of strings, for example, would work like this:
+
+```java
+ListTag list = tag.getList("SomeListHere", Tag.TAG_STRING);
+```
+
+Similarly, when creating a `ListTag`, you must also specify the list type during creation:
+
+```java
+ListTag list = new ListTag(List.of("Value1", "Value2"), Tag.TAG_STRING);
+```
+
+Finally, working with `CompoundTag`s inside other `CompoundTag`s directly utilizes `CompoundTag#get` and `#put`:
+
+```java
+tag.put("Tag", new CompoundTag());
+tag.get("Tag");
+```
+
+## Usages of NBT
+
+NBT is used in a lot of places in Minecraft. Some of the most common examples include [`BlockEntity`][blockentity]s and `Entity`s.
+
+:::note
+`ItemStack`s abstract away the usage of NBT into [data components][datacomponents].
+:::
+
+## See Also
+
+- [NBT Format on the Minecraft Wiki][nbtwiki]
+
+[blockentity]: ../blockentities/index.md
+[datapack]: ../resources/index.md#data
+[datacomponents]: ../items/datacomponents.md
+[nbtwiki]: https://minecraft.wiki/w/NBT_format
diff --git a/versioned_docs/version-1.21.3/datastorage/saveddata.md b/versioned_docs/version-1.21.3/datastorage/saveddata.md
new file mode 100644
index 00000000..37f1a6bb
--- /dev/null
+++ b/versioned_docs/version-1.21.3/datastorage/saveddata.md
@@ -0,0 +1,60 @@
+---
+sidebar_position: 4
+---
+# Saved Data
+
+The Saved Data (SD) system can be used to save additional data on levels.
+
+_If the data is specific to some block entities, chunks, or entities, consider using a [data attachment](attachments) instead._
+
+## Declaration
+
+Each SD implementation must subtype the `SavedData` class. There are two important methods to be aware of:
+
+- `save`: Allows the implementation to write NBT data to the level.
+- `setDirty`: A method that must be called after changing the data, to notify the game that there are changes that need to be written. If not called, `#save` will not get called and the original data will remain unchanged.
+
+## Attaching to a Level
+
+Any `SavedData` is loaded and/or attached to a level dynamically. As such, if one is never created on a level, then it will not exist.
+
+`SavedData`s are created and loaded from the `DimensionDataStorage`, which can be accessed by calling either `ServerChunkCache#getDataStorage` or `ServerLevel#getDataStorage`. From there, you can get or create an instance of your SD by calling `DimensionDataStorage#computeIfAbsent`. This will attempt to get the current instance of the SD if present or create a new one and load all available data.
+
+`DimensionDataStorage#computeIfAbsent` takes in two arguments. The first is an instance of `SavedData.Factory`, which consists of a supplier to construct a new instance of the SD and a function to load NBT data into a SD and return it. The second argument is the name of the `.dat` file stored within the `data` folder for the implemented level. The name must be a valid filename and can not contain `/` or `\`.
+
+For example, if a SD was named "example" within the Nether, then a file would be created at `./<level_folder>/DIM-1/data/example.dat` and would be implemented like so:
+
+```java
+// In some saved data implementation
+public class ExampleSavedData extends SavedData {
+
+    // Create new instance of saved data
+    public ExampleSavedData create() {
+        return new ExampleSavedData();
+    }
+
+    // Load existing instance of saved data
+    public ExampleSavedData load(CompoundTag tag, HolderLookup.Provider lookupProvider) {
+        ExampleSavedData data = this.create();
+        // Load saved data
+        return data;
+    }
+
+    @Override
+    public CompoundTag save(CompoundTag tag, HolderLookup.Provider registries) {
+        // Write data to tag
+        return tag;
+    }
+
+    public void foo() {
+        // Change data in saved data
+        // Call set dirty if data changes
+        this.setDirty();
+    }
+}
+
+// In some method within the class
+netherDataStorage.computeIfAbsent(new Factory<>(this::create, this::load), "example");
+```
+
+If a SD is not specific to a level, the SD should be attached to the Overworld, which can be obtained from `MinecraftServer#overworld`. The Overworld is the only dimension that is never fully unloaded and as such makes it perfect to store multi-level data on.
diff --git a/versioned_docs/version-1.21.3/gettingstarted/_category_.json b/versioned_docs/version-1.21.3/gettingstarted/_category_.json
new file mode 100644
index 00000000..5ed99b17
--- /dev/null
+++ b/versioned_docs/version-1.21.3/gettingstarted/_category_.json
@@ -0,0 +1,4 @@
+{
+    "label": "Getting Started",
+    "position": 1
+}
\ No newline at end of file
diff --git a/versioned_docs/version-1.21.3/gettingstarted/index.md b/versioned_docs/version-1.21.3/gettingstarted/index.md
new file mode 100644
index 00000000..c6d77d06
--- /dev/null
+++ b/versioned_docs/version-1.21.3/gettingstarted/index.md
@@ -0,0 +1,61 @@
+# Getting Started with NeoForge
+
+This section includes information about how to set up a NeoForge workspace, and how to run and test your mod.
+
+## Prerequisites
+
+- Familiarity with the Java programming language, specifically its object-oriented, polymorphic, generic, and functional features.
+- An installation of the Java 21 Development Kit (JDK) and 64-bit Java Virtual Machine (JVM). NeoForge recommends and officially supports the [Microsoft builds of OpenJDK][jdk], but any other JDK should work as well.
+
+:::caution
+Make sure you are using a 64-bit JVM. One way of checking is to run `java -version` in a terminal. Issues may arise when using a 32-bit JVM, due to 32-bit JVMs running out of support for a lot of things.
+:::
+
+- Familiarity with an Integrated Development Environment (IDE) of your choice.
+      - NeoForge officially supports [IntelliJ IDEA][intellij] and [Eclipse][eclipse], both of which have integrated Gradle support. However, any IDE can be used, ranging from Netbeans or Visual Studio Code to Vim or Emacs.
+- Familiarity with [Git][git] and [GitHub][github]. This is technically not required, but it will make your life a lot easier.
+
+## Setting Up the Workspace
+
+- Open the Mod Developer Kit (MDK) (either [ModDevGradle][mdgmdk] or [NeoGradle][ngmdk]) GitHub repository, click "Use this template" and clone the newly-created repository to your local machine.
+      - If you do not want to use GitHub, or if you want to get the template for an older commit, you can also download the ZIP of the repository (under Code -> Download ZIP) and extract it.
+- Open your IDE and import the Gradle project. Eclipse and IntelliJ IDEA will do this automatically for you. If you have an IDE that does not do this, you can also do it via the `gradlew` terminal command.
+      - When doing this for the first time, Gradle will download all dependencies of NeoForge, including Minecraft itself, and decompile them. This can take a fair amount of time (up to an hour, depending on your hardware and network strength).
+      - Whenever you make a change to the Gradle files, the Gradle changes will need to be reloaded, either through the "Reload Gradle" button in your IDE, or again through the `gradlew` terminal command.
+
+## Customizing Your Mod Information
+
+Many of the basic properties of your mod can be changed in the `gradle.properties` file. This includes basic things like the mod name or the mod version. For more information, see the comments in the `gradle.properties` file, or see [the documentation of the `gradle.properties` file][properties].
+
+If you want to modify the build process beyond that, you can edit the `build.gradle` file. NeoGradle, the Gradle plugin for NeoForge, provides several configuration options, a few of which are explained by comments in the `build.gradle` files. For full documentation, see the [NeoGradle documentation][neogradle].
+
+:::caution
+Only edit the `build.gradle` and `settings.gradle` files if you know what you are doing. All basic properties can be set via `gradle.properties`.
+:::
+
+## Building and Testing Your Mod
+
+To build your mod, run `gradlew build`. This will output a file in `build/libs` with the name `<archivesBaseName>-<version>.jar`. `<archivesBaseName>` and `<version>` are properties set by the `build.gradle` and default to the `mod_id` and `mod_version` values in the `gradle.properties` file, respectively; this can be changed in the `build.gradle` if desired. The resulting JAR file can then be placed in the `mods` folder of a NeoForge-enabled Minecraft setup, or uploaded to a mod distribution platform.
+
+To run your mod in a test environment, you can either use the generated run configurations or use the associated tasks (e.g. `gradlew runClient`). This will launch Minecraft from the corresponding runs directory (e.g. `runs/client` or `runs/server`), along with any source sets specified. The default MDK includes the `main` source set, so any code written in `src/main/java` will be applied.
+
+### Server Testing
+
+If you are running a dedicated server, whether through the run configuration or `gradlew runServer`, the server will shut down immediately. You will need to accept the Minecraft EULA by editing the `eula.txt` file in the run directory.
+
+Once accepted, the server will load and become available under `localhost` (or `127.0.0.1` by default). However, you will still not able to join, because the server will be put into online mode by default, which requires authentication (that the Dev player does not have). To fix this, stop your server again and set the `online-mode` property in the `server.properties` file to `false`. Now, start your server, and you should be able to connect.
+
+:::tip
+You should always test your mod in a dedicated server environment. This includes [client-only mods][client], as these should not do anything when loaded on the server.
+:::
+
+[client]: ../concepts/sides.md
+[eclipse]: https://www.eclipse.org/downloads/
+[git]: https://www.git-scm.com/
+[github]: https://github.com/
+[intellij]: https://www.jetbrains.com/idea/
+[jdk]: https://learn.microsoft.com/en-us/java/openjdk/download#openjdk-21
+[mdgmdk]: https://github.com/NeoForgeMDKs/MDK-1.21.3-ModDevGradle
+[ngmdk]: https://github.com/NeoForgeMDKs/MDK-1.21.3-NeoGradle
+[neogradle]: https://docs.neoforged.net/neogradle/docs/
+[properties]: modfiles.md#gradleproperties
diff --git a/versioned_docs/version-1.21.3/gettingstarted/modfiles.md b/versioned_docs/version-1.21.3/gettingstarted/modfiles.md
new file mode 100644
index 00000000..25820979
--- /dev/null
+++ b/versioned_docs/version-1.21.3/gettingstarted/modfiles.md
@@ -0,0 +1,247 @@
+# Mod Files
+
+The mod files are responsible for determining what mods are packaged into your JAR, what information to display within the 'Mods' menu, and how your mod should be loaded in the game.
+
+## `gradle.properties`
+
+The `gradle.properties` file holds various common properties of your mod, such as the mod id or mod version. During building, Gradle reads the values in these files and inlines them in various places, such as the [neoforge.mods.toml][neoforgemodstoml] file. This way, you only need to change values in one place, and they are then applied everywhere for you.
+
+Most values are also explained as comments in [the MDK's `gradle.properties` file][mdkgradleproperties].
+
+| Property                  | Description                                                                                                                                                                                                                             | Example                                    |
+|---------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------|
+| `org.gradle.jvmargs`      | Allows you to pass extra JVM arguments to Gradle. Most commonly, this is used to assign more/less memory to Gradle. Note that this is for Gradle itself, not Minecraft.                                                                 | `org.gradle.jvmargs=-Xmx3G`                |
+| `org.gradle.daemon`       | Whether Gradle should use the daemon when building.                                                                                                                                                                                     | `org.gradle.daemon=false`                  |
+| `org.gradle.debug`        | Whether Gradle is set to debug mode. Debug mode mainly means more Gradle log output. Note that this is for Gradle itself, not Minecraft.                                                                                                | `org.gradle.debug=false`                   |
+| `minecraft_version`       | The Minecraft version you are modding on. Must match with `neo_version`.                                                                                                                                                                | `minecraft_version=1.20.6`                 |
+| `minecraft_version_range` | The Minecraft version range this mod can use, as a [Maven Version Range][mvr]. Note that [snapshots, pre-releases and release candidates][mcversioning] are not guaranteed to sort properly, as they do not follow maven versioning.    | `minecraft_version_range=[1.20.6,1.21)`    |
+| `neo_version`             | The NeoForge version you are modding on. Must match with `minecraft_version`. See [NeoForge Versioning][neoversioning] for more information on how NeoForge versioning works.                                                           | `neo_version=20.6.62`                      |
+| `neo_version_range`       | The NeoForge version range this mod can use, as a [Maven Version Range][mvr].                                                                                                                                                           | `neo_version_range=[20.6.62,20.7)`         |
+| `loader_version_range`    | The version range of the mod loader this mod can use, as a [Maven Version Range][mvr]. Note that the loader versioning is decoupled from NeoForge versioning.                                                                           | `loader_version_range=[1,)`                |
+| `mod_id`                  | See [The Mod ID][modid].                                                                                                                                                                                                                | `mod_id=examplemod`                        |
+| `mod_name`                | The human-readable display name of your mod. By default, this can only be seen in the mod list, however, mods such as [JEI][jei] prominently display mod names in item tooltips as well.                                                | `mod_name=Example Mod`                     |
+| `mod_license`             | The license your mod is provided under. It is suggested that this is set to the [SPDX identifier][spdx] you are using and/or a link to the license. You can visit https://choosealicense.com/ to help pick the license you want to use. | `mod_license=MIT`                          |
+| `mod_version`             | The version of your mod, shown in the mod list. See [the page on Versioning][versioning] for more information.                                                                                                                          | `mod_version=1.0`                          |
+| `mod_group_id`            | See [The Group ID][group].                                                                                                                                                                                                              | `mod_group_id=com.example.examplemod`      |
+| `mod_authors`             | The authors of the mod, shown in the mod list.                                                                                                                                                                                          | `mod_authors=ExampleModder`                |
+| `mod_description`         | The description of the mod, as a multiline string, shown in the mod list. Newline characters (`\n`) can be used and will be replaced properly.                                                                                          | `mod_description=Example mod description.` |
+
+### The Mod ID
+
+The mod ID is the main way your mod is distinguished from others. It is used in a wide variety of places, including as the namespace for your mod's [registries][registration], and as your [resource and data pack][resource] namespaces. Having two mods with the same id will prevent the game from loading.
+
+As such, your mod ID should be something unique and memorable. Usually, it will be your mod's display name (but lower case), or some variation thereof. Mod IDs may only contain lowercase letters, digits and underscores, and must be between 2 and 64 characters long (both inclusive).
+
+:::info
+Changing this property in the `gradle.properties` file will automatically apply the change everywhere, except for the [`@Mod` annotation][javafml] in your main mod class. There, you need to change it manually to match the value in the `gradle.properties` file.
+:::
+
+### The Group ID
+
+While the `group` property in the `build.gradle` is only necessary if you plan to publish your mod to a maven, it is considered good practice to always properly set this. This is done for you through the `gradle.properties`'s `mod_group_id` property.
+
+The group id should be set to your top-level package. See [Packaging][packaging] for more information.
+
+```text
+// In your gradle.properties file
+mod_group_id=com.example
+```
+
+The packages within your java source (`src/main/java`) should also now conform to this structure, with an inner package representing the mod id:
+
+```text
+com
+- example (top-level package specified in group property)
+    - mymod (the mod id)
+        - MyMod.java (renamed ExampleMod.java)
+```
+
+## `neoforge.mods.toml`
+
+The `neoforge.mods.toml` file, located at `src/main/resources/META-INF/neoforge.mods.toml`, is a file in [TOML][toml] format that defines the metadata of your mod(s). It also contains additional information on how your mod(s) should be loaded into the game, as well as display information that is displayed within the 'Mods' menu. The [`neoforge.mods.toml` file provided by the MDK][mdkneoforgemodstoml] contains comments explaining every entry, they will be explained here in more detail.
+
+The `neoforge.mods.toml` can be separated into three parts: the non-mod-specific properties, which are linked to the mod file; the mod properties, with a section for each mod; and the dependency configurations, with a section for each mod's or mods' dependencies. Some of the properties associated with the `neoforge.mods.toml` file are mandatory; mandatory properties require a value to be specified, otherwise an exception will be thrown.
+
+:::note
+In the default MDK, Gradle replaces various properties in this file with the values specified in the `gradle.properties` file. For example, the line `license="${mod_license}"` means that the `license` field is replaced by the `mod_license` property from `gradle.properties`. Values that are replaced like this should be changed in the `gradle.properties` instead of changing them here.
+:::
+
+### Non-Mod-Specific Properties
+
+Non-mod-specific properties are properties associated with the JAR itself, indicating how to load the mod(s) and any additional global metadata.
+
+| Property             | Type     | Default        | Description                                                                                                                                                                                                                                                                                                                                         | Example                                                                        |
+|----------------------|----------|----------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------|
+| `modLoader`          | string   | **mandatory**  | The language loader used by the mod(s). Can be used to support alternative language structures, such as Kotlin objects for the main file, or different methods of determining the entrypoint, such as an interface or method. NeoForge provides the Java loader [`"javafml"`][javafml] and the lowcode/nocode loader [`"lowcodefml"`][lowcodefml].  | `modLoader="javafml"`                                                          |
+| `loaderVersion`      | string   | **mandatory**  | The acceptable version range of the language loader, expressed as a [Maven Version Range][mvr]. For `javafml` and `lowcodefml`, this is currently version `1`.                                                                                                                                                                                      | `loaderVersion="[1,)"`                                                         |
+| `license`            | string   | **mandatory**  | The license the mod(s) in this JAR are provided under. It is suggested that this is set to the [SPDX identifier][spdx] you are using and/or a link to the license. You can visit https://choosealicense.com/ to help pick the license you want to use.                                                                                              | `license="MIT"`                                                                |
+| `showAsResourcePack` | boolean  | `false`        | When `true`, the mod(s)'s resources will be displayed as a separate resource pack on the 'Resource Packs' menu, rather than being combined with the 'Mod Resources' pack.                                                                                                                                                                           | `showAsResourcePack=true`                                                      |
+| `showAsDataPack`     | boolean  | `false`        | When `true`, the mod(s)'s data files will be displayed as a separate data pack on the 'Data Packs' menu, rather than being combined with the 'Mod Data' pack.                                                                                                                                                                           | `showAsDataPack=true`                                                          |
+| `services`           | array    | `[]`           | An array of services your mod uses. This is consumed as part of the created module for the mod from NeoForge's implementation of the Java Platform Module System.                                                                                                                                                                                   | `services=["net.neoforged.neoforgespi.language.IModLanguageProvider"]`         |
+| `properties`         | table    | `{}`           | A table of substitution properties. This is used by `StringSubstitutor` to replace `${file.<key>}` with its corresponding value.                                                                                                                                                                                                                    | `properties={"example"="1.2.3"}` (can then be referenced by `${file.example}`) |
+| `issueTrackerURL`    | string   | _nothing_      | A URL representing the place to report and track issues with the mod(s).                                                                                                                                                                                                                                                                            | `"https://github.com/neoforged/NeoForge/issues"`                               |
+
+:::note
+The `services` property is functionally equivalent to specifying the [`uses` directive in a module][uses], which allows [loading a service of a given type][serviceload].
+
+Alternatively, it can be defined in a service file inside the `src/main/resources/META-INF/services` folder, where the file name is the fully-qualified name of the service, and the file content is the name of the service to load (see also [this example from the AtlasViewer mod][atlasviewer]).
+:::
+
+### Mod-Specific Properties
+
+Mod-specific properties are tied to the specified mod using the `[[mods]]` header. This is an [array of tables][array]; all key/value properties will be attached to that mod until the next header.
+
+```toml
+# Properties for examplemod1
+[[mods]]
+modId = "examplemod1"
+
+# Properties for examplemod2
+[[mods]]
+modId = "examplemod2"
+```
+
+| Property         | Type     | Default                      | Description                                                                                                                                                                                                                                                                    | Example                                                         |
+|------------------|----------|------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------|
+| `modId`          | string   | **mandatory**                | See [The Mod ID][modid].                                                                                                                                                                                                                                                       | `modId="examplemod"`                                            |
+| `namespace`      | string   | value of `modId`             | An override namespace for the mod. Must also be a valid [mod ID][modid], but may additionally include dots or dashes. Currently unused.                                                                                                                                        | `namespace="example"`                                           |
+| `version`        | string   | `"1"`                        | The version of the mod, preferably in a [variation of Maven versioning][versioning]. When set to `${file.jarVersion}`, it will be replaced with the value of the `Implementation-Version` property in the JAR's manifest (displays as `0.0NONE` in a development environment). | `version="1.20.2-1.0.0"`                                        |
+| `displayName`    | string   | value of `modId`             | The display name of the mod. Used when representing the mod on a screen (e.g., mod list, mod mismatch).                                                                                                                                                                        | `displayName="Example Mod"`                                     |
+| `description`    | string   | `'''MISSING DESCRIPTION'''`  | The description of the mod shown in the mod list screen. It is recommended to use a [multiline literal string][multiline]. This value is also translatable, see [Translating Mod Metadata][i18n] for more info.                                                                | `description='''This is an example.'''`                         |
+| `logoFile`       | string   | _nothing_                    | The name and extension of an image file used on the mods list screen. The location must be an absolute path starting from the root of the JAR or source set (e.g. `src/main/resources` for the main source set). Valid filename characters are lowercase letters (`a-z`), digits (`0-9`), slashes, (`/`), underscores (`_`), periods (`.`) and hyphens (`-`). The complete character set is `[a-z0-9_-.]`.                                                                  | `logoFile="test/example_logo.png"`                              |
+| `logoBlur`       | boolean  | `true`                       | Whether to use `GL_LINEAR*` (true) or `GL_NEAREST*` (false) to render the `logoFile`. In simpler terms, this means whether the logo should be blurred or not when trying to scale the logo.                                                                                    | `logoBlur=false`                                                |
+| `updateJSONURL`  | string   | _nothing_                    | A URL to a JSON used by the [update checker][update] to make sure the mod you are playing is the latest version.                                                                                                                                                               | `updateJSONURL="https://example.github.io/update_checker.json"` |
+| `features`       | table    | `{}`                         | See [features].                                                                                                                                                                                                                                                                | `features={java_version="[17,)"}`                               |
+| `modproperties`  | table    | `{}`                         | A table of key/values associated with this mod. Unused by NeoForge, but is mainly for use by mods.                                                                                                                                                                             | `modproperties={example="value"}`                               |
+| `modUrl`         | string   | _nothing_                    | A URL to the download page of the mod. Currently unused.                                                                                                                                                                                                                       | `modUrl="https://neoforged.net/"`                               |
+| `credits`        | string   | _nothing_                    | Credits and acknowledges for the mod shown on the mod list screen.                                                                                                                                                                                                             | `credits="The person over here and there."`                     |
+| `authors`        | string   | _nothing_                    | The authors of the mod shown on the mod list screen.                                                                                                                                                                                                                           | `authors="Example Person"`                                      |
+| `displayURL`     | string   | _nothing_                    | A URL to the display page of the mod shown on the mod list screen.                                                                                                                                                                                                             | `displayURL="https://neoforged.net/"`                           |
+| `enumExtensions` | string   | _nothing_                    | The file path of a JSON file used for [enum extension][enumextension]                                                                                                                                                                                                          | `enumExtensions="META_INF/enumextensions.json"`                 |
+| `featureFlags`   | string   | _nothing_                    | The file path of a JSON file used for [feature flags][featureflags]                                                                                                                                                                                                            | `featureFlags="META-INF/feature_flags.json"`                    |
+
+#### Features
+
+The features system allows mods to demand that certain settings, software, or hardware are available when loading the system. When a feature is not satisfied, mod loading will fail, informing the user about the requirement. Currently, NeoForge provides the following features:
+
+| Feature          | Description                                                                                                                                                                                                | Example                             |
+|------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------|
+| `javaVersion`   | The acceptable version range of the Java version, expressed as a [Maven Version Range][mvr]. This should be the supported version used by Minecraft.                                                       | `features={javaVersion="[17,)"}`  |
+| `openGLVersion` | The acceptable version range of the OpenGL version, expressed as a [Maven Version Range][mvr]. Minecraft requires OpenGL 3.2 or newer. If you want to require a newer OpenGL version, you can do so here.  | `features={openGLVersion="[4.6,)"}` |
+
+### Access Transformer-Specific Properties
+
+[Access Transformer-specific properties][accesstransformer] are tied to the specified access transformer using the `[[accessTransformers]]` header. This is an [array of tables][array]; all key/value properties will be attached to that access transformer until the next header. The access transformer header is optional; however, when specified, all elements are mandatory.
+
+| Property |  Type  |    Default    |             Description              |     Example     |
+|:--------:|:------:|:-------------:|:------------------------------------:|:----------------|
+| `file`   | string | **mandatory** | See [Adding ATs][accesstransformer]. | `file="at.cfg"` |
+
+### Mixin Configuration Properties
+
+[Mixin Configuration Properties][mixinconfig] are tied to the specified mixin config using the `[[mixins]]` header. This is an [array of tables][array]; all key/value properties will be attached to that mixin block until the next header. The mixin header is optional; however, when specified, all elements are mandatory.
+
+| Property |  Type  |    Default    |             Description                       |     Example                       |
+|:--------:|:------:|:-------------:|:---------------------------------------------:|:----------------------------------|
+| `config` | string | **mandatory** | The location of the mixin configuration file. | `config="examplemod.mixins.json"` |
+
+### Dependency Configurations
+
+Mods can specify their dependencies, which are checked by NeoForge before loading the mods. These configurations are created using the [array of tables][array] `[[dependencies.<modid>]]`, where `modid` is the identifier of the mod that consumes the dependency.
+
+| Property       | Type    | Default        | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                | Example                                      |
+|----------------|---------|----------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------|
+| `modId`        | string  | **mandatory**  | The identifier of the mod added as a dependency.                                                                                                                                                                                                                                                                                                                                                                                                                           | `modId="jei"`                                |
+| `type`         | string  | `"required"`   | Specifies the nature of this dependency: `"required"` is the default and prevents the mod from loading if this dependency is missing; `"optional"` will not prevent the mod from loading if the dependency is missing, but still validates that the dependency is compatible; `"incompatible"` prevents the mod from loading if this dependency is present; `"discouraged"` still allows the mod to load if the dependency is present, but presents a warning to the user. | `type="incompatible"`                        |
+| `reason`       | string  | _nothing_      | An optional user-facing message to describe why this dependency is required, or why it is incompatible.                                                                                                                                                                                                                                                                                                                                                                    | `reason="integration"`                       |
+| `versionRange` | string  | `""`           | The acceptable version range of the language loader, expressed as a [Maven Version Range][mvr]. An empty string matches any version.                                                                                                                                                                                                                                                                                                                                       | `versionRange="[1, 2)"`                      |
+| `ordering`     | string  | `"NONE"`       | Defines if the mod must load before (`"BEFORE"`) or after (`"AFTER"`) this dependency. If the ordering does not matter, return `"NONE"`                                                                                                                                                                                                                                                                                                                                    | `ordering="AFTER"`                           |
+| `side`         | string  | `"BOTH"`       | The [physical side][sides] the dependency must be present on: `"CLIENT"`, `"SERVER"`, or `"BOTH"`.                                                                                                                                                                                                                                                                                                                                                                         | `side="CLIENT"`                              |
+| `referralUrl`  | string  | _nothing_      | A URL to the download page of the dependency. Currently unused.                                                                                                                                                                                                                                                                                                                                                                                                            | `referralUrl="https://library.example.com/"` |
+
+:::danger
+The `ordering` of two mods may cause a crash due to a cyclic dependency, for example if mod A must load `"BEFORE"` mod B and at the same time, mod B must load `"BEFORE"` mod A.
+:::
+
+## Mod Entrypoints
+
+Now that the `neoforge.mods.toml` is filled out, we need to provide an entrypoint for the mod. Entrypoints are essentially the starting point for executing the mod. The entrypoint itself is determined by the language loader used in the `neoforge.mods.toml`.
+
+### `javafml` and `@Mod`
+
+`javafml` is a language loader provided by NeoForge for the Java programming language. The entrypoint is defined using a public class with the `@Mod` annotation. The value of `@Mod` must contain one of the mod ids specified within the `neoforge.mods.toml`. From there, all initialization logic (e.g. [registering events][events] or [adding `DeferredRegister`s][registration]) can be specified within the constructor of the class.
+
+The main mod class must only have one public constructor; otherwise a `RuntimeException` will be thrown. The constructor may have **any** of the following arguments in **any** order; none of them are explicitly required. However, no duplicate parameters are allowed.
+
+Argument Type     | Description                                                                                              |
+------------------|----------------------------------------------------------------------------------------------------------|
+`IEventBus`       | The [mod-specific event bus][modbus] (needed for registration, events, etc.)                             |
+`ModContainer`    | The abstract container holding this mod's metadata                                                       |
+`FMLModContainer` | The actual container as defined by `javafml` holding this mod's metadata; an extension of `ModContainer` |
+`Dist`            | The [physical side][sides] this mod is loading on                                                        |
+
+```java
+@Mod("examplemod") // Must match a mod id in the neoforge.mods.toml
+public class ExampleMod {
+    // Valid constructor, only uses two of the available argument types
+    public ExampleMod(IEventBus modBus, ModContainer container) {
+        // Initialize logic here
+    }
+}
+```
+
+By default, a `@Mod` annotation is loaded on both [sides]. This can be changed by specifying the `dist` parameter:
+
+```java
+// Must match a mod id in the neoforge.mods.toml
+// This mod class will only be loaded on the physical client
+@Mod(value = "examplemod", dist = Dist.CLIENT) 
+public class ExampleModClient {
+    // Valid constructor
+    public ExampleModClient(FMLModContainer container, IEventBus modBus, Dist dist) {
+        // Initialize client-only logic here
+    }
+}
+```
+
+:::note
+An entry in `neoforge.mods.toml` does not need a corresponding `@Mod` annotation. Likewise, an entry in the `neoforge.mods.toml` can have multiple `@Mod` annotations, for example if you want to separate common logic and client only logic.
+:::
+
+### `lowcodefml`
+
+`lowcodefml` is a language loader used as a way to distribute datapacks and resource packs as mods without the need of an in-code entrypoint. It is specified as `lowcodefml` rather than `nocodefml` for minor additions in the future that might require minimal coding.
+
+[accesstransformer]: ../advanced/accesstransformers.md#adding-ats
+[array]: https://toml.io/en/v1.0.0#array-of-tables
+[atlasviewer]: https://github.com/XFactHD/AtlasViewer/blob/1.20.2/neoforge/src/main/resources/META-INF/services/xfacthd.atlasviewer.platform.services.IPlatformHelper
+[events]: ../concepts/events.md
+[features]: #features
+[group]: #the-group-id
+[i18n]: ../resources/client/i18n.md#translating-mod-metadata
+[javafml]: #javafml-and-mod
+[jei]: https://www.curseforge.com/minecraft/mc-mods/jei
+[lowcodefml]: #lowcodefml
+[mcversioning]: versioning.md#minecraft
+[mdkgradleproperties]: https://github.com/NeoForgeMDKs/MDK-1.21-NeoGradle/blob/main/gradle.properties
+[mdkneoforgemodstoml]: https://github.com/NeoForgeMDKs/MDK-1.21-NeoGradle/blob/main/src/main/resources/META-INF/neoforge.mods.toml
+[neoforgemodstoml]: #neoforgemodstoml
+[mixinconfig]: https://github.com/SpongePowered/Mixin/wiki/Introduction-to-Mixins---The-Mixin-Environment#mixin-configuration-files
+[modbus]: ../concepts/events.md#event-buses
+[modid]: #the-mod-id
+[mojmaps]: https://github.com/neoforged/NeoForm/blob/main/Mojang.md
+[multiline]: https://toml.io/en/v1.0.0#string
+[mvr]: https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html
+[neoversioning]: versioning.md#neoforge
+[packaging]: structuring.md#packaging
+[registration]: ../concepts/registries.md#deferredregister
+[resource]: ../resources/index.md
+[serviceload]: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/ServiceLoader.html#load(java.lang.Class)
+[sides]: ../concepts/sides.md
+[spdx]: https://spdx.org/licenses/
+[toml]: https://toml.io/
+[update]: ../misc/updatechecker.md
+[uses]: https://docs.oracle.com/javase/specs/jls/se21/html/jls-7.html#jls-7.7.3
+[versioning]: versioning.md
+[enumextension]: ../advanced/extensibleenums.md
+[featureflags]: ../advanced/featureflags.md
diff --git a/versioned_docs/version-1.21.3/gettingstarted/structuring.md b/versioned_docs/version-1.21.3/gettingstarted/structuring.md
new file mode 100644
index 00000000..2f801772
--- /dev/null
+++ b/versioned_docs/version-1.21.3/gettingstarted/structuring.md
@@ -0,0 +1,80 @@
+# Structuring Your Mod
+
+Structured mods are beneficial for maintenance, making contributions, and providing a clearer understanding of the underlying codebase. Some of the recommendations from Java, Minecraft, and NeoForge are listed below.
+
+:::note
+You do not have to follow the advice below; you can structure your mod any way you see fit. However, it is still highly recommended to do so.
+:::
+
+## Packaging
+
+When structuring your mod, pick a unique, top-level package structure. Many programmers will use the same name for different classes, interfaces, etc. Java allows classes to have the same name as long as they are in different packages. As such, if two classes have the same package with the same name, only one would be loaded, most likely causing the game to crash.
+
+```
+a.jar
+    - com.example.ExampleClass
+b.jar
+    - com.example.ExampleClass // This class will not normally be loaded
+```
+
+This is even more relevant when it comes to loading modules. If there are class files in two packages under the same name in separate modules, this will cause the mod loader to crash on startup since mod modules are exported to the game and other mods.
+
+```
+module A
+    - package X
+        - class I
+        - class J
+module B
+    - package X // This package will cause the mod loader to crash, as there already is a module with package X being exported
+        - class R
+        - class S
+        - class T
+```
+
+As such, your top level package should be something that you own: a domain, email address, a (subdomain of a) website, etc. It can even be your name or username as long as you can guarantee that it will be uniquely identifiable within the expected target. Furthermore, the top-level package should also match your [group id][group].
+
+|   Type    |       Value       | Top-Level Package   |
+|:---------:|:-----------------:|:--------------------|
+|  Domain   |    example.com    | `com.example`       |
+| Subdomain | example.github.io | `io.github.example` |
+|   Email   | example@gmail.com | `com.gmail.example` |
+
+The next level package should then be your mod's id (e.g. `com.example.examplemod` where `examplemod` is the mod id). This will guarantee that, unless you have two mods with the same id (which should never be the case), your packages should not have any issues loading.
+
+You can find some additional naming conventions on [Oracle's tutorial page][naming].
+
+### Sub-package Organization
+
+In addition to the top-level package, it is highly recommend to break your mod's classes between subpackages. There are two major methods on how to do so:
+
+- **Group By Function**: Make subpackages for classes with a common purpose. For example, blocks can be under `block`, items under `item`, entities under `entity`, etc. Minecraft itself uses a similar structure (with some exceptions).
+- **Group By Logic**: Make subpackages for classes with a common logic. For example, if you were creating a new type of crafting table, you would put its block, menu, item, and more under `feature.crafting_table`.
+
+#### Client, Server, and Data Packages
+
+In general, code only for a given side or runtime should be isolated from the other classes in a separate subpackage. For example, code related to [data generation][datagen] should go in a `data` package, and code only on the dedicated server should go in a `server` package.
+
+It is highly recommended that [client-only code][sides] should be isolated in a `client` subpackage. This is because dedicated servers have no access to any of the client-only packages in Minecraft and will crash if your mod tries to access them anyway. As such, having a dedicated package provides a decent sanity check to verify you are not reaching across sides within your mod.
+
+## Class Naming Schemes
+
+A common class naming scheme makes it easier to decipher the purpose of the class or to easily locate specific classes.
+
+Classes are commonly suffixed with its type, for example:
+
+- An `Item` called `PowerRing` -> `PowerRingItem`.
+- A `Block` called `NotDirt` -> `NotDirtBlock`.
+- A menu for an `Oven` -> `OvenMenu`.
+
+:::tip
+Mojang typically follows a similar structure for all classes except entities. Those are represented by just their names (e.g. `Pig`, `Zombie`, etc.).
+:::
+
+## Choose One Method from Many
+
+There are many methods for performing a certain task: registering an object, listening for events, etc. It's generally recommended to be consistent by using a single method to accomplish a given task. This improves readability and avoids weird interactions or redundancies that may occur (e.g. your event listener running twice).
+
+[group]: index.md#the-group-id
+[naming]: https://docs.oracle.com/javase/tutorial/java/package/namingpkgs.html
+[datagen]: ../resources/index.md#data-generation
+[sides]: ../concepts/sides.md
diff --git a/versioned_docs/version-1.21.3/gettingstarted/versioning.md b/versioned_docs/version-1.21.3/gettingstarted/versioning.md
new file mode 100644
index 00000000..5fdcce37
--- /dev/null
+++ b/versioned_docs/version-1.21.3/gettingstarted/versioning.md
@@ -0,0 +1,96 @@
+# Versioning
+
+This article will break down how versioning works in Minecraft and NeoForge, and will give some recommendations for mod versioning as well.
+
+## Minecraft
+
+Minecraft uses [semantic versioning][semver]. Semantic versioning, or "semver" for short, has the format `major.minor.patch`. So for example, Minecraft 1.20.2 has the major version 1, the minor version 20 and the patch version 2.
+
+Minecraft has used `1` as the major version since 2011, when Minecraft 1.0 was introduced. Before that, the versioning scheme changed often, and there were versions like `a1.1` (Alpha 1.1), `b1.7.3` (Beta 1.7.3) or even the `infdev` versions, which didn't follow a clear versioning scheme at all. Due to the `1` major version holding up for over a decade now, and due to the in-joke that is Minecraft 2, it is generally considered unlikely that this is ever going to change.
+
+### Snapshots
+
+Snapshots deviate from the standard semver scheme. They are labeled as `YYwWWa`, where `YY` represents the last two digits of the year (e.g. `23`) and `WW` represents the week of that year (e.g. `01`). So for example, snapshot `23w01a` is the snapshot released in the first week of 2023.
+
+The `a` suffix exists for occasions where two snapshots get released in the same week (where the second snapshot would then be named something like `23w01b`). Mojang has occasionally used this in the past. The alternative suffix has also been used for snapshots like `20w14infinite`, which was the [2020 infinite dimensions April Fool's joke][infinite].
+
+### Pre-releases and Release Candidates
+
+When a snapshot cycle is coming completion, Mojang starts releasing so-called pre-releases. Pre-releases are deemed feature-complete for a version and focus solely on bugfixes. They use the semver notation for the version it is for, suffixed by `-preX`. So for example, the first pre-release for 1.20.2 was named `1.20.2-pre1`. There can be and usually are multiple pre-releases, which are accordingly suffixed with `-pre2`, `-pre3`, etc.
+
+Similarly, when the pre-release cycle completes, Mojang releases Release Candidate 1 (suffixing the version with `-rc1`, for example `1.20.2-rc1`). Mojang aims to have one release candidate that they can release if no further bugs occur. However, if an unexpected bug occurs, then there can also be an `-rc2`, `-rc3`, etc. version, similar to pre-releases.
+
+## NeoForge
+
+NeoForge uses an adapted semver system: The major version is Minecraft's minor version, the minor version is Minecraft's patch version, and the patch version is the "actual" NeoForge version. So for example, NeoForge 20.2.59 is the 60th version (we start at 0) for Minecraft 1.20.2. The `1` at the beginning is omitted because it is very unlikely that it will ever change, see [above][minecraft] for why that is the case.
+
+A few places in NeoForge also use [Maven version ranges][mvr], for example the Minecraft and NeoForge version ranges in the [`neoforge.mods.toml`][neoforgemodstoml] file. These are mostly, but not fully compatible with semver (the `pre`-tag is not considered by it, for example).
+
+## Mods
+
+There is no definitive best versioning system. Different styles of development, scopes of projects, etc. all influence the decision of what versioning system to use. Sometimes, versioning system can also be combined. This section attempts to give an overview over some commonly used versioning systems, with real-life examples.
+
+Usually, a mod's file name looks like `modid-<version>.jar`. So if our mod id is `examplemod` and our version is `1.2.3`, our mod file would be named `examplemod-1.2.3.jar`.
+
+:::note
+Versioning systems are suggestions, rather than strictly enforced rules. This is especially true with regard to when the version is changed ("bumped"), and in what way. If you want to use a different versioning system, nobody is going to stop you.
+:::
+
+### Semantic Versioning
+
+Semantic versioning ("semver") consists of three parts: `major.minor.patch`. The major version is bumped when major changes are made to the codebase, which usually correlates with major new features and bugfixes. The minor version is bumped when minor features are introduced, and patch bumps happen when an update only includes bug-fixes.
+
+It is generally agreed upon that any version `0.x.x` is a development version, and with the first (full) release, the version should be bumped to `1.0.0`.
+
+The "minor for features, patch for bugfixes" rule is often disregarded in practice. A popular example for this is Minecraft itself, which does major features through the minor version number, minor features through the patch number, and bugfixes in snapshots (see above).
+
+Depending on how often a mod is updated, these numbers can be smaller or larger. For example, [Supplementaries][supplementaries] is on version `2.6.31` (at the time of writing). Triple- or even quadruple-digit numbers, especially in the `patch`, are absolutely possible.
+
+### "Reduced" and "Expanded" Semver
+
+Sometimes, semver can be seen with only two numbers. This is a sort of "reduced" semver, or "2-part" semver. Their version numbers only have a `major.minor` scheme. This is commonly used by small mods that only add a few simple objects and thus rarely need updates (except Minecraft version updates), often staying at version `1.0` forever.
+
+"Expanded" semver, or "4-part" semver, has four numbers (so something like `1.0.0.0`). Depending on the mod, the format can be `major.api.minor.patch`, or `major.minor.patch.hotfix`, or something different entirely - there is no standard way to do it.
+
+For `major.api.minor.patch`, the `major` version is decoupled from the `api` version. This means that the `major` (feature) bit and the `api` bit can be bumped independently. This is commonly used by mods that expose an API for other modders to use. For example, [Mekanism][mekanism] is currently on version 10.4.5.19 (at the time of writing).
+
+For `major.minor.patch.hotfix`, the patch level is split into two. This is the approach used by the [Create][create] mod, which is currently on version 0.5.1f (at the time of writing). Note that Create denotes the hotfix as a letter instead of a fourth number, in order to stay compatible with regular semver.
+
+:::info
+Reduced semver, expanded semver, 2-part semver and 4-part semver are not official terms or standardized formats in any way.
+:::
+
+### Alpha, Beta, Release
+
+Like Minecraft itself, modding is often done in the classical `alpha`/`beta`/`release` stages known from software engineering, where `alpha` denotes an unstable/experimental version (sometimes also called `experimental` or `snapshot`), `beta` denotes a semi-stable version, and `release` denotes a stable version (sometimes called `stable` instead of `release`).
+
+Some mods use their major version to denote a Minecraft version bump. An example of this is [JEI][jei], which uses `13.x.x.x` for Minecraft 1.19.2, `14.x.x.x` for 1.19.4, and `15.x.x.x` for 1.20.1 (there are no versions for 1.19.3 and 1.20.0). Others append the tag to the mod name, for example the [Minecolonies][minecolonies] mod, which is on `1.1.328-BETA` at the time of writing.
+
+### Including the Minecraft Version
+
+It is common to include the Minecraft version a mod is for in the filename. This makes it easier for end users to easily find out what Minecraft version a mod is for. A common place for this is either before or after the mod version, with the former being more widespread than the latter. For example, JEI version `16.0.0.28` (latest at the time of writing) for 1.20.2 would become `jei-1.20.2-16.0.0.28` or `jei-16.0.0.28-1.20.2`.
+
+### Including the Mod Loader
+
+As you probably know, NeoForge is not the only mod loader out there, and many mod developers develop on multiple platforms. As a result, a way to distinguish between two files of the same mod of the same version, but for different mod loaders is needed.
+
+Usually, this is done by including the mod loader somewhere in the name. `jei-neoforge-1.20.2-16.0.0.28`, `jei-1.20.2-neoforge-16.0.0.28` or `jei-1.20.2-16.0.0.28-neoforge` are all valid ways to do it. For other mod loaders, the `neoforge` bit would be replaced with `forge`, `fabric`, `quilt` or whatever different mod loader you might be developing on alongside NeoForge.
+
+### A Note on Maven
+
+Maven, the system used for dependency hosting, uses a versioning system that differs from semver in some details (though the general `major.minor.patch` pattern remains the same). The related [Maven Versioning Range (MVR)][mvr] system is used in some places in NeoForge (see [above][neoforge]). When choosing your versioning scheme, you should make sure it is compatible with MVR, as otherwise, mods will not be able to depend on specific versions of your mod!
+
+[create]: https://www.curseforge.com/minecraft/mc-mods/create
+[infinite]: https://minecraft.wiki/w/Java_Edition_20w14∞
+[jei]: https://www.curseforge.com/minecraft/mc-mods/jei
+[mekanism]: https://www.curseforge.com/minecraft/mc-mods/mekanism
+[minecolonies]: https://www.curseforge.com/minecraft/mc-mods/minecolonies
+[minecraft]: #minecraft
+[neoforgemodstoml]: modfiles.md#neoforgemodstoml
+[mvr]: https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html
+[mvr]: https://maven.apache.org/ref/3.5.2/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html
+[neoforge]: #neoforge
+[pre]: #pre-releases
+[rc]: #release-candidates
+[semver]: https://semver.org/
+[supplementaries]: https://www.curseforge.com/minecraft/mc-mods/supplementaries
diff --git a/versioned_docs/version-1.21.3/gui/_category_.json b/versioned_docs/version-1.21.3/gui/_category_.json
new file mode 100644
index 00000000..66d6d72a
--- /dev/null
+++ b/versioned_docs/version-1.21.3/gui/_category_.json
@@ -0,0 +1,4 @@
+{
+    "label": "GUIs",
+    "position": 9
+}
\ No newline at end of file
diff --git a/versioned_docs/version-1.21.3/gui/menus.md b/versioned_docs/version-1.21.3/gui/menus.md
new file mode 100644
index 00000000..cc29a1b9
--- /dev/null
+++ b/versioned_docs/version-1.21.3/gui/menus.md
@@ -0,0 +1,354 @@
+# Menus
+
+Menus are one type of backend for Graphical User Interfaces, or GUIs; they handle the logic involved in interacting with some represented data holder. Menus themselves are not data holders. They are views which allow to user to indirectly modify the internal data holder state. As such, a data holder should not be directly coupled to any menu, instead passing in the data references to invoke and modify.
+
+## `MenuType`
+
+Menus are created and removed dynamically and as such are not registry objects. As such, another factory object is registered instead to easily create and refer to the *type* of the menu. For a menu, these are `MenuType`s.
+
+`MenuType`s must be [registered].
+
+### `MenuSupplier`
+
+A `MenuType` is created by passing in a `MenuSupplier` and a `FeatureFlagSet` to its constructor. A `MenuSupplier` represents a function which takes in the id of the container and the inventory of the player viewing the menu, and returns a newly created [`AbstractContainerMenu`][acm].
+
+```java
+// For some DeferredRegister<MenuType<?>> REGISTER
+public static final Supplier<MenuType<MyMenu>> MY_MENU = REGISTER.register("my_menu", () -> new MenuType<>(MyMenu::new, FeatureFlags.DEFAULT_FLAGS));
+
+// In MyMenu, an AbstractContainerMenu subclass
+public MyMenu(int containerId, Inventory playerInv) {
+    super(MY_MENU.get(), containerId);
+    // ...
+}
+```
+
+:::note
+The container identifier is unique for an individual player. This means that the same container id on two different players will represent two different menus, even if they are viewing the same data holder.
+:::
+
+The `MenuSupplier` is usually responsible for creating a menu on the client with dummy data references used to store and interact with the synced information from the server data holder.
+
+### `IContainerFactory`
+
+If additional information is needed on the client (e.g. the position of the data holder in the world), then the subclass `IContainerFactory` can be used instead. In addition to the container id and the player inventory, this also provides a `RegistryFriendlyByteBuf` which can store additional information that was sent from the server. A `MenuType` can be created using an `IContainerFactory` via `IMenuTypeExtension#create`.
+
+```java
+// For some DeferredRegister<MenuType<?>> REGISTER
+public static final Supplier<MenuType<MyMenuExtra>> MY_MENU_EXTRA = REGISTER.register("my_menu_extra", () -> IMenuTypeExtension.create(MyMenu::new));
+
+// In MyMenuExtra, an AbstractContainerMenu subclass
+public MyMenuExtra(int containerId, Inventory playerInv, FriendlyByteBuf extraData) {
+    super(MY_MENU_EXTRA.get(), containerId);
+    // Store extra data from buffer
+    // ...
+}
+```
+
+## `AbstractContainerMenu`
+
+All menus are extended from `AbstractContainerMenu`. A menu takes in two parameters, the [`MenuType`][mt], which represents the type of the menu itself, and the container id, which represents the unique identifier of the menu for the current accessor.
+
+:::note
+The menu identifier cycles through 0-99, incrementing whenever a player opens a menu.
+:::
+
+Each menu should contain two constructors: one used to initialize the menu on the server and one used to initialize the menu on the client. The constructor used to initialize the menu on the client is the one supplied to the `MenuType`. Any fields that the server menu constructor contains should have some default for the client menu constructor.
+
+```java
+// Client menu constructor
+public MyMenu(int containerId, Inventory playerInventory) { // optional FriendlyByteBuf parameter if reading data from server
+    this(containerId, playerInventory, /* Any default parameters here */);
+}
+
+// Server menu constructor
+public MyMenu(int containerId, Inventory playerInventory, /* Any additional parameters here. */) {
+    // ...
+}
+```
+
+:::note
+If no additional data needs to be displayed in the menu, then only one constructor is necessary.
+:::
+
+Each menu implementation must implement two methods: `#stillValid` and [`#quickMoveStack`][qms].
+
+### `#stillValid` and `ContainerLevelAccess`
+
+`#stillValid` determines whether the menu should remain open for a given player. This is typically directed to the static `#stillValid` which takes in a `ContainerLevelAccess`, the player, and the `Block` this menu is attached to. The client menu must always return `true` for this method, which the static `#stillValid` does default to. This implementation checks whether the player is within eight blocks of where the data storage object is located.
+
+A `ContainerLevelAccess` supplies the current level and block position within an enclosed scope. When constructing the menu on the server, a new access can be created by calling `ContainerLevelAccess#create`. The client menu constructor can pass in `ContainerLevelAccess#NULL`, which will do nothing.
+
+```java
+// Client menu constructor
+public MyMenuAccess(int containerId, Inventory playerInventory) {
+    this(containerId, playerInventory, ContainerLevelAccess.NULL);
+}
+
+// Server menu constructor
+public MyMenuAccess(int containerId, Inventory playerInventory, ContainerLevelAccess access) {
+    // ...
+}
+
+// Assume this menu is attached to Supplier<Block> MY_BLOCK
+@Override
+public boolean stillValid(Player player) {
+    return AbstractContainerMenu.stillValid(this.access, player, MY_BLOCK.get());
+}
+```
+
+### Data Synchronization
+
+Some data needs to be present on both the server and the client to display to the player. To do this, the menu implements a basic layer of data synchronization such that whenever the current data does not match the data last synced to the client. For players, this is checked every tick.
+
+Minecraft supports two forms of data synchronization by default: `ItemStack`s via `Slot`s and integers via `DataSlot`s. `Slot`s and `DataSlot`s are views which hold references to data storages that can be be modified by the player in a screen, assuming the action is valid. These can be added to a menu within the constructor through `#addSlot` and `#addDataSlot`.
+
+:::note
+Since `Container`s used by `Slot`s are deprecated by NeoForge in favor of using the [`IItemHandler` capability][cap], the rest of the explanation will revolve around using the capability variant: `SlotItemHandler`.
+:::
+
+A `SlotItemHandler` contains four parameters: the `IItemHandler` representing the inventory the stacks are within, the index of the stack this slot is specifically representing, and the x and y position of where the top-left position of the slot will render on the screen relative to `AbstractContainerScreen#leftPos` and `#topPos`. The client menu constructor should always supply an empty instance of an inventory of the same size.
+
+In most cases, any slots the menu contains is first added, followed by the player's inventory, and finally concluded with the player's hotbar. To access any individual `Slot` from the menu, the index must be calculated based upon the order of which slots were added.
+
+A `DataSlot` is an abstract class which should implement a getter and setter to reference the data stored in the data storage object. The client menu constructor should always supply a new instance via `DataSlot#standalone`.
+
+These, along with slots, should be recreated every time a new menu is initialized.
+
+:::note
+Although a `DataSlot` stores an integer, it is effectively limited to a **short** (-32768 to 32767) because of how it sends the value across the network. The 16 high-order bits of the integer are ignored.
+
+NeoForge patches the packet to provide the full integer to the client.
+:::
+
+```java
+// Assume we have an inventory from a data object of size 5
+// Assume we have a DataSlot constructed on each initialization of the server menu
+
+// Client menu constructor
+public MyMenuAccess(int containerId, Inventory playerInventory) {
+    this(containerId, playerInventory, new ItemStackHandler(5), DataSlot.standalone());
+}
+
+// Server menu constructor
+public MyMenuAccess(int containerId, Inventory playerInventory, IItemHandler dataInventory, DataSlot dataSingle) {
+    // Check if the data inventory size is some fixed value
+    // Then, add slots for data inventory
+    this.addSlot(new SlotItemHandler(dataInventory, /*...*/));
+
+    // Add slots for player inventory
+    this.addSlot(new Slot(playerInventory, /*...*/));
+
+    // Add data slots for handled integers
+    this.addDataSlot(dataSingle);
+
+    // ...
+}
+```
+
+#### `ContainerData`
+
+If multiple integers need to be synced to the client, a `ContainerData` can be used to reference the integers instead. This interface functions as an index lookup such that each index represents a different integer. `ContainerData`s can also be constructed in the data object itself if the `ContainerData` is added to the menu through `#addDataSlots`. The method creates a new `DataSlot` for the amount of data specified by the interface. The client menu constructor should always supply a new instance via `SimpleContainerData`.
+
+```java
+// Assume we have a ContainerData of size 3
+
+// Client menu constructor
+public MyMenuAccess(int containerId, Inventory playerInventory) {
+    this(containerId, playerInventory, new SimpleContainerData(3));
+}
+
+// Server menu constructor
+public MyMenuAccess(int containerId, Inventory playerInventory, ContainerData dataMultiple) {
+    // Check if the ContainerData size is some fixed value
+    checkContainerDataCount(dataMultiple, 3);
+
+    // Add data slots for handled integers
+    this.addDataSlots(dataMultiple);
+
+    // ...
+}
+```
+
+#### `#quickMoveStack`
+
+`#quickMoveStack` is the second method that must be implemented by any menu. This method is called whenever a stack has been shift-clicked, or quick moved, out of its current slot until the stack has been fully moved out of its previous slot or there is no other place for the stack to go. The method returns a copy of the stack in the slot being quick moved.
+
+Stacks are typically moved between slots using `#moveItemStackTo`, which moves the stack into the first available slot. It takes in the stack to be moved, the first slot index (inclusive) to try and move the stack to, the last slot index (exclusive), and whether to check the slots from first to last (when `false`) or from last to first (when `true`).
+
+Across Minecraft implementations, this method is fairly consistent in its logic:
+
+```java
+// Assume we have a data inventory of size 5
+// The inventory has 4 inputs (index 1 - 4) which outputs to a result slot (index 0)
+// We also have the 27 player inventory slots and the 9 hotbar slots
+// As such, the actual slots are indexed like so:
+//   - Data Inventory: Result (0), Inputs (1 - 4)
+//   - Player Inventory (5 - 31)
+//   - Player Hotbar (32 - 40)
+@Override
+public ItemStack quickMoveStack(Player player, int quickMovedSlotIndex) {
+    // The quick moved slot stack
+    ItemStack quickMovedStack = ItemStack.EMPTY;
+    // The quick moved slot
+    Slot quickMovedSlot = this.slots.get(quickMovedSlotIndex) 
+  
+    // If the slot is in the valid range and the slot is not empty
+    if (quickMovedSlot != null && quickMovedSlot.hasItem()) {
+        // Get the raw stack to move
+        ItemStack rawStack = quickMovedSlot.getItem(); 
+        // Set the slot stack to a copy of the raw stack
+        quickMovedStack = rawStack.copy();
+
+        /*
+        The following quick move logic can be simplified to if in data inventory,
+        try to move to player inventory/hotbar and vice versa for containers
+        that cannot transform data (e.g. chests).
+        */
+
+        // If the quick move was performed on the data inventory result slot
+        if (quickMovedSlotIndex == 0) {
+            // Try to move the result slot into the player inventory/hotbar
+            if (!this.moveItemStackTo(rawStack, 5, 41, true)) {
+                // If cannot move, no longer quick move
+                return ItemStack.EMPTY;
+            }
+
+            // Perform logic on result slot quick move
+            slot.onQuickCraft(rawStack, quickMovedStack);
+        }
+        // Else if the quick move was performed on the player inventory or hotbar slot
+        else if (quickMovedSlotIndex >= 5 && quickMovedSlotIndex < 41) {
+            // Try to move the inventory/hotbar slot into the data inventory input slots
+            if (!this.moveItemStackTo(rawStack, 1, 5, false)) {
+                // If cannot move and in player inventory slot, try to move to hotbar
+                if (quickMovedSlotIndex < 32) {
+                    if (!this.moveItemStackTo(rawStack, 32, 41, false)) {
+                        // If cannot move, no longer quick move
+                        return ItemStack.EMPTY;
+                    }
+                }
+                // Else try to move hotbar into player inventory slot
+                else if (!this.moveItemStackTo(rawStack, 5, 32, false)) {
+                    // If cannot move, no longer quick move
+                    return ItemStack.EMPTY;
+                }
+            }
+        }
+        // Else if the quick move was performed on the data inventory input slots, try to move to player inventory/hotbar
+        else if (!this.moveItemStackTo(rawStack, 5, 41, false)) {
+            // If cannot move, no longer quick move
+            return ItemStack.EMPTY;
+        }
+
+        if (rawStack.isEmpty()) {
+            // If the raw stack has completely moved out of the slot, set the slot to the empty stack
+            quickMovedSlot.set(ItemStack.EMPTY);
+        } else {
+            // Otherwise, notify the slot that that the stack count has changed
+            quickMovedSlot.setChanged();
+        }
+
+        /*
+        The following if statement and Slot#onTake call can be removed if the
+        menu does not represent a container that can transform stacks (e.g.
+        chests).
+        */
+        if (rawStack.getCount() == quickMovedStack.getCount()) {
+            // If the raw stack was not able to be moved to another slot, no longer quick move
+            return ItemStack.EMPTY;
+        }
+        // Execute logic on what to do post move with the remaining stack
+        quickMovedSlot.onTake(player, rawStack);
+    }
+
+    return quickMovedStack; // Return the slot stack
+}
+```
+
+## Opening a Menu
+
+Once a menu type has been registered, the menu itself has been finished, and a [screen] has been attached, a menu can then be opened by the player. Menus can be opened by calling `IPlayerExtension#openMenu` on the logical server. The method takes in the `MenuProvider` of the server side menu and optionally a `Consumer<RegistryFriendlyByteBuf>` if extra data needs to be synced to the client.
+
+:::note
+`IPlayerExtension#openMenu` with the `Consumer<RegistryFriendlyByteBuf>` parameter should only be used if a menu type was created using an [`IContainerFactory`][icf].
+:::
+
+#### `MenuProvider`
+
+A `MenuProvider` is an interface that contains two methods: `#createMenu`, which creates the server instance of the menu, and `#getDisplayName`, which returns a component containing the title of the menu to pass to the [screen]. The `#createMenu` method contains three parameter: the container id of the menu, the inventory of the player who opened the menu, and the player who opened the menu.
+
+A `MenuProvider` can easily be created using `SimpleMenuProvider`, which takes in a method reference to create the server menu and the title of the menu.
+
+```java
+// In some implementation with access to the Player on the logical server (e.g. ServerPlayer instance)
+// Assume we have ServerPlayer serverPlayer
+serverPlayer.openMenu(new SimpleMenuProvider(
+    (containerId, playerInventory, player) -> new MyMenu(containerId, playerInventory),
+    Component.translatable("menu.title.examplemod.mymenu")
+));
+```
+
+### Common Implementations
+
+Menus are typically opened on a player interaction of some kind (e.g. when a block or entity is right-clicked).
+
+#### Block Implementation
+
+Blocks typically implement a menu by overriding `BlockBehaviour#useWithoutItem`, returning `InteractionResult#SUCCESS` for the [interaction].
+
+The `MenuProvider` should be implemented by overriding `BlockBehaviour#getMenuProvider`. Vanilla methods use this to view the menu in spectator mode.
+
+```java
+// In some Block subclass
+@Override
+public MenuProvider getMenuProvider(BlockState state, Level level, BlockPos pos) {
+    return new SimpleMenuProvider(/* ... */);
+}
+
+@Override
+public InteractionResult useWithoutItem(BlockState state, Level level, BlockPos pos, Player player, InteractionHand hand, BlockHitResult result) {
+    if (!level.isClientSide && player instanceof ServerPlayer serverPlayer) {
+        serverPlayer.openMenu(state.getMenuProvider(level, pos));
+    }
+
+    return InteractionResult.SUCCESS;
+}
+```
+
+:::note
+This is the simplest way to implement the logic, not the only way. If you want the block to only open the menu under certain conditions, then some data will need to be synced to the client beforehand to return `InteractionResult#PASS` or `#FAIL` if the conditions are not met.
+:::
+
+#### Mob Implementation
+
+Mobs typically implement a menu by overriding `Mob#mobInteract`. This is done similarly to the block implementation with the only difference being that the `Mob` itself should implement `MenuProvider` to support spectator mode viewing.
+
+```java
+public class MyMob extends Mob implements MenuProvider {
+    // ...
+
+    @Override
+    public InteractionResult mobInteract(Player player, InteractionHand hand) {
+        if (!this.level.isClientSide && player instanceof ServerPlayer serverPlayer) {
+            serverPlayer.openMenu(this);
+        }
+
+        return InteractionResult.SUCCESS;
+    }
+}
+```
+
+:::note
+Once again, this is the simplest way to implement the logic, not the only way.
+:::
+
+[registered]: ../concepts/registries.md#methods-for-registering
+[acm]: #abstractcontainermenu
+[mt]: #menutype
+[qms]: #quickmovestack
+[cap]: ../datastorage/capabilities.md#neoforge-provided-capabilities
+[screen]: screens.md
+[icf]: #icontainerfactory
+[side]: ../concepts/sides.md#the-logical-side
+[interaction]: ../items/interactionpipeline.md
diff --git a/versioned_docs/version-1.21.3/gui/screens.md b/versioned_docs/version-1.21.3/gui/screens.md
new file mode 100644
index 00000000..d35e5547
--- /dev/null
+++ b/versioned_docs/version-1.21.3/gui/screens.md
@@ -0,0 +1,426 @@
+# Screens
+
+Screens are typically the base of all Graphical User Interfaces (GUIs) in Minecraft: taking in user input, verifying it on the server, and syncing the resulting action back to the client. They can be combined with [menus] to create an communication network for inventory-like views, or they can be standalone which modders can handle through their own [network] implementations.
+
+Screens are made up of numerous parts, making it difficult to fully understand what a 'screen' actually is in Minecraft. As such, this document will go over each of the screen's components and how it is applied before discussing the screen itself.
+
+## Relative Coordinates
+
+Whenever anything is rendered, there needs to be some identifier which specifies where it will appear. With numerous abstractions, most of Minecraft's rendering calls take x, y, and z values in a coordinate plane. X values increase from left to right, y from top to bottom, and z from far to near. However, the coordinates are not fixed to a specified range. Their range can change depending on the size of the screen and the “GUI scale” specified within the game’s options. As such, extra care must be taken to ensure the coordinates values passed to rendering calls scale properly—are relativized correctly—to the changeable screen size.
+
+Information on how to relativize your coordinates is in the [screen] section.
+
+:::caution
+If you choose to use fixed coordinates or incorrectly scale the screen, the rendered objects may look strange or misplaced. An easy way to check if you relativized your coordinates correctly is to click the 'Gui Scale' button in your video settings. This value is used as the divisor to the width and height of your display when determining the scale at which a GUI should render.
+:::
+
+## Gui Graphics
+
+Any GUI rendered by Minecraft is typically done using `GuiGraphics`. `GuiGraphics` is the first parameter to almost all rendering methods; it contains basic methods to render commonly used objects. These fall into five categories: colored rectangles, strings, textures, items, and tooltips. There is also an additional method for rendering a snippet of a component (`#enableScissor` / `#disableScissor`). `GuiGraphics` also exposes the `PoseStack` which applies the transformations necessary to properly render where the component should be rendered. Additionally, colors are in the [ARGB][argb] format.
+
+### Colored Rectangles
+
+Colored rectangles are drawn through a position color shader. All fill methods can take in an optional `RenderType` to specify how the rectangle should be rendered. There are three types of colored rectangles that can be drawn.
+
+First, there is a colored horizontal and vertical one-pixel wide line, `#hLine` and `#vLine` respectively. `#hLine` takes in two x coordinates defining the left and right (inclusively), the top y coordinate, and the color. `#vLine` takes in the left x coordinate, two y coordinates defining the top and bottom (inclusively), and the color.
+
+Second, there is the `#fill` method, which draws a rectangle to the screen. The line methods internally call this method. This takes in the left x coordinate, the top y coordinate, the right x coordinate, the bottom y coordinate, and the color. `#fillRenderType` also does the same; however, it draws the vertices without correcting the coordinate locations.
+
+Finally, there is the `#fillGradient` method, which draws a rectangle with a vertical gradient. This takes in the right x coordinate, the bottom y coordinate, the left x coordinate, the top y coordinate, the z coordinate, and the bottom and top colors.
+
+### Strings
+
+Strings are drawn through its `Font`, typically consisting of their own shaders for normal, see through, and offset mode. There are two alignment of strings that can be rendered, each with a back shadow: a left-aligned string (`#drawString`) and a center-aligned string (`#drawCenteredString`). These both take in the font the string will be rendered in, the string to draw, the x coordinate representing the left or center of the string respectively, the top y coordinate, and the color.
+
+If the text should be wrapped within a given bounds, then `#drawWordWrap` can be used instead. This renders a left-aligned string by default.
+
+:::note
+Strings should typically be passed in as [`Component`s][component] as they handle a variety of usecases, including the two other overloads of the method.
+:::
+
+### Textures
+
+Textures are drawn through blitting, hence the method name `#blit`, which, for this purpose, copies the bits of an image and draws them directly to the screen. These are drawn through a position texture shader.
+
+Each `#blit` method takes in a `Function<ResourceLocation, RenderType>`, which determines how to render the texture, and `ResourceLocation`, which represents the absolute location of the texture:
+
+```java
+// Points to 'assets/examplemod/textures/gui/container/example_container.png'
+private static final ResourceLocation TEXTURE = ResourceLocation.fromNamespaceAndPath("examplemod", "textures/gui/container/example_container.png");
+```
+
+While there are many different `#blit` overloads, we will only discuss two of them.
+
+The first `#blit` takes in two integers, than two floats, and finally four more integers, assuming the image is on a PNG file. It takes in the left x and top y screen coordinate, the left x and top y coordinate within the PNG, the width and height of the image to render, and the width and height of the PNG file.
+
+:::tip
+The size of the PNG file must be specified so that the coordinates can be normalized to obtain the associated UV values.
+:::
+
+The second `#blit` adds an additional integer at the end which represents the tint color of the image to be drawn. This color will be treated as an ARGB value, and is `0xFFFFFFFF` if not specified.
+
+#### `blitSprite`
+
+`#blitSprite` is a special implementation of `#blit` where the texture is written to the GUI texture atlas. Most textures that overlay the background, such as the 'burn progress' overlay in furnace GUIs, are sprites. All sprite textures are relative to `textures/gui/sprites` and do not need to specify the file extension.
+
+```java
+// Points to 'assets/examplemod/textures/gui/sprites/container/example_container/example_sprite.png'
+private static final ResourceLocation SPRITE = ResourceLocation.fromNamespaceAndPath("examplemod", "container/example_container/example_sprite");
+```
+
+One set of `#blitSprite` methods have the same parameters as `#blit`, except for the the four integers dealing with the coordinates, width, and height of the PNG.
+
+The other `#blitSprite` methods take in more texture information to allow for rendering part of the sprite. These methods take in the texture width and height, the x and y coordinate in the sprite, the left x and top y screen coordinate, the tint color (in ARGB format), and the width and height of the image to render.
+
+If the sprite size does not match the texture size, then the sprite can be scaled in one of three ways: `stretch`, `tile`, and `nine_slice`. `stretch` stretches the image from the texture size to the screen size. `tile` renders the texture over and over again until it reaches the screen size. `nine_slice` divides the texture into one center, four edges, and four corners to tile the texture to the required screen size.
+
+This is set by adding the `gui.scaling` JSON object in an mcmeta file with the same name of the texture file.
+
+```json5
+// For some texture file example_sprite.png
+// In example_sprite.png.mcmeta
+
+// Stretch example
+{
+    "gui": {
+        "scaling": {
+            "type": "stretch"
+        }
+    }
+}
+
+// Tile example
+{
+    "gui": {
+        "scaling": {
+            "type": "tile",
+            // The size to begin tiling at
+            // This is usually the size of the texture
+            "width": 40,
+            "height": 40
+        }
+    }
+}
+
+// Nine slice example
+{
+    "gui": {
+        "scaling": {
+            "type": "nine_slice",
+            // The size to begin tiling at
+            // This is usually the size of the texture
+            "width": 40,
+            "height": 40,
+            "border": {
+                // The padding of the texture that will be sliced into the border texture
+                "left": 1,
+                "right": 1,
+                "top": 1,
+                "bottom": 1
+            },
+            // When true the center part of the texture will be applied like
+            // the stretch type instead of a nine slice tiling.
+            "stretch_inner": true
+        }
+    }
+}
+```
+
+#### Blit Offset
+
+The z coordinate when rendering a texture is typically set to the blit offset. The offset is responsible for properly layering renders when viewing a screen. Renders with a smaller z coordinate are rendered in the background and vice versa where renders with a larger z coordinate are rendered in the foreground. The z offset can be set directly on the `PoseStack` itself via `#translate`. Some basic offset logic is applied internally in some methods of `GuiGraphics` (e.g. item rendering).
+
+:::caution
+When setting the blit offset, you must reset it after rendering your object. Otherwise, other objects within the screen may be rendered in an incorrect layer causing graphical issues. It is recommended to push the current pose before translating and then popping after all rendering at the offset is completed.
+:::
+
+## Renderable
+
+`Renderable`s are essentially objects that are rendered. These include screens, buttons, chat boxes, lists, etc. `Renderable`s only have one method: `#render`. This takes in the `GuiGraphics` used to render things to the screen, the x and y positions of the mouse scaled to the relative screen size, and the tick delta (how many ticks have passed since the last frame).
+
+Some common renderables are screens and 'widgets': interactable elements which typically render on the screen such as `Button`, its subtype `ImageButton`, and `EditBox` which is used to input text on the screen.
+
+## GuiEventListener
+
+Any screen rendered in Minecraft implements `GuiEventListener`. `GuiEventListener`s are responsible for handling user interaction with the screen. These include inputs from the mouse (movement, clicked, released, dragged, scrolled, mouseover) and keyboard (pressed, released, typed). Each method returns whether the associated action affected the screen successfully. Widgets like buttons, chat boxes, lists, etc. also implement this interface.
+
+### ContainerEventHandler
+
+Almost synonymous with `GuiEventListener`s are their subtype: `ContainerEventHandler`s. These are responsible for handling user interaction on screens which contain widgets, managing which is currently focused and how the associated interactions are applied. `ContainerEventHandler`s add three additional features: interactable children, dragging, and focusing.
+
+Event handlers hold children which are used to determine the interaction order of elements. During the mouse event handlers (excluding dragging), the first child in the list that the mouse hovers over has their logic executed.
+
+Dragging an element with the mouse, implemented via `#mouseClicked` and `#mouseReleased`, provides more precisely executed logic.
+
+Focusing allows for a specific child to be checked first and handled during an event's execution, such as during keyboard events or dragging the mouse. Focus is typically set through `#setFocused`. In addition, interactable children can be cycled using `#nextFocusPath`, selecting the child based upon the `FocusNavigationEvent` passed in.
+
+:::note
+Screens implement `ContainerEventHandler` through `AbstractContainerEventHandler`, which adds in the setter and getter logic for dragging and focusing children.
+:::
+
+## NarratableEntry
+
+`NarratableEntry`s are elements which can be spoken about through Minecraft's accessibility narration feature. Each element can provide different narration depending on what is hovered or selected, prioritized typically by focus, hovering, and then all other cases.
+
+`NarratableEntry`s have four methods: two which determine the priority of the element when being read (`#narrationPriority` and `#getTabOrderGroup`), one which determines whether to speak the narration (`#isActive`), and finally one which supplies the narration to its associated output, spoken or read (`#updateNarration`). 
+
+:::note
+All widgets from Minecraft are `NarratableEntry`s, so it typically does not need to be manually implemented if using an available subtype.
+:::
+
+## The Screen Subtype
+
+With all of the above knowledge, a basic screen can be constructed. To make it easier to understand, the components of a screen will be mentioned in the order they are typically encountered.
+
+First, all screens take in a `Component` which represents the title of the screen. This component is typically drawn to the screen by one of its subtypes. It is only used in the base screen for the narration message.
+
+```java
+// In some Screen subclass
+public MyScreen(Component title) {
+    super(title);
+}
+```
+
+### Initialization
+
+Once a screen has been initialized, the `#init` method is called. The `#init` method sets the initial settings inside the screen from the `Minecraft` instance to the relative width and height as scaled by the game. Any setup such as adding widgets or precomputing relative coordinates should be done in this method. If the game window is resized, the screen will be reinitialized by calling the `#init` method.
+
+There are three ways to add a widget to a screen, each serving a separate purpose:
+
+Method                 | Description
+:---:                  | :---
+`#addWidget`           | Adds a widget that is interactable and narrated, but not rendered.
+`#addRenderableOnly`   | Adds a widget that will only be rendered; it is not interactable or narrated.
+`#addRenderableWidget` | Adds a widget that is interactable, narrated, and rendered.
+
+Typically, `#addRenderableWidget` will be used most often.
+
+```java
+// In some Screen subclass
+@Override
+protected void init() {
+    super.init();
+
+    // Add widgets and precomputed values
+    this.addRenderableWidget(new EditBox(/* ... */));
+}
+```
+
+### Ticking Screens
+
+Screens also tick using the `#tick` method to perform some level of client side logic for rendering purposes.
+
+```java
+// In some Screen subclass
+@Override
+public void tick() {
+    super.tick();
+
+    // Execute some logic every frame
+}
+```
+
+### Input Handling
+
+Since screens are subtypes of `GuiEventListener`s, the input handlers can also be overridden, such as for handling logic on a specific [key press][keymapping].
+
+### Rendering the Screen
+
+Finally, screens are rendered through the `#render` method provided by being a `Renderable` subtype. As mentioned, the `#render` method draws the everything the screen has to render every frame, such as the background, widgets, tooltips, etc. By default, the `#render` method only renders the widgets to the screen.
+
+The two most common things rendered within a screen that is typically not handled by a subtype is the background and the tooltips.
+
+The background can be rendered using `#renderBackground`, with one method taking in a v Offset for the options background whenever a screen is rendered when the level behind it cannot be.
+
+Tooltips are rendered through `GuiGraphics#renderTooltip` or `GuiGraphics#renderComponentTooltip` which can take in the text components being rendered, an optional custom tooltip component, and the x / y relative coordinates on where the tooltip should be rendered on the screen.
+
+```java
+// In some Screen subclass
+
+// mouseX and mouseY indicate the scaled coordinates of where the cursor is in on the screen
+@Override
+public void render(GuiGraphics graphics, int mouseX, int mouseY, float partialTick) {
+    // Background is typically rendered first
+    this.renderBackground(graphics, mouseX, mouseY, partialTick);
+
+    // Render things here before widgets (background textures)
+
+    // Then the widgets if this is a direct child of the Screen
+    super.render(graphics, mouseX, mouseY, partialTick);
+
+    // Render things after widgets (tooltips)
+}
+```
+
+### Closing the Screen
+
+When a screen is closed, two methods handle the teardown: `#onClose` and `#removed`.
+
+`#onClose` is called whenever the user makes an input to close the current screen. This method is typically used as a callback to destroy and save any internal processes in the screen itself. This includes sending packets to the server.
+
+`#removed` is called just before the screen changes and is released to the garbage collector. This handles anything that hasn't been reset back to its initial state before the screen was opened.
+
+```java
+// In some Screen subclass
+
+@Override
+public void onClose() {
+    // Stop any handlers here
+
+    // Call last in case it interferes with the override
+    super.onClose();
+}
+
+@Override
+public void removed() {
+    // Reset initial states here
+
+    // Call last in case it interferes with the override
+    super.removed()
+;}
+```
+
+## `AbstractContainerScreen`
+
+If a screen is directly attached to a [menu][menus], then an `AbstractContainerScreen` should be subclassed instead. An `AbstractContainerScreen` acts as the renderer and input handler of a menu and contains logic for syncing and interacting with slots. As such, only two methods typically need to be overridden or implemented to have a working container screen. Once again, to make it easier to understand, the components of a container screen will be mentioned in the order they are typically encountered.
+
+An `AbstractContainerScreen` typically requires three parameters: the container menu being opened (represented by the generic `T`), the player inventory (only for the display name), and the title of the screen itself. Within here, a number of positioning fields can be set:
+
+Field             | Description
+:---:             | :---
+`imageWidth`      | The width of the texture used for the background. This is typically inside a PNG of 256 x 256 and defaults to 176.
+`imageHeight`     | The width of the texture used for the background. This is typically inside a PNG of 256 x 256 and defaults to 166.
+`titleLabelX`     | The relative x coordinate of where the screen title will be rendered.
+`titleLabelY`     | The relative y coordinate of where the screen title will be rendered.
+`inventoryLabelX` | The relative x coordinate of where the player inventory name will be rendered.
+`inventoryLabelY` | The relative y coordinate of where the player inventory name will be rendered.
+
+:::caution
+In a previous section, it mentioned that precomputed relative coordinates should be set in the `#init` method. This still remains true, as the values mentioned here are not precomputed coordinates but static values and relativized coordinates.
+
+The image values are static and non changing as they represent the background texture size. To make things easier when rendering, two additional values (`leftPos` and `topPos`) are precomputed in the `#init` method which marks the top left corner of where the background will be rendered. The label coordinates are relative to these values.
+
+The `leftPos` and `topPos` is also used as a convenient way to render the background as they already represent the position to pass into the `#blit` method.
+:::
+
+```java
+// In some AbstractContainerScreen subclass
+public MyContainerScreen(MyMenu menu, Inventory playerInventory, Component title) {
+    super(menu, playerInventory, title);
+
+    this.titleLabelX = 10;
+    this.inventoryLabelX = 10;
+
+    /*
+     * If the 'imageHeight' is changed, 'inventoryLabelY' must also be
+     * changed as the value depends on the 'imageHeight' value.
+     */
+}
+```
+
+### Menu Access
+
+As the menu is passed into the screen, any values that were within the menu and synced (either through slots, data slots, or a custom system) can now be accessed through the `menu` field.
+
+### Container Tick
+
+Container screens tick within the `#tick` method when the player is alive and looking at the screen via `#containerTick`. This essentially takes the place of `#tick` within container screens, with its most common usage being to tick the recipe book.
+
+```java
+// In some AbstractContainerScreen subclass
+@Override
+protected void containerTick() {
+    super.containerTick();
+
+    // Tick things here
+}
+```
+
+### Rendering the Container Screen
+
+The container screen is rendered across three methods: `#renderBg`, which renders the background textures, `#renderLabels`, which renders any text on top of the background, and `#render` which encompass the previous two methods in addition to providing a grayed out background and tooltips.
+
+Starting with `#render`, the most common override (and typically the only case) adds the background, calls the super to render the container screen, and finally renders the tooltips on top of it.
+
+```java
+// In some AbstractContainerScreen subclass
+@Override
+public void render(GuiGraphics graphics, int mouseX, int mouseY, float partialTick) {
+    this.renderBackground(graphics);
+    super.render(graphics, mouseX, mouseY, partialTick);
+
+    /*
+     * This method is added by the container screen to render
+     * the tooltip of the hovered slot.
+     */
+    this.renderTooltip(graphics, mouseX, mouseY);
+}
+```
+
+Within the super, `#renderBg` is called to render the background of the screen. The most standard representation uses three method calls: two for setup and one to draw the background texture.
+
+```java
+// In some AbstractContainerScreen subclass
+
+// The location of the background texture (assets/<namespace>/<path>)
+private static final ResourceLocation BACKGROUND_LOCATION = ResourceLocation.fromNamespaceAndPath(MOD_ID, "textures/gui/container/my_container_screen.png");
+
+@Override
+protected void renderBg(GuiGraphics graphics, float partialTick, int mouseX, int mouseY) {
+    /*
+     * Renders the background texture to the screen. 'leftPos' and
+     * 'topPos' should already represent the top left corner of where
+     * the texture should be rendered as it was precomputed from the
+     * 'imageWidth' and 'imageHeight'. The two zeros represent the
+     * integer u/v coordinates inside the PNG file, whose size is
+     * represented by the last two integers (typically 256 x 256).
+     */
+    graphics.blit(
+        RenderType::guiTextured,
+        BACKGROUND_LOCATION,
+        this.leftPos, this.topPos,
+        0, 0,
+        this.imageWidth, this.imageHeight,
+        256, 256
+    );
+}
+```
+
+Finally, `#renderLabels` is called to render any text above the background, but below the tooltips. This simply calls uses the font to draw the associated components.
+
+```java
+// In some AbstractContainerScreen subclass
+@Override
+protected void renderLabels(GuiGraphics graphics, int mouseX, int mouseY) {
+    super.renderLabels(graphics, mouseX, mouseY);
+
+    // Assume we have some Component 'label'
+    // 'label' is drawn at 'labelX' and 'labelY'
+    // The color is an ARGB value, if the alpha is less than 4, than the alpha is set to 255
+    // The final boolean renders the drop shadow when true
+    graphics.drawString(this.font, this.label, this.labelX, this.labelY, 0x404040, false);
+}
+```
+
+:::note
+When rendering the label, you do **not** need to specify the `leftPos` and `topPos` offset. Those have already been translated within the `PoseStack` so everything within this method is drawn relative to those coordinates.
+:::
+
+## Registering an AbstractContainerScreen
+
+To use an `AbstractContainerScreen` with a menu, it needs to be registered. This can be done by calling `register` within the `RegisterMenuScreensEvent` on the [**mod event bus**][modbus].
+
+```java
+// Event is listened to on the mod event bus
+private void registerScreens(RegisterMenuScreensEvent event) {
+    event.register(MY_MENU.get(), MyContainerScreen::new);
+}
+```
+
+[menus]: menus.md
+[network]: ../networking/index.md
+[screen]: #the-screen-subtype
+[argb]: https://en.wikipedia.org/wiki/RGBA_color_model#ARGB32
+[component]: ../resources/client/i18n.md#components
+[keymapping]: ../misc/keymappings.md#inside-a-gui
+[modbus]: ../concepts/events.md#event-buses
diff --git a/versioned_docs/version-1.21.3/items/_category_.json b/versioned_docs/version-1.21.3/items/_category_.json
new file mode 100644
index 00000000..ce451776
--- /dev/null
+++ b/versioned_docs/version-1.21.3/items/_category_.json
@@ -0,0 +1,4 @@
+{
+    "label": "Items",
+    "position": 4
+}
\ No newline at end of file
diff --git a/versioned_docs/version-1.21.3/items/armor.md b/versioned_docs/version-1.21.3/items/armor.md
new file mode 100644
index 00000000..86204da7
--- /dev/null
+++ b/versioned_docs/version-1.21.3/items/armor.md
@@ -0,0 +1,423 @@
+---
+sidebar_position: 5
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# Armor
+
+Armors are [items][item] whose primary use is to protect an entity from damage using a variety of resistances and effects. Many mods add new armor sets (for example copper armor).
+
+## Custom Armor Sets
+
+An armor set for a humanoid entity typically consists of four items: a helmet for the head, a chestplate for the chest, leggings for the legs, and boots for the feet. There is also armor for wolves, horses, and llamas that are applied to a 'body' armor slot specifically for animals. All of these items are generally implemented through `ArmorItem` and `AnimalArmorItem`, respectively.
+
+Armors are almost completely implemented through seven [data components][datacomponents]: 
+
+- `DataComponents#MAX_DAMAGE` and `#DAMAGE` for durability
+- `#MAX_STACK_SIZE` to set the stack size to `1`
+- `#REPAIRABLE` for repairing an armor piece in an anvil
+- `#ENCHANTABLE` for the maximum [enchanting][enchantment] value
+- `#ATTRIBUTE_MODIFIERS` for armor, armor toughness, and knockback resistance
+- `#EQUIPPABLE` for how the entity can equip the item.
+
+`ArmorItem` and `AnimalArmorItem` use `ArmorMaterial` combined with `ArmorType` or `AnimalArmorItem.BodyType` respectively to set up the components. Reference values can be found within `ArmorMaterials`. This example uses a copper armor material, which you can adjust the values as needed.
+
+```java
+public static final ArmorMaterial COPPER_ARMOR_MATERIAL = new ArmorMaterial(
+    // The durability multiplier of the armor material.
+    // ArmorType have different unit durabilities that the multiplier is applied to:
+    // - HELMET: 11
+    // - CHESTPLATE: 16
+    // - LEGGINGS: 15
+    // - BOOTS: 13
+    // - BODY: 16
+    15,
+    // Determines the defense value (or the number of half-armors on the bar).
+    // Based on ArmorType.
+    Util.make(new EnumMap<>(ArmorType.class), map -> {
+        map.put(ArmorItem.Type.BOOTS, 2);
+        map.put(ArmorItem.Type.LEGGINGS, 4);
+        map.put(ArmorItem.Type.CHESTPLATE, 6);
+        map.put(ArmorItem.Type.HELMET, 2);
+        map.put(ArmorItem.Type.BODY, 4);
+    }),
+    // Determines the enchantability of the armor. This represents how good the enchantments on this armor will be.
+    // Gold uses 25; we put copper slightly below that.
+    20,
+    // Determines the sound played when equipping this armor.
+    // This is wrapped with a Holder.
+    SoundEvents.ARMOR_EQUIP_GENERIC,
+     // Returns the toughness value of the armor. The toughness value is an additional value included in
+    // damage calculation, for more information, refer to the Minecraft Wiki's article on armor mechanics:
+    // https://minecraft.wiki/w/Armor#Armor_toughness
+    // Only diamond and netherite have values greater than 0 here, so we just return 0.
+    0,
+    // Returns the knockback resistance value of the armor. While wearing this armor, the player is
+    // immune to knockback to some degree. If the player has a total knockback resistance value of 1 or greater
+    // from all armor pieces combined, they will not take any knockback at all.
+    // Only netherite has values greater than 0 here, so we just return 0.
+    0,
+    // The tag that determines what items can repair this armor.
+    Tags.Items.INGOTS_COPPER,
+    // The relative location of the EquipmentModel JSON discussed below
+    // Points to assets/examplemod/models/equipment/copper.json
+    ResourceLocation.fromNamespaceAndPath("examplemod", "copper")
+);
+```
+
+Now that we have our `ArmorMaterial`, we can use it for [registering] armor. `ArmorItem` takes in the `ArmorMaterial` and the `ArmorType` representing where the item can be equipped. `AnimalArmorItem`, on the other hand takes in the `ArmorMaterial` and the `AnimalArmorItem.BodyType`. It also can optionally take in the an equip sound and whether to apply the durability and repairable components.
+
+```java
+// ITEMS is a DeferredRegister.Items
+public static final DeferredItem<ArmorItem> COPPER_HELMET = ITEMS.registerItem(
+    "copper_helmet",
+    props -> new ArmorItem(
+        // The material to use.
+        COPPER_ARMOR_MATERIAL,
+        // The type of armor to create.
+        ArmorType.HELMET,
+        // The item properties.
+        props
+    )
+);
+
+public static final DeferredItem<ArmorItem> COPPER_CHESTPLATE =
+    ITEMS.registerItem("copper_chestplate", props -> new ArmorItem(...));
+public static final DeferredItem<ArmorItem> COPPER_LEGGINGS =
+    ITEMS.registerItem("copper_chestplate", props -> new ArmorItem(...));
+public static final DeferredItem<ArmorItem> COPPER_BOOTS =
+    ITEMS.registerItem("copper_chestplate", props -> new ArmorItem(...));
+
+public static final DeferredItem<AnimalArmorItem> COPPER_WOLF_ARMOR = ITEMS.registerItem(
+    "copper_wolf_armor",
+    props -> new AnimalArmorItem(
+        // The material to use.
+        COPPER_ARMOR_MATERIAL,
+        // The body type the armor can be worn by.
+        AnimalArmorItem.BodyType.CANINE,
+        // The item properties.
+        props
+    )
+);
+
+public static final DeferredItem<AnimalArmorItem> COPPER_HORSE_ARMOR =
+    ITEMS.registerItem("copper_horse_armor", props -> new AnimalArmorItem(...));
+```
+
+Now, creating armor or an armor-like item does not need to extend `ArmorItem` or `AnimalArmorItem`. It simply can be implemented using a combination of the following parts:
+
+- Adding a `Equippable` with your own requirements by setting `DataComponents#EQUIPPABLE` via `Item.Properties#component`.
+- Adding attributes to the item (e.g. armor, toughness, knockback) via `Item.Properties#attributes`.
+- Adding item durability via `Item.Properties#durability`.
+- Allowing the item to be repaired via `Item.Properties#repariable`.
+- Allowing the item to be enchanted via `Item.Properties#enchantable`.
+- Adding your armor to some of the `minecraft:enchantable/*` `ItemTags` so that your item can have certain enchantments applied to it.
+
+:::note
+The only logic that has no alternative to using an `ArmorItem` base is when mobs replace their current held item via `Mob#canReplaceCurrentItem`. Mobs will always check for an instance of `SwordItem`, followed by `BowItem`, `CrossbowItem`, `ArmorItem`, and `DiggerItem`, with all other items not considered for specialized logic.
+:::
+
+### `Equippable`
+
+`Equippable` is a data component that contains how an entity can equip this item and what handles the rendering in game. This allows any item, regardless of whether it is considered 'armor', to be equipped if this component is available (for example carpets on llamas). Each item with this component can only be equipped to a single `EquipmentSlot`.
+
+An `Equippable` can be created either by directly calling the record constructor or via `Equippable#builder`, which sets the defaults for each field, folowed by `build` once finished:
+
+```java
+// Assume there is some DeferredRegister.Items ITEMS
+public static final DeferredItem<Item> EQUIPPABLE = ITEMS.registerSimpleItem(
+    "equippable",
+    new Item.Properties().copmonent(
+        DataComponents.EQUIPPABLE,
+        // Sets the slot that this item can be equipped to.
+        Equippable.builder(EquipmentSlot.HELMET)
+            // Determines the sound played when equipping this armor.
+            // This is wrapped with a Holder.
+            // Defaults to SoundEvents#ARMOR_EQUIP_GENERIC.
+            .setEquipSound(SoundEvents.ARMOR_EQUIP_GENERIC)
+            // The relative location of the EquipmentModel JSON discussed below.
+            // Points to assets/examplemod/models/equipment/equippable.json
+            // When not set, does not render the equipment.
+            .setModel(ResourceLocation.fromNamespaceAndPath("examplemod", "equippable"))
+            // The relative location of the texture to overlay on the player screen when wearing (e.g., pumpkin blur).
+            // Points to assets/examplemod/textures/equippable.png
+            // When not set, does not render an overlay.
+            .setCameraOverlay(ResourceLocation.withDefaultNamespace("examplemod", "equippable"))
+            // A HolderSet of entity types (direct or tag) that can equip this item.
+            // When not set, any entity can equip this item.
+            .setAllowedEntities(EntityType.ZOMBIE)
+            // Whether the item can be equipped when dispensed from a dispenser.
+            // Defaults to true.
+            .setDispensable(true),
+            // Whether the item can be swapped off the player during a quick equip.
+            // Defaults to true.
+            .setSwappable(false),
+            // Whether the item should be damaged when attacked (for equipment typically).
+            // Must also be a damageable item.
+            // Defaults to true.
+            .setDamageOnHurt(false)
+            .build()
+    )
+);
+```
+
+## Equipment Models
+
+Now we have some armor in game, but if we try to wear it, nothing will render since we never specified how to render the equipment. To do so, we need to create an `EquipmentModel` JSON at the location specified by `Equippable#model`, relative to the `models/equipment` folder of the [resource pack][respack] (`assets` folder). The `EquipmentModel` specifies the associated textures to use for each layer to render.
+
+:::note
+`EquipmentModel` is a bit of a misnomer as it does **not** specify the model to use when rendering, only the textures. The model used is the one passed in during [equipment rendering][rendering].
+:::
+
+An `EquipmentModel` is functionally a map of `EquipmentModel.LayerType`s to a list of `EquipmentModel.Layer`s to apply.
+
+The `LayerType` can be thought of as a group of textures to render for some instance. For example, `LayerType#HUMANOID` is used by the `HumanoidArmorLayer` to render the head, chest, and feet on humanoid entities; `LayerType#WOLF_BODY` is used by `WolfArmorLayer` to render the body armor. These can be combined into one equipment model JSON if they are for the same type of equippable, like copper armor.
+
+The `LayerType` maps to some list of `Layer`s to apply and render the model in the order provided. A `Layer` effectively represents a single texture to render. The first parameter represents the location of the texture, relative to `textures/entity/equipment`.
+
+The second parameter is an optional that indicates whether the [texture can be tinted][tinting] as a `EquipmentModel.Dyeable`. The `Dyeable` object holds an integer that, when present, indicates the default RGB color to tint the texture with. If this optional is not present, then pure white is used.
+
+:::warning
+For a tint other than the undyed color to be applied to the item, the item must be in the [`ItemTags#DYEABLE`][tag] and have the `DataComponents#DYED_COLOR` component set to some RGB value.
+:::
+
+The third parameter is a boolean that indicates whether the texture provided during rendering should be used instead of the one defined within the `Layer`. An example of this is a custom cape or custom elytra texture for the player.
+
+Let's create a equipment model for the copper armor material. We'll also assume that for each layer there are two textures: one for the actual armor and one that is overlayed and tinted. For the animal armor, we'll say that there is some dynamic texture to be used that can be passed in.
+
+<Tabs>
+<TabItem value="json" label="JSON" default>
+
+```json5
+// In assets/examplemod/models/equipment/copper.json
+{
+    // The layer map
+    "layers": {
+        // The serialized name of the EquipmentModel.LayerType to apply.
+        // For humanoid head, chest, and feet
+        "humanoid": [
+            // A list of layers to render in the order provided
+            {
+                // The relative texture of the armor
+                // Points to assets/examplemod/textures/entity/equipment/copper/outer.png
+                "texture": "examplemod:copper/outer"
+            },
+            {
+                // The overlay texture
+                // Points to assets/examplemod/textures/entity/equipment/copper/outer_overlay.png
+                "texture": "examplemod:copper/outer_overlay",
+                // When specified, allows the texture to be tinted the color in DataComponents#DYED_COLOR
+                // Otherwise, cannot be tinted
+                "dyeable": {
+                    // An RGB value (always opaque color)
+                    // 0x7683DE as decimal
+                    // When not specified, set to 0 (meaning transparent or invisible)
+                    "color_when_undyed": 7767006
+                }
+            }
+        ],
+        // For humanoid legs
+        "humanoid_leggings": [
+            {
+                // Points to assets/examplemod/textures/entity/equipment/copper/inner.png
+                "texture": "examplemod:copper/inner"
+            },
+            {
+                // Points to assets/examplemod/textures/entity/equipment/copper/inner_overlay.png
+                "texture": "examplemod:copper/inner_overlay",
+                "dyeable": {
+                    "color_when_undyed": 7767006
+                }
+            }
+        ],
+        // For wolf armor
+        "wolf_body": [
+            {
+                // Points to assets/examplemod/textures/entity/equipment/copper/wolf.png
+                "texture": "examplemod:copper/wolf",
+                // When true, uses the texture passed into the layer renderer instead
+                "use_player_texture": true
+            }
+        ],
+        // For horse armor
+        "horse_body": [
+            {
+                // Points to assets/examplemod/textures/entity/equipment/copper/horse.png
+                "texture": "examplemod:copper/horse",
+                "use_player_texture": true
+            }
+        ]
+    }
+}
+```
+
+</TabItem>
+
+<TabItem value="datagen" label="Datagen">
+
+```java
+public class MyEquipmentModelProvider implements DataProvider {
+
+    private final PackOutput.PathProvider path;
+
+    public MyEquipmentModelProvider(PackOutput output) {
+        this.path = output.createPathProvider(PackOutput.Target.RESOURCE_PACK, "models/equipment");
+    }
+
+    private void add(BiConsumer<ResourceLocation, EquipmentModel> registrar) {
+        registrar.accept(
+            // Must match Equippable#model
+            ResourceLocation.fromNamespaceAndPath("examplemod", "copper"),
+            EquipmentModel.builder()
+                // For humanoid head, chest, and feet
+                .addLayers(
+                    EquipmentModel.LayerType.HUMANOID,
+                    // Base texture
+                    new EquipmentModel.Layer(
+                        // The relative texture of the armor
+                        // Points to assets/examplemod/textures/entity/equipment/copper/outer.png
+                        ResourceLocation.fromNamespaceAndPath("examplemod", "copper/outer"),
+                        Optional.empty(),
+                        false
+                    ),
+                    // Overlay texture
+                    new EquipmentModel.Layer(
+                        // The overlay texture
+                        // Points to assets/examplemod/textures/entity/equipment/copper/outer_overlay.png
+                        ResourceLocation.fromNamespaceAndPath("examplemod", "copper/outer_overlay"),
+                        // An RGB value (always opaque color)
+                        // When not specified, set to 0 (meaning transparent or invisible)
+                        Optional.of(new EquipmentModel.Dyeable(Optional.of(0x7683DE))),
+                        false
+                    )
+                )
+                // For humanoid legs
+                .addLayers(
+                    EquipmentModel.LayerType.HUMANOID_LEGGINGS,
+                    new EquipmentModel.Layer(
+                        // Points to assets/examplemod/textures/entity/equipment/copper/inner.png
+                        ResourceLocation.fromNamespaceAndPath("examplemod", "copper/inner"),
+                        Optional.empty(),
+                        false
+                    ),
+                    new EquipmentModel.Layer(
+                        // Points to assets/examplemod/textures/entity/equipment/copper/inner_overlay.png
+                        ResourceLocation.fromNamespaceAndPath("examplemod", "copper/inner_overlay"),
+                        Optional.of(new EquipmentModel.Dyeable(Optional.of(0x7683DE))),
+                        false
+                    )
+                )
+                // For wolf armor
+                .addLayers(
+                    EquipmentModel.LayerType.WOLF_BODY,
+                    // Base texture
+                    new EquipmentModel.Layer(
+                        // Points to assets/examplemod/textures/entity/equipment/copper/wolf.png
+                        ResourceLocation.fromNamespaceAndPath("examplemod", "copper/wolf"),
+                        Optional.empty(),
+                        // When true, uses the texture passed into the layer renderer instead
+                        true
+                    )
+                )
+                // For horse armor
+                .addLayers(
+                    EquipmentModel.LayerType.HORSE_BODY,
+                    // Base texture
+                    new EquipmentModel.Layer(
+                        // Points to assets/examplemod/textures/entity/equipment/copper/horse.png
+                        ResourceLocation.fromNamespaceAndPath("examplemod", "copper/horse"),
+                        Optional.empty(),
+                        true
+                    )
+                )
+                .build()
+        );
+    }
+
+    @Override
+    public CompletableFuture<?> run(CachedOutput cache) {
+        Map<ResourceLocation, EquipmentModel> map = new HashMap<>();
+        this.add((name, model) -> {
+            if (map.putIfAbsent(name, model) != null) {
+                throw new IllegalStateException("Tried to register equipment model twice for id: " + name);
+            }
+        });
+        return DataProvider.saveAll(cache, EquipmentModel.CODEC, this.pathProvider, map);
+    }
+
+    @Override
+    public String getName() {
+        return "Equipment Model Definitions: " + MOD_ID;
+    }
+}
+
+// Listening to the mod event bus
+@SubscribeEvent
+public static void gatherData(GatherDataEvent event) {
+    PackOutput output = generator.getPackOutput();
+
+    // Other providers here
+    event.getGenerator().addProvider(
+        event.includeClient(),
+        new MyEquipmentModelProvider(output)
+    );
+}
+```
+
+</TabItem>
+</Tabs>
+
+## Equipment Rendering
+
+The equipment models are rendered via the `EquipmentLayerRenderer` in the render function of an `EntityRenderer` or one of its `RenderLayer`s. `EquipmentLayerRenderer` is obtained as part of the render context via `EntityRendererProvider.Context#getEquipmentRenderer`. If the `EquipmentModel`s are required, they are also available via `EntityRendererProvider.Context#getEquipmentModels`.
+
+By default, the following layers render the associated `EquipmentModel.LayerType`:
+
+| `LayerType`         | `RenderLayer`        | Used by                                                        |
+|:-------------------:|:--------------------:|:---------------------------------------------------------------|
+| `HUMANOID`          | `HumanoidArmorLayer` | Player, humanoid mobs (e.g., zombies, skeletons), armor stands |
+| `HUMANOID_LEGGINGS` | `HumanoidArmorLayer` | Player, humanoid mobs (e.g., zombies, skeletons), armor stands |
+| `WINGS`             | `WingsLayer`         | Player, humanoid mobs (e.g., zombies, skeletons), armor stands |
+| `WOLF_BODY`         | `WolfArmorLayer`     | Wolf                                                           |
+| `HORSE_BODY`        | `HorseArmorLayer`    | Horse                                                          |
+| `LLAMA_BODY`        | `LlamaDecorLayer`    | Llama, trader llama                                            |
+
+`EquipmentLayerRenderer` has only one method to render the equipment layers, aptly named `renderLayers`:
+
+```java
+// In some render method where EquipmentLayerRenderer equipmentLayerRenderer is a field
+this.equipmentLayerRenderer.renderLayers(
+    // The layer type to render
+    EquipmentModel.LayerType.HUMANOID,
+    // The model id representing the EquipmentModel JSON
+    // This would be set in the `EQUIPPABLE` data component via `model`
+    stack.get(DataComponents.EQUIPPABLE).model().orElseThrow(),
+    // The model to apply the textures to
+    // These are usually separate models from the entity model
+    // and are separate ModelLayers linking to a LayerDefinition
+    model,
+    // The item stack representing the item being rendered as a model
+    // This is only used to get the dyeable, foil, and armor trim information
+    stack,
+    // The pose stack used to render the model in the correct location
+    poseStack,
+    // The source of the buffers to get the vertex consumer of the render type
+    bufferSource,
+    // The packed light texture
+    lighting,
+    // An absolute path of the texture to render when use_player_texture is true for one of the layer if not null
+    // Represents an absolute location within the assets folder
+    ResourceLocation.fromNamespaceAndPath("examplemod", "textures/other_texture.png")
+);
+```
+
+[item]: index.md
+[datacomponents]: datacomponents.md
+[enchantment]: ../resources/server/enchantments/index.md#enchantment-costs-and-levels
+[registering]: ../concepts/registries.md#methods-for-registering
+[rendering]: #equipement-rendering
+[respack]: ../resources/index.md#assets
+[tag]: ../resources/server/tags.md
+[tinting]: ../resources/client/models/index.md#tinting
diff --git a/versioned_docs/version-1.21.3/items/consumables.md b/versioned_docs/version-1.21.3/items/consumables.md
new file mode 100644
index 00000000..7c22b1ea
--- /dev/null
+++ b/versioned_docs/version-1.21.3/items/consumables.md
@@ -0,0 +1,368 @@
+---
+sidebar_position: 3
+---
+# Consumables
+
+Consumables are [items][item] which can be used over a period of time, 'consuming' them in the process. Anything that can be eaten or drunk in Minecraft is a consumable of some kind.
+
+## The `Consumable` Data Component
+
+Any item that can be consumed has the [`DataComponents#CONSUMABLE` component][datacomponent]. The backing record `Consumable` defines how the item is consumed and what effects to apply after consumption.
+
+A `Consumable` can be created either by directly calling the record constructor or via `Consumable#builder`, which sets the defaults for each field, followed by `build` once finished:
+
+- `consumeSeconds` - A `float` representing the number of seconds needed to fully consume the item. `Item#finishUsingItem` is called after the alloted time passes. Defaults to 1.6 seconds, or 32 ticks.
+- `animation` - Sets the [`ItemUseAnimation`][animation] to play while the item is being used. Defaults to `ItemUseAnimation#EAT`.
+- `sound` - Sets the [`SoundEvent`][sound] to play while consuming the item. This must be a `Holder` instance. Defaults to `SoundEvents#GENERIC_EAT`.
+    - If a vanilla instance is not a `Holder<SoundEvent>`, a `Holder` wrapped version can be obtained by calling `BuiltInRegistries.SOUND_EVENT.wrapAsHolder(soundEvent)`.
+- `soundAfterConsume` - Sets the [`SoundEvent`][sound] to player once the item has finished being consumed. This delegates to the [`PlaySoundConsumeEffect`][consumeeffect].
+- `hasConsumeParticles` - When `true`, spawns item [particles] every four ticks and once the item is fully consumed. Defauts to `true`.
+- `onConsume` - Adds a [`ConsumeEffect`][consumeeffect] to apply once the item has fully been consumed via `Item#finishUsingItem`.
+
+Vanilla provides some consumables within their `Consumables` class, such as `#defaultFood` for [food] items and `#defaultDrink` for [potions] and milk buckets.
+
+The `Consumable` component can be added by calling `Item.Properties#component`:
+
+```java
+// Assume there is some DeferredRegister.Items ITEMS
+public static final DeferredItem<Item> CONSUMABLE = ITEMS.registerSimpleItem(
+    "consumable",
+    new Item.Properties().component(
+        DataComponents.CONSUMABLE,
+        Consumable.builder()
+            // Spend 2 seconds, or 40 ticks, to consume
+            .consumeSeconds(2f)
+            // Sets the animation to play while consuming
+            .animation(ItemUseAnimation.BLOCK)
+            // Play sound while consuming every tick
+            .sound(SoundEvents.ARMOR_EQUIP_CHAIN)
+            // Play sound once finished consuming
+            .soundAfterConsume(SoundEvents.BREEZE_WIND_CHARGE_BURST)
+            // Don't show particles while eating
+            .hasConsumeParticles(false)
+            .onConsume(
+                // When finished consuming, applies the effects with a 30% chance
+                new ApplyStatusEffectsConsumeEffect(new MobEffectInstance(MobEffects.HUNGER, 600, 0), 0.3F)
+            )
+            // Can have multiple
+            .onConsume(
+                // Teleports the entity randomly in a 50 block radius
+                new TeleportRandomlyConsumeEffect(100f)
+            )
+            .build()
+    )
+);
+```
+
+### `ConsumeEffect`
+
+When a consumable has finished being used, you may want to trigger some kind of logic to execute like adding a potion effect. These are handled by `ConsumeEffect`s, which are added to the `Consumable` by calling `Consumable.Builder#onConsume`.
+
+A list of vanilla effects can be found in `ConsumeEffect`.
+
+Every `ConsumeEffect` has two methods: `getType`, which specifies the registry object `ConsumeEffect.Type`; and `apply`, which is called on the item when it has been fully consumed. `apply` takes three arguments: the `Level` the consuming entity is in, the `ItemStack` the consumable was called on, and the `LivingEntity` consuming the object. When the effect is successfully applied, the method returns `true`, or `false` if it failed.
+
+A `ConsumeEffect` can be created by implementing the interface and [registering] the `ConsumeEffect.Type` with the associated `MapCodec` and `StreamCodec` to `BuiltInRegistries#CONSUME_EFFECT_TYPE`:
+
+```java
+public record UsePortalConsumeEffect(ResourceKey<Level> level)
+    implements ConsumeEffect, Portal {
+
+    @Override
+    public boolean apply(Level level, ItemStack stack, LivingEntity entity) {
+        if (entity.canUsePortal(false)) {
+            entity.setAsInsidePortal(this, entity.blockPosition());
+
+            // Can successfully use portal
+            return true;
+        }
+
+        // Cannot use portal
+        return false;
+    }
+
+    @Override
+    public ConsumeEffect.Type<? extends ConsumeEffect> getType() {
+        // Set to registered object
+        return USE_PORTAL.get();
+    }
+
+    @Override
+    @Nullable
+    public TeleportTransition getPortalDestination(ServerLevel level, Entity entity, BlockPos pos) {
+        // Set teleport location
+    }
+}
+
+// In some registrar class
+// Assume there is some DeferredRegister<ConsumeEffect.Type<?>> CONSUME_EFFECT_TYPES
+public static final Supplier<ConsumeEffect.Type<UsePortalConsumeEffect>> USE_PORTAL =
+    CONSUME_EFFECT_TYPES.register("use_portal", () -> new ConsumeEffect.Type<>(
+        ResourceKey.codec(Registries.DIMENSION).optionalFieldOf("dimension")
+            .xmap(UsePortalConsumeEffect::new, UsePortalConsumeEffect::level),
+        ResourceKey.streamCodec(Registries.DIMENSION)
+            .map(UsePortalConsumeEffect::new, UsePortalConsumeEffect::level)
+    ));
+
+// For some Item.Properties that is adding a CONSUMABLE component
+Consumable.builder()
+    .onConsume(
+        new UsePortalConsumeEffect(Level.END)
+    )
+    .build();
+```
+
+### `ItemUseAnimation`
+
+`ItemUseAnimation` is functionally an enum which doesn't define anything besides its id and name. Its uses are hardcoded into `ItemHandRenderer#renderArmWithItem` for first person and `PlayerRenderer#getArmPose` for third person. As such, simply creating a new `ItemUseAnimation` will only function similarly to `ItemUseAnimation#NONE`.
+
+To apply some animation, you need to implement `IClientItemExtensions#applyForgeHandTransform` for first person and/or `IClientItemExtensions#getArmPose` for third person rendering.
+
+#### Creating the `ItemUseAnimation`
+
+First, let's create a new `ItemUseAnimation`. This is done using the [extensible enum][extensibleenum] system:
+
+```json5
+{
+    "entries": [
+        {
+            "enum": "net/minecraft/world/item/ItemUseAnimation",
+            "name": "EXAMPLEMOD_ITEM_USE_ANIMATION",
+            "constructor": "(ILjava/lang/String;)V",
+            "parameters": [
+                // The id, should always be -1
+                -1,
+                // The name, should be a unique identifier
+                "examplemod:item_use_animation"
+            ]
+        }
+    ]
+}
+```
+
+Then we can get the enum constant via `valueOf`:
+
+```java
+public static final ItemUseAnimation EXAMPLE_ANIMATION = ItemUseAnimation.valueOf("EXAMPLEMOD_ITEM_USE_ANIMATION");
+```
+
+From there, we can then start applying the transforms. To do this, we must create a new `IClientItemExtensions`, implement our desired methods, and register it via `RegisterClientExtensionsEvent` on the [**mod event bus**][modbus]:
+
+```java
+public class ConsumableClientItemExtensions implements IClientItemExtensions {
+    // Implement methods here
+}
+
+// In some event listener class
+@SubscribeEvent
+public static void registerClientExtensions(RegisterClientExtensionsEvent event) {
+    event.registerItem(
+        // The instance of the item extensions
+        new ConsumableClientItemExtensions(),
+        // A vararg of items that use this
+        CONSUMABLE
+    )
+}
+```
+
+#### First Person
+
+The first person transform, which all consumables have, is implemented via `IClientItemExtensions#applyForgeHandTransform`:
+
+```java
+public class ConsumableClientItemExtensions implements IClientItemExtensions {
+
+    // ...
+
+    @Override
+    public boolean applyForgeHandTransform(
+        PoseStack poseStack, LocalPlayer player, HumanoidArm arm, ItemStack itemInHand,
+        float partialTick, float equipProcess, float swingProcess
+    ) {
+        // We first need to check if the item is being used and has our animation
+        HumanoidArm usingArm = entity.getUsedItemHand() == InteractionHand.MAIN_HAND
+            ? entity.getMainArm()
+            : entity.getMainArm().getOpposite();
+        if (
+            entity.isUsingItem() && entity.getUseItemRemainingTicks() > 0
+            && usingArm == arm && itemInHand.getUseAnimation() == EXAMPLE_ANIMATION
+        ) {
+            // Apply transformations to pose stack (translate, scale, mulPose)
+            // ...
+            return true;
+        }
+
+        // Do nothing
+        return false;
+    }
+}
+```
+
+#### Third Person
+
+The third person transforms, which all but `EAT` and `DRINK` have special logic for, is implemented via `IClientItemExtensions#getArmPose`, where `HumanoidModel.ArmPose` can also be extended for a custom transform.
+
+As an `ArmPose` requries a lambda as part of its constructor, an `EnumProxy` reference must be used:
+
+```json5
+{
+    "entries": [
+        {
+            "name": "EXAMPLEMOD_ITEM_USE_ANIMATION",
+            // ...
+        },
+        {
+            "enum": "net/minecraft/client/model/HumanoidModel$ArmPose",
+            "name": "EXAMPLEMOD_ARM_POSE",
+            "constructor": "(ZLnet/neoforged/neoforge/client/IArmPoseTransformer;)V",
+            "parameters": {
+                // Point to class where the proxy is located
+                // Should be separate as this is a client only class
+                "class": "example/examplemod/client/MyClientEnumParams",
+                // The field name of the enum proxy
+                "field": "CUSTOM_ARM_POSE"
+            }
+        }
+    ]
+}
+```
+
+```java
+// Create the enum parameters
+public class MyClientEnumParams {
+    public static final EnumProxy<HumanoidModel.ArmPose> CUSTOM_ARM_POSE = new EnumProxy<>(
+        HumanoidModel.ArmPose.class,
+        // Whether the pose uses both arms
+        false,
+        // The pose transformer
+        (IArmPoseTransformer) MyClientEnumParams::applyCustomModelPose
+    );
+
+    private static void applyCustomModelPose(
+        HumanoidModel<?> model, HumanoidRenderState state, HumanoidArm arm
+    ) {
+        // Apply model transforms here
+        // ...
+    }
+}
+
+// In some client only class
+public static final HumanoidModel.ArmPose EXAMPLE_POSE = HumanoidModel.ArmPose.valueOf("EXAMPLEMOD_ARM_POSE");
+```
+
+Then, the arm pose is set via `IClientItemExtensions#getArmPose`:
+
+```java
+public class ConsumableClientItemExtensions implements IClientItemExtensions {
+
+    // ...
+
+    @Override
+    public HumanoidModel.ArmPose getArmPose(
+        LivingEntity entity, InteractionHand hand, ItemStack stack
+    ) {
+        // We first need to check if the item is being used and has our animation
+        if (
+            entity.isUsingItem() && entity.getUseItemRemainingTicks() > 0
+            && entity.getUsedItemHand() == hand
+            && itemInHand.getUseAnimation() == EXAMPLE_ANIMATION
+        ) {
+            // Return pose to apply
+            return EXAMPLE_POSE;
+        }
+
+        // Otherwise return null
+        return null;
+    }
+}
+```
+
+### Overriding Sounds on Entity
+
+Sometimes, an entity may want to play a different sound while consuming an item. In those instances, the `LivingEntity` instance can implement `Consumable.OverrideConsumeSound` and have `getConsumeSound` return the `SoundEvent` they want their entity to play.
+
+```java
+public class MyEntity extends LivingEntity implements Consumable.OverrideConsumeSound {
+    
+    // ...
+
+    @Override
+    public SoundEvent getConsumeSound(ItemStack stack) {
+        // Return the sound to play
+    }
+}
+```
+
+## `ConsumableListener`
+
+While consumables and effects that are applied after consumption are useful, sometimes the properties of an effect need to be externally available as other [data components][datacomponents]. For example, cats and wolves also eat [food] and query its nutrition, or item with potion contents query its color for rendering. In these instances, data components implement `ConsumableListener` to provide consumption logic.
+
+A `ConsumableListener` only has one method: `#onConsume`, which takes in the current level, the entity consuming the item, the item being consumed, and the `Consumable` instance on the item. `onConsume` is called during `Item#finishUsingItem` when the item has been fully consumed.
+
+Adding your own `ConsumableListener` is simply [registering a new data component][datacompreg] and implementing `ConsumableListener`.
+
+```java
+public record MyConsumableListener() implements ConsumableListener {
+
+    @Override
+    public void onConsume(
+        Level level, LivingEntity entity, ItemStack stack, Consumable consumable
+    ) {
+        // Do things here
+    }
+}
+```
+
+### Food
+
+Food is one type of `ConsumableListener` that is part of the hunger system. All of the functionality for food items is already handled within the `Item` class, so simply adding the `FoodProperties` to `DataComponents#FOOD` along with a consumable is all that's needed. There is a helper method called `food` which takes in the `FoodProperties` and the `Consumable` object, or `Consumables#DEFAULT_FOOD` if none is specified.
+
+`FoodProperties` can be created either by directly calling the record constructor or via `new FoodProperties.Builder()`, followed by `build` once finished:
+
+- `nutrition` - Sets how many hunger points are restored. Counts in half hunger points, so for example, Minecraft's steak restores 8 hunger points.
+- `saturationModifier` - The saturation modifier used in calculating the [saturation value][hunger] restored when eating this food. The calculation is `min(2 * nutrition * saturationModifier, playerNutrition)`, meaning that using `0.5` will make the effective saturation value the same as the nutrition value.
+- `alwaysEdible` - Whether this item can always be eaten, even if the hunger bar is full. `false` by default, `true` for golden apples and other items that provide bonuses beyond just filling the hunger bar.
+
+```java
+// Assume there is some DeferredRegister.Items ITEMS
+public static final DeferredItem<Item> FOOD = ITEMS.registerSimpleItem(
+    "food",
+    new Item.Properties().food(
+        new FoodProperties.Builder()
+            // Heals 1.5 hearts
+            .nutrition(3)
+            // Carrot is 0.3
+            // Raw Cod is 0.1
+            // Cooked Chicken is 0.6
+            // Cooked Beef is 0.8
+            // Golden Aple is 1.2
+            .saturationModifier(0.3f)
+            // When set, the food can alway be eaten even with
+            //  a full hunger bar.
+            .alwaysEdible()
+    )
+);
+```
+
+For examples, or to look at the various values used by Minecraft, have a look at the `Foods` class.
+
+To get the `FoodProperties` for an item, call `ItemStack.get(DataComponents.FOOD)`. This may return null, since not every item is edible. To determine whether an item is edible, null-check the result of the `getFoodProperties` call.
+
+### Potion Contents
+
+The contents of a [potion][potions] via `PotionContents` is another `ConsumableListener` whose effects are applied on consumption. They contain an optional potion to apply, an optional tint for the potion color, a list of custom [`MobEffectInstance`s][mobeffectinstance] to apply alongside the potion, and an optional translation key to use when getting the stack name. The modder needs to override `Item#getName` if not a subtype of `PotionItem`.
+
+[animation]: #itemuseanimation
+[consumeeffect]: #consumeeffect
+[datacomponent]: datacomponents.md
+[datacompreg]: datacomponents.md#creating-custom-data-components
+[extensibleenum]: ../advanced/extensibleenums.md
+[food]: #food
+[hunger]: https://minecraft.wiki/w/Hunger#Mechanics
+[item]: index.md
+[modbus]: ../concepts/events.md#event-buses
+[mobeffectinstance]: mobeffects.md#mobeffectinstances
+[particles]: ../resources/client/particles.md
+[potions]: mobeffects.md#potions
+[sound]: ../resources/client/sounds.md#creating-soundevents
+[registering]: ../concepts/registries.md#methods-for-registering
diff --git a/versioned_docs/version-1.21.3/items/datacomponents.md b/versioned_docs/version-1.21.3/items/datacomponents.md
new file mode 100644
index 00000000..36a00841
--- /dev/null
+++ b/versioned_docs/version-1.21.3/items/datacomponents.md
@@ -0,0 +1,331 @@
+---
+sidebar_position: 2
+---
+
+# Data Components
+
+Data components are key-value pairs within a map used to store data on an `ItemStack`. Each piece of data, such as firework explosions or tools, are stored as actual objects on the stack, making the values visible and operable without having to dynamically transform a general encoded instance (e.g., `CompoundTag`, `JsonElement`).
+
+## `DataComponentType`
+
+Each data component has an associated `DataComponentType<T>`, where `T` is the component value type. The `DataComponentType` represents a key to reference the stored component value along with some codecs to handle reading and writing to the disk and network, if desired.
+
+A list of existing components can be found within `DataComponents`.
+
+### Creating Custom Data Components
+
+The component value associated with the `DataComponentType` must implement `hashCode` and `equals` and should be considered **immutable** when stored.
+
+:::note
+Component values can very easily be implemented using a record. Record fields are immutable and implement `hashCode` and `equals`.
+:::
+
+```java
+// A record example
+public record ExampleRecord(int value1, boolean value2) {}
+
+// A class example
+public class ExampleClass {
+
+    private final int value1;
+    // Can be mutable, but care needs to be taken when using
+    private boolean value2;
+
+    public ExampleClass(int value1, boolean value2) {
+        this.value1 = value1;
+        this.value2 = value2;
+    }
+
+    @Override
+    public int hashCode() {
+        return Objects.hash(this.value1, this.value2);
+    }
+
+    @Override
+    public boolean equals(Object obj) {
+        if (obj == this) {
+            return true;
+        } else {
+            return obj instanceof ExampleClass ex
+                && this.value1 == ex.value1
+                && this.value2 == ex.value2;
+        }
+    }
+}
+```
+
+A standard `DataComponentType` can be created via `DataComponentType#builder` and built using `DataComponentType.Builder#build`. The builder contains three settings: `persistent`, `networkSynchronized`, `cacheEncoding`.
+
+`persistent` specifies the [`Codec`][codec] used to read and write the component value to disk. `networkSynchronized` specifies the `StreamCodec` used to read and write the component across the network. If `networkSynchronized` is not specified, then the `Codec` provided in `persistent` will be wrapped and used as the [`StreamCodec`][streamcodec].
+
+:::warning
+Either `persistent` or `networkSynchronized` must be provided in the builder; otherwise, a `NullPointerException` will be thrown. If no data should be sent across the network, then set `networkSynchronized` to `StreamCodec#unit`, providing the default component value.
+:::
+
+`cacheEncoding` caches the encoding result of the `Codec` such that any subsequent encodes uses the cached value if the component value hasn't changed. This should only be used if the component value is expected to rarely or never change.
+
+`DataComponentType` are registry objects and must be [registered].
+
+```java
+// Using ExampleRecord(int, boolean)
+// Only one Codec and/or StreamCodec should be used below
+// Multiple are provided for an example
+
+// Basic codec
+public static final Codec<ExampleRecord> BASIC_CODEC = RecordCodecBuilder.create(instance ->
+    instance.group(
+        Codec.INT.fieldOf("value1").forGetter(ExampleRecord::value1),
+        Codec.BOOL.fieldOf("value2").forGetter(ExampleRecord::value2)
+    ).apply(instance, ExampleRecord::new)
+);
+public static final StreamCodec<ByteBuf, ExampleRecord> BASIC_STREAM_CODEC = StreamCodec.composite(
+    ByteBufCodecs.INT, ExampleRecord::value1,
+    ByteBufCodecs.BOOL, ExampleRecord::value2,
+    ExampleRecord::new
+);
+
+// Unit stream codec if nothing should be sent across the network
+public static final StreamCodec<ByteBuf, ExampleRecord> UNIT_STREAM_CODEC = StreamCodec.unit(new ExampleRecord(0, false));
+
+
+// In another class
+// The specialized DeferredRegister.DataComponents simplifies data component registration and avoids some generic inference issues with the `DataComponentType.Builder` within a `Supplier`
+public static final DeferredRegister.DataComponents REGISTRAR = DeferredRegister.createDataComponents(Registries.DATA_COMPONENT_TYPE, "examplemod");
+
+public static final Supplier<DataComponentType<ExampleRecord>> BASIC_EXAMPLE = REGISTRAR.registerComponentType(
+    "basic",
+    builder -> builder
+        // The codec to read/write the data to disk
+        .persistent(BASIC_CODEC)
+        // The codec to read/write the data across the network
+        .networkSynchronized(BASIC_STREAM_CODEC)
+);
+
+/// Component will not be saved to disk
+public static final Supplier<DataComponentType<ExampleRecord>> TRANSIENT_EXAMPLE = REGISTRAR.registerComponentType(
+    "transient",
+    builder -> builder.networkSynchronized(BASIC_STREAM_CODEC)
+);
+
+// No data will be synced across the network
+public static final Supplier<DataComponentType<ExampleRecord>> NO_NETWORK_EXAMPLE = REGISTRAR.registerComponentType(
+   "no_network",
+   builder -> builder
+        .persistent(BASIC_CODEC)
+        // Note we use a unit stream codec here
+        .networkSynchronized(UNIT_STREAM_CODEC)
+);
+```
+
+## The Component Map
+
+All data components are stored within a `DataComponentMap`, using the `DataComponentType` as the key and the object as the value. `DataComponentMap` functions similarly to a read-only `Map`. As such, there are methods to `#get` an entry given its `DataComponentType` or provide a default if not present (via `#getOrDefault`).
+
+```java
+// For some DataComponentMap map
+
+// Will get dye color if component is present
+// Otherwise null
+@Nullable
+DyeColor color = map.get(DataComponents.BASE_COLOR);
+```
+
+### `PatchedDataComponentMap`
+
+As the default `DataComponentMap` only provides methods for read-based operations, write-based operations are supported using the subclass `PatchedDataComponentMap`. This includes `#set`ting the value of a component or `#remove`ing it altogether.
+
+`PatchedDataComponentMap` stores changes using a prototype and patch map. The prototype is a `DataComponentMap` that contains the default components and their
+values this map should have. The patch map is a map of `DataComponentType`s to `Optional` values that contain the changes made to the default components.
+
+```java
+// For some PatchedDataComponentMap map
+
+// Sets the base color to white
+map.set(DataComponents.BASE_COLOR, DyeColor.WHITE);
+
+// Removes the base color by
+// - Removing the patch if no default is provided
+// - Setting an empty optional if there is a default
+map.remove(DataComponents.BASE_COLOR);
+```
+
+:::danger
+Both the prototype and patch map are part of the hash code for the `PatchedDataComponentMap`. As such, any component values within the map should be treated as **immutable**. Always call `#set` or one of its referring methods discussed below after modifying the value of a data component.
+:::
+
+## The Component Holder
+
+All instances that can hold data components implement `DataComponentHolder`. `DataComponentHolder` is effectively a delegate to the read-only methods within `DataComponentMap`.
+
+```java
+// For some ItemStack stack
+
+// Delegates to 'DataComponentMap#get'
+@Nullable
+DyeColor color = stack.get(DataComponents.BASE_COLOR);
+```
+
+### `MutableDataComponentHolder`
+
+`MutableDataComponentHolder` is an interface provided by NeoForge to support write-based methods to the component map. All implementations within Vanilla and NeoForge store data components using a `PatchedDataComponentMap`, so the `#set` and `#remove` methods also have delegates with the same name.
+
+In addition, `MutableDataComponentHolder` also provides an `#update` method which handles getting the component value or the provided default if none is set, operating on the value, and then setting it back to the map. The operator is either a `UnaryOperator`, which takes in the component value and returns the component value, or a `BiFunction`, which takes in the component value and another object and returns the component value.
+
+```java
+// For some ItemStack stack
+
+FireworkExplosion explosion = stack.get(DataComponents.FIREWORK_EXPLOSION);
+
+// Modifying the component value
+explosion = explosion.withFadeColors(new IntArrayList(new int[] {1, 2, 3}));
+
+// Since we modified the component value, 'set' should be called afterward
+stack.set(DataComponents.FIREWORK_EXPLOSION, explosion);
+
+// Update the component value (calls 'set' internally)
+stack.update(
+    DataComponents.FIREWORK_EXPLOSION,
+    // Default value if no component value is present
+    FireworkExplosion.DEFAULT,
+    // Return a new FireworkExplosion to set
+    explosion -> explosion.withFadeColors(new IntArrayList(new int[] {4, 5, 6}))
+);
+
+stack.update(
+    DataComponents.FIREWORK_EXPLOSION,
+    // Default value if no component value is present
+    FireworkExplosion.DEFAULT,
+    // An object that is supplied to the function
+    new IntArrayList(new int[] {7, 8, 9}),
+    // Return a new FireworkExplosion to set
+    FireworkExplosion::withFadeColors
+);
+```
+
+## Adding Default Data Components to Items
+
+Although data components are stored on an `ItemStack`, a map of default components can be set on an `Item` to be passed to the `ItemStack` as a prototype when constructed. A component can be added to the `Item` via `Item.Properties#component`.
+
+```java
+// For some DeferredRegister.Items REGISTRAR
+public static final Item COMPONENT_EXAMPLE = REGISTRAR.register("component",
+    // register is used over other overloads as the DataComponentType has not been registered yet
+    registryName -> new Item(
+        new Item.Properties()
+        .setId(ResourceKey.create(Registries.ITEM, registryName))
+        .component(BASIC_EXAMPLE.get(), new ExampleRecord(24, true))
+    )
+);
+```
+
+If the data component should be added to an existing item that belongs to Vanilla or another mod, then `ModifyDefaultComponentEvent` should be listened for on the [**mod event bus**][modbus]. The event provides the `modify` and `modifyMatching` methods which allows the `DataComponentPatch.Builder` to be modified for the associated items. The builder can either `#set` components or `#remove` existing components.
+
+```java
+// Listened to on the mod event bus
+@SubscribeEvent
+public void modifyComponents(ModifyDefaultComponentsEvent event) {
+    // Sets the component on melon seeds
+    event.modify(Items.MELON_SEEDS, builder ->
+        builder.set(BASIC_EXAMPLE.get(), new ExampleRecord(10, false))
+    );
+
+    // Removes the component for any items that have a crafting remainder
+    event.modifyMatching(
+        item -> !item.getCraftingRemainder().isEmpty(),
+        builder -> builder.remove(DataComponents.BUCKET_ENTITY_DATA)
+    );
+}
+```
+
+## Using Custom Component Holders
+
+To create a custom data component holder, the holder object simply needs to implement `MutableDataComponentHolder` and implement the missing methods. The holder object must contain a field representing the `PatchedDataComponentMap` to implement the associated methods.
+
+```java
+public class ExampleHolder implements MutableDataComponentHolder {
+
+    private int data;
+    private final PatchedDataComponentMap components;
+
+    // Overloads can be provided to supply the map itself
+    public ExampleHolder() {
+        this.data = 0;
+        this.components = new PatchedDataComponentMap(DataComponentMap.EMPTY);
+    }
+
+    @Override
+    public DataComponentMap getComponents() {
+        return this.components;
+    }
+
+    @Nullable
+    @Override
+    public <T> T set(DataComponentType<? super T> componentType, @Nullable T value) {
+        return this.components.set(componentType, value);
+    }
+
+    @Nullable
+    @Override
+    public <T> T remove(DataComponentType<? extends T> componentType) {
+        return this.components.remove(componentType);
+    }
+
+    @Override
+    public void applyComponents(DataComponentPatch patch) {
+        this.components.applyPatch(patch);
+    }
+
+    @Override
+    public void applyComponents(DataComponentMap components) {
+        this.components.setAll(components);
+    }
+
+    // Other methods
+}
+```
+
+### `DataComponentPatch` and Codecs
+
+To persist components to disk or send information across the network, the holder could send the entire `DataComponentMap`. However, this is generally a waste of information as any defaults will already be present wherever the data is sent to. So, instead, we use a `DataComponentPatch` to send the associated data. `DataComponentPatch`es only contain the patch information of the component map without any defaults. The patches are then applied to the prototype in the receiver's location.
+
+A `DataComponentPatch` can be created from a `PatchedDataComponentMap` via `#patch`. Likewise, `PatchedDataComponentMap#fromPatch` can construct a `PatchedDataComponentMap` given the prototype `DataComponentMap` and a `DataComponentPatch`.
+
+```java
+public class ExampleHolder implements MutableDataComponentHolder {
+
+    public static final Codec<ExampleHolder> CODEC = RecordCodecBuilder.create(instance ->
+        instance.group(
+            Codec.INT.fieldOf("data").forGetter(ExampleHolder::getData),
+            DataCopmonentPatch.CODEC.optionalFieldOf("components", DataComponentPatch.EMPTY).forGetter(holder -> holder.components.asPatch())
+        ).apply(instance, ExampleHolder::new)
+    );
+
+    public static final StreamCodec<RegistryFriendlyByteBuf, ExampleHolder> STREAM_CODEC = StreamCodec.composite(
+        ByteBufCodecs.INT, ExampleHolder::getData,
+        DataComponentPatch.STREAM_CODEC, holder -> holder.components.asPatch(),
+        ExampleHolder::new
+    );
+
+    // ...
+
+    public ExampleHolder(int data, DataComponentPatch patch) {
+        this.data = data;
+        this.components = PatchedDataComponentMap.fromPatch(
+            // The prototype map to apply to
+            DataComponentMap.EMPTY,
+            // The associated patches
+            patch
+        );
+    }
+
+    // ...
+}
+```
+
+[Syncing the holder data across the network][network] and reading/writing the data to disk must be done manually.
+
+[registered]: ../concepts/registries.md
+[codec]: ../datastorage/codecs.md
+[modbus]: ../concepts/events.md#event-buses
+[network]: ../networking/payload.md
+[streamcodec]: ../networking/streamcodecs.md
diff --git a/versioned_docs/version-1.21.3/items/index.md b/versioned_docs/version-1.21.3/items/index.md
new file mode 100644
index 00000000..d4691346
--- /dev/null
+++ b/versioned_docs/version-1.21.3/items/index.md
@@ -0,0 +1,255 @@
+# Items
+
+Along with blocks, items are a key component of Minecraft. While blocks make up the world around you, items exist within inventories.
+
+## What Even Is an Item?
+
+Before we get further into creating items, it is important to understand what an item actually is, and what distinguishes it from, say, a [block][block]. Let's illustrate this using an example:
+
+- In the world, you encounter a dirt block and want to mine it. This is a **block**, because it is placed in the world. (Actually, it is not a block, but a blockstate. See the [Blockstates article][blockstates] for more detailed information.)
+    - Not all blocks drop themselves when breaking (e.g. leaves), see the article on [loot tables][loottables] for more information.
+- Once you have [mined the block][breaking], it is removed (= replaced with an air block) and the dirt drops. The dropped dirt is an item **entity**. This means that like other entities (pigs, zombies, arrows, etc.), it can inherently be moved by things like water pushing on it, or burned by fire and lava.
+- Once you pick up the dirt item entity, it becomes an **item stack** in your inventory. An item stack is, simply put, an instance of an item with some extra information, such as the stack size.
+- Item stacks are backed by their corresponding **item** (which is what we're creating). Items hold [data components][datacomponents] that contains the default information all items stacks are initialized to (for example, every iron sword has a max durability of 250), while item stacks can modify those data components, allowing two different stacks for the same item to have different information (for example, one iron sword has 100 uses left, while another iron sword has 200 uses left). For more information on what is done through items and what is done through item stacks, read on.
+    - The relationship between items and item stacks is roughly the same as between [blocks][block] and [blockstates][blockstates], in that a blockstate is always backed by a block. It's not a really accurate comparison (item stacks aren't singletons, for example), but it gives a good basic idea about what the concept is here.
+
+## Creating an Item
+
+Now that we understand what an item is, let's create one!
+
+Like with basic blocks, for basic items that need no special functionality (think sticks, sugar, etc.), the `Item` class can be used directly. To do so, during registration, instantiate `Item` with a `Item.Properties` parameter. This `Item.Properties` parameter can be created using `Item.Properties#of`, and it can be customized by calling its methods:
+
+- `setId` - Sets the resource key of the item.
+    - This **must** be set on every item; otherwise, an exception will be thrown.
+- `overrideDescription` - Sets the translation key of the item. The created `Component` is stored in `DataComponents#ITEM_NAME`.
+- `useBlockDescriptionPrefix` - Convenience helper that calls `overrideDescription` with the translation key `block.<modid>.<registry_name>`. This should be called on any `BlockItem`.
+- `overrideModel` - Sets the `ResourceLocation` representing the item model and expands to `assets/<namespace>/models/item/<path>.json`. The `ResourceLocation` is stored in `DataComponents#ITEM_MODEL`.
+- `requiredFeatures` - Sets the required feature flags for this item. This is mainly used for vanilla's feature locking system in minor versions. It is discouraged to use this, unless you're integrating with a system locked behind feature flags by vanilla.
+- `stacksTo` - Sets the max stack size (via `DataComponents#MAX_STACK_SIZE`) of this item. Defaults to 64. Used e.g. by ender pearls or other items that only stack to 16.
+- `durability` - Sets the durability (via `DataComponents#MAX_DAMAGE`) of this item and the initial damage to 0 (via `DataComponents#DAMAGE`). Defaults to 0, which means "no durability". For example, iron tools use 250 here. Note that setting the durability automatically locks the max stack size to 1.
+- `fireResistant` - Makes item entities that use this item immune to fire and lava (via `DataComponents#FIRE_RESISTANT`). Used by various netherite items.
+- `rarity` - Sets the rarity of this item (via `DataComponents#RARITY`). Currently, this simply changes the item's color. `Rarity` is an enum consisting of the four values `COMMON` (white, default), `UNCOMMON` (yellow), `RARE` (aqua) and `EPIC` (light purple). Be aware that mods may add more rarity types.
+- `setNoRepair` - Disables anvil and crafting grid repairing for this item. Unused in vanilla.
+- `jukeboxPlayable` - Sets the resource key of the datapack `JukeboxSong` to play when inserted into a jukebox.
+- `food` - Sets the [`FoodProperties`][food] of this item (via `DataComponents#FOOD`).
+
+For examples, or to look at the various values used by Minecraft, have a look at the `Items` class.
+
+### Remainders and Cooldowns
+
+Items may have additional properties that are applied when being used or prevent the item from being used for a set time:
+
+- `craftRemainder` - Sets the crafting remainder of this item. Vanilla uses this for filled buckets that leave behind empty buckets after crafting.
+- `usingConvertsTo` - Sets the item to return after the item is finished being used via `Item#use`, `IItemExtension#finishUsingItem`, or `Item#releaseUsing`. The `ItemStack` is stored on `DataComponents#USE_REMAINDER`.
+- `useCooldown` - Sets the number of seconds before the item can be used again (via `DataComponents#USE_COOLDOWN`).
+
+### Tools and Armor
+
+Some items act like [tools] and [armor]. These are constructed via a series of item properties, with only some usage being delegated to their associated classes:
+
+- `enchantable` - Sets the maximum [enchantment] value of the stack, allowing the item to be enchanted (via `DataComponents#ENCHANTABLE`).
+- `repairable` - Sets the item or tag that can be used to repair the durability of this item (via `DataComponents#REPAIRABLE`). Must have durability components and not `DataComponents#UNBREAKABLE`.
+- `equippable` - Sets the slot the item can be equipped to (via `DataComponents#EQUIPPABLE`).
+- `equippableUnswappable` - Same as `equippable`, but disables quick swapping via the use item button (default right-click).
+
+More information can be found on their relevant pages.
+
+### More Functionality
+
+Directly using `Item` only allows for very basic items. If you want to add functionality, for example right-click interactions, a custom class that extends `Item` is required. The `Item` class has many methods that can be overridden to do different things; see the classes `Item` and `IItemExtension` for more information.
+
+The two most common use cases for items are left-clicking and right-clicking. For left-clicking, see [Breaking a Block][breaking] and Attacking an Entity (WIP). For right-clicking, see [The Interaction Pipeline][interactionpipeline].
+
+### `DeferredRegister.Items`
+
+All registries use `DeferredRegister` to register their contents, and items are no exceptions. However, due to the fact that adding new items is such an essential feature of an overwhelming amount of mods, NeoForge provides the `DeferredRegister.Items` helper class that extends `DeferredRegister<Item>` and provides some item-specific helpers:
+
+```java
+public static final DeferredRegister.Items ITEMS = DeferredRegister.createItems(ExampleMod.MOD_ID);
+
+public static final DeferredItem<Item> EXAMPLE_ITEM = ITEMS.registerItem(
+    "example_item",
+    Item::new, // The factory that the properties will be passed into.
+    new Item.Properties() // The properties to use.
+);
+```
+
+Internally, this will simply call `ITEMS.register("example_item", registryName -> new Item(new Item.Properties().setId(ResourceKey.create(Registries.ITEM, registryName))))` by applying the properties parameter to the provided item factory (which is commonly the constructor). The id is set on the properties.
+
+If you want to use `Item::new`, you can leave out the factory entirely and use the `simple` method variant:
+
+```java
+public static final DeferredItem<Item> EXAMPLE_ITEM = ITEMS.registerSimpleItem(
+    "example_item",
+    new Item.Properties() // The properties to use.
+);
+```
+
+This does the exact same as the previous example, but is slightly shorter. Of course, if you want to use a subclass of `Item` and not `Item` itself, you will have to use the previous method instead.
+
+Both of these methods also have overloads that omit the `new Item.Properties()` parameter:
+
+```java
+public static final DeferredItem<Item> EXAMPLE_ITEM = ITEMS.registerItem("example_item", Item::new);
+
+// Variant that also omits the Item::new parameter
+public static final DeferredItem<Item> EXAMPLE_ITEM = ITEMS.registerSimpleItem("example_item");
+```
+
+Finally, there's also shortcuts for block items. Along with `setId`, these also call `useBlockDescriptionPrefix` to set the translation key to the one used for a block:
+
+```java
+public static final DeferredItem<BlockItem> EXAMPLE_BLOCK_ITEM = ITEMS.registerSimpleBlockItem(
+    "example_block",
+    ExampleBlocksClass.EXAMPLE_BLOCK,
+    new Item.Properties()
+);
+
+// Variant that omits the properties parameter:
+public static final DeferredItem<BlockItem> EXAMPLE_BLOCK_ITEM = ITEMS.registerSimpleBlockItem(
+    "example_block",
+    ExampleBlocksClass.EXAMPLE_BLOCK
+);
+
+// Variant that omits the name parameter, instead using the block's registry name:
+public static final DeferredItem<BlockItem> EXAMPLE_BLOCK_ITEM = ITEMS.registerSimpleBlockItem(
+    // Must be an instance of `Holder<Block>`
+    // DeferredBlock<T> also works
+    ExampleBlocksClass.EXAMPLE_BLOCK,
+    new Item.Properties()
+);
+
+// Variant that omits both the name and the properties:
+public static final DeferredItem<BlockItem> EXAMPLE_BLOCK_ITEM = ITEMS.registerSimpleBlockItem(
+    // Must be an instance of `Holder<Block>`
+    // DeferredBlock<T> also works
+    ExampleBlocksClass.EXAMPLE_BLOCK
+);
+```
+
+:::note
+If you keep your registered blocks in a separate class, you should classload your blocks class before your items class.
+:::
+
+### Resources
+
+If you register your item and get your item (via `/give` or through a [creative tab][creativetabs]), you will find it to be missing a proper model and texture. This is because textures and models  are handled by Minecraft's resource system.
+
+To apply a simple texture to an item, you must add an item model JSON and a texture PNG. See the section on [resources][resources] for more information.
+
+## `ItemStack`s
+
+Like with blocks and blockstates, most places where you'd expect an `Item` actually use an `ItemStack` instead. `ItemStack`s represent a stack of one or multiple items in a container, e.g. an inventory. Again like with blocks and blockstates, methods should be overridden by the `Item` and called on the `ItemStack`, and many methods in `Item` get an `ItemStack` instance passed in.
+
+An `ItemStack` consists of three major parts:
+
+- The `Item` it represents, obtainable through `ItemStack#getItem`, or `getItemHolder` for `Holder<Item>`.
+- The stack size, typically between 1 and 64, obtainable through `getCount` and changeable through `setCount` or `shrink`.
+- The [data components][datacomponents] map, where stack-specific data is stored. Obtainable through `getComponents`. The components values are typically accessed and mutated via `has`, `get`, `set`, `update`, and `remove`.
+
+To create a new `ItemStack`, call `new ItemStack(Item)`, passing in the backing item. By default, this uses a count of 1 and no NBT data; there are constructor overloads that accept a count and NBT data as well if needed.
+
+`ItemStack`s are mutable objects (see below), however it is sometimes required to treat them as immutables. If you need to modify an `ItemStack` that is to be treated immutable, you can clone the stack using `#copy` or `#copyWithCount` if a specific stack size should be used.
+
+If you want to represent that a stack has no item, use `ItemStack.EMPTY`. If you want to check whether an `ItemStack` is empty, call `#isEmpty`.
+
+### Mutability of `ItemStack`s
+
+`ItemStack`s are mutable objects. This means that if you call for example `#setCount` or any data component map methods, the `ItemStack` itself will be modified. Vanilla uses the mutability of `ItemStack`s extensively, and several methods rely on it. For example, `#split` splits the given amount off the stack it is called on, both modifying the caller and returning a new `ItemStack` in the process.
+
+However, this can sometimes lead to issues when dealing with multiple `ItemStack`s at once. The most common instance where this arises is when handling inventory slots, since you have to consider both the `ItemStack` currently selected by the cursor, as well as the `ItemStack` you are trying to insert to/extract from.
+
+:::tip
+When in doubt, better be safe than sorry and `#copy` the stack.
+:::
+
+### JSON Representation
+
+In many situations, for example [recipes], item stacks need to be represented as JSON objects. An item stack's JSON representation looks the following way:
+
+```json5
+{
+    // The item ID. Required.
+    "id": "minecraft:dirt",
+    // The item stack count [1, 99]. Optional, defaults to 1.
+    "count": 4,
+    // A map of data components. Optional, defaults to an empty map.
+    "components": {
+        "minecraft:enchantment_glint_override": true
+    }
+}
+```
+
+## Creative Tabs
+
+By default, your item will only be available through `/give` and not appear in the creative inventory. Let's change that!
+
+The way you get your item into the creative menu depends on what tab you want to add it to.
+
+### Existing Creative Tabs
+
+:::note
+This method is for adding your items to Minecraft's tabs, or to other mods' tabs. To add items to your own tabs, see below.
+:::
+
+An item can be added to an existing `CreativeModeTab` via the `BuildCreativeModeTabContentsEvent`, which is fired on the [mod event bus][modbus], only on the [logical client][sides]. Add items by calling `event#accept`.
+
+```java
+//MyItemsClass.MY_ITEM is a Supplier<? extends Item>, MyBlocksClass.MY_BLOCK is a Supplier<? extends Block>
+@SubscribeEvent
+public static void buildContents(BuildCreativeModeTabContentsEvent event) {
+    // Is this the tab we want to add to?
+    if (event.getTabKey() == CreativeModeTabs.INGREDIENTS) {
+        event.accept(MyItemsClass.MY_ITEM.get());
+        // Accepts an ItemLike. This assumes that MY_BLOCK has a corresponding item.
+        event.accept(MyBlocksClass.MY_BLOCK.get());
+    }
+}
+```
+
+The event also provides some extra information, such as `getFlags` to get the list of enabled feature flags, or `hasPermissions` to check if the player has permissions to view the operator items tab.
+
+### Custom Creative Tabs
+
+`CreativeModeTab`s are a registry, meaning custom `CreativeModeTab`s must be [registered][registering]. Creating a creative tab uses a builder system, the builder is obtainable through `CreativeModeTab#builder`. The builder provides options to set the title, icon, default items, and a number of other properties. In addition, NeoForge provides additional methods to customize the tab's image, label and slot colors, where the tab should be ordered, etc.
+
+```java
+//CREATIVE_MODE_TABS is a DeferredRegister<CreativeModeTab>
+public static final Supplier<CreativeModeTab> EXAMPLE_TAB = CREATIVE_MODE_TABS.register("example", () -> CreativeModeTab.builder()
+    //Set the title of the tab. Don't forget to add a translation!
+    .title(Component.translatable("itemGroup." + MOD_ID + ".example"))
+    //Set the icon of the tab.
+    .icon(() -> new ItemStack(MyItemsClass.EXAMPLE_ITEM.get()))
+    //Add your items to the tab.
+    .displayItems((params, output) -> {
+        output.accept(MyItemsClass.MY_ITEM.get());
+        // Accepts an ItemLike. This assumes that MY_BLOCK has a corresponding item.
+        output.accept(MyBlocksClass.MY_BLOCK.get());
+    })
+    .build()
+);
+```
+
+## `ItemLike`
+
+`ItemLike` is an interface implemented by `Item`s and [`Block`s][block] in vanilla. It defines the method `#asItem`, which returns an item representation of whatever the object actually is: `Item`s just return themselves, while `Block`s return their associated `BlockItem` if available, and `Blocks.AIR` otherwise. `ItemLike`s are used in various contexts where the "origin" of the item isn't important, for example in many [data generators][datagen].
+
+It is also possible to implement `ItemLike` on your custom objects. Simply override `#asItem` and you're good to go.
+
+[armor]: armor.md
+[block]: ../blocks/index.md
+[blockstates]: ../blocks/states.md
+[breaking]: ../blocks/index.md#breaking-a-block
+[creativetabs]: #creative-tabs
+[datacomponents]: datacomponents.md
+[datagen]: ../resources/index.md#data-generation
+[enchantment]: ../resources/server/enchantments/index.md#enchantment-costs-and-levels
+[food]: consumables.md#food
+[interactionpipeline]: interactionpipeline.md
+[loottables]: ../resources/server/loottables/index.md
+[modbus]: ../concepts/events.md#event-buses
+[recipes]: ../resources/server/recipes/index.md
+[registering]: ../concepts/registries.md#methods-for-registering
+[resources]: ../resources/index.md#assets
+[sides]: ../concepts/sides.md
+[tools]: tools.md
diff --git a/versioned_docs/version-1.21.3/items/interactionpipeline.md b/versioned_docs/version-1.21.3/items/interactionpipeline.md
new file mode 100644
index 00000000..1c3a3112
--- /dev/null
+++ b/versioned_docs/version-1.21.3/items/interactionpipeline.md
@@ -0,0 +1,75 @@
+---
+sidebar_position: 1
+---
+# The Interaction Pipeline
+
+This page aims to make the fairly complex and confusing process of things being right-clicked by the player more understandable, as well as clarifying what result to use where and why.
+
+## What Happens When I Right-Click?
+
+When you right-click anywhere in the world, a number of things happen, depending on what you are currently looking at and what `ItemStack`s are in your hands. A number of methods returning one of two result types (see below) are called. Most of these methods cancel the pipeline if an explicit success or an explicit failure is returned. For the sake of readability, this "explicit success or explicit failure" will be called a "definitive result" from now on.
+
+- `InputEvent.InteractionKeyMappingTriggered` is fired with the right mouse button and the main hand. If the event is canceled, the pipeline ends.
+- Several circumstances are checked, for example that you are not in spectator mode or that all required feature flags for the `ItemStack` in your main hand are enabled. If at least one of these checks fails, the pipeline ends.
+- Depending on what you are looking at, different things happen:
+    - If you are looking at an entity that is within your reach and not outside the world border:
+        - `PlayerInteractEvent.EntityInteractSpecific` is fired. If the event is canceled, the pipeline ends.
+        - `Entity#interactAt` will be called **on the entity you are looking at**. If it returns a definitive result, the pipeline ends.
+            - If you want to add behavior for your own entity, override this method. If you want to add behavior for a vanilla entity, use the event.
+        - If the entity opens an interface (for example a villager trading GUI or a chest minecart GUI), the pipeline ends.
+        - `PlayerInteractEvent.EntityInteract` is fired. If the event is canceled, the pipeline ends.
+        - `Entity#interact` is called **on the entity you are looking at**. If it returns a definitive result, the pipeline ends.
+            - If you want to add behavior for your own entity, override this method. If you want to add behavior for a vanilla entity, use the event.
+            - For `Mob`s, the override of `Entity#interact` handles things like leashing and spawning babies when the `ItemStack` in your main hand is a spawn egg, and then defers mob-specific handling to `Mob#mobInteract`. The rules for results for `Entity#interact` apply here as well.
+        - If the entity you are looking at is a `LivingEntity`, `Item#interactLivingEntity` is called on the `ItemStack` in your main hand. If it returns a definitive result, the pipeline ends.
+    - If you are looking at a block that is within your reach and not outside the world border:
+        - `PlayerInteractEvent.RightClickBlock` is fired. If the event is canceled, the pipeline ends. You may also specifically deny only block or item usage in this event.
+        - `IItemExtension#onItemUseFirst` is called. If it returns a definitive result, the pipeline ends.
+        - If the player is not sneaking and the event does not deny block usage, `UseItemOnBlockEvent` is fired. If the event is canceled, the cancellation result is used. Otherwise, `Block#useItemOn` is called. If it returns a definitive result, the pipeline ends.
+        - If the `InteractionResult` is `TRY_WITH_EMPTY_HAND` and the executing hand is the main hand, then `Block#useWithoutItem` is called. If it returns a definitive result, the pipeline ends.
+        - If the event does not deny item usage, `Item#useOn` is called. If it returns a definitive result, the pipeline ends.
+- `Item#use` is called. If it returns a definitive result, the pipeline ends.
+- The above process runs a second time, this time with the off hand instead of the main hand.
+
+## `InteractionResult`
+
+`InteractionResult` is a sealed interface that respresents the result of some interaction between an item or an empty hand and some object (e.g. entities, blocks, etc.). The interface is broken into four records, where there are six potential default states.
+
+First there is `InteractionResult.Success`, which indicates that the operation should be considered sucessful, ending the pipeline. A successful state has two parameters: the `SwingSource`, which indicates whether the entity should swing on the respective [logical side][side]; and the `InteractionResult.ItemContext`, which holds whether the interaction was caused by a held item, and what the held item transformed into after use. The swing source is determined by one of the default states: `InteractionResult#SUCCESS` for client swing, `InteractionResult#SUCCESS_SERVER` for server swing, and `InteractionResult#CONSUME` for no swing. The item context is set via `Success#heldItemTransformedTo` if the `ItemStack` changed, or `withoutItem` if there wasn't an interaction between the held item and the object. The default sets there was an item interaction but no transformation.
+
+```java
+// In some method that returns an interaction result
+
+// Item in hand will turn into an apple
+return InteractionResult.SUCCESS.heldItemTransformedTo(new ItemStack(Items.APPLE));
+```
+
+:::note
+`SUCCESS` and `SUCCESS_SERVER` should generally never be used in the same method. If the client has enough information to determine when to swing, then `SUCCESS` should always be used. Otherwise, if it relies on server information not present on the client, `SUCCESS_SERVER` should be used.
+:::
+
+Then there is `InteractionResult.Fail`, implemented by `InteractionResult#FAIL`, which indicates that the operation should be considered failed, allowing no further interaction to occur. The pipeline will end. This can be used anywhere, but it should be used with care outside of `Item#useOn` and `Item#use`. In many cases, using `InteractionResult#PASS` makes more sense.
+
+Finally, there is `InteractionResult.Pass` and `InteractionResult.TryWithEmptyHandInteraction`, implemented by `InteractionResult#PASS` and `InteractionResult#TRY_WITH_EMPTY_HAND` respectively. These records indicate when an operation should be considered neither successful or failed, and the pipeline should continue. `PASS` is the default behavior for all `InteractionResult` methods except `BlockBehaviour#useItemOn`, which returns `TRY_WITH_EMPTY_HAND`. More specifically, if `BlockBehaviour#useItemOn` returns anything but `TRY_WITH_EMPTY_HAND`, `BlockBehaviour#useWithoutItem` will not be called regardless of if the item is in the main hand.
+
+Some methods have special behavior or requirements, which are explained in the below chapters.
+
+## `Item#useOn`
+
+If you want the operation to be considered successful, but you do not want the arm to swing or an `ITEM_USED` stat point to be awarded, use `InteractionResult#CONSUME` and calling `#withoutItem`.
+
+```java
+// In Item#useOn
+return InteractionResult.CONSUME.withoutItem();
+```
+
+## `Item#use`
+
+This is the only instance where the transformed `ItemStack` is used from a `Success` variant (`SUCCESS`, `SUCCESS_SERVER`, `CONSUME`). The resulting `ItemStack` set by `Success#heldItemTransformedTo` replaces the `ItemStack` the usage was initiated with, if it has changed.
+
+The default implementation of `Item#use` returns `InteractionResult#CONSUME` when the item is edible (has `DataComponents#CONSUMABLE`) and the player can eat the item (because they are hungry, or because the item is always edible) and `InteractionResult#FAIL` when the item is edible (has `DataComponents#CONSUMABLE`) but the player cannot eat the item. If the item is equippable (has `DataComponents#EQUIPPABLE`), then it returns `InteractionResult#SUCCESS` on swap with the held item replaced by the swaped item (via `heldItemTransformedTo`), or `InteractionResult#FAIL` if the enchantment on the armor has the `EnchantmentEffectComponents#PREVENT_ARMOR_CHANGE` component. Otherwise `InteractionResult#PASS` is returned.
+
+Returning `InteractionResult#FAIL` here while considering the main hand will prevent offhand behavior from running. If you want offhand behavior to run (which you usually want), return `InteractionResult#PASS` instead.
+
+[itemuseon]: #itemuseon
+[side]: ../concepts/sides.md#the-logical-side
diff --git a/versioned_docs/version-1.21.3/items/mobeffects.md b/versioned_docs/version-1.21.3/items/mobeffects.md
new file mode 100644
index 00000000..9e146932
--- /dev/null
+++ b/versioned_docs/version-1.21.3/items/mobeffects.md
@@ -0,0 +1,204 @@
+---
+sidebar_position: 6
+---
+# Mob Effects & Potions
+
+Status effects, sometimes known as potion effects and referred to in-code as `MobEffect`s, are effects that influence an entity every tick. This article explains how to use them, what the difference between an effect and a potion is, and how to add your own.
+
+## Terminology
+
+- A `MobEffect` affects an entity every tick. Like [blocks][block] or [items][item], `MobEffect`s are registry objects, meaning they must be [registered][registration] and are singletons.
+    - An **instant mob effect** is a special kind of mob effect that is designed to be applied for one tick. Vanilla has two instant effects, Instant Health and Instant Harming.
+- A `MobEffectInstance` is an instance of a `MobEffect`, with a duration, amplifier and some other properties set (see below). `MobEffectInstance`s are to `MobEffect`s what [`ItemStack`s][itemstack] are to `Item`s.
+- A `Potion` is a collection of `MobEffectInstance`s. Vanilla mainly uses potions for the four potion items (read on), however, they can be applied to any item at will. It is up to the item if and how the item then uses the potion set on it.
+- A **potion item** is an item that is meant to have a potion set on it. This is an informal term, the vanilla `PotionItem` class has nothing to do with this (it refers to the "normal" potion item). Minecraft currently has four potion items: potions, splash potions, lingering potions, and tipped arrows; however more may be added by mods.
+
+## `MobEffect`s
+
+To create your own `MobEffect`, extend the `MobEffect` class:
+
+```java
+public class MyMobEffect extends MobEffect {
+    public MyMobEffect(MobEffectCategory category, int color) {
+        super(category, color);
+    }
+    
+    @Override
+    public boolean applyEffectTick(LivingEntity entity, int amplifier) {
+        // Apply your effect logic here.
+
+        // If this returns false when shouldApplyEffectTickThisTick returns true, the effect will immediately be removed
+        return true;
+    }
+    
+    // Whether the effect should apply this tick. Used e.g. by the Regeneration effect that only applies
+    // once every x ticks, depending on the tick count and amplifier.
+    @Override
+    public boolean shouldApplyEffectTickThisTick(int tickCount, int amplifier) {
+        return tickCount % 2 == 0; // replace this with whatever check you want
+    }
+    
+    // Utility method that is called when the effect is first added to the entity.
+    // This does not get called again until all instances of this effect have been removed from the entity.
+    @Override
+    public void onEffectAdded(LivingEntity entity, int amplifier) {
+        super.onEffectAdded(entity, amplifier);
+    }
+
+    // Utility method that is called when the effect is added to the entity.
+    // This gets called every time this effect is added to the entity.
+    @Override
+    public void onEffectStarted(LivingEntity entity, int amplifier) {
+    }
+}
+```
+
+Like all registry objects, `MobEffect`s must be [registered][registration], like so:
+
+```java
+// MOB_EFFECTS is a DeferredRegister<MobEffect>
+public static final Holder<MobEffect> MY_MOB_EFFECT = MOB_EFFECTS.register("my_mob_effect", () -> new MyMobEffect(
+        //Can be either BENEFICIAL, NEUTRAL or HARMFUL. Used to determine the potion tooltip color of this effect.
+        MobEffectCategory.BENEFICIAL,
+        //The color of the effect particles in RGB format.
+        0xffffff
+));
+```
+
+The `MobEffect` class also provides default functionality for adding attribute modifiers to affected entities. For example, the speed effect adds an attribute modifier for movement speed. Effect attribute modifiers are added like so:
+
+```java
+public static final Holder<MobEffect> MY_MOB_EFFECT = MOB_EFFECTS.register("my_mob_effect", () -> new MyMobEffect(...)
+        .addAttributeModifier(Attributes.ATTACK_DAMAGE, ResourceLocation.fromNamespaceAndPath("examplemod", "effect.strength"), 2.0, AttributeModifier.Operation.ADD_VALUE)
+);
+```
+
+### `InstantenousMobEffect`
+
+If you want to create an instant effect, you can use the helper class `InstantenousMobEffect` instead of the regular `MobEffect` class, like so:
+
+```java
+public class MyMobEffect extends InstantenousMobEffect {
+    public MyMobEffect(MobEffectCategory category, int color) {
+        super(category, color);
+    }
+
+    @Override
+    public void applyEffectTick(LivingEntity entity, int amplifier) {
+        // Apply your effect logic here.
+    }
+}
+```
+
+Then, [register][registration] your effect like normal.
+
+### Events
+
+Many effects have their logic applied in other places. For example, the levitation effect is applied in the living entity movement handler. For modded `MobEffect`s, it often makes sense to apply them in an [event handler][events]. NeoForge also provides a few events related to effects:
+
+- `MobEffectEvent.Applicable` is fired when the game checks whether a `MobEffectInstance` can be applied to an entity. This event can be used to deny or force adding the effect instance to the target.
+- `MobEffectEvent.Added` is fired when the `MobEffectInstance` is added to the target. This event contains information about a previous `MobEffectInstance` that may have been present on the target.
+- `MobEffectEvent.Expired` is fired when the `MobEffectInstance` expires, i.e. the timer goes to zero.
+- `MobEffectEvent.Remove` is fired when the effect is removed from the entity through means other than expiring, e.g. through drinking milk or via commands.
+
+## `MobEffectInstance`s
+
+A `MobEffectInstance` is, simply put, an effect applied to an entity. Creating a `MobEffectInstance` is done by calling the constructor:
+
+```java
+MobEffectInstance instance = new MobEffectInstance(
+        // The mob effect to use.
+        MobEffects.REGENERATION,
+        // The duration to use, in ticks. Defaults to 0 if not specified.
+        500,
+        // The amplifier to use. This is the "strength" of the effect, i.e. Strength I, Strength II, etc.
+        // Must be between 0 and 255 (inclusive). Defaults to 0 if not specified.
+        0,
+        // Whether the effect is an "ambient" effect, meaning it is being applied by an ambient source,
+        // of which Minecraft currently has the beacon and the conduit. Defaults to false if not specified.
+        false,
+        // Whether the effect is visible in the inventory. Defaults to true if not specified.
+        true,
+        // Whether an effect icon is visible in the top right corner. Defaults to true if not specified.
+        true
+);
+```
+
+Several constructor overloads are available, omitting the last 1-5 parameters, respectively.
+
+:::info
+`MobEffectInstance`s are mutable. If you need a copy, call `new MobEffectInstance(oldInstance)`.
+:::
+
+### Using `MobEffectInstance`s
+
+A `MobEffectInstance` can be added to a `LivingEntity` like so:
+
+```java
+MobEffectInstance instance = new MobEffectInstance(...);
+livingEntity.addEffect(instance);
+```
+
+Similarly, `MobEffectInstance` can also be removed from an `LivingEntity`. Since a `MobEffectInstance` overwrites pre-existing `MobEffectInstance`s of the same `MobEffect` on the entity, there can only ever be one `MobEffectInstance` per `MobEffect` and entity. As such, specifying the `MobEffect` suffices when removing:
+
+```java
+livingEntity.removeEffect(MobEffects.REGENERATION);
+```
+
+:::info
+`MobEffect`s can only be applied to `LivingEntity` or its subclasses, i.e. players and mobs. Things like items or thrown snowballs cannot be affected by `MobEffect`s.
+:::
+
+## `Potion`s
+
+`Potion`s are created by calling the constructor of `Potion` with the `MobEffectInstance`s you want the potion to have. For example:
+
+```java
+//POTIONS is a DeferredRegister<Potion>
+public static final Holder<Potion> MY_POTION = POTIONS.register("my_potion", registryName -> new Potion(
+    // The suffix applied to the potion
+    registryName.getPath(),
+    // The effects used by the potion
+    new MobEffectInstance(MY_MOB_EFFECT, 3600)
+));
+```
+
+The name of the potion is the first constructor argument. It is used as the suffix for a translation key; for example, the long and strong potion variants in vanilla use this to have the same names as their base variant.
+
+The `MobEffectInstance` parameter of `new Potion` is a vararg. This means that you can add as many effects as you want to the potion. This also means that it is possible to create empty potions, i.e. potions that don't have any effects. Simply call `new Potion()` and you're done! (This is how vanilla adds the `awkward` potion, by the way.)
+
+The `PotionContents` class offers various helper methods related to potion items. Potion item store their `PotionContents` via `DataComponent#POTION_CONTENTS`.
+
+### Brewing
+
+Now that your potion is added, potion items are available for your potion. However, there is no way to obtain your potion in survival, so let's change that!
+
+Potions are traditionally made in the Brewing Stand. Unfortunately, Mojang does not provide [datapack][datapack] support for brewing recipes, so we have to be a little old-fashioned and add our recipes through code via the `RegisterBrewingRecipesEvent` event. This is done like so:
+
+```java
+// Using some method to listen to the event
+@SubscribeEvent
+public static void registerBrewingRecipes(RegisterBrewingRecipesEvent event) {
+    // Gets the builder to add recipes to
+    PotionBrewing.Builder builder = event.getBuilder();
+
+    // Will add brewing recipes for all container potions (e.g. potion, splash potion, lingering potion)
+    builder.addMix(
+        // The initial potion to apply to
+        Potions.AWKWARD,
+        // The brewing ingredient. This is the item at the top of the brewing stand.
+        Items.FEATHER,
+        // The resulting potion
+        MY_POTION
+    );
+}
+```
+
+[block]: ../blocks/index.md
+[commonsetup]: ../concepts/events.md#event-buses
+[datapack]: ../resources/index.md#data
+[events]: ../concepts/events.md
+[item]: index.md
+[itemstack]: index.md#itemstacks
+[registration]: ../concepts/registries.md#methods-for-registering
+[uuidgen]: https://www.uuidgenerator.net/version4
diff --git a/versioned_docs/version-1.21.3/items/tools.md b/versioned_docs/version-1.21.3/items/tools.md
new file mode 100644
index 00000000..67d76b22
--- /dev/null
+++ b/versioned_docs/version-1.21.3/items/tools.md
@@ -0,0 +1,175 @@
+---
+sidebar_position: 4
+---
+# Tools
+
+Tools are [items][item] whose primary use is to break [blocks][block]. Many mods add new tool sets (for example copper tools) or new tool types (for example hammers).
+
+## Custom Tool Sets
+
+A tool set typically consists of five items: a pickaxe, an axe, a shovel, a hoe and a sword. (Swords aren't tools in the classical sense, but are included here for consistency as well.) All of those items have their corresponding class: `PickaxeItem`, `AxeItem`, `ShovelItem`, `HoeItem` and `SwordItem`, respectively. The class hierarchy of tools looks as follows:
+
+```text
+Item
+- DiggerItem
+    - AxeItem
+    - HoeItem
+    - PickaxeItem
+    - ShovelItem
+- SwordItem
+```
+
+Tools are almost completely implemented through seven [data components][datacomponents]:
+
+- `DataComponents#MAX_DAMAGE` and `#DAMAGE` for durability
+- `#MAX_STACK_SIZE` to set the stack size to `1`
+- `#REPAIRABLE` for reepairing a tool in an anvil
+- `#ENCHANTABLE` for the maximum [enchanting][enchantment] value
+- `#ATTRIBUTE_MODIFIERS` for attack damage and attack speed
+- `#TOOL` for mining information
+
+For `DiggerItem` and `SwordItem`, they are simply delegates that set up the components via the utility record `ToolMaterial`. Note that other items usually considered tools, such as shears, are not included in this hierarchy. Instead, they directly extend `Item` and hold the breaking logic themselves.
+
+To create a standard set of tools using a `DiggerItem` or `SwordItem`, you must first define a `ToolMaterial`. Reference values can be found within the constants in `ToolMaterial`. This example uses copper tools, you can use your own material here and adjust the values as needed.
+
+```java
+// We place copper somewhere between stone and iron.
+public static final ToolMaterial COPPER_MATERIAL = new ToolMaterial(
+        // The tag that determines what blocks this material cannot break. See below for more information.
+        MyBlockTags.INCORRECT_FOR_COPPER_TOOL,
+        // Determines the durability of the material.
+        // Stone is 131, iron is 250.
+        200,
+        // Determines the mining speed of the material. Unused by swords.
+        // Stone uses 4, iron uses 6.
+        5f,
+        // Determines the attack damage bonus. Different tools use this differently. For example, swords do (getAttackDamageBonus() + 4) damage.
+        // Stone uses 1, iron uses 2, corresponding to 5 and 6 attack damage for swords, respectively; our sword does 5.5 damage now.
+        1.5f,
+        // Determines the enchantability of the material. This represents how good the enchantments on this tool will be.
+        // Gold uses 22, we put copper slightly below that.
+        20,
+        // The tag that determines what items can repair this material.
+        Tags.Items.INGOTS_COPPER
+);
+```
+
+Now that we have our `ToolMaterial`, we can use it for [registering] tools. All tool constructors have the same four parameters.
+
+```java
+// ITEMS is a DeferredRegister.Items
+public static final DeferredItem<SwordItem> COPPER_SWORD = ITEMS.registerItem(
+    "copper_sword",
+    props -> new SwordItem(
+        // The material to use.
+        COPPER_MATERIAL,
+        // The type-specific attack damage bonus. 3 for swords, 1.5 for shovels, 1 for pickaxes, varying for axes and hoes.
+        3,
+        // The type-specific attack speed modifier. The player has a default attack speed of 4, so to get to the desired
+        // value of 1.6f, we use -2.4f. -2.4f for swords, -3f for shovels, -2.8f for pickaxes, varying for axes and hoes.
+        -2.4f,
+        // The item properties.
+        props
+    )
+);
+
+public static final DeferredItem<AxeItem> COPPER_AXE = ITEMS.registerItem("copper_axe", props -> new AxeItem(...));
+public static final DeferredItem<PickaxeItem> COPPER_PICKAXE = ITEMS.registerItem("copper_pickaxe", props -> new PickaxeItem(...));
+public static final DeferredItem<ShovelItem> COPPER_SHOVEL = ITEMS.registerItem("copper_shovel", props -> new ShovelItem(...));
+public static final DeferredItem<HoeItem> COPPER_HOE = ITEMS.registerItem("copper_hoe", props -> new HoeItem(...));
+```
+
+### Tags
+
+When creating a `ToolMaterial`, it is assigned a block [tag][tags] containing blocks that will not drop anything if broken with this tool. For example, the `minecraft:incorrect_for_stone_tool` tag contains blocks like Diamond Ore, and the `minecraft:incorrect_for_iron_tool` tag contains blocks like Obsidian and Ancient Debris. To make it easier to assign blocks to their incorrect mining levels, a tag also exists for blocks that need this tool to be mined. For example, the `minecraft:needs_iron_tool` tag contains blocks like Diamond Ore, and the `minecraft:needs_diamond_tool` tag contains blocks like Obsidian and Ancient Debris.
+
+You can reuse one of the incorrect tags for your tool if you're fine with that. For example, if we wanted our copper tools to just be more durable stone tools, we'd pass in `BlockTags#INCORRECT_FOR_STONE_TOOL`.
+
+Alternatively, we can create our own tag, like so:
+
+```java
+// This tag will allow us to add these blocks to the incorrect tags that cannot mine them
+public static final TagKey<Block> NEEDS_COPPER_TOOL = TagKey.create(BuiltInRegistries.BLOCK.key(), ResourceLocation.fromNamespaceAndPath(MOD_ID, "needs_copper_tool"));
+
+// This tag will be passed into our material
+public static final TagKey<Block> INCORRECT_FOR_COPPER_TOOL = TagKey.create(BuiltInRegistries.BLOCK.key(), ResourceLocation.fromNamespaceAndPath(MOD_ID, "incorrect_for_cooper_tool"));
+```
+
+And then, we populate our tag. For example, let's make copper able to mine gold ores, gold blocks and redstone ore, but not diamonds or emeralds. (Redstone blocks are already mineable by stone tools.) The tag file is located at `src/main/resources/data/mod_id/tags/block/needs_copper_tool.json` (where `mod_id` is your mod id):
+
+```json5
+{
+    "values": [
+        "minecraft:gold_block",
+        "minecraft:raw_gold_block",
+        "minecraft:gold_ore",
+        "minecraft:deepslate_gold_ore",
+        "minecraft:redstone_ore",
+        "minecraft:deepslate_redstone_ore"
+    ]
+}
+```
+
+Then, for our tag to pass into the material, we can provide a negative constraint for any tools that are incorrect for stone tools but within our copper tools tag. The tag file is located at `src/main/resources/data/mod_id/tags/block/incorrect_for_cooper_tool.json`:
+
+```json5
+{
+    "values": [
+        "#minecraft:incorrect_for_stone_tool"
+    ],
+    "remove": [
+        "#mod_id:needs_copper_tool"
+    ]
+}
+```
+
+Finally, we can pass our tag into our material instance, as seen above.
+
+If you want to check if a tool can make a block state drop its blocks, call `Tool#isCorrectForDrops`. The `Tool` can be obtained by calling `ItemStack#get` with `DataComponents#TOOL`.
+
+## Custom Tools
+
+Custom tools can be created by adding a `Tool` [data component][datacomponents] (via `DataComponents#TOOL`) to the list of default components on your item via `Item.Properties#component`. `DiggerItem` is an implementation which takes in a `ToolMaterial`, as explained above, to construct the `Tool`, along with a few other basic components such as attributes and durability.
+
+A `Tool` contains a list of `Tool.Rule`s, the default mining speed when holding the tool (`1` by default), and the amount of damage the tool should take when mining a block (`1` by default). A `Tool.Rule` contains three pieces of information: a `HolderSet` of blocks to apply the rule to, an optional speed at which to mine the blocks in the set, and an optional boolean at which to determine whether these blocks can drop from this tool. If the optional are not set, then the other rules will be checked. The default behavior if all rules fail is the default mining speed and that the block cannot be dropped.
+
+:::note
+A `HolderSet` can be created from a `TagKey` via `Registry#getOrThrow`.
+:::
+
+Creating any tool or multitool-like item (i.e. an item that combines two or more tools into one, e.g. an axe and a pickaxe as one item) does not need to extend any of the existing `DiggerItem`s or `SwordItem`. It simply can be implemented using a combination of the following parts:
+
+- Adding a `Tool` with your own rules by setting `DataComponents#TOOL` via `Item.Properties#component`.
+- Adding attributes to the item (e.g. attack damage, attack speed) via `Item.Properties#attributes`.
+- Adding item durability via `Item.Properties#durability`.
+- Allowing the item to be repaired via `Item.Properties#repariable`.
+- Allowing the item to be enchanted via `Item.Properties#enchantable`.
+- Overriding `IItemExtension#canPerformAction` to determine what [`ItemAbility`s][itemability] the item can perform.
+- Calling `IBlockExtension#getToolModifiedState` if you want your item to modify the block state on right click based on the `ItemAbility`s.
+- Adding your tool to some of the `minecraft:enchantable/*` `ItemTags` so that your item can have certain enchantments applied to it.
+
+:::note
+The only logic that has no alternative to using a `DiggerItem` or `SwordItem` base is when mobs replace their current held item via `Mob#canReplaceCurrentItem`. Mobs will always check for an instance of `SwordItem`, followed by `BowItem`, `CrossbowItem`, `ArmorItem`, and `DiggerItem`, with all other items not considered for specialized logic.
+:::
+
+## `ItemAbility`s
+
+`ItemAbility`s are an abstraction over what an item can and cannot do. This includes both left-click and right-click behavior. NeoForge provides default `ItemAbility`s in the `ItemAbilities` class:
+
+- Digging abilities. These exist for all four `DiggerItem` types as mentioned above, as well as sword and shears digging.
+- Axe right-click abilities for stripping (logs), scraping (oxidized copper), and unwaxing (waxed copper).
+- Shovel right-click abilities for flattening (dirt paths) and dousing (campfires).
+- Shear abilities for harvesting (honeycombs), removing armor (armored wolves), carving (pumpkins), disarming (tripwires), and trimming (stop plants from growing).
+- Abilities for sword sweeping, hoe tilling, shield blocking, fishing rod casting, trident throwing, brush brushing, and firestarter lighting.
+
+To create your own `ItemAbility`s, use `ItemAbility#get` - it will create a new `ItemAbility` if needed. Then, in a custom tool type, override `IItemExtension#canPerformAction` as needed.
+
+To query if an `ItemStack` can perform a certain `ItemAbility`, call `IItemStackExtension#canPerformAction`. Note that this works on any `Item`, not just tools.
+
+[block]: ../blocks/index.md
+[datacomponents]: datacomponents.md
+[enchantment]: ../resources/server/enchantments/index.md#enchantment-costs-and-levels
+[item]: index.md
+[itemability]: #itemabilitys
+[registering]: ../concepts/registries.md#methods-for-registering
+[tags]: ../resources/server/tags.md
diff --git a/versioned_docs/version-1.21.3/legacy/_category_.json b/versioned_docs/version-1.21.3/legacy/_category_.json
new file mode 100644
index 00000000..3a78b370
--- /dev/null
+++ b/versioned_docs/version-1.21.3/legacy/_category_.json
@@ -0,0 +1,4 @@
+{
+    "label": "Legacy",
+    "position": 14
+}
\ No newline at end of file
diff --git a/versioned_docs/version-1.21.3/legacy/porting.md b/versioned_docs/version-1.21.3/legacy/porting.md
new file mode 100644
index 00000000..ceccede9
--- /dev/null
+++ b/versioned_docs/version-1.21.3/legacy/porting.md
@@ -0,0 +1,31 @@
+# Porting to Minecraft 1.21.3
+
+Here you can find a list of primers on how to port from old versions to the current version. Some versions are lumped together since that particular version never saw much usage.
+
+|    From -> To      |               Primer                    |
+|:------------------:|:----------------------------------------|
+| 1.12 -> 1.13/1.14  | [Primer by williewillus][112to114]      |
+| 1.14 -> 1.15       | [Primer by williewillus][114to115]      |
+| 1.15 -> 1.16       | [Primer by 50ap5ud5][115to116]          |
+| 1.16 -> 1.17       | [Primer by 50ap5ud5][116to117]          |
+| 1.19.2 -> 1.19.3   | [Primer by ChampionAsh5357][1192to1193] |
+| 1.19.3 -> 1.19.4   | [Primer by ChampionAsh5357][1193to1194] |
+| 1.19.4 -> 1.20     | [Primer by ChampionAsh5357][1194to120]  |
+| 1.20.4 -> 1.20.5   | [Primer by ChampionAsh5357][1204to1205] |
+| 1.20.5 -> 1.20.6   | [Primer by ChampionAsh5357][1205to1206] |
+| 1.20.6 -> 1.21     | [Primer by ChampionAsh5357][1206to121]  |
+| 1.21   -> 1.21.1   | [Primer by ChampionAsh5357][121to1211]  |
+| 1.21.1 -> 1.21.2/3 | [Primer by ChampionAsh5357][1211to1212] |
+
+[112to114]: https://gist.github.com/williewillus/353c872bcf1a6ace9921189f6100d09a
+[114to115]: https://gist.github.com/williewillus/30d7e3f775fe93c503bddf054ef3f93e
+[115to116]: https://gist.github.com/50ap5ud5/f4e70f0e8faeddcfde6b4b1df70f83b8
+[116to117]: https://gist.github.com/50ap5ud5/beebcf056cbdd3c922cc8993689428f4
+[1192to1193]: https://github.com/neoforged/.github/blob/main/primers/1.19.3/index.md
+[1193to1194]: https://github.com/neoforged/.github/blob/main/primers/1.19.4/index.md
+[1194to120]: https://github.com/neoforged/.github/blob/main/primers/1.20/index.md
+[1204to1205]: https://github.com/neoforged/.github/blob/main/primers/1.20.5/index.md
+[1205to1206]: https://github.com/neoforged/.github/blob/main/primers/1.20.6/index.md
+[1206to121]: https://github.com/neoforged/.github/blob/main/primers/1.21/index.md
+[121to1211]: https://github.com/neoforged/.github/blob/main/primers/1.21.1/index.md
+[1211to1212]: https://github.com/neoforged/.github/blob/main/primers/1.21.2/index.md
diff --git a/versioned_docs/version-1.21.3/misc/_category_.json b/versioned_docs/version-1.21.3/misc/_category_.json
new file mode 100644
index 00000000..366f9872
--- /dev/null
+++ b/versioned_docs/version-1.21.3/misc/_category_.json
@@ -0,0 +1,4 @@
+{
+    "label": "Miscellaneous",
+    "position": 13
+}
\ No newline at end of file
diff --git a/versioned_docs/version-1.21.3/misc/config.md b/versioned_docs/version-1.21.3/misc/config.md
new file mode 100644
index 00000000..1c15a1c2
--- /dev/null
+++ b/versioned_docs/version-1.21.3/misc/config.md
@@ -0,0 +1,213 @@
+# Configuration
+
+Configurations define settings and consumer preferences that can be applied to a mod instance. NeoForge uses a configuration system using [TOML][toml] files and read with [NightConfig][nightconfig].
+
+## Creating a Configuration
+
+A configuration can be created using a subtype of `IConfigSpec`. NeoForge implements the type via `ModConfigSpec` and enables its construction through `ModConfigSpec.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:
+
+ Method     | Description
+ :---       | :---
+`build`     | Creates the `ModConfigSpec`.
+`configure` | Creates a pair of the class holding the config values and the `ModConfigSpec`.
+
+:::note
+`ModConfigSpec.Builder#configure` is typically used with a `static` block and a class that takes in `ModConfigSpec.Builder` as part of its constructor to attach and hold the values:
+
+```java
+//Define a field to keep the config and spec for later
+public static final ExampleConfig CONFIG;
+public static final ModConfigSpec CONFIG_SPEC;
+
+private ExampleConfig(ModConfigSpec.Builder builder) {
+    // Define properties used by the configuration
+    // ...
+}
+
+//CONFIG and CONFIG_SPEC are both built from the same builder, so we use a static block to seperate the properties
+static {
+    Pair<ExampleConfig, ModConfigSpec> pair =
+            new ModConfigSpec.Builder().configure(ExampleConfig::new);
+        
+    //Store the resulting values
+    CONFIG = pair.getLeft();
+    CONFIG_SPEC = pair.getRight();
+}
+```
+:::
+
+Each config value can be supplied with additional context to provide additional behavior. Contexts must be defined before the config value is fully built:
+
+| Method         | Description                                                                                                 |
+|:---------------|:------------------------------------------------------------------------------------------------------------|
+| `comment`      | Provides a description of what the config value does. Can provide multiple strings for a multiline comment. |
+| `translation`  | Provides a translation key for the name of the config value.                                                |
+| `worldRestart` | The world must be restarted before the config value can be changed.                                         |
+
+### ConfigValue
+
+Config values can be built with the provided contexts (if defined) using any of the `#define` methods.
+
+All config value methods take in at least two components:
+
+- A path representing the name of the variable: a `.` separated string representing the sections the config value is in
+- The default value when no valid configuration is present
+
+The `ConfigValue` specific methods take in two additional components:
+
+- A validator to make sure the deserialized object is valid
+- A class representing the data type of the config value
+
+```java
+//Store the config properties as public finals
+public final ModConfigSpec.ConfigValue<String> welcomeMessage;
+
+private ExampleConfig(ModConfigSpec.Builder builder) {
+    //Define each property
+    //One property could be a message to log to the console when the game is initialised
+    welcomeMessage = builder.define("welcome_message", "Hello from the config!");
+}
+```
+
+The values themselves can be obtained using `ConfigValue#get`. The values are additionally cached to prevent multiple readings from files.
+
+#### Additional Config Value Types
+
+- **Range Values**
+    - Description: Value must be between the defined bounds
+    - Class Type: `Comparable<T>`
+    - Method Name: `#defineInRange`
+    - Additional Components:
+        - The minimum and maximum the config value may be
+        - A class representing the data type of the config value
+
+:::note
+`DoubleValue`s, `IntValue`s, and `LongValue`s are range values which specify the class as `Double`, `Integer`, and `Long` respectively.
+:::
+
+- **Whitelisted Values**
+    - Description: Value must be in supplied collection
+    - Class Type: `T`
+    - Method Name: `#defineInList`
+    - Additional Components:
+        - A collection of the allowed values the configuration can be
+
+- **List Values**
+    - Description: Value is a list of entries
+    - Class Type: `List<T>`
+    - Method Name: `#defineList`, `#defineListAllowEmpty` if list can be empty
+    - Additional Components:
+        - A supplier that returns a default value to use when a new entry is added in configuration screens.
+        - A validator to make sure a deserialized element from the list is valid
+        - (optional) A vaidator to make sure the list does not get too little or too many entries
+
+- **Enum Values**
+    - Description: An enum value in the supplied collection
+    - Class Type: `Enum<T>`
+    - Method Name: `#defineEnum`
+    - Additional Components:
+        - A getter to convert a string or integer into an enum
+        - A collection of the allowed values the configuration can be
+
+- **Boolean Values**
+    - Description: A `boolean` value
+    - Class Type: `Boolean`
+    - Method Name: `#define`
+
+## Registering a Configuration
+
+Once a `ModConfigSpec` has been built, it must be registered to allow NeoForge to load, track, and sync the configuration settings as required. Configurations should be registered in the mod constructor via `ModConatiner#registerConfig`. A configuration can be registered with a [given type][configtype] representing the side the config belongs to, the `ModConfigSpec`, and optionally a specific file name for the configuration.
+
+```java
+// In the main mod file with a ModConfigSpec CONFIG
+public ExampleMod(ModContainer container) {
+    ...
+    //Register the config
+    container.registerConfig(ModConfig.Type.COMMON, ExampleConfig.CONFIG);
+    ...
+}
+```
+
+### Configuration Types
+
+Configuration types determine where the configuration file is located, what time it is loaded, and whether the file is synced across the network. All configurations are, by default, either loaded from `.minecraft/config` on the physical client or `<server_folder>/config` on the physical server. Some nuances between each configuration type can be found in the following subsections.
+
+:::tip
+NeoForge documents the [config types][type] within their codebase.
+:::
+
+- `STARTUP`
+    - Loaded on both the physical client and physical server from the config folder
+    - Read immediately on registration
+    - **NOT** synced across the network
+    - Suffixed with `-startup` by default
+
+:::warning
+Configurations registered under the `STARTUP` type can cause desyncs between the client and server, such as if the configuration is used to disable the registration of content. Therefore, it is highly recommended that any configurations within `STARTUP` are not used to enable or disable features that may change the content of the mod.
+:::
+
+- `CLIENT`
+    - Loaded **ONLY** on the physical client from the config folder
+        - There is no server location for this configuration type
+    - Read immedately before `FMLCommonSetupEvent` is fired
+    - **NOT** synced across the network
+    - Suffixed with `-client` by default
+- `COMMON`
+    - Loaded on both the physical client and physical server from the config folder
+    - Read immedately before `FMLCommonSetupEvent` is fired
+    - **NOT** synced across the network
+    - Suffixed with `-common` by default
+- `SERVER`
+    - Loaded on both the physical client and physical server from the config folder
+        - Can be overridden for each world by adding a config to:
+            - Client: `.minecraft/saves/<world_name>/serverconfig`
+            - Server: `<server_folder>/world/serverconfig`
+    - Read immedately before `ServerAboutToStartEvent` is fired
+    - Synced across the network to the client
+    - Suffixed with `-server` by default
+
+## 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.
+
+:::caution
+These events are called for all configurations for the mod; the `ModConfig` object provided should be used to denote which configuration is being loaded or reloaded.
+:::
+## Configuration Screen
+
+A configuration screen allows users to edit the config values for a mod while in-game without needing to open any files. The screen will automatically parse your registered config files and populate the screen. 
+
+A mod can use the built-in configuration screen that NeoForge provides. Mods can extend `ConfigurationScreen` to change the behavior of the default screen or make their own configuration screen. Mods can also create their own screen from scratch and provide that custom screen to NeoForge through the below extension point.
+
+A configuration screen can be registered for a mod by registering a `IConfigScreenFactory` extension point during mod construction on the [client]:
+```java
+// In the main client mod file
+public ExampleModClient(ModContainer container) {
+    ...
+    // This will use NeoForge's ConfigurationScreen to display this mod's configs
+    container.registerExtensionPoint(IConfigScreenFactory.class, ConfigurationScreen::new);
+    ...
+}
+```
+
+The configuration screen can be accessed in game by going to the 'Mods' page, selecting the mod from the sidebar, and clicking the 'Config' button. Startup, Common, and Client config options will always be editable at any point. Server configs are only editable in the screen when playing on a world locally. If connected to a server or to another person's LAN world, Server config option will be disabled in the screen. The first page of the config screen for the mod will show every registered config file for players to pick which one to edit.
+
+:::warning
+Translation keys should be added and have the text defined within the lang JSON for all config entries if you are making a screen.
+
+You can specify a translation key for a config by using the `ModConfigSpec$Builder#translation` method, so we can extend the previous code to:
+```java
+ConfigValue<T> value = builder.comment("This value is called 'config_value_name', and is set to defaultValue if no existing config is present")
+    .translation("modid.config.config_value_name")
+    .define("config_value_name", defaultValue);
+```
+
+To make translating easier, open the configuration screen and visit all of the configs and their subsections. Then back out to the mod list screen. All untranslated config entries that were encountered will be printed to the console at this point. This makes it easier to know what to translate and what the translation keys are. 
+:::
+
+[toml]: https://toml.io/
+[nightconfig]: https://github.com/TheElectronWill/night-config
+[configtype]: #configuration-types
+[type]: https://github.com/neoforged/FancyModLoader/blob/1b6af92893464a4f477cab310256639f39d41ea7/loader/src/main/java/net/neoforged/fml/config/ModConfig.java#L81-L114
+[events]: ../concepts/events.md#registering-an-event-handler
+[client]: ../concepts/sides.md#mod
diff --git a/versioned_docs/version-1.21.3/misc/debugprofiler.md b/versioned_docs/version-1.21.3/misc/debugprofiler.md
new file mode 100644
index 00000000..c187c13c
--- /dev/null
+++ b/versioned_docs/version-1.21.3/misc/debugprofiler.md
@@ -0,0 +1,50 @@
+# 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.
+
+## Using the Debug Profiler
+
+The Debug Profiler is very simple to use. It requires the debug keybind `F3 + L` to start the profiler. After 10 seconds, it will automatically stop; however, it can be stopped earlier by pressing the keybind again.
+
+:::note
+Naturally, you can only profile code paths that are actually being reached. `Entities` and `BlockEntities` that you want to profile must exist in the level to show up in the results.
+:::
+
+After you have stopped the debugger, it will create a new zip within the `debug/profiling` subdirectory in your run directory.
+The file name will be formatted with the date and time as `yyyy-mm-dd_hh_mi_ss-WorldName-VersionNumber.zip`
+
+## Reading a Profiling result
+
+Within each sided folder (`client` and `server`), you will find a `profiling.txt` file containing the result data. At the top, it first tells you how long in milliseconds it was running and how many ticks ran in that time.
+
+Below that, you will find information similar to the snippet below:
+
+```
+[00] levels - 96.70%/96.70%
+[01] |   Level Name - 99.76%/96.47%
+[02] |   |   tick - 99.31%/95.81%
+[03] |   |   |   entities - 47.72%/45.72%
+[04] |   |   |   |   regular - 98.32%/44.95%
+[04] |   |   |   |   blockEntities - 0.90%/0.41%
+[05] |   |   |   |   |   unspecified - 64.26%/0.26%
+[05] |   |   |   |   |   minecraft:furnace - 33.35%/0.14%
+[05] |   |   |   |   |   minecraft:chest - 2.39%/0.01%
+```
+
+Here is a small explanation of what each part means:
+
+| [02]                     | tick                    | 99.31%       | 95.81%       |
+| :----------------------- | :---------------------- | :----------- | :----------- |
+| The Depth of the section | The Name of the Section | The percentage of time it took in relation to it's parent. For Layer 0, it is the percentage of the time a tick takes. For Layer 1, it is the percentage of the time its parent takes. | The second percentage tells you how much time it took from the entire tick.
+
+## Profiling your own code
+
+The Debug Profiler has basic support for `Entity` and `BlockEntity`. If you would like to profile something else, you may need to manually create your sections like so:
+
+```java
+Profiler.get().push("yourSectionName");
+//The code you want to profile
+Profiler.get().pop();
+```
+
+Now you just need to search the results file for your section name.
diff --git a/versioned_docs/version-1.21.3/misc/gametest.md b/versioned_docs/version-1.21.3/misc/gametest.md
new file mode 100644
index 00000000..3912ab04
--- /dev/null
+++ b/versioned_docs/version-1.21.3/misc/gametest.md
@@ -0,0 +1,282 @@
+# 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
+
+A standard Game Test follows three basic steps:
+
+1. A structure, or template, is loaded holding the scene on which the interaction or behavior is tested.
+1. A method conducts the logic to perform on the scene.
+1. The method logic executes. If a successful state is reached, then the test succeeds. Otherwise, the test fails and the result is stored within a lectern adjacent to the scene.
+
+As such, to create a Game Test, there must be an existing template holding the initial start state of the scene and a method which provides the logic of execution.
+
+### The Test Method
+
+A Game Test method is a `Consumer<GameTestHelper>` reference, meaning it takes in a `GameTestHelper` and returns nothing. For a Game Test method to be recognized, it must have a `@GameTest` annotation:
+
+```java
+public class ExampleGameTests {
+    @GameTest
+    public static void exampleTest(GameTestHelper helper) {
+        // Do stuff
+    }
+}
+```
+
+The `@GameTest` annotation also contains members which configure how the game test should run.
+
+```java
+// In some class
+@GameTest(
+    setupTicks = 20L, // The test spends 20 ticks to set up for execution
+    required = false // The failure is logged but does not affect the execution of the batch
+)
+public static void exampleConfiguredTest(GameTestHelper helper) {
+    // Do stuff
+}
+```
+
+#### Relative Positioning
+
+All `GameTestHelper` methods translate relative coordinates within the structure template scene to its absolute coordinates using the structure block's current location. To allow for easy conversion between relative and absolute positioning, `GameTestHelper#absolutePos` and `GameTestHelper#relativePos` can be used respectively.
+
+The relative position of a structure template can be obtained in-game by loading the structure via the [test command][test], placing the player at the wanted location, and finally running the `/test pos` command. This will grab the coordinates of the player relative to the closest structure within 200 blocks of the player. The command will export the relative position as a copyable text component in the chat to be used as a final local variable.
+
+:::tip
+The local variable generated by `/test pos` can specify its reference name by appending it to the end of the command:
+
+```bash
+/test pos <var> # Exports 'final BlockPos <var> = new BlockPos(...);'
+```
+:::
+
+#### Successful Completion
+
+A Game Test method is responsible for one thing: marking the test was successful on a valid completion. If no success state was achieved before the timeout is reached (as defined by `GameTest#timeoutTicks`), then the test automatically fails.
+
+There are many abstracted methods within `GameTestHelper` which can be used to define a successful state; however, four are extremely important to be aware of.
+
+Method               | Description
+:---:                | :---
+`#succeed`           | The test is marked as successful.
+`#succeedIf`         | The supplied `Runnable` is tested immediately and succeeds if no `GameTestAssertException` is thrown. If the test does not succeed on the immediate tick, then it is marked as a failure.
+`#succeedWhen`       | The supplied `Runnable` is tested every tick until timeout and succeeds if the check on one of the ticks does not throw a `GameTestAssertException`.
+`#succeedOnTickWhen` | The supplied `Runnable` is tested on the specified tick and will succeed if no `GameTestAssertException` is thrown. If the `Runnable` succeeds on any other tick, then it is marked as a failure.
+
+:::caution
+Game Tests are executed every tick until the test is marked as a success. As such, methods which schedule success on a given tick must be careful to always fail on any previous tick.
+:::
+
+#### Scheduling Actions
+
+Not all actions will occur when a test begins. Actions can be scheduled to occur at specific times or intervals:
+
+Method           | Description
+:---:            | :---
+`#runAtTickTime` | The action is ran on the specified tick.
+`#runAfterDelay` | The action is ran `x` ticks after the current tick.
+`#onEachTick`    | The action is ran every tick.
+
+#### Assertions
+
+At any time during a Game Test, an assertion can be made to check if a given condition is true. There are numerous assertion methods within `GameTestHelper`; however, it simplifies to throwing a `GameTestAssertException` whenever the appropriate state is not met.
+
+### Generated Test Methods
+
+If Game Test methods need to be generated dynamically, a test method generator can be created. These methods take in no parameters and return a collection of `TestFunction`s. For a test method generator to be recognized, it must have a `@GameTestGenerator` annotation:
+
+```java
+public class ExampleGameTests {
+    @GameTestGenerator
+    public static Collection<TestFunction> exampleTests() {
+        // Return a collection of TestFunctions
+    }
+}
+```
+
+#### TestFunction
+
+A `TestFunction` is the boxed information held by the `@GameTest` annotation and the method running the test.
+
+:::tip
+Any methods annotated using `@GameTest` are translated into a `TestFunction` using `GameTestRegistry#turnMethodIntoTestFunction`. That method can be used as a reference for creating `TestFunction`s without the use of the annotation.
+:::
+
+### Batching
+
+Game Tests can be executed in batches instead of registration order. A test can be added to a batch by having the same supplied `GameTest#batch` string.
+
+On its own, batching does not provide anything useful. However, batching can be used to perform setup and teardown states on the current level the tests are running in. This is done by annotating a method with either `@BeforeBatch` for setup or `@AfterBatch` for takedown. The `#batch` methods must match the string supplied to the game test.
+
+Batch methods are `Consumer<ServerLevel>` references, meaning they take in a `ServerLevel` and return nothing:
+
+```java
+public class ExampleGameTests {
+    @BeforeBatch(batch = "firstBatch")
+    public static void beforeTest(ServerLevel level) {
+        // Perform setup
+    }
+
+    @GameTest(batch = "firstBatch")
+    public static void exampleTest2(GameTestHelper helper) {
+        // Do stuff
+    }
+}
+```
+
+## 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`.
+
+### GameTestHolder
+
+The `@GameTestHolder` annotation registers any test methods within the type (class, interface, enum, or record). `@GameTestHolder` contains a single method which has multiple uses. In this instance, the supplied `#value` must be the mod id of the mod; otherwise, the test will not run under default configurations.
+
+```java
+@GameTestHolder(MODID)
+public class ExampleGameTests {
+    // ...
+}
+```
+
+### RegisterGameTestsEvent
+
+`RegisterGameTestsEvent` can also register either classes or methods using `#register`. The event listener must be [added][event] to the mod event bus. Test methods registered this way must supply their mod id to `GameTest#templateNamespace` on every method annotated with `@GameTest`.
+
+```java
+// In some class
+public void registerTests(RegisterGameTestsEvent event) {
+    event.register(ExampleGameTests.class);
+}
+
+// In ExampleGameTests
+@GameTest(templateNamespace = MODID)
+public static void exampleTest3(GameTestHelper helper) {
+    // Perform setup
+}
+```
+
+:::note
+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
+
+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>/structure`.
+
+:::tip
+A structure template can be created and saved using a structure block.
+:::
+
+The location of the template is specified by a few factors:
+
+- If the namespace of the template is specified.
+- If the class should be prepended to the name of the template.
+- If the name of the template is specified.
+
+The namespace of the template is determined by `GameTest#templateNamespace`, then `GameTestHolder#value` if not specified, then `minecraft` if neither is specified.
+
+The simple class name is not prepended to the name of the template if the `@PrefixGameTestTemplate` is applied to a class or method with the test annotations and set to `false`. Otherwise, the simple class name is made lowercase and prepended and followed by a dot before the template name.
+
+The name of the template is determined by `GameTest#template`. If not specified, then the lowercase name of the method is used instead.
+
+```java
+// Modid for all structures will be MODID
+@GameTestHolder(MODID)
+public class ExampleGameTests {
+
+    // Class name is prepended, template name is not specified
+    // Template Location at 'modid:examplegametests.exampletest'
+    @GameTest
+    public static void exampleTest(GameTestHelper helper) { /*...*/ }
+
+    // Class name is not prepended, template name is not specified
+    // Template Location at 'modid:exampletest2'
+    @PrefixGameTestTemplate(false)
+    @GameTest
+    public static void exampleTest2(GameTestHelper helper) { /*...*/ }
+
+    // Class name is prepended, template name is specified
+    // Template Location at 'modid:examplegametests.test_template'
+    @GameTest(template = "test_template")
+    public static void exampleTest3(GameTestHelper helper) { /*...*/ }
+
+    // Class name is not prepended, template name is specified
+    // Template Location at 'modid:test_template2'
+    @PrefixGameTestTemplate(false)
+    @GameTest(template = "test_template2")
+    public static void exampleTest4(GameTestHelper helper) { /*...*/ }
+}
+```
+
+## 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:
+
+| Subcommand  | Description                                           |
+|:-----------:|:------------------------------------------------------|
+| `run`       | Runs the specified test: `run <test_name>`.           |
+| `runall`    | Runs all available tests.                             |
+| `runclosest`| Runs the nearest test to the player within 15 blocks. |
+| `runthese`  | Runs tests within 200 blocks of the player.           |
+| `runfailed` | Runs all tests that failed in the previous run.       |
+
+:::note
+Subcommands follow the test command: `/test <subcommand>`.
+:::
+
+## Buildscript Configurations
+
+Game Tests provide additional configuration settings within a buildscript (the `build.gradle` file) to run and integrate into different settings.
+
+### Enabling Other Namespaces
+
+If the buildscript was [setup as recommended][buildscript], then only Game Tests under the current mod id would be enabled. To enable other namespaces to load Game Tests from, a run configuration must set the property `neoforge.enabledGameTestNamespaces` to a string specifying each namespace separated by a comma. If the property is empty or not set, then all namespaces will be loaded.
+
+```gradle
+// Inside a run configuration
+property 'neoforge.enabledGameTestNamespaces', 'modid1,modid2,modid3'
+```
+
+:::caution
+There must be no spaces in-between namespaces; otherwise, the namespace will not be loaded correctly.
+:::
+
+### Game Test Server Run Configuration
+
+The Game Test Server is a special configuration which runs a build server. The build server returns an exit code of the number of required, failed Game Tests. All failed tests, whether required or optional, are logged. This server can be run using `gradlew runGameTestServer`.
+
+<details>
+<summary>Important information on NeoGradle</summary>
+
+:::caution
+Due to a quirk in how Gradle works, by default, if a task forces a system exit, the Gradle daemon will be killed, causing the Gradle runner to report a build failure. NeoGradle sets by default a force exit on run tasks such that any subprojects are not executed in sequence. However, as such, the Game Test Server will always fail.
+
+This can be fixed by disabling the force exit on the run configuration using the `#setForceExit` method:
+
+```gradle
+// Game Test Server run configuration
+gameTestServer {
+    // ...
+    setForceExit false
+}
+```
+:::
+</details>
+
+
+### Enabling Game Tests in Other Run Configurations
+
+By default, only the `client`, `server`, and `gameTestServer` run configurations have Game Tests enabled. If another run configuration should run Game Tests, then the `neoforge.enableGameTest` property must be set to `true`.
+
+```gradle
+// Inside a run configuration
+property 'neoforge.enableGameTest', 'true'
+```
+
+[test]: #running-game-tests
+[namespaces]: #enabling-other-namespaces
+[event]: ../concepts/events.md#registering-an-event-handler
+[buildscript]: ../gettingstarted/index.md#simple-buildgradle-customizations
diff --git a/versioned_docs/version-1.21.3/misc/keymappings.md b/versioned_docs/version-1.21.3/misc/keymappings.md
new file mode 100644
index 00000000..d84dab4d
--- /dev/null
+++ b/versioned_docs/version-1.21.3/misc/keymappings.md
@@ -0,0 +1,154 @@
+# 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].
+
+## Registering a `KeyMapping`
+
+A `KeyMapping` can be registered by listening to the `RegisterKeyMappingsEvent` on the [mod event bus][eventbus] only on the physical client and calling `#register`.
+
+```java
+// In some physical client only class
+
+// Key mapping is lazily initialized so it doesn't exist until it is registered
+public static final Lazy<KeyMapping> EXAMPLE_MAPPING = Lazy.of(() -> /*...*/);
+
+// Event is on the mod event bus only on the physical client
+@SubscribeEvent
+public void registerBindings(RegisterKeyMappingsEvent event) {
+    event.register(EXAMPLE_MAPPING.get());
+}
+```
+
+## Creating a `KeyMapping`
+
+A `KeyMapping` can be created using it's constructor. The `KeyMapping` takes in a [translation key][tk] defining the name of the mapping, the default input of the mapping, and the [translation key][tk] defining the category the mapping will be put within in the [Controls option menu][controls].
+
+:::tip
+A `KeyMapping` can be added to a custom category by providing a category [translation key][tk] not provided by vanilla. Custom category translation keys should contain the mod id (e.g. `key.categories.examplemod.examplecategory`).
+:::
+
+### Default Inputs
+
+Each key mapping has a default input associated with it. This is provided through `InputConstants.Key`. Each input consists of an `InputConstants.Type`, which defines what device is providing the input, and an integer, which defines the associated identifier of the input on the device.
+
+Vanilla provides three types of inputs: `KEYSYM`, which defines a keyboard through the provided `GLFW` key tokens, `SCANCODE`, which defines a keyboard through the platform-specific scancode, and `MOUSE`, which defines a mouse.
+
+:::note
+It is highly recommended to use `KEYSYM` over `SCANCODE` for keyboards as `GLFW` key tokens are not tied to any particular system. You can read more on the [GLFW docs][keyinput].
+:::
+
+The integer is dependent on the type provided. All input codes are defined in `GLFW`: `KEYSYM` tokens are prefixed with `GLFW_KEY_*` while `MOUSE` codes are prefixed with `GLFW_MOUSE_*`.
+
+```java
+new KeyMapping(
+    "key.examplemod.example1", // Will be localized using this translation key
+    InputConstants.Type.KEYSYM, // Default mapping is on the keyboard
+    GLFW.GLFW_KEY_P, // Default key is P
+    "key.categories.misc" // Mapping will be in the misc category
+)
+```
+
+:::note
+If the key mapping should not be mapped to a default, the input should be set to `InputConstants#UNKNOWN`. The vanilla constructor will require you to extract the input code via `InputConstants$Key#getValue` while the NeoForge constructor can be supplied the raw input field.
+:::
+
+### `IKeyConflictContext`
+
+Not all mappings are used in every context. Some mappings are only used in a GUI, while others are only used purely in game. To avoid mappings of the same key used in different contexts conflicting with each other, an `IKeyConflictContext` can be assigned.
+
+Each conflict context contains two methods: `#isActive`, which defines if the mapping can be used in the current game state, and `#conflicts`, which defines whether the mapping conflicts with a key in the same or different conflict context.
+
+Currently, NeoForge defines three basic contexts through `KeyConflictContext`: `UNIVERSAL`, which is the default meaning the key can be used in every context, `GUI`, which means the mapping can only be used when a `Screen` is open, and `IN_GAME`, which means the mapping can only be used if a `Screen` is not open. New conflict contexts can be created by implementing `IKeyConflictContext`.
+
+```java
+new KeyMapping(
+    "key.examplemod.example2",
+    KeyConflictContext.GUI, // Mapping can only be used when a screen is open
+    InputConstants.Type.MOUSE, // Default mapping is on the mouse
+    GLFW.GLFW_MOUSE_BUTTON_LEFT, // Default mouse input is the left mouse button
+    "key.categories.examplemod.examplecategory" // Mapping will be in the new example category
+)
+```
+
+### `KeyModifier`
+
+Modders may not want mappings to have the same behavior if a modifier key is held at the same (e.g. `G` vs `CTRL + G`). To remedy this, NeoForge adds an additional parameter to the constructor to take in a `KeyModifier` which can apply control (`KeyModifier#CONTROL`), shift (`KeyModifier#SHIFT`), or alt (`KeyModifier#ALT`) to any input. `KeyModifier#NONE` is the default and will apply no modifier.
+
+A modifier can be added in the [controls option menu][controls] by holding down the modifier key and the associated input.
+
+```java
+new KeyMapping(
+    "key.examplemod.example3",
+    KeyConflictContext.UNIVERSAL,
+    KeyModifier.SHIFT, // Default mapping requires shift to be held down
+    InputConstants.Type.KEYSYM, // Default mapping is on the keyboard
+    GLFW.GLFW_KEY_G, // Default key is G
+    "key.categories.misc"
+)
+```
+
+## Checking a `KeyMapping`
+
+A `KeyMapping` can be checked to see whether it has been clicked. Depending on when, the mapping can be used in a conditional to apply the associated logic.
+
+### Within the Game
+
+Within the game, a mapping should be checked by listening to `ClientTickEvent.Post` on the [event bus][eventbus] and checking `KeyMapping#consumeClick` within a while loop. `#consumeClick` will return `true` only the number of times the input was performed and not already previously handled, so it won't infinitely stall the game.
+
+```java
+// Event is on the NeoForge event bus only on the physical client
+public void onClientTick(ClientTickEvent.Post event) {
+    while (EXAMPLE_MAPPING.get().consumeClick()) {
+        // Execute logic to perform on click here
+    }
+}
+```
+
+:::caution
+Do not use the `InputEvent`s as an alternative to `ClientTickEvent.Post`. There are separate events for keyboard and mouse inputs only, so they wouldn't handle any additional inputs.
+:::
+
+### Inside a GUI
+
+Within a GUI, a mapping can be checked within one of the `GuiEventListener` methods using `IKeyMappingExtension#isActiveAndMatches`. The most common methods which can be checked are `#keyPressed` and `#mouseClicked`. 
+
+`#keyPressed` takes in the `GLFW` key token, the platform-specific scan code, and a bitfield of the held down modifiers. A key can be checked against a mapping by creating the input using `InputConstants#getKey`. The modifiers are already checked within the mapping methods itself.
+
+```java
+// In some Screen subclass
+@Override
+public boolean keyPressed(int key, int scancode, int mods) {
+    if (EXAMPLE_MAPPING.get().isActiveAndMatches(InputConstants.getKey(key, scancode))) {
+        // Execute logic to perform on key press here
+        return true;
+    }
+    return super.keyPressed(x, y, button);
+} 
+```
+
+:::note
+If you do not own the screen which you are trying to check a **key** for, you can listen to the `Pre` or `Post` events of `ScreenEvent.KeyPressed` on the [event bus][eventbus] instead.
+:::
+
+`#mouseClicked` takes in the mouse's x position, y position, and the button clicked. A mouse button can be checked against a mapping by creating the input using `InputConstants.Type#getOrCreate` with the `MOUSE` input.
+
+```java
+// In some Screen subclass
+@Override
+public boolean mouseClicked(double x, double y, int button) {
+    if (EXAMPLE_MAPPING.get().isActiveAndMatches(InputConstants.TYPE.MOUSE.getOrCreate(button))) {
+        // Execute logic to perform on mouse click here
+        return true;
+    }
+    return super.mouseClicked(x, y, button);
+} 
+```
+
+:::note
+If you do not own the screen which you are trying to check a **mouse** for, you can listen to the `Pre` or `Post` events of `ScreenEvent.MouseButtonPressed` on the [event bus][eventbus] instead.
+:::
+
+[eventbus]: ../concepts/events.md#registering-an-event-handler
+[controls]: https://minecraft.wiki/w/Options#Controls
+[tk]: ../resources/client/i18n.md#components
+[keyinput]: https://www.glfw.org/docs/3.3/input_guide.html#input_key
diff --git a/versioned_docs/version-1.21.3/misc/resourcelocation.md b/versioned_docs/version-1.21.3/misc/resourcelocation.md
new file mode 100644
index 00000000..dda7c1de
--- /dev/null
+++ b/versioned_docs/version-1.21.3/misc/resourcelocation.md
@@ -0,0 +1,48 @@
+# Resource Locations
+
+`ResourceLocation`s are one of the most important things in Minecraft. They are used as keys in [registries][registries], as identifiers for data or resource files, as references to models in code, and in a lot of other places. A `ResourceLocation` consists of two parts: a namespace and a path, separated by a `:`.
+
+The namespace denotes what mod, resource pack or datapack the location refers to. For example, a mod with the mod id `examplemod` will use the `examplemod` namespace. Minecraft uses the `minecraft` namespace. Extra namespaces can be defined at will simply by creating a corresponding data folder, this is usually done by datapacks to keep their logic separate from the point where they integrate with vanilla.
+
+The path is a reference to whatever object you want, inside your namespace. For example, `minecraft:cow` is a reference to something named `cow` in the `minecraft` namespace - usually this location would be used to get the cow entity from the entity registry. Another example would be `examplemod:example_item`, which would probably be used to get your mod's `example_item` from the item registry.
+
+`ResourceLocation`s may only contain lowercase letters, digits, underscores, dots and hyphens. Paths may additionally contain forward slashes. Note that due to Java module restrictions, mod ids may not contain hyphens, which by extension means that mod namespaces may not contain hyphens either (they are still permitted in paths).
+
+:::info
+A `ResourceLocation` on its own says nothing about what kind of objects we are using it for. Objects named `minecraft:dirt` exist in multiple places, for example. It is up to whatever receives the `ResourceLocation` to associate an object with it.
+:::
+
+A new `ResourceLocation` can be created by calling `ResourceLocation.fromNamespaceAndPath("examplemod", "example_item")` or `ResourceLocation.parse("examplemod:example_item")`. If `withDefaultNamespace` is used, the string will be used as the path, and `minecraft` will be used as the namespace. So for example, `ResourceLocation.withDefaultNamespace("example_item")` will result in `minecraft:example_item`.
+
+The namespace and path of a `ResourceLocation` can be retrieved using `ResourceLocation#getNamespace()` and `#getPath()`, respectively, and the combined form can be retrieved through `ResourceLocation#toString`.
+
+`ResourceLocation`s are immutable. All utility methods on `ResourceLocation`, such as `withPrefix` or `withSuffix`, return a new `ResourceLocation`.
+
+## Resolving `ResourceLocation`s
+
+Some places, for example registries, use `ResourceLocation`s directly. Some other places, however, will resolve the `ResourceLocation` as needed. For example:
+
+- `ResourceLocation`s are used as identifiers for GUI background. For example, the furnace GUI uses the resource location `minecraft:textures/gui/container/furnace.png`. This maps to the file `assets/minecraft/textures/gui/container/furnace.png` on disk. Note that the `.png` suffix is required in this resource location.
+- `ResourceLocation`s are used as identifiers for block models. For example, the block model of dirt uses the resource location `minecraft:block/dirt`. This maps to the file `assets/minecraft/models/block/dirt.json` on disk. Note that the `.json` suffix is not required here. Note as well that this resource location automatically maps into the `models` subfolder.
+- `ResourceLocation`s are used as identifiers for recipes. For example, the iron block crafting recipe uses the resource location `minecraft:iron_block`. This maps to the file `data/minecraft/recipe/iron_block.json` on disk. Note that the `.json` suffix is not required here. Note as well that this resource location automatically maps into the `recipe` subfolder.
+
+Whether the `ResourceLocation` expects a file suffix, or what exactly the resource location resolves to, depends on the use case.
+
+## `ModelResourceLocation`s
+
+`ModelResourceLocation`s are a special kind of resource location that includes a third part, called the variant. Minecraft uses these mainly to differentiate between different variants of models, where the different variants are used in different display contexts (for example with tridents, which have different models in first person, third person and inventories). The variant is always `inventory` for items, and the comma-delimited string of property-value pairs for blockstates (for example `facing=north,waterlogged=false`, empty for blocks with no blockstate properties).
+
+The variant is appended to the regular resource location, along with a `#`. For example, the full name of the diamond sword's item model is `minecraft:diamond_sword#inventory`. However, in most contexts, the `inventory` variant can be omitted.
+
+`ModelResourceLocation` is a [client only][sides] class. This means that servers referencing this class will crash with a `NoClassDefFoundError`.
+
+## `ResourceKey`s
+
+`ResourceKey`s combine a registry id with a registry name. An example would be a registry key with the registry id `minecraft:item` and the registry name `minecraft:diamond_sword`. Unlike a `ResourceLocation`, `ResourceKey`s actually refer to a unique element, thus being able to clearly identify an element. They are most commonly used in contexts where many different registries come in contact with one another. A common use case are datapacks, especially worldgen.
+
+A new `ResourceKey` can be created through the static method `ResourceKey#create(ResourceKey<? extends Registry<T>>, ResourceLocation)`. The second parameter here is the registry name, while the first parameter is what is known as a registry key. Registry keys are a special kind of `ResourceKey` whose registry is the root registry (i.e. the registry of all other registries). A registry key can be created via `ResourceKey#createRegistryKey(ResourceLocation)` with the desired registry's id.
+
+`ResourceKey`s are interned at creation. This means that comparing by reference equality (`==`) is possible and encouraged, but their creation is comparatively expensive.
+
+[registries]: ../concepts/registries.md
+[sides]: ../concepts/sides.md
diff --git a/versioned_docs/version-1.21.3/misc/updatechecker.md b/versioned_docs/version-1.21.3/misc/updatechecker.md
new file mode 100644
index 00000000..79a601db
--- /dev/null
+++ b/versioned_docs/version-1.21.3/misc/updatechecker.md
@@ -0,0 +1,59 @@
+# NeoForge Update Checker
+
+NeoForge 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
+
+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
+
+The JSON itself has a relatively simple format as follows:
+
+```json5
+{
+    "homepage": "<homepage/download page for your mod>",
+    "<mcversion>": {
+        "<modversion>": "<changelog for this version>", 
+        // List all versions of your mod for the given Minecraft version, along with their changelogs
+        // ...
+    },
+    "promos": {
+        "<mcversion>-latest": "<modversion>",
+        // Declare the latest "bleeding-edge" version of your mod for the given Minecraft version
+        "<mcversion>-recommended": "<modversion>",
+        // Declare the latest "stable" version of your mod for the given Minecraft version
+        // ...
+    }
+}
+```
+
+This is fairly self-explanatory, but some notes:
+ 
+- The link under `homepage` is the link the user will be shown when the mod is outdated.
+- NeoForge uses an internal algorithm to determine whether one version string of your mod is "newer" than another. Most versioning schemes should be compatible, but see the `ComparableVersion` class if you are concerned about whether your scheme is supported. Adherence to [Maven versioning][mvnver] is highly recommended.
+- The changelog string can be separated into lines using `\n`. Some prefer to include a abbreviated changelog, then link to an external site that provides a full listing of changes.
+- Manually inputting data can be chore. You can configure your `build.gradle` to automatically update this file when building a release as Groovy has native JSON parsing support. Doing this is left as an exercise to the reader.
+
+- Some examples can be found here for [nocubes], [Corail Tombstone][corail] and [Chisels & Bits 2][chisel].
+
+## Retrieving Update Check Results
+
+You can retrieve the results of the NeoForge Update Checker using `VersionChecker#getResult(IModInfo)`. You can obtain your `IModInfo` via `ModContainer#getModInfo`, where `ModContainer` can be added as a parameter to your mod constructor. 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.
+
+|          Status | Description |
+|----------------:|:------------|
+|        `FAILED` | The version checker could not connect to the URL provided. |
+|    `UP_TO_DATE` | The current version is equal to the recommended version. |
+|         `AHEAD` | The current version is newer than the recommended version if there is not latest version. |
+|      `OUTDATED` | There is a new recommended or latest version. |
+| `BETA_OUTDATED` | There is a new latest version. |
+|          `BETA` | The current version is equal to or newer than the latest version. |
+|       `PENDING` | The result requested has not finished yet, so you should try again in a little bit. |
+
+The returned object will also have the target version and any changelog lines as specified in `update.json`.
+
+[mvnver]: ../gettingstarted/versioning.md
+[nocubes]: https://cadiboo.github.io/projects/nocubes/update.json
+[corail]: https://github.com/Corail31/tombstone_lite/blob/master/update.json
+[chisel]: https://github.com/Aeltumn/Chisels-and-Bits-2/blob/master/update.json
diff --git a/versioned_docs/version-1.21.3/networking/_category_.json b/versioned_docs/version-1.21.3/networking/_category_.json
new file mode 100644
index 00000000..31c81bdb
--- /dev/null
+++ b/versioned_docs/version-1.21.3/networking/_category_.json
@@ -0,0 +1,4 @@
+{
+    "label": "Networking",
+    "position": 11
+}
\ No newline at end of file
diff --git a/versioned_docs/version-1.21.3/networking/configuration-tasks.md b/versioned_docs/version-1.21.3/networking/configuration-tasks.md
new file mode 100644
index 00000000..87c3450f
--- /dev/null
+++ b/versioned_docs/version-1.21.3/networking/configuration-tasks.md
@@ -0,0 +1,133 @@
+---
+sidebar_position: 3
+---
+# Using Configuration Tasks
+
+The networking protocol for the client and server has a specific phase where the server can configure the client before the player actually joins the game. This phase is called the configuration phase, and is for example used by the vanilla server to send the resource pack information to the client.
+
+This phase can also be used by mods to configure the client before the player joins the game.
+
+## Registering a configuration task
+
+The first step to using the configuration phase is to register a configuration task. This can be done by registering a new configuration task in the `RegisterConfigurationTasksEvent` event.
+
+```java
+@SubscribeEvent
+public static void register(final RegisterConfigurationTasksEvent event) {
+    event.register(new MyConfigurationTask());
+}
+```
+
+The `RegisterConfigurationTasksEvent` event is fired on the mod bus, and exposes the current listener used by the server to configure the relevant client. A modder can use the exposed listener to figure out if the client is running the mod, and if so, register a configuration task.
+
+## Implementing a configuration task
+
+A configuration task is a simple interface: `ICustomConfigurationTask`. This interface has two methods: `void run(Consumer<CustomPacketPayload> sender);`, and `ConfigurationTask.Type type();` which returns the type of the configuration task. The type is used to identify the configuration task. An example of a configuration task is shown below:
+
+```java
+public record MyConfigurationTask implements ICustomConfigurationTask {
+    public static final ConfigurationTask.Type TYPE = new ConfigurationTask.Type(ResourceLocation.fromNamespaceAndPath("mymod", "my_task"));
+    
+    @Override
+    public void run(final Consumer<CustomPacketPayload> sender) {
+        final MyData payload = new MyData();
+        sender.accept(payload);
+    }
+
+    @Override
+    public ConfigurationTask.Type type() {
+        return TYPE;
+    }
+}
+```
+
+## Acknowledging a configuration task
+
+Your configuration is executed on the server, and the server needs to know when the next configuration task can be executed. This is done by acknowledging the execution of said configuration task.
+
+There are two primary ways of achieving this:
+
+### Capturing the listener
+
+When the client does not need to acknowledge the configuration task, then the listener can be captured, and the configuration task can be acknowledged directly on the server side.
+
+```java
+public record MyConfigurationTask(ServerConfigurationPacketListener listener) implements ICustomConfigurationTask {
+    public static final ConfigurationTask.Type TYPE = new ConfigurationTask.Type(ResourceLocation.fromNamespaceAndPath("mymod", "my_task"));
+    
+    @Override
+    public void run(final Consumer<CustomPacketPayload> sender) {
+        final MyData payload = new MyData();
+        sender.accept(payload);
+        this.listener().finishCurrentTask(this.type());
+    }
+
+    @Override
+    public ConfigurationTask.Type type() {
+        return TYPE;
+    }
+}
+```
+
+To use such a configuration task, the listener needs to be captured in the `RegisterConfigurationTasksEvent` event.
+
+```java
+@SubscribeEvent
+public static void register(final RegisterConfigurationTasksEvent event) {
+    event.register(new MyConfigurationTask(event.getListener()));
+}
+```
+
+Then the next configuration task will be executed immediately after the current configuration task has completed, and the client does not need to acknowledge the configuration task. Additionally, the server will not wait for the client to properly process the send payloads.
+
+### Acknowledging the configuration task
+
+When the client needs to acknowledge the configuration task, then you will need to send your own payload to the client:
+
+```java
+public record AckPayload() implements CustomPacketPayload {
+    public static final CustomPacketPayload.Type<AckPayload> TYPE = new CustomPacketPayload.Type<>(ResourceLocation.fromNamespaceAndPath("mymod", "ack"));
+    
+    // Unit codec with no data to write
+    public static final StreamCodec<ByteBuf, AckPayload> STREAM_CODEC = StreamCodec.unit(new AckPayload());
+
+    @Override
+    public CustomPacketPayload.Type<? extends CustomPacketPayload> type() {
+        return TYPE;
+    }
+}
+```
+
+When a payload from a server side configuration task is properly processed you can send this payload to the server to acknowledge the configuration task.
+
+```java
+public void onMyData(MyData data, IPayloadContext context) {
+    context.enqueueWork(() -> {
+        blah(data.name());
+    })
+    .exceptionally(e -> {
+        // Handle exception
+        context.disconnect(Component.translatable("my_mod.configuration.failed", e.getMessage()));
+        return null;
+    })
+    .thenAccept(v -> {
+        context.reply(new AckPayload());
+    });     
+}
+```
+
+Where `onMyData` is the handler for the payload that was sent by the server side configuration task.
+
+When the server receives this payload it will acknowledge the configuration task, and the next configuration task will be executed:
+
+```java
+public void onAck(AckPayload payload, IPayloadContext context) {
+    context.finishCurrentTask(MyConfigurationTask.TYPE);
+}
+```
+
+Where `onAck` is the handler for the payload that was sent by the client.
+
+## Stalling the login process
+
+When the configuration is not acknowledged, then the server will wait forever, and the client will never join the game. So it is important to always acknowledge the configuration task, unless the configuration task failed, then you can disconnect the client.
diff --git a/versioned_docs/version-1.21.3/networking/entities.md b/versioned_docs/version-1.21.3/networking/entities.md
new file mode 100644
index 00000000..80be9b6d
--- /dev/null
+++ b/versioned_docs/version-1.21.3/networking/entities.md
@@ -0,0 +1,30 @@
+---
+sidebar_position: 4
+---
+# Entities
+
+In addition to regular network messages, there are various other systems provided to handle synchronizing entity data.
+
+## Spawn Data
+
+Since 1.20.2 Mojang introduced the concept of Bundle packets, which are used to send entity spawn packets together. This allows for more data to be sent with the spawn packet, and for that data to be sent more efficiently.
+
+You can add extra data to the spawn packet NeoForge sends by implementing the following interface.
+
+### IEntityWithComplexSpawn
+
+If your entity has data that is needed on the client, but does not change over time, then it can be added to the entity spawn packet using this interface. `#writeSpawnData` and `#readSpawnData` control how the data should be encoded to/decoded from the network buffer. Alternatively you can override the method `IEntityExtension#sendPairingData` which is called when the entity's initial data is sent to the client. This method is called on the server, and can be used to send additional payloads to the client within the same bundle as the spawn packet.
+
+## Dynamic Data Parameters
+
+This is the main vanilla system for synchronizing entity data from the server to the client. As such, a number of vanilla examples are available to refer to.
+
+Firstly, you need a `EntityDataAccessor<T>` for the data you wish to keep synchronized. This should be stored as a `static final` field in your entity class, obtained by calling `SynchedEntityData#defineId` and passing the entity class and a serializer for that type of data. The available serializer implementations can be found as static constants within the `EntityDataSerializers` class.
+
+:::caution
+You should __only__ create data parameters for your own entities, _within that entity's class_. Adding parameters to entities you do not control can cause the IDs used to send that data over the network to become desynchronized, causing difficult to debug crashes.
+:::
+
+Then, override `Entity#defineSynchedData` and call `SynchedEntityData.Builder#define` for each of your data parameters, passing the parameter and an initial value to use. Remember to always call the `super` method first!
+
+You can then get and set these values via your entity's `entityData` instance. Changes made will be synchronized to the client automatically.
diff --git a/versioned_docs/version-1.21.3/networking/index.md b/versioned_docs/version-1.21.3/networking/index.md
new file mode 100644
index 00000000..32f57224
--- /dev/null
+++ b/versioned_docs/version-1.21.3/networking/index.md
@@ -0,0 +1,17 @@
+# Networking
+
+Communication between servers and clients is the backbone of a successful mod implementation.
+
+There are two primary goals in network communication:
+
+1. Making sure the client view is "in sync" with the server view
+    - The flower at coordinates (X, Y, Z) just grew
+1. Giving the client a way to tell the server that something has changed about the player
+    - the player pressed a key
+
+The most common way to accomplish these goals is to pass messages between the client and the server. These messages will usually be structured, containing data in a particular arrangement, for easy sending and receiving.
+
+There is a technique provided by NeoForge to facilitate communication mostly built on top of [netty]. This technique can be used by listening for the `RegisterPayloadHandlersEvent` event, and then registering a specific type of [payloads], its reader, and its handler function to the registrar.
+
+[netty]: https://netty.io "Netty Website"
+[payloads]: payload.md "Registering custom Payloads"
diff --git a/versioned_docs/version-1.21.3/networking/payload.md b/versioned_docs/version-1.21.3/networking/payload.md
new file mode 100644
index 00000000..d2a2bf45
--- /dev/null
+++ b/versioned_docs/version-1.21.3/networking/payload.md
@@ -0,0 +1,193 @@
+---
+sidebar_position: 1
+---
+# Registering Payloads
+
+Payloads are a way to send arbitrary data between the client and the server. They are registered using the `PayloadRegistrar` from the `RegisterPayloadHandlersEvent` event.
+
+```java
+@SubscribeEvent
+public static void register(final RegisterPayloadHandlersEvent event) {
+    // Sets the current network version
+    final PayloadRegistrar registrar = event.registrar("1");
+}
+```
+
+Assuming we want to send the following data:
+
+```java
+public record MyData(String name, int age) {}
+```
+
+Then we can implement the `CustomPacketPayload` interface to create a payload that can be used to send and receive this data.
+
+```java
+public record MyData(String name, int age) implements CustomPacketPayload {
+    
+    public static final CustomPacketPayload.Type<MyData> TYPE = new CustomPacketPayload.Type<>(ResourceLocation.fromNamespaceAndPath("mymod", "my_data"));
+
+    // Each pair of elements defines the stream codec of the element to encode/decode and the getter for the element to encode
+    // 'name' will be encoded and decoded as a string
+    // 'age' will be encoded and decoded as an integer
+    // The final parameter takes in the previous parameters in the order they are provided to construct the payload object
+    public static final StreamCodec<ByteBuf, MyData> STREAM_CODEC = StreamCodec.composite(
+        ByteBufCodecs.STRING_UTF8,
+        MyData::name,
+        ByteBufCodecs.VAR_INT,
+        MyData::age,
+        MyData::new
+    )
+    
+    @Override
+    public CustomPacketPayload.Type<? extends CustomPacketPayload> type() {
+        return TYPE;
+    }
+}
+```
+
+As you can see from the example above the `CustomPacketPayload` interface requires us to implement the `type` method. The `type` method is responsible for returning a unique identifier for this payload. We then also need a reader to register this later on with the `StreamCodec` to read and write the payload data.
+
+Finally, we can register this payload with the registrar:
+
+```java
+@SubscribeEvent
+public static void register(final RegisterPayloadHandlersEvent event) {
+    final PayloadRegistrar registrar = event.registrar("1");
+    registrar.playBidirectional(
+        MyData.TYPE,
+        MyData.STREAM_CODEC,
+        new DirectionalPayloadHandler<>(
+            ClientPayloadHandler::handleDataOnMain,
+            ServerPayloadHandler::handleDataOnMain
+        )
+    );
+}
+```
+
+Dissecting the code above we can notice a couple of things:
+- The registrar has `play*` methods, that can be used for registering payloads which are sent during the play phase of the game.
+    - Not visible in this code are the methods `configuration*` and `common*`; however, they can also be used to register payloads for the configuration phase. The `common` method can be used to register payloads for both the configuration and play phase simultaneously.
+- The registrar uses a `*Bidirectional` method, that can be used for registering payloads which are sent to both the logical server and logical client.
+    - Not visible in this code are the methods `*ToClient` and `*ToServer`; however, they can also be used to register payloads to only the logical client or only the logical server, respectively.
+- The type of the payload is used as a unique identifier for the payload.
+- The [stream codec][streamcodec] is used to read and write the payload to and from the buffer sent across the network
+- The payload handler is a callback for when the payload arrives on one of the logical sides.
+    - If a `*Bidirectional` method is used, a `DirectionalPayloadHandler` can be used to provide two separate payload handlers for each of the logical sides.
+
+Now that we have registered the payload we need to implement a handler. For this example we will specifically take a look at the client side handler, however the server side handler is very similar.
+
+```java
+public class ClientPayloadHandler {
+    
+    public static void handleDataOnMain(final MyData data, final IPayloadContext context) {
+        // Do something with the data, on the main thread
+        blah(data.age());
+    }
+}
+```
+
+Here a couple of things are of note:
+
+- The handling method here gets the payload, and a contextual object.
+- The handling method of the payload is, by default, invoked on the main thread.
+
+
+If you need to do some computation that is resource intensive, then the work should be done on the network thread, instead of blocking the main thread. This is done by setting the `HandlerThread` of the `PayloadRegistrar` to `HandlerThread#NETWORK` via `PayloadRegistrar#executesOn` before registering the payload.
+
+```java
+@SubscribeEvent
+public static void register(final RegisterPayloadHandlersEvent event) {
+    final PayloadRegistrar registrar = event.registrar("1")
+        .executesOn(HandlerThread.NETWORK); // All subsequent payloads will register on the network thread
+    registrar.playBidirectional(
+        MyData.TYPE,
+        MyData.STREAM_CODEC,
+        new DirectionalPayloadHandler<>(
+            ClientPayloadHandler::handleDataOnNetwork,
+            ServerPayloadHandler::handleDataOnNetwork
+        )
+    );
+}
+```
+
+:::note
+All payloads registered after an `executesOn` call will retain the same thread execution location until `executesOn` is called again.
+
+```java
+PayloadRegistrar registrar = event.registrar("1");
+
+registrar.playBidirectional(...); // On the main thread
+registrar.playBidirectional(...); // On the main thread
+
+// Configuration methods modify the state of the registrar
+// by creating a new instance, so the change needs to be
+/// updated by storing the result
+registrar = registrar.executesOn(HandlerThread.NETWORK);
+
+registrar.playBidirectional(...); // On the network thread
+registrar.playBidirectional(...); // On the network thread
+
+registrar = registrar.executesOn(HandlerThread.MAIN);
+
+registrar.playBidirectional(...); // On the main thread
+registrar.playBidirectional(...); // On the main thread
+```
+:::
+
+Here a couple of things are of note:
+
+- If you want to run code on the main game thread you can use `enqueueWork` to submit a task to the main thread.
+    - The method will return a `CompletableFuture` that will be completed on the main thread.
+    - Notice: A `CompletableFuture` is returned, this means that you can chain multiple tasks together, and handle exceptions in a single place.
+    - If you do not handle the exception in the `CompletableFuture` then it will be swallowed, **and you will not be notified of it**.
+
+```java
+public class ClientPayloadHandler {
+    
+    public static void handleDataOnNetwork(final MyData data, final IPayloadContext context) {
+        // Do something with the data, on the network thread
+        blah(data.name());
+        
+        // Do something with the data, on the main thread
+        context.enqueueWork(() -> {
+            blah(data.age());
+        })
+        .exceptionally(e -> {
+            // Handle exception
+            context.disconnect(Component.translatable("my_mod.networking.failed", e.getMessage()));
+            return null;
+        });
+    }
+}
+```
+
+With your own payloads you can then use those to configure the client and server using [Configuration Tasks][configuration].
+
+## Sending Payloads
+
+`CustomPacketPayload`s are sent across the network using vanilla's packet system by wrapping the payload via `ServerboundCustomPayloadPacket` when sending to the server, or `ClientboundCustomPayloadPacket` when sending to the client. Payloads sent to the client can only contain at most 1 MiB of data while payloads to the server can only contain less than 32 KiB. 
+
+All payloads are sent via `Connection#send` with some level of abstraction; however, it is generally inconvenient to call these methods if you want to send packets to multiple people based on a given condition. Therefore, `PacketDistributor` contains a number of convenience implementations to send payloads. There is only one method to send packets to the server (`sendToServer`); however, there are numerous methods to send packets to the client depending on which players should receive the payload.
+
+```java
+// ON THE CLIENT
+
+// Send payload to server
+PacketDistributor.sendToServer(new MyData(...));
+
+// ON THE SERVER
+
+// Send to one player (ServerPlayer serverPlayer)
+PacketDistributor.sendToPlayer(serverPlayer, new MyData(...));
+
+/// Send to all players tracking this chunk (ServerLevel serverLevel, ChunkPos chunkPos)
+PacketDistributor.sendToPlayersTrackingChunk(serverLevel, chunkPos, new MyData(...));
+
+/// Send to all connected players
+PacketDistributor.sendToAllPlayers(new MyData(...));
+```
+
+See the `PacketDistributor` class for more implementations.
+
+[configuration]: configuration-tasks.md
+[streamcodec]: streamcodecs.md
diff --git a/versioned_docs/version-1.21.3/networking/streamcodecs.md b/versioned_docs/version-1.21.3/networking/streamcodecs.md
new file mode 100644
index 00000000..91ff7456
--- /dev/null
+++ b/versioned_docs/version-1.21.3/networking/streamcodecs.md
@@ -0,0 +1,383 @@
+---
+sidebar_position: 2
+---
+# Stream Codecs
+
+Stream codecs are a serialization tool used to describe how an object should be stored and read from a stream, such as buffers. Stream codecs are primarly used by Vanilla's [networking system][networking] to sync data.
+
+:::info
+As stream codecs are roughly analagous to [codecs], this page has been formatted in the same way to show the similarities.
+:::
+
+## Using Stream Codecs
+
+Stream codecs encode and decode objects into some stream using `StreamCodec#encode` and `StreamCodec#decode`, respectively. `encode` takes in the stream and the object to encode into the stream. `decode` takes in the stream and returns the decoded object. Typically, the stream is either a `ByteBuf`, `FriendlyByteBuf`, or `RegistryFriendlyByteBuf`.
+
+```java
+// Let exampleStreamCodec represent a StreamCodec<ExampleJavaObject>
+// Let exampleObject be a ExampleJavaObject
+// Let buffer be a RegistryFriendlyByteBuf
+
+// Encode Java object into the buffer stream
+exampleStreamCodec.encode(buffer, exampleObject);
+
+// Read Java object from buffer stream
+ExampleJavaObject obj = exampleStreamCodec.decode(buffer);
+```
+
+:::note
+Unless you are manually handling the buffer object, you will generally never call `encode` and `decode`.
+:::
+
+## Existing Stream Codecs
+
+### `ByteBufCodecs`
+
+`ByteBufCodecs` contains static instances of codecs for certain primitives and objects.
+
+| Stream Codec   | Java Type     |
+|----------------|---------------|
+| `BOOL`         | `Boolean`     |
+| `BYTE`         | `Byte`        |
+| `SHORT`        | `Short`       |
+| `INT`          | `Integer`     |
+| `LONG`         | `Long`        |
+| `FLOAT`        | `Float`       |
+| `DOUBLE`       | `Double`      |
+| `BYTE_ARRAY`   | `byte[]`\*    |
+| `STRING_UTF8`  | `String`\*\*  |
+| `TAG`          | `Tag`         |
+| `COMPOUND_TAG` | `CompoundTag` |
+| `VECTOR3F`     | `Vector3f`    |
+| `QUATERNIONF`  | `Quaternionf` |
+| `GAME_PROFILE` | `GameProfile` |
+
+\* `byte[]` can be limited to a certain number of values via `ByteBufCodecs#byteArray`.
+
+\*\* `String` can be limited to a certain number of characters via `ByteBufCodecs#stringUtf8`.
+
+Additionally, there are some static instances that encode and decode primivites and objects using a different method.
+
+#### Unsigned Shorts
+
+`UNSIGNED_SHORT` is an alternative of `SHORT` that is meant to be treated as an unsigned number. As numbers are signed in Java, unsigned shorts are sent and received as `Integer`s with the upper two bytes masked out.
+
+#### Variable-Sized Number
+
+`VAR_INT` and `VAR_LONG` are stream codecs where the value is encoded to be as small as possible. This is done by encoding seven bits at a time, using the upper bit as a marker of whether there is more data for this number. Numbers between 0 and 2^28-1 for integers or 0 and 2^56-1 for longs will be sent shorter or equal to the number of bytes in a integer or long, respectively. If the values of your numbers are normally in this range and generally at the lower end of it, then these variable stream codecs should be used.
+
+:::note
+`VAR_INT` and `VAR_LONG` are alternatives for `INT` and `LONG`, respectively.
+:::
+
+#### Trusted Tags
+
+`TRUSTED_TAG` and `TRUSTED_COMPOUND_TAG` are variants of `TAG` and `COMPOUND_TAG`, respectively, that have an unlimited heap to decode the tag to, compared to the 2MiB limit of `TAG` and `COMPOUND_TAG`. Trusted tag stream codecs should ideally only be used in clientbound packets, such as what Vanilla does for [block entity data packet][blockentity] and [entity data serializers][entityserializer].
+
+If a different limit should be used, then a `NbtAccounter` can be supplied with the given size using `ByteBufCodecs#tagCodec` or `#compoundTagCodec`.
+
+### Vanilla and NeoForge
+
+Minecraft and NeoForge define many stream codecs for objects that are frequently encoded and decoded. Some examples include `ResourceLocation#STREAM_CODEC` for `ResourceLocation`s or `NeoForgeStreamCodecs#CHUNK_POS` for `ChunkPos`s.
+
+Most of the stream codecs can be found within the object class itself or within `StreamCodec`, `ByteBufCodecs`, or `NeoForgeStreamCodecs`. 
+
+## Creating Stream Codecs
+
+Stream codecs can be created for reading or writing any object to a stream. This documentation will focus on the stream as a buffer as that is its primary purpose.
+
+Stream codecs have two generics: `B` representing the buffer and `V` representing the object value. `B` is generally one of three types: `ByteBuf`, `FriendlyByteBuf`, `RegistryFriendlyByteBuf`, each extending one another. `FriendlyByteBuf` adds Minecraft-specific read and write methods while `RegistryFriendlyByteBuf` provides access to the list of registries and its objects.
+
+When constructing a stream codec, `B` should be the least-specific buffer type. For example, a `ResourceLocation` is sent as a string. As strings are supported by a regular `ByteBuf`, its type should be `StreamCodec<ByteBuf, ResourceLocation>`. `FriendlyByteBuf` contains methods for writing a `ChunkPos`, so its type should be `StreamCodec<FriendlyByteBuf, ChunkPos>`. An `Item` needs access to the registry, so its type should be `StreamCodec<RegistryFriendlyByteBuf, Item>`.
+
+Most methods that take in a stream codec look for `? super B` for the buffer type, meaning that all three of the above examples can be used if the buffer type is a `RegistryFriendlyByteBuf`.
+
+### Member Encoders
+
+`StreamMemberEncoder` is an alternative to `StreamEncoder` where the encoding object comes first and the buffer second. This is typically used when the encoding object contains an instance method to write the object to the buffer. A `StreamMemberEncoder` can be used to create the `StreamCodec` by calling `StreamCodec#ofMember`.
+
+```java
+// Some object to create a stream codec for
+public class ExampleObject {
+    
+    // The normal constructor
+    public ExampleObject(String arg1, int arg2, boolean arg3) { /* ... */ }
+
+    // The stream decoder reference
+    public ExampleObject(ByteBuf buffer) { /* ... */ }
+
+    // The stream encoder reference
+    public void encode(ByteBuf buffer) { /* ... */ }
+}
+
+// What the stream codec would look like
+public static StreamCodec<ByteBuf, ExampleObject> =
+    StreamCodec.ofMember(ExampleObject::encode, ExampleObject::new);
+```
+
+### Composites
+
+Stream codecs can read and write objects via `StreamCodec#composite`. Each composite stream codec defines a list of stream codecs and getters which are read/written in the order they are provided. `composite` has overloads up to eight parameters.
+
+Every two parameters in a `composite` represents the stream codec used to read/write the field and a getter to get the field to encode from the object. The final parameter is a function to create a new instance of the object when decoding.
+
+```java
+// Objects to create a stream codec for
+public record SimpleExample(String arg1, int arg2, boolean arg3) {}
+public record RegistryExample(double arg1, Holder<Item> arg2) {}
+
+// The stream codecs
+public static final StreamCodec<ByteBuf, SimpleExample> SIMPLE_STREAM_CODEC =
+    StreamCodec.composite(
+        // Stream codec and getter pair
+        ByteBufCodecs.STRING_UTF8, SimpleExample::arg1,
+        ByteBufCodecs.VAR_INT, SimpleExample::arg2,
+        ByteBufCodecs.BOOL, SimpleExample::arg3,
+        SimpleExample::new
+    );
+
+// Since this has a holder, a RegistryFriendlyByteBuf is used
+public static final StreamCodec<RegistryFriendlyByteBuf, RegistryExample> REGISTRY_STREAM_CODEC =
+    StreamCodec.composite(
+        // Note that ByteBuf stream codecs can be used here
+        ByteBufCodecs.DOUBLE, RegistryExample::arg1,
+        ByteBufCodecs.holderRegistry(Registries.ITEM), RegistryExample::arg2,
+        RegistryExample::new
+    );
+```
+
+### Transformers
+
+Stream codecs can be transformed into equivalent, or partially equivalent, representations using mapping methods. Two mapping methods apply to the value while one mapping method applies to the buffer.
+
+The `map` method transforms the value using two functions: one to transform the current type into the new type, and one to transform the new type back into the current type. This is analagous to [codec transformers][transformers].
+
+```java
+public static final StreamCodec<ByteBuf, ResourceLocation> STREAM_CODEC = 
+    ByteBufCodecs.STRING_UTF8.map(
+        // String -> ResourceLocation
+        ResourceLocation::new,
+        // ResourceLocation -> String
+        ResourceLocation::toString
+    );
+```
+
+The `apply` method transforms the value using a `StreamCodec.CodecOperation`. A `StreamCodec.CodecOperation` takes in a stream codec of the current type and returns a stream codec of the new type. These typically wrap around `map` or take in helper methods.
+
+```java
+public static final StreamCodec<ByteBuf, List<ResourceLocation>> STREAM_CODEC =
+    ResourceLocation.STREAM_CODEC.apply(ByteBufCodecs.list());
+```
+
+The `mapStream` method transforms the buffer using a function that takes in the new buffer type and returns the current buffer type. This method should rarely be used as most methods with stream codecs do not need to change the type of the buffer.
+
+```java
+public static final StreamCodec<RegistryFriendlyByteBuf, Integer> STREAM_CODEC =
+    ByteBufCodecs.VAR_INT.mapStream(buffer -> (ByteBuf) buffer);
+```
+
+### Unit
+
+A stream codec which supplies an in-code value and encodes to nothing can be represented using `StreamCodec#unit`. This is useful if no information should be synced across the network.
+
+:::warning
+Unit stream codecs expect that any encoded object must match the unit specified; otherwise an error will be thrown. Therefore, all objects must have some `equals` implementation that returns true for the unit object, or that the instance provided to the stream codec is always provided when encoding.
+:::
+
+```java
+public static final StreamCodec<ByteBuf, Item> UNIT_STREAM_CODEC =
+    StreamCodec.unit(Items.AIR);
+```
+### Lazy Initialized
+
+Sometimes, a stream codec may rely on data that is not present when it is constructed. In these situations `NeoForgeStreamCodecs#lazy` can be used for a stream codec to construct itself on first read/write. The method takes in a supplied stream codec.
+
+```java
+public static final StreamCodec<ByteBuf, Item> LAZY_STREAM_CODEC = 
+    NeoForgeStreamCodecs.lazy(
+        () -> StreamCodec.unit(Items.AIR)
+    );
+```
+
+### Collections
+
+A stream codec for collections can be generated from a object stream codec via `collection`. `collection` takes in an `IntFunction` that constructs the empty collection, a stream codec of the object, and an optional maximum size.
+
+```java
+public static final StreamCodec<ByteBuf, Set<BlockPos>> COLLECTION_STREAM_CODEC =
+    ByteBufCodecs.collection(
+        HashSet::new, // Constructs a set with the specified capacity
+        BlockPos.STREAM_CODEC,
+        256 // The set can only have up to 256 elements
+    );
+```
+
+Another overload of `collection` can be specified with `StreamCodec#apply`.
+
+```java
+public static final StreamCodec<ByteBuf, Set<BlockPos>> COLLECTION_STREAM_CODEC =
+    BlockPos.STREAM_CODEC.apply(
+        ByteBufCodecs.collection(HashSet::new)
+    );
+```
+
+List-based collections also can be specified through `StreamCodec#apply` by calling `ByteBufCodecs#list` with an optional maximum size.
+
+```java
+public static final StreamCodec<ByteBuf, List<BlockPos>> LIST_STREAM_CODEC =
+    BlockPos.STREAM_CODEC.apply(
+        // The list can only have up to 256 elements
+        ByteBufCodecs.list(256)
+    );
+```
+
+### Map
+
+A stream codec for a map of key and value objects can be generated using two stream codecs via `ByteBufCodecs#map`. The function also takes in an `IntFunction` that constructs the empty map and an optional maximum size.
+
+```java
+public static final StreamCodec<ByteBuf, Map<String, BlockPos>> MAP_STREAM_CODEC =
+    ByteBufCodecs.map(
+        HashMap::new, // Constructs a map with the specified capacity
+        ByteBufCodecs.STRING_UTF8,
+        BlockPos.STREAM_CODEC,
+        256 // The map can only have up to 256 elements
+    );
+```
+
+### Either
+
+A stream codec for two different methods of reading/writing some object data can be generated from two steram codecs via `ByteBufCodecs#either`. This method first reads/writes a boolean indicating whether to read/write the first or second stream codec, respectively.
+
+```java
+public static final StreamCodec<ByteBuf, Either<Integer, String>> EITHER_STREAM_CODEC = 
+    ByteBufCodecs.either(
+        ByteBufCodecs.VAR_INT,
+        ByteBufCodecs.STRING_UTF8
+    );
+```
+
+### Id Mapper
+
+In most cases, when sending information across the network where an object is present on both sides, an integer representing an id is sent. Ids representing an object reduce the amount of information that need to be synced across the network. Both enums and registries make use of this.
+
+`ByteBufCodecs#idMapper` provides a convenient way to send ids for objects. It either takes in two functions which convert an object to int and vice versa, or an `IdMap`.
+
+```java
+// For some enum
+public enum ExampleIdObject {
+    ;
+
+    // Gets Id -> Enum
+    public static final IntFunction<ExampleIdObject> BY_ID = 
+        ByIdMap.continuous(
+            ExampleIdObject::getId,
+            ExampleIdObject.values(),
+            ByIdMap.OutOfBoundsStrategy.ZERO
+    );
+    
+    ExampleIdObject(int id) { /* ... */ }
+}
+
+// The stream codec would look like
+public static final StreamCodec<ByteBuf, ExampleIdObject> ID_STREAM_CODEC =
+    ByteBufCodecs.idMapper(ExampleIdObject.BY_ID, ExampleIdObject::getId);
+```
+
+### Optional
+
+A stream codec for sending an `Optional` wrapped value can be generated by supplying a stream codec to `ByteBufCodecs#optional`. This method first reads/writes a boolean indicating whether to read/write the object.
+
+```java
+public static final StreamCodec<RegistryFriendlyByteBuf, Optional<DataComponentType<?>>> OPTIONAL_STREAM_CODEC =
+    DataComponentType.STREAM_CODEC.apply(ByteBufCodecs::optional);
+```
+
+### Registry Objects
+
+Registry objects can be sent across the network using one of three methods: `registry`, `holderRegistry`, or `holder`. Each takes in a `ResourceKey` representing the registry the registry object is in.
+
+:::warning
+Custom registries must be syncable by calling `RegistryBuilder#sync` and setting the value to `true`. Otherwise, the encoder will throw an exception.
+:::
+
+`registry` and `holderRegistry` returns the registry object or a holder wrapped registry object, respectively. These methods send over an id representing the registry object.
+
+```java
+// Registry object
+public static final StreamCodec<RegistryFriendlyByteBuf, Item> VALUE_STREAM_CODEC =
+    BytebufCodecs.registry(Registries.ITEM);
+
+// Holder of registry object
+public static final StreamCodec<RegistryFriendlyByteBuf, Holder<Item>> HOLDER_STREAM_CODEC =
+    BytebufCodecs.holderRegistry(Registries.ITEM);
+```
+
+`holder` returns a holder wrapped registry object. This method sends over an id representing the registry object, or the registry object itself if the provided `Holder` is a direct reference. To do so, `holder` also takes in the stream codec of the registry object.
+
+```java
+public static final StreamCodec<RegistryFriendlyByteBuf, Holder<SoundEvent>> STREAM_CODEC =
+    ByteBufCodecs.holder(
+        Registries.SOUND_EVENT, SoundEvent.DIRECT_STREAM_CODEC
+    );
+```
+
+:::note
+`holder` will only throw an exception for a non-synced custom registry if the holder is not direct.
+:::
+
+### Holder Sets
+
+Tags or sets of holder wrapped registry objects can be sent using `holderSet`. This takes in a `ResourceKey` representing the registry the registry objects are in.
+
+```java
+public static final StreamCodec<RegistryFriendlyByteBuf, HolderSet<Item>> HOLDER_SET_STREAM_CODEC =
+    BytebufCodecs.holderSet(Registries.ITEM);
+```
+
+### Recursive
+
+Sometimes, an object may reference an object of the same type as a field. For example, `MobEffectInstance` takes in an optional `MobEffectInstance` if there is a hidden effect. In this case, `StreamCodec#recursive` can be used to supply the stream codec as part of a function to create the stream codec.
+
+```java
+// Define our recursive object
+public record RecursiveObject(Optional<RecursiveObject> inner) { /* ... */ }
+
+public static final StreamCodec<ByteBuf, RecursiveObject> RECURSIVE_CODEC = StreamCodec.recursive(
+    recursedStreamCodec -> StreamCodec.composite(
+        recursedStreamCodec.apply(ByteBufCodecs::optional),
+        RecursiveObject::inner,
+        RecursiveObject::new
+    )
+);
+```
+
+### Dispatch
+
+Stream codecs can have sub-stream codecs that can decode a particular object based on some specified type via `StreamCodec#dispatch`. This is typically used with registry objects that represent a type, like `ParticleType` for `ParticleOptions` or `StatType` for `Stat`s.
+
+A dispatch stream codec first attempts to read/write the type object. From there, the current object is read/written using one of the functions provided in the method. The first `Function` takes in the current object and gets the type to write the value. The second `Function` takes in the type object and gets the `StreamCodec` for the current object to read the value.
+
+```java
+// Define our object(s)
+public abstract class ExampleObject {
+
+    // Define the method used to specify the object type for encoding
+    public abstract StreamCodec<? super RegistryFriendlyByteBuf, ? extends ExampleObject> streamCodec();
+}
+
+// Assume there is a ResourceKey<StreamCodec<? super RegistryFriendlyByteBuf, ? extends ExampleObject>> DISPATCH
+public static final StreamCodec<RegistryFriendlyByteBuf, ExampleObject> DISPATCH_STREAM_CODEC =
+    ByteBufCodecs.registry(DISPATCH).dispatch(
+        // Get the stream codec from the specific object
+        ExampleObject::streamCodec,
+        // Get the stream codec from the registry object
+        Function.identity()
+    );
+```
+
+[networking]: payload.md
+[codecs]: ../datastorage/codecs.md
+[blockentity]: ../blockentities/index.md#synchronizing-on-block-update
+[entityserializer]: ../networking/entities.md#dynamic-data-parameters
+[transformers]: ../datastorage/codecs.md#transformers
diff --git a/versioned_docs/version-1.21.3/resources/_category_.json b/versioned_docs/version-1.21.3/resources/_category_.json
new file mode 100644
index 00000000..5f05cd31
--- /dev/null
+++ b/versioned_docs/version-1.21.3/resources/_category_.json
@@ -0,0 +1,4 @@
+{
+    "label": "Resources",
+    "position": 7
+}
\ No newline at end of file
diff --git a/versioned_docs/version-1.21.3/resources/client/_category_.json b/versioned_docs/version-1.21.3/resources/client/_category_.json
new file mode 100644
index 00000000..c1b8c6d9
--- /dev/null
+++ b/versioned_docs/version-1.21.3/resources/client/_category_.json
@@ -0,0 +1,3 @@
+{
+    "label": "Client"
+}
\ No newline at end of file
diff --git a/versioned_docs/version-1.21.3/resources/client/i18n.md b/versioned_docs/version-1.21.3/resources/client/i18n.md
new file mode 100644
index 00000000..c66292df
--- /dev/null
+++ b/versioned_docs/version-1.21.3/resources/client/i18n.md
@@ -0,0 +1,190 @@
+# I18n and L10n
+
+I18n (short for internationalization) is the way of designing a program to work with multiple languages. L10n (short for localization) is the process of translating text into the user's language. Minecraft implements these using `Component`s.
+
+## `Component`s
+
+A `Component` is a piece of text with metadata, with the metadata including things such as text formatting. It can be created in one of the following ways (all of the following are static methods in the `Component` interface):
+
+| Method         | Description                                                                                           |
+|----------------|-------------------------------------------------------------------------------------------------------|
+| `empty`        | Creates an empty component.                                                                           |
+| `literal`      | Creates a component with the given text and directly displays that text without translating.          |
+| `nullToEmpty`  | Creates an empty component when given null, and a literal component otherwise.                        |
+| `translatable` | Creates a translatable component. The given string is then resolved as a translation key (see below). |
+| `keybind`      | Creates a component containing the (translated) display name of the given keybind.                    |
+| `nbt`          | Creates a component representing the [NBT][nbt] at the given path.                                    |
+| `score`        | Creates a component containing a scoreboard objective value.                                          |
+| `selector`     | Creates a component containing a list of entity names for a given [entity selector][selector].        |
+
+`Component.translatable()` additionally has a vararg parameter that accepts string interpolation elements. This works similar to Java's `String#format`, but always uses `%s` instead of `%i`, `%d`, `%f` and any other format specifier, calling `#toString()` where needed.
+
+Every `Component` can be resolved using `#getString()`. Resolving is generally lazy, meaning that the server can specify a `Component`, send it to the clients, and the clients will each resolve the `Component`s on their own (where different languages may result in different text). Many places in Minecraft will also directly accept `Component`s and take care of resolving for you.
+
+:::caution
+Never let a server translate a `Component`. Always send `Component`s to the client and resolve them there.
+:::
+
+### `MutableComponent`
+
+All constructed components are generally `MutableComponent`s. A `MutableComponent` provides methods to add new component siblings that are appended to the end of this component and set the [style] of the text. Constructing or modifying a component should always refer to `MutableComponent`s.
+
+### Text Formatting
+
+`Component`s can be formatted using `Style`s. `Style`s are immutable, creating a new `Style` object when modified, and thus allowing them to be created once and then be reused as needed.
+
+:::note
+Styles can only be set using methods on `MutableComponent`, so make sure to check that the `Component` is a `MutableComponent`.
+:::
+
+`Style.EMPTY` can generally be used as a base to work off. Multiple `Style`s can be merged with `Style#applyTo(Style other)`, which returns a new `Style` that takes settings from the `Style` the `applyTo()` method was called on unless the respective setting is absent, in which case the setting from the `Style` passed in as a parameter is used. `Style`s can then be applied to components like so:
+
+```java
+MutableComponent text = Component.literal("Hello World!");
+
+// Create a new style.
+Style blue = Style.EMPTY.withColor(0x0000FF);
+// Styles use a builder-like pattern.
+Style blueItalic = Style.EMPTY.withColor(0x0000FF).withItalic(true);
+// Besides italic, we can also make styles bold, underlined, strikethrough, or obfuscated.
+Style bold          = Style.EMPTY.withBold(true);
+Style underlined    = Style.EMPTY.withUnderlined(true);
+Style strikethrough = Style.EMPTY.withStrikethrough(true);
+Style obfuscated    = Style.EMPTY.withObfuscated(true);
+// Let's merge some styles together!
+Style merged = blueItalic.applyTo(bold).applyTo(strikethrough);
+
+// Set a style on a component.
+text.setStyle(merged);
+// Merge a new style into it.
+text.withStyle(Style.EMPTY.withColor(0xFF0000));
+```
+
+Another, more elaborate option of formatting is to use click and hover events:
+
+```java
+// We have a total of 6 options for a click event, and a total of 3 options for a hover event.
+ClickEvent clickEvent;
+HoverEvent hoverEvent;
+
+// Opens the given URL in your default browser when clicked.
+clickEvent = new ClickEvent(ClickEvent.Action.OPEN_URL, "http://example.com/");
+// Opens the given file when clicked. For security reasons, this cannot be sent from a server.
+clickEvent = new ClickEvent(ClickEvent.Action.OPEN_FILE, "C:/example.txt");
+// Runs the given command when clicked.
+clickEvent = new ClickEvent(ClickEvent.Action.RUN_COMMAND, "/gamemode creative");
+// Suggests the given command in the chat when clicked.
+clickEvent = new ClickEvent(ClickEvent.Action.SUGGEST_COMMAND, "/gamemode creative");
+// Changes a book page when clicked. Irrelevant outside of a book screen context.
+clickEvent = new ClickEvent(ClickEvent.Action.CHANGE_PAGE, "1");
+// Copies the given text to the clipboard.
+clickEvent = new ClickEvent(ClickEvent.Action.COPY_TO_CLIPBOARD, "Hello World!");
+
+// Shows the given component when hovered. May be formatted as well.
+// Keep in mind that click or hover events won't work in a hover tooltip for obvious reasons.
+hoverEvent = new HoverEvent(HoverEvent.Action.SHOW_TEXT, Component.literal("Hello World!"));
+// Shows a complete tooltip of the given item stack when hovered.
+// See the possible constructors of ItemStackInfo.
+hoverEvent = new HoverEvent(HoverEvent.Action.SHOW_ITEM, new HoverEvent.ItemStackInfo(...));
+// Shows a complete tooltip of the given entity when hovered.
+// See the possible constructors of EntityTooltipInfo.
+hoverEvent = new HoverEvent(HoverEvent.Action.SHOW_ENTITY, new HoverEvent.EntityTooltipInfo(...));
+
+// Apply the events to a style.
+Style clickable = Style.EMPTY.withClickEvent(clickEvent);
+Style hoverable = Style.EMPTY.withHoverEvent(hoverEvent);
+```
+
+## Language Files
+
+Language files are JSON files that contain mappings from translation keys (see below) to actual names. They are located at `assets/<modid>/lang/language_name.json`. For example, US English translations for a mod with id `examplemod` would be located at `assets/examplemod/lang/en_us.json`. A full list of languages supported by Minecraft can be found [here][mcwikilang].
+
+A language file generally looks like this:
+
+```json
+{
+    "translation.key.1": "Translation 1",
+    "translation.key.2": "Translation 2"
+}
+```
+
+### Translation Keys
+
+Translation keys are the keys used in translations. In many cases, they follow the format `registry.modid.name`. For example, a mod with the id `examplemod` that provides a block named `example_block` will probably want to provide translations for the key `block.examplemod.example_block`. However, you can use basically any string as a translation key.
+
+If a translation key does not have an associated translation in the selected language, the game will fall back to US English (`en_us`), if that is not already the selected language. If US English does not have a translation either, the translation will fail silently, and the raw translation key will be displayed instead.
+
+Some places in Minecraft offer you helper methods to get a translation keys. For example, both blocks and items provide `#getDescriptionId` methods. For items, these can not only be queried, but also changed if needed via `Item$Properties#overrideDescription`. If items have different names depending on their underlying [data components][datacomponent], these can be overriden by setting the `CUSTOM_NAME` data component with the desired translatable component on the `ItemStack`. There is also a variant on the `Item#getName` which takes in an [`ItemStack`][itemstack] parameter to set the default component of the item. `BlockItem`s, on the other hand, set the description id by calling `Item$Properties#useBlockDescriptionPrefix`.
+
+:::tip
+The only purpose of translation keys is for localization. Do not use them for game logic, that's what [registry names][regname] are for.
+:::
+
+### Translating Mod Metadata
+
+Starting with NeoForge 20.4.179, translation files can override certain parts of [mod info][modstoml] using the following keys (where `modid` is to be replaced with the actual mod id):
+
+|              | Translation Key                        | Overriding                                                                   |
+|--------------|----------------------------------------|------------------------------------------------------------------------------|
+| Description  | `fml.menu.mods.info.description.modid` | A field named `description` may be placed in the `[[mods]]` section instead. |
+
+### Datagen
+
+Language files can be [datagenned][datagen]. To do so, extend the `LanguageProvider` class and add your translations in the `addTranslations()` method:
+
+```java
+public class MyLanguageProvider extends LanguageProvider {
+    public MyLanguageProvider(PackOutput output) {
+        super(
+            // Provided by the GatherDataEvent.
+            output,
+            // Your mod id.
+            "examplemod",
+            // The locale to use. You may use multiple language providers for different locales.
+            "en_us"
+        );
+    }
+    
+    @Override
+    protected void addTranslations() {
+        // Adds a translation with the given key and the given value.
+        this.add("translation.key.1", "Translation 1");
+        
+        // Helpers are available for various common object types. Every helper has two variants: an add() variant
+        // for the object itself, and an addTypeHere() variant that accepts a supplier for the object.
+        // The different names for the supplier variants are required due to generic type erasure.
+        // All following examples assume the existence of the values as suppliers of the needed type.
+
+        // Adds a block translation.
+        this.add(MyBlocks.EXAMPLE_BLOCK.get(), "Example Block");
+        this.addBlock(MyBlocks.EXAMPLE_BLOCK, "Example Block");
+        // Adds an item translation.
+        this.add(MyItems.EXAMPLE_ITEM.get(), "Example Item");
+        this.addItem(MyItems.EXAMPLE_ITEM, "Example Item");
+        // Adds an item stack translation. This is mainly for items that have NBT-specific names.
+        this.add(MyItems.EXAMPLE_ITEM_STACK.get(), "Example Item");
+        this.addItemStack(MyItems.EXAMPLE_ITEM_STACK, "Example Item");
+        // Adds an entity type translation.
+        this.add(MyEntityTypes.EXAMPLE_ENTITY_TYPE.get(), "Example Entity");
+        this.addEntityType(MyEntityTypes.EXAMPLE_ENTITY_TYPE, "Example Entity");
+        // Adds an enchantment translation.
+        this.add(MyEnchantments.EXAMPLE_ENCHANTMENT.get(), "Example Enchantment");
+        this.addEnchantment(MyEnchantments.EXAMPLE_ENCHANTMENT, "Example Enchantment");
+        // Adds a mob effect translation.
+        this.add(MyMobEffects.EXAMPLE_MOB_EFFECT.get(), "Example Effect");
+        this.addEffect(MyMobEffects.EXAMPLE_MOB_EFFECT, "Example Effect");
+    }
+}
+```
+
+Then, register the provider like any other provider in the `GatherDataEvent`.
+
+[datacomponent]: ../../items/datacomponents.md
+[datagen]: ../index.md#data-generation
+[itemstack]: ../../items/index.md#itemstacks
+[mcwikilang]: https://minecraft.wiki/w/Language
+[modstoml]: ../../gettingstarted/modfiles.md#modstoml
+[nbt]: ../../datastorage/nbt.md
+[regname]: ../../concepts/registries.md
+[selector]: https://minecraft.wiki/w/Target_selectors
+[style]: #text-formatting
diff --git a/versioned_docs/version-1.21.3/resources/client/models/bakedmodel.md b/versioned_docs/version-1.21.3/resources/client/models/bakedmodel.md
new file mode 100644
index 00000000..99a9089b
--- /dev/null
+++ b/versioned_docs/version-1.21.3/resources/client/models/bakedmodel.md
@@ -0,0 +1,137 @@
+# Baked Models
+
+`BakedModel`s are the in-code representation of a shape with textures. They can originate from multiple sources, for example from a call to `UnbakedModel#bake` (default model loader) or `IUnbakedGeometry#bake` ([custom model loaders][modelloader]). Some [block entity renderers][ber] also make use of baked models. There is no limit to how complex a model may be.
+
+Models are stored in the `ModelManager`, which can be accessed through `Minecraft.getInstance().modelManager`. Then, you can call `ModelManager#getModel` to get a certain model by its [`ModelResourceLocation`][mrl]. Mods will basically always reuse a model that was previously automatically loaded and baked.
+
+## Methods of `BakedModel`
+
+### `getQuads`
+
+The most important method of a baked model is `getQuads`. This method is responsible for returning a list of `BakedQuad`s, which can then be sent to the GPU. A quad compares to a triangle in a modeling program (and in most other games), however due to Minecraft's general focus on squares, the developers elected to use quads (4 vertices) instead of triangles (3 vertices) for rendering in Minecraft. `getQuads` has five parameters that can be used:
+
+- A `BlockState`: The [blockstate] being rendered. May be null, indicating that an item is being rendered.
+- A `Direction`: The direction of the face being culled against. May be null, which means quads that cannot be occluded should be returned.
+- A `RandomSource`: A client-bound random source you can use for randomization.
+- A `ModelData`: The extra model data to use. This may contain additional data from the block entity needed for rendering. Supplied by `BakedModel#getModelData`.
+- A `RenderType`: The [render type][rendertype] to use for rendering the block. May be null, indicating that the quads for all render types used by this model should be returned. Otherwise, it is one of the render types returned by `BakedModel#getRenderTypes` (see below).
+
+Models should heavily cache. This is because even though chunks are only rebuilt when a block in them changes, the computations done in this method still need to be as fast as possible and should ideally be cached heavily due to the amount of times this method will be called per chunk section (up to seven times per RenderType used by a given model * amount of RenderTypes used by the respective model * 4096 blocks per chunk section). In addition, [BERs][ber] or entity renderers may actually call this method several times per frame.
+
+### `applyTransform` and `getTransforms`
+
+`applyTransform` allows for applying custom logic when applying perspective transformations to the model, including returning a completely separate model. This method is added by NeoForge as a replacement for the vanilla `getTransforms()` method, which only allows you to customize the transforms themselves, but not the way they are applied. However, `applyTransform`'s default implementation defers to `getTransforms`, so if you only need custom transforms, you can also override `getTransforms` and be done with it. `applyTransforms` offers three parameters:
+
+- An `ItemDisplayContext`: The [perspective] the model is being transformed to.
+- A `PoseStack`: The pose stack used for rendering.
+- A `boolean`: Whether to use modified values for left-hand rendering instead of the default right hand rendering; `true` if the rendered hand is the left hand (off hand, or main hand if left hand mode is enabled in the options)
+
+:::note
+`applyTransform` and `getTransforms` only apply to item models.
+:::
+
+### Others
+
+Other methods in `BakedModel` that you may override and/or query include:
+
+| Signature                                                                     | Effect                                                                                                                                                                                                                                                                                                                                                                                                      |
+|-------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `TriState useAmbientOcclusion()`                                              | Whether to use [ambient occlusion][ao] or not. Accepts a `BlockState`, `RenderType` and `ModelData` parameter and returns a `TriState` which allows not only force-disabling AO but also force-enabling AO. Has two overloads that each return a `boolean` parameter and accept either only a `BlockState` or no parameters at all; both of these are deprecated for removal in favor of the first variant. |
+| `boolean isGui3d()`                                                           | Whether this model renders as 3d or flat in GUI slots.                                                                                                                                                                                                                                                                                                                                                      |
+| `boolean usesBlockLight()`                                                    | Whether to use 3D lighting (`true`) or flat lighting from the front (`false`) when lighting the model.                                                                                                                                                                                                                                                                                                      |
+| `boolean isCustomRenderer()`                                                  | If true, skips normal rendering and calls an associated [`BlockEntityWithoutLevelRenderer`][bewlr]'s `renderByItem` method instead. If false, renders through the default renderer.                                                                                                                                                                                                                         |
+| `BakedOverrides overrides()`                                                | Returns the [`BakedOverrides`][bakedoverrides] associated with this model. This is only relevant on item models.                                                                                                                                                                                                                                                                                              |
+| `ModelData getModelData(BlockAndTintGetter, BlockPos, BlockState, ModelData)` | Returns the model data to use for the model. This method is passed an existing `ModelData` that is either the result of `BlockEntity#getModelData()` if the block has an associated block entity, or `ModelData.EMPTY` if that is not the case. This method can be used for blocks that need model data, but do not have a block entity, for example for blocks with connected textures.                    |
+| `TextureAtlasSprite getParticleIcon(ModelData)`                               | Returns the particle sprite to use for the model. May use the model data to use different particle sprites for different model data values. NeoForge-added, replacing the vanilla `getParticleIcon()` overload with no parameters.                                                                                                                                                                          |
+| `ChunkRenderTypeSet getRenderTypes(BlockState, RandomSource, ModelData)`      | Returns a `ChunkRenderTypeSet` containing the render type(s) to use for rendering the block model. A `ChunkRenderTypeSet` is a set-backed ordered `Iterable<RenderType>`. By default falls back to [getting the render type from the model JSON][rendertype]. Only used for block models, item models use the overload below.                                                                               |
+| `List<RenderType> getRenderTypes(ItemStack)`                         | Returns a `List<RenderType>` containing the render type(s) to use for rendering the item model. By default falls back to the normal model-bound render type lookup, which always yields a list with one element. Only used for item models, block models use the overload above.                                                                                                                            |
+| `List<BakedModel> getRenderPasses(ItemStack)`                         | Returns a `List<BakedModel>` containing the models used by the item. Each of those models' render types will be queired using `getRenderTypes`.                                                                                                                            |
+
+## Perspectives
+
+Minecraft's render engine recognizes a total of 8 perspective types (9 if you include the in-code fallback) for item rendering. These are used in a model JSON's `display` block, and represented in code through the `ItemDisplayContext` enum.
+
+| Enum value                | JSON key                  | Usage                                                                                                            |
+|---------------------------|---------------------------|------------------------------------------------------------------------------------------------------------------|
+| `THIRD_PERSON_RIGHT_HAND` | `"thirdperson_righthand"` | Right hand in third person (F5 view, or on other players)                                                        |
+| `THIRD_PERSON_LEFT_HAND`  | `"thirdperson_lefthand"`  | Left hand in third person (F5 view, or on other players)                                                         |
+| `FIRST_PERSON_RIGHT_HAND` | `"firstperson_righthand"` | Right hand in first person                                                                                       |
+| `FIRST_PERSON_LEFT_HAND`  | `"firstperson_lefthand"`  | Left hand in first person                                                                                        |
+| `HEAD`                    | `"head"`                  | When in a player's head armor slot (often only achievable via commands)                                          |
+| `GUI`                     | `"gui"`                   | Inventories, player hotbar                                                                                       |
+| `GROUND`                  | `"ground"`                | Dropped items; note that the rotation of the dropped item is handled by the dropped item renderer, not the model |
+| `FIXED`                   | `"fixed"`                 | Item frames                                                                                                      |
+| `NONE`                    | `"none"`                  | Fallback purposes in code, should not be used in JSON                                                            |
+
+## `BakedOverrides`
+
+`BakedOverrides` is a class that provides a way for baked models to process the state of an [`ItemStack`][itemstack] and return a new baked model through the `#findOverride` method. `#findOverride` has four parameters:
+
+- An `ItemStack`: The item stack being rendered.
+- A `ClientLevel`: The level the model is being rendered in. This should only be used for querying the level, not mutating it in any way. May be null.
+- A `LivingEntity`: The entity the model is rendered on. May be null, e.g. when rendering from a [block entity renderer][ber].
+- An `int`: A seed for randomizing.
+
+`BakedOverrides` also hold the model's override options as `BakedOverride`s. An object of `BakedOverride` is an in-code representation of a model's [`overrides`][overrides] block. It can be used by baked models to return different models depending on its contents. A list of all `BakedOverride`s of an `BakedOverrides` instance can be retrieved through `BakedOverrides#getOverrides()`.
+
+## `BakedModelWrapper`
+
+A `BakedModelWrapper` can be used to modify an already existing `BakedModel`. `BakedModelWrapper` is a subclass of `BakedModel` that accepts another `BakedModel` (the "original" model) in the constructor and by default redirects all methods to the original model. Your implementation can then override only select methods, like so:
+
+```java
+// The generic parameter may optionally be a more specific subclass of BakedModel.
+// If it is, the constructor parameter must match that type.
+public class MyBakedModelWrapper extends BakedModelWrapper<BakedModel> {
+    // Pass the original model to super.
+    public MyBakedModelWrapper(BakedModel originalModel) {
+        super(originalModel);
+    }
+    
+    // Override whatever methods you want here. You may also access originalModel if needed.
+}
+```
+
+After writing your model wrapper class, you must apply the wrappers to the models it should affect. Do so in a [client-side][sides] [event handler][event] for `ModelEvent.ModifyBakingResult` on the [**mod event bus**][modbus]:
+
+```java
+@SubscribeEvent
+public static void modifyBakingResult(ModelEvent.ModifyBakingResult event) {
+    // For block models
+    event.getModels().computeIfPresent(
+        // The model resource location of the model to modify. Get it from
+        // BlockModelShaper#stateToModelLocation with the blockstate to be affected as a parameter.
+        BlockModelShaper.stateToModelLocation(MyBlocksClass.EXAMPLE_BLOCK.defaultBlockState()),
+        // A BiFunction with the location and the original models as parameters, returning the new model.
+        (location, model) -> new MyBakedModelWrapper(model);
+    );
+    // For item models
+    event.getModels().computeIfPresent(
+        // The model resource location of the model to modify.
+        ModelResourceLocation.inventory(
+            ResourceLocation.fromNamespaceAndPath("examplemod", "example_item")
+        ),
+        // A BiFunction with the location and the original models as parameters, returning the new model.
+        (location, model) -> new MyBakedModelWrapper(model);
+    );
+}
+```
+
+:::warning
+It is generally encouraged to use a [custom model loader][modelloader] over wrapping baked models in `ModelEvent.ModifyBakingResult` when possible. Custom model loaders can also use `BakedModelWrapper`s if needed.
+:::
+
+[ao]: https://en.wikipedia.org/wiki/Ambient_occlusion
+[ber]: ../../../blockentities/ber.md
+[bewlr]: ../../../blockentities/ber.md#blockentitywithoutlevelrenderer
+[blockstate]: ../../../blocks/states.md
+[event]: ../../../concepts/events.md
+[bakedoverrides]: #bakedoverrides
+[itemstack]: ../../../items/index.md#itemstacks
+[modbus]: ../../../concepts/events.md#event-buses
+[modelloader]: modelloaders.md
+[mrl]: ../../../misc/resourcelocation.md#modelresourcelocations
+[overrides]: index.md#overrides
+[perspective]: #perspectives
+[rendertype]: index.md#render-types
+[rl]: ../../../misc/resourcelocation.md
+[sides]: ../../../concepts/sides.md
diff --git a/versioned_docs/version-1.21.3/resources/client/models/datagen.md b/versioned_docs/version-1.21.3/resources/client/models/datagen.md
new file mode 100644
index 00000000..2a11b8ac
--- /dev/null
+++ b/versioned_docs/version-1.21.3/resources/client/models/datagen.md
@@ -0,0 +1,283 @@
+# Model Datagen
+
+Like most JSON data, block and item models can be [datagenned][datagen]. Since some things are common between item and block models, so is some of the datagen code.
+
+## Model Datagen Classes
+
+### `ModelBuilder`
+
+Every model starts out as a `ModelBuilder` of some sort - usually a `BlockModelBuilder` or an `ItemModelBuilder`, depending on what you are generating. It contains all the properties of the model: its parent, its textures, its elements, its transforms, its loader, etc. Each of the properties can be set by a method:
+
+| Method                                           | Effect                                                                                                                                                                                                                                                                                                                                                  |
+|--------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `#texture(String key, ResourceLocation texture)` | Adds a texture variable with the given key and the given texture location. Has an overload where the second parameter is a `String`.                                                                                                                                                                                                                    |
+| `#renderType(ResourceLocation renderType)`       | Sets the render type. Has an overload where the parameter is a `String`. For a list of valid values, see the `RenderType` class.                                                                                                                                                                                                                        |
+| `#ao(boolean ao)`                                | Sets whether to use [ambient occlusion][ao] or not.                                                                                                                                                                                                                                                                                                     |
+| `#guiLight(GuiLight light)`                      | Sets the GUI light. May be `GuiLight.FRONT` or `GuiLight.SIDE`.                                                                                                                                                                                                                                                                                         |
+| `#element()`                                     | Adds a new `ElementBuilder` (equivalent to adding a new [element][elements] to the model). Returns said `ElementBuilder` for further modification.                                                                                                                                                                                                      |
+| `#transforms()`                                  | Returns the builder's `TransformVecBuilder`, used for setting the `display` on a model.                                                                                                                                                                                                                                                                 |
+| `#customLoader(BiFunction customLoaderFactory)`  | Using the given factory, makes this model use a [custom loader][custommodelloader], and thus, a custom loader builder. This changes the builder type, and as such may use different methods, depending on the loader's implementation. NeoForge provides a few custom loaders out of the box, see the linked article for more info (including datagen). |
+
+:::tip
+While elaborate and complex models can be created through datagen, it is recommended to instead use modeling software such as [Blockbench][blockbench] to create more complex models and then have the exported models be used, either directly or as parents for other models.
+:::
+
+### `ModelProvider`
+
+Both block and item model datagen utilize subclasses of `ModelProvider`, named `BlockModelProvider` and `ItemModelProvider`, respectively. While item model datagen directly extends `ItemModelProvider`, block model datagen uses the `BlockStateProvider` base class, which has an internal `BlockModelProvider` that can be accessed via `BlockStateProvider#models()`. Additionally, `BlockStateProvider` also has its own internal `ItemModelProvider`, accessible via `BlockStateProvider#itemModels()`. The most important part of `ModelProvider` is the `getBuilder(String path)` method, which returns a `BlockModelBuilder` (or `ItemModelBuilder`) at the given location.
+
+However, `ModelProvider` also contains various helper methods. The most important helper method is probably `withExistingParent(String name, ResourceLocation parent)`, which returns a new builder (via `getBuilder(name)`) and sets the given `ResourceLocation` as model parent. Two other very common helpers are `mcLoc(String name)`, which returns a `ResourceLocation` with the namespace `minecraft` and the given name as path, and `modLoc(String name)`, which does the same but with the provider's mod id (so usually your mod id) instead of `minecraft`. Furthermore, it provides various helper methods that are shortcuts for `#withExistingParent` for common things such as slabs, stairs, fences, doors, etc.
+
+### `ModelFile`
+
+Finally, the last important class is `ModelFile`. A `ModelFile` is an in-code representation of a model JSON on disk. `ModelFile` is an abstract class and has two inner subclasses `ExistingModelFile` and `UncheckedModelFile`. An `ExistingModelFile`'s existence is verified using an `ExistingFileHelper`, while an `UncheckedModelFile` is assumed to be existent without further checking. In addition, a `ModelBuilder` is considered to be a `ModelFile` as well.
+
+## Block Model Datagen
+
+Now, to actually generate blockstate and block model files, extend `BlockStateProvider` and override the `registerStatesAndModels()` method. Note that block models will always be placed in the `models/block` subfolder, but references are relative to `models` (i.e. they must always be prefixed with `block/`). In most cases, it makes sense to choose from one of the many predefined helper methods:
+
+```java
+public class MyBlockStateProvider extends BlockStateProvider {
+    // Parameter values are provided by GatherDataEvent.
+    public MyBlockStateProvider(PackOutput output, ExistingFileHelper existingFileHelper) {
+        // Replace "examplemod" with your own mod id.
+        super(output, "examplemod", existingFileHelper);
+    }
+    
+    @Override
+    protected void registerStatesAndModels() {
+        // Placeholders, their usages should be replaced with real values. See above for how to use the model builder,
+        // and below for the helpers the model builder offers.
+        ModelFile exampleModel = this.models().withExistingParent("example_model", this.mcLoc("block/cobblestone"));
+        Block block = MyBlocksClass.EXAMPLE_BLOCK.get();
+        ResourceLocation exampleTexture = modLoc("block/example_texture");
+        ResourceLocation bottomTexture = modLoc("block/example_texture_bottom");
+        ResourceLocation topTexture = modLoc("block/example_texture_top");
+        ResourceLocation sideTexture = modLoc("block/example_texture_front");
+        ResourceLocation frontTexture = modLoc("block/example_texture_front");
+
+        // Create a simple block model with the same texture on each side.
+        // The texture must be located at assets/<namespace>/textures/block/<path>.png, where
+        // <namespace> and <path> are the block's registry name's namespace and path, respectively.
+        // Used by the majority of (full) blocks, such as planks, cobblestone or bricks.
+        this.simpleBlock(block);
+        // Overload that accepts a model file to use.
+        this.simpleBlock(block, exampleModel);
+        // Overload that accepts one or multiple (vararg) ConfiguredModel objects.
+        // See below for more info about ConfiguredModel.
+        this.simpleBlock(block, ConfiguredModel.builder().build());
+        // Adds an item model file with the block's name, parenting the given model file, for a block item to pick up.
+        this.simpleBlockItem(block, exampleModel);
+        // Shorthand for calling #simpleBlock() (model file overload) and #simpleBlockItem.
+        this.simpleBlockWithItem(block, exampleModel);
+        
+        // Adds a log block model. Requires two textures at assets/<namespace>/textures/block/<path>.png and
+        // assets/<namespace>/textures/block/<path>_top.png, referencing the side and top texture, respectively.
+        // Note that the block input here is limited to RotatedPillarBlock, which is the class vanilla logs use.
+        this.logBlock(block);
+        // Like #logBlock, but the textures are named <path>_side.png and <path>_end.png instead of
+        // <path>.png and <path>_top.png, respectively. Used by quartz pillars and similar blocks.
+        // Has an overload that allow you to specify a different texture base name, that is then suffixed
+        // with _side and _end as needed, an overload that allows you to specify two resource locations
+        // for the side and end textures, and an overload that allows specifying side and end model files.
+        this.axisBlock(block);
+        // Variants of #logBlock and #axisBlock that additionally allow for render types to be specified.
+        // Comes in string and resource location variants for the render type,
+        // in all combinations with all variants of #logBlock and #axisBlock.
+        this.logBlockWithRenderType(block, "minecraft:cutout");
+        this.axisBlockWithRenderType(block, mcLoc("cutout_mipped"));
+        
+        // Specifies a horizontally-rotatable block model with a side texture, a front texture, and a top texture.
+        // The bottom will use the side texture as well. If you don't need the front or top texture,
+        // just pass in the side texture twice. Used by e.g. furnaces and similar blocks.
+        this.horizontalBlock(block, sideTexture, frontTexture, topTexture);
+        // Specifies a horizontally-rotatable block model with a model file that will be rotated as needed.
+        // Has an overload that instead of a model file accepts a Function<BlockState, ModelFile>,
+        // allowing for different rotations to use different models. Used e.g. by the stonecutter.
+        this.horizontalBlock(block, exampleModel);
+        // Specifies a horizontally-rotatable block model that is attached to a face, e.g. for buttons or levers.
+        // Accounts for placing the block on the ground and on the ceiling, and rotates them accordingly.
+        // Like #horizontalBlock, has an overload that accepts a Function<BlockState, ModelFile> instead.
+        this.horizontalFaceBlock(block, exampleModel);
+        // Similar to #horizontalBlock, but for blocks that are rotatable in all directions, including up and down.
+        // Again, has an overload that accepts a Function<BlockState, ModelFile> instead.
+        this.directionalBlock(block, exampleModel);
+    }
+}
+```
+
+Additionally, helpers for the following common block models exist in `BlockStateProvider`:
+
+- Stairs
+- Slabs
+- Buttons
+- Pressure Plates
+- Signs
+- Fences
+- Fence Gates
+- Walls
+- Panes
+- Doors
+- Trapdoors
+
+In some cases, the blockstates don't need special casing, but the models do. For this case, the `BlockModelProvider`, accessible via `BlockStateProvider#models()`, provides a few additional helpers, all of which accept a name as the first parameter and most of which are in some way related to full cubes. They will typically be used as model file parameters for e.g. `simpleBlock`. The helpers include supporting methods for the ones in `BlockStateProvider`, as well as:
+
+- `withExistingParent`: Already mentioned before, this method returns a new model builder with the given parent. The parent must either already exist or be created before the model.
+- `getExistingFile`: Performs a lookup in the model provider's `ExistingFileHelper`, returning the corresponding `ModelFile` if present and throwing an `IllegalStateException` otherwise.
+- `singleTexture`: Accepts a parent and a single texture location, returning a model with the given parent, and with the texture variable `texture` set to the given texture location.
+- `sideBottomTop`: Accepts a parent and three texture locations, returning a model with the given parent and the side, bottom and top textures set to the three texture locations.
+- `cube`: Accepts six texture resource locations for the six sides, returning a full cube model with the six sides set to the six textures.
+- `cubeAll`: Accepts a texture location, returning a full cube model with the given texture applied to all six sides. A mix between `singleTexture` and `cube`, if you will.
+- `cubeTop`: Accepts two texture locations, returning a full cube model with the first texture applied to the sides and the bottom, and the second texture applied to the top.
+- `cubeBottomTop`: Accepts three texture locations, returning a full cube model with the side, bottom and top textures set to the three texture locations. A mix between `cube` and `sideBottomTop`, if you will.
+- `cubeColumn` and `cubeColumnHorizontal`: Accepts two texture locations, returning a "standing" or "laying" pillar cube model with the side and end textures set to the two texture locations. Used by `BlockStateProvider#logBlock`, `BlockStateProvider#axisBlock` and their variants.
+- `orientable`: Accepts three texture locations, returning a cube with a "front" texture. The three texture locations are the side, front and top texture, respectively.
+- `orientableVertical`: Variant of `orientable` that omits the top parameter, instead using the side parameter as well.
+- `orientableWithBottom`: Variant of `orientable` that has a fourth parameter for a bottom texture between the front and top parameter.
+- `crop`: Accepts a texture location, returning a crop-like model with the given texture, as used by the four vanilla crops.
+- `cross`: Accepts a texture location, returning a cross model with the given texture, as used by flowers, saplings and many other foliage blocks.
+- `torch`: Accepts a texture location, returning a torch model with the given texture.
+- `wall_torch`: Accepts a texture location, returning a wall torch model with the given texture (wall torches are separate blocks from standing torches).
+- `carpet`: Accepts a texture location, returning a carpet model with the given texture.
+
+Finally, don't forget to register your block state provider to the event:
+
+```java
+@SubscribeEvent
+public static void gatherData(GatherDataEvent event) {
+    DataGenerator generator = event.getGenerator();
+    PackOutput output = generator.getPackOutput();
+    ExistingFileHelper existingFileHelper = event.getExistingFileHelper();
+
+    // other providers here
+    generator.addProvider(
+        event.includeClient(),
+        new MyBlockStateProvider(output, existingFileHelper)
+    );
+}
+```
+
+### `ConfiguredModel.Builder`
+
+If the default helpers won't do it for you, you can also directly build model objects using a `ConfiguredModel.Builder` and then use them in a `VariantBlockStateBuilder` to build a `variants` blockstate file, or in a `MultiPartBlockStateBuilder` to build a `multipart` blockstate file:
+
+```java
+// Create a ConfiguredModel.Builder. Alternatively, you can use one of the ways demonstrated below
+// (VariantBlockStateBuilder.PartialBlockstate#modelForState or MultiPartBlockStateBuilder#part) where applicable.
+ConfiguredModel.Builder<?> builder = ConfiguredModel.builder()
+// Use a model file. As mentioned previously, can either be an ExistingModelFile, an UncheckedModelFile,
+// or some sort of ModelBuilder. See above for how to use ModelBuilder.
+        .modelFile(this.models().withExistingParent("example_model", this.mcLoc("block/cobblestone")))
+        // Set rotations around the x and y axes.
+        .rotationX(90)
+        .rotationY(180)
+        // Set a uvlock.
+        .uvlock(true)
+        // Set a weight.
+        .weight(5);
+// Build the configured model. The return type is an array
+// to account for multiple possible models in the same blockstate.
+ConfiguredModel[] model = builder.build();
+
+// Get a variant block state builder.
+VariantBlockStateBuilder variantBuilder = this.getVariantBuilder(MyBlocksClass.EXAMPLE_BLOCK.get());
+// Create a partial state and set properties on it.
+VariantBlockStateBuilder.PartialBlockstate partialState = variantBuilder.partialState();
+// Add one or multiple models for a partial blockstate. The models are a vararg parameter.
+variantBuilder.addModels(partialState,
+    // Specify at least one ConfiguredModel.Builder, as seen above. Create through #modelForState().
+    partialState.modelForState()
+        .modelFile(this.models().withExistingParent("example_variant_model", this.mcLoc("block/cobblestone")))
+        .uvlock(true)
+);
+// Alternatively, forAllStates(Function<BlockState, ConfiguredModel[]>) creates a model for every state.
+// The passed function will be called once for each possible state.
+variantBuilder.forAllStates(state -> {
+    // Return a ConfiguredModel depending on the state's properties.
+    // For example, the following code will rotate the model depending on the horizontal rotation of the block.
+    return ConfiguredModel.builder()
+        .modelFile(this.models().withExistingParent("example_variant_model", this.mcLoc("block/cobblestone")))
+        .rotationY((int) state.getValue(BlockStateProperties.HORIZONTAL_FACING).toYRot())
+        .build();
+});
+
+// Get a multipart block state builder.
+MultiPartBlockStateBuilder multipartBuilder = this.getMultipartBuilder(MyBlocksClass.EXAMPLE_BLOCK.get());
+// Add a new part. Starts with .part() and ends with .end().
+multipartBuilder.part()
+    // Step one: Build the model. multipartBuilder.part() returns a ConfiguredModel.Builder,
+    // meaning that all methods seen above can be used here as well.
+    .modelFile(this.models().withExistingParent("example_multipart_model", this.mcLoc("block/cobblestone")))
+    // Call .addModel(). Now that the model is built, we can proceed to step two: add the part data.
+    .addModel()
+    // Add a condition for the part. Requires a property
+    // and at least one property value; property values are a vararg.
+    .condition(BlockStateProperties.FACING, Direction.NORTH, Direction.SOUTH)
+    // Set the multipart conditions to be ORed instead of the default ANDing.
+    .useOr()
+    // Creates a nested condition group.
+    .nestedGroup()
+    // Adds a condition to the nested group.
+    .condition(BlockStateProperties.FACING, Direction.NORTH)
+    // Sets only this condition group to be ORed instead of ANDed.
+    .useOr()
+    // Creates yet another nested condition group. There is no limit on how many groups can be nested.
+    .nestedGroup()
+    // Ends the nested condition group, returning to the owning part builder or condition group level.
+    // Called twice here since we currently have two nested groups.
+    .endNestedGroup()
+    .endNestedGroup()
+    // End the part builder and add the resulting part to the multipart builder.
+    .end();
+```
+
+## Item Model Datagen
+
+Generating item models is considerably simpler, which is mainly due to the fact that we operate directly on an `ItemModelProvider` instead of using an intermediate class like `BlockStateProvider`, which is of course because item models don't have an equivalent to blockstate files and are instead used directly.
+
+Similar to above, we create a class and have it extend the base provider, in this case `ItemModelProvider`. Since we are directly in a subclass of `ModelProvider`, all `models()` calls become `this` (or are omitted).
+
+```java
+public class MyItemModelProvider extends ItemModelProvider {
+    public MyItemModelProvider(PackOutput output, ExistingFileHelper existingFileHelper) {
+        super(output, "examplemod", existingFileHelper);
+    }
+    
+    // Assume that EXAMPLE_BLOCK_ITEM and EXAMPLE_ITEM are both DeferredItems
+    @Override
+    protected void registerModels() {
+        // Block items generally use their corresponding block models as parent.
+        this.withExistingParent(MyItemsClass.EXAMPLE_BLOCK_ITEM.getId().toString(), modLoc("block/example_block"));
+        // Items generally use a simple parent and one texture. The most common parents are item/generated and item/handheld.
+        // In this example, the item texture would be located at assets/examplemod/textures/item/example_item.png.
+        // If you want a more complex model, you can use getBuilder() and then work from that, like you would with block models.
+        this.withExistingParent(MyItemsClass.EXAMPLE_ITEM.getId().toString(), mcLoc("item/generated")).texture("layer0", "item/example_item");
+        // The above line is so common that there is a shortcut for it. Note that the item registry name and the
+        // texture path, relative to textures/item, must match.
+        this.basicItem(MyItemsClass.EXAMPLE_ITEM.get());
+    }
+}
+```
+
+And like all data providers, don't forget to register your provider to the event:
+
+```java
+@SubscribeEvent
+public static void gatherData(GatherDataEvent event) {
+    DataGenerator generator = event.getGenerator();
+    PackOutput output = generator.getPackOutput();
+    ExistingFileHelper existingFileHelper = event.getExistingFileHelper();
+
+    // other providers here
+    generator.addProvider(
+        event.includeClient(),
+        new MyItemModelProvider(output, existingFileHelper)
+    );
+}
+```
+
+[ao]: https://en.wikipedia.org/wiki/Ambient_occlusion
+[blockbench]: https://www.blockbench.net
+[custommodelloader]: modelloaders.md#datagen
+[datagen]: ../../index.md#data-generation
+[elements]: index.md#elements
diff --git a/versioned_docs/version-1.21.3/resources/client/models/index.md b/versioned_docs/version-1.21.3/resources/client/models/index.md
new file mode 100644
index 00000000..c9f9b388
--- /dev/null
+++ b/versioned_docs/version-1.21.3/resources/client/models/index.md
@@ -0,0 +1,326 @@
+# Models
+
+Models are JSON files that determine the visual shape and texture(s) of a block or item. A model consists of cuboid elements, each with their own size, that then get assigned a texture to each face.
+
+Each item gets an item model assigned to it by its registry name. For example, an item with the registry name `examplemod:example_item` would get the model at `assets/examplemod/models/item/example_item.json` assigned to it. For blocks, this is a bit more complicated, as they get assigned a blockstate file first. See [below][bsfile] for more information.
+
+## Specification
+
+_See also: [Model][mcwikimodel] on the [Minecraft Wiki][mcwiki]_
+
+A model is a JSON file with the following optional properties in the root tag:
+
+- `loader`: NeoForge-added. Sets a custom model loader. See [Custom Model Loaders][custommodelloader] for more information.
+- `parent`: Sets a parent model, in the form of a [resource location][rl] relative to the `models` folder. All parent properties will be applied and then overridden by the properties set in the declaring model. Common parents include:
+    - `minecraft:block/block`: The common parent of all block models.
+    - `minecraft:block/cube`: Parent of all models that use a 1x1x1 cube model.
+    - `minecraft:block/cube_all`: Variant of the cube model that uses the same texture on all six sides, for example cobblestone or planks.
+    - `minecraft:block/cube_bottom_top`: Variant of the cube model that uses the same texture on all four horizontal sides, and separate textures on the top and the bottom. Common examples include sandstone or chiseled quartz.
+    - `minecraft:block/cube_column`: Variant of the cube model that has a side texture and a bottom and top texture. Examples include wooden logs, as well as quartz and purpur pillars.
+    - `minecraft:block/cross`: Model that uses two planes with the same texture, one rotated 45° clockwise and the other rotated 45° counter-clockwise, forming an X when viewed from above (hence the name). Examples include most plants, e.g. grass, saplings and flowers.
+    - `minecraft:item/generated`: Parent for classic 2D flat item models. Used by most items in the game. Ignores an `elements` block since its quads are generated from the textures.
+    - `minecraft:item/handheld`: Parent for 2D flat item models that appear to be actually held by the player. Used predominantly by tools. Submodel of `item/generated`, which causes it to ignore the `elements` block as well.
+    - `minecraft:builtin/entity`: Specifies no textures other than `particle`. If this is the parent, [`BakedModel#isCustomRenderer()`][iscustomrenderer] returns `true` to allow use of a [`BlockEntityWithoutLevelRenderer`][bewlr].
+    - Block items commonly (but not always) use their corresponding block models as parent. For example, the cobblestone item model uses the parent `minecraft:block/cobblestone`.
+- `ambientocclusion`: Whether to enable [ambient occlusion][ao] or not. Only effective on block models. Defaults to `true`. If your custom block model has weird shading, try setting this to `false`.
+- `render_type`: See [Render Types][rendertype].
+- `gui_light`: Can be `"front"` or `"side"`. If `"front"`, light will come from the front, useful for flat 2D models. If `"side"`, light will come from the side, useful for 3D models (especially block models). Defaults to `"side"`. Only effective on item models.
+- `textures`: A sub-object that maps names (known as texture variables) to [texture locations][textures]. Texture variables can then be used in [elements]. They can also be specified in elements, but left unspecified in order for child models to specify them.
+    - Block models should additionally specify a `particle` texture. This texture is used when falling on, running across, or breaking the block.
+    - Item models can also use layer textures, named `layer0`, `layer1`, etc., where layers with a higher index are rendered above those with a lower index (e.g. `layer1` would be rendered above `layer0`). Only works if the parent is `item/generated`, and only works for up to 5 layers (`layer0` through `layer4`).
+- `elements`: A list of cuboid [elements].
+- `overrides`: A list of [override models][overrides]. Only effective on item models.
+- `display`: A sub-object that holds the different display options for different [perspectives], see linked article for possible keys. Only effective on item models, but often specified in block models so that item models can inherit the display options. Every perspective is an optional sub-object that may contain the following options, which are applied in that order:
+    - `translation`: The translation of the model, specified as `[x, y, z]`.
+    - `rotation`: The rotation of the model, specified as `[x, y, z]`.
+    - `scale`: The scale of the model, specified as `[x, y, z]`.
+    - `right_rotation`: NeoForge-added. A second rotation that is applied after scaling, specified as `[x, y, z]`.
+- `transform`: See [Root Transforms][roottransforms].
+
+:::tip
+If you're having trouble finding out how exactly to specify something, have a look at a vanilla model that does something similar.
+:::
+
+### Render Types
+
+Using the optional NeoForge-added `render_type` field, you can set a render type for your model. If this is not set (as is the case in all vanilla models), the game will fall back to the render types hardcoded in `ItemBlockRenderTypes`. If `ItemBlockRenderTypes` doesn't contain the render type for that block either, it will fall back to `minecraft:solid`. Vanilla provides the following default render types:
+
+- `minecraft:solid`: Used for fully solid blocks, such as stone.
+- `minecraft:cutout`: Used for blocks where any pixel is either fully solid or fully transparent, i.e. with either full or no transparency, for example glass.
+- `minecraft:cutout_mipped`: Variant of `minecraft:cutout` that will scale down textures at large distances to avoid visual artifacts ([mipmapping]). Does not apply the mipmapping to item rendering, as it is usually undesired on items and may cause artifacts. Used for example by leaves.
+- `minecraft:cutout_mipped_all`: Variant of `minecraft:cutout_mipped` which applies mipmapping to item models as well.
+- `minecraft:translucent`: Used for blocks where any pixel may be partially transparent, for example stained glass.
+- `minecraft:tripwire`: Used by blocks with the special requirement of being rendered to the weather target, i.e. tripwire.
+
+Selecting the correct render type is a question of performance to some degree. Solid rendering is faster than cutout rendering, and cutout rendering is faster than translucent rendering. Because of this, you should specify the "strictest" render type applicable for your use case, as it will also be the fastest.
+
+If you want, you can also add your own render types. To do so, subscribe to the [mod bus][modbus] [event] `RegisterNamedRenderTypesEvent` and `#register` your render types. `#register` has three or four parameters:
+
+- The name of the render type. Will be prefixed with your mod id. For example, using `"my_cutout"` here will provide `examplemod:my_cutout` as a new render type for you to use (provided that your mod id is `examplemod`, of course).
+- The chunk render type. Any of the types in the list returned by `RenderType.chunkBufferLayers()` can be used.
+- The entity render type. Must be a render type with the `DefaultVertexFormat.NEW_ENTITY` vertex format.
+- Optional: The fabulous render type. Must be a render type with the `DefaultVertexFormat.NEW_ENTITY` vertex format. Will be used instead of the regular entity render type if the graphics mode is set to _Fabulous!_. If omitted, falls back to the regular render type. Generally recommended to set if the render type uses transparency in some way.
+
+### Elements
+
+An element is a JSON representation of a cuboid object. It has the following properties:
+
+- `from`: The coordinate of the start corner of the cuboid, specified as `[x, y, z]`. Specified in 1/16 block units. For example, `[0, 0, 0]` would be the "bottom left" corner, `[8, 8, 8]` would be the center, and `[16, 16, 16]` would be the "top right" corner of the block.
+- `to`: The coordinate of the end corner of the cuboid, specified as `[x, y, z]`. Like `from`, this is specified in 1/16 block units.
+
+:::tip
+Values in `from` and `to` are limited by Minecraft to the range `[-16, 32]`. However, it is highly discouraged to exceed `[0, 16]`, as that will lead to lighting and/or culling issues.
+:::
+
+- `neoforge_data`: See [Extra Face Data][extrafacedata].
+- `faces`: An object containing data for of up to 6 faces, named `north`, `south`, `east`, `west`, `up` and `down`, respectively. Every face has the following data:
+    - `uv`: The uv of the face, specified as `[u1, v1, u2, v2]`, where `u1, v1` is the top left uv coordinates and `u2, v2` is the bottom right uv coordinates.
+    - `texture`: The texture to use for the face. Must be a texture variable prefixed with a `#`. For example, if your model had a texture named `wood`, you would use `#wood` to reference that texture. Technically optional, will use the missing texture if absent.
+    - `rotation`: Optional. Rotates the texture clockwise by 90, 180 or 270 degrees.
+    - `cullface`: Optional. Tells the render engine to skip rendering the face when there is a full block touching it in the specified direction. The direction can be `north`, `south`, `east`, `west`, `up` or `down`.
+    - `tintindex`: Optional. Specifies a tint index that may be used by a color handler, see [Tinting][tinting] for more information. Defaults to -1, which means no tinting.
+    - `neoforge_data`: See [Extra Face Data][extrafacedata].
+
+Additionally, it can specify the following optional properties:
+
+- `shade`: Only for block models. Optional. Whether the faces of this element should have direction-dependent shading on it or not. Defaults to true.
+- `rotation`: A rotation of the object, specified as a sub object containing the following data:
+    - `angle`: The rotation angle, in degrees. Can be -45 through 45 in steps of 22.5 degrees.
+    - `axis`: The axis to rotate around. It is currently not possible to rotate an object around more than one axis.
+    - `origin`: Optional. The origin point to rotate around, specified as `[x, y, z]`. Note that these are absolute values, i.e. they are not relative to the cube's position. If unspecified, will use `[0, 0, 0]`.
+
+#### Extra Face Data
+
+Extra face data (`neoforge_data`) can be applied to both an element and a single face of an element. It is optional in all contexts where it is available. If both element-level and face-level extra face data is specified, the face-level data will override the element-level data. Extra data can specify the following data:
+
+- `color`: Tints the face with the given color. Must be an ARGB value. Can be specified as a string or as a decimal integer (JSON does not support hex literals). Defaults to `0xFFFFFFFF`. This can be used as a replacement for tinting if the color values are constant.
+- `block_light`: Overrides the block light value used for this face. Defaults to 0.
+- `sky_light`: Overrides the sky light value used for this face. Defaults to 0.
+- `ambient_occlusion`: Disables or enables ambient occlusion for this face. Defaults to the value set in the model.
+
+Using the custom `neoforge:item_layers` loader, you can also specify extra face data to apply to all the geometry in an `item/generated` model. In the following example, layer 1 will be tinted red and glow at full brightness:
+
+```json5
+{
+    "loader": "neoforge:item_layers",
+    "parent": "minecraft:item/generated",
+    "textures": {
+        "layer0": "minecraft:item/stick",
+        "layer1": "minecraft:item/glowstone_dust"
+    },
+    "neoforge_data": {
+        "1": {
+            "color": "0xFFFF0000",
+            "block_light": 15,
+            "sky_light": 15,
+            "ambient_occlusion": false
+        }
+    }
+}
+```
+
+### Overrides
+
+Item overrides can assign a different model to an item based on a float value, called the override value. For example, bows and crossbows use this to change the texture depending on how long they have been drawn. Overrides have both a model and a code side to them.
+
+The model can specify one or multiple override models that should be used when the override value is equal to or greater than the given threshold value. For example, the bow uses two different properties `pulling` and `pull`. `pulling` is treated as a boolean value, with 1 being interpreted as pulling and 0 as not pulling, while `pull` represents how much the bow is currently pulled. It then uses these properties to specify usage of three alternative models when charged to below 65% (`pulling` 1, no `pull` value), 65% (`pulling` 1, `pull` 0.65) and 90% (`pulling` 1, `pull` 0.9). If multiple models apply (because the value keeps on becoming bigger), the last element of the list matches, so make sure your order is correct. The overrides look as follows:
+
+```json5
+{
+    // other stuff here
+    "overrides": [
+        {
+            // pulling = 1
+            "predicate": {
+                "pulling": 1
+            },
+            "model": "item/bow_pulling_0"
+        },
+        {
+            // pulling = 1, pull >= 0.65
+            "predicate": {
+                "pulling": 1,
+                "pull": 0.65
+            },
+            "model": "item/bow_pulling_1"
+        },
+        // pulling = 1, pull >= 0.9
+        {
+            "predicate": {
+                "pulling": 1,
+                "pull": 0.9
+            },
+            "model": "item/bow_pulling_2"
+        }
+    ]
+}
+```
+
+The code side of things is pretty simple. Assuming that we want to add a property named `examplemod:property` to our item, we would use the following code in a [client-side][side] [event handler][eventhandler]:
+
+```java
+@SubscribeEvent
+public static void onClientSetup(FMLClientSetupEvent event) {
+    event.enqueueWork(() -> { // ItemProperties#register is not threadsafe, so we need to call it on the main thread
+        ItemProperties.register(
+            // The item to apply the property to.
+            ExampleItems.EXAMPLE_ITEM,
+            // The id of the property.
+            ResourceLocation.fromNamespaceAndPath("examplemod", "property"),
+            // A reference to a method that calculates the override value.
+            // Parameters are the used item stack, the level context, the player using the item,
+            // and a random seed you can use.
+            (stack, level, player, seed) -> someMethodThatReturnsAFloat()
+        );
+    });
+}
+```
+
+:::info
+Vanilla Minecraft only allows for float values between 0 and 1. NeoForge patches this to allow arbitrary float values.
+:::
+
+### Root Transforms
+
+Adding the `transform` property at the top level of a model tells the loader that a transformation to all geometry should be applied right before the rotations in a [blockstate file][bsfile] (for block models) or the transformations in a `display` block (for item models) are applied. This is added by NeoForge.
+
+The root transforms can be specified in two ways. The first way would be as a single property named `matrix` containing a transformation 3x4 matrix (row major order, last row is omitted) in the form of a nested JSON array. The matrix is the composition of the translation, left rotation, scale, right rotation and the transformation origin in that order. An example would look like this:
+
+```json5
+{
+    // ...
+    "transform": {
+        "matrix": [
+            [0, 0, 0, 0],
+            [0, 0, 0, 0],
+            [0, 0, 0, 0]
+        ]
+    }
+}
+```
+
+The second way is to specify a JSON object containing any combination of the following entries, applied in that order:
+
+- `translation`: The relative translation. Specified as a three-dimensional vector (`[x, y, z]`) and defaults to `[0, 0, 0]` if absent.
+- `rotation` or `left_rotation`: Rotation around the translated origin to be applied before scaling. Defaults to no rotation. Specified in one of the following ways:
+    - A JSON object with a single axis to rotation mapping, e.g. `{"x": 90}`
+    - An array of JSON objects with a single axis to rotation mapping each, applied in the order they are specified in, e.g. `[{"x": 90}, {"y": 45}, {"x": -22.5}]`
+    - An array with three values that each specify the rotation around each axis, e.g. `[90, 45, -22.5]`
+    - An array with four values directly specifying a quaternion, e.g. `[0.38268346, 0, 0, 0.9238795]` (= 45 degrees around the X axis)
+- `scale`: The scale relative to the translated origin. Specified as a three-dimensional vector (`[x, y, z]`) and defaults to `[1, 1, 1]` if absent.
+- `post_rotation` or `right_rotation`: Rotation around the translated origin to be applied after scaling. Defaults to no rotation. Specified the same as `rotation`.
+- `origin`: Origin point used for rotation and scaling. The transformation is also moved here as a final step. Specified either as a three-dimensional vector (`[x, y, z]`) or using one of the three builtin values `"corner"` (= `[0, 0, 0]`), `"center"` (= `[0.5, 0.5, 0.5]`) or `"opposing-corner"` (= `[1, 1, 1]`, default).
+
+## Blockstate Files
+
+_See also: [Blockstate files][mcwikiblockstate] on the [Minecraft Wiki][mcwiki]_
+
+Blockstate files are used by the game to assign different models to different [blockstates]. There must be exactly one blockstate file per block registered to the game. Specifying block models for blockstates works in two mutually exclusive ways: via variants or via multipart.
+
+Inside a `variants` block, there is an element for each blockstate. This is the predominant way of associating blockstates with models, used by the vast majority of blocks.
+- The key is the string representation of the blockstate without the block name, so for example `"type=top,waterlogged=false"` for a non-waterlogged top slab, or `""` for a block with no properties. It is worth noting that unused properties may be omitted. For example, if the `waterlogged` property has no influence on the model chosen, two objects `type=top,waterlogged=false` and `type=top,waterlogged=true` may be collapsed into one `type=top` object. This also means that an empty string is valid for every block.
+- The value is either a single model object or an array of model objects. If an array of model objects is used, a model will be randomly chosen from it. A model object consists of the following data:
+    - `model`: A path to a model file location, relative to the namespace's `models` folder, for example `minecraft:block/cobblestone`.
+    - `x` and `y`: Rotation of the model on the x-axis/y-axis. Limited to steps of 90 degrees. Optional each, defaults to 0.
+    - `uvlock`: Whether to lock the UVs of the model when rotating or not. Optional, defaults to false.
+    - `weight`: Only useful with arrays of model objects. Gives the object a weight, used when choosing a random model object. Optional, defaults to 1.
+
+In contrast, inside a `multipart` block, elements are combined depending on the properties of the blockstate. This method is mainly used by fences and walls, who enable the four directional parts based on boolean properties. A multipart element consists of two parts: a `when` block and an `apply` block.
+
+- The `when` block specifies either a string representation of a blockstate or a list of properties that must be met for the element to apply. The lists can either be named `"OR"` or `"AND"`, performing the respective logical operation on its contents. Both single blockstate and list values can additionally specify multiple actual values by separating them with `|` (for example `facing=east|facing=west`).
+- The `apply` block specifies the model object or an array of model objects to use. This works exactly like with a `variants` block.
+
+## Tinting
+
+Some blocks, such as grass or leaves, change their texture color based on their location and/or properties. [Model elements][elements] can specify a tint index on their faces, which will allow a color handler to handle the respective faces. The code side of things works through two events, one for block color handlers and one for item color handlers. They both work pretty similar, so let's have a look at a block handler first:
+
+```java
+// Client-side mod bus event handler
+@SubscribeEvent
+public static void registerBlockColorHandlers(RegisterColorHandlersEvent.Block event) {
+    // Parameters are the block's state, the level the block is in, the block's position, and the tint index.
+    // The level and position may be null.
+    event.register((state, level, pos, tintIndex) -> {
+        // Replace with your own calculation. See the BlockColors class for vanilla references.
+        // Colors are in ARGB format. Generally, if the tint index is -1, it means that no tinting
+        // should take place and a default value should be used instead.
+        return 0xFFFFFFFF;
+    },
+    // A varargs of blocks to apply the tinting to
+    EXAMPLE_BLOCK.get(), ...);
+}
+```
+
+Item handlers work pretty much the same, except for some naming and the lambda parameters:
+
+```java
+// Client-side mod bus event handler
+@SubscribeEvent
+public static void registerItemColorHandlers(RegisterColorHandlersEvent.Item event) {
+    // Parameters are the item stack and the tint index.
+    event.register((stack, tintIndex) -> {
+        // Like above, replace with your own calculation. Vanilla values are in the ItemColors class.
+        // Also like above, tint index -1 means no tint and should use a default value instead.
+        return 0xFFFFFFFF;
+    },
+    // A varargs of items to apply the tinting to
+    EXAMPLE_ITEM.get(), ...);
+}
+```
+
+Be aware that the `item/generated` model specifies tint indices for its various layers - `layer0` has tint index 0, `layer1` has tint index 1, etc. Also, remember that block items are items, not blocks, and require an item color handler to be colored.
+
+## Registering Additional Models
+
+Models that are not associated with a block or item in some way, but are still required in other contexts (e.g. [block entity renderers][ber]), can be registered through `ModelEvent.RegisterAdditional`:
+
+```java
+// Client-side mod bus event handler
+@SubscribeEvent
+public static void registerAdditional(ModelEvent.RegisterAdditional event) {
+    event.register(new ModelResourceLocation(
+        // The id of the model
+        ResourceLocation.fromNamespaceAndPath("examplemod", "block/example_unused_model"),
+        // The string representing what variant of the model this is for
+        // In normal vanilla, this would be one of three values:
+        // - Blocks: The stringified block state
+        // - Items: 'inventory' as it is the inventory model
+        // - Standalone: 'standalone' as this does not refer to any other model
+        "variant_type=true"
+    ));
+
+    // An inventory model example
+    event.register(ModelResourceLocation.inventory(
+        ResourceLocation.fromNamespaceAndPath("examplemod", "item/example_unused_inventory_model")
+    ));
+
+    // A standalone model example
+    event.register(ModelResourceLocation.standalone(
+        ResourceLocation.fromNamespaceAndPath("examplemod", "block/example_unused_standalone_model")
+    ));
+}
+```
+
+[ao]: https://en.wikipedia.org/wiki/Ambient_occlusion
+[ber]: ../../../blockentities/ber.md
+[bewlr]: ../../../blockentities/ber.md#blockentitywithoutlevelrenderer
+[bsfile]: #blockstate-files
+[custommodelloader]: modelloaders.md
+[elements]: #elements
+[event]: ../../../concepts/events.md
+[eventhandler]: ../../../concepts/events.md#registering-an-event-handler
+[extrafacedata]: #extra-face-data
+[iscustomrenderer]: bakedmodel.md#others
+[mcwiki]: https://minecraft.wiki
+[mcwikiblockstate]: https://minecraft.wiki/w/Tutorials/Models#Block_states
+[mcwikimodel]: https://minecraft.wiki/w/Model
+[mipmapping]: https://en.wikipedia.org/wiki/Mipmap
+[modbus]: ../../../concepts/events.md#event-buses
+[overrides]: #overrides
+[perspectives]: bakedmodel.md#perspectives
+[rendertype]: #render-types
+[roottransforms]: #root-transforms
+[rl]: ../../../misc/resourcelocation.md
+[side]: ../../../concepts/sides.md
+[textures]: ../textures.md
+[tinting]: #tinting
diff --git a/versioned_docs/version-1.21.3/resources/client/models/modelloaders.md b/versioned_docs/version-1.21.3/resources/client/models/modelloaders.md
new file mode 100644
index 00000000..6b387406
--- /dev/null
+++ b/versioned_docs/version-1.21.3/resources/client/models/modelloaders.md
@@ -0,0 +1,488 @@
+# Custom Model Loaders
+
+A model is simply a shape. It can be a cube, a collection of cubes, a collection of triangles, or any other geometrical shape (or collection of geometrical shape). For most contexts, it is not relevant how a model is defined, as everything will end up as a `BakedModel` in memory anyway. As such, NeoForge adds the ability to register custom model loaders that can transform any model you want into a `BakedModel` for the game to use.
+
+The entry point for a block model remains the model JSON file. However, you can specify a `loader` field in the root of the JSON that will swap out the default loader for your own loader. A custom model loader may ignore all fields the default loader requires.
+
+## Builtin Model Loaders
+
+Besides the default model loader, NeoForge offers several builtin loaders, each serving a different purpose.
+
+### Composite Model
+
+A composite model can be used to specify different model parts in the parent and only apply some of them in a child. This is best illustrated by an example. Consider the following parent model at `examplemod:example_composite_model`:
+
+```json5
+{
+    "loader": "neoforge:composite",
+    // Specify model parts.
+    "children": {
+        "part_1": {
+            "parent": "examplemod:some_model_1"
+        },
+        "part_2": {
+            "parent": "examplemod:some_model_2"
+        }
+    },
+    "visibility": {
+        // Disable part 2 by default.
+        "part_2": false
+    }
+}
+```
+
+Then, we can disable and enable individual parts in a child model of `examplemod:example_composite_model`:
+
+```json5
+{
+    "parent": "examplemod:example_composite_model",
+    // Override visibility. If a part is missing, it will use the parent model's visibility value.
+    "visibility": {
+        "part_1": false,
+        "part_2": true
+    }
+}
+```
+
+To [datagen][modeldatagen] this model, use the custom loader class `CompositeModelBuilder`.
+
+### Dynamic Fluid Container Model
+
+The dynamic fluid container model, also called dynamic bucket model after its most common use case, is used for items that represent a fluid container (such as a bucket or a tank) and want to show the fluid within the model. This only works if there is a fixed amount of fluids (e.g. only lava and powder snow) that can be used, use a [`BlockEntityWithoutLevelRenderer`][bewlr] instead if the fluid is arbitrary.
+
+```json5
+{
+    "loader": "neoforge:fluid_container",
+    // Required. Must be a valid fluid id.
+    "fluid": "minecraft:water",
+    // The loader generally expects two textures: base and fluid.
+    "textures": {
+        // The base container texture, i.e. the equivalent of an empty bucket.
+        "base": "examplemod:item/custom_container",
+        // The fluid texture, i.e. the equivalent of water in a bucket.
+        "fluid": "examplemod:item/custom_container_fluid"
+    },
+    // Optional, defaults to false. Whether to flip the model upside down, for gaseous fluids.
+    "flip_gas": true,
+    // Optional, defaults to true. Whether to have the cover act as the mask.
+    "cover_is_mask": false,
+    // Optional, defaults to true. Whether to apply the fluid's luminosity to the item model.
+    "apply_fluid_luminosity": false,
+}
+```
+
+:::note
+If you would like to apply a tint to the fluid texture, you will need to [register an `ItemColor`][tint]. An instance with the fluid tinting logic can be created from `DynamicFluidContainerModel.Colors`:
+
+```java
+// Client-side mod bus event handler
+@SubscribeEvent
+public static void registerItemColorHandlers(RegisterColorHandlersEvent.Item event) {
+    event.register(new DynamicFluidContainerModel.Colors(), EXAMPLE_BUCKET.get(), ...);
+}
+```
+:::
+
+Very often, dynamic fluid container models will directly use the bucket model. This is done by specifying the `neoforge:item_bucket` parent model, like so:
+
+```json5
+{
+    "loader": "neoforge:fluid_container",
+    "parent": "neoforge:item/bucket",
+    // Replace with your own fluid.
+    "fluid": "minecraft:water"
+    // Optional properties here. Note that the textures are handled by the parent.
+}
+```
+
+To [datagen][modeldatagen] this model, use the custom loader class `DynamicFluidContainerModelBuilder`.
+
+### Elements Model
+
+An elements model consists of block model [elements][elements] and an optional [root transform][transform]. Intended mainly for usage outside regular model rendering, for example within a [BER][ber].
+
+```json5
+{
+    "loader": "neoforge:elements",
+    "elements": [...],
+    "transform": {...}
+}
+```
+
+### Empty Model
+
+An empty model just renders nothing at all.
+
+```json5
+{
+    "loader": "neoforge:empty"
+}
+```
+
+### Item Layer Model
+
+Item layer models are a variant of the standard `item/generated` model that offer the following additional features:
+
+- Unlimited amount of layers (instead of the default 5)
+- Per-layer [render types][rendertype]
+
+```json5
+{
+    "loader": "neoforge:item_layers",
+    "textures": {
+        "layer0": "...",
+        "layer1": "...",
+        "layer2": "...",
+        "layer3": "...",
+        "layer4": "...",
+        "layer5": "...",
+    },
+    "render_types": {
+        // Map render types to layer numbers. For example, layers 0, 2 and 4 will use cutout.
+        "minecraft:cutout": [0, 2, 4],
+        "minecraft:cutout_mipped": [1, 3],
+        "minecraft:translucent": [5]
+    },
+    // other stuff the default loader allows here
+}
+```
+
+To [datagen][modeldatagen] this model, use the custom loader class `ItemLayerModelBuilder`.
+
+### OBJ Model
+
+The OBJ model loader allows you to use Wavefront `.obj` 3D models in the game, allowing for arbitrary shapes (including triangles, circles, etc.) to be included in a model. The `.obj` model must be placed in the `models` folder (or a subfolder thereof), and a `.mtl` file with the same name must be provided (or set manually), so for example, an OBJ model at `models/block/example.obj` must have a corresponding MTL file at `models/block/example.mtl`.
+
+```json5
+{
+    "loader": "neoforge:obj",
+    // Required. Reference to the model file. Note that this is relative to the namespace root, not the model folder.
+    "model": "examplemod:models/example.obj",
+    // Normally, .mtl files must be put into the same location as the .obj file, with only the file ending differing.
+    // This will cause the loader to automatically pick them up. However, you can also set the location
+    // of the .mtl file manually if needed.
+    "mtl_override": "examplemod:models/example_other_name.mtl",
+    // These textures can be referenced in the .mtl file as #texture0, #particle, etc.
+    // This usually requires manual editing of the .mtl file.
+    "textures": {
+        "texture0": "minecraft:block/cobblestone",
+        "particle": "minecraft:block/stone"
+    },
+    // Enable or disable automatic culling of the model. Optional, defaults to true.
+    "automatic_culling": false,
+    // Whether to shade the model or not. Optional, defaults to true.
+    "shade_quads": false,
+    // Some modeling programs will assume V=0 to be bottom instead of the top. This property flips the Vs upside-down.
+    // Optional, defaults to false.
+    "flip_v": true,
+    // Whether to enable emissivity or not. Optional, defaults to true.
+    "emissive_ambient": false
+}
+```
+
+To [datagen][modeldatagen] this model, use the custom loader class `ObjModelBuilder`.
+
+### Separate Transforms Model
+
+A separate transforms model can be used to switch between different models based on the perspective. The perspectives are the same as for the `display` block in a [normal model][model]. This works by specifying a base model (as a fallback) and then specifying per-perspective override models. Note that each of these can be fully-fledged models if you so desire, but it is usually easiest to just refer to another model by using a child model of that model, like so:
+
+```json5
+{
+    "loader": "neoforge:separate_transforms",
+    // Use the cobblestone model normally.
+    "base": {
+        "parent": "minecraft:block/cobblestone"
+    },
+    // Use the stone model only when dropped.
+    "perspectives": {
+        "ground": {
+            "parent": "minecraft:block/stone"
+        }
+    }
+}
+```
+
+To [datagen][modeldatagen] this model, use the custom loader class `SeparateTransformsModelBuilder`.
+
+## Creating Custom Model Loaders
+
+To create your own model loader, you need three classes, plus an event handler:
+
+- A geometry loader class
+- A geometry class
+- A dynamic [baked model][bakedmodel] class
+- A [client-side][sides] [event handler][event] for `ModelEvent.RegisterGeometryLoaders` that registers the geometry loader
+
+To illustrate how these classes are connected, we will follow a model being loaded:
+
+- During model loading, a model JSON with the `loader` property set to your loader is passed to your geometry loader. The geometry loader then reads the model JSON and returns a geometry object using the model JSON's properties.
+- During model baking, the geometry is baked, returning a dynamic baked model.
+- During model rendering, the dynamic baked model is used for rendering.
+
+Let's illustrate this further through a basic class setup. The geometry loader class is named `MyGeometryLoader`, the geometry class is named `MyGeometry`, and the dynamic baked model class is named `MyDynamicModel`:
+
+```java
+public class MyGeometryLoader implements IGeometryLoader<MyGeometry> {
+    // It is highly recommended to use a singleton pattern for geometry loaders, as all models can be loaded through one loader.
+    public static final MyGeometryLoader INSTANCE = new MyGeometryLoader();
+    // The id we will use to register this loader. Also used in the loader datagen class.
+    public static final ResourceLocation ID = ResourceLocation.fromNamespaceAndPath("examplemod", "my_custom_loader");
+    
+    // In accordance with the singleton pattern, make the constructor private.        
+    private MyGeometryLoader() {}
+    
+    @Override
+    public MyGeometry read(JsonObject jsonObject, JsonDeserializationContext context) throws JsonParseException {
+        // Use the given JsonObject and, if needed, the JsonDeserializationContext to get properties from the model JSON.
+        // The MyGeometry constructor may have constructor parameters (see below).
+        return new MyGeometry();
+    }
+}
+
+public class MyGeometry implements IUnbakedGeometry<MyGeometry> {
+    // The constructor may have any parameters you need, and store them in fields for further usage below.
+    // If the constructor has parameters, the constructor call in MyGeometryLoader#read must match them.
+    public MyGeometry() {}
+
+    // Method responsible for model baking, returning our dynamic model. Parameters in this method are:
+    // - The geometry baking context. Contains many properties that we will pass into the model, e.g. light and ao values.
+    // - The model baker. Can be used for baking sub-models.
+    // - The sprite getter. Maps materials (= texture variables) to TextureAtlasSprites. Materials can be obtained from the context.
+    //   For example, to get a model's particle texture, call spriteGetter.apply(context.getMaterial("particle"));
+    // - The model state. This holds the properties from the blockstate file, e.g. rotations and the uvlock boolean.
+    // - The item overrides. This is the code representation of an "overrides" block in an item model.
+    @Override
+    public BakedModel bake(IGeometryBakingContext context, ModelBaker baker, Function<Material, TextureAtlasSprite> spriteGetter, ModelState modelState, List<ItemOverride> overrides) {
+        // See info on the parameters below.
+        return new MyDynamicModel(context.useAmbientOcclusion(), context.isGui3d(), context.useBlockLight(),
+            spriteGetter.apply(context.getMaterial("particle")), new BakedOverrides(baker, overrides));
+    }
+
+    // Method responsible for correctly resolving parent properties. Required if this model loads any nested models or reuses the vanilla loader on itself (see below).
+    @Override
+    public void resolveDependencies(UnbakedModel.Resolver resolver, IGeometryBakingContext context) {
+        // UnbakedModel#resolveDependencies
+    }
+
+    // Gets the name of the components that can be configured via IGeometryBakingContext
+    // Usually empty unless there are child components
+    @Override
+    public Set<String> getConfigurableComponentNames() {
+        return Set.of();
+    }
+}
+
+// BakedModelWrapper can be used as well to return default values for most methods, allowing you to only override what actually needs to be overridden.
+public class MyDynamicModel implements IDynamicBakedModel {
+    // Material of the missing texture. Its sprite can be used as a fallback when needed.
+    private static final Material MISSING_TEXTURE = 
+        new Material(TextureAtlas.LOCATION_BLOCKS, MissingTextureAtlasSprite.getLocation());
+
+    // Attributes for use in the methods below. Optional, the methods may also use constant values if applicable.
+    private final boolean useAmbientOcclusion;
+    private final boolean isGui3d;
+    private final boolean usesBlockLight;
+    private final TextureAtlasSprite particle;
+    private final BakedOverrides overrides;
+
+    // The constructor does not require any parameters other than the ones for instantiating the final fields.
+    // It may specify any additional parameters to store in fields you deem necessary for your model to work.
+    public MyDynamicModel(boolean useAmbientOcclusion, boolean isGui3d, boolean usesBlockLight, TextureAtlasSprite particle, BakedOverrides overrides) {
+        this.useAmbientOcclusion = useAmbientOcclusion;
+        this.isGui3d = isGui3d;
+        this.usesBlockLight = usesBlockLight;
+        this.particle = particle;
+        this.overrides = overrides;
+    }
+
+    // Use our attributes. Refer to the article on baked models for more information on the method's effects.
+    @Override
+    public boolean useAmbientOcclusion() {
+        return useAmbientOcclusion;
+    }
+
+    @Override
+    public boolean isGui3d() {
+        return isGui3d;
+    }
+
+    @Override
+    public boolean usesBlockLight() {
+        return usesBlockLight;
+    }
+
+    @Override
+    public TextureAtlasSprite getParticleIcon() {
+        // Return MISSING_TEXTURE.sprite() if you don't need a particle, e.g. when in an item model context.
+        return particle;
+    }
+
+    @Override
+    public BakedOverrides overrides() {
+        // Return BakedOverrides.EMPTY when in a block model context.
+        return overrides;
+    }
+
+    // Override this to true if you want to use a custom block entity renderer instead of the default renderer.
+    @Override
+    public boolean isCustomRenderer() {
+        return false;
+    }
+
+    // This is where the magic happens. Return a list of the quads to render here. Parameters are:
+    // - The blockstate being rendered. May be null if rendering an item.
+    // - The side being culled against. May be null, which means quads that cannot be occluded should be returned.
+    // - A client-bound random source you can use for randomizing stuff.
+    // - The extra data to use. Originates from a block entity (if present), or from BakedModel#getModelData().
+    // - The render type for which quads are being requested.
+    // NOTE: This may be called many times in quick succession, up to several times per block.
+    // This should be as fast as possible and use caching wherever applicable.
+    @Override
+    public List<BakedQuad> getQuads(@Nullable BlockState state, @Nullable Direction side, RandomSource rand, ModelData extraData, @Nullable RenderType renderType) {
+        List<BakedQuad> quads = new ArrayList<>();
+        // add elements to the quads list as needed here
+        return quads;
+    }
+}
+```
+
+When all is done, don't forget to actually register your loader, otherwise all the work will have been for nothing:
+
+```java
+// Client-side mod bus event handler
+@SubscribeEvent
+public static void registerGeometryLoaders(ModelEvent.RegisterGeometryLoaders event) {
+    event.register(MyGeometryLoader.ID, MyGeometryLoader.INSTANCE);
+}
+```
+
+### Datagen
+
+Of course, we can also [datagen] our models. To do so, we need a class that extends `CustomLoaderBuilder`:
+
+```java
+// This assumes a block model. Use ItemModelBuilder as the generic parameter instead 
+// if you're making a custom item model.
+public class MyLoaderBuilder extends CustomLoaderBuilder<BlockModelBuilder> {
+    public MyLoaderBuilder(BlockModelBuilder parent, ExistingFileHelper existingFileHelper) {
+        super(
+            // Your model loader's id.
+            MyGeometryLoader.ID,
+            // The parent builder we use. This is always the first constructor parameter.
+            parent,
+            // The existing file helper we use. This is always the second constructor parameter.
+            existingFileHelper,
+            // Whether the loader allows inline vanilla elements as a fallback if the loader is absent.
+            false
+        );
+    }
+    
+    // Add fields and setters for the fields here. The fields can then be used below.
+    
+    // Serialize the model to JSON.
+    @Override
+    public JsonObject toJson(JsonObject json) {
+        // Add your fields to the given JsonObject.
+        // Then call super, which adds the loader property and some other things.
+        return super.toJson(json);
+    }
+}
+```
+
+To use this loader builder, do the following during block (or item) [model datagen][modeldatagen]:
+
+```java
+// This assumes a BlockStateProvider. Use getBuilder("my_cool_block") directly in an ItemModelProvider.
+// The parameter for customLoader() is a BiFunction. The parameters of the BiFunction
+// are the result of the getBuilder() call and the provider's ExistingFileHelper.
+MyLoaderBuilder loaderBuilder = models().getBuilder("my_cool_block").customLoader(MyLoaderBuilder::new);
+```
+
+Then, call your field setters on the `loaderBuilder`.
+
+#### Visibility
+
+The default implementation of `CustomLoaderBuilder` holds methods for applying visibility. You may choose to use or ignore the `visibility` property in your model loader. Currently, only the [composite model loader][composite] makes use of this property.
+
+### Reusing the Default Model Loader
+
+In some contexts, it makes sense to reuse the vanilla model loader and just building your model logic on top of that instead of outright replacing it. We can do so using a neat trick: In the model loader, we simply remove the `loader` property and send it back to the model deserializer, tricking it into thinking that it is a regular model now. We then pass it to the geometry, bake the model geometry there (like the default geometry handler would) and pass it along to the dynamic model, where we can then use the model's quads in whatever way we want:
+
+```java
+public class MyGeometryLoader implements IGeometryLoader<MyGeometry> {
+    public static final MyGeometryLoader INSTANCE = new MyGeometryLoader();
+    public static final ResourceLocation ID = ResourceLocation.fromNamespaceAndPath(...);
+    
+    private MyGeometryLoader() {}
+    
+    @Override
+    public MyGeometry read(JsonObject jsonObject, JsonDeserializationContext context) throws JsonParseException {
+        // Trick the deserializer into thinking this is a normal model by removing the loader field and then passing it back into the deserializer.
+        jsonObject.remove("loader");
+        BlockModel base = context.deserialize(jsonObject, BlockModel.class);
+        // other stuff here if needed
+        return new MyGeometry(base);
+    }
+}
+
+public class MyGeometry implements IUnbakedGeometry<MyGeometry> {
+    private final BlockModel base;
+
+    // Store the block model for usage below.            
+    public MyGeometry(BlockModel base) {
+        this.base = base;
+    }
+
+    @Override
+    public BakedModel bake(IGeometryBakingContext context, ModelBaker baker, Function<Material, TextureAtlasSprite> spriteGetter, ModelState modelState, List<ItemOverride> overrides) {
+        BakedModel bakedBase = this.base.bake(baker, spriteGetter, modelState);
+        return new MyDynamicModel(bakedBase, /* other parameters here */);
+    }
+
+    @Override
+    public void resolveDependencies(UnbakedModel.Resolver resolver, IGeometryBakingContext context) {
+        this.base.resolveDependencies(resolver);
+    }
+}
+
+public class MyDynamicModel implements IDynamicBakedModel {
+    private final BakedModel base;
+    // other fields here
+
+    public MyDynamicModel(BakedModel base, /* other parameters here */) {
+        this.base = base;
+        // set other fields here
+    }
+
+    // other override methods here
+
+    @Override
+    public List<BakedQuad> getQuads(@Nullable BlockState state, @Nullable Direction side, RandomSource rand, ModelData extraData, @Nullable RenderType renderType) {
+        List<BakedQuad> quads = new ArrayList<>();
+        // Add the base model's quads. Can also do something different with the quads here, depending on what you need.
+        quads.addAll(this.base.getQuads(state, side, rand, extraData, renderType));
+        // add other elements to the quads list as needed here
+        return quads;
+    }
+    
+    // Apply the base model's transforms to our model as well.
+    @Override
+    public BakedModel applyTransform(ItemDisplayContext transformType, PoseStack poseStack, boolean applyLeftHandTransform) {
+        return this.base.applyTransform(transformType, poseStack, applyLeftHandTransform);
+    }
+}
+```
+
+[bakedmodel]: bakedmodel.md
+[ber]: ../../../blockentities/ber.md
+[bewlr]: ../../../blockentities/ber.md#blockentitywithoutlevelrenderer
+[composite]: #composite-model
+[datagen]: ../../index.md#data-generation
+[elements]: index.md#elements
+[event]: ../../../concepts/events.md#registering-an-event-handler
+[model]: index.md#specification
+[modeldatagen]: datagen.md
+[rendertype]: index.md#render-types
+[sides]: ../../../concepts/sides.md
+[tint]: index.md#tinting
+[transform]: index.md#root-transforms
diff --git a/versioned_docs/version-1.21.3/resources/client/particles.md b/versioned_docs/version-1.21.3/resources/client/particles.md
new file mode 100644
index 00000000..51ec1145
--- /dev/null
+++ b/versioned_docs/version-1.21.3/resources/client/particles.md
@@ -0,0 +1,268 @@
+# Particles
+
+Particles are 2D effects that polish the game and add immersion. They can be spawned both client and server [side], but being mostly visual in nature, critical parts exist only on the physical (and logical) client side.
+
+## Registering Particles
+
+### `ParticleType`
+
+Particles are registered using `ParticleType`s. These work similar to `EntityType`s or `BlockEntityType`s, in that there's a `Particle` class - every spawned particle is an instance of that class -, and then there's the `ParticleType` class, holding some common information, that is used for registration. `ParticleType`s are a [registry], which means that we want to register them using a `DeferredRegister` like all other registered objects:
+
+```java
+public class MyParticleTypes {
+    // Assuming that your mod id is examplemod
+    public static final DeferredRegister<ParticleType<?>> PARTICLE_TYPES =
+        DeferredRegister.create(BuiltInRegistries.PARTICLE_TYPE, "examplemod");
+    
+    // The easiest way to add new particle types is reusing vanilla's SimpleParticleType.
+    // Implementing a custom ParticleType is also possible, see below.
+    public static final Supplier<SimpleParticleType> MY_PARTICLE = PARTICLE_TYPES.register(
+        // The name of the particle type.
+        "my_particle",
+        // The supplier. The boolean parameter denotes whether setting the Particles option in the
+        // video settings to Minimal will affect this particle type or not; this is false for
+        // most vanilla particles, but true for e.g. explosions, campfire smoke, or squid ink.
+        () -> new SimpleParticleType(false)
+    );
+}
+```
+
+:::info
+A `ParticleType` is only necessary if you need to work with particles on the server side. The client can also use `Particle`s directly.
+:::
+
+### `Particle`
+
+A `Particle` is what is later spawned into the world and displayed to the player. While you may extend `Particle` and implement things yourself, in many cases it will be better to extend `TextureSheetParticle` instead, as this class provides helpers for things such as animating and scaling, and also does the actual rendering for you (all of which you'd need to implement yourself if extending `Particle` directly).
+
+Most properties of `Particle`s are controlled by fields such as `gravity`, `lifetime`, `hasPhysics`, `friction`, etc. The only two methods that make sense to implement yourself are `tick` and `move`, both of which do exactly what you'd expect. As such, custom particle classes are often short, consisting e.g. only of a constructor that sets some fields and lets the superclass handle the rest. A basic implementation would look somewhat like this:
+
+```java
+public class MyParticle extends TextureSheetParticle {
+    private final SpriteSet spriteSet;
+    
+    // First four parameters are self-explanatory. The SpriteSet parameter is provided by the
+    // ParticleProvider, see below. You may also add additional parameters as needed, e.g. xSpeed/ySpeed/zSpeed.
+    public MyParticle(ClientLevel level, double x, double y, double z, SpriteSet spriteSet) {
+        super(level, x, y, z);
+        this.spriteSet = spriteSet;
+        this.gravity = 0; // Our particle floats in midair now, because why not.
+
+        // We set the initial sprite here since ticking is not guaranteed to set the sprite
+        // before the render method is called.
+        this.setSpriteFromAge(spriteSet);
+    }
+    
+    @Override
+    public void tick() {
+        // Set the sprite for the current particle age, i.e. advance the animation.
+        this.setSpriteFromAge(spriteSet);
+        // Let super handle further movement. You may replace this with your own movement if needed.
+        // You may also override move() if you only want to modify the built-in movement.
+        super.tick();
+    }
+}
+```
+
+### `ParticleProvider`
+
+Next, particle types must register a `ParticleProvider`. `ParticleProvider` is a client-only class responsible for actually creating our `Particle`s through the `createParticle` method. While more elaborate code can be included here, many particle providers are as simple as this:
+
+```java
+// The generic type of ParticleProvider must match the type of the particle type this provider is for.
+public class MyParticleProvider implements ParticleProvider<SimpleParticleType> {
+    // A set of particle sprites.
+    private final SpriteSet spriteSet;
+    
+    // The registration function passes a SpriteSet, so we accept that and store it for further use.
+    public MyParticleProvider(SpriteSet spriteSet) {
+        this.spriteSet = spriteSet;
+    }
+    
+    // This is where the magic happens. We return a new particle each time this method is called!
+    // The type of the first parameter matches the generic type passed to the super interface.
+    @Override
+    public Particle createParticle(SimpleParticleType type, ClientLevel level,
+            double x, double y, double z, double xSpeed, double ySpeed, double zSpeed) {
+        // We don't use the type and speed, and pass in everything else. You may of course use them if needed.
+        return new MyParticle(level, x, y, z, spriteSet);
+    }
+}
+```
+
+Your particle provider must then be associated with the particle type in the [client-side][side] [mod bus][modbus] [event] `RegisterParticleProvidersEvent`:
+
+```java
+@SubscribeEvent
+public static void registerParticleProviders(RegisterParticleProvidersEvent event) {
+    // There are multiple ways to register providers, all differing in the functional type they provide in the
+    // second parameter. For example, #registerSpriteSet represents a Function<SpriteSet, ParticleProvider<?>>:
+    event.registerSpriteSet(MyParticleTypes.MY_PARTICLE.get(), MyParticleProvider::new);
+    // Other methods include #registerSprite, which is essentially a Supplier<TextureSheetParticle>,
+    // and #registerSpecial, which maps to a Supplier<Particle>. See the source code of the event for further info.
+}
+```
+
+### Particle Descriptions
+
+Finally, we must associate our particle type with a texture. Similar to how items are associated with an item model, we associate our particle type with what is known as a particle description. A particle description is a JSON file in the `assets/<namespace>/particles` directory and has the same name as the particle type (so for example `my_particle.json` for the above example). The particle definition JSON has the following format:
+
+```json5
+{
+    // A list of textures that will be played in order. Will loop if necessary.
+    // Texture locations are relative to the textures/particle folder.
+    "textures": [
+        "examplemod:my_particle_0",
+        "examplemod:my_particle_1",
+        "examplemod:my_particle_2",
+        "examplemod:my_particle_3"
+    ]
+}
+```
+
+A particle definition is required when using a particle that takes in a `SpriteSet`, which is done when registering a particle provider via `registerSpriteSet` or `registerSprite`. They must **not** be provided for particle providers registered via `#registerSpecial`.
+
+:::danger
+A mismatched list of sprite set particle factories and particle definition files, i.e. a particle description without a corresponding particle factory, or vice versa, will throw an exception!
+:::
+
+:::note
+While particle descriptions must have providers registered a certain way, they are only used if the `ParticleRenderType` (set via `Particle#getRenderType`) uses the `TextureAtlas#LOCATION_PARTICLES` as the shader texture. For vanilla render types, these are `PARTICLE_SHEET_OPAQUE` and `PARTICLE_SHEET_TRANSLUCENT`.
+:::
+
+### Datagen
+
+Particle definition files can also be [datagenned][datagen] by extending `ParticleDescriptionProvider` and overriding the `#addDescriptions()` method:
+
+```java
+public class MyParticleDescriptionProvider extends ParticleDescriptionProvider {
+    // Get the parameters from GatherDataEvent.
+    public AMParticleDefinitionsProvider(PackOutput output, ExistingFileHelper existingFileHelper) {
+        super(output, existingFileHelper);
+    }
+
+    // Assumes that all the referenced particles actually exists. Replace "examplemod" with your mod id.
+    @Override
+    protected void addDescriptions() {
+        // Adds a single sprite particle definition with the file at
+        // assets/examplemod/textures/particle/my_single_particle.png.
+        sprite(MyParticleTypes.MY_SINGLE_PARTICLE.get(), ResourceLocation.fromNamespaceAndPath("examplemod", "my_single_particle"));
+        // Adds a multi sprite particle definition, with a vararg parameter. Alternatively accepts a list.
+        spriteSet(MyParticleTypes.MY_MULTI_PARTICLE.get(),
+            ResourceLocation.fromNamespaceAndPath("examplemod", "my_multi_particle_0"),
+            ResourceLocation.fromNamespaceAndPath("examplemod", "my_multi_particle_1"),
+            ResourceLocation.fromNamespaceAndPath("examplemod", "my_multi_particle_2")
+        );
+        // Alternative for the above, appends "_<index>" to the base name given, for the given amount of textures.
+        spriteSet(MyParticleTypes.MY_ALT_MULTI_PARTICLE.get(),
+            // The base name.
+            ResourceLocation.fromNamespaceAndPath("examplemod", "my_multi_particle"),
+            // The amount of textures.
+            3,
+            // Whether to reverse the list, i.e. start at the last element instead of the first.
+            false
+        );
+    }
+}
+```
+
+Don't forget to add the provider to the `GatherDataEvent`:
+
+```java
+@SubscribeEvent
+public static void gatherData(GatherDataEvent event) {
+    DataGenerator generator = event.getGenerator();
+    PackOutput output = generator.getPackOutput();
+    ExistingFileHelper existingFileHelper = event.getExistingFileHelper();
+
+    // other providers here
+    generator.addProvider(
+        event.includeClient(),
+        new MyParticleDescriptionProvider(output, existingFileHelper)
+    );
+}
+```
+
+### Custom `ParticleType`s
+
+While for most cases `SimpleParticleType` suffices, it is sometimes necessary to attach additional data to the particle on the server side. This is where a custom `ParticleType` and an associated custom `ParticleOptions` are required. Let's start with the `ParticleOptions`, as that is where the information is actually stored:
+
+```java
+public class MyParticleOptions implements ParticleOptions {
+    
+    // Read and write information, typically for use in commands
+    // Since there is no information in this type, this will be an empty string
+    public static final MapCodec<MyParticleOptions> CODEC = MapCodec.unit(new MyParticleOptions());
+
+    // Read and write information to the network buffer.
+    public static final StreamCodec<ByteBuf, MyParticleOptions> STREAM_CODEC = StreamCodec.unit(new MyParticleOptions());
+
+    // Does not need any parameters, but may define any fields necessary for the particle to work.
+    public MyParticleOptions() {}
+
+    @Override
+    public ParticleType<?> getType() {
+        // Return the registered particle type
+    }
+}
+```
+
+We then use this `ParticleOptions` implementation in our custom `ParticleType`...
+
+```java
+public class MyParticleType extends ParticleType<MyParticleOptions> {
+    // The boolean parameter again determines whether to limit particles at lower particle settings.
+    // See implementation of the MyParticleTypes class near the top of the article for more information.
+    public MyParticleType(boolean overrideLimiter) {
+        // Pass the deserializer to super.
+        super(overrideLimiter);
+    }
+
+    @Override
+    public MapCodec<MyParticleOptions> codec() {
+        return MyParticleOptions.CODEC;
+    }
+
+    @Override
+    public StreamCodec<? super RegistryFriendlyByteBuf, MyParticleOptions> streamCodec() {
+        return MyParticleOptions.STREAM_CODEC;
+    }
+}
+```
+
+... and reference it during [registration][registry]:
+
+```java
+public static final Supplier<MyParticleType> MY_CUSTOM_PARTICLE = PARTICLE_TYPES.register(
+    "my_custom_particle",
+    () -> new MyParticleType(false)
+);
+```
+
+The registered particle is then passed into `ParticleOptions#getType`:
+
+```java
+public class MyParticleOptions implements ParticleOptions {
+    
+    // ...
+
+    @Override
+    public ParticleType<?> getType() {
+        return MY_CUSTOM_PARTICLE.get();
+    }
+}
+```
+
+## Spawning Particles
+
+As a reminder from before, the server only knows `ParticleType`s and `ParticleOption`s, while the client works directly with `Particle`s provided by `ParticleProvider`s that are associated with a `ParticleType`. Consequently, the ways in which particles are spawned are vastly different depending on the side you are on.
+
+- **Common code**: Call `Level#addParticle` or `Level#addAlwaysVisibleParticle`. This is the preferred way of creating particles that are visible to everyone.
+- **Client code**: Use the common code way. Alternatively, create a `new Particle()` with the particle class of your choice and call `Minecraft.getInstance().particleEngine#add(Particle)` with that particle. Note that particles added this way will only display for the client and thus not be visible to other players.
+- **Server code**: Call `ServerLevel#sendParticles`. Used in vanilla by the `/particle` command.
+
+[datagen]: ../index.md#data-generation
+[event]: ../../concepts/events.md
+[modbus]: ../../concepts/events.md#event-buses
+[registry]: ../../concepts/registries.md#methods-for-registering
+[side]: ../../concepts/sides.md
diff --git a/versioned_docs/version-1.21.3/resources/client/sounds.md b/versioned_docs/version-1.21.3/resources/client/sounds.md
new file mode 100644
index 00000000..fc278133
--- /dev/null
+++ b/versioned_docs/version-1.21.3/resources/client/sounds.md
@@ -0,0 +1,315 @@
+# Sounds
+
+Sounds, while not required for anything, can make a mod feel much more nuanced and alive. Minecraft offers you various ways to register and play sounds, which will be laid out in this article.
+
+## Terminology
+
+The Minecraft sound engine uses a variety of terms to refer to different things:
+
+- **Sound event**: A sound event is an in-code trigger that tells the sound engine to play a certain sound. `SoundEvent`s are also the things you register to the game.
+- **Sound category** or **sound source**: Sound categories are rough groupings of sounds that can be individually toggled. The sliders in the sound options GUI represent these categories: `master`, `block`, `player` etc. In code, they can be found in the `SoundSource` enum.
+- **Sound definition**: A mapping of a sound event to one or multiple sound objects, plus some optional metadata. Sound definitions are located in a namespace's [`sounds.json` file][soundsjson].
+- **Sound object**: A JSON object consisting of a sound file location, plus some optional metadata.
+- **Sound file**: An on-disk sound file. Minecraft only supports `.ogg` sound files.
+
+:::danger
+Due to the implementation of OpenAL (Minecraft's audio library), for your sound to have attenuation - that is, for it to get quieter and louder depending on the player's distance to it -, your sound file must be mono (single channel). Stereo (multichannel) sound files will not be subject to attenuation and always play at the player's location, making them ideal for ambient sounds and background music. See also [MC-146721][bug].
+:::
+
+## Creating `SoundEvent`s
+
+`SoundEvent`s are [registered objects][registration], meaning that they must be registered to the game through a `DeferredRegister` and be singletons:
+
+```java
+public class MySoundsClass {
+    // Assuming that your mod id is examplemod
+    public static final DeferredRegister<SoundEvent> SOUND_EVENTS =
+            DeferredRegister.create(BuiltInRegistries.SOUND_EVENT, "examplemod");
+    
+    // All vanilla sounds use variable range events.
+    public static final Holder<SoundEvent> MY_SOUND = SOUND_EVENTS.register(
+            "my_sound",
+            // Takes in the registry name
+            SoundEvent::createVariableRangeEvent
+    );
+    
+    // There is a currently unused method to register fixed range (= non-attenuating) events as well:
+    public static final Holder<SoundEvent> MY_FIXED_SOUND = SOUND_EVENTS.register(
+            "my_fixed_sound",
+            // 16 is the default range of sounds. Be aware that due to OpenAL limitations,
+            // values above 16 have no effect and will be capped to 16.
+            registryName -> SoundEvent.createFixedRangeEvent(registryName, 16f)
+    );
+}
+```
+
+Of course, don't forget to add your registry to the [mod event bus][modbus] in the [mod constructor][modctor]:
+
+```java
+public ExampleMod(IEventBus modBus) {
+    MySoundsClass.SOUND_EVENTS.register(modBus);
+    // other things here
+}
+```
+
+And voilà, you have a sound event!
+
+## `sounds.json`
+
+_See also: [sounds.json][mcwikisounds] on the [Minecraft Wiki][mcwiki]_
+
+Now, to connect your sound event to actual sound files, we need to create sound definitions. All sound definitions for a namespace are stored in a single file named `sounds.json`, also known as the sound definitions file, directly in the namespace's root. Every sound definition is a mapping of sound event id (e.g. `my_sound`) to a JSON sound object. Note that the sound event ids do not specify a namespace, as that is already determined by the namespace the sound definitions file is in. An example `sounds.json` would look something like this:
+
+```json5
+{
+    // Sound definition for the sound event "examplemod:my_sound"
+    "my_sound": {
+        // List of sound objects. If this contains more than one element, an element will be chosen randomly.
+        "sounds": [
+            // Only name is required, all other properties are optional.
+            {
+                // Location of the sound file, relative to the namespace's sounds folder.
+                // This example references a sound at assets/examplemod/sounds/sound_1.ogg.
+                "name": "examplemod:sound_1",
+                // May be "sound" or "event". "sound" causes the name to refer to a sound file.
+                // "event" causes the name to refer to another sound event. Defaults to "sound".
+                "type": "sound",
+                // The volume this sound will be played at. Must be between 0.0 and 1.0 (default).
+                "volume": 0.8,
+                // The pitch value the sound will be played at.
+                // Must be between 0.0 and 2.0. Defaults to 1.0.
+                "pitch": 1.1,
+                // Weight of this sound when choosing a sound from the sounds list. Defaults to 1.
+                "weight": 3,
+                // If true, the sound will be streamed from the file instead of loaded all at once.
+                // Recommended for sound files that are more than a few seconds long. Defaults to false.
+                "stream": true,
+                // Manual override for the attenuation distance. Defaults to 16. Ignored by fixed range sound events.
+                "attenuation_distance": 8,
+                // If true, the sound will be loaded into memory on pack load, instead of when the sound is played.
+                // Vanilla uses this for underwater ambience sounds. Defaults to false.
+                "preload": true
+            },
+            // Shortcut for { "name": "examplemod:sound_2" }
+            "examplemod:sound_2"
+        ]
+    },
+    "my_fixed_sound": {
+        // Optional. If true, replaces sounds from other resource packs instead of adding to them.
+        // See the Merging chapter below for more information.
+        "replace": true,
+        // The translation key of the subtitle displayed when this sound event is triggered.
+        "subtitle": "examplemod.my_fixed_sound",
+        "sounds": [
+            "examplemod:sound_1",
+            "examplemod:sound_2"
+        ]
+    }
+}
+```
+
+### Merging
+
+Unlike most other resource files, `sounds.json` do not overwrite values in packs below them. Instead, they are merged together and then interpreted as one combined `sounds.json` file. Consider sounds `sound_1`, `sound_2`, `sound_3` and `sound_4` being defined in two `sounds.json` files from two different resource packs RP1 and RP2, where RP2 is placed below RP1:
+
+`sounds.json` in RP1:
+
+```json5
+{
+    "sound_1": {
+        "sounds": [
+            "sound_1"
+        ]
+    },
+    "sound_2": {
+        "replace": true,
+        "sounds": [
+            "sound_2"
+        ]
+    },
+    "sound_3": {
+        "sounds": [
+            "sound_3"
+        ]
+    },
+    "sound_4": {
+        "replace": true,
+        "sounds": [
+            "sound_4"
+        ]
+    }
+}
+```
+
+`sounds.json` in RP2:
+
+```json5
+{
+    "sound_1": {
+        "sounds": [
+            "sound_5"
+        ]
+    },
+    "sound_2": {
+        "sounds": [
+            "sound_6"
+        ]
+    },
+    "sound_3": {
+        "replace": true,
+        "sounds": [
+            "sound_7"
+        ]
+    },
+    "sound_4": {
+        "replace": true,
+        "sounds": [
+            "sound_8"
+        ]
+    }
+}
+```
+
+The combined (merged) `sounds.json` file the game would then go on and use to load sounds would look something look this (only in memory, this file is never written anywhere):
+
+```json5
+{
+    "sound_1": {
+        // replace false and false: add from lower pack, then from upper pack
+        "sounds": [
+            "sound_5",
+            "sound_1"
+        ]
+    },
+    "sound_2": {
+        // replace true in upper pack and false in lower pack: add from upper pack only
+        "sounds": [
+            "sound_2"
+        ]
+    },
+    "sound_3": {
+        // replace false in upper pack and true in lower pack: add from lower pack, then from upper pack
+        // Would still discard values from a third resource pack sitting below RP2
+        "sounds": [
+            "sound_7",
+            "sound_3"
+        ]
+    },
+    "sound_4": {
+        // replace true and true: add from upper pack only
+        "sounds": [
+            "sound_8"
+        ]
+    }
+}
+```
+
+## Playing Sounds
+
+Minecraft offers various methods to play sounds, and it is sometimes unclear which one should be used. All methods accept a `SoundEvent`, which can either be your own or a vanilla one (vanilla sound events are found in the `SoundEvents` class). For the following method descriptions, client and server refer to the [logical client and logical server][sides], respectively.
+
+### `Level`
+
+- `playSeededSound(Player player, double x, double y, double z, Holder<SoundEvent> soundEvent, SoundSource soundSource, float volume, float pitch, long seed)`
+    - Client behavior: If the player passed in is the local player, play the sound event to the player at the given location, otherwise no-op.
+    - Server behavior: A packet instructing the client to play the sound event to the player at the given location is sent to all players except the one passed in.
+    - Usage: Call from client-initiated code that will run on both sides. The server not playing it to the initiating player prevents playing the sound event twice to them. Alternatively, call from server-initiated code (e.g. a [block entity][be]) with a `null` player to play the sound to everyone.
+- `playSound(Player player, double x, double y, double z, SoundEvent soundEvent, SoundSource soundSource, float volume, float pitch)`
+    - Forwards to `playSeededSound` with a random seed selected and the holder wrapped around the `SoundEvent`
+- `playSound(Player player, BlockPos pos, SoundEvent soundEvent, SoundSource soundSource, float volume, float pitch)`
+    - Forwards to the above method with `x`, `y` and `z` taking the values of `pos.getX() + 0.5`, `pos.getY() + 0.5` and `pos.getZ() + 0.5`, respectively.
+- `playLocalSound(double x, double y, double z, SoundEvent soundEvent, SoundSource soundSource, float volume, float pitch, boolean distanceDelay)`
+    - Client behavior: Plays the sound to the player at the given location. Does not send anything to the server. If `distanceDelay` is `true`, delays the sound based on the distance to the player.
+    - Server behavior: No-op.
+    - Usage: Called from custom packets sent from the server. Vanilla uses this for thunder sounds.
+
+### `ClientLevel`
+
+- `playLocalSound(BlockPos pos, SoundEvent soundEvent, SoundSource soundSource, float volume, float pitch, boolean distanceDelay)`
+    - Forwards to `Level#playLocalSound` with `x`, `y` and `z` taking the values of `pos.getX() + 0.5`, `pos.getY() + 0.5` and `pos.getZ() + 0.5`, respectively.
+
+### `Entity`
+
+- `playSound(SoundEvent soundEvent, float volume, float pitch)`
+    - Forwards to `Level#playSound` with `null` as the player, `Entity#getSoundSource` as the sound source, the entity's position for x/y/z, and the other parameters passed in.
+
+### `Player`
+
+- `playSound(SoundEvent soundEvent, float volume, float pitch)` (overrides the method in `Entity`)
+    - Forwards to `Level#playSound` with `this` as the player, `SoundSource.PLAYER` as the sound source, the player's position for x/y/z, and the other parameters passed in. As such, the client/server behavior mimics the one from `Level#playSound`:
+        - Client behavior: Play the sound event to the client player at the given location.
+        - Server behavior: Play the sound event to everyone near the given location except the player this method was called on.
+
+## Datagen
+
+Sound files themselves can of course not be [datagenned][datagen], but `sounds.json` files can. To do so, we extend `SoundDefinitionsProvider` and override the `registerSounds()` method:
+
+```java
+public class MySoundDefinitionsProvider extends SoundDefinitionsProvider {
+    // Parameters can be obtained from GatherDataEvent.
+    public MySoundDefinitionsProvider(PackOutput output, ExistingFileHelper existingFileHelper) {
+        // Use your actual mod id instead of "examplemod".
+        super(output, "examplemod", existingFileHelper);
+    }
+
+    @Override
+    public void registerSounds() {
+        // Accepts a Supplier<SoundEvent>, a SoundEvent, or a ResourceLocation as the first parameter.
+        add(MySoundsClass.MY_SOUND, SoundDefinition.definition()
+            // Add sound objects to the sound definition. Parameter is a vararg.
+            .with(
+                // Accepts either a string or a ResourceLocation as the first parameter.
+                // The second parameter can be either SOUND or EVENT, and can be omitted if the former.
+                sound("examplemod:sound_1", SoundDefinition.SoundType.SOUND)
+                    // Sets the volume. Also has a double counterpart.
+                    .volume(0.8f)
+                    // Sets the pitch. Also has a double counterpart.
+                    .pitch(1.2f)
+                    // Sets the weight.
+                    .weight(2)
+                    // Sets the attenuation distance.
+                    .attenuationDistance(8)
+                    // Enables streaming.
+                    // Also has a parameterless overload that defers to stream(true).
+                    .stream(true)
+                    // Enables preloading.
+                    // Also has a parameterless overload that defers to preload(true).
+                    .preload(true),
+                // The shortest we can get.
+                sound("examplemod:sound_2")
+            )
+            // Sets the subtitle.
+            .subtitle("sound.examplemod.sound_1")
+            // Enables replacing.
+            .replace(true)
+        );
+    }
+}
+```
+
+As with every data provider, don't forget to register the provider to the event:
+
+```java
+@SubscribeEvent
+public static void gatherData(GatherDataEvent event) {
+    DataGenerator generator = event.getGenerator();
+    PackOutput output = generator.getPackOutput();
+    ExistingFileHelper existingFileHelper = event.getExistingFileHelper();
+
+    // other providers here
+    generator.addProvider(
+        event.includeClient(),
+        new MySoundDefinitionsProvider(output, existingFileHelper)
+    );
+}
+```
+
+[bug]: https://bugs.mojang.com/browse/MC-146721
+[datagen]: ../index.md#data-generation
+[mcwiki]: https://minecraft.wiki
+[mcwikisounds]: https://minecraft.wiki/w/Sounds.json
+[modbus]: ../../concepts/events.md#event-buses
+[modctor]: ../../gettingstarted/modfiles.md#javafml-and-mod
+[registration]: ../../concepts/registries.md
+[sides]: ../../concepts/sides.md#the-logical-side
+[soundsjson]: #soundsjson
diff --git a/versioned_docs/version-1.21.3/resources/client/textures.md b/versioned_docs/version-1.21.3/resources/client/textures.md
new file mode 100644
index 00000000..0f3541cd
--- /dev/null
+++ b/versioned_docs/version-1.21.3/resources/client/textures.md
@@ -0,0 +1,73 @@
+# Textures
+
+All textures in Minecraft are PNG files located within a namespace's `textures` folder. JPG, GIF and other image formats are not supported. The path of [resource locations][rl] referring to textures is generally relative to the `textures` folder, so for example, the resource location `examplemod:block/example_block` refers to the texture file at `assets/examplemod/textures/block/example_block.png`.
+
+Textures should generally be in sizes that are powers of two, for example 16x16 or 32x32. Unlike older versions, modern Minecraft natively supports block and item texture sizes greater than 16x16. For textures that are not in powers of two that you render yourself anyway (for example GUI backgrounds), create an empty file in the next available power-of-two size (often 256x256), and add your texture in the top left corner of that file, leaving the rest of the file empty. The actual size of the drawn texture can then be set in the code that uses the texture.
+
+## Texture Metadata
+
+Texture metadata can be specified in a file named exactly the same as the texture, with an additional `.mcmeta` suffix. For example, an animated texture at `textures/block/example.png` would need an accompanying `textures/block/example.png.mcmeta` file. The `.mcmeta` file has the following format (all optional):
+
+```json5
+{
+    // Whether the texture will be blurred if needed. Defaults to false.
+    // Currently specified by the codec, but unused otherwise both in the files and in code.
+    "blur": true,
+    // Whether the texture will be clamped if needed. Defaults to false.
+    // Currently specified by the codec, but unused otherwise both in the files and in code.
+    "clamp": true,
+    "gui": {
+        // Specifies how the texture will be scaled if needed. Can be one of these three:
+        "scaling": {
+            "type": "stretch" // default
+        },
+        "scaling": {
+            "type": "tile",
+            "width": 16,
+            "height": 16
+        },
+        "scaling": {
+            // Like "tile", but allows specifying the border offsets.
+            "type": "nine_slice",
+            "width": 16,
+            "height": 16,
+            // May also be a single int that is used as the value for all four sides.
+            "border": {
+                "left": 0,
+                "top": 0,
+                "right": 0,
+                "bottom": 0
+            },
+            // When true the center part of the texture will be applied like
+            // the stretch type instead of a nine slice tiling.
+            "stretch_inner": true
+        }
+    },
+    // See below.
+    "animation": {}
+}
+```
+
+## Animated Textures
+
+Minecraft natively supports animated textures for blocks and items. Animated textures consist of a texture file where the different animation stages are located below each other (for example, an animated 16x16 texture with 8 phases would be represented through a 16x128 PNG file).
+
+To actually be animated and not just be displayed as a distorted texture, there must be an `animation` object in the texture metadata. The sub-object can be empty, but may contain the following optional entries:
+
+```json5
+{
+    "animation": {
+        // A custom order in which the frames are played. If omitted, the frames are played top to bottom.
+        "frames": [1, 0],
+        // How long one frame stays before switching to the next animation stage, in frames. Defaults to 1.
+        "frametime": 5,
+        // Whether to interpolate between animation stages. Defaults to false.
+        "interpolate": true,
+        // Width and height of one animation stage. If omitted, uses the texture width for both of these.
+        "width": 12,
+        "height": 12
+    }
+}
+```
+
+[rl]: ../../misc/resourcelocation.md
diff --git a/versioned_docs/version-1.21.3/resources/index.md b/versioned_docs/version-1.21.3/resources/index.md
new file mode 100644
index 00000000..a74519b6
--- /dev/null
+++ b/versioned_docs/version-1.21.3/resources/index.md
@@ -0,0 +1,218 @@
+# Resources
+
+Resources are external files that are used by the game, but are not code. The most prominent kinds of resources are textures, however, many other types of resources exist in the Minecraft ecosystem. Of course, all these resources require a consumer on the code side, so the consuming systems are grouped in this section as well.
+
+Minecraft generally has two kinds of resources: resources for the [logical client][logicalsides], known as assets, and resources for the [logical server][logicalsides], known as data. Assets are mostly display-only information, for example textures, display models, translations, or sounds, while data includes various things that affect gameplay, such as loot tables, recipes, or worldgen information. They are loaded from resource packs and data packs, respectively. NeoForge generates a built-in resource and data pack for every mod.
+
+Both resource and data packs normally require a [`pack.mcmeta` file][packmcmeta]; however, modern NeoForge generates these at runtime for you, so you don't need to worry about it.
+
+If you are confused about the format of something, have a look at the vanilla resources. Your NeoForge development environment not only contains vanilla code, but also vanilla resources. They can be found in the External Resources section (IntelliJ)/Project Libraries section (Eclipse), under the name `ng_dummy_ng.net.minecraft:client:client-extra:<minecraft_version>` (for Minecraft resources) or `ng_dummy_ng.net.neoforged:neoforge:<neoforge_version>` (for NeoForge resources).
+
+## Assets
+
+_See also: [Resource Packs][mcwikiresourcepacks] on the [Minecraft Wiki][mcwiki]_
+
+Assets, or client-side resources, are all resources that are only relevant on the [client][sides]. They are loaded from resource packs, sometimes also known by the old term texture packs (stemming from old versions when they could only affect textures). A resource pack is basically an `assets` folder. The `assets` folder contains subfolders for the various namespaces the resource pack includes; every namespace is one subfolder. For example, a resource pack for a mod with the id `coolmod` will probably contain a `coolmod` namespace, but may additionally include other namespaces, such as `minecraft`.
+
+NeoForge automatically collects all mod resource packs into the `Mod resources` pack, which sits at the bottom of the Selected Packs side in the resource packs menu. It is currently not possible to disable the `Mod resources` pack. However, resource packs that sit above the `Mod resources` pack override resources defined in a resource pack below them. This mechanic allows resource pack makers to override your mod's resources, and also allows mod developers to override Minecraft resources if needed.
+
+Resource packs can contain [models][models], [blockstate files][bsfile], [textures][textures], [sounds][sounds], [particle definitions][particles] and [translation files][translations].
+
+## Data
+
+_See also: [Data Packs][mcwikidatapacks] on the [Minecraft Wiki][mcwiki]_
+
+In contrast to assets, data is the term for all [server][sides] resources. Similar to resource packs, data is loaded through data packs (or datapacks). Like a resource pack, a data pack consists of a [`pack.mcmeta` file][packmcmeta] and a root folder, named `data`. Then, again like with resource packs, that `data` folder contains subfolders for the various namespaces the resource pack includes; every namespace is one subfolder. For example, a data pack for a mod with the id `coolmod` will probably contain a `coolmod` namespace, but may additionally include other namespaces, such as `minecraft`.
+
+NeoForge automatically applies all mod data packs to a new world upon creation. It is currently not possible to disable mod data packs. However, most data files can be overridden (and thus be removed by replacing them with an empty file) by a data pack with a higher priority. Additional data packs can be enabled or disabled by placing them in a world's `datapacks` subfolder and then enabling or disabling them through the [`/datapack`][datapackcmd] command.
+
+:::info
+There is currently no built-in way to apply a set of custom data packs to every world. However, there are a number of mods that achieve this.
+:::
+
+Data packs may contain folders with files affecting the following things:
+
+| Folder name                                                                       | Contents                     |
+|-----------------------------------------------------------------------------------|------------------------------|
+| `advancement`                                                                     | [Advancements][advancements] |
+| `damage_type`                                                                     | [Damage types][damagetypes]  |
+| `loot_table`                                                                      | [Loot tables][loottables]    |
+| `recipe`                                                                          | [Recipes][recipes]           |
+| `tags`                                                                            | [Tags][tags]                 |
+| `neoforge/data_maps`                                                              | [Data maps][datamap]         |
+| `neoforge/loot_modifiers`                                                         | [Global loot modifiers][glm] |
+| `dimension`, `dimension_type`, `structure`, `worldgen`, `neoforge/biome_modifier` | Worldgen files               |
+
+Additionally, they may also contain subfolders for some systems that integrate with commands. These systems are rarely used in conjunction with mods, but worth mentioning regardless:
+
+| Folder name     | Contents                       |
+|-----------------|--------------------------------|
+| `chat_type`     | [Chat types][chattype]         |
+| `function`      | [Functions][function]          |
+| `item_modifier` | [Item modifiers][itemmodifier] |
+| `predicate`     | [Predicates][predicate]        |
+
+## `pack.mcmeta`
+
+_See also: [`pack.mcmeta` (Resource Pack)][packmcmetaresourcepack] and [`pack.mcmeta` (Data Pack)][packmcmetadatapack] on the [Minecraft Wiki][mcwiki]_
+
+`pack.mcmeta` files hold the metadata of a resource or data pack. For mods, NeoForge makes this file obsolete, as the `pack.mcmeta` is generated synthetically. In case you still need a `pack.mcmeta` file, the full specification can be found in the linked Minecraft Wiki articles.
+
+## Data Generation
+
+Data generation, colloquially known as datagen, is a way to programmatically generate JSON resource files, in order to avoid the tedious and error-prone process of writing them by hand. The name is a bit misleading, as it works for assets as well as data.
+
+Datagen is run through the Data run configuration, which is generated for you alongside the Client and Server run configurations. The data run configuration follows the [mod lifecycle][lifecycle] until after the registry events are fired. It then fires the [`GatherDataEvent`][event], in which you can register your to-be-generated objects in the form of data providers, writes said objects to disk, and ends the process.
+
+All data providers extend the `DataProvider` interface and usually require one method to be overridden. The following is a list of noteworthy data generators Minecraft and NeoForge offer (the linked articles add further information, such as helper methods):
+
+| Class                                                | Method                           | Generates                                                               | Side   | Notes                                                                                                           |
+|------------------------------------------------------|----------------------------------|-------------------------------------------------------------------------|--------|-----------------------------------------------------------------------------------------------------------------|
+| [`BlockStateProvider`][blockstateprovider]           | `registerStatesAndModels()`      | Blockstate files, block models                                          | Client |                                                                                                                 |
+| [`ItemModelProvider`][itemmodelprovider]             | `registerModels()`               | Item models                                                             | Client |                                                                                                                 |
+| [`LanguageProvider`][langprovider]                   | `addTranslations()`              | Translations                                                            | Client | Also requires passing the language in the constructor.                                                          |
+| [`ParticleDescriptionProvider`][particleprovider]    | `addDescriptions()`              | Particle definitions                                                    | Client |                                                                                                                 |
+| [`SoundDefinitionsProvider`][soundprovider]          | `registerSounds()`               | Sound definitions                                                       | Client |                                                                                                                 |
+| `SpriteSourceProvider`                               | `gather()`                       | Sprite sources / atlases                                                | Client |                                                                                                                 |
+| [`AdvancementProvider`][advancementprovider]         | `generate()`                     | Advancements                                                            | Server | Make sure to use the NeoForge variant, not the Minecraft one.                                                   |
+| [`LootTableProvider`][loottableprovider]             | `generate()`                     | Loot tables                                                             | Server | Requires extra methods and classes to work properly, see linked article for details.                            |
+| [`RecipeProvider`][recipeprovider]                   | `buildRecipes(RecipeOutput)`     | Recipes                                                                 | Server |                                                                                                                 |
+| [Various subclasses of `TagsProvider`][tagsprovider] | `addTags(HolderLookup.Provider)` | Tags                                                                    | Server | Several specialized subclasses exist, see linked article for details.                                           |
+| [`DataMapProvider`][datamapprovider]                 | `gather()`                       | Data map entries                                                        | Server |                                                                                                                 |
+| [`GlobalLootModifierProvider`][glmprovider]          | `start()`                        | Global loot modifiers                                                   | Server |                                                                                                                 |
+| [`DatapackBuiltinEntriesProvider`][datapackprovider] | N/A                              | Datapack builtin entries, e.g. worldgen and [damage types][damagetypes] | Server | No method overriding, instead entries are added in a lambda in the constructor. See linked article for details. |
+| `JsonCodecProvider` (abstract class)                 | `gather()`                       | Objects with a codec                                                    | Both   | This can be extended for use with any object that has a [codec] to encode data to.                              |
+
+All of these providers follow the same pattern. First, you create a subclass and add your own resources to be generated. Then, you add the provider to the event in an [event handler][eventhandler]. An example using a `RecipeProvider`:
+
+```java
+public class MyRecipeProvider extends RecipeProvider {
+    public MyRecipeProvider(PackOutput output, CompletableFuture<HolderLookup.Provider> lookupProvider) {
+        super(output, lookupProvider);
+    }
+
+    @Override
+    protected void buildRecipes(RecipeOutput output) {
+        // Register your recipes here.
+    }
+}
+
+@EventBusSubscriber(bus = EventBusSubscriber.Bus.MOD, modid = "examplemod")
+public class MyDatagenHandler {
+    @SubscribeEvent
+    public static void gatherData(GatherDataEvent event) {
+        // Data generators may require some of these as constructor parameters.
+        // See below for more details on each of these.
+        DataGenerator generator = event.getGenerator();
+        PackOutput output = generator.getPackOutput();
+        ExistingFileHelper existingFileHelper = event.getExistingFileHelper();
+        CompletableFuture<HolderLookup.Provider> lookupProvider = event.getLookupProvider();
+
+        // Register the provider.
+        generator.addProvider(
+                // A boolean that determines whether the data should actually be generated.
+                // The event provides methods that determine this:
+                // event.includeClient(), event.includeServer(),
+                // event.includeDev() and event.includeReports().
+                // Since recipes are server data, we only run them in a server datagen.
+                event.includeServer(),
+                // Our provider.
+                new MyRecipeProvider(output, lookupProvider)
+        );
+        // Other data providers here.
+    }
+}
+```
+
+The event offers some context for you to use:
+
+- `event.getGenerator()` returns the `DataGenerator` that you register the providers to.
+- `event.getPackOutput()` returns a `PackOutput` that is used by some providers to determine their file output location.
+- `event.getExistingFileHelper()` returns an `ExistingFileHelper` that is used by providers for things that can reference other files (for example block models, which can specify a parent file).
+- `event.getLookupProvider()` returns a `CompletableFuture<HolderLookup.Provider>` that is mainly used by tags and datagen registries to reference other, potentially not yet existing elements.
+- `event.includeClient()`, `event.includeServer()`, `event.includeDev()` and `event.includeReports()` are `boolean` methods that allow you to check whether specific command line arguments (see below) are enabled.
+
+### Command Line Arguments
+
+The data generator can accept several command line arguments:
+
+- `--mod examplemod`: Tells the data generator to run datagen for this mod. Automatically added by NeoGradle for the owning mod id, add this if you e.g. have multiple mods in one project.
+- `--output path/to/folder`: Tells the data generator to output into the given folder. It is recommended to use Gradle's `file(...).getAbsolutePath()` to generate an absolute path for you (with a path relative to the project root directory). Defaults to `file('src/generated/resources').getAbsolutePath()`.
+- `--existing path/to/folder`: Tells the data generator to consider the given folder when checking for existing files. Like with the output, it is recommended to use Gradle's `file(...).getAbsolutePath()`.
+- `--existing-mod examplemod`: Tells the data generator to consider the resources in the given mod's JAR file when checking for existing files.
+- Generator modes (all of these are boolean arguments and do not need any additional arguments):
+    - `--includeClient`: Whether to generate client resources (assets). Check at runtime with `GatherDataEvent#includeClient()`.
+    - `--includeServer`: Whether to generate server resources (data). Check at runtime with `GatherDataEvent#includeServer()`.
+    - `--includeDev`: Whether to run dev tools. Generally shouldn't be used by mods. Check at runtime with `GatherDataEvent#includeDev()`.
+    - `--includeReports`: Whether to dump a list of registered objects. Check at runtime with `GatherDataEvent#includeReports()`.
+    - `--all`: Enable all generator modes.
+
+All arguments can be added to the run configurations by adding the following to your `build.gradle`:
+
+```groovy
+runs {
+    // other run configurations here
+
+    data {
+        programArguments.addAll '--arg1', 'value1', '--arg2', 'value2', '--all' // boolean args have no value
+    }
+}
+```
+
+For example, to replicate the default arguments, you could specify the following:
+
+```groovy
+runs {
+    // other run configurations here
+
+    data {
+        programArguments.addAll '--mod', 'examplemod', // insert your own mod id
+                '--output', file('src/generated/resources').getAbsolutePath(),
+                '--includeClient',
+                '--includeServer'
+    }
+}
+```
+
+[advancementprovider]: server/advancements.md#data-generation
+[advancements]: server/advancements.md
+[blockstateprovider]: client/models/datagen.md#block-model-datagen
+[bsfile]: client/models/index.md#blockstate-files
+[chattype]: https://minecraft.wiki/w/Chat_type
+[codec]: ../datastorage/codecs.md
+[damagetypes]: server/damagetypes.md
+[datamap]: server/datamaps/index.md
+[datamapprovider]: server/datamaps/index.md#data-generation
+[datapackcmd]: https://minecraft.wiki/w/Commands/datapack
+[datapackprovider]: ../concepts/registries.md#data-generation-for-datapack-registries
+[event]: ../concepts/events.md
+[eventhandler]: ../concepts/events.md#registering-an-event-handler
+[function]: https://minecraft.wiki/w/Function_(Java_Edition)
+[glm]: server/loottables/glm.md
+[glmprovider]: server/loottables/glm.md#datagen
+[itemmodelprovider]: client/models/datagen.md#item-model-datagen
+[itemmodifier]: https://minecraft.wiki/w/Item_modifier
+[langprovider]: client/i18n.md#datagen
+[lifecycle]: ../concepts/events.md#the-mod-lifecycle
+[logicalsides]: ../concepts/sides.md#the-logical-side
+[loottableprovider]: server/loottables/index.md#datagen
+[loottables]: server/loottables/index.md
+[mcwiki]: https://minecraft.wiki
+[mcwikidatapacks]: https://minecraft.wiki/w/Data_pack
+[mcwikiresourcepacks]: https://minecraft.wiki/w/Resource_pack
+[models]: client/models/index.md
+[packmcmeta]: #packmcmeta
+[packmcmetadatapack]: https://minecraft.wiki/w/Data_pack#pack.mcmeta
+[packmcmetaresourcepack]: https://minecraft.wiki/w/Resource_pack#Contents
+[particleprovider]: client/particles.md#datagen
+[particles]: client/particles.md
+[predicate]: https://minecraft.wiki/w/Predicate
+[recipeprovider]: server/recipes/index.md#data-generation
+[recipes]: server/recipes/index.md
+[sides]: ../concepts/sides.md
+[soundprovider]: client/sounds.md#datagen
+[sounds]: client/sounds.md
+[tags]: server/tags.md
+[tagsprovider]: server/tags.md#datagen
+[textures]: client/textures.md
+[translations]: client/i18n.md#language-files
diff --git a/versioned_docs/version-1.21.3/resources/server/_category_.json b/versioned_docs/version-1.21.3/resources/server/_category_.json
new file mode 100644
index 00000000..8de78b39
--- /dev/null
+++ b/versioned_docs/version-1.21.3/resources/server/_category_.json
@@ -0,0 +1,3 @@
+{
+    "label": "Server"
+}
\ No newline at end of file
diff --git a/versioned_docs/version-1.21.3/resources/server/advancements.md b/versioned_docs/version-1.21.3/resources/server/advancements.md
new file mode 100644
index 00000000..3ca5143f
--- /dev/null
+++ b/versioned_docs/version-1.21.3/resources/server/advancements.md
@@ -0,0 +1,293 @@
+# Advancements
+
+Advancements are quest-like tasks that can be achieved by the player. Advancements are awarded based on advancement criteria, and can run behavior when completed.
+
+A new advancement can be added by creating a JSON file in your namespace's `advancement` subfolder. So for example, if we want to add an advancement named `example_name` for a mod with the mod id `examplemod`, it will be located at `data/examplemod/advancement/example_name.json`. An advancement's ID will be relative to the `advancement` directory, so for our example, it would be `examplemod:example_name`. Any name can be chosen, and the advancement will automatically be picked up by the game. Java code is only necessary if you want to add new criteria or trigger a certain criterion from code (see below).
+
+## Specification
+
+An advancement JSON file may contain the following entries:
+
+- `parent`: The parent advancement ID of this advancement. Circular references will be detected and cause a loading failure. Optional; if absent, this advancement will be considered a root advancement. Root advancements are advancements that have no parent set. They will be the root of their [advancement tree][tree].
+- `display`: The object holding several properties used for display of the advancement in the advancement GUI. Optional; if absent, this advancement will be invisible, but can still be triggered.
+    - `icon`: A [JSON representation of an item stack][itemstackjson].
+    - `text`: A [text component][text] to use as the advancement's title.
+    - `description`: A [text component][text] to use as the advancement's description.
+    - `frame`: The frame type of the advancement. Accepts `challenge`, `goal` and `task`. Optional, defaults to `task`.
+    - `background`: The texture to use for the tree background. This is not relative to the `textures` directory, i.e. the `textures/` folder prefix must be included. Optional, defaults to the missing texture. Only effective on root advancements.
+    - `show_toast`: Whether to show a toast in the top right corner on completion. Optional, defaults to true.
+    - `announce_to_chat`: Whether to announce advancement completion in the chat. Optional, defaults to true.
+    - `hidden`: Whether to hide this advancement and all children from the advancement GUI until it is completed. Has no effect on root advancements themselves, but still hides all of their children. Optional, defaults to false.
+- `criteria`: A map of criteria this advancement should track. Every criterion is identified by its map key. A list of criteria triggers added by Minecraft can be found in the `CriteriaTriggers` class, and the JSON specifications can be found on the [Minecraft Wiki][triggers]. For implementing your own criteria or triggering criteria from code, see below.
+- `requirements`: A list of lists that determine what criteria are required. This is a list of OR lists that are ANDed together, or in other words, every sublist must have at least one criterion matching. Optional, defaults to all criteria being required.
+- `rewards`: An object representing the rewards to grant when this advancement is completed. Optional, all values of the object are also optional.
+    - `experience`: The amount of experience to award to the player.
+    - `recipes`: A list of [recipe] IDs to unlock.
+    - `loot`: A list of [loot tables][loottable] to roll and give to the player.
+    - `function`: A [function] to run. If you want to run multiple functions, create a wrapper function that runs all other functions.
+- `sends_telemetry_event`: Determines whether telemetry data should be collected when this advancement is completed or not. Only actually does anything if in the `minecraft` namespace. Optional, defaults to false.
+- `neoforge:conditions`: NeoForge-added. A list of [conditions] that must be passed for the advancement to be loaded. Optional.
+
+### Advancement Trees
+
+Advancement files may be grouped in directories, which tells the game to create multiple advancement tabs. One advancement tab may contain one or more advancement trees, depending on the amount of root advancements. Empty advancement tabs will automatically be hidden.
+
+:::tip
+Minecraft only ever has one root advancement per tab, and always calls the root advancement `root`. It is suggested to follow this practice.
+:::
+
+## Criteria Triggers
+
+To unlock an advancement, the specified criteria must be met. Criteria are tracked through triggers, which are executed from code when the associated action happens (e.g. the `player_killed_entity` trigger executes when the player kills the specified entity). Any time an advancement is loaded into the game, the criteria defined are read and added as listeners to the trigger. When a trigger is executed, all advancements that have a listener for the corresponding criterion are rechecked for completion. If the advancement is completed, the listeners are removed.
+
+Custom criteria triggers are made up of two parts: the trigger, which is activated in code by calling `#trigger`, and the instance which defines the conditions under which the trigger should award the criterion. The trigger extends `SimpleCriterionTrigger<T>` while the instance implements `SimpleCriterionTrigger.SimpleInstance`. The generic value `T` represents the trigger instance type.
+
+### `SimpleCriterionTrigger.SimpleInstance`
+
+A `SimpleCriterionTrigger.SimpleInstance` represents a single criterion defined in the `criteria` object. Trigger instances are responsible for holding the defined conditions, and returning whether the inputs match the condition.
+
+Conditions are usually passed in through the constructor. The `SimpleCriterionTrigger.SimpleInstance` interface requires only one function, called `#player`, which returns the conditions the player must meet as an `Optional<ContextAwarePredicate>`. If the subclass is a record with a `player` parameter of this type (as below), the automatically generated `#player` method will suffice.
+
+```java
+public record ExampleTriggerInstance(Optional<ContextAwarePredicate> player/*, other parameters here*/)
+        implements SimpleCriterionTrigger.SimpleInstance {}
+```
+
+Typically, trigger instances have static helper methods which construct the full `Criterion<T>` object from the arguments to the instance. This allows these instances to be easily created during data generation, but are optional.
+
+```java
+// In this example, EXAMPLE_TRIGGER is a DeferredHolder<CriterionTrigger<?>, ExampleTrigger>.
+// See below for how to register triggers.
+public static Criterion<ExampleTriggerInstance> instance(ContextAwarePredicate player, ItemPredicate item) {
+    return EXAMPLE_TRIGGER.get().createCriterion(new ExampleTriggerInstance(Optional.of(player), item));
+}
+```
+
+Finally, a method should be added which takes in the current data state and returns whether the user has met the necessary conditions. The conditions of the player are already checked through `SimpleCriterionTrigger#trigger(ServerPlayer, Predicate)`. Most trigger instances call this method `#matches`.
+
+```java
+// Let's assume we have an additional ItemPredicate parameter. This can be whatever you need.
+// For example, this could also be a Predicate<LivingEntity>.
+public record ExampleTriggerInstance(Optional<ContextAwarePredicate> player, ItemPredicate predicate)
+        implements SimpleCriterionTrigger.SimpleInstance {
+    // This method is unique for each instance and is as such not overridden.
+    // The parameter may be whatever you need to properly match, for example, this could also be a LivingEntity.
+    // If you need no context other than the player, this may also take no parameters at all.
+    public boolean matches(ItemStack stack) {
+        // Since ItemPredicate matches a stack, we use a stack as the input here.
+        return this.predicate.test(stack);
+    }
+}
+```
+
+### `SimpleCriterionTrigger`
+
+The `SimpleCriterionTrigger<T>` implementation has two purposes: supplying a method to check trigger instances and run attached listeners on success, and specifying a [codec] to serialize the trigger instance (`T`).
+
+First, we want to add a method that takes the inputs we need and calls `SimpleCriterionTrigger#trigger` to properly handle checking all listeners. Most trigger instances also name this method `#trigger`. Reusing our example trigger instance from above, our trigger would look something like this:
+
+```java
+public class ExampleCriterionTrigger extends SimpleCriterionTrigger<ExampleTriggerInstance> {
+    // This method is unique for each trigger and is as such not a method to override
+    public void trigger(ServerPlayer player, ItemStack stack) {
+        this.trigger(player,
+                // The condition checker method within the SimpleCriterionTrigger.SimpleInstance subclass
+                triggerInstance -> triggerInstance.matches(stack)
+        );
+    }
+}
+```
+
+Triggers must be registered to the `Registries.TRIGGER_TYPE` [registry][registration]:
+
+```java
+public static final DeferredRegister<CriterionTrigger<?>> TRIGGER_TYPES =
+        DeferredRegister.create(Registries.TRIGGER_TYPE, ExampleMod.MOD_ID);
+
+public static final Supplier<ExampleCriterionTrigger> EXAMPLE_TRIGGER =
+        TRIGGER_TYPES.register("example", ExampleCriterionTrigger::new);
+```
+
+And then, triggers must define a [codec] to serialize and deserialize the trigger instance by overriding `#codec`. This codec is typically created as a constant within the instance implementation.
+
+```java
+public record ExampleTriggerInstance(Optional<ContextAwarePredicate> player/*, other parameters here*/)
+        implements SimpleCriterionTrigger.SimpleInstance {
+    public static final Codec<ExampleTriggerInstance> CODEC = ...;
+
+    // ...
+}
+
+public class ExampleTrigger extends SimpleCriterionTrigger<ExampleTriggerInstance> {
+    @Override
+    public Codec<ExampleTriggerInstance> codec() {
+        return ExampleTriggerInstance.CODEC;
+    }
+
+    // ...
+}
+```
+
+For the earlier example of a record with a `ContextAwarePredicate` and an `ItemPredicate`, the codec could be:
+
+```java
+public static final Codec<ExampleTriggerInstace> CODEC = RecordCodecBuilder.create(instance -> instance.group(
+        EntityPredicate.ADVANCEMENT_CODEC.optionalFieldOf("player").forGetter(ExampleTriggerInstance::player),
+        ItemPredicate.CODEC.fieldOf("item").forGetter(ExampleTriggerInstance::item)
+).apply(instance, ExampleTriggerInstance::new));
+```
+
+### Calling Criterion Triggers
+
+Whenever the action being checked is performed, the `#trigger` method defined by our `SimpleCriterionTrigger` subclass should be called. Of course, you can also call on vanilla triggers, which are found in `CriteriaTriggers`.
+
+```java
+// In some piece of code where the action is being performed
+// Again, EXAMPLE_TRIGGER is a supplier for the registered instance of the custom criterion trigger
+public void performExampleAction(ServerPlayer player, additionalContextParametersHere) {
+    // Run code to perform action here
+    EXAMPLE_TRIGGER.get().trigger(player, additionalContextParametersHere);
+}
+```
+
+## Data Generation
+
+Advancements can be [datagenned][datagen] using an `AdvancementProvider`. An `AdvancementProvider` accepts a list of `AdvancementGenerator`s, which actually generate the advancements using `Advancement.Builder`.
+
+:::warning
+Both Minecraft and NeoForge provide a class named `AdvancementProvider`, located at `net.minecraft.data.advancements.AdvancementProvider` and `net.neoforged.neoforge.common.data.AdvancementProvider`, respectively. The NeoForge class is an improvement on the one Minecraft provides, and should always be used in favor of the Minecraft one. The following documentation always assumes usage of the NeoForge `AdvancementProvider` class.
+:::
+
+To start, create an instance of `AdvancementProvider` within `GatherDataEvent`:
+
+```java
+@SubscribeEvent
+public static void gatherData(GatherDataEvent event) {
+    DataGenerator generator = event.getGenerator();
+    PackOutput output = generator.getPackOutput();
+    CompletableFuture<HolderLookup.Provider> lookupProvider = event.getLookupProvider();
+    ExistingFileHelper existingFileHelper = event.getExistingFileHelper();
+
+    generator.addProvider(
+            event.includeServer(),
+            new AdvancementProvider(
+                output, lookupProvider, existingFileHelper,
+                // Add generators here
+                List.of(...)
+            )
+    );
+
+     // Other providers
+}
+```
+
+Now, the next step is to fill the list with our generators. To do so, we can either add generators as classes or lambdas, and then add an instance of each of them to the currently empty list in the constructor parameter.
+
+```java
+// Class example
+public class MyAdvancementGenerator extends AdvancementProvider.AdvancementGenerator {
+
+    @Override
+    public void generate(HolderLookup.Provider registries, Consumer<AdvancementHolder> saver, ExistingFileHelper existingFileHelper) {
+        // Generate your advancements here.
+    }
+}
+
+// Method Example
+public class ExampleClass {
+
+    // Matches the parameters provided by AdvancementProvider.AdvancementGenerator#generate
+    public static void generateExampleAdvancements(HolderLookup.Provider registries, Consumer<AdvancementHolder> saver, ExistingFileHelper existingFileHelper) {
+        // Generate your advancements here.
+    }
+}
+
+// In GatherDataEvent
+generator.addProvider(
+    event.includeServer(),
+    new AdvancementProvider(
+        output, lookupProvider, existingFileHelper,
+        // Add generators here
+        List.of(
+            // Add an instance of our generator to the list parameter. This can be done as many times as you want.
+            // Having multiple generators is purely for organization, all functionality can be achieved with a single generator.
+            new MyAdvancementGenerator(),
+            ExampleClass::generateExampleAdvancements
+        )
+    )
+);
+```
+
+To generate an advancement, you want to use an `Advancement.Builder`:
+
+```java
+// All methods follow the builder pattern, meaning that chaining is possible and encouraged.
+// For better readability of the explanations, chaining will not be done here.
+
+// Create an advancement builder using the static #advancement() method.
+// Using #advancement() automatically enables telemetry events. If you do not want this,
+// #recipeAdvancement() can be used instead, there are no other functional differences.
+Advancement.Builder builder = Advancement.Builder.advancement();
+
+// Sets the parent of the advancement. You can use another advancement you have already generated,
+// or create a placeholder advancement using the static AdvancementSubProvider#createPlaceholder method.
+builder.parent(AdvancementSubProvider.createPlaceholder("minecraft:story/root"));
+
+// Sets the display properties of the advancement. This can either be a DisplayInfo object,
+// or pass in the values directly. If values are passed in directly, a DisplayInfo object will be created for you.
+builder.display(
+        // The advancement icon. Can be an ItemStack or an ItemLike.
+        new ItemStack(Items.GRASS_BLOCK),
+        // The advancement title and description. Don't forget to add translations for these!
+        Component.translatable("advancements.examplemod.example_advancement.title"),
+        Component.translatable("advancements.examplemod.example_advancement.description"),
+        // The background texture. Use null if you don't want a background texture (for non-root advancements).
+        null,
+        // The frame type. Valid values are AdvancementType.TASK, CHALLENGE, or GOAL.
+        AdvancementType.GOAL,
+        // Whether to show the advancement toast or not.
+        true,
+        // Whether to announce the advancement into chat or not.
+        true,
+        // Whether the advancement should be hidden or not.
+        false
+);
+
+// An advancement reward builder. Can be created with any of the four reward types, and further rewards
+// can be added using the methods prefixed with add. This can also be built beforehand,
+// and the resulting AdvancementRewards can then be reused across multiple advancement builders.
+builder.rewards(
+    // Alternatively, use addExperience() to add to an existing builder.
+    AdvancementRewards.Builder.experience(100)
+    // Alternatively, use loot() to create a new builder.
+    .addLootTable(ResourceKey.create(Registries.LOOT_TABLE, ResourceLocation.fromNamespaceAndPath("minecraft", "chests/igloo")))
+    // Alternatively, use recipe() to create a new builder.
+    .addRecipe(ResourceKey.create(Registries.RECIPE, ResourceLocation.fromNamespaceAndPath("minecraft", "iron_ingot")))
+    // Alternatively, use function() to create a new builder.
+    .runs(ResourceLocation.fromNamespaceAndPath("examplemod", "example_function"))
+);
+
+// Adds a criterion with the given name to the advancement. Use the corresponding trigger instance's static method.
+builder.addCriterion("pickup_dirt", InventoryChangeTrigger.TriggerInstance.hasItems(Items.DIRT));
+
+// Adds a requirements handler. Minecraft natively provides allOf() and anyOf(), more complex requirements
+// must be implemented manually. Only has an effect with two or more criteria.
+builder.requirements(AdvancementRequirements.allOf(List.of("pickup_dirt")));
+
+// Save the advancement to disk, using the given resource location. This returns an AdvancementHolder,
+// which may be stored in a variable and used as a parent by other advancement builders.
+builder.save(saver, ResourceLocation.fromNamespaceAndPath("examplemod", "example_advancement"), existingFileHelper);
+```
+
+[codec]: ../../datastorage/codecs.md
+[conditions]: conditions.md
+[datagen]: ../index.md#data-generation
+[function]: https://minecraft.wiki/w/Function_(Java_Edition)
+[itemstackjson]: ../../items/index.md#json-representation
+[loottable]: loottables/index.md
+[recipe]: recipes/index.md
+[registration]: ../../concepts/registries.md#methods-for-registering
+[root]: #root-advancements
+[text]: ../client/i18n.md#components
+[tree]: #advancement-trees
+[triggers]: https://minecraft.wiki/w/Advancement/JSON_format#List_of_triggers
diff --git a/versioned_docs/version-1.21.3/resources/server/conditions.md b/versioned_docs/version-1.21.3/resources/server/conditions.md
new file mode 100644
index 00000000..bc00f36b
--- /dev/null
+++ b/versioned_docs/version-1.21.3/resources/server/conditions.md
@@ -0,0 +1,202 @@
+# Data Load Conditions
+
+Sometimes, it is desirable to disable or enable certain features if another mod is present, or if any mod adds another type of ore, etc. For these use cases, NeoForge adds data load conditions. These were originally called recipe conditions, since recipes were the original use case for this system, but it has since been extended to other systems. This is also why some of the built-in conditions are limited to items.
+
+Most JSON files can optionally declare a `neoforge:conditions` block in the root, which will be evaluated before the data file is actually loaded. Loading will continue if and only if all conditions pass, otherwise the data file will be ignored. (The exception to this rule are [loot tables][loottable], which will be replaced with an empty loot table instead.)
+
+```json5
+{
+    "neoforge:conditions": [
+        {
+            // Condition 1
+        },
+        {
+            // Condition 2
+        },
+        // ...
+    ],
+    // The rest of the data file
+}
+```
+
+For example, if we want to only load our file if a mod with id `examplemod` is present, our file would look something like this:
+
+```json5
+{
+    // highlight-start
+    "neoforge:conditions": [
+        {
+            "type": "neoforge:mod_loaded",
+            "modid": "examplemod"
+        }
+    ],
+    // highlight-end
+    "type": "minecraft:crafting_shaped",
+    // ...
+}
+```
+
+:::note
+Most vanilla files have been patched to use conditions using the `ConditionalCodec` wrapper. However, not all systems, especially those not using a [codec], can use conditions. To find out whether a data file can use conditions, check the backing codec definition. 
+:::
+
+## Built-In Conditions
+
+### `neoforge:true` and `neoforge:false`
+
+These consist of no data and return the expected value.
+
+```json5
+{
+    // Will always return true (or false for "neoforge:false")
+    "type": "neoforge:true"
+}
+```
+
+:::tip
+Using the `neoforge:false` condition very cleanly allows disabling any data file. Simply place a file with the following contents at the needed location:
+
+```json5
+{"neoforge:conditions":[{"type":"neoforge:false"}]}
+```
+
+Disabling files this way will **not** cause log spam.
+:::
+
+### `neoforge:not`
+
+This condition accepts another condition and inverts it.
+
+```json5
+{
+    // Inverts the result of the stored condition
+    "type": "neoforge:not",
+    "value": {
+        // Another condition
+    }
+}
+```
+
+### `neoforge:and` and `neoforge:or`
+
+These conditions accept the condition(s) being operated upon and apply the expected logic. There is no limit to the amount of accepted conditions.
+
+```json5
+{
+    // ANDs the stored conditions together (or ORs for "neoforge:or")
+    "type": "neoforge:and",
+    "values": [
+        {
+            // First condition
+        },
+        {
+            // Second condition
+        }
+    ]
+}
+```
+
+### `neoforge:mod_loaded`
+
+This condition returns true if a mod with the given mod id is loaded, and false otherwise.
+
+```json5
+{
+    "type": "neoforge:mod_loaded",
+    // Returns true if "examplemod" is loaded
+    "modid": "examplemod"
+}
+```
+
+### `neoforge:item_exists`
+
+This condition returns true if an item with the given registry name has been registered, and false otherwise.
+
+```json5
+{
+    "type": "neoforge:item_exists",
+    // Returns true if "examplemod:example_item" has been registered
+    "item": "examplemod:example_item"
+}
+```
+
+### `neoforge:tag_empty`
+
+This condition returns true if the given item [tag] is empty, and false otherwise.
+
+```json5
+{
+    "type": "neoforge:tag_empty",
+    // Returns true if "examplemod:example_tag" is an empty item tag
+    "tag": "examplemod:example_tag"
+}
+```
+
+## Creating Custom Conditions
+
+Custom conditions can be created by implementing `ICondition` and its `#test(IContext)` method, as well as creating a [map codec][codec] for it. The `IContext` parameter in `#test` has access to some parts of the game state. Currently, this only allows you to query tags from registries. Some objects with conditions may be loaded earlier than tags, in which case the context will be `IContext.EMPTY` and not contain any tag information at all.
+
+For example, let's assume we want to reimplement the `tag_empty` condition, but for entity type tags instead of item tags, then our condition would look something like this:
+
+```java
+// This class is basically a boiled-down copy of TagEmptyCondition, adjusted for entity types instead of items.
+public record EntityTagEmptyCondition(TagKey<EntityType<?>> tag) implements ICondition {
+    public static final MapCodec<EntityTagEmptyCondition> CODEC = RecordCodecBuilder.mapCodec(inst -> inst.group(
+            TagKey.codec(Registries.ENTITY_TYPE).fieldOf("tag").forGetter(EntityTagEmptyCondition::tag)
+    ).apply(inst, EntityTagEmptyCondition::new));
+
+    @Override
+    public boolean test(ICondition.IContext context) {
+        return !context.isTagLoaded(this.tag());
+    }
+
+    @Override
+    public MapCodec<? extends ICondition> codec() {
+        return CODEC;
+    }
+}
+```
+
+Conditions are a registry of codecs. As such, we need to [register] our codec, like so:
+
+```java
+public static final DeferredRegister<MapCodec<? extends ICondition>> CONDITION_CODECS =
+        DeferredRegister.create(NeoForgeRegistries.Keys.CONDITION_CODECS, ExampleMod.MOD_ID);
+
+public static final Supplier<MapCodec<EntityTagEmptyCondition>> ENTITY_TAG_EMPTY =
+        CONDITION_CODECS.register("entity_tag_empty", () -> EntityTagEmptyCondition.CODEC);
+```
+
+And then, we can use our condition in some data file (assuming we registered the condition under the `examplemod` namespace):
+
+```json5
+{
+    "neoforge:conditions": [
+        {
+            "type": "examplemod:entity_tag_empty",
+            "tag": "minecraft:zombies"
+        }
+    ],
+    // The rest of the data file
+}
+```
+
+## Datagen
+
+While any datapack JSON file can use load conditions, only a few [data providers][datagen] have been modified to be able to generate them. These include:
+
+- [`RecipeProvider`][recipeprovider] (via `RecipeOutput#withConditions`), including recipe advancements
+- `JsonCodecProvider` and its subclass `SpriteSourceProvider`
+- [`DataMapProvider`][datamapprovider]
+- [`GlobalLootModifierProvider`][glmprovider]
+
+For the conditions themselves, the `IConditionBuilder` interface provides static helpers for each of the built-in condition types that return the corresponding `ICondition`s.
+
+[codec]: ../../datastorage/codecs
+[datagen]: ../index.md#data-generation
+[datamapprovider]: datamaps/index.md#data-generation
+[glmprovider]: loottables/glm.md#datagen
+[loottable]: loottables/index.md
+[recipeprovider]: recipes/index.md#data-generation
+[register]: ../../concepts/registries
+[tag]: tags.md
diff --git a/versioned_docs/version-1.21.3/resources/server/damagetypes.md b/versioned_docs/version-1.21.3/resources/server/damagetypes.md
new file mode 100644
index 00000000..6515f070
--- /dev/null
+++ b/versioned_docs/version-1.21.3/resources/server/damagetypes.md
@@ -0,0 +1,134 @@
+# Damage Types & Damage Sources
+
+A damage type denotes what kind of damage is being applied to an entity - physical damage, fire damage, drowning damage, magic damage, void damage, etc. The distinction into damage types is used for various immunities (e.g. blazes won't take fire damage), enchantments (e.g. blast protection will only protect against explosion damage), and many more use cases.
+
+A damage type is a template for a damage source, so to speak. Or in other words, a damage source can be viewed as a damage type instance. Damage types exist as [`ResourceKey`s][rk] in code, but have all of their properties defined in data packs. Damage sources, on the other hand, are created as needed by the game, based off the values in the data pack files. They can hold additional context, for example the attacking entity.
+
+## Creating Damage Types
+
+To get started, you want to create your own `DamageType`. `DamageType`s are a [datapack registry][dr], and as such, new `DamageType`s are not registered in code, but are registered automatically when the corresponding files are added. However, we still need to provide some point for the code to get the damage sources from. We do so by specifying a [resource key][rk]:
+
+```java
+public static final ResourceKey<DamageType> EXAMPLE_DAMAGE =
+        ResourceKey.create(Registries.DAMAGE_TYPE, ResourceLocation.fromNamespaceAndPath(ExampleMod.MOD_ID, "example"));
+```
+
+Now that we can reference it from code, let's specify some properties in the data file. Our data file is located at `data/examplemod/damage_type/example.json` (swap out `examplemod` and `example` for the mod id and the name of the resource location) and contains the following:
+
+```json5
+{
+    // The death message id of the damage type. The full death message translation key will be
+    // "death.attack.examplemod.example" (with swapped-out mod id and name).
+    "message_id": "examplemod.example",
+    // Whether this damage type's damage amount scales with difficulty or not. Valid vanilla values are:
+    // - "never": The damage value remains the same on any difficulty. Common for player-caused damage types.
+    // - "when_caused_by_living_non_player": The damage value is scaled if the entity is caused by a
+    //   living entity of some sort, including indirectly (e.g. an arrow shot by a skeleton), that is not a player.
+    // - "always": The damage value is always scaled. Commonly used by explosion-like damage.
+    "scaling": "when_caused_by_living_non_player",
+    // The amount of exhaustion caused by receiving this kind of damage.
+    "exhaustion": 0.1,
+    // The damage effects (currently only sound effects) that are applied when receiving this kind of damage. Optional.
+    // Valid vanilla values are "hurt" (default), "thorns", "drowning", "burning", "poking", and "freezing".
+    "effects": "hurt",
+    // The death message type. Determines how the death message is built. Optional.
+    // Valid vanilla values are "default" (default), "fall_variants", and "intentional_game_design".
+    "death_message_type": "default"
+}
+```
+
+:::tip
+The `scaling`, `effects` and `death_message_type` fields are internally controlled by the enums `DamageScaling`, `DamageEffects` and `DeathMessageType`, respectively. These enums can be [extended][extenum] to add custom values if needed.
+:::
+
+The same format is also used for vanilla's damage types, and pack developers can change these values if needed.
+ 
+## Creating and Using Damage Sources
+
+`DamageSource`s are usually created on the fly when `Entity#hurt` is called. Be aware that since damage types are a [datapack registry][dr], you will need a `RegistryAccess` to query them, which can be obtained via `Level#registryAccess`. To create a `DamageSource`, call the `DamageSource` constructor with up to four parameters:
+
+```java
+DamageSource damageSource = new DamageSource(
+        // The damage type holder to use. Query from the registry. This is the only required parameter.
+        registryAccess.lookupOrThrow(Registries.DAMAGE_TYPE).getOrThrow(EXAMPLE_DAMAGE),
+        // The direct entity. For example, if a skeleton shot you, the skeleton would be the causing entity
+        // (= the parameter above), and the arrow would be the direct entity (= this parameter). Similar to
+        // the causing entity, this isn't always applicable and therefore nullable. Optional, defaults to null.
+        null,
+        // The entity causing the damage. This isn't always applicable (e.g. when falling out of the world)
+        // and may therefore be null. Optional, defaults to null.
+        null,
+        // The damage source position. This is rarely used, one example would be intentional game design
+        // (= nether beds exploding). Nullable and optional, defaulting to null.
+        null
+);
+```
+
+:::warning
+`DamageSources#source`, which is a wrapper around `new DamageSource`, flips the second and third parameters (direct entity and causing entity). Make sure you are supplying the correct values to the correct parameters.
+:::
+
+If `DamageSource`s have no entity or position context whatsoever, it makes sense to cache them in a field. For `DamageSource`s that do have entity or position context, it is common to add helper methods, like so:
+
+```java
+public static DamageSource exampleDamage(Entity causer) {
+    return new DamageSource(
+            causer.level().registryAccess().lookupOrThrow(Registries.DAMAGE_TYPE).getOrThrow(EXAMPLE_DAMAGE),
+            causer);
+}
+```
+
+:::tip
+Vanilla's `DamageSource` factories can be found in `DamageSources`, and vanilla's `DamageType` resource keys can be found in `DamageTypes`.
+:::
+
+The first and foremost use case for damage sources is `Entity#hurt`. This method is called whenever an entity is receiving damage. To hurt an entity with our own damage type, we simply call `Entity#hurt` ourselves:
+
+```java
+// The second parameter is the amount of damage, in half hearts.
+entity.hurt(exampleDamage(player), 10);
+```
+
+Other damage type-specific behavior, such as invulnerability checks, is often run through damage type [tags]. These are both added by Minecraft and NeoForge and can be found under `DamageTypeTags` and `Tags.DamageTypes`, respectively.
+
+## Datagen
+
+_For more info, see [Data Generation for Datapack Registries][drdatagen]._
+
+Damage type JSON files can be [datagenned][datagen]. Since damage types are a datapack registry, we add a `DatapackBuiltinEntriesProvider` to the `GatherDataEvent` and put our damage types in the `RegistrySetBuilder`:
+
+```java
+// In your datagen class
+@SubscribeEvent
+public static void onGatherData(GatherDataEvent event) {
+    CompletableFuture<HolderLookup.Provider> lookupProvider = event.getGenerator().addProvider(
+            event.includeServer(),
+            output -> new DatapackBuiltinEntriesProvider(output, event.getLookupProvider(), new RegistrySetBuilder()
+                    // Add a datapack builtin entry provider for damage types. If this lambda becomes longer,
+                    // this should probably be extracted into a separate method for the sake of readability.
+                    .add(Registries.DAMAGE_TYPE, bootstrap -> {
+                        // Use new DamageType() to create an in-code representation of a damage type.
+                        // The parameters map to the values of the JSON file, in the order seen above.
+                        // All parameters except for the message id and the exhaustion value are optional.
+                        bootstrap.register(EXAMPLE_DAMAGE, new DamageType(EXAMPLE_DAMAGE.location(),
+                                DamageScaling.WHEN_CAUSED_BY_LIVING_NON_PLAYER,
+                                0.1f,
+                                DamageEffects.HURT,
+                                DeathMessageType.DEFAULT))
+                    })
+                    // Add datapack providers for other datapack entries, if applicable.
+                    .add(...),
+                    Set.of(ExampleMod.MOD_ID)
+            )
+    ).getRegistryProvider();
+
+    // ...
+}
+```
+
+[datagen]: ../index.md#data-generation
+[dr]: ../../concepts/registries.md#datapack-registries
+[drdatagen]: ../../concepts/registries.md#data-generation-for-datapack-registries
+[extenum]: ../../advanced/extensibleenums.md
+[rk]: ../../misc/resourcelocation.md#resourcekeys
+[tags]: tags.md
diff --git a/versioned_docs/version-1.21.3/resources/server/datamaps/builtin.md b/versioned_docs/version-1.21.3/resources/server/datamaps/builtin.md
new file mode 100644
index 00000000..8ae8b90d
--- /dev/null
+++ b/versioned_docs/version-1.21.3/resources/server/datamaps/builtin.md
@@ -0,0 +1,228 @@
+# Built-In Data Maps
+
+NeoForge provides various built-in [data maps][datamap] for common use cases, replacing hardcoded vanilla fields. Vanilla values are shipped by data map files in NeoForge, so there is no functional difference to the player.
+
+## `neoforge:compostables`
+
+Allows configuring composter values, as a replacement for `ComposterBlock.COMPOSTABLES` (which is now ignored). This data map is located at `neoforge/data_maps/item/compostables.json` and its objects have the following structure:
+
+```json5
+{
+    // A 0 to 1 (inclusive) float representing the chance that the item will update the level of the composter
+    "chance": 1,
+    // Optional, defaults to false - whether farmer villagers can compost this item
+    "can_villager_compost": false
+}
+```
+
+Example:
+
+```json5
+{
+    "values": {
+        // Give acacia logs a 50% chance that they will fill a composter
+        "minecraft:acacia_log": {
+            "chance": 0.5
+        }
+    }
+}
+```
+
+## `neoforge:furnace_fuels`
+
+Allows configuring item burn times. This data map is located at `neoforge/data_maps/item/furnace_fuels.json` and its objects have the following structure:
+
+```json5
+{
+    // A positive integer representing the item's burn time in ticks
+    "burn_time": 1000
+}
+```
+
+Example:
+
+```json5
+{
+    "values": {
+        // Give anvils a 2 seconds burn time
+        "minecraft:anvil": {
+            "burn_time": 40
+        }
+    }
+}
+```
+
+:::info
+NeoForge additionally adds the `IItemExtension#getBurnTime` method to be overridden in custom items, overruling this data map. `#getBurnTime` should only be used in scenarios where the datamap does not suffice, for example [data component][datacomponent]-dependent burn times.
+:::
+
+:::warning
+Vanilla adds an implicit burn time of 300 ticks (15 seconds) for `#minecraft:logs` and `#minecraft:planks`, and then hardcodes the removal of crimson and warped items from that. This means that if you add another non-flammable wood, you should add a removal for that wood type's items from this map, like so:
+
+```json5
+{
+    "replace": false,
+    "values": [
+        // values here
+    ],
+    "remove": [
+        "examplemod:example_nether_wood_planks",
+        "#examplemod:example_nether_wood_stems",
+        "examplemod:example_nether_wood_door",
+        // etc.
+        // other removals here
+    ]
+}
+```
+:::
+
+## `neoforge:monster_room_mobs`
+
+Allows configuring the mobs that may appear in the mob spawner in a monster room, as a replacement for `MonsterRoomFeature#MOBS` (which is now ignored). This data map is located at `neoforge/data_maps/entity_type/monster_room_mobs.json` and its objects have the following structure:
+
+```json5
+{
+    // The weight of this mob, relative to other mobs in the datamap
+    "weight": 100
+}
+```
+
+Example:
+
+```json5
+{
+    "values": {
+        // Make squids appear in monster room spawners with a weight of 100
+        "minecraft:squid": {
+            "weight": 100
+        }
+    }
+}
+```
+
+## `neoforge:oxidizables`
+
+Allows configuring oxidation stages, as a replacement for `WeatheringCopper#NEXT_BY_BLOCK` (which will be ignored in 1.21.2). This data map is also used to build a reverse deoxidation map (for scraping with an axe). It is located at `neoforge/data_maps/block/oxidizables.json` and its objects have the following structure:
+
+```json5
+{
+    // The block this block will turn into once oxidized
+    "next_oxidized_stage": "examplemod:oxidized_block"
+}
+```
+
+:::note
+Custom blocks must implement `WeatheringCopperFullBlock` or `WeatheringCopper` and call `changeOverTime` in `randomTick` to oxidize naturally.
+:::
+
+Example:
+
+```json5
+{
+    "values": {
+        "mymod:custom_copper": {
+            // Make a custom copper block oxidize into custom oxidized copper
+            "next_oxidized_stage": "mymod:custom_oxidized_copper"
+        }
+    }
+}
+```
+
+## `neoforge:parrot_imitations`
+
+Allows configuring the sounds produced by parrots when they want to imitate a mob, as a replacement for `Parrot#MOB_SOUND_MAP` (which is now ignored). This data map is located at `neoforge/data_maps/entity_type/parrot_imitations.json` and its objects have the following structure:
+
+```json5
+{
+    // The ID of the sound that parrots will produce when imitating the mob
+    "sound": "minecraft:entity.parrot.imitate.creeper"
+}
+```
+
+Example:
+
+```json5
+{
+    "values": {
+        // Make parrots produce the ambient cave sound when imitating allays
+        "minecraft:allay": {
+            "sound": "minecraft:ambient.cave"
+        }
+    }
+}
+```
+
+## `neoforge:raid_hero_gifts`
+
+Allows configuring the gift that a villager with a certain `VillagerProfession` may gift you if you stop the raid, as a replacement for `GiveGiftToHero#GIFTS` (which is now ignored). This data map is located at `neoforge/data_maps/villager_profession/raid_hero_gifts.json` and its objects have the following structure:
+
+```json5
+{
+    // The ID of the loot table that a villager profession will hand out after a raid
+    "loot_table": "minecraft:gameplay/hero_of_the_village/armorer_gift"
+}
+```
+
+Example:
+
+```json5
+{
+    "values": {
+        "minecraft:armorer": {
+            // Make armorers give the raid hero the armorer gift loot table
+            "loot_table": "minecraft:gameplay/hero_of_the_village/armorer_gift"
+        }
+    }
+}
+```
+
+## `neoforge:vibration_frequencies`
+
+Allows configuring the sculk vibration frequencies emitted by game events, as a replacement for `VibrationSystem#VIBRATION_FREQUENCY_FOR_EVENT` (which is now ignored). This data map is located at `neoforge/data_maps/game_event/vibration_frequencies.json` and its objects have the following structure:
+
+```json5
+{
+    // An integer between 1 and 15 (inclusive) that indicates the vibration frequency of the event
+    "frequency": 2
+}
+```
+
+Example:
+
+```json5
+{
+    "values": {
+        // Make the splash in water game event vibrate on the second frequency
+        "minecraft:splash": {
+            "frequency": 2
+        }
+    }
+}
+```
+
+## `neoforge:waxables`
+
+Allows configuring the block a block will turn into when waxed (right clicked with a honeycomb), as a replacement for `HoneycombItem#WAXABLES` (which will be ignored in 1.21.2). This data map is also used to build a reverse dewaxing map (for scraping with an axe). It is located at `neoforge/data_maps/block/waxables.json` and its objects have the following structure:
+
+```json5
+{
+    // The waxed variant of this block
+    "waxed": "minecraft:iron_block"
+}
+```
+
+Example:
+
+```json5
+{
+    "values": {
+        // Make gold blocks turn into iron blocks once waxed
+        "minecraft:gold_block": {
+            "waxed": "minecraft:iron_block"
+        }
+    }
+}
+```
+
+[datacomponent]: ../../../items/datacomponents.md
+[datamap]: index.md
diff --git a/versioned_docs/version-1.21.3/resources/server/datamaps/index.md b/versioned_docs/version-1.21.3/resources/server/datamaps/index.md
new file mode 100644
index 00000000..f874d870
--- /dev/null
+++ b/versioned_docs/version-1.21.3/resources/server/datamaps/index.md
@@ -0,0 +1,390 @@
+# Data Maps
+
+A data map contains data-driven, reloadable objects that can be attached to a registered object. This system allows for more easily data-driving game behaviour, as they provide functionality such as syncing or conflict resolution, leading to a better and more configurable user experience. You can think of [tags] as registry object ➜ boolean maps, while data maps are more flexible registry object ➜ object maps. Similar to [tags], data maps will add to their corresponding data map rather than overwriting.
+
+Data maps can be attached to both static, built-in, registries and dynamic data-driven datapack registries. Data maps support reloading through the use of the `/reload` command or any other means that reload server resources.
+
+NeoForge provides various [built-in data maps][builtin] for common use cases, replacing hardcoded vanilla fields. More info can be found in the linked article.
+
+## File Location
+
+Data maps are loaded from a JSON file located at `<mapNamespace>/data_maps/<registryNamespace>/<registryPath>/<mapPath>.json`, where:
+
+- `<mapNamespace>` is the namespace of the ID of the data map,
+- `<mapPath>` is the path of the ID of the data map,
+- `<registryNamespace>` is the namespace of the ID of the registry (omitted if it is `minecraft`), and
+- `<registryPath>` is the path of the ID of the registry.
+
+Examples:
+
+- For a data map named `mymod:drop_healing` for the `minecraft:item` registry (as in the example below), the path will be `mymod/data_maps/item/drop_healing.json`.
+- For a data map named `somemod:somemap` for the `minecraft:block` registry, the path will be `somemod/data_maps/block/somemap.json`.
+- For a data map named `example:stuff` for the `somemod:custom` registry, the path will be `example/data_maps/somemod/custom/stuff.json`.
+
+## JSON Structure
+
+A data map file itself may contain the following fields:
+
+- `replace`: A boolean that will clear the data map before adding the values of this file. This should never be shipped by mods, and only be used by pack developers that want to overwrite this map for their own purposes.
+- `neoforge:conditions`: A list of [loading conditions][conditions].
+- `values`: A map of registry IDs or tag IDs to values that should be added to the data map by your mod. The structure of the values themselves is defined by the data map's codec (see below).
+- `remove`: A list of registry IDs or tag IDs to be removed from the data map.
+
+### Adding Values
+
+For example, let's assume that we have a data map object with two float keys `amount` and `chance` for the registry `minecraft:item`. A corresponding data map file could look something like this:
+
+```json5
+{
+    "values": {
+        // Attach a value to the carrot item
+        "minecraft:carrot": {
+            "amount": 12,
+            "chance": 1
+        },
+        // Attach a value to all items in the logs tag
+        "#minecraft:logs": {
+            "amount": 1,
+            "chance": 0.1
+        }
+    }
+}
+```
+
+Data maps may support [mergers][mergers], which will cause custom merging behavior in the case of a conflict, e.g. if two mods add a data map value for the same item. To avoid the merger from triggering, we can specify the `replace` field on the element level, like so:
+
+```json5
+{
+    "values": {
+        // Overwrite the value of the carrot item
+        "minecraft:carrot": {
+            // highlight-next-line
+            "replace": true,
+            // The new value will be under a value sub-object
+            "value": {
+                "amount": 12,
+                "chance": 1
+            }
+        }
+    }
+}
+```
+
+### Removing Existing Values
+
+Removing elements can be done by specifying a list of item IDs or tag IDs to remove:
+
+```json5
+{
+    // We do not want the potato to have a value, even if another mod's data map added it
+    "remove": [
+        "minecraft:potato"
+    ]
+}
+```
+
+Removals run after additions, so we can include a tag and then exclude certain elements from it again:
+
+```json5
+{
+    "values": {
+        "#minecraft:logs": { /* ... */ }
+    },
+    // Exclude crimson stem again
+    "remove": [
+        "minecraft:crimson_stem"
+    ]
+}
+```
+
+Data maps may support custom [removers] with additional arguments. To supply these, the `remove` list can be transformed into a JSON object that contains the to-be-removed elements as map keys and the additional data as the associated value. For example, let's assume that our remover object is serialized to a string, then our remover map could look something like this:
+
+```json5
+{
+    "remove": {
+        // The remover will be deserialized from the value (`somekey1` in this case)
+        // and applied to the value attached to the carrot item
+        "minecraft:carrot": "somekey1"
+    }
+}
+```
+
+## Custom Data Maps
+
+To begin, we define the format of our data map entries. **Data map entries must be immutable**, making records ideal for this. Reiterating our example from above with two float values `amount` and `chance`, our data map entries will look something like this:
+
+```java
+public record ExampleData(float amount, float chance) {}
+```
+
+Like many other things, data maps are serialized and deserialized using [codecs]. This means that we need to provide a codec for our data map entry that we will use in a bit:
+
+```java
+public record ExampleData(float amount, float chance) {
+    public static final Codec<ExampleData> CODEC = RecordCodecBuilder.create(instance -> instance.group(
+            Codec.FLOAT.fieldOf("amount").forGetter(ExampleData::amount),
+            Codec.floatRange(0, 1).fieldOf("chance").forGetter(ExampleData::chance)
+    ).apply(instance, ExampleData::new));
+}
+```
+
+Next, we create the data map itself:
+
+```java
+// In this example, we register the data map for the minecraft:item registry, hence we use Item as the generic.
+// Adjust the types accordingly if you want to create a data map for a different registry.
+public static final DataMapType<Item, ExampleData> EXAMPLE_DATA = DataMapType.builder(
+        // The ID of the data map. Data map files for this data map will be located at
+        // <yourmodid>:examplemod/data_maps/item/example_data.json.
+        ResourceLocation.fromNamespaceAndPath("examplemod", "example_data"),
+        // The registry to register the data map for.
+        Registries.ITEM,
+        // The codec of the data map entries.
+        ExampleData.CODEC
+).build();
+```
+
+Finally, register the data map during the [`RegisterDataMapTypesEvent`][events] on the [mod event bus][modbus]:
+
+```java
+@SubscribeEvent
+private static void registerDataMapTypes(RegisterDataMapTypesEvent event) {
+    event.register(EXAMPLE_DATA);
+}
+```
+
+### Syncing
+
+Synced data maps will have their values synced to clients. A data map can be marked as synced by calling `#synced` on the builder, like so:
+
+```java
+public static final DataMapType<Item, ExampleData> EXAMPLE_DATA = DataMapType.builder(...)
+        .synced(
+                // The codec used for syncing. May be identical to the normal codec, but may also be
+                // a codec with less fields, omitting parts of the object that are not required on the client.
+                ExampleData.CODEC,
+                // Whether the data map is mandatory or not. Marking a data map as mandatory will disconnect clients
+                // that are missing the data map on their side; this includes vanilla clients.
+                false
+        ).build();
+```
+
+### Usage
+
+As data maps can be used on any registry, they must be queried through `Holder`s, not through actual registry objects. Moreover, it will only work for reference holders, not `Direct` holders. However, most places will return a reference holder, for example `Registry#wrapAsHolder`, `Registry#getHolder` or the different `builtInRegistryHolder` methods, so in most situations this shouldn't be a problem.
+
+You can then query the data map value via `Holder#getData(DataMapType)`. If an object does not have a data map value attached, the method will return `null`. Reusing our `ExampleData` from before, let's use them to heal the player whenever he picks them up:
+
+```java
+@SubscribeEvent
+private static void itemPickup(ItemPickupEvent event) {
+    ItemStack stack = event.getItemStack();
+    // Get a Holder<Item> via ItemStack#getItemHolder.
+    Holder<Item> holder = stack.getItemHolder();
+    // Get the data from the holder.
+    //highlight-next-line
+    ExampleData data = holder.getData(EXAMPLE_DATA);
+    if (data != null) {
+        // The values are present, so let's do something with them!
+        Player player = event.getPlayer();
+        if (player.getLevel().getRandom().nextFloat() > data.chance()) {
+            player.heal(data.amount());
+        }
+    }
+}
+```
+
+This process of course also works for all data maps provided by NeoForge.
+
+## Advanced Data Maps
+
+Advanced data maps are data maps that use `AdvancedDataMapType` instead of the standard `DataMapType` (of which `AdvancedDataMapType` is a subclass). They have some extra functionality, namely the ability to specify custom mergers and custom removers. Implementing this is highly recommended for data maps whose values are collections or collection-likes, such as `List`s or `Map`s.
+
+While `DataMapType` has two generics `R` (registry type) and `T` (data map value type), `AdvancedDataMapType` has one more: `VR extends DataMapValueRemover<R, T>`. This generic allows for datagenning removers with proper type safety.
+
+`AdvancedDataMapType`s are created using `AdvancedDataMapType#builder()` instead of `DataMapType#builder()`, returning an `AdvancedDataMapType.Builder`. This builder has two extra methods `#remover` and `#merger` for specifying removers and mergers (see below), respectively. All other functionality, including syncing, remains the same.
+
+### Mergers
+
+A merger can be used to handle conflicts between multiple data packs that attempt to add a value for the same object. The default merger (`DataMapValueMerger#defaultMerger`) will overwrite existing values (from e.g. data packs with lower priority) with new values, so a custom merger is necessary if this isn't the desired behavior.
+
+The merger will be given the two conflicting values, as well as the objects the values are being attached to (as an `Either<TagKey<R>, ResourceKey<R>>`, since values can be attached to all objects in a tag or a single object) and the object's owning registry, and should return the value that should actually be attached. Generally, mergers should simply merge and not perform overwrites if possible (i.e. only if merging the normal way doesn't work). If a data pack wants to bypass the merger, it should specify the `replace` field on the object (see [Adding Values][add]).
+
+Let's imagine a scenario where we have a data map that adds integers to items. We could then simply resolve conflicts by adding both values, like so:
+
+```java
+public class IntMerger implements DataMapValueMerger<Item, Integer> {
+    @Override
+    public Integer merge(Registry<Item> registry,
+            Either<TagKey<Item>, ResourceKey<Item>> first, Integer firstValue,
+            Either<TagKey<Item>, ResourceKey<Item>> second, Integer secondValue) {
+        return firstValue + secondValue;
+    }
+}
+```
+
+This way, if one pack specifies the value 12 for `minecraft:carrot` and another pack specifies the value 15 for `minecraft:carrot`, then the final value for `minecraft:carrot` will be 27. If either of these objects specify `"replace": true`, then that object's value will be used. If both specify `"replace": true`, then the higher datapack's value is used.
+
+Finally, don't forget to actually specify the merger in the builder, like so:
+
+```java
+// The types of the data map must match the type of the merger.
+AdvancedDataMapType<Item, Integer> ADVANCED_MAP = AdvancedDataMapType.builder(...)
+        .merger(new IntMerger())
+        .build();
+```
+
+:::tip
+NeoForge provides default mergers for lists, sets and maps in `DataMapValueMerger`.
+:::
+
+### Removers
+
+Similar to mergers for more complex data, removers can be used for proper handling of `remove` clauses for an element. The default remover (`DataMapValueRemover.Default.INSTANCE`) will simply remove any and all information related to the specified object, so we want to use a custom remover to remove only parts of the object's data.
+
+The codec passed to the builder (read on) will be used to decode remover instances. The remover will then be passed the value currently attached to the object and its source, and should return an `Optional` of the value to replace the old value. Alternatively, an empty `Optional` will lead to the value being actually removed.
+
+Consider the following example of a remover that will remove a value with a specific key from a `Map<String, String>`-based data map:
+
+```java
+public record MapRemover(String key) implements DataMapValueRemover<Item, Map<String, String>> {
+    public static final Codec<MapRemover> CODEC = Codec.STRING.xmap(MapRemover::new, MapRemover::key);
+    
+    @Override
+    public Optional<Map<String, String>> remove(Map<String, String> value, Registry<Item> registry, Either<TagKey<Item>, ResourceKey<Item>> source, Item object) {
+        final Map<String, String> newMap = new HashMap<>(value);
+        newMap.remove(key);
+        return Optional.of(newMap);
+    }
+}
+```
+
+With this remover in mind, consider the following data file:
+
+```json5
+{
+    "values": {
+        "minecraft:carrot": {
+            "somekey1": "value1",
+            "somekey2": "value2"
+        }
+    }
+}
+```
+
+Now, consider this second data file that is placed at a higher priority than the first one:
+
+```json5
+{
+    "remove": {
+        // As the remover is decoded as a string, we can use a string as the value here.
+        // If it were decoded as an object, we would have needed to use an object.
+        "minecraft:carrot": "somekey1"
+    }
+}
+```
+
+That way, after both files are applied, the final result will be (an in-memory representation of) this:
+
+```json5
+{
+    "values": {
+        "minecraft:carrot": {
+            "somekey1": "value1"
+        }
+    }
+}
+```
+
+As with mergers, don't forget to add them to the builder. Note that we simply use the codec here:
+
+```java
+// We assume AdvancedData contains a Map<String, String> property of some sort.
+AdvancedDataMapType<Item, AdvancedData> ADVANCED_MAP = AdvancedDataMapType.builder(...)
+        .remover(MapRemover.CODEC)
+        .build();
+```
+
+## Data Generation
+
+Data maps can be [datagenned][datagen] by extending `DataMapProvider` and overriding `#gather` to create your entries. Reusing the `ExampleData` from before (with float values `amount` and `chance`), our datagen file could look something like this:
+
+```java
+public class MyDataMapProvider extends DataMapProvider {
+    public MyDataMapProvider(PackOutput packOutput, CompletableFuture<HolderLookup.Provider> lookupProvider) {
+        super(packOutput, lookupProvider);
+    }
+    
+    @Override
+    protected void gather() {
+        // We create a builder for the EXAMPLE_DATA data map and add our entries using #add.
+        this.builder(EXAMPLE_DATA)
+                // We turn on replacing. Don't ever ship a mod like this! This is purely for educational purposes.
+                .replace(true)
+                // We add the value "amount": 10, "chance": 1 for all slabs. The boolean parameter controls
+                // the "replace" field, which should always be false in a mod.
+                .add(ItemTags.SLABS, new ExampleData(10, 1), false)
+                // We add the value "amount": 5, "chance": 0.2 for apples.
+                .add(Items.APPLE.builtInRegistryHolder(), new ExampleData(5, 0.2f), false) // Can also use Registry#wrapAsHolder to get the holder of a registry object
+                // We remove wooden slabs again.
+                .remove(ItemTags.WOODEN_SLABS)
+                // We add a mod loaded condition for Botania, because why not.
+                .conditions(new ModLoadedCondition("botania"));
+    }
+}
+```
+
+This would then result in the following JSON file:
+
+```json5
+{
+    "replace": true,
+    "values": {
+        "#minecraft:slabs": {
+            "amount": 10,
+            "chance": 1.0
+        },
+        "minecraft:apple": {
+            "amount": 5,
+            "chance": 0.2
+        }
+    },
+    "remove": [
+        "#minecraft:wooden_slabs"
+    ],
+    "neoforge:conditions": [
+        {
+            "type": "neoforge:mod_loaded",
+            "modid": "botania"
+        }
+    ]
+}
+```
+
+Like all data providers, don't forget to add the provider to the event:
+
+```java
+@SubscribeEvent
+public static void gatherData(GatherDataEvent event) {
+    DataGenerator generator = event.getGenerator();
+    PackOutput output = generator.getPackOutput();
+    CompletableFuture<HolderLookup.Provider> lookupProvider = event.getLookupProvider();
+
+    // other providers here
+    generator.addProvider(
+            event.includeServer(),
+            new MyDataMapProvider(output, lookupProvider)
+    );
+}
+```
+
+[builtin]: builtin.md
+[codecs]: ../../../datastorage/codecs.md
+[conditions]: ../conditions.md
+[datagen]: ../../index.md#data-generation
+[events]: ../../../concepts/events.md
+[add]: #adding-values
+[mergers]: #mergers
+[modbus]: ../../../concepts/events.md#event-buses
+[removers]: #removers
+[tags]: ../tags.md
diff --git a/versioned_docs/version-1.21.3/resources/server/enchantments/builtin.md b/versioned_docs/version-1.21.3/resources/server/enchantments/builtin.md
new file mode 100644
index 00000000..625b525d
--- /dev/null
+++ b/versioned_docs/version-1.21.3/resources/server/enchantments/builtin.md
@@ -0,0 +1,341 @@
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# Built-In Enchantment Effect Components
+
+Vanilla Minecraft provides numerous different types of enchantment effect components for use in [enchantment] definitions. This article will explain each, including their usage and in-code definition.
+
+## Value Effect Components
+
+_See also [Value Effect Components] on the Minecraft Wiki_
+
+Value effect components are used for enchantments that alter a numerical value somewhere in the game, and are implemented by the class `EnchantmentValueEffect`. If a value is altered by more than one value effect component (for example, by multiple enchantments), all of their effects will apply.
+
+Value effect components can be set to use any of these operations on their given values:
+- `minecraft:set`: Overwrites the given level-based value.
+- `minecraft:add`: Adds the specified level-based value to the old one.
+- `minecraft:multiply`: Multiplies the specified level-based factor by the old one.
+- `minecraft:remove_binomial`: Polls a given (level-based) chance using a binomial distibution. If it works, subtracts 1 from the value. Note that many values are effectively flags, being fully on at 1 and fully off at 0.
+- `minecraft:all_of`: Accepts a list of other value effects and applies them in the stated sequence.
+
+The Sharpness enchantment uses `minecraft:damage`, a value effect component, as follows to achieve its effect:
+
+<Tabs>
+<TabItem value="sharpness.json" label="JSON">
+
+```json5
+"effects": {
+    // The type of this effect component is "minecraft:damage".
+    // This means that the effect will modify weapon damage.
+    // See below for a list of more effect component types.
+    "minecraft:damage": [
+        {
+            // A value effect that should be applied.
+            // In this case, since there's only one, this value effect is just named "effect".
+            "effect": {
+                // The type of value effect to use. In this case, it is "minecraft:add", so the value (given below) will be added 
+                // to the weapon damage value.
+                "type": "minecraft:add",
+
+                // The value block. In this case, the value is a LevelBasedValue that starts at 1 and increases by 0.5 every enchantment level.
+                "value": {
+                    "type": "minecraft:linear",
+                    "base": 1.0,
+                    "per_level_above_first": 0.5
+                }
+            }
+        }
+    ]
+}
+```
+
+</TabItem>
+<TabItem value="sharpness.datagen" label="Datagen">
+
+```java
+// Passed into 'effects' in an Enchantment during data generation
+// See the Data Generation section of the Enchantments entry to learn more
+DataComponentMap.builder().set(
+    // Selects the "minecraft:damage" component.
+    EnchantmentEffectComponents.DAMAGE,
+
+    // Constructs a list of one conditional AddValue without any requirements.
+    List.of(new ConditionalEffect<>(
+        new AddValue(LevelBasedValue.perLevel(1.0F, 0.5F)),
+        Optional.empty()))
+).build()
+```
+
+</TabItem>
+</Tabs>
+
+The object within the `value` block is a [LevelBasedValue], which can be used to have a value effect component that changes the intensity of its effect by level.
+
+The `EnchantmentValueEffect#process` method can be used to adjust values based on the provided numerical operations, like so:
+
+```java
+// `valueEffect` is an EnchantmentValueEffect instance.
+// `enchantLevel` is an integer representing the level of the enchantment
+float baseValue = 1.0;
+float modifiedValue = valueEffect.process(enchantLevel, server.random, baseValue);
+```
+
+### Vanilla Enchantment Value Effect Component Types
+
+#### Defined as `DataComponentType<EnchantmentValueEffect>`
+
+- `minecraft:crossbow_charge_time`: Modifies the charge-up time of this crossbow in seconds. Used by Quick Charge.
+- `minecraft:trident_spin_attack_strength`: Modifies the 'strength' of the spin attack of a trident (see `TridentItem#releaseUsing`). Used by Riptide.
+
+#### Defined as `DataComponentType<List<ConditionalEffect<EnchantmentValueEffect>>>`
+
+Armor related:
+- `minecraft:armor_effectiveness`: Determines effectiveness of armor against this weapon on a scale of 0 (no protection) to 1 (normal protection). Used by Breach.
+- `minecraft:damage_protection`: Each "point" of damage reduction reduces damage taken while wielding this item by 4%, to a maximum reduction of 80%. Used by Blast Protection, Feather Falling, Fire Protection, Protection, and Projectile Protection.
+
+Attack related:
+- `minecraft:damage`: Modifies attack damage with this weapon. Used by Sharpness, Impaling, Bane of Arthropods, Power, and Smite. 
+- `minecraft:smash_damage_per_fallen_block`: Adds damage per block fallen to a mace. Used by Density.
+- `minecraft:knockback`: Modifies the amount of knockback caused while wielding this weapon, measured in game units. Used by Knockback and Punch.
+- `minecraft:mob_experience`: Modifies the amount of experience for killing a mob. Unused.
+
+Durability related:
+- `minecraft:item_damage`: Modifies the durability damage taken by the item. Values below 1 act as a chance that the item takes damage. Used by Unbreaking.
+- `minecraft:repair_with_xp`: Causes the item to repair itself using XP gain, and determines how effective this is. Used by Mending.
+
+Projectile related:
+- `minecraft:ammo_use`: Modifies the amount of ammo used when firing a bow or crossbow. The value is clamped to an integer, so values below 1 will result in 0 ammo use. Used by Infinity.
+- `minecraft:projectile_piercing`: Modifies the number of entities pierced by a projectile from this weapon. Used by Piercing.
+- `minecraft:projectile_count`: Modifies the number of projectiles spawned when shooting this bow. Used by Multishot.
+- `minecraft:projectile_spread`: Modifies the maximum spread of projectiles in degrees from the direction they were fired. Used by Multishot.
+- `minecraft:trident_return_acceleration`: Causes the trident to return to its owner, and modifies the acceleration applied to this trident while doing so. Used by Loyalty.
+
+Other:
+- `minecraft:block_experience`: Modifies the amount of XP from breaking a block. Used by Silk Touch.
+- `minecraft:fishing_time_reduction`: Reduces the time it takes for the bobber to sink while fishing with this rod by the given number of seconds. Used by Lure.
+- `minecraft:fishing_luck_bonus`: Modifies the amount of [luck] used in the fishing loot table. Used by Luck of the Sea.
+
+#### Defined as `DataComponentType<List<TargetedConditionalEffect<EnchantmentValueEffect>>>`
+
+- `minecraft:equipment_drops`: Modifies the chance of equipment dropping from an entity killed by this weapon. Used by Looting.
+
+## Location Based Effect Components
+
+_See also: [Location Based Effect Components] on the Minecraft Wiki_
+
+Location based effect components are components that implement `EnchantmentLocationBasedEffect`. These components define actions to take that need to know where in the level the wielder of the enchantment is. They operate using two major methods: `EnchantmentEntityEffect#onChangedBlock`, which is called when the enchanted item is equipped and when the wielder changes their `BlockPos`, and `onDeactivate`, which is called when the enchanted item is removed.
+
+Here is an example which uses the `minecraft:attributes` location based effect component type to change the wielder's entity scale:
+
+<Tabs>
+<TabItem value="attribute.json" label="JSON">
+
+```json5
+// The type is "minecraft:attributes" (described below).
+// In a nutshell, this applies an attribute modifier.
+"minecraft:attributes": [
+    {
+        // This "amount" block is a LevelBasedValue.
+        "amount": {
+            "type": "minecraft:linear",
+            "base": 1,
+            "per_level_above_first": 1
+        },
+
+        // Which attribute to modify. In this case, modifies "minecraft:scale"
+        "attribute": "minecraft:generic.scale",
+        // The unique identifier for this attribute modifier. Should not overlap with others, but doesn't need to be registered.
+        "id": "examplemod:enchantment.size_change",
+        // What operation to use on the attribute. Can be "add_value", "add_multiplied_base", or "add_multiplied_total".
+        "operation": "add_value"
+    }
+],
+```
+
+</TabItem>
+<TabItem value="attribute.datagen" label="Datagen">
+
+```java
+// Passed into the effects of an Enchantment during data generation
+DataComponentMap.builder().set(
+    // Specifies the "minecraft:attributes" component type.
+    EnchantmentEffectComponents.ATTRIBUTES,
+
+    // This component takes a list of these EnchantmentAttributeEffect objects.
+    List.of(new EnchantmentAttributeEffect(
+        ResourceLocation.fromNamespaceAndPath("examplemod", "enchantment.size_change"),
+        Attributes.SCALE,
+        LevelBasedValue.perLevel(1F, 1F),
+        AttributeModifier.Operation.ADD_VALUE
+    ))
+).build()
+```
+
+
+</TabItem>
+</Tabs>
+
+Vanilla adds the following location based events:
+
+- `minecraft:all_of`: Runs a list of entity effects in sequence.
+- `minecraft:apply_mob_effect`: Applies a [mob effect] to the affected mob.
+- `minecraft:attribute`: Applies an [attribute modifier] to the wielder of the enchantment.
+- `minecraft:change_item_damage`: Damages this item's durability.
+- `minecraft:damage_entity`: Does damage to the affected entity. This stacks with attack damage if in an attacking context.
+- `minecraft:explode`: Summons an explosion. 
+- `minecraft:ignite`: Sets the entity on fire.
+- `minecraft:play_sound`: Plays a specified sound.
+- `minecraft:replace_block`: Replaces a block at a given offset.
+- `minecraft:replace_disk`: Replaces a disk of blocks.
+- `minecraft:run_function`: Runs a specified [datapack function].
+- `minecraft:set_block_properies`: Modifies the block state properties of the specified block.
+- `minecraft:spawn_particles`: Spawns a particle.
+- `minecraft:summon_entity`: Summons an entity.
+
+### Vanilla Location Based Effect Component Types
+
+#### Defined as `DataComponentType<List<ConditionalEffect<EnchantmentLocationBasedEffect>>>`
+
+- `minecraft:location_changed`: Runs a location based effect when the wielder's Block Position changes and when this item is equipped. Used by Frost Walker and Soul Speed.
+
+#### Defined as `DataComponentType<List<EnchantmentAttributeEffect>>`
+
+- `minecraft:attributes`: Applies an attribute modifier to the wielder, and removes it when the enchanted item is no longer equipped.
+
+## Entity Effect Components
+
+_See also [Entity Effect Components] on the Minecraft Wiki._
+
+Entity effect components are components that implement `EnchantmentEntityEffect`, an subtype of `EnchantmentLocationBasedEffect`. These override `EnchantmentLocationBasedEffect#onChangedBlock` to run `EnchantmentEntityEffect#apply` instead; this `apply` method is also directly invoked somewhere else in the codebase depending on the specific type of the component. This allows effects to occur without waiting for the wielder's block position to change.
+
+All types of location based effect component are also valid types of entity effect component, except for `minecraft:attribute`, which is registered only as a location based effect component.
+
+Here is an example of the JSON definition of one such component from the Fire Aspect enchantment:
+
+<Tabs>
+<TabItem value="fire.json" label="JSON">
+
+```json5
+// This component's type is "minecraft:post_attack" (see below).
+"minecraft:post_attack": [
+    {
+        // Decides whether the "victim" of the attack, the "attacker", or the "damaging entity" (the projectile if there is one, attacker if not) recieves the effect.
+        "affected": "victim",
+        
+        // Decides which enchantment entity effect to apply.
+        "effect": {
+            // The type of this effect is "minecraft:ignite".
+            "type": "minecraft:ignite",
+            // "minecraft:ignite" requires a LevelBasedValue as a duration for how long the entity will be ignited.
+            "duration": {
+                "type": "minecraft:linear",
+                "base": 4.0,
+                "per_level_above_first": 4.0
+            }
+        },
+
+        // Decides who (the "victim", "attacker", or "damaging entity") must have the enchantment for it to take effect.
+        "enchanted": "attacker",
+
+        // An optional predicate which controls whether the effect applies.
+        "requirements": {
+            "condition": "minecraft:damage_source_properties",
+            "predicate": {
+                "is_direct": true
+            }
+        }
+    }
+]
+```
+
+</TabItem>
+<TabItem value="fire.datagen" label="Datagen">
+
+```java
+// Passed into the effects of an Enchantment during data generation
+DataComponentMap.builder().set(
+    // Specifies the "minecraft:post_attack" component type.
+    EnchantmentEffectComponents.POST_ATTACK,
+
+    // Defines the data for this component. In this case, a list of one TargetedConditionalEffect.
+    List.of(
+        new TargetedConditionalEffect<>(
+
+            // Determines the "enchanted" field.
+            EnchantmentTarget.ATTACKER,
+
+            // Determines the "affected" field.
+            EnchantmentTarget.VICTIM,
+
+            // The enchantment entity effect.
+            new Ignite(LevelBasedValue.perLevel(4.0F, 4.0F)),
+
+            // The "requirements" clause. 
+            // In this case, the only optional part activated is the isDirect boolean flag.
+            Optional.of(
+                new DamageSourceCondition(
+                    Optional.of(
+                        new DamageSourcePredicate(
+                            List.of(),
+                            Optional.empty(),
+                            Optional.empty(),
+                            Optional.of(true)
+                        )
+                    )
+                )
+            )
+        )
+    )
+).build()
+```
+
+</TabItem>
+</Tabs>
+
+Here, the entity effect component is `minecraft:post_attack`. Its effect is `minecraft:ignite`, which is implemented by the `Ignite` record. This record's implementation of `EnchantmentEntityEffect#apply` sets the target entity on fire.
+
+### Vanilla Enchantment Entity Effect Component Types
+
+#### Defined as `DataComponentType<List<ConditionalEffect<EnchantmentEntityEffect>>>`
+
+- `minecraft:hit_block`: Runs an entity effect when an entity (for example, a projectile) hits a block. Used by Channeling.
+- `minecraft:tick`: Runs an entity effect each tick. Used by Soul Speed.
+- `minecraft:projectile_spawned`: Runs an entity effect after a projectile entity has been spawned from a bow or crossbow. Used by Flame.
+
+#### Defined as `DataComponentType<List<TargetedConditionalEffect<EnchantmentEntityEffect>>>`
+
+- `minecraft:post_attack`: Runs an entity effect after an attack damages an entity. Used by Bane of Arthropods, Channeling, Fire Aspect, Thorns, and Wind Burst.
+
+For more detail on each of these, please look at the [relevant minecraft wiki page].
+
+## Other Vanilla Enchantment Component Types
+
+#### Defined as `DataComponentType<List<ConditionalEffect<DamageImmunity>>>`
+
+- `minecraft:damage_immunity`: Applies immunity to a specified damage type. Used by Frost Walker.
+
+#### Defined as `DataComponentType<Unit>`
+
+- `minecraft:prevent_equipment_drop`: Prevents this item from being dropped by a player when dying. Used by Curse of Vanishing.
+- `minecraft:prevent_armor_change`: Prevents this item from being unequipped from an armor slot. Used by Curse of Binding.
+
+#### Defined as `DataComponentType<List<CrossbowItem.ChargingSounds>>`
+
+- `minecraft:crossbow_charge_sounds`: Determines the sound events that occur when charging a crossbow. Each entry represents one level of the enchantment.
+
+#### Defined as `DataComponentType<List<Holder<SoundEvent>>>`
+
+- `minecraft:trident_sound`: Determines the sound events that occur when using a trident. Each entry represents one level of the enchantment.
+
+[enchantment]: index.md
+[Value Effect Components]: https://minecraft.wiki/w/Enchantment_definition#Components_with_value_effects
+[Entity Effect Components]: https://minecraft.wiki/w/Enchantment_definition#Components_with_entity_effects
+[Location Based Effect Components]: https://minecraft.wiki/w/Enchantment_definition#location_changed
+[text component]: ../../client/i18n.md
+[LevelBasedValue]: ../loottables/index.md#number-provider
+[Attribute Effect Component]: https://minecraft.wiki/w/Enchantment_definition#Attribute_effects
+[datapack function]: https://minecraft.wiki/w/Function_(Java_Edition)
+[luck]: https://minecraft.wiki/w/Luck
+[mob effect]: ../../../items/mobeffects.md
+[attribute modifier]: https://minecraft.wiki/w/Attribute#Modifiers
+[relevant minecraft wiki page]: https://minecraft.wiki/w/Enchantment_definition#Components_with_entity_effects
\ No newline at end of file
diff --git a/versioned_docs/version-1.21.3/resources/server/enchantments/index.md b/versioned_docs/version-1.21.3/resources/server/enchantments/index.md
new file mode 100644
index 00000000..c0084d49
--- /dev/null
+++ b/versioned_docs/version-1.21.3/resources/server/enchantments/index.md
@@ -0,0 +1,329 @@
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# Enchantments
+
+Enchantments are special effects that can be applied to tools and other items. As of 1.21, enchantments are stored on items as [Data Components], are defined in JSON, and are comprised of so-called enchantment effect components. During the game, the enchantments on a particular item are contained within the `DataComponents.ENCHANTMENTS` component, in an `ItemEnchantments` instance.
+
+A new enchantment can be added by creating a JSON file in your namespace's `enchantment` datapack subfolder. For example, to create an enchantment called `examplemod:example_enchant`, one would create a file `data/examplemod/enchantment/example_enchantment.json`. 
+
+## Enchantment JSON Format
+
+```json5
+{
+    // The text component that will be used as the in-game name of the enchantment.
+    // Can be a translation key or a literal string. 
+    // Remember to translate this in your lang file if you use a translation key!
+    "description": {
+        "translate": "enchantment.examplemod.enchant_name"
+    },
+    
+    // Which items this enchantment can be applied to.
+    // Can be either an item id, such as "minecraft:trident",
+    // or a list of item ids, such as ["examplemod:red_sword", "examplemod:blue_sword"]
+    // or an item tag, such as "#examplemod:enchantable/enchant_name".
+    // Note that this doesn't cause the enchantment to appear for these items in the enchanting table.
+    "supported_items": "#examplemod:enchantable/enchant_name",
+
+    // (Optional) Which items this enchantment appears for in the enchanting table.
+    // Can be an item, list of items, or item tag.
+    // If left unspecified, this is the same as `supported_items`.
+    "primary_items": [
+        "examplemod:item_a",
+        "examplemod:item_b"
+    ],
+
+    // (Optional) Which enchantments are incompatible with this one.
+    // Can be an enchantment id, such as "minecraft:sharpness",
+    // or a list of enchantment ids, such as ["minecraft:sharpness", "minecraft:fire_aspect"],
+    // or enchantment tag, such as "#examplemod:exclusive_to_enchant_name".
+    // Incompatible enchantments will not be added to the same item by vanilla mechanics.
+    "exclusive_set": "#examplemod:exclusive_to_enchant_name",
+    
+    // The likelihood that this enchantment will appear in the Enchanting Table. 
+    // Bounded by [1, 1024].
+    "weight": 6,
+    
+    // The maximum level this enchantment is allowed to reach.
+    // Bounded by [1, 255].
+    "max_level": 3,
+    
+    // The maximum cost of this enchantment, measured in "enchanting power". 
+    // This corresponds to, but is not equivalent to, the threshold in levels the player needs to meet to bestow this enchantment.
+    // See below for details.
+    // The actual cost will be between this and the min_cost.
+    "max_cost": {
+        "base": 45,
+        "per_level_above_first": 9
+    },
+    
+    // Specifies the minimum cost of this enchantment; otherwise as above.
+    "min_cost": {
+        "base": 2,
+        "per_level_above_first": 8
+    },
+
+    // The cost that this enchantment adds to repairing an item in an anvil in levels. The cost is multiplied by enchantment level.
+    // If an item has a DataComponentTypes.STORED_ENCHANTMENTS component, the cost is halved. In vanilla, this only applies to enchanted books.
+    // Bounded by [1, inf).
+    "anvil_cost": 2,
+    
+    // (Optional) A list of slot groups this enchantment provides effects in. 
+    // A slot group is defined as one of the possible values of the EquipmentSlotGroup enum.
+    // In vanilla, these are: `any`, `hand`, `mainhand`, `offhand`, `armor`, `feet`, `legs`, `chest`, `head`, and  `body`.
+    "slots": [
+        "mainhand"
+    ],
+
+    // The effects that this enchantment provides as a map of enchantment effect components (read on).
+    "effects": {
+        "examplemod:custom_effect": [
+            {
+                "effect": {
+                    "type": "minecraft:add",
+                    "value": {
+                        "type": "minecraft:linear",
+                        "base": 1,
+                        "per_level_above_first": 1
+                    }
+                }
+            }
+        ]
+    }
+}
+```
+
+### Enchantment Costs and Levels
+
+The `max_cost` and `min_cost` fields specify boundaries for how much enchanting power is needed to create this enchantment. There is a somewhat convoluted procedure to actually make use of these values, however.
+
+First, the table takes into account the return value of `IBlockExtension#getEnchantPowerBonus()` for the surrounding blocks. From this, it calls `EnchantmentHelper#getEnchantmentCost` to derive a 'base level' for each slot. This level is shown in-game as the green numbers besides the enchantments in the menu. For each enchantment, the base level is modified twice by a random value derived from the item's enchantability (its return value from `IItemExtension#getEnchantmentValue()`), like so:
+
+`(Modified Level) = (Base Level) + random.nextInt(e / 4 + 1) + random.nextInt(e / 4 + 1)`, where `e` is the enchantability score.
+
+This modified level is adjusted up or down by a random 15%, and then is finally used to choose an enchantment. This level must fall within your enchantment's cost bounds in order for it to be chosen.
+
+In practical terms, this means that the cost values in your enchantment definition might be above 30, sometimes far above. For example, with an enchantability 10 item, the table could produce enchantments up to 1.15 * (30 + 2 * (10 / 4) + 1) = 40 cost. 
+
+## Enchantment Effect Components
+
+Enchantment effect components are specially-registered [Data Components] that determine how an enchantment functions. The type of the component defines its effect, while the data it contains is used to inform or modify that effect. For instance, the `minecraft:damage` component modifies the damage that a weapon deals by an amount determined by its data.
+
+Vanilla defines various [built-in enchantment effect components], which are used to implement all vanilla enchantments.
+
+### Custom Enchantment Effect Components
+
+The logic of applying a custom enchantment effect component must be entirely implemented by its creator. First, you should define a class or record to hold the information you need to implement a given effect. For example, let's make an example record class `Increment`:
+
+```java
+// Define an example data-bearing record.
+public record Increment(int value) {
+    public static final Codec<Increment> CODEC = RecordCodecBuilder.create(instance ->
+            instance.group(
+                    Codec.INT.fieldOf("value").forGetter(Increment::value)
+            ).apply(instance, Increment::new)
+    );
+
+    public int add(int x) {
+        return value() + x;
+    }
+}
+```
+
+Enchantment effect component types must be [registered] to `BuiltInRegistries.ENCHANTMENT_EFFECT_COMPONENT_TYPE`, which takes a `DataComponentType<?>`. For example, you could register an enchantment effect component that can store an `Increment` object as follows:
+
+```java
+// In some registration class
+public static final DeferredRegister.DataComponents ENCHANTMENT_COMPONENT_TYPES =
+    DeferredRegister.createDataComponents(BuiltInRegistries.ENCHANTMENT_EFFECT_COMPONENT_TYPE, "examplemod");
+
+public static final Supplier<DataComponentType<Increment>> INCREMENT =
+    ENCHANTMENT_COMPONENT_TYPES.registerComponentType(
+        "increment",
+        builder -> builder.persistent(Increment.CODEC)
+    );
+```
+
+Now, we can implement some game logic that makes use of this component to alter an integer value:
+
+```java
+// Somewhere in game logic where an `itemStack` is available.
+// `INCREMENT` is the enchantment component type holder defined above.
+// `value` is an integer.
+AtomicInteger atomicValue = new AtomicInteger(value);
+
+EnchantmentHelper.runIterationOnItem(stack, (enchantmentHolder, enchantLevel) -> {
+    // Acquire the Increment instance from the enchantment holder (or null if this is a different enchantment)
+    Increment increment = enchantmentHolder.value().effects().get(INCREMENT.get());
+
+    // If this enchant has an Increment component, use it.
+    if(increment != null){
+        atomicValue.set(increment.add(atomicValue.get()));
+    }
+});
+
+int modifiedValue = atomicValue.get();
+// Use the now-modified value elsewhere in your game logic.
+```
+
+First, we invoke one of the overloads of `EnchantmentHelper#runIterationOnItem`. This function accepts an `EnchantmentHelper.EnchantmentVisitor`, which is a functional interface that accepts an enchantment and its level, and is invoked on all of the enchantments that the given itemstack has (essentially a `BiConsumer<Holder<Enchantment>, Integer>`).
+
+To actually perform the adjustment, use the provided `Increment#add` method. Since this is inside of a lambda expression, we need to use a type that can be updated atomically, such as `AtomicInteger`, to modify this value. This also permits multiple `INCREMENT` components to run on the same item and stack their effects, like what happens in vanilla.
+
+### `ConditionalEffect`
+Wrapping the type in `ConditionalEffect<?>` allows the enchantment effect component to optionally take effect based on a given [LootContext].
+
+`ConditionalEffect` provides `ConditionalEffect#matches(LootContext context)`, which returns whether the effect should be allowed to run based on its internal `Optional<LootItemConditon>`, and handled serialization and deserialization of its `LootItemCondition`.
+
+Vanilla adds an additional helper method to further streamline the process of checking these conditions: `Enchantment#applyEffects()`. This method takes a `List<ConditionalEffect<T>>`, evaluates the conditions, and runs a `Consumer<T>` on each `T` contained by a `ConditionalEffect` whose condition was met. Since many vanilla enchantment effect components are defined as a `List<ConditionalEffect<?>>`, these can be directly plugged into the helper method like so:
+
+```java
+// `enchant` is an Enchantment instance.
+// `lootContext` is a LootContext instance.
+enchant.applyEffects(
+    // Or whichever other List<ConditionalEffect<T>> you want
+    enchant.getEffects(EnchantmentEffectComponents.KNOCKBACK),
+    // The context to test the conditions against
+    lootContext,
+    (effectData) -> // Use the effectData (in this example, an EnchantmentValueEffect) however you want.
+);
+```
+
+Registering a custom `ConditionalEffect`-wrapped enchantment effect component type can be done as follows:
+
+```java
+public static final DeferredHolder<DataComponentType<?>, DataComponentType<ConditionalEffect<Increment>>> CONDITIONAL_INCREMENT =
+    ENCHANTMENT_COMPONENT_TYPES.register("conditional_increment",
+        () -> DataComponentType.ConditionalEffect<Increment>builder()
+            // The ContextKeySet needed depends on what the enchantment is supposed to do.
+            // This might be one of ENCHANTED_DAMAGE, ENCHANTED_ITEM, ENCHANTED_LOCATION, ENCHANTED_ENTITY, or HIT_BLOCK
+            // since all of these bring the enchantment level into context (along with whatever other information is indicated).
+            .persistent(ConditionalEffect.codec(Increment.CODEC, LootContextParamSets.ENCHANTED_DAMAGE))
+            .build());
+```
+
+The parameters to `ConditionalEffect.codec` are the codec for the generic `ConditionalEffect<T>`, followed by some `ContextKeySet` entry.
+
+## Enchantment Data Generation
+
+Enchantment JSON files can be created automatically using the [data generation] system by passing a `RegistrySetBuilder` into `DatapackBuiltInEntriesProvider`. The JSON will be placed in `<project root>/src/generated/data/<modid>/enchantment/<path>.json`.
+
+For more information on how `RegistrySetBuilder` and `DatapackBuiltinEntriesProvider` work, please see the article on [Data Generation for Datapack Registries]. 
+
+<Tabs>
+<TabItem value="datagen" label="Datagen">
+
+```java
+
+// This RegistrySetBuilder should be passed into a DatapackBuiltinEntriesProvider in your GatherDataEvent handler.
+RegistrySetBuilder BUILDER = new RegistrySetBuilder();
+BUILDER.add(
+    Registries.ENCHANTMENT,
+    bootstrap -> bootstrap.register(
+        // Define the ResourceKey for our enchantment.
+        ResourceKey.create(
+            Registries.ENCHANTMENT,
+            ResourceLocation.fromNamespaceAndPath("examplemod", "example_enchantment")
+        ),
+        new Enchantment(
+            // The text Component that specifies the enchantment's name.
+            Component.literal("Example Enchantment"),  
+            
+            // Specify the enchantment definition of for our enchantment.
+            new Enchantment.EnchantmentDefinition(
+                // A HolderSet of Items that the enchantment will be compatible with.
+                HolderSet.direct(...), 
+
+                // An Optional<HolderSet> of items that the enchantment considers "primary".
+                Optional.empty(), 
+
+                // The weight of the enchantment.
+                30, 
+
+                // The maximum level this enchantment can be.
+                3, 
+
+                // The minimum cost of the enchantment. The first parameter is base cost, the second is cost per level.
+                new Enchantment.Cost(3, 1), 
+
+                // The maximum cost of the enchantment. As above.
+                new Enchantment.Cost(4, 2), 
+
+                // The anvil cost of the enchantment.
+                2, 
+
+                // A list of EquipmentSlotGroups that this enchantment has effects in.
+                List.of(EquipmentSlotGroup.ANY) 
+            ),
+            // A HolderSet of incompatible other enchantments.
+            HolderSet.empty(), 
+
+            // A DataComponentMap of the enchantment effect components associated with this enchantment and their values.
+            DataComponentMap.builder() 
+                .set(MY_ENCHANTMENT_EFFECT_COMPONENT_TYPE, new ExampleData())
+                .build()
+        )
+    )
+);
+
+```
+
+</TabItem>
+
+<TabItem value="json" label="JSON" default>
+
+```json5
+// For more detail on each entry, please check the section above on the enchantment JSON format.
+{
+    // The anvil cost of the enchantment.
+    "anvil_cost": 2,
+
+    // The text Component that specifies the enchantment's name.
+    "description": "Example Enchantment",
+
+    // A map of the effect components associated with this enchantment and their values.
+    "effects": {
+        // <effect components>
+    },
+
+    // The maximum cost of the enchantment.
+    "max_cost": {
+        "base": 4,
+        "per_level_above_first": 2
+    },
+
+    // The maximum level this enchantment can be.
+    "max_level": 3,
+
+    // The minimum cost of the enchantment.
+    "min_cost": {
+        "base": 3,
+        "per_level_above_first": 1
+    },
+
+    // A list of EquipmentSlotGroup aliases that this enchantment has effects in.
+    "slots": [
+        "any"
+    ],
+
+    // The set of items that this enchantment can be applied to using an anvil.
+    "supported_items": /* <supported item list> */,
+
+    // The weight of this enchantment.
+    "weight": 30
+}
+```
+
+</TabItem>
+</Tabs>
+
+[Data Components]: ../../../items/datacomponents.md
+[Codec]: ../../../datastorage/codecs.md
+[Enchantment definition Minecraft wiki page]: https://minecraft.wiki/w/Enchantment_definition
+[registered]: ../../../concepts/registries.md
+[Predicate]: https://minecraft.wiki/w/Predicate
+[data generation]: ../../../resources/index.md#data-generation
+[Data Generation for Datapack Registries]: https://docs.neoforged.net/docs/concepts/registries/#data-generation-for-datapack-registries
+[relevant minecraft wiki page]: https://minecraft.wiki/w/Enchantment_definition#Entity_effects
+[built-in enchantment effect components]: builtin.md
+[LootContext]: ../loottables/index.md#loot-context
\ No newline at end of file
diff --git a/versioned_docs/version-1.21.3/resources/server/loottables/custom.md b/versioned_docs/version-1.21.3/resources/server/loottables/custom.md
new file mode 100644
index 00000000..ceba663b
--- /dev/null
+++ b/versioned_docs/version-1.21.3/resources/server/loottables/custom.md
@@ -0,0 +1,298 @@
+# Custom Loot Objects
+
+Due to the complexity of the loot table system, there are several [registries] at work, all of which can be used by a modder to add more behavior.
+
+All loot table related registries follow a similar pattern. To add a new registry entry, you generally extend some class or implement some interface that holds your functionality. Then, you define a [codec] for serialization, and register that codec to the corresponding registry, using `DeferredRegister` like normal. This goes along with the "one base object, many instances" approach most registries (for example also blocks/blockstates and items/item stacks) use.
+
+## Custom Loot Entry Types
+
+To create a custom loot entry type, extend `LootPoolEntryContainer` or one of its two direct subclasses, `LootPoolSingletonContainer` or `CompositeEntryBase`. For the sake of example, we want to create a loot entry type that returns the drops of a entity - this is purely for example purposes, in practice it would be more ideal to directly reference the other loot table. Let's start by creating our loot entry type class:
+
+```java
+// We extend LootPoolSingletonContainer since we have a "finite" set of drops.
+// Some of this code is adapted from NestedLootTable.
+public class EntityLootEntry extends LootPoolSingletonContainer {
+    // A Holder for the entity type we want to roll the other table for.
+    private final Holder<EntityType<?>> entity;
+
+    // It is common practice to have a private constructor and have a static factory method.
+    // This is because weight, quality, conditions, and functions are supplied by a lambda below.
+    private EntityLootEntry(Holder<EntityType<?>> entity, int weight, int quality, List<LootItemCondition> conditions, List<LootItemFunction> functions) {
+        // Pass lambda-provided parameters to super.
+        super(weight, quality, conditions, functions);
+        // Set our values.
+        this.entity = entity;
+    }
+
+    // Static builder method, accepting our custom parameters and combining them with a lambda that supplies the values common to all entry types.
+    public static LootPoolSingletonContainer.Builder<?> entityLoot(Holder<EntityType<?>> entity) {
+        // Use the static simpleBuilder() method defined in LootPoolSingletonContainer.
+        return simpleBuilder((weight, quality, conditions, functions) -> new EntityLootEntry(entity, weight, quality, conditions, functions));
+    }
+
+    // This is where the magic happens. To add an item stack, we generally call #accept on the consumer.
+    // However, in this case, we let #getRandomItems do that for us.
+    @Override
+    public void createItemStack(Consumer<ItemStack> consumer, LootContext context) {
+        // Get the entity's loot table. If it doesn't exist, an empty loot table will be returned, so null-checking is not necessary.
+        LootTable table = context.getLevel().reloadableRegistries().getLootTable(entity.value().getDefaultLootTable());
+        // Use the raw version here, because vanilla does it too. :P
+        // #getRandomItemsRaw calls consumer#accept for us on the results of the roll.
+        table.getRandomItemsRaw(context, consumer);
+    }
+}
+```
+
+Next up, we create a `MapCodec` for our loot entry:
+
+```java
+// This is placed as a constant in EntityLootEntry.
+public static final MapCodec<EntityLootEntry> CODEC = RecordCodecBuilder.mapCodec(inst ->
+        // Add our own fields.
+        inst.group(
+                        // A value referencing an entity type id.
+                        BuiltInRegistries.ENTITY_TYPE.holderByNameCodec().fieldOf("entity").forGetter(e -> e.entity)
+                )
+                // Add common fields: weight, display, conditions, and functions.
+                .and(singletonFields(inst))
+                .apply(inst, EntityLootEntry::new)
+);
+```
+
+We then use this codec in [registration][registries]:
+
+```java
+public static final DeferredRegister<LootPoolEntryType> LOOT_POOL_ENTRY_TYPES =
+        DeferredRegister.create(Registries.LOOT_POOL_ENTRY_TYPE, ExampleMod.MOD_ID);
+
+public static final Supplier<LootPoolEntryType> ENTITY_LOOT =
+        LOOT_POOL_ENTRY_TYPES.register("entity_loot", () -> new LootPoolEntryType(EntityLootEntry.CODEC));
+```
+
+Finally, in our loot entry class, we must override `getType()`:
+
+```java
+public class EntityLootEntry extends LootPoolSingletonContainer {
+    // other stuff here
+
+    @Override
+    public LootPoolEntryType getType() {
+        return ENTITY_LOOT.get();
+    }
+}
+```
+
+## Custom Number Providers
+
+To create a custom number provider, implement the `NumberProvider` interface. For the sake of example, let's assume we want to create a number provider that changes the sign of the provided number:
+
+```java
+// We accept another number provider as our base.
+public record InvertedSignProvider(NumberProvider base) implements NumberProvider {
+    public static final MapCodec<InvertedSignProvider> CODEC = RecordCodecBuilder.mapCodec(inst -> inst.group(
+            NumberProviders.CODEC.fieldOf("base").forGetter(InvertedSignProvider::base)
+    ).apply(inst, InvertedSignProvider::new));
+
+    // Return a float value. Use the context and the record parameters as needed.
+    @Override
+    public float getFloat(LootContext context) {
+        return -this.base.getFloat(context);
+    }
+
+    // Return an int value. Use the context and the record parameters as needed.
+    // Overriding this is optional, the default implementation will round the result of #getFloat.
+    @Override
+    public int getInt(LootContext context) {
+        return -this.base.getInt(context);
+    }
+
+    // Return a set of the loot context params used by this provider. See below for more information.
+    // Since we have a base value, we just defer to the base.
+    @Override
+    public Set<ContextKey<?>> getReferencedContextParams() {
+        return this.base.getReferencedContextParams();
+    }
+}
+```
+
+Like with custom loot entry types, we then use this codec in [registration][registries]:
+
+```java
+public static final DeferredRegister<LootNumberProviderType> LOOT_NUMBER_PROVIDER_TYPES =
+        DeferredRegister.create(Registries.LOOT_NUMBER_PROVIDER_TYPE, ExampleMod.MOD_ID);
+
+public static final Supplier<LootNumberProviderType> INVERTED_SIGN =
+        LOOT_NUMBER_PROVIDER_TYPES.register("inverted_sign", () -> new LootNumberProviderType(InvertedSignProvider.CODEC));
+```
+
+And similarly, in our number provider class, we must override `getType()`:
+
+```java
+public record InvertedSignProvider(NumberProvider base) implements NumberProvider {
+    // other stuff here
+
+    @Override
+    public LootNumberProviderType getType() {
+        return INVERTED_SIGN.get();
+    }
+}
+```
+
+## Custom Level-Based Values
+
+Custom `LevelBasedValue`s can be created by implementing the `LevelBasedValue` interface in a record. Again, for the sake of example, let's assume that we want to invert the output of another `LevelBasedValue`:
+
+```java
+public record InvertedSignLevelBasedValue(LevelBasedValue base) implements LevelBaseValue {
+    public static final MapCodec<InvertedLevelBasedValue> CODEC = RecordCodecBuilder.mapCodec(inst -> inst.group(
+            LevelBasedValue.CODEC.fieldOf("base").forGetter(InvertedLevelBasedValue::base)
+    ).apply(inst, InvertedLevelBasedValue::new));
+
+    // Perform our operation.
+    @Override
+    public float calculate(int level) {
+        return -this.base.calculate(level);
+    }
+
+    // Unlike NumberProviders, we don't return the registered type, instead we return the codec directly.
+    @Override
+    public MapCodec<InvertedLevelBasedValue> codec() {
+        return CODEC;
+    }
+}
+```
+
+And again, we then use the codec in [registration][registries], though this time directly:
+
+```java
+public static final DeferredRegister<MapCodec<? extends LevelBasedValue>> LEVEL_BASED_VALUES =
+        DeferredRegister.create(Registries.ENCHANTMENT_LEVEL_BASED_VALUE_TYPE, ExampleMod.MOD_ID);
+
+public static final Supplier<MapCodec<? extends LevelBasedValue>> INVERTED_SIGN =
+        LEVEL_BASED_VALUES.register("inverted_sign", () -> InvertedSignLevelBasedValue.CODEC);
+```
+
+## Custom Loot Conditions
+
+To get started, we create our loot item condition class that implements `LootItemCondition`. For the sake of example, let's assume we only want the condition to pass if the player killing the mob has a certain xp level:
+
+```java
+public record HasXpLevelCondition(int level) implements LootItemCondition {
+    // Add the context we need for this condition. In our case, this will be the xp level the player must have.
+    public static final MapCodec<HasXpLevelCondition> CODEC = RecordCodecBuilder.mapCodec(inst -> inst.group(
+            Codec.INT.fieldOf("level").forGetter(HasXpLevelCondition::level)
+    ).apply(inst, HasXpLevelCondition::new));
+    
+    // Evaluates the condition here. Get the required loot context parameters from the provided LootContext.
+    // In our case, we want the KILLER_ENTITY to have at least our required level.
+    @Override
+    public boolean test(LootContext context) {
+        @Nullable
+        Entity entity = context.getOptionalParameter(LootContextParams.KILLER_ENTITY);
+        return entity instanceof Player player && player.experienceLevel >= level; 
+    }
+    
+    // Tell the game what parameters we expect from the loot context. Used in validation.
+    @Override
+    public Set<ContextKey<?>> getReferencedContextParams() {
+        return ImmutableSet.of(LootContextParams.KILLER_ENTITY);
+    }
+}
+```
+
+We can [register][registries] the condition type to the registry using the condition's codec:
+
+```java
+public static final DeferredRegister<LootItemConditionType> LOOT_CONDITION_TYPES =
+        DeferredRegister.create(Registries.LOOT_CONDITION_TYPE, ExampleMod.MOD_ID);
+
+public static final Supplier<LootItemConditionType> MIN_XP_LEVEL =
+        LOOT_CONDITION_TYPES.register("min_xp_level", () -> new LootItemConditionType(HasXpLevelCondition.CODEC));
+```
+
+After we have done that, we need to override `#getType` in our condition and return the registered type:
+
+```java
+public record HasXpLevelCondition(int level) implements LootItemCondition {
+    // other stuff here
+
+    @Override
+    public LootItemConditionType getType() {
+        return MIN_XP_LEVEL.get();
+    }
+}
+```
+
+## Custom Loot Functions
+
+To get started, we create our own class extending `LootItemFunction`. `LootItemFunction` extends `BiFunction<ItemStack, LootContext, ItemStack>`, so what we want is to use the existing item stack and the loot context to return a new, modified item stack. However, almost all loot functions don't directly extend `LootItemFunction`, but extend `LootItemConditionalFunction` instead. This class has built-in functionality for applying loot conditions to the function - the function is only applied if the loot conditions apply. For the sake of example, let's apply a random enchantment with a specified level to the item:
+
+```java
+// Code adapted from vanilla's EnchantRandomlyFunction class.
+// LootItemConditionalFunction is an abstract class, not an interface, so we cannot use a record here.
+public class RandomEnchantmentWithLevelFunction extends LootItemConditionalFunction {
+    // Our context: an optional list of enchantments, and a level.
+    private final Optional<HolderSet<Enchantment>> enchantments;
+    private final int level;
+    // Our codec.
+    public static final MapCodec<RandomEnchantmentWithLevelFunction> CODEC =
+            // #commonFields adds the conditions field.
+            RecordCodecBuilder.mapCodec(inst -> commonFields(inst).and(inst.group(
+                    RegistryCodecs.homogeneousList(Registries.ENCHANTMENT).optionalFieldOf("enchantments").forGetter(e -> e.enchantments),
+                    Codec.INT.fieldOf("level").forGetter(e -> e.level)
+            ).apply(inst, RandomEnchantmentWithLevelFunction::new));
+    
+    public RandomEnchantmentWithLevelFunction(List<LootItemCondition> conditions, Optional<HolderSet<Enchantment>> enchantments, int level) {
+        super(conditions);
+        this.enchantments = enchantments;
+        this.level = level;
+    }
+    
+    // Run our enchantment application logic. Most of this is copied from EnchantRandomlyFunction#run.
+    @Override
+    public ItemStack run(ItemStack stack, LootContext context) {
+        RandomSource random = context.getRandom();
+        List<Holder<Enchantment>> stream = this.enchantments
+                .map(HolderSet::stream)
+                .orElseGet(() -> context.getLevel().registryAccess().registryOrThrow(Registries.ENCHANTMENT).listElements().map(Function.identity()))
+                .filter(e -> e.value().canEnchant(stack))
+                .toList();
+        Optional<Holder<Enchantment>> optional = Util.getRandomSafe(list, random);
+        if (optional.isEmpty()) {
+            LOGGER.warn("Couldn't find a compatible enchantment for {}", stack);
+        } else {
+            if (stack.is(Items.BOOK)) {
+                stack = new ItemStack(Items.ENCHANTED_BOOK);
+            }
+            stack.enchant(enchantment, Mth.nextInt(random, enchantment.value().getMinLevel(), enchantment.value().getMaxLevel()));
+        }
+        return stack;
+    }
+}
+```
+
+We can then [register][registries] the function type to the registry using the function's codec:
+
+```java
+public static final DeferredRegister<LootItemFunctionType<?>> LOOT_FUNCTION_TYPES =
+        DeferredRegister.create(Registries.LOOT_FUNCTION_TYPE, ExampleMod.MOD_ID);
+
+public static final Supplier<LootItemFunctionType<RandomEnchantmentWithLevelFunction>> RANDOM_ENCHANTMENT_WITH_LEVEL =
+        LOOT_FUNCTION_TYPES.register("random_enchantment_with_level", () -> new LootItemFunctionType(RandomEnchantmentWithLevelFunction.CODEC));
+```
+
+After we have done that, we need to override `#getType` in our condition and return the registered type:
+
+```java
+public class RandomEnchantmentWithLevelFunction extends LootItemConditionalFunction {
+    // other stuff here
+
+    @Override
+    public LootItemFunctionType<?> getType() {
+        return RANDOM_ENCHANTMENT_WITH_LEVEL.get();
+    }
+}
+```
+
+[codec]: ../../../datastorage/codecs.md
+[registries]: ../../../concepts/registries.md#methods-for-registering
diff --git a/versioned_docs/version-1.21.3/resources/server/loottables/glm.md b/versioned_docs/version-1.21.3/resources/server/loottables/glm.md
new file mode 100644
index 00000000..46ad439c
--- /dev/null
+++ b/versioned_docs/version-1.21.3/resources/server/loottables/glm.md
@@ -0,0 +1,194 @@
+# Global Loot Modifiers
+
+Global Loot Modifiers, or GLMs for short, are a data-driven way to modify drops without the need to overwrite dozens or hundreds of vanilla loot tables, or to handle effects that would require interactions with another mod's loot tables without knowing what mods are loaded.
+
+GLMs work by first rolling the associated [loot table][loottable] and then applying the GLM to the result of rolling the table. GLMs are also stacking, rather than last-load-wins, to allow for multiple mods to modify the same loot table, this is similar to [tags].
+
+To register a GLM, you will need four things:
+
+- A `global_loot_modifiers.json` file, located at `data/neoforge/loot_modifiers/global_loot_modifiers.json` (**not in your mod's namespace**). This file tells NeoForge what modifiers to apply, and in what order.
+- A JSON file representing your loot modifier. This file contains all the data for your modification, allowing data packs to tweak your effect. It is located at `data/<namespace>/loot_modifiers/<path>.json`.
+- A class that implements `IGlobalLootModifier` or extends `LootModifier` (which in turn implements `IGlobalLootModifier`). This class contains the code that makes the modifier work.
+- A map [codec] to encode and decode your loot modifier class. Usually, this is implemented as a `public static final` field in the loot modifier class.
+
+## `global_loot_modifiers.json`
+
+The `global_loot_modifiers.json` file tells NeoForge what modifiers to apply to loot tables. The file may contain two keys:
+
+- `entries` is a list of modifiers that should be loaded. The [`ResourceLocation`][resloc]s specified points to their associated entry within `data/<namespace>/loot_modifiers/<path>.json`. This list is ordered, meaning that modifiers will apply in the specified order, which is sometimes relevant when mod compatibility issues occur.
+- `replace` denotes whether the modifiers should replace old ones (`true`) or simply add to the existing list (`false`). This works similar to the `replace` key in [tags], however unlike tags, the key is required here. Generally, modders should always use `false` here; the ability to use `true` is directed at modpack or data pack developers.
+
+Example usage:
+
+```json5
+{
+    "replace": false, // must be present
+    "entries": [
+        // represents a loot modifier in data/examplemod/loot_modifiers/example_glm_1.json
+        "examplemod:example_glm_1",
+        "examplemod:example_glm_2"
+        // ...
+    ]
+}
+```
+
+## The Loot Modifier JSON
+
+This file contains all values related to your modifier, for example chances to apply, what items to add, etc. It is recommended to avoid hard-coded values wherever possible so that data pack makers can adjust balance if they wish to. A loot modifier must contain at least two fields and may contain more, depending on the circumstances:
+
+- The `type` field contains the registry name of the loot modifier.
+- The `conditions` field is a list of loot table conditions for this modifier to activate.
+- Additional properties may be required or optional, depending on the used codec.
+
+:::tip
+A common use case for GLMs is to add extra loot to one specific loot table. To achieve this, the [`neoforge:loot_table_id` condition][loottableid] can be used.
+:::
+
+An example usage may look something like this:
+
+```json5
+{
+    // This is the registry name of the loot modifier
+    "type": "examplemod:my_loot_modifier",
+    "conditions": [
+        // Loot table conditions here
+    ],
+    // Extra properties specified by the codec
+    "field1": "somestring",
+    "field2": 10,
+    "field3": "minecraft:dirt"
+}
+```
+
+## `IGlobalLootModifier` and `LootModifier`
+
+To actually apply the loot modifier to the loot table, a `IGlobalLootModifier` implementation must be specified. In most cases, you will want to use the `LootModifier` subclass, which handles things like conditions for you. To get started, we extend `LootModifier` in our loot modifier class:
+
+```java
+// We cannot use a record because records cannot extend other classes.
+public class MyLootModifier extends LootModifier {
+    // See below for how the codec works.
+    public static final MapCodec<MyLootModifier> CODEC = ...;
+    // Our extra properties.
+    private final String field1;
+    private final int field2;
+    private final Item field3;
+    
+    // First constructor parameter is the list of conditions. The rest is our extra properties.
+    public MyLootModifier(LootItemCondition[] conditions, String field1, int field2, Item field3) {
+        super(conditions);
+        this.field1 = field1;
+        this.field2 = field2;
+        this.field3 = field3;
+    }
+    
+    // Return our codec here.
+    @Override
+    public MapCodec<? extends IGlobalLootModifier> codec() {
+        return CODEC;
+    }
+    
+    // This is where the magic happens. Use your extra properties here if needed.
+    // Parameters are the existing loot, and the loot context.
+    @Override
+    protected ObjectArrayList<ItemStack> doApply(ObjectArrayList<ItemStack> generatedLoot, LootContext context) {
+        // Add your items to generatedLoot here.
+        return generatedLoot;
+    }
+}
+```
+
+:::info
+The returned list of drops from a modifier is fed into other modifiers in the order they are registered. As such, modified loot can and should be expected to be modified by another loot modifier.
+:::
+
+## The Loot Modifier Codec
+
+To tell the game about the existence of our loot modifier, we must define and [register] a [codec] for it. Reiterating on our previous example with the three fields, this would look something like this:
+
+```java
+public static final MapCodec<MyLootModifier> CODEC = RecordCodecBuilder.mapCodec(inst -> 
+        // LootModifier#codecStart adds the conditions field.
+        LootModifier.codecStart(inst).and(inst.group(
+                Codec.STRING.fieldOf("field1").forGetter(e -> e.field1),
+                Codec.INT.fieldOf("field2").forGetter(e -> e.field2),
+                BuiltInRegistries.ITEM.byNameCodec().fieldOf("field3").forGetter(e -> e.field3)
+        )).apply(inst, MyLootModifier::new)
+);
+```
+
+Then, we [register] the codec to the registry:
+
+```java
+public static final DeferredRegister<MapCodec<? extends IGlobalLootModifier>> GLOBAL_LOOT_MODIFIER_SERIALIZERS =
+        DeferredRegister.create(NeoForgeRegistries.Keys.GLOBAL_LOOT_MODIFIER_SERIALIZERS, ExampleMod.MOD_ID);
+
+public static final Supplier<MapCodec<MyLootModifier>> MY_LOOT_MODIFIER =
+        GLOBAL_LOOT_MODIFIER_SERIALIZERS.register("my_loot_modifier", () -> MyLootModifier.CODEC);
+```
+
+## Builtin Loot Modifiers
+
+NeoForge provides a loot modifier out of the box for you to use:
+
+### `neoforge:add_table`
+
+This loot modifier rolls a second loot table and adds the results to the loot table the modifier is applied to.
+
+```json5
+{
+    "type": "neoforge:add_table",
+    "conditions": [], // the required loot conditions
+    "table": "minecraft:chests/abandoned_mineshaft" // the second table to roll
+}
+```
+
+## Datagen
+
+GLMs can be [datagenned][datagen]. This is done by subclassing `GlobalLootModifierProvider`:
+
+```java
+public class MyGlobalLootModifierProvider extends GlobalLootModifierProvider {
+    // Get the PackOutput from GatherDataEvent.
+    public MyGlobalLootModifierProvider(PackOutput output, CompletableFuture<HolderLookup.Provider> registries) {
+        super(output, registries, ExampleMod.MOD_ID);
+    }
+    
+    @Override
+    protected void start() {
+        // Call #add to add a new GLM. This also adds a corresponding entry in global_loot_modifiers.json.
+        this.add(
+                // The name of the modifier. This will be the file name.
+                "my_loot_modifier_instance",
+                // The loot modifier to add. For the sake of example, we add a weather loot condition.
+                new MyLootModifier(new LootItemCondition[] {
+                        WeatherCheck.weather().setRaining(true).build()
+                }, "somestring", 10, Items.DIRT),
+                // A list of data load conditions. Note that these are unrelated to the loot conditions
+                // specified on the modifier itself. For the sake of example, we add a mod loaded condition.
+                // An overload of #add is available that accepts a vararg of conditions instead of a list.
+                List.of(new ModLoadedCondition("create"))
+        );
+    }
+}
+```
+
+And like all data providers, you must register the provider to `GatherDataEvent`:
+
+```java
+@SubscribeEvent
+public static void onGatherData(GatherDataEvent event) {
+    event.getGenerator().addProvider(
+        event.includeServer(),
+        output -> new MyGlobalLootModifierProvider(output, event.getLookupProvider())
+    );
+}
+```
+
+[codec]: ../../../datastorage/codecs.md
+[datagen]: ../../index.md#data-generation
+[loottable]: index.md
+[loottableid]: lootconditions#neoforgeloot_table_id
+[register]: ../../../concepts/registries.md#methods-for-registering
+[resloc]: ../../../misc/resourcelocation.md
+[tags]: ../tags.md
diff --git a/versioned_docs/version-1.21.3/resources/server/loottables/index.md b/versioned_docs/version-1.21.3/resources/server/loottables/index.md
new file mode 100644
index 00000000..1419b2c7
--- /dev/null
+++ b/versioned_docs/version-1.21.3/resources/server/loottables/index.md
@@ -0,0 +1,433 @@
+# Loot Tables
+
+Loot tables are data files that are used to define randomized loot drops. A loot table can be rolled, returning a (potentially empty) list of item stacks. The output of this process depends on (pseudo-)randomness. Loot tables are located at `data/<mod_id>/loot_table/<name>.json`. For example, the loot table `minecraft:blocks/dirt`, used by the dirt block, is located at `data/minecraft/loot_table/blocks/dirt.json`.
+
+Minecraft uses loot tables at various points in the game, including block drops, entity drops, chest loot, fishing loot, and many others. How a loot table is referenced depends on the context:
+
+- Every block will, by default, receive an associated loot table, located at `<block_namespace>:blocks/<block_name>`. This can be disabled by calling `#noLootTable` on the block's `Properties`, resulting in no loot table being created and the block dropping nothing; this is mainly done by air-like or technical blocks.
+- Every entity that does not call `EntityType.Builder#noLootTable` (which is typically entities in `MobCategory#MISC`) will, by default, receive an associated loot table, located at `<entity_namespace>:entities/<entity_name>`. This can be changed by overriding `#getLootTable`. For example, sheep use this to roll different loot tables depending on their wool color.
+- Chests in structures specify their loot table in their block entity data. Minecraft stores all chest loot tables in `minecraft:chests/<chest_name>`; it is recommended, but not required to follow this practice in mods.
+- The loot tables for gift items that villagers may throw at players after a raid are defined in the [`neoforge:raid_hero_gifts` data map][raidherogifts].
+- Other loot tables, for example the fishing loot table, are retrieved when needed from `level.getServer().reloadableRegistries().getLootTable(lootTableKey)`. A list of all vanilla loot table locations can be found in `BuiltInLootTables`.
+
+:::warning
+Loot tables should generally only be created for stuff that belongs to your mod. For modifying existing loot tables, [global loot modifiers (GLMs)][glm] should be used instead.
+:::
+
+Due to the complexity of the loot table system, loot tables are compromised of several sub-systems that each have a different purpose.
+
+## Loot Entry
+
+A loot entry (or loot pool entry), represented in code through the abstract `LootPoolEntryContainer` class, is a singular loot element. It can specify one or multiple items to be dropped.
+
+Vanilla provides a total of 8 different loot entry types. Through the common `LootPoolEntryContainer` superclass, all of them have the following properties:
+
+- `weight`: The weight value. Defaults to 1. This is used for cases where some items should be more common than others. For example, given two loot entries, one with weight 3 and one with weight 1, then there is a 75% chance for the first entry to be chosen, and a 25% chance for the second entry.
+- `quality`: The quality value. Defaults to 0. If this is non-zero, then this value is multiplied by the luck value (set in the [loot context][context]) and added to the weight when rolling the loot table.
+- `conditions`: A list of [loot conditions][lootcondition] to apply to this loot entry. If one condition fails, the entry is treated as if it weren't present.
+- `functions`: A list of [loot functions][lootfunction] to apply to the outputs of this loot entry.
+
+Loot entries are generally split into two groups: singletons (with the common superclass `LootPoolSingletonContainer`) and composites (with the common superclass `CompositeEntryBase`), where composites are made up of multiple singletons. The following singleton types are provided by Minecraft:
+
+- `minecraft:empty`: An empty loot entry, representing no item. Created in code by calling `EmptyLootItem#emptyItem`.
+- `minecraft:item`: A singular loot item entry, dropping the specified item when rolled. Created in code by calling `LootItem#lootTableItem` with the desired item.
+    - Setting stack size, data components, etc. can be done using loot functions.
+- `minecraft:tag`: A tag entry, dropping all items in the specified tag when rolling. Has two variants, depending on the value of the boolean `expand` property. If `expand` is true, a separate entry for each item in the tag is generated, otherwise one entry is used to drop all items. Created by calling `TagEntry#tagContents` (for `expand=false`) or `TagEntry#expandTag` (for `expand=true`), each with an item [tag key][tags] parameter.
+    - For example, if `expand` is true and the tag is `#minecraft:planks`, one entry is generated for each planks type (so 11 entries for the 11 vanilla planks + one entry per modded planks), each with the specified weight, quality and functions; whereas if `expand` is false, one single entry dropping all planks is used.
+- `minecraft:dynamic`: A loot entry referencing a dynamic drop. Dynamic drops are a system to add entries to a loot table that cannot be specified beforehand, instead adding them in code. A dynamic drops entry consists of an id and a `Consumer<ItemStack>` that actually adds the items. To add a dynamic drops entry, specify a `minecraft:dynamic` entry with the desired id and then add a corresponding consumer in the [loot context][context]. Created using `DynamicLoot#dynamicEntry`.
+- `minecraft:loot_table`: A loot entry that rolls another loot table, adding the result of that loot table as a single entry. The other loot table can either be specified by id or be inlined as a whole. Created in code by calling `NestedLootTable#lootTableReference` with a `ResourceLocation` parameter, or `NestedLootTable#inlineLootTable` with a `LootTable` object parameter for an inline loot table.
+
+The following composite types are provided by Minecraft:
+
+- `minecraft:group`: A loot entry containing a list of other loot entries, which are run in order. Created in code by calling `EntryGroup#list`, or by calling `#append` on another `LootPoolSingletonContainer.Builder`, each with other loot entry builders.
+- `minecraft:sequence`: Like `minecraft:group`, but the loot entry stops running as soon as one sub-entry fails, discarding all entries after that. Created in code by calling `SequentialEntry#sequential`, or by calling `#then` on another `LootPoolSingletonContainer.Builder`, each with other loot entry builders.
+- `minecraft:alternatives`: Sort of an opposite to `minecraft:sequence`, but the loot entry stops running as soon as one sub-entry succeeds (instead of as soon as one fails), discarding all entries after that. Created in code by calling `AlternativesEntry#alternatives`, or by calling `#otherwise` on another `LootPoolSingletonContainer.Builder`, each with other loot entry builders.
+
+For modders, it is also possible to define [custom loot entry types][customentry].
+
+## Loot Pool
+
+A loot pool is, in essence, a list of loot entries. Loot tables can contain multiple loot pools, each loot pool will be rolled independently of the others.
+
+Loot pools may contain the following contents:
+
+- `entries`: A list of loot entries.
+- `conditions`: A list of [loot conditions][lootcondition] to apply to this loot pool. If one condition fails, none of the loot pool's entries will be rolled.
+- `functions`: A list of [loot functions][lootfunction] to apply to all loot entry outputs of this loot pool.
+- `rolls` and `bonus_rolls`: Two number providers (read on) that together determine the amount of times this loot pool will be rolled. The formula is rolls + bonus_rolls * luck, where the luck value is set in the [loot parameters][parameters].
+- `name`: A name for the loot pool. NeoForge-added. This can be used by [GLMs][glm]. If unspecified, this is the hash code of the loot pool, prefixed by `custom#`.
+
+## Number Provider
+
+Number providers are a way to get (pseudo-)randomized numbers in a datapack context. Primarily used by loot tables, they are also used in other contexts, for example in worldgen. Vanilla provides the following six number providers:
+
+- `minecraft:constant`: A constant float value, rounding to integer where needed. Created through `ConstantValue#exactly`.
+- `minecraft:uniform`: Uniformly-distributed random integer or float values, with min and max values set. All values between min and max have the same chance to appear. Created through `UniformGenerator#between`.
+- `minecraft:binomial`: Binomially-distributed random integer values, with n and p values set. See [Binomial Distribution][binomial] for more information on what these values mean. Created through `BinomialDistributionGenerator#binomial`.
+- `minecraft:score`: Given an entity target, a score name and (optionally) a scale value, retrieves the given scoreboard value for the entity target, multiplying it with the given scale value (if available). Created through `ScoreboardValue#fromScoreboard`.
+- `minecraft:storage`: A value from the command storage at a given nbt path. Created through `new StorageValue`.
+- `minecraft:enchantment_level`: A provider of values for each enchantment level. Created through `EnchantmentLevelProvider#forEnchantmentLevel`, providing a `LevelBasedValue`. Valid `LevelBasedValue`s are:
+    - Simply a constant value, without a specified type. Created through `LevelBasedValue#constant`.
+    - `minecraft:linear`: A linearly-increasing value per enchantment level, plus an optional constant base value. Created through `LevelBasedValue#perLevel`.
+    - `minecraft:levels_squared`: Squares the enchantment value, and then adds an optional base value to it. Created through `new LevelBasedValue.LevelsSquared`.
+    - `minecraft:fraction`: Accepts two other `LevelBasedValue`s, using them to create a fraction. Created through `new LevelBasedValue.Fraction`.
+    - `minecraft:clamped`: Accepts another `LevelBasedValue`, alongside min and max values. Calculates the value using the other `LevelBasedValue` and clamps the result. Created through `new LevelBasedValue.Clamped`.
+    - `minecraft:lookup`: Accepts a `List<Float>` and a fallback `LevelBasedValue`. Looks up the value to use in the list (level 1 is the first element in the list, level 2 is the second element, etc.), and uses the fallback value if the value for a level is missing. Created through `LevelBasedValue#lookup`.
+
+Modders can also register [custom number providers][customnumber] and [custom level-based values][customlevelbased] if needed.
+
+## Loot Parameters
+
+A loot parameter, known internally as a `ContextKey<T>`, is a parameter provided to a loot table when rolled, where `T` is the type of the provided parameter, for example `BlockPos` or `Entity`. They can be used by [loot conditions][lootcondition] and [loot functions][lootfunction]. For example, the `minecraft:killed_by_player` loot condition checks for the presence of the `minecraft:player` parameter.
+
+Minecraft provides the following loot parameters:
+
+- `minecraft:origin`: A location associated with the loot table, e.g. the location of a loot chest. Access via `LootContextParams.ORIGIN`.
+- `minecraft:tool`: An item stack associated with the loot table, e.g. the item used to break a block. This is not necessarily a tool. Access via `LootContextParams.TOOL`.
+- `minecraft:enchantment_level`: An enchantment level, used by enchantment logic. Access via `LootContextParams.ENCHANTMENT_LEVEL`.
+- `minecraft:enchantment_active`: Whether the used item has an enchantment or not, used e.g. by silk touch checks. Access via `LootContextParams.ENCHANTMENT_ACTIVE`.
+- `minecraft:block_state`: A block state associated with the loot table, e.g. the broken block state. Access via `LootContextParams.BLOCK_STATE`.
+- `minecraft:block_entity`: A block entity associated with the loot table, e.g. the block entity associated with the broken block. Used e.g. by shulker boxes to save their inventory to the dropped item. Access via `LootContextParams.BLOCK_ENTITY`.
+- `minecraft:explosion_radius`: An explosion radius in the current context. Used primarily to apply explosion decay to drops. Access via `LootContextParams.EXPLOSION_RADIUS`.
+- `minecraft:this_entity`: An entity associated with the loot table, typically the killed entity. Access via `LootContextParams.THIS_ENTITY`.
+- `minecraft:damage_source`: A [damage source][damagesource] associated with the loot table, typically the damage source that killed the entity. Access via `LootContextParams.DAMAGE_SOURCE`.
+- `minecraft:attacking_entity`: An attacking entity associated with the loot table, typically the killer of the entity. Access via `LootContextParams.ATTACKING_ENTITY`.
+- `minecraft:direct_attacking_entity`: A direct attacking entity associated with the loot table. For example, if the attacking entity were a skeleton, the direct attacking entity would be the arrow. Access via `LootContextParams.DIRECT_ATTACKING_ENTITY`.
+- `minecraft:last_damage_player`: A player associated with the loot table, typically the player that last attacked the killed entity, even if the player kill was indirect (for example: the player tapped the entity, and it was then killed by spikes). Used e.g. for player-kill-only drops. Access via `LootContextParams.LAST_DAMAGE_PLAYER`.
+
+Custom loot parameters can be created by calling `new ContextKey<T>` with the desired id. Since they are merely resource location wrappers, they do not need to be registered.
+
+### Entity Targets
+
+Entity targets are a type used in loot conditions and functions, represented by the `LootContext.EntityTarget` enum in code. They are used to specify the entity loot parameter to query in a condition or function context. Valid values are:
+
+- `"this"` or `LootContext.EntityTarget.THIS`: Represents the `"minecraft:this_entity"` parameter.
+- `"attacker"` or `LootContext.EntityTarget.ATTACKER`: Represents the `"minecraft:attacking_entity"` parameter.
+- `"direct_attacker"` or `LootContext.EntityTarget.DIRECT_ATTACKER`: Represents the `"minecraft:direct_attacking_entity"` parameter.
+- `"attacking_player"` or `LootContext.EntityTarget.ATTACKING_PLAYER`: Represents the `"minecraft:last_damage_player"` parameter.
+
+For example, the `minecraft:entity_properties` loot condition accepts an entity target to allow all four loot parameters to be checked, if that is what you (as the loot table author) need.
+
+### Loot Parameter Sets
+
+Loot parameter sets, also known as loot table types and known as `ContextKeySet`s in code, are a collection of required and optional loot parameters. Despite their name, they are not `Set`s (not even `Collection`s). Rather, they are a wrapper around two `Set<ContextKey<?>>`s, one holding the required parameters (`#required`) and one holding the optional parameters (`#allowed`). They are used to validate that users of loot parameters only use the parameters that can be expected to be available, and to verify that the required parameters are present when rolling a table. Besides that, they are also used in advancement and enchantment logic.
+
+Vanilla provides the following loot parameter sets (required parameters are **bold**, optional parameters are _in italics_; the in-code names are constants in `LootContextParamSets`):
+
+| ID                               | In-code name           | Specified Loot Parameters                                                                                                                                                                                                                                                                                            | Usage                                                     |
+|----------------------------------|------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------|
+| `minecraft:empty`                | `EMPTY`                | n/a                                                                                                                                                                                                                                                                                                                  | Fallback purposes.                                        |
+| `minecraft:generic`              | `ALL_PARAMS`           | **`minecraft:origin`**, **`minecraft:tool`**, **`minecraft:block_state`**, **`minecraft:block_entity`**, **`minecraft:explosion_radius`**, **`minecraft:this_entity`**, **`minecraft:damage_source`**, **`minecraft:attacking_entity`**, **`minecraft:direct_attacking_entity`**, **`minecraft:last_damage_player`** | Validation.                                               |
+| `minecraft:command`              | `COMMAND`              | **`minecraft:origin`**, _`minecraft:this_entity`_                                                                                                                                                                                                                                                                    | Commands.                                                 |
+| `minecraft:selector`             | `SELECTOR`             | **`minecraft:origin`**, _`minecraft:this_entity`_                                                                                                                                                                                                                                                                    | Entity selectors in commands.                             |
+| `minecraft:block`                | `BLOCK`                | **`minecraft:origin`**, **`minecraft:tool`**, **`minecraft:block_state`**, _`minecraft:block_entity`_, _`minecraft:explosion_radius`_, _`minecraft:this_entity`_                                                                                                                                                     | Block breaking.                                           |
+| `minecraft:block_use`            | `BLOCK_USE`            | **`minecraft:origin`**, **`minecraft:block_state`**, **`minecraft:this_entity`**                                                                                                                                                                                                                                     | No vanilla uses.                                          |
+| `minecraft:hit_block`            | `HIT_BLOCK`            | **`minecraft:origin`**, **`minecraft:enchantment_level`**, **`minecraft:block_state`**, **`minecraft:this_entity`**                                                                                                                                                                                                  | The channeling enchantment.                               |
+| `minecraft:chest`                | `CHEST`                | **`minecraft:origin`**, _`minecraft:this_entity`_, _`minecraft:attacking_entity`_                                                                                                                                                                                                                                    | Loot chests and similar containers, loot chest minecarts. |
+| `minecraft:archaeology`          | `ARCHAEOLOGY`          | **`minecraft:origin`**, **`minecraft:this_entity`**, **`minecraft:tool`**                                                                                                                                                                                                                                                                    | Archaeology.                                              |
+| `minecraft:vault`                | `VAULT`                | **`minecraft:origin`**, _`minecraft:this_entity`_, _`minecraft:tool`_                                                                                                                                                                                                                                                                    | Trial chamber vault rewards.                              |
+| `minecraft:entity`               | `ENTITY`               | **`minecraft:origin`**, **`minecraft:this_entity`**, **`minecraft:damage_source`**, _`minecraft:attacking_entity`_, _`minecraft:direct_attacking_entity`_, _`minecraft:last_damage_player`_                                                                                                                          | Entity kills.                                             |
+| `minecraft:shearing`             | `SHEARING`             | **`minecraft:origin`**, **`minecraft:this_entity`**, **`minecraft:tool`**                                                                                                                                                                                                                                                                    | Shearing entities, e.g. sheep.                            |
+| `minecraft:equipment`            | `EQUIPMENT`            | **`minecraft:origin`**, **`minecraft:this_entity`**                                                                                                                                                                                                                                                                  | Entity equipment for e.g. zombies.                        |
+| `minecraft:gift`                 | `GIFT`                 | **`minecraft:origin`**, **`minecraft:this_entity`**                                                                                                                                                                                                                                                                  | Raid hero gifts.                                          |
+| `minecraft:barter`               | `PIGLIN_BARTER`        | **`minecraft:this_entity`**                                                                                                                                                                                                                                                                                          | Piglin bartering.                                         |
+| `minecraft:fishing`              | `FISHING`              | **`minecraft:origin`**, **`minecraft:tool`**, _`minecraft:this_entity`_, _`minecraft:attacking_entity`_                                                                                                                                                                                                              | Fishing.                                                  |
+| `minecraft:enchanted_item`       | `ENCHANTED_ITEM`       | **`minecraft:tool`**, **`minecraft:enchantment_level`**                                                                                                                                                                                                                                                              | Several enchantments.                                     |
+| `minecraft:enchanted_entity`     | `ENCHANTED_ENTITY`     | **`minecraft:origin`**, **`minecraft:enchantment_level`**, **`minecraft:this_entity`**                                                                                                                                                                                                                               | Several enchantments.                                     |
+| `minecraft:enchanted_damage`     | `ENCHANTED_DAMAGE`     | **`minecraft:origin`**, **`minecraft:enchantment_level`**, **`minecraft:this_entity`**, **`minecraft:damage_source`**, _`minecraft:attacking_entity`_, _`minecraft:direct_attacking_entity`_                                                                                                                         | Damage and protection enchantments.                       |
+| `minecraft:enchanted_location`   | `ENCHANTED_LOCATION`   | **`minecraft:origin`**, **`minecraft:enchantment_level`**, **`minecraft:enchantment_active`**, **`minecraft:this_entity`**                                                                                                                                                                                           | Frost walker and soul speed enchantments.                 |
+| `minecraft:advancement_entity`   | `ADVANCEMENT_ENTITY`   | **`minecraft:origin`**, **`minecraft:this_entity`**                                                                                                                                                                                                                                                                  | Several [advancement criteria][advancement].              |
+| `minecraft:advancement_location` | `ADVANCEMENT_LOCATION` | **`minecraft:origin`**, **`minecraft:tool`**, **`minecraft:block_state`**, **`minecraft:this_entity`**                                                                                                                                                                                                               | Several [advancement triggers][advancement].              |
+| `minecraft:advancement_reward`   | `ADVANCEMENT_REWARD`   | **`minecraft:origin`**, **`minecraft:this_entity`**                                                                                                                                                                                                                                                                  | [Advancement rewards][advancement].                       |
+
+### Loot Context
+
+The loot context is an object containing situational information for rolling loot tables. The information includes:
+
+- The `ServerLevel` the loot table is rolled in. Get via `#getLevel`.
+- The `RandomSource` used to roll the loot table. Get via `#getRandom`.
+- The loot parameters. Check presence using `#hasParameter`, and get single parameters using `#getParameter`.
+- The luck value, used for calculating bonus rolls and quality values. Usually populated via the entity's luck attribute. Get via `#getLuck`.
+- The dynamic drops consumers. See [above][entry] for more information. Set via `#addDynamicDrops`. No getter available.
+
+## Loot Table
+
+Combining all the previous elements, we finally get a loot table. Loot table JSONs can specify the following values:
+
+- `pools`: A list of loot pools.
+- `neoforge:conditions`: A list of [data load conditions][conditions]. **Warning: These are data load conditions, not [loot conditions][lootcondition]!**
+- `functions`: A list of [loot functions][lootfunction] to apply to all loot entry outputs of this loot table.
+- `type`: A loot parameter set, used to validate proper usage of loot parameters. Optional; if absent, validation will be skipped.
+- `random_sequence`: A random sequence for this loot table, in the form of a resource location. Random sequences are provided by the `Level` and used for consistent loot table rolls under identical conditions. This commonly uses the loot table's location.
+
+An example loot table could have the following format:
+
+```json5
+{
+    "type": "chest", // loot parameter set
+    "neoforge:conditions": [
+        // data load conditions
+    ],
+    "functions": [
+        // table-wide loot functions
+    ],
+    "pools": [ // list of loot pools
+        {
+            "rolls": 1, // amount of rolls of the loot table, using 5 here will yield 5 results from the pool
+            "bonus_rolls": 0.5, // amount of bonus rolls
+            "name": "my_pool",
+            "conditions": [
+                // pool-wide loot conditions
+            ],
+            "functions": [
+                // pool-wide loot functions
+            ],
+            "entries": [ // list of loot table entries
+                {
+                    "type": "minecraft:item", // loot entry type
+                    "name": "minecraft:dirt", // type-specific properties, for example the name of the item
+                    "weight": 3, // weight of an entry
+                    "quality": 1, // quality of an entry
+                    "conditions": [
+                        // entry-wide loot conditions
+                    ],
+                    "functions": [
+                        // entry-wide loot functions
+                    ]
+                }
+            ]
+        }
+    ]
+}
+```
+
+## Rolling a Loot Table
+
+To roll a loot table, we need two things: the loot table itself, and a loot context.
+
+Let's start with getting the loot table itself. We can obtain a loot table using `level.getServer().reloadableRegistries().getLootTable(lootTableId)`. As the loot data is only available through the server, this logic must run on a [logical server][sides], not a logical client.
+
+:::tip
+Minecraft's built-in loot table IDs can be found in the `BuiltInLootTables` class. Block loot tables can be obtained through `BlockBehaviour#getLootTable`, and entity loot tables can be obtained through `EntityType#getDefaultLootTable` or `Entity#getLootTable`.
+:::
+
+Now that we have a loot table, let's build our parameter set. We begin by creating an instance of `LootParams.Builder`:
+
+```java
+// Make sure that you are on a server, otherwise the cast will fail.
+LootParams.Builder builder = new LootParams.Builder((ServerLevel) level);
+```
+
+We can then add loot context parameters, like so:
+
+```java
+// Use whatever context parameters and values you need. Vanilla parameters can be found in LootContextParams.
+builder.withParameter(LootContextParams.ORIGIN, position);
+// This variant can accept null as the value, in which case an existing value for that parameter will be removed.
+builder.withOptionalParameter(LootContextParams.ORIGIN, null);
+// Add a dynamic drop.
+builder.withDynamicDrop(ResourceLocation.fromNamespaceAndPath("examplemod", "example_dynamic_drop"), stackAcceptor -> {
+    // some logic here
+});
+// Set our luck value. Assumes that a player is available. Contexts without a player should use 0 here.
+builder.withLuck(player.getLuck());
+```
+
+Finally, we can create the `LootParams` from the builder and use them to roll the loot table:
+
+```java
+// Specify a loot context param set here if you want.
+LootParams params = builder.create(LootContextParamSets.EMPTY);
+// Get the loot table.
+LootTable table = level.getServer().reloadableRegistries().getLootTable(location);
+// Actually roll the loot table.
+List<ItemStack> list = table.getRandomItems(params);
+// Use this instead if you are rolling the loot table for container contents, e.g. loot chests.
+// This method takes care of properly splitting the loot items across the container.
+List<ItemStack> containerList = table.fill(container, params, someSeed);
+```
+
+:::danger
+`LootTable` additionally exposes a method named `#getRandomItemsRaw`. Unlike the various `#getRandomItems` variants, `#getRandomItemsRaw` method will not apply [global loot modifiers][glm]. Use this method only if you know what you are doing.
+:::
+
+## Datagen
+
+Loot tables can be [datagenned][datagen] by registering a `LootTableProvider` and providing a list of `LootTableSubProvider` in the constructor:
+
+```java
+@SubscribeEvent
+public static void onGatherData(GatherDataEvent event) {
+    event.getGenerator().addProvider(
+            event.includeServer(),
+            output -> new LootTableProvider(
+                    output,
+                    // A set of required table resource locations. These are later verified to be present.
+                    // It is generally not recommended for mods to validate existence,
+                    // therefore we pass in an empty set.
+                    Set.of(),
+                    // A list of sub provider entries. See below for what values to use here.
+                    List.of(...),
+                    // The registry access
+                    event.getLookupProvider()
+            )
+    );
+}
+```
+
+### `LootTableSubProvider`s
+
+`LootTableSubProvider`s are where the actual generation happens. To get started, we implement `LootTableSubProvider` and override `#generate`:
+
+```java
+public class MyLootTableSubProvider implements LootTableSubProvider {
+    // The parameter is provided by the lambda (see below). It can be stored and used to lookup other registry entries.
+    public MyLootTableSubProvider(HolderLookup.Provider lookupProvider) {
+        // Store the lookupProvider in a field
+    }
+
+    @Override
+    public void generate(BiConsumer<ResourceLocation, LootTable.Builder> consumer) {
+        // LootTable.lootTable() returns a loot table builder we can add loot tables to.
+        consumer.accept(ResourceLocation.fromNamespaceAndPath(ExampleMod.MOD_ID, "example_loot_table"), LootTable.lootTable()
+                // Add a loot table-level loot function. This example uses a number provider (see below).
+                .apply(SetItemCountFunction.setCount(ConstantValue.exactly(5)))
+                // Add a loot pool.
+                .withPool(LootPool.lootPool()
+                        // Add a loot pool-level function, similar to above.
+                        .apply(...)
+                        // Add a loot pool-level condition. This example only rolls the pool if it is raining.
+                        .when(WeatherCheck.weather().setRaining(true))
+                        // Set the amount of rolls and bonus rolls, respectively.
+                        // Both of these methods utilize a number provider.
+                        .setRolls(UniformGenerator.between(5, 9))
+                        .setBonusRolls(ConstantValue.exactly(1))
+                        // Add a loot entry. This example returns an item loot entry. See below for more loot entries.
+                        .add(LootItem.lootTableItem(Items.DIRT))
+                )
+        );
+    }
+}
+```
+
+Once we have our loot table sub provider, we add it to the constructor of our loot provider, like so:
+
+```java
+new LootTableProvider(output, Set.of(), List.of(
+        new SubProviderEntry(
+                // A reference to the sub provider's constructor.
+                // This is a Function<HolderLookup.Provider, ? extends LootTableSubProvider>.
+                MyLootTableSubProvider::new,
+                // An associated loot context set. If you're unsure what to use, use empty.
+                LootContextParamSets.EMPTY
+        ),
+        // other sub providers here (if applicable)
+    ), lookupProvider
+);
+```
+
+### `BlockLootSubProvider`
+
+`BlockLootSubProvider` is an abstract helper class containing many helpers for creating common block loot tables, e.g. single item drops (`#createSingleItemTable`), dropping the block the table is created for (`#dropSelf`), silk touch-only drops (`#createSilkTouchOnlyTable`), drops for slab-like blocks (`#createSlabItemTable`), and many more. Unfortunately, setting up a `BlockLootSubProvider` for modded usage involves more boilerplate:
+
+```java
+public class MyBlockLootSubProvider extends BlockLootSubProvider {
+    // The constructor can be private if this class is an inner class of your loot table provider.
+    // The parameter is provided by the lambda in the LootTableProvider's constructor.
+    public MyBlockLootSubProvider(HolderLookup.Provider lookupProvider) {
+        // The first parameter is a set of blocks we are creating loot tables for. Instead of hardcoding,
+        // we use our block registry and just pass an empty set here.
+        // The second parameter is the feature flag set, this will be the default flags
+        // unless you are adding custom flags (which is beyond the scope of this article).
+        super(Set.of(), FeatureFlags.DEFAULT_FLAGS, lookupProvider);
+    }
+
+    // The contents of this Iterable are used for validation.
+    // We return an Iterable over our block registry's values here.
+    @Override
+    protected Iterable<Block> getKnownBlocks() {
+        // The contents of our DeferredRegister.
+        return MyRegistries.BLOCK_REGISTRY.getEntries()
+                .stream()
+                // Cast to Block here, otherwise it will be a ? extends Block and Java will complain.
+                .map(e -> (Block) e.value())
+                .toList();
+    }
+
+    // Actually add our loot tables.
+    @Override
+    protected void generate() {
+        // Equivalent to calling add(MyBlocks.EXAMPLE_BLOCK.get(), createSingleItemTable(MyBlocks.EXAMPLE_BLOCK.get()));
+        this.dropSelf(MyBlocks.EXAMPLE_BLOCK.get());
+        // Add a table with a silk touch only loot table.
+        this.add(MyBlocks.EXAMPLE_SILK_TOUCHABLE_BLOCK.get(),
+                this.createSilkTouchOnlyTable(MyBlocks.EXAMPLE_SILK_TOUCHABLE_BLOCK.get()));
+        // other loot table additions here
+    }
+}
+```
+
+We then add our sub provider to the loot table provider's constructor like any other sub provider:
+
+```java
+new LootTableProvider(output, Set.of(), List.of(new SubProviderEntry(
+        MyBlockLootTableSubProvider::new,
+        LootContextParamSets.BLOCK // it makes sense to use BLOCK here
+    )), lookupProvider
+);
+```
+
+### `EntityLootSubProvider`
+
+Similar to `BlockLootSubProvider`, `EntityLootSubProvider` provides many helpers for entity loot table generation. Also similar to `BlockLootSubProvider`, we must provide a `Stream<EntityType<?>>` of entities known to the provider (instead of the `Iterable<Block>` used before). Overall, our implementation looks very similar to our `BlockLootSubProvider`, but with every mentioned of blocks swapped out for entity types:
+
+```java
+public class MyEntityLootSubProvider extends EntityLootSubProvider {
+    public MyEntityLootSubProvider(HolderLookup.Provider lookupProvider) {
+        // Unlike with blocks, we do not provide a set of known entity types. Vanilla instead uses custom checks here.
+        super(FeatureFlags.DEFAULT_FLAGS, lookupProvider);
+    }
+
+    // This class uses a Stream instead of an Iterable, so we need to adjust this slightly.
+    @Override
+    protected Stream<EntityType<?>> getKnownEntityTypes() {
+        return MyRegistries.ENTITY_TYPES.getEntries()
+                .stream()
+                .map(e -> (EntityType<?>) e.value());
+    }
+
+    @Override
+    protected void generate() {
+        this.add(MyEntities.EXAMPLE_ENTITY.get(), LootTable.lootTable());
+        // other loot table additions here
+    }
+}
+```
+
+And again, we then add our sub provider to the loot table provider's constructor:
+
+```java
+new LootTableProvider(output, Set.of(), List.of(new SubProviderEntry(
+        MyEntityLootTableSubProvider::new,
+        LootContextParamSets.ENTITY
+    )), lookupProvider
+);
+```
+
+[advancement]: ../advancements.md
+[binomial]: https://en.wikipedia.org/wiki/Binomial_distribution
+[conditions]: ../conditions.md
+[context]: #loot-context
+[customentry]: custom.md#custom-loot-entry-types
+[customlevelbased]: custom.md#custom-level-based-values
+[customnumber]: custom.md#custom-number-providers
+[damagesource]: ../damagetypes.md#creating-and-using-damage-sources
+[datagen]: ../../index.md#data-generation
+[entry]: #loot-entry
+[glm]: glm.md
+[lootcondition]: lootconditions
+[lootfunction]: lootfunctions
+[parameters]: #loot-parameters
+[raidherogifts]: ../datamaps/builtin.md#neoforgeraid_hero_gifts
+[sides]: ../../../concepts/sides.md
+[tags]: ../tags.md
diff --git a/versioned_docs/version-1.21.3/resources/server/loottables/lootconditions.md b/versioned_docs/version-1.21.3/resources/server/loottables/lootconditions.md
new file mode 100644
index 00000000..2a35f1fe
--- /dev/null
+++ b/versioned_docs/version-1.21.3/resources/server/loottables/lootconditions.md
@@ -0,0 +1,400 @@
+# Loot Conditions
+
+Loot conditions can be used to check whether a [loot entry][entry] or [loot pool][pool] should be used in the current context. In both cases, a list of conditions is defined; the entry or pool is only used if all conditions pass. During datagen, they are added to a `LootPoolEntryContainer.Builder<?>` or `LootPool.Builder` by calling `#when` with an instance of the desired condition. This article will outline the available loot conditions. To create your own loot conditions, see [Custom Loot Conditions][custom].
+
+## `minecraft:inverted`
+
+This condition accepts another condition and inverts its result. Requires whatever loot parameters the other condition requires.
+
+```json5
+{
+    "condition": "minecraft:inverted",
+    "term": {
+        // Some other loot condition.
+    }
+}
+```
+
+During datagen, call `InvertedLootItemCondition#invert` with the condition to invert to construct a builder for this condition.
+
+## `minecraft:all_of`
+
+This condition accepts any number of other conditions and returns true if all sub conditions return true. If the list is empty, it returns false. Requires whatever loot parameters the other conditions require.
+
+```json5
+{
+    "condition": "minecraft:all_of",
+    "terms": [
+        {
+            // A loot condition.
+        },
+        {
+            // Another loot condition.
+        },
+        {
+            // Yet another loot condition.
+        }
+    ]
+}
+```
+
+During datagen, call `AllOfCondition#allOf` with the desired condition(s) to construct a builder for this condition.
+
+## `minecraft:any_of`
+
+This condition accepts any number of other conditions and returns true if at least one sub condition returns true. If the list is empty, it returns false. Requires whatever loot parameters the other conditions require.
+
+```json5
+{
+    "condition": "minecraft:any_of",
+    "terms": [
+        {
+            // A loot condition.
+        },
+        {
+            // Another loot condition.
+        },
+        {
+            // Yet another loot condition.
+        }
+    ]
+}
+```
+
+During datagen, call `AnyOfCondition#anyOf` with the desired condition(s) to construct a builder for this condition.
+
+## `minecraft:random_chance`
+
+This condition accepts a [number provider][numberprovider] representing a chance between 0 and 1, and randomly returns true or false depending on that chance. The number provider should generally not return values outside the `[0, 1]` interval.
+
+```json5
+{
+    "condition": "minecraft:random_chance",
+    // A constant 50% chance for the condition to apply. 
+    "chance": 0.5
+}
+```
+
+During datagen, call `LootItemRandomChanceCondition#randomChance` with the number provider or a (constant) float value to construct a builder for this condition.
+
+## `minecraft:random_chance_with_enchanted_bonus`
+
+This condition accepts an enchantment id, a [`LevelBasedValue`][numberprovider] and a constant fallback float value. If the specified enchantment is present, the `LevelBasedValue` is queried for a value. If the specified enchantment is absent, or no value could be retrieved from the `LevelBasedValue`, the constant fallback value is used. The condition then randomly returns true or false, with the previously determined value denoting the chance that true is returned. Requires the `minecraft:attacking_entity` parameter, falling back to level 0 if absent.
+
+```json5
+{
+    "condition": "minecraft:random_chance_with_enchanted_bonus",
+    // Add a 20% chance per looting level to succeed.
+    "enchantment": "minecraft:looting",
+    "enchanted_chance": {
+        "type": "linear",
+        "base": 0.2,
+        "per_level_above_first": 0.2
+    },
+    // Always fail if the looting enchantment is not present.
+    "unenchanted_chance": 0.0
+}
+```
+
+During datagen, call `LootItemRandomChanceWithEnchantedBonusCondition#randomChanceAndLootingBoost` with the registry lookup (`HolderLookup.Provider`), the base value and the increase per level to construct a builder for this condition. Alternatively, call `new LootItemRandomChanceWithEnchantedBonusCondition` to further specify the values.
+
+## `minecraft:value_check`
+
+This condition accepts a [number provider][numberprovider] and an `IntRange`, returning true if the result of the number provided is within the range.
+
+```json5
+{
+    "condition": "minecraft:value_check",
+    // May be any number provider.
+    "value": {
+        "type": "minecraft:uniform",
+        "min": 0.0,
+        "max": 10.0
+    },
+    // A range with min/max values.
+    "range": {
+        "min": 2.0,
+        "max": 5.0
+    }
+}
+```
+
+During datagen, call `ValueCheckCondition#hasValue` with the number provider and the range to construct a builder for this condition.
+
+## `minecraft:time_check`
+
+This condition checks if the world time is within an `IntRange`. Optionally, a `period` parameter can be provided to modulo the time with; this can be used to e.g. check the time of day if `period` is 24000 (one in-game day/night cycle has 24000 ticks).
+
+```json5
+{
+    "condition": "minecraft:time_check",
+    // Optional, can be omitted. If omitted, no modulo operation will take place.
+    // We use 24000 here, which is the length of one in-game day/night cycle.
+    "period": 24000,
+    // A range with min/max values. This example checks if the time is between 0 and 12000.
+    // Combined with the modulo operand of 24000 specified above, this example checks if it is currently daytime.
+    "value": {
+        "min": 0,
+        "max": 12000
+    }
+}
+```
+
+During datagen, call `TimeCheck#time` with the desired range to construct a builder for this condition. The `period` value can then be set on the builder using `#setPeriod`.
+
+## `minecraft:weather_check`
+
+This condition checks the current weather for raining and thundering.
+
+```json5
+{
+    "condition": "minecraft:weather_check",
+    // Optional. If unspecified, the rain state will not be checked.
+    "raining": true,
+    // Optional. If unspecified, the thundering state will not be checked.
+    // Specifying "raining": true and "thundering": true is functionally equivalent to just specifying
+    // "thundering": true, since it is always raining when a thunderstorm occurs.
+    "thundering": false
+}
+```
+
+During datagen, call `WeatherCheck#weather` to construct a builder for this condition. The `raining` and `thundering` values can then be set on the builder using `#setRaining` and `#setThundering`, respectively.
+
+## `minecraft:location_check`
+
+This condition accepts a `LocationPredicate` and an optional offset value for each axis direction. `LocationPredicate`s allow checking conditions such as the position itself, the block or fluid state at that position, the dimension, biome or structure at that position, the light level, whether the sky is visible, etc. All possible values can be viewed in the `LocationPredicate` class definition. Requires the `minecraft:origin` loot parameter, always failing if that parameter is absent.
+
+```json5
+{
+    "condition": "minecraft:location_check",
+    "predicate": {
+        // Succeed if our target is anywhere in the nether.
+        "dimension": "the_nether"
+    },
+    // Optional position offset values. Only relevant if you are checking the position in some way.
+    // Must either be provided all at once, or not at all.
+    "offsetX": 10,
+    "offsetY": 10,
+    "offsetZ": 10
+}
+```
+
+During datagen, call `LocationCheck#checkLocation` with the `LocationPredicate` and optionally a `BlockPos` to construct a builder for this condition.
+
+## `minecraft:block_state_property`
+
+This condition checks for the specified block state properties to have the specified value in the broken block state. Requires the `minecraft:block_state` loot parameter, always failing if that parameter is absent.
+
+```json5
+{
+    "condition": "minecraft:block_state_property",
+    // The expected block. If this does not match the block that is actually broken, the condition fails.
+    "block": "minecraft:oak_slab",
+    // The block state properties to match. Unspecified properties can have either value.
+    // In this example, we want to only succeed if a top slab - waterlogged or not - is broken.
+    // If this specifies properties not present on the block, a log warning will be printed.
+    "properties": {
+        "type": "top"
+    }
+}
+```
+
+During datagen, call `LootItemBlockStatePropertyCondition#hasBlockStateProperties` with the block to construct a builder for this condition. The desired block state property values can then be set on the builder using `#setProperties`.
+
+## `minecraft:survives_explosion`
+
+This condition randomly destroys the drops. The chance for drops to survive is 1 / `explosion_radius` loot parameter. This function is used by all block drops, with very few exceptions such as the beacon or the dragon egg. Requires the `minecraft:explosion_radius` loot parameter, always succeeding if that parameter is absent.
+
+```json5
+{
+    "condition": "minecraft:survives_explosion"
+}
+```
+
+During datagen, call `ExplosionCondition#survivesExplosion` to construct a builder for this condition.
+
+## `minecraft:match_tool`
+
+This condition accepts an `ItemPredicate` that is checked against the `tool` loot parameter. An `ItemPredicate` can specify a list of valid item ids (`items`), a min/max range for the item count (`count`), a `DataComponentPredicate` (`components`) and a map of `ItemSubPredicate`s (`predicates`); all fields are optional. Requires the `minecraft:tool` loot parameter, always failing if that parameter is absent.
+
+```json5
+{
+    "condition": "minecraft:match_tool",
+    // Match a netherite pickaxe or axe.
+    "predicate": {
+        "items": [
+            "minecraft:netherite_pickaxe",
+            "minecraft:netherite_axe"
+        ]
+    }
+}
+```
+
+During datagen, call `MatchTool#toolMatches` with an `ItemPredicate.Builder` to invert to construct a builder for this condition.
+
+## `minecraft:enchantment_active`
+
+This condition returns whether an enchantment is active or not. Requires the `minecraft:enchantment_active` loot parameter, always failing if that parameter is absent.
+
+```json5
+{
+    "condition": "minecraft:enchantment_active",
+    // Whether the enchantment should be active (true) or not (false).
+    "active": true
+}
+```
+
+During datagen, call `EnchantmentActiveCheck#enchantmentActiveCheck` or `#enchantmentInactiveCheck` to construct a builder for this condition.
+
+## `minecraft:table_bonus`
+
+This condition is similar to `minecraft:random_chance_with_enchanted_bonus`, but with fixed values instead of randomized values. Requires the `minecraft:tool` loot parameter, always failing if that parameter is absent.
+
+```json5
+{
+    "condition": "minecraft:table_bonus",
+    // Apply the bonus if the fortune enchantment is present.
+    "enchantment": "minecraft:fortune",
+    // The chances to use per level. This example has a 20% chance of succeeding if unenchanted,
+    // 30% if enchanted at level 1, and 60% if enchanted at level 2 or above.
+    "chances": [0.2, 0.3, 0.6]
+}
+```
+
+During datagen, call `BonusLevelTableCondition#bonusLevelFlatChance` with the enchantment id and the chances to construct a builder for this condition.
+
+## `minecraft:entity_properties`
+
+This condition checks a given `EntityPredicate` against an [entity target][entitytarget]. The `EntityPredicate` can check the entity type, mob effects, nbt values, equipment, location, etc.
+
+```json5
+{
+    "condition": "minecraft:entity_properties",
+    // The entity target to use. Valid values are "this", "attacker", "direct_attacker" or "attacking_player".
+    // These correspond to the "this_entity", "attacking_entity", "direct_attacking_entity" and
+    // "last_damage_player" loot parameters, respectively.
+    "entity": "attacker",
+    // Only succeed if the target is a pig. The predicate may also be empty, this can be used
+    // to check whether the specified entity target is set at all.
+    "predicate": {
+        "type": "minecraft:pig"
+    }
+}
+```
+
+During datagen, call `LootItemEntityPropertyCondition#entityPresent` with the entity target, or `LootItemEntityPropertyCondition#hasProperties` with the entity target and the `EntityPredicate`, to construct a builder for this condition.
+
+## `minecraft:damage_source_properties`
+
+This condition checks a given `DamageSourcePredicate` against the damage source loot parameter. Requires the `minecraft:origin` and `minecraft:damage_source` loot parameters, always failing if those parameter are absent.
+
+```json5
+{
+    "condition": "minecraft:damage_source_properties",
+    "predicate": {
+        // Check whether the source entity is a zombie.
+        "source_entity": {
+            "type": "zombie"
+        }
+    }
+}
+```
+
+During datagen, call `DamageSourceCondition#hasDamageSource` with a `DamageSourcePredicate.Builder` to construct a builder for this condition.
+
+## `minecraft:killed_by_player`
+
+This condition determines whether the kill was a player kill. Used by some entity drops, for example blaze rods dropped by blazes. Requires the `minecraft:last_player_damage` loot parameter, always failing if that parameter is absent.
+
+```json5
+{
+    "condition": "minecraft:killed_by_player"
+}
+```
+
+During datagen, call `LootItemKilledByPlayerCondition#killedByPlayer` to construct a builder for this condition.
+
+## `minecraft:entity_scores`
+
+This condition checks the [entity target][entitytarget]'s scoreboard. Requires the loot parameter corresponding to the specified entity target, always failing if that parameter is absent.
+
+```json5
+{
+    "condition": "minecraft:entity_scores"
+    // The entity target to use. Valid values are "this", "attacker", "direct_attacker" or "attacking_player".
+    // These correspond to the "this_entity", "attacking_entity", "direct_attacking_entity" and
+    // "last_damage_player" loot parameters, respectively.
+    "entity": "attacker",
+    // A list of scoreboard values that must be in the given ranges.
+    "scores": {
+        "score1": {
+            "min": 0,
+            "max": 100
+        },
+        "score2": {
+            "min": 10,
+            "max": 20
+        }
+    }
+}
+```
+
+During datagen, call `EntityHasScoreCondition#hasScores` with an entity target to construct a builder for this condition. Then, add required scores to the builder using `#withScore`.
+
+## `minecraft:reference`
+
+This condition references a predicate file and returns its result. See [Item Predicates][predicate] for more information.
+
+```json5
+{
+    "condition": "minecraft:reference",
+    // Refers to the predicate file at data/examplemod/predicate/example_predicate.json.
+    "name": "examplemod:example_predicate"
+}
+```
+
+During datagen, call `ConditionReference#conditionReference` with the id of the referenced predicate file to construct a builder for this condition.
+
+## `neoforge:loot_table_id`
+
+This condition only returns true if the surrounding loot table id matches. This is typically used within [global loot modifiers][glm].
+
+```json5
+{
+    "condition": "neoforge:loot_table_id",
+    // Will only apply when the loot table is for dirt
+    "loot_table_id": "minecraft:blocks/dirt"
+}
+```
+
+During datagen, call `LootTableIdCondition#builder` with the desired loot table id to construct a builder for this condition.
+
+## `neoforge:can_item_perform_ability`
+
+This condition only returns true if the item in the `tool` loot context parameter (`LootContextParams.TOOL`), usually the item used to break the block or kill the entity, can perform the specified [`ItemAbility`][itemability]. Requires the `minecraft:tool` loot parameter, always failing if that parameter is absent.
+
+```json5
+{
+    "condition": "neoforge:can_item_perform_ability",
+    // Will only apply if the tool can strip a log like an axe
+    "ability": "axe_strip"
+}
+```
+
+During datagen, call `CanItemPerformAbility#canItemPerformAbility` with the id of the desired item ability to construct a builder for this condition.
+
+## See Also
+
+- [Item Predicates][predicatejson] on the [Minecraft Wiki][mcwiki]
+
+[custom]: custom.md#custom-loot-conditions
+[entitytarget]: index.md#entity-targets
+[entry]: index.md#loot-entry
+[glm]: glm.md
+[itemability]: ../../../items/tools.md#itemabilitys
+[mcwiki]: https://minecraft.wiki
+[numberprovider]: index.md#number-provider
+[pool]: index.md#loot-pool
+[predicate]: https://minecraft.wiki/w/Predicate
+[predicatejson]: https://minecraft.wiki/w/Predicate#JSON_format
+[registry]: ../../../concepts/registries.md
diff --git a/versioned_docs/version-1.21.3/resources/server/loottables/lootfunctions.md b/versioned_docs/version-1.21.3/resources/server/loottables/lootfunctions.md
new file mode 100644
index 00000000..0cc4df8c
--- /dev/null
+++ b/versioned_docs/version-1.21.3/resources/server/loottables/lootfunctions.md
@@ -0,0 +1,859 @@
+# Loot Functions
+
+Loot functions can be used to modify the result of a [loot entry][entry], or the multiple results of a [loot pool][pool] or [loot table][table]. In both cases, a list of functions is defined, which is run in order. During datagen, loot functions can be applied to `LootPoolSingletonContainer.Builder<?>`s, `LootPool.Builder`s and `LootTable.Builder`s by calling `#apply`. This article will outline the available loot functions. To create your own loot functions, see [Custom Loot Functions][custom].
+
+:::note
+Loot functions cannot be applied to composite loot entries (subclasses of `CompositeEntryBase` and their associated builder classes). They must be added to each singleton entry manually.
+:::
+
+All vanilla loot functions except `minecraft:sequence` can specify [loot conditions][conditions] in a `conditions` block. If one of these conditions fails, the function will not be applied. On the code side, this is controlled by the `LootItemConditionalFunction`, which all loot functions except for `SequenceFunction` extend.
+
+## `minecraft:set_item`
+
+Sets a different item to use in the result item stack.
+
+```json5
+{
+    "function": "minecraft:set_item",
+    // The item to use.
+    "item": "minecraft:dirt"
+}
+```
+
+It is currently not possible to create this function during datagen.
+
+## `minecraft:set_count`
+
+Sets an item count to use in the result item stack. Uses a [number provider][numberprovider].
+
+```json5
+{
+    "function": "minecraft:set_count",
+    // The count to use.
+    "count": {
+        "type": "minecraft:uniform",
+        "min": 1,
+        "max": 3
+    },
+    // Whether to add to the existing value instead of setting it. Optional, defaults to false.
+    "add": true
+}
+```
+
+During datagen, call `SetItemCountFunction#setCount` with the desired number provider and optionally an `add` boolean to construct a builder for this function.
+
+## `minecraft:explosion_decay`
+
+Applies an explosion decay. The item has a chance of 1 / `explosion_radius` to "survive". This is run multiple times depending on the count. Requires the `minecraft:explosion_radius` loot parameter, no modification is performed if that parameter is absent.
+
+```json5
+{
+    "function": "minecraft:explosion_decay"
+}
+```
+
+During datagen, call `ApplyExplosionDecay#explosionDecay` to construct a builder for this function.
+
+## `minecraft:limit_count`
+
+Clamps the count of the item stack between a given `IntRange`.
+
+```json5
+{
+    "function": "minecraft:limit_count",
+    // The limit to use. Can have a min, a max, or both.
+    "limit": {
+        "max": 32
+    }
+}
+```
+
+During datagen, call `LimitCount#limitCount` with the desired `IntRange` to construct a builder for this function.
+
+## `minecraft:set_custom_data`
+
+Sets custom NBT data on the item stack.
+
+```json5
+{
+    "function": "minecraft:set_custom_data",
+    "tag": {
+        "exampleproperty": 0
+    }
+}
+```
+
+During datagen, call `SetCustomDataFunction#setCustomData` with the desired [`CompoundTag`][nbt] to construct a builder for this function.
+
+:::warning
+This function should generally be considered deprecated. Use `minecraft:set_components` instead.
+:::
+
+## `minecraft:copy_custom_data`
+
+Copies custom NBT data from a block entity or entity source to the item stack. Use of this is discouraged for block entities, use `minecraft:copy_components` or `minecraft:set_contents` instead. For entities, this requires setting the [entity target][entitytarget]. Requires the loot parameter corresponding to the specified source (entity target or block entity), no modification is performed if that parameter is absent.
+
+```json5
+{
+    "function": "minecraft:copy_custom_data",
+    // The source to use. Valid values are either an entity target, "block_entity" to use the loot context's
+    // block entity parameter, or be "storage" for command storage. If this is "storage", it can instead be a
+    // JSON object that additionally specify the command storage path to be used.
+    "source": "this",
+    // Example for using "storage".
+    "source": {
+        "type": "storage",
+        "source": "examplepath"
+    },
+    // The copy operation(s).
+    "ops": [
+        {
+            // The source and target paths. In this example, we copy from "src" in the source to "dest" in the target.
+            "source": "src",
+            "target": "dest",
+            // A merging strategy. Valid values are "replace", "append", and "merge".
+            "op": "merge"
+        }
+    ]
+}
+```
+
+During datagen, call `CopyCustomDataFunction#copyData` with the associated `NbtProvider` to get the builder. Then call `Builder#copy` with the desired source and target values, as well as a merging strategy (optional, defaults to `replace`), to construct a builder for this function.
+
+## `minecraft:set_components`
+
+Sets [data component][datacomponent] values on the item stack. Most vanilla use cases have specialized functions that are explained below.
+
+```json5
+{
+    "function": "minecraft:set_components",
+    // Any component can be used. In this example, we set the dyed color of the item to red.
+    "components": {
+        "dyed_color": {
+            "rgb": 16711680
+        }
+    }
+}
+```
+
+During datagen, call `SetComponentsFunction#setComponent` with the desired data component and value to construct a builder for this function.
+
+## `minecraft:copy_components`
+
+Copies [data component][datacomponent] values from a block entity to the item stack. Requires the `minecraft:block_entity` loot parameter, no modification is performed if that parameter is absent.
+
+```json5
+{
+    "function": "minecraft:copy_components",
+    // The system is designed to allow multiple sources, however for now, there are only block entities available.
+    "source": "block_entity",
+    // By default, all components are copied. The "exclude" list allows excluding certain components, and the
+    // "include" list allows explicitly re-including components. Both fields are optional.
+    "exclude": [],
+    "include": []
+}
+```
+
+During datagen, call `CopyComponentsFunction#copyComponents` with the desired data source (usually `CopyComponentsFunction.Source.BLOCK_ENTITY`) to construct a builder for this function.
+
+## `minecraft:copy_state`
+
+Copies block state properties into the item stack's `block_state` [data component][datacomponent], used when trying to place a block. The block state properties to copy must be explicitly specified. Requires the `minecraft:block_state` loot parameter, no modification is performed if that parameter is absent.
+
+```json5
+{
+    "function": "minecraft:copy_state",
+    // The expected block. If this does not match the block that is actually broken, the function does not run.
+    "block": "minecraft:oak_slab",
+    // The block state properties to save.
+    "properties": {
+        "type": "top"
+    }
+}
+```
+
+During datagen, call `CopyBlockState#copyState` with the block to construct a builder for this condition. The desired block state property values can then be set on the builder using `#copy`.
+
+## `minecraft:set_contents`
+
+Sets contents of the item stack.
+
+```json5
+{
+    "function": "minecraft:set_contents",
+    // The contents component to use. Valid values are "container", "bundle_contents" and "charged_projectiles".
+    "component": "container",
+    // A list of loot entries to add to the contents.
+    "entries": [
+        {
+            "type": "minecraft:empty",
+            "weight": 3
+        },
+        {
+            "type": "minecraft:item",
+            "item": "minecraft:arrow"
+        }
+    ]
+}
+```
+
+During datagen, call `SetContainerContents#setContents` with the desired contents component to construct a builder for this function. Then, call `#withEntry` on the builder to add entries.
+
+## `minecraft:modify_contents`
+
+Applies a function to the contents of the item stack.
+
+```json5
+{
+    "function": "minecraft:modify_contents",
+    // The contents component to use. Valid values are "container", "bundle_contents" and "charged_projectiles".
+    "component": "container",
+    // The function to use.
+    "modifier": "apply_explosion_decay"
+}
+```
+
+It is currently not possible to create this function during datagen.
+
+## `minecraft:set_loot_table`
+
+Sets a container loot table on the result item stack. Intended for chests and other loot containers that retain this property when placed down.
+
+```json5
+{
+    "function": "minecraft:set_loot_table",
+    // The id of the loot table to use.
+    "name": "minecraft:entities/enderman",
+    // The id of the block entity type of the target block entity.
+    "type": "minecraft:chest",
+    // The random seed for generating loot tables. Optional, defaults to 0.
+    "seed": 42
+}
+```
+
+During datagen, call `SetContainerLootTable#withLootTable` with the desired block entity type, loot table resource key and optionally a seed to construct a builder for this function.
+
+## `minecraft:set_name`
+
+Sets a name for the result item stack. The name can be a [`Component`][component] instead of a literal string. It can also be resolved from an [entity target][entitytarget]. Requires the corresponding entity loot parameter if applicable, no modification is performed if that parameter is absent.
+
+```json5
+{
+    "function": "minecraft:set_name",
+    "name": "Funny Item",
+    // The entity target to use.
+    "entity": "this",
+    // Whether to set the custom name ("custom_name") or the item name ("item_name") itself.
+    // Custom name are displayed in italics and can be changed in an anvil, while item names cannot.
+    "target": "custom_name"
+}
+```
+
+During datagen, call `SetNameFunction#setName` with the desired name component, the desired name target and optionally an entity target to construct a builder for this function.
+
+## `minecraft:copy_name`
+
+Copies an [entity target][entitytarget]'s or block entity's name into the result item stack. Requires the loot parameter corresponding to the specified source (entity target or block entity), no modification is performed if that parameter is absent.
+
+```json5
+{
+    "function": "minecraft:copy_name",
+    // The entity target, or "block_entity" if a block entity's name should be copied.
+    "source": "this"
+}
+```
+
+During datagen, call `CopyNameFunction#copyName` with the desired entity source to construct a builder for this function.
+
+## `minecraft:set_lore`
+
+Sets lore (tooltip lines) for the result item stack. The lines can be [`Component`][component]s instead of literal strings. It can also be resolved from an [entity target][entitytarget]. Requires the corresponding entity loot parameter if applicable, no modification is performed if that parameter is absent.
+
+```json5
+{
+    "function": "minecraft:set_lore",
+    "lore": [
+        "Funny Lore",
+        "Funny Lore 2"
+    ],
+    // The merging mode used. Valid values are:
+    // - "append": Appends the entries to any existing lore entries.
+    // - "insert": Inserts the entries at a certain position. The position is denoted as an additional field
+    //   named "offset". "offset" is optional and defaults to 0.
+    // - "replace_all": Removes all previous entries and then appends the entries.
+    // - "replace_section": Removes a section of entries and then adds the entries at that position.
+    //   The section removed is denoted through the "offset" and optional "size" fields.
+    //   If "size" is omitted, the amount of lines in "lore" is used.
+    "mode": {
+        "type": "insert",
+        "offset": 0
+    },
+    // The entity target to use.
+    "entity": "this"
+}
+```
+
+During datagen, call `SetLoreFunction#setLore` to construct a builder for this function. Then, call `#addLine`, `#setMode` and `#setResolutionContext` as needed on the builder.
+
+## `minecraft:toggle_tooltips`
+
+Enables or disables certain component tooltips.
+
+```json5
+{
+    "function": "minecraft:toggle_tooltips",
+    "toggles": {
+        // All values are optional. If omitted, these values will use pre-existing values on the stack.
+        // The pre-existing values are generally true, unless they have already been modified by another function.
+        "minecraft:attribute_modifiers": false,
+        "minecraft:can_break": false,
+        "minecraft:can_place_on": false,
+        "minecraft:dyed_color": false,
+        "minecraft:enchantments": false,
+        "minecraft:jukebox_playable": false,
+        "minecraft:stored_enchantments": false,
+        "minecraft:trim": false,
+        "minecraft:unbreakable": false
+    }
+}
+```
+
+It is currently not possible to create this function during datagen.
+
+## `minecraft:enchant_with_levels`
+
+Randomly enchants the item stack with a given amount of levels. Uses a [number provider][numberprovider].
+
+```json5
+    {
+    "function": "minecraft:enchant_with_levels",
+    // The amount of levels to use.
+    "levels": {
+        "type": "minecraft:uniform",
+        "min": 10,
+        "max": 30
+    },
+    // A list of possible enchantments. Optional, defaults to all applicable enchantments for the item.
+    "options": [
+        "minecraft:sharpness",
+        "minecraft:fire_aspect"
+    ]
+}
+```
+
+During datagen, call `EnchantWithLevelsFunction#enchantWithLevels` with the desired number provider to construct a builder for this function. Then, if desired, set a list of enchantments on the builder using `#fromOptions`.
+
+## `minecraft:enchant_randomly`
+
+Enchants the item with one random enchantment.
+
+```json5
+{
+    "function": "minecraft:enchant_randomly",
+    // A list of possible enchantments. Optional, defaults to all enchantments.
+    "options": [
+        "minecraft:sharpness",
+        "minecraft:fire_aspect"
+    ],
+    // Whether to only allow compatible enchantments, or any enchantments. Optional, defaults to true.
+    "only_compatible": true
+}
+```
+
+During datagen, call `EnchantRandomlyFunction#randomEnchantment` or `EnchantRandomlyFunction#randomApplicableEnchantment` to construct a builder for this function. Then, if desired, call `#withEnchantment` or `#withOneOf` on the builder.
+
+## `minecraft:set_enchantments`
+
+Sets enchantments on the result item stack.
+
+```json5
+{
+    "function": "minecraft:set_enchantments",
+    // A map of enchantments to number providers.
+    "enchantments": {
+        "minecraft:fire_aspect": 2,
+        "minecraft:sharpness": {
+        "type": "minecraft:uniform",
+        "min": 3,
+        "max": 5,
+        }
+    },
+    // Whether to add enchantment levels to existing levels instead of overwriting them. Optional, defaults to false.
+    "add": true
+}
+```
+
+During datagen, call `new SetEnchantmentsFunction.Builder` with the `add` boolean value (optionally) to construct a builder for this function. Then, call `#withEnchantment` to add an enchantment to set.
+
+## `minecraft:enchanted_count_increase`
+
+Increases the item stack count based on the enchantment value. Uses a [number provider][numberprovider]. Requires the `minecraft:attacking_entity` loot parameter, no modification is performed if that parameter is absent.
+
+```json5
+{
+    "function": "minecraft:enchanted_count_increase",
+    // The enchantment to use.
+    "enchantment": "minecraft:fortune",
+    // The increase count per level. The number provider is rolled once per function, not once per level.
+    "count": {
+        "type": "minecraft:uniform",
+        "min": 1,
+        "max": 3
+    },
+    // The stack size limit, which will not be exceeded no matter the enchantment level. Optional.
+    "limit": 5
+}
+```
+
+During datagen, call `EnchantedCountIncreaseFunction#lootingMultiplier` with the desired number provider to construct a builder for this function. Optionally, call `#setLimit` on the builder afterwards.
+
+## `minecraft:apply_bonus`
+
+Applies an increase to the item stack count based on the enchantment value and various formulas. Requires the `minecraft:tool` loot parameter, no modification is performed if that parameter is absent.
+
+```json5
+{
+    "function": "minecraft:apply_bonus",
+    // The enchantment value to query.
+    "enchantment": "minecraft:fortune",
+    // The formula to use. Valid values are:
+    // - "minecraft:binomial_with_bonus_count": Applies a bonus based on a binomial distribution with
+    //   n = enchantment level + extra and p = probability.
+    // - "minecraft:ore_drops": Applies a bonus based on a special formula for ore drops, including randomness.
+    // - "minecraft:uniform_bonus_count": Adds a bonus based on the enchantment level scaled by a constant multiplier.
+    "formula": "ore_drops",
+    // The parameter values, depending on the formula.
+    // If the formula is "minecraft:binomial_with_bonus_count", requires "extra" and "probability".
+    // If the formula is "minecraft:ore_drops", requires no parameters.
+    // If the formula is "minecraft:uniform_bonus_count", requires "bonusMultiplier".
+    "parameters": {}
+}
+```
+
+During datagen, call `ApplyBonusCount#addBonusBinomialDistributionCount`, `ApplyBonusCount#addOreBonusCount` or `ApplyBonusCount#addUniformBonusCount` with the enchantment and other required parameters (depending on the formula) to construct a builder for this function.
+
+## `minecraft:furnace_smelt`
+
+Attempts to smelt the item as if it were in a furnace, returning the unmodified item stack if it could not be smelted.
+
+```json5
+{
+    "function": "minecraft:furnace_smelt"
+}
+```
+
+During datagen, call `SmeltItemFunction#smelted` to construct a builder for this function.
+
+## `minecraft:set_damage`
+
+Sets a durability damage value on the result item stack. Uses a [number provider][numberprovider].
+
+```json5
+{
+    "function": "minecraft:set_damage",
+    // The damage to set.
+    "damage": {
+        "type": "minecraft:uniform",
+        "min": 10,
+        "max": 300
+    },
+    // Whether to add to the existing damage instead of setting it. Optional, defaults to false.
+    "add": true
+}
+```
+
+During datagen, call `SetItemDamageFunction#setDamage` with the desired number provider and optionally an `add` boolean to construct a builder for this function.
+
+## `minecraft:set_attributes`
+
+Adds a list of attribute modifiers to the result item stack.
+
+```json5
+{
+    "function": "minecraft:set_attributes",
+    // A list of attribute modifiers.
+    "modifiers": [
+        {
+            // The resource location id of the modifier. Should be prefixed by your mod id.
+            "id": "examplemod:example_modifier",
+            // The id of the attribute the modifier is for.
+            "attribute": "minecraft:generic.attack_damage",
+            // The attribute modifier operation.
+            // Valid values are "add_value", "add_multiplied_base" and "add_multiplied_total". 
+            "operation": "add_value",
+            // The amount of the modifier. This can also be a number provider.
+            "amount": 5,
+            // The slot(s) the modifier applies for. Valid values are "any" (any inventory slot),
+            // "mainhand", "offhand", "hand", (mainhand/offhand/both hands),
+            // "feet", "legs", "chest", "head", "armor" (boots/leggings/chestplates/helmets/any armor slots)
+            // and "body" (horse armor and similar slots).
+            "slot": "armor"
+        }
+    ],
+    // Whether to replace the existing values instead of adding to them. Optional, defaults to true.
+    "replace": false
+}
+```
+
+During datagen, call `SetAttributesFunction#setAttributes` to construct a builder for this function. Then, add modifiers using `#withModifier` on the builder. Use `SetAttributesFunction#modifier` to get a modifier.
+
+## `minecraft:set_potion`
+
+Sets a potion on the result item stack.
+
+```json5
+{
+    "function": "minecraft:set_potion",
+    // The id of the potion.
+    "id": "minecraft:strength"
+}
+```
+
+During datagen, call `SetPotionFunction#setPotion` with the desired potion to construct a builder for this function.
+
+## `minecraft:set_stew_effect`
+
+Sets a list of stew effects on the result item stack.
+
+```json5
+{
+    "function": "minecraft:set_stew_effect",
+    // The effects to set.
+    "effects": [
+        {
+        // The effect id.
+        "type": "minecraft:fire_resistance",
+        // The effect duration, in ticks. This can also be a number provider.
+        "duration": 100
+        }
+    ]
+}
+```
+
+During datagen, call `SetStewEffectFunction#stewEffect` to construct a builder for this function. Then, call `#withModifier` on the builder.
+
+## `minecraft:set_ominous_bottle_amplifier`
+
+Sets an ominous bottle amplifier on the result item stack. Uses a [number provider][numberprovider].
+
+```json5
+{
+    "function": "minecraft:set_ominous_bottle_amplifier",
+    // The amplifier to use.
+    "amplifier": {
+        "type": "minecraft:uniform",
+        "min": 1,
+        "max": 3
+    }
+}
+```
+
+During datagen, call `SetOminousBottleAmplifierFunction#setAmplifier` with the desired number provider to construct a builder for this function.
+
+## `minecraft:exploration_map`
+
+Transforms the result item stack into an exploration map if and only if it is a map. Requires the `minecraft:origin` loot parameter, no modification is performed if that parameter is absent.
+
+```json5
+{
+    "function": "minecraft:exploration_map",
+    // A structure tag, containing the structures an exploration map can lead to.
+    // Optional, defaults to "minecraft:on_treasure_maps", which only contains buried treasures by default.
+    "destination": "minecraft:eye_of_ender_located",
+    // The map decoration type to use. See the MapDecorationTypes class for available values.
+    // Optional, defaults to "minecraft:mansion".
+    "decoration": "minecraft:target_x",
+    // The zoom level to use. Optional, defaults to 2.
+    "zoom": 4,
+    // The search radius to use. Optional, defaults to 50.
+    "search_radius": 25,
+    // Whether existing chunks are skipped when searching for structures. Optional, defaults to true.
+    "skip_existing_chunks": true
+}
+```
+
+During datagen, call `ExplorationMapFunction#makeExplorationMap` to construct a builder for this function. Then, call the various setters on the builder if desired.
+
+## `minecraft:fill_player_head`
+
+Sets the player head owner on the result item stack based on the given [entity target][entitytarget]. Requires the corresponding loot parameter, no modification is performed if that parameter is absent.
+
+```json5
+{
+    "function": "minecraft:fill_player_head",
+    // The entity target to use. If this doesn't resolve to a player, the stack is not modified.
+    "entity": "this_entity"
+}
+```
+
+During datagen, call `FillPlayerHead#fillPlayerHead` with the desired entity target to construct a builder for this function.
+
+## `minecraft:set_banner_pattern`
+
+Sets banner patterns on the result item stack. This is for banners, not banner pattern items.
+
+```json5
+{
+    "function": "minecraft:set_banner_patterns",
+    // A list of banner pattern layers.
+    "patterns": [
+        {
+            // The id of the banner pattern to use.
+            "pattern": "minecraft:globe",
+            // The dye color of the layer.
+            "color": "light_blue"
+        }
+    ],
+    // Whether to append to the existing layers instead of replacing them.
+    "append": true
+}
+```
+
+During datagen, call `SetBannerPatternFunction#setBannerPattern` with the `append` boolean to construct a builder for this function. Then, call `#addPattern` to add patterns to the function.
+
+## `minecraft:set_instrument`
+
+Sets the instrument tag on the result item stack.
+
+```json5
+{
+    "function": "minecraft:set_instrument",
+    // The instrument tag to use.
+    "options": "minecraft:goat_horns"
+}
+```
+
+During datagen, call `SetInstrumentFunction#setInstrumentOptions` with the desired instrument tag to construct a builder for this function.
+
+## `minecraft:set_fireworks`
+
+```json5
+{
+    "function": "minecraft:set_fireworks",
+    // The explosions to use. Optional, uses the existing data component value if absent.
+    "explosions": [
+        {
+            // The firework explosion shape to use. Valid vanilla values are "small_ball", "large_ball",
+            // "star", "creeper" and "burst". Optional, defaults to "small_ball".
+            "shape": "star",
+            // The colors to use. Optional, defaults to an empty list.
+            "colors": [
+                16711680,
+                65280
+            ],
+            // The fade colors to use. Optional, defaults to an empty list.
+            "fade_colors": [
+                65280,
+                255
+            ],
+            // Whether the explosion has a trail. Optional, defaults to false.
+            "has_trail": true,
+            // Whether the explosion has a twinkle. Optional, defaults to false.
+            "has_twinkle": true
+        }
+    ],
+    // The flight duration of the fireworks. Optional, uses the existing data component value if absent.
+    "flight_duration": 5
+}
+```
+
+It is currently not possible to create this function during datagen.
+
+## `minecraft:set_firework_explosion`
+
+Sets a firework explosion on the result item stack.
+
+```json5
+{
+    "function": "minecraft:set_firework_explosion",
+    // The firework explosion shape to use. Valid vanilla values are "small_ball", "large_ball",
+    // "star", "creeper" and "burst". Optional, defaults to "small_ball".
+    "shape": "star",
+    // The colors to use. Optional, defaults to an empty list.
+    "colors": [
+        16711680,
+        65280
+    ],
+    // The fade colors to use. Optional, defaults to an empty list.
+    "fade_colors": [
+        65280,
+        255
+    ],
+    // Whether the explosion has a trail. Optional, defaults to false.
+    "trail": true,
+    // Whether the explosion has a twinkle. Optional, defaults to false.
+    "twinkle": true
+}
+```
+
+It is currently not possible to create this function during datagen.
+
+## `minecraft:set_book_cover`
+
+Sets a written book's non-page-specific content.
+
+```json5
+{
+    "function": "minecraft:set_book_cover",
+    // The book title. Optional, if absent, the book title remains unchanged.
+    "title": "Hello World!",
+    // The book author. Optional, if absent, the book author remains unchanged.
+    "author": "Steve",
+    // The book generation, i.e. how often it has been copied. Clamped between 0 and 3.
+    // Optional, if absent, the book generation remains unchanged.
+    "generation": 2
+}
+```
+
+During datagen, call `new SetBookCoverFunction` with the desired parameters to construct a builder for this function.
+
+## `minecraft:set_written_book_pages`
+
+Sets the pages of a written book.
+
+```json5
+{
+    "function": "minecraft:set_written_book_pages",
+    // The pages to set, as a list of strings.
+    "pages": [
+        "Hello World!",
+        "Hello World on page 2!",
+        "Never Gonna Give You Up!"
+    ],
+    // The merging mode used. Valid values are:
+    // - "append": Appends the entries to any existing lore entries.
+    // - "insert": Inserts the entries at a certain position. The position is denoted as an additional field
+    //   named "offset". "offset" is optional and defaults to 0.
+    // - "replace_all": Removes all previous entries and then appends the entries.
+    // - "replace_section": Removes a section of entries and then adds the entries at that position.
+    //   The section removed is denoted through the "offset" and optional "size" fields.
+    //   If "size" is omitted, the amount of lines in "lore" is used.
+    "mode": {
+        "type": "insert",
+        "offset": 0
+    }
+}
+```
+
+It is currently not possible to create this function during datagen.
+
+## `minecraft:set_writable_book_pages`
+
+Sets the pages of a writable book (book and quill).
+
+```json5
+{
+    "function": "minecraft:set_writable_book_pages",
+    // The pages to set, as a list of strings.
+    "pages": [
+        "Hello World!",
+        "Hello World on page 2!",
+        "Never Gonna Give You Up!"
+    ],
+    // The merging mode used. Valid values are:
+    // - "append": Appends the entries to any existing lore entries.
+    // - "insert": Inserts the entries at a certain position. The position is denoted as an additional field
+    //   named "offset". "offset" is optional and defaults to 0.
+    // - "replace_all": Removes all previous entries and then appends the entries.
+    // - "replace_section": Removes a section of entries and then adds the entries at that position.
+    //   The section removed is denoted through the "offset" and optional "size" fields.
+    //   If "size" is omitted, the amount of lines in "lore" is used.
+    "mode": {
+        "type": "insert",
+        "offset": 0
+    }
+}
+```
+
+It is currently not possible to create this function during datagen.
+
+## `minecraft:set_custom_model_data`
+
+Sets the custom model data of the result item stack.
+
+```json5
+{
+    "function": "minecraft:set_custom_model_data",
+    // The custom model data value to use. This can also be a number provider.
+    "value": 4
+}
+```
+
+It is currently not possible to create this function during datagen.
+
+## `minecraft:filtered`
+
+This function accepts an `ItemPredicate` that is checked against the generated stack; if the check succeeds, the other function is run. An `ItemPredicate` can specify a list of valid item ids (`items`), a min/max range for the item count (`count`), a `DataComponentPredicate` (`components`) and a map of `ItemSubPredicate`s (`predicates`); all fields are optional.
+
+```json5
+{
+    "function": "minecraft:filtered",
+    // The custom model data value to use. This can also be a number provider.
+    "item_filter": {
+        "items": [
+            "minecraft:diamond_shovel"
+        ]
+    },
+    // The other loot function to run, as either a loot modifier file or an in-line list of functions.
+    "modifier": "examplemod:example_modifier"
+}
+```
+
+It is currently not possible to create this function during datagen.
+
+:::warning
+This function should generally be considered deprecated. Use the passed function with a `minecraft:match_tool` condition instead.
+:::
+
+## `minecraft:reference`
+
+This function references an item modifier and applies it to the result item stack. See [Item Modifiers][itemmodifiers] for more information.
+
+```json5
+{
+    "function": "minecraft:reference",
+    // Refers to the item modifier file at data/examplemod/item_modifier/example_modifier.json.
+    "name": "examplemod:example_modifier"
+}
+```
+
+During datagen, call `FunctionReference#functionReference` with the id of the referenced predicate file to construct a builder for this function.
+
+## `minecraft:sequence`
+
+This function runs other loot functions one after another.
+
+```json5
+{
+    "function": "minecraft:sequence",
+    // A list of functions to run.
+    "functions": [
+        {
+            "function": "minecraft:set_count",
+            // ...
+        },
+        {
+            "function": "minecraft:explosion_decay"
+        }
+    ],
+}
+```
+
+During datagen, call `SequenceFunction#of` with the other functions to construct a builder for this condition.
+
+## See Also
+
+- [Item Modifiers][itemmodifiers] on the [Minecraft Wiki][mcwiki]
+
+[component]: ../../client/i18n.md#components
+[conditions]: lootconditions
+[custom]: custom.md#custom-loot-functions
+[datacomponent]: ../../../items/datacomponents.md
+[entitytarget]: index.md#entity-targets
+[entry]: index.md#loot-entry
+[itemmodifiers]: https://minecraft.wiki/w/Item_modifier#JSON_format
+[mcwiki]: https://minecraft.wiki
+[nbt]: ../../../datastorage/nbt.md
+[numberprovider]: index.md#number-provider
+[pool]: index.md#loot-pool
+[table]: index.md#loot-table
diff --git a/versioned_docs/version-1.21.3/resources/server/recipes/builtin.md b/versioned_docs/version-1.21.3/resources/server/recipes/builtin.md
new file mode 100644
index 00000000..b67d15ac
--- /dev/null
+++ b/versioned_docs/version-1.21.3/resources/server/recipes/builtin.md
@@ -0,0 +1,388 @@
+# Built-In Recipe Types
+
+Minecraft provides a variety of recipe types and serializers out of the box for you to use. This article will explain each recipe type, as well as how to generate them.
+
+## Crafting
+
+Crafting recipes are typically made in crafting tables, crafters, or in modded crafting tables or machines. Their recipe type is `minecraft:crafting`.
+
+### Shaped Crafting
+
+Some of the most important recipes - such as the crafting table, sticks, or most tools - are created through shaped recipes. These recipes are defined by a crafting pattern or shape (hence "shaped") in which the items must be inserted. Let's have a look at what an example looks like:
+
+```json5
+{
+    "type": "minecraft:crafting_shaped",
+    "category": "equipment",
+    "key": {
+        "#": "minecraft:stick",
+        "X": "minecraft:iron_ingot"
+    },
+    "pattern": [
+        "XXX",
+        " # ",
+        " # "
+    ],
+    "result": {
+        "count": 1,
+        "id": "minecraft:iron_pickaxe"
+    }
+}
+```
+
+Let's digest this line for line:
+
+- `type`: This is the id of the shaped recipe serializer, `minecraft:crafting_shaped`.
+- `category`: This optional field defines the `CraftingBookCategory` in the crafting book.
+- `key` and `pattern`: Together, these define how the items must be put into the crafting grid.
+    - The pattern defines up to three lines of up to three-wide strings that define the shape. All lines must be the same length, i.e. the pattern must form a rectangular shape. Spaces can be used to denote slots that should stay empty.
+    - The key associates the characters used in the pattern with [ingredients][ingredient]. In the above example, all `X`s in the pattern must be iron ingots, and all `#`s must be sticks.
+- `result`: The result of the recipe. This is [an item stack's JSON representation][itemjson].
+- Not shown in the example is the `group` key. This optional string property creates a group in the recipe book. Recipes in the same group will be displayed as one in the recipe book.
+- Not shown in the example is `show_notification`. This optional boolean, when false, disables the toast shown on the top right hand corner on first use or unlock.
+
+And then, let's have a look at how you'd generate this recipe within `RecipeProvider#buildRecipes`:
+
+```java
+// We use a builder pattern, therefore no variable is created. Create a new builder by calling
+// ShapedRecipeBuilder#shaped with the recipe category (found in the RecipeCategory enum)
+// and a result item, a result item and count, or a result item stack.
+ShapedRecipeBuilder.shaped(this.registries.lookupOrThrow(Registries.ITEM), RecipeCategory.TOOLS, Items.IRON_PICKAXE)
+        // Create the lines of your pattern. Each call to #pattern adds a new line.
+        // Patterns will be validated, i.e. their shape will be checked.
+        .pattern("XXX")
+        .pattern(" # ")
+        .pattern(" # ")
+        // Create the keys for the pattern. All non-space characters used in the pattern must be defined.
+        // This can either accept Ingredients, TagKey<Item>s or ItemLikes, i.e. items or blocks.
+        .define('X', Items.IRON_INGOT)
+        .define('#', Items.STICK)
+        // Creates the recipe advancement. While not mandated by the consuming background systems,
+        // the recipe builder will crash if you omit this. The first parameter is the advancement name,
+        // and the second one is the condition. Normally, you want to use the has() shortcut for the condition.
+        // Multiple advancement requirements can be added by calling #unlockedBy multiple times.
+        .unlockedBy("has_iron_ingot", this.has(Items.IRON_INGOT))
+        // Stores the recipe in the passed RecipeOutput, to be written to disk.
+        // If you want to add conditions to the recipe, those can be set on the output.
+        .save(this.output);
+```
+
+Additionally, you can call `#group` and `#showNotification` to set the recipe book group and toggle the toast pop-up, respectively.
+
+### Shapeless Crafting
+
+Unlike shaped crafting recipes, shapeless crafting recipes do not care about the order the ingredients are passed in. As such, there is no pattern and key, instead there is just a list of ingredients:
+
+```json5
+{
+    "type": "minecraft:crafting_shapeless",
+    "category": "misc",
+    "ingredients": [
+        "minecraft:brown_mushroom",
+        "minecraft:red_mushroom",
+        "minecraft:bowl"
+    ],
+    "result": {
+        "count": 1,
+        "id": "minecraft:mushroom_stew"
+    }
+}
+```
+
+Like before, let's digest this line for line:
+
+- `type`: This is the id of the shapeless recipe serializer, `minecraft:crafting_shapeless`.
+- `category`: This optional field defines the category in the crafting book.
+- `ingredients`: A list of [ingredients][ingredient]. The list order is preserved in code for recipe viewing purposes, but the recipe itself accepts the ingredients in any order.
+- `result`: The result of the recipe. This is [an item stack's JSON representation][itemjson].
+- Not shown in the example is the `group` key. This optional string property creates a group in the recipe book. Recipes in the same group will be displayed as one in the recipe book.
+
+And then, let's have a look at how you'd generate this recipe in `RecipeProvider#buildRecipes`:
+
+```java
+// We use a builder pattern, therefore no variable is created. Create a new builder by calling
+// ShapelessRecipeBuilder#shapeless with the recipe category (found in the RecipeCategory enum)
+// and a result item, a result item and count, or a result item stack.
+ShapelessRecipeBuilder.shapeless(this.registries.lookupOrThrow(Registries.ITEM), RecipeCategory.MISC, Items.MUSHROOM_STEW)
+        // Add the recipe ingredients. This can either accept Ingredients, TagKey<Item>s or ItemLikes.
+        // Overloads also exist that additionally accept a count, adding the same ingredient multiple times.
+        .requires(Blocks.BROWN_MUSHROOM)
+        .requires(Blocks.RED_MUSHROOM)
+        .requires(Items.BOWL)
+        // Creates the recipe advancement. While not mandated by the consuming background systems,
+        // the recipe builder will crash if you omit this. The first parameter is the advancement name,
+        // and the second one is the condition. Normally, you want to use the has() shortcut for the condition.
+        // Multiple advancement requirements can be added by calling #unlockedBy multiple times.
+        .unlockedBy("has_mushroom_stew", this.has(Items.MUSHROOM_STEW))
+        .unlockedBy("has_bowl", this.has(Items.BOWL))
+        .unlockedBy("has_brown_mushroom", this.has(Blocks.BROWN_MUSHROOM))
+        .unlockedBy("has_red_mushroom", this.has(Blocks.RED_MUSHROOM))
+        // Stores the recipe in the passed RecipeOutput, to be written to disk.
+        // If you want to add conditions to the recipe, those can be set on the output.
+        .save(this.output);
+```
+
+Additionally, you can call `#group` to set the recipe book group.
+
+:::info
+One-item recipes (e.g. storage blocks unpacking) should be shapeless recipes to follow vanilla standards.
+:::
+
+### Transmute Crafting
+
+Transmute recipes are a special type of single item crafting recipes where the input stack's data components are completely copied to the resulting stack. Transmutations usually occur between two different items where one is the dyed version of another. For example:
+
+```json5
+{
+    "type": "minecraft:crafting_transmute",
+    "category": "misc",
+    "group": "shulker_box_dye",
+    "input": "#minecraft:shulker_boxes",
+    "material": "minecraft:blue_dye",
+    "result": "minecraft:blue_shulker_box"
+}
+```
+
+Like before, let's digest this line for line:
+
+- `type`: This is the id of the shapeless recipe serializer, `minecraft:crafting_transmute`.
+- `category`: This optional field defines the category in the crafting book.
+- `group`: This optional string property creates a group in the recipe book. Recipes in the same group will be displayed as one in the recipe book, which typically makes sense for transmuted recipes.
+- `input`: The [ingredient] to transmute.
+- `material`: The [ingredient] that transforms the stack into its result.
+- `result`: The result of the recipe. This is an item, as the stack would be constructed given the components of the input.
+
+And then, let's have a look at how you'd generate this recipe in `RecipeProvider#buildRecipes`:
+
+```java
+// We use a builder pattern, therefore no variable is created. Create a new builder by calling
+// TransmuteRecipeBuilder#transmute with the recipe category (found in the RecipeCategory enum),
+// the ingredient input, the ingredient material, and the resulting item.
+TransmuteRecipeBuilder.transmute(RecipeCategory.MISC, this.tag(ItemTags.SHULKER_BOXES),
+    Ingredient.of(DyeItem.byColor(DyeColor.BLUE)), ShulkerBoxBlock.getBlockByColor(DyeColor.BLUE).asItem())
+        // Sets the group of the recipe to display in the recipe book.
+        .group("shulker_box_dye")
+        // Creates the recipe advancement. While not mandated by the consuming background systems,
+        // the recipe builder will crash if you omit this. The first parameter is the advancement name,
+        // and the second one is the condition. Normally, you want to use the has() shortcut for the condition.
+        // Multiple advancement requirements can be added by calling #unlockedBy multiple times.
+        .unlockedBy("has_shulker_box", this.has(ItemTags.SHULKER_BOXES))
+        // Stores the recipe in the passed RecipeOutput, to be written to disk.
+        // If you want to add conditions to the recipe, those can be set on the output.
+        .save(this.output);
+```
+
+### Special Crafting
+
+In some cases, outputs must be created dynamically from inputs. Most of the time, this is to set data components on the output by calculating their values from the input stacks. These recipes usually only specify the type and hardcode everything else. For example:
+
+```json5
+{
+    "type": "minecraft:crafting_special_armordye"
+}
+```
+
+This recipe, which is for leather armor dyeing, just specifies the type and hardcodes everything else - most notably the color calculation, which would be hard to express in JSON. Minecraft prefixes most special crafting recipes with `crafting_special_`, however this practice is not necessary to follow.
+
+Generating this recipe looks as follows in `RecipeProvider#buildRecipes`:
+
+```java
+// The parameter of #special is a Function<CraftingBookCategory, Recipe<?>>.
+// All vanilla special recipes use a constructor with one CraftingBookCategory parameter for this.
+SpecialRecipeBuilder.special(ArmorDyeRecipe::new)
+        // This overload of #save allows us to specify a name. It can also be used on shaped or shapeless builders.
+        .save(this.output, "armor_dye");
+```
+
+Vanilla provides the following special crafting serializers (mods may add more):
+
+- `minecraft:crafting_special_armordye`: For dyeing leather armor and other dyeable items.
+- `minecraft:crafting_special_bannerduplicate`: For duplicating banners.
+- `minecraft:crafting_special_bookcloning`: For copying written books. This increases the resulting book's generation property by one.
+- `minecraft:crafting_special_firework_rocket`: For crafting firework rockets.
+- `minecraft:crafting_special_firework_star`: For crafting firework stars.
+- `minecraft:crafting_special_firework_star_fade`: For applying a fade to a firework star.
+- `minecraft:crafting_special_mapcloning`: For copying filled maps. Also works for treasure maps.
+- `minecraft:crafting_special_mapextending`: For extending filled maps.
+- `minecraft:crafting_special_repairitem`: For repairing two broken items into one.
+- `minecraft:crafting_special_shielddecoration`: For applying a banner to a shield.
+- `minecraft:crafting_special_shulkerboxcoloring`: For coloring a shulker box while preserving its contents.
+- `minecraft:crafting_special_tippedarrow`: For crafting tipped arrows depending on the input potion.
+- `minecraft:crafting_decorated_pot`: For crafting decorated pots from sherds.
+
+## Furnace-like Recipes
+
+The second most important group of recipes are the ones made through smelting or a similar process. All recipes made in furnaces (type `minecraft:smelting`), smokers (`minecraft:smoking`), blast furnaces (`minecraft:blasting`) and campfires (`minecraft:campfire_cooking`) use the same format:
+
+```json5
+{
+    "type": "minecraft:smelting",
+    "category": "food",
+    "cookingtime": 200,
+    "experience": 0.1,
+    "ingredient": {
+        "item": "minecraft:kelp"
+    },
+    "result": {
+        "id": "minecraft:dried_kelp"
+    }
+}
+```
+
+Let's digest this line by line:
+
+- `type`: This is the id of the recipe serializer, `minecraft:smelting`. This may be different depending on what kind of furnace-like recipe you're making.
+- `category`: This optional field defines the category in the crafting book.
+- `cookingtime`: This field determines how long the recipes needs to be processed, in ticks. All vanilla furnace recipes use 200, smokers and blast furnaces use 100, and campfires use 600. However, this can be any value you want.
+- `experience`: Determines the amount of experience rewarded when making this recipe. This field is optional, and no experience will be awarded if it is omitted.
+- `ingredient`: The input [ingredient] of the recipe.
+- `result`: The result of the recipe. This is [an item stack's JSON representation][itemjson].
+
+Datagen for these recipes looks like this in `RecipeProvider#buildRecipes`:
+
+```java
+// Use #smoking for smoking recipes, #blasting for blasting recipes, and #campfireCooking for campfire recipes.
+// All of these builders work the same otherwise.
+SimpleCookingRecipeBuilder.smelting(
+        // Our input ingredient.
+        Ingredient.of(Items.KELP),
+        // Our recipe category.
+        RecipeCategory.FOOD,
+        // Our result item. May also be an ItemStack.
+        Items.DRIED_KELP,
+        // Our experience reward
+        0.1f,
+        // Our cooking time.
+        200
+)
+        // The recipe advancement, like with the crafting recipes above.
+        .unlockedBy("has_kelp", this.has(Blocks.KELP))
+        // This overload of #save allows us to specify a name.
+        .save(this.output, "dried_kelp_smelting");
+```
+
+:::info
+The recipe type for these recipes is the same as their recipe serializer, i.e. furnaces use `minecraft:smelting`, smokers use `minecraft:smoking`, and so on.
+:::
+
+## Stonecutting
+
+Stonecutter recipes use the `minecraft:stonecutting` recipe type. They are about as simple as it gets, with only a type, an input and an output:
+
+```json5
+{
+    "type": "minecraft:stonecutting",
+    "ingredient": "minecraft:andesite",
+    "result": {
+        "count": 2,
+        "id": "minecraft:andesite_slab"
+    }
+}
+```
+
+The `type` defines the recipe serializer (`minecraft:stonecutting`). The ingredient is an [ingredient], and the result is a basic [item stack JSON][itemjson]. Like crafting recipes, they can also optionally specify a `group` for grouping in the recipe book.
+
+Datagen is also simple in `RecipeProvider#buildRecipes`:
+
+```java
+SingleItemRecipeBuilder.stonecutting(Ingredient.of(Items.ANDESITE), RecipeCategory.BUILDING_BLOCKS, Items.ANDESITE_SLAB, 2)
+        .unlockedBy("has_andesite", this.has(Items.ANDESITE))
+        .save(this.output, "andesite_slab_from_andesite_stonecutting");
+```
+
+Note that the single item recipe builder does not support actual ItemStack results, and as such, no results with data components. The recipe codec, however, does support them, so a custom builder would need to be implemented if this functionality was desired.
+
+## Smithing
+
+The smithing table supports two different recipe serializers. One is for transforming inputs into outputs, copying over the components of the input (such as enchantments), and the other is for applying components to the input. Both use the `minecraft:smithing` recipe type, and require three inputs, named the base, the template, and the addition item.
+
+### Transform Smithing
+
+This recipe serializer is for transforming two input items into one, preserving the data components of the first input. Vanilla uses this mainly for netherite equipment, however any items can be used here:
+
+```json5
+{
+  "type": "minecraft:smithing_transform",
+  "addition": "#minecraft:netherite_tool_materials",
+  "base": "minecraft:diamond_axe",
+  "result": {
+    "count": 1,
+    "id": "minecraft:netherite_axe"
+  },
+  "template": "minecraft:netherite_upgrade_smithing_template"
+}
+```
+
+Let's break this down line by line:
+
+- `type`: This is the id of the recipe serializer, `minecraft:smithing_transform`.
+- `base`: The base [ingredient] of the recipe. Usually, this is some piece of equipment.
+- `template`: The template [ingredient] of the recipe. Usually, this is a smithing template.
+- `addition`: The addition [ingredient] of the recipe. Usually, this is some sort of material, for example a netherite ingot.
+- `result`: The result of the recipe. This is [an item stack's JSON representation][itemjson].
+
+During datagen, call on `SmithingTransformRecipeBuilder#smithing` to add your recipe in `RecipeProvider#buildRecipes`:
+
+```java
+SmithingTransformRecipeBuilder.smithing(
+        // The template ingredient.
+        Ingredient.of(Items.NETHERITE_UPGRADE_SMITHING_TEMPLATE),
+        // The base ingredient.
+        Ingredient.of(Items.DIAMOND_AXE),
+        // The addition ingredient.
+        this.tag(ItemTags.NETHERITE_TOOL_MATERIALS),
+        // The recipe book category.
+        RecipeCategory.TOOLS,
+        // The result item. Note that while the recipe codec accepts an item stack here, the builder does not.
+        // If you need an item stack output, you need to use your own builder.
+        Items.NETHERITE_AXE
+)
+        // The recipe advancement, like with the other recipes above.
+        .unlocks("has_netherite_ingot", this.has(ItemTags.NETHERITE_TOOL_MATERIALS))
+        // This overload of #save allows us to specify a name.
+        .save(this.output, "netherite_axe_smithing");
+```
+
+### Trim Smithing
+
+Trim smithing is the process of applying armor trims to armor:
+
+```json5
+{
+  "type": "minecraft:smithing_trim",
+  "addition": "#minecraft:trim_materials",
+  "base": "#minecraft:trimmable_armor",
+  "template": "minecraft:bolt_armor_trim_smithing_template"
+}
+```
+
+Again, let's break this down into its bits:
+
+- `type`: This is the id of the recipe serializer, `minecraft:smithing_trim`.
+- `base`: The base [ingredient] of the recipe. All vanilla use cases use the `minecraft:trimmable_armor` tag here.
+- `template`: The template [ingredient] of the recipe. All vanilla use cases use a smithing trim template here.
+- `addition`: The addition [ingredient] of the recipe. All vanilla use cases use the `minecraft:trim_materials` tag here.
+
+This recipe serializer is notably missing a result field. This is because it uses the base input and "applies" the template and addition items on it, i.e., it sets the base's components based on the other inputs and uses the result of that operation as the recipe's result.
+
+During datagen, call on `SmithingTrimRecipeBuilder#smithingTrim` to add your recipe in `RecipeProvider#buildRecipes`:
+
+```java
+SmithingTrimRecipeBuilder.smithingTrim(
+        // The template ingredient.
+        Ingredient.of(Items.BOLT_ARMOR_TRIM_SMITHING_TEMPLATE),
+        // The base ingredient.
+        this.tag(ItemTags.TRIMMABLE_ARMOR),
+        // The addition ingredient.
+        this.tag(ItemTags.TRIM_MATERIALS),
+        // The recipe book category.
+        RecipeCategory.MISC
+)
+        // The recipe advancement, like with the other recipes above.
+        .unlocks("has_smithing_trim_template", this.has(Items.BOLT_ARMOR_TRIM_SMITHING_TEMPLATE))
+        // This overload of #save allows us to specify a name. Yes, this name is copied from vanilla.
+        .save(this.output, "bolt_armor_trim_smithing_template_smithing_trim");
+```
+
+[ingredient]: ingredients.md
+[itemjson]: ../../../items/index.md#json-representation
diff --git a/versioned_docs/version-1.21.3/resources/server/recipes/custom.md b/versioned_docs/version-1.21.3/resources/server/recipes/custom.md
new file mode 100644
index 00000000..81c34daf
--- /dev/null
+++ b/versioned_docs/version-1.21.3/resources/server/recipes/custom.md
@@ -0,0 +1,756 @@
+# Custom Recipes
+
+To add custom recipes, we need at least three things: a `Recipe`, a `RecipeType`, and a `RecipeSerializer`. Depending on what you are implementing, you may also need a custom `RecipeInput`, `RecipeDisplay`, `SlotDisplay`, `RecipeBookCategory`, and `RecipePropertySet` if reusing an existing subclass is not feasible.
+
+For the sake of example, and to highlight many different features, we are going to implement a recipe-driven mechanic that requires you to right-click a `BlockState` in-world with a certain item, breaking the `BlockState` and dropping the result item.
+
+## The Recipe Input
+
+Let's begin by defining what we want to put into the recipe. It's important to understand that the recipe input represents the actual inputs that the player is using right now. As such, we don't use tags or ingredients here, instead we use the actual item stacks and blockstates we have available.
+
+```java
+// Our inputs are a BlockState and an ItemStack.
+public record RightClickBlockInput(BlockState state, ItemStack stack) implements RecipeInput {
+    // Method to get an item from a specific slot. We have one stack and no concept of slots, so we just assume
+    // that slot 0 holds our item, and throw on any other slot. (Taken from SingleRecipeInput#getItem.)
+    @Override
+    public ItemStack getItem(int slot) {
+        if (slot != 0) throw new IllegalArgumentException("No item for index " + slot);
+        return this.stack();
+    }
+
+    // The slot size our input requires. Again, we don't really have a concept of slots, so we just return 1
+    // because we have one item stack involved. Inputs with multiple items should return the actual count here.
+    @Override
+    public int size() {
+        return 1;
+    }
+}
+```
+
+Recipe inputs don't need to be registered or serialized in any way because they are created on demand. It is not always necessary to create your own, the vanilla ones (`CraftingInput`, `SingleRecipeInput` and `SmithingRecipeInput`) are fine for many use cases.
+
+Additionally, NeoForge provides the `RecipeWrapper` input, which wraps the `#getItem` and `#size` calls with respect to an `IItemHandler` passed in the constructor. Basically, this means that any grid-based inventory, such as a chest, can be used as a recipe input by wrapping it in a `RecipeWrapper`.
+
+## The Recipe Class
+
+Now that we have our inputs, let's get to the recipe itself. This is what holds our recipe data, and also handles matching and returning the recipe result. As such, it is usually the longest class for your custom recipe.
+
+```java
+// The generic parameter for Recipe<T> is our RightClickBlockInput from above.
+public class RightClickBlockRecipe implements Recipe<RightClickBlockInput> {
+    // An in-code representation of our recipe data. This can be basically anything you want.
+    // Common things to have here is a processing time integer of some kind, or an experience reward.
+    // Note that we now use an ingredient instead of an item stack for the input.
+    private final BlockState inputState;
+    private final Ingredient inputItem;
+    private final ItemStack result;
+
+    // Add a constructor that sets all properties. 
+    public RightClickBlockRecipe(BlockState inputState, Ingredient inputItem, ItemStack result) {
+        this.inputState = inputState;
+        this.inputItem = inputItem;
+        this.result = result;
+    }
+
+    // Check whether the given input matches this recipe. The first parameter matches the generic.
+    // We check our blockstate and our item stack, and only return true if both match.
+    // If we needed to check the dimensions of our input, we would also do so here.
+    @Override
+    public boolean matches(RightClickBlockInput input, Level level) {
+        return this.inputState == input.state() && this.inputItem.test(input.stack());
+    }
+
+    // Return the result of the recipe here, based on the given input. The first parameter matches the generic.
+    // IMPORTANT: Always call .copy() if you use an existing result! If you don't, things can and will break,
+    // as the result exists once per recipe, but the assembled stack is created each time the recipe is crafted.
+    @Override
+    public ItemStack assemble(RightClickBlockInput input, HolderLookup.Provider registries) {
+        return this.result.copy();
+    }
+
+    // When true, will prevent the recipe from being synced within the recipe book or awarded on use/unlock.
+    // This should only be true if the recipe shouldn't appear in a recipe book, such as map extending.
+    // Although this recipe takes in an input state, it could still be used in a custom recipe book using
+    //   the methods below.
+    @Override
+    public boolean isSpecial() {
+        return true;
+    }
+
+    // This example outlines the most important methods. There is a number of other methods to override.
+    // Some methods will be explained in the below sections as they cannot be easily compressed and understood here.
+    // Check the class definition of Recipe to view them all.
+}
+```
+
+## Recipe Book Categories
+
+A `RecipeBookCategory` simply defines a group to display this recipe within in a recipe book. For example, an iron pickaxe crafting recipe would show up in the `RecipeBookCategories#CARFTING_EQUIPMENT` while a cooked cod recipe would show up in `#FURNANCE_FOOD` or `#SMOKER_FOOD`. Each recipe has one associated `RecipeBookCategory`. The vanilla categories can be found in `RecipeBookCategories`.
+
+:::note
+There are two cooked cod recipes, one for the furnance and one for the smoker. The furnace and smoker recipes have different book categories.
+:::
+
+If your recipe does not fit into one of the existing categories, typically because the recipe does not use one of the existing crafting stations (e.g., crafting table, furnace), then a new `RecipeBookCategory` can be created. Each `RecipeBookCategory` must be [registered][registry] to `BuiltInRegistries#RECIPE_BOOK_CATEGORY`:
+
+```java
+/// For some DeferredRegister<RecipeBookCategory> RECIPE_BOOK_CATEGORIES
+public static final Supplier<RecipeBookCategory> RIGHT_CLICK_BLOCK_CATEGORY = RECIPE_BOOK_CATEGORIES.register(
+    "right_click_block", RecipeBookCategory::new
+);
+```
+
+Then, to set the category, we must override `#recipeBookCategory` like so:
+
+```java
+public class RightClickBlockRecipe implements Recipe<RightClickBlockInput> {
+    // other stuff here
+
+    @Override
+    public RecipeBookCategory recipeBookCategory() {
+        return RIGHT_CLICK_BLOCK_CATEGORY.get();
+    }
+}
+```
+
+### Search Categories
+
+All `RecipeBookCategory`s are technically `ExtendedRecipeBookCategory`s. There is another type of `ExtendedRecipeBookCategory` called `SearchRecipeBookCategory`, which is used to aggregate `RecipeBookCategory`s when viewing all recipes in a recipe book.
+
+NeoForge allows users to specify their own `ExtendedRecipeBookCategory` as a search category via `RegisterRecipeBookSearchCategoriesEvent#register` on the mod event bus. `register` takes in the `ExtendedRecipeBookCategory` representing the search category and the `RecipeBookCategory`s that make up that search category. The `ExtendedRecipeBookCategory` search category does not need to be registered to some static vanilla registry.
+
+```java
+// In some location
+public static final ExtendedRecipeBookCategory RIGHT_CLICK_BLOCK_SEARCH_CATEGORY = new ExtendedRecipeBookCategory() {};
+
+// On the mod event bus
+@SubscribeEvent
+public static void registerSearchCategories(RegisterRecipeBookSearchCategoriesEvent event) {
+    event.register(
+        // The search category
+        RIGHT_CLICK_BLOCK_SEARCH_CATEGORY,
+        // All recipe categories within the search category as varargs
+        RIGHT_CLICK_BLOCK_CATEGORY.get()
+    )
+}
+```
+
+## Placement Info
+
+A `PlacementInfo` is meant to define the crafting requirements used by the recipe consumer and whether/how it can be placed into its associated crafting station (e.g., crafting table, furnace). `PlacementInfo` are only meant for item ingredients, so if other types of ingredients are desired (e.g., fluid, block), the surrounding logic will need to be implemented from scratch. In these cases, the recipe can be labelled as not placeable, and say as such via `PlacementInfo#NOT_PLACEABLE`. However, if there is at least one item-like object in your recipe, you should create a `PlacementInfo`.
+
+A `PlacementInfo` can be created via `create`, which takes in one or a list of ingredient, or `createFromOptionals`, which takes in a list of optional ingredients. If your recipe contains some representation of empty slots, then `createFromOptionals` should be used, providing an empty optional for an empty slot:
+
+```java
+public class RightClickBlockRecipe implements Recipe<RightClickBlockInput> {
+    // other stuff here
+    private PlacementInfo info;
+
+    @Override
+    public PlacementInfo placementInfo() {
+        // This delegate is in case the ingredient is not fully populated at this point in time
+        // Tags and recipes are loaded at the same time, which is why this might be the case.
+        if (this.info == null) {
+            // Use optional ingredient as the block state may have an item representation
+            List<Optional<Ingredient>> ingredients = new ArrayList<>();
+            Item stateItem = this.inputState.getBlock().asItem();
+            ingredients.add(stateItem != Items.AIR ? Optional.of(Ingredient.of(stateItem)): Optional.empty());
+            ingredients.add(Optional.of(this.inputItem));
+
+            // Create placement info
+            this.info = PlacementInfo.createFromOptionals(ingredients);
+        }
+
+        return this.info;
+    }
+}
+```
+
+## Slot Displays
+
+`SlotDisplay`s represent the information on what should render in what slot when viewed by a recipe consumer, like a recipe book. A `SlotDisplay` has two methods. First there's `resolve`, which takes in the `ContextMap` containing the available registries and fuel values (as shown in `SlotDisplayContext`); and the current `DisplayContentsFactory`, which accepts the contents to display for this slot; and returns the transformed list of contents into the output to be accepted. Then there's `type`, which holds the [`MapCodec`][codec] and [`StreamCodec`][streamcodec] used to encode/decode the display.
+
+`SlotDisplay`s are typically implemented on the [`Ingredient` via `#display`, or `ICustomIngredient#display` for modded ingredients][ingredients]; however, in some cases, the input may not be an ingredient, meaning a `SlotDisplay` will need to use one available, or have a new one created.
+
+These are the available slot displays provided by Vanilla and NeoForge:
+
+- `SlotDisplay.Empty`: A slot that represents nothing.
+- `SlotDisplay.ItemSlotDisplay`: A slot that respresents an item.
+- `SlotDisplay.ItemStackSlotDisplay`: A slot that represents an item stack.
+- `SlotDisplay.TagSlotDisplay`: A slot that represents an item tag.
+- `SlotDisplay.WithRemainder`: A slot that represents some input that has some crafting remainder.
+- `SlotDisplay.AnyFuel`: A slot that represents all fuel items.
+- `SlotDisplay.Composite`: A slot that represents a combination of other slot displays.
+- `SlotDisplay.SmithingTrimDemoSlotDisplay`: A slot that represents a random smithing drim being applied to some base with the given material.
+- `FluidSlotDisplay`: A slot that represents a fluid.
+- `FluidStackSlotDisplay`: A slot that represents a fluid stack.
+- `FluidTagSlotDisplay`: A slot that represents a fluid tag.
+
+We have three 'slots' in our recipe: the `BlockState` input, the `Ingredient` input, and the `ItemStack` result. The `Ingredient` input will already have an associated `SlotDisplay` and the `ItemStack` can be represented by `SlotDisplay.ItemStackSlotDisplay`. The `BlockState`, on the other hand, will need its own custom `SlotDisplay` and `DisplayContentsFactory`, as existing ones only take in item stacks, and for this example, block states are handled in a different fashion.
+
+Starting with the `DisplayContentsFactory`, it is meant to be a transformer for some type to desired content display type. The available factories are:
+
+- `DisplayContentsFactory.ForStacks`: A transformer that takes in `ItemStack`s.
+- `DisplayContentsFactory.ForRemainders`: A transformer that takes in the input object and a list of remainder objects.
+- `DisplayContentsFactory.ForFluidStacks`: A transformer that takes in a `FluidStack`.
+
+With this, the `DisplayContentsFactory` can be implemented to transform the provided objects into the desired output. For example, `SlotDisplay.ItemStackContentsFactory`, takes the `ForStacks` transformer and has the stacks transformed into `ItemStack`s.
+
+For our `BlockState`, we'll create a factory that takes in the state, along with a basic implementation that outputs the state itself.
+
+```java
+// A basic transformer for block states
+public interface ForBlockStates<T> extends DisplayContentsFactory<T> {
+
+    // Delegate methods
+    default forState(Holder<Block> block) {
+        return this.forState(block.value());
+    }
+
+    default forState(Block block) {
+        return this.forState(block.defaultBlockState());
+    }
+
+    // The block state to take in and transform to the desired output
+    T forState(BlockState state);
+}
+
+// An implementation for a block state output
+public class BlockStateContentsFactory implements ForBlockStates<BlockState> {
+    // Singleton instance
+    public static final BlockStateContentsFactory INSTANCE = new BlockStateContentsFactory();
+
+    private BlockStateContentsFactory() {}
+
+    @Override
+    public BlockState forState(BlockState state) {
+        return state;
+    }
+}
+
+// An implementation for an item stack output
+public class BlockStateStackContentsFactory implements ForBlockStates<ItemStack> {
+    // Singleton instance
+    public static final BlockStateStackContentsFactory INSTANCE = new BlockStateStackContentsFactory();
+
+    private BlockStateStackContentsFactory() {}
+
+    @Override
+    public ItemStack forState(BlockState state) {
+        return new ItemStack(state.getBlock());
+    }
+}
+```
+
+Then, with that, we can create a new `SlotDisplay`. The `SlotDisplay.Type` must be [registered][registry]:
+
+```java
+// A simple slot display
+public record BlockStateSlotDisplay(BlockState state) implements SlotDisplay {
+    public static final MapCodec<BlockStateSlotDisplay> CODEC = BlockState.CODEC.fieldOf("state")
+        .xmap(BlockStateSlotDisplay::new, BlockStateSlotDisplay::state);
+    public static final StreamCodec<RegistryFriendlyByteBuf, BlockStateSlotDisplay> STREAM_CODEC =
+        StreamCodec.composite(
+            ByteBufCodecs.idMapper(Block.BLOCK_STATE_REGISTRY), BlockStateSlotDisplay::state,
+            BlockStateSlotDisplay::new
+        );
+    
+    @Override
+    public <T> Stream<T> resolve(ContextMap context, DisplayContentsFactory<T> factory) {
+        return switch (factory) {
+            // Check for our contents factory and transform if necessary
+            case ForBlockStates<T> states -> Stream.of(states.forState(this.state));
+            // If you want the contents to be handled differently depending on contents display
+            //   then you can case on other displays like so
+            case ForStacks<T> stacks -> Stream.of(stacks.forStack(state.getBlock().asItem()));
+            // If no factories match, then do not return anything in the transformed stream
+            default -> Stream.empty();
+        }
+    }
+
+    @Override
+    public SlotDisplay.Type<? extends SlotDisplay> type() {
+        // Return the registered type from below
+        return BLOCK_STATE_SLOT_DISPLAY.get();
+    }
+}
+
+// In some registrar class
+/// For some DeferredRegister<SlotDisplay.Type<?>> SLOT_DISPLAY_TYPES
+public static final Supplier<SlotDisplay.Type<BlockStateSlotDisplay>> BLOCK_STATE_SLOT_DISPLAY = SLOT_DISPLAY_TYPES.register(
+    "block_state",
+    () -> new SlotDisplay.Type<>(BlockStateSlotDisplay.CODEC, BlockStateSlotDisplay.STREAM_CODEC)
+);
+```
+
+## Recipe Display
+
+A `RecipeDisplay` is the same as a `SlotDisplay`, except that it represents an entire recipe. The default interface only keeps track of the `result` of recipe and the `craftingStation` which represents the workbench where the recipe is applied. The `RecipeDisplay` also has a `type` that holds the [`MapCodec`][codec] and [`StreamCodec`][streamcodec] used to encode/decode the display. However, no available subtypes of `RecipeDisplay` contain all the information required to properly render our recipe on the client. As such, we will need to create our own `RecipeDisplay`.
+
+All slots and ingredients should be represented as `SlotDisplay`s. Any restrictions, such as grid size, can be provided in any manner the user decides.
+
+```java
+// A simple recipe display
+public record RightClickBlockRecipeDisplay(
+    SlotDisplay inputState,
+    SlotDisplay inputItem,
+    SlotDisplay result, // Implements RecipeDisplay#result
+    SlotDisplay craftingStation // Implements RecipeDisplay#craftingStation
+) implements RecipeDisplay {
+    public static final MapCodec<RightClickBlockRecipeDisplay> MAP_CODEC = RecordCodecBuilder.mapCodec(
+        instance -> instance.group(
+                    SlotDisplay.CODEC.fieldOf("inputState").forGetter(RightClickBlockRecipeDisplay::inputState),
+                    SlotDisplay.CODEC.fieldOf("inputState").forGetter(RightClickBlockRecipeDisplay::inputItem),
+                    SlotDisplay.CODEC.fieldOf("result").forGetter(RightClickBlockRecipeDisplay::result),
+                    SlotDisplay.CODEC.fieldOf("crafting_station").forGetter(RightClickBlockRecipeDisplay::craftingStation)
+                )
+                .apply(instance, RightClickBlockRecipeDisplay::new)
+    );
+    public static final StreamCodec<RegistryFriendlyByteBuf, RightClickBlockRecipeDisplay> STREAM_CODEC = StreamCodec.composite(
+        SlotDisplay.STREAM_CODEC,
+        RightClickBlockRecipeDisplay::inputState,
+        SlotDisplay.STREAM_CODEC,
+        RightClickBlockRecipeDisplay::inputItem,
+        SlotDisplay.STREAM_CODEC,
+        RightClickBlockRecipeDisplay::result,
+        SlotDisplay.STREAM_CODEC,
+        RightClickBlockRecipeDisplay::craftingStation,
+        RightClickBlockRecipeDisplay::new
+    );
+
+    @Override
+    public RecipeDisplay.Type<? extends RecipeDisplay> type() {
+        // Return the registered type from below
+        return RIGHT_CLICK_BLOCK_RECIPE_DISPLAY.get();
+    }
+}
+
+// In some registrar class
+/// For some DeferredRegister<RecipeDisplay.Type<?>> RECIPE_DISPLAY_TYPES
+public static final Supplier<RecipeDisplay.Type<RightClickBlockRecipeDisplay>> RIGHT_CLICK_BLOCK_RECIPE_DISPLAY = RECIPE_DISPLAY_TYPES.register(
+    "right_click_block",
+    () -> new RecipeDisplay.Type<>(RightClickBlockRecipeDisplay.CODEC, RightClickBlockRecipeDisplay.STREAM_CODEC)
+);
+```
+
+Then we can create the recipe display for the recipe by overriding `#display` like so:
+
+```java
+public class RightClickBlockRecipe implements Recipe<RightClickBlockInput> {
+    // other stuff here
+
+    @Override
+    public List<RecipeDisplay> display() {
+        // You can have many different displays for the same recipe
+        // But this example will only use one like the other recipes.
+        return List.of(
+            // Add our recipe display with the specified slots
+            new RightClickBlockRecipeDisplay(
+                new BlockStateSlotDisplay(this.inputState),
+                this.inputItem.display(),
+                new SlotDisplay.ItemStackSlotDisplay(this.result),
+                new SlotDisplay.ItemSlotDisplay(Items.GRASS_BLOCK)
+            )
+        )
+    }
+}
+```
+
+## The Recipe Type
+
+Next up, our recipe type. This is fairly straightforward because there's no data other than a name associated with a recipe type. They are one of two [registered][registry] parts of the recipe system, so like with all other registries, we create a `DeferredRegister` and register to it:
+
+```java
+public static final DeferredRegister<RecipeType<?>> RECIPE_TYPES =
+        DeferredRegister.create(Registries.RECIPE_TYPE, ExampleMod.MOD_ID);
+
+public static final Supplier<RecipeType<RightClickBlockRecipe>> RIGHT_CLICK_BLOCK_TYPE =
+        RECIPE_TYPES.register(
+                "right_click_block",
+                // We need the qualifying generic here due to generics being generics.
+                registryName -> new RecipeType<RightClickBlockRecipe> {
+
+                    @Override
+                    public String toString() {
+                        return registryName.toString();
+                    }
+                }
+        );
+```
+
+After we have registered our recipe type, we must override `#getType` in our recipe, like so:
+
+```java
+public class RightClickBlockRecipe implements Recipe<RightClickBlockInput> {
+    // other stuff here
+
+    @Override
+    public RecipeType<? extends Recipe<RightClickBlockInput>> getType() {
+        return RIGHT_CLICK_BLOCK_TYPE.get();
+    }
+}
+```
+
+## The Recipe Serializer
+
+A recipe serializer provides two codecs, one map codec and one stream codec, for serialization from/to JSON and from/to network, respectively. This section will not go in depth about how the codecs work, please see [Map Codecs][codec] and [Stream Codecs][streamcodec] for more information.
+
+Since recipe serializers can get fairly large, vanilla moves them to separate classes. It is recommended, but not required to follow the practice - smaller serializers are often defined in anonymous classes within fields of the recipe class. To follow good practice, we will create a separate class that holds our codecs:
+
+```java
+// The generic parameter is our recipe class.
+// Note: This assumes that simple RightClickBlockRecipe#getInputState, #getInputItem and #getResult getters
+// are available, which were omitted from the code above.
+public class RightClickBlockRecipeSerializer implements RecipeSerializer<RightClickBlockRecipe> {
+    public static final MapCodec<RightClickBlockRecipe> CODEC = RecordCodecBuilder.mapCodec(inst -> inst.group(
+            BlockState.CODEC.fieldOf("state").forGetter(RightClickBlockRecipe::getInputState),
+            Ingredient.CODEC.fieldOf("ingredient").forGetter(RightClickBlockRecipe::getInputItem),
+            ItemStack.CODEC.fieldOf("result").forGetter(RightClickBlockRecipe::getResult)
+    ).apply(inst, RightClickBlockRecipe::new));
+    public static final StreamCodec<RegistryFriendlyByteBuf, RightClickBlockRecipe> STREAM_CODEC =
+            StreamCodec.composite(
+                    ByteBufCodecs.idMapper(Block.BLOCK_STATE_REGISTRY), RightClickBlockRecipe::getInputState,
+                    Ingredient.CONTENTS_STREAM_CODEC, RightClickBlockRecipe::getInputItem,
+                    ItemStack.STREAM_CODEC, RightClickBlockRecipe::getResult,
+                    RightClickBlockRecipe::new
+            );
+
+    // Return our map codec.
+    @Override
+    public MapCodec<RightClickBlockRecipe> codec() {
+        return CODEC;
+    }
+
+    // Return our stream codec.
+    @Override
+    public StreamCodec<RegistryFriendlyByteBuf, RightClickBlockRecipe> streamCodec() {
+        return STREAM_CODEC;
+    }
+}
+```
+
+Like with the type, we register our serializer:
+
+```java
+public static final DeferredRegister<RecipeType<?>> RECIPE_SERIALIZERS =
+        DeferredRegister.create(Registries.RECIPE_SERIALIZER, ExampleMod.MOD_ID);
+
+public static final Supplier<RecipeSerializer<RightClickBlockRecipe>> RIGHT_CLICK_BLOCK =
+        RECIPE_SERIALIZERS.register("right_click_block", RightClickBlockRecipeSerializer::new);
+```
+
+And similarly, we must also override `#getSerializer` in our recipe, like so:
+
+```java
+public class RightClickBlockRecipe implements Recipe<RightClickBlockInput> {
+    // other stuff here
+
+    @Override
+    public RecipeSerializer<? extends Recipe<RightClickBlockInput>> getSerializer() {
+        return RIGHT_CLICK_BLOCK.get();
+    }
+}
+```
+
+## The Crafting Mechanic
+
+Now that all parts of your recipe are complete, you can make yourself some recipe JSONs (see the [datagen] section for that) and then query the recipe manager for your recipes, like above. What you then do with the recipe is up to you. A common use case would be a machine that can process your recipes, storing the active recipe as a field.
+
+In our case, however, we want to apply the recipe when an item is right-clicked on a block. We will do so using an [event handler][event]. Keep in mind that this is an example implementation, and you can alter this in any way you like (so long as you run it on the server). As we want the interaction state to match on both the client and server, we will also need to [sync any relevant input states across the network][networking].
+
+We can set up a simple network implementation to sync the recipe inputs like so:
+
+```java
+// A basic packet class, must be registered.
+public record ClientboundRightClickBlockRecipesPayload(
+    Set<BlockState> inputStates, Set<Holder<Item>> inputItems
+) implements CustomPacketPayload {
+
+    // ...
+}
+
+// Packet stores data in an instance class.
+// Present on both server and client to do initial matching.
+public interface RightClickBlockRecipeInputs {
+
+    Set<BlockState> inputStates();
+    Set<Holder<Item>> inputItems();
+
+    default boolean test(BlockState state, ItemStack stack) {
+        return this.inputStates().contains(state) && this.inputItems().contains(stack.getItemHolder());
+    }
+}
+
+// Server resource listener so it can be reloaded when recipes are.
+public class ServerRightClickBlockRecipeInputs implements ResourceManagerReloadListener, RightClickBlockRecipeInputs {
+
+    private final RecipeManager recipeManager;
+
+    private Set<BlockState> inputStates;
+    private Set<Holder<Item>> inputItems;
+
+    public RightClickBlockRecipeInputs(RecipeManager recipeManager) {
+        this.recipeManager = recipeManager;
+    }
+
+    // Set inputs here as #apply is fired synchronously based on listener registration order.
+    // Recipes are always applied first.
+    @Override
+    public void onResourceManagerReload(ResourceManager manager) {
+        MinecraftServer server = ServerLifecycleHooks.getCurrentServer();
+        if (server != null) { // Should never be null
+            // Populate inputs
+            Set<BlockState> inputStates = new HashSet<>();
+            Set<Holder<Item>> inputItems = new HashSet<>();
+
+            this.recipeManager.recipeMap().byType(RIGHT_CLICK_BLOCK_TYPE.get())
+                .forEach(holder -> {
+                    var recipe = holder.value();
+                    inputStates.add(recipe.getInputState());
+                    inputItems.addAll(recipe.getInputItem().items());
+                });
+            
+            this.inputStates = Set.unmodifiableSet(inputStates);
+            this.inputItems = Set.unmodifiableSet(inputItems);
+        }
+    }
+
+    public void syncToClient(Stream<ServerPlayer> players) {
+        ClientboundRightClickBlockRecipesPayload payload =
+            new ClientboundRightClickBlockRecipesPayload(this.inputStates, this.inputItems);
+        players.forEach(player -> PacketDistributor.sendToPlayer(player, payload));
+    }
+
+    @Override
+    public Set<BlockState> inputStates() {
+        return this.inputStates;
+    }
+
+    @Override
+    public Set<Holder<Item>> inputItems() {
+        return this.inputItems;
+    }
+}
+
+// Client implementation to hold the inputs.
+public record ClientRightClickBlockRecipeInputs(
+    Set<BlockState> inputStates, Set<Holder<Item>> inputItems
+) implements RightClickBlockRecipeInputs {
+
+    public ClientRightClickBlockRecipeInputs(Set<BlockState> inputStates, Set<Holder<Item>> inputItems) {
+        this.inputStates = Set.unmodifiableSet(inputStates);
+        this.inputItems = Set.unmodifiableSet(inputItems);
+    }
+}
+
+// Handling the recipe instance depending on side.
+public class ServerRightClickBlockRecipes {
+
+    private static ServerRightClickBlockRecipeInputs inputs;
+
+    public static RightClickBlockRecipeInputs inputs() {
+        return ServerRightClickBlockRecipes.inputs;
+    }
+
+    // On the game event bus
+    @SubscribeEvent
+    public static void addListener(AddReloadListenerEvent event) {
+        // Register server reload listener
+        ServerRightClickBlockRecipes.inputs = new ServerRightClickBlockRecipeInputs(
+            event.getServerResources().getRecipeManager()
+        );
+        event.addListener(ServerRightClickBlockRecipes.inputs);
+    }
+
+    // On the game event bus
+    @SubscribeEvent
+    public static void datapackSync(OnDatapackSyncEvent event) {
+        // Send to client
+        ServerRightClickBlockRecipes.inputs.syncToClient(event.getRelevantPlayers());
+    }
+}
+public class ClientRightClickBlockRecipes {
+
+    private static ClientRightClickBlockRecipeInputs inputs;
+
+    public static RightClickBlockRecipeInputs inputs() {
+        return ClientRightClickBlockRecipes.inputs;
+    }
+
+    // Handling the sent packet
+    public static void handle(final ClientboundRightClickBlockRecipesPayload data, final IPayloadContext context) {
+        // Do something with the data, on the main thread
+        ClientRightClickBlockRecipes.inputs = new ClientRightClickBlockRecipeInputs(
+            data.inputStates(), data.inputItems()
+        );
+    }
+}
+
+public class RightClickBlockRecipes {
+    // Make proxy method to access properly
+    public static RightClickBlockRecipeInputs inputs(Level level) {
+        return level.isClientSide
+            ? ClientRightClickBlockRecipes.inputs()
+            : ServerRightClickBlockRecipes.inputs();
+    }
+}
+```
+
+Then, using the synced inputs, we can check the game for the used inputs:
+
+```java
+// On the game event bus
+@SubscribeEvent
+public static void useItemOnBlock(UseItemOnBlockEvent event) {
+    // Skip if we are not in the block-dictated phase of the event. See the event's javadocs for details.
+    if (event.getUsePhase() != UseItemOnBlockEvent.UsePhase.BLOCK) return;
+    // Get parameters to check input first
+    Level level = event.getLevel();
+    BlockPos pos = event.getPos();
+    BlockState blockState = level.getBlockState(pos);
+    ItemStack itemStack = event.getItemStack();
+
+    // Check if the input can result in a recipe on both sides
+    if (!RightClickBlockRecipes.inputs(level).test(blockState, itemStack)) return;
+
+    // If so, make sure on server before checking recipe
+    if (!level.isClientSide() && level instanceof ServerLevel serverLevel) {
+        // Create an input and query the recipe.
+        RightClickBlockInput input = new RightClickBlockInput(blockState, itemStack);
+        Optional<RecipeHolder<? extends Recipe<CraftingInput>>> optional = serverLevel.recipeAccess().getRecipeFor(
+            // The recipe type.
+            RIGHT_CLICK_BLOCK_TYPE.get(),
+            input,
+            level
+        );
+        ItemStack result = optional
+            .map(RecipeHolder::value)
+            .map(e -> e.assemble(input, level.registryAccess()))
+            .orElse(ItemStack.EMPTY);
+        
+        // If there is a result, break the block and drop the result in the world.
+        if (!result.isEmpty()) {
+            level.removeBlock(pos, false);
+            ItemEntity entity = new ItemEntity(level,
+                    // Center of pos.
+                    pos.getX() + 0.5, pos.getY() + 0.5, pos.getZ() + 0.5,
+                    result);
+            level.addFreshEntity(entity);
+        }
+    }
+
+    // Cancel the event to stop the interaction pipeline regardless of side.
+    // Already made sure that there could be a result.
+    event.cancelWithResult(InteractionResult.SUCCESS_SERVER);
+}
+```
+
+## Data Generation
+
+To create a recipe builder for your own recipe serializer(s), you need to implement `RecipeBuilder` and its methods. A common implementation, partially copied from vanilla, would look like this:
+
+```java
+// This class is abstract because there is a lot of per-recipe-serializer logic.
+// It serves the purpose of showing the common part of all (vanilla) recipe builders.
+public abstract class SimpleRecipeBuilder implements RecipeBuilder {
+    // Make the fields protected so our subclasses can use them.
+    protected final ItemStack result;
+    protected final Map<String, Criterion<?>> criteria = new LinkedHashMap<>();
+    @Nullable
+    protected final String group;
+
+    // It is common for constructors to accept the result item stack.
+    // Alternatively, static builder methods are also possible.
+    public SimpleRecipeBuilder(ItemStack result) {
+        this.result = result;
+    }
+
+    // This method adds a criterion for the recipe advancement.
+    @Override
+    public SimpleRecipeBuilder unlockedBy(String name, Criterion<?> criterion) {
+        this.criteria.put(name, criterion);
+        return this;
+    }
+
+    // This method adds a recipe book group. If you do not want to use recipe book groups,
+    // remove the this.group field and make this method no-op (i.e. return this).
+    @Override
+    public SimpleRecipeBuilder group(@Nullable String group) {
+        this.group = group;
+        return this;
+    }
+
+    // Vanilla wants an Item here, not an ItemStack. You still can and should use the ItemStack
+    // for serializing the recipes.
+    @Override
+    public Item getResult() {
+        return this.result.getItem();
+    }
+}
+```
+
+So we have a base for our recipe builder. Now, before we continue with the recipe serializer-dependent part, we should first consider what to make our recipe factory. In our case, it makes sense to use the constructor directly. In other situations, using a static helper or a small functional interface is the way to go. This is especially relevant if you use one builder for multiple recipe classes.
+
+Utilizing `RightClickBlockRecipe::new` as our recipe factory, and reusing the `SimpleRecipeBuilder` class above, we can create the following recipe builder for `RightClickBlockRecipe`s:
+
+```java
+public class RightClickBlockRecipeBuilder extends SimpleRecipeBuilder {
+    private final BlockState inputState;
+    private final Ingredient inputItem;
+
+    // Since we have exactly one of each input, we pass them to the constructor.
+    // Builders for recipe serializers that have ingredient lists of some sort would usually
+    // initialize an empty list and have #addIngredient or similar methods instead.
+    public RightClickBlockRecipeBuilder(ItemStack result, BlockState inputState, Ingredient inputItem) {
+        super(result);
+        this.inputState = inputState;
+        this.inputItem = inputItem;
+    }
+
+    // Saves a recipe using the given RecipeOutput and key. This method is defined in the RecipeBuilder interface.
+    @Override
+    public void save(RecipeOutput output, ResourceKey<Recipe<?>> key) {
+        // Build the advancement.
+        Advancement.Builder advancement = output.advancement()
+                .addCriterion("has_the_recipe", RecipeUnlockedTrigger.unlocked(key))
+                .rewards(AdvancementRewards.Builder.recipe(key))
+                .requirements(AdvancementRequirements.Strategy.OR);
+        this.criteria.forEach(advancement::addCriterion);
+        // Our factory parameters are the result, the block state, and the ingredient.
+        RightClickBlockRecipe recipe = new RightClickBlockRecipe(this.inputState, this.inputItem, this.result);
+        // Pass the id, the recipe, and the recipe advancement into the RecipeOutput.
+        output.accept(key, recipe, advancement.build(key.location().withPrefix("recipes/")));
+    }
+}
+```
+
+And now, during [datagen][recipedatagen], you can call on your recipe builder like any other:
+
+```java
+@Override
+protected void buildRecipes(RecipeOutput output) {
+    new RightClickRecipeBuilder(
+            // Our constructor parameters. This example adds the ever-popular dirt -> diamond conversion.
+            new ItemStack(Items.DIAMOND),
+            Blocks.DIRT.defaultBlockState(),
+            Ingredient.of(Items.APPLE)
+    )
+            .unlockedBy("has_apple", this.has(Items.APPLE))
+            .save(output);
+    // other recipe builders here
+}
+```
+
+:::note
+It is also possible to have `SimpleRecipeBuilder` be merged into `RightClickBlockRecipeBuilder` (or your own recipe builder), especially if you only have one or two recipe builders. The abstraction here serves to show which parts of the builder are recipe-dependent and which are not.
+:::
+
+[codec]: ../../../datastorage/codecs.md
+[datagen]: #data-generation
+[event]: ../../../concepts/events.md
+[ingredients]: ingredients.md
+[networking]: ../../../networking/payload.md
+[recipedatagen]: index.md#data-generation
+[registry]: ../../../concepts/registries.md#methods-for-registering
+[streamcodec]: ../../../networking/streamcodecs.md
diff --git a/versioned_docs/version-1.21.3/resources/server/recipes/index.md b/versioned_docs/version-1.21.3/resources/server/recipes/index.md
new file mode 100644
index 00000000..c5a0760d
--- /dev/null
+++ b/versioned_docs/version-1.21.3/resources/server/recipes/index.md
@@ -0,0 +1,218 @@
+# Recipes
+
+Recipes are a way to transform a set of objects into other objects within a Minecraft world. Although Minecraft uses this system purely for item transformations, the system is built in a way that allows any kind of objects - blocks, entities, etc. - to be transformed. Almost all recipes use recipe data files; a "recipe" is assumed to be a data-driven recipe in this article unless explicitly stated otherwise.
+
+Recipe data files are located at `data/<namespace>/recipe/<path>.json`. For example, the recipe `minecraft:diamond_block` is located at `data/minecraft/recipe/diamond_block.json`.
+
+## Terminology
+
+- A **recipe JSON**, or **recipe file**, is a JSON file that is loaded and stored by the `RecipeManager`. It contains info such as the recipe type, the inputs and outputs, as well as additional information (e.g. processing time).
+- A **`Recipe`** holds in-code representations of all JSON fields, alongside the matching logic ("Does this input match the recipe?") and some other properties.
+- A **`RecipeInput`** is a type that provides inputs to a recipe. Comes in several subclasses, e.g. `CraftingInput` or `SingleRecipeInput` (for furnaces and similar).
+- A **recipe ingredient**, or just **ingredient**, is a single input for a recipe (whereas the `RecipeInput` generally represents a collection of inputs to check against a recipe's ingredients). Ingredients are a very powerful system and as such outlined [in their own article][ingredients].
+- A **`PlacementInfo`** is a definition of items the recipe contains and what indexes they should populate. If the recipe cannot be captured to some degree based on the items provided (e.g., only changing the data components), then `PlacementInfo#NOT_PLACEABLE` is used.
+- A **`SlotDisplay`** defines how a single slot should display within a recipe viewer, like the recipe book.
+- A **`RecipeDisplay`** defines the `SlotDisplay`s of a recipe to be consumed by a recipe viewer, like the recipe book. While the interface only contains methods for the result of a recipe and the workstation the recipe was conducted within, a subtype can capture information like ingredients or grid size.
+- The **`RecipeManager`** is a singleton field on the server that holds all loaded recipes.
+- A **`RecipeSerializer`** is basically a wrapper around a [`MapCodec`][codec] and a [`StreamCodec`][streamcodec], both used for serialization.
+- A **`RecipeType`** is the registered type equivalent of a `Recipe`. It is mainly used when looking up recipes by type. As a rule of thumb, different crafting containers should use different `RecipeType`s. For example, the `minecraft:crafting` recipe type covers the `minecraft:crafting_shaped` and `minecraft:crafting_shapeless` recipe serializers, as well as the special crafting serializers.
+- A **`RecipeBookCategory`** is a group representing some recipes when viewed through a recipe book.
+- A **recipe [advancement]** is an advancement responsible for unlocking a recipe in the recipe book. They are not required, and generally neglected by players in favor of recipe viewer mods, however the [recipe data provider][datagen] generates them for you, so it's recommended to just roll with it.
+- A **`RecipePropertySet`** defines the available list of ingredients that can be accepted by the defined input slot in a menu.
+- A **`RecipeBuilder`** is used during datagen to create JSON recipes.
+- A **recipe factory** is a method reference used to create a `Recipe` from a `RecipeBuilder`. It can either be a reference to a constructor, or a static builder method, or a functional interface (often named `Factory`) created specifically for this purpose.
+
+## JSON Specification
+
+The contents of recipe files vary greatly depending on the selected type. Common to all recipe files are the `type` and [`neoforge:conditions`][conditions] properties:
+
+```json5
+{
+    // The recipe type. This maps to an entry in the recipe serializer registry.
+    "type": "minecraft:crafting_shaped",
+    // A list of data load conditions. Optional, NeoForge-added. See the article linked above for more information.
+    "neoforge:conditions": [ /*...*/ ]
+}
+```
+
+A full list of types provided by Minecraft can be found in the [Built-In Recipe Types article][builtin]. Mods can also [define their own recipe types][customrecipes].
+
+## Using Recipes
+
+Recipes are loaded, stored and obtained via the `RecipeManager` class, which is in turn obtained via `ServerLevel#recipeAccess` or - if you don't have a `ServerLevel` available - `ServerLifecycleHooks.getCurrentServer()#getRecipeManager`. The server does not sync the recipes to the client by default, instead it only sends the `RecipePropertySet`s for restricting inputs on menu slots. Additionally, whenever a recipe is unlocked for the recipe book, its `RecipeDisplay`s and the corresponding `RecipeDisplayEntry`s are sent to the client (excluding all recipes where `Recipe#isSpecial` returns true) As such, recipe logic should always run on the server.
+
+The easiest way to get a recipe is by its resource key:
+
+```java
+RecipeManager recipes = serverLevel.recipeAccess();
+// RecipeHolder<?> is a record of the resource key and the recipe itself.
+Optional<RecipeHolder<?>> optional = recipes.byKey(
+    ResourceKey.create(Registries.RECIPE, ResourceLocation.withDefaultNamespace("diamond_block"))
+);
+optional.map(RecipeHolder::value).ifPresent(recipe -> {
+    // Do whatever you want to do with the recipe here. Be aware that the recipe may be of any type.
+});
+```
+
+A more practically applicable method is constructing a `RecipeInput` and trying to get a matching recipe. In this example, we will be creating a `CraftingInput` containing one diamond block using `CraftingInput#of`. This will create a shapeless input, a shaped input would instead use `CraftingInput#ofPositioned`, and other inputs would use other `RecipeInput`s (for example, furnace recipes will generally use `new SingleRecipeInput`).
+
+```java
+RecipeManager recipes = serverLevel.recipeAccess();
+// Construct a RecipeInput, as required by the recipe. For example, construct a CraftingInput for a crafting recipe.
+// The parameters are width, height and items, respectively.
+CraftingInput input = CraftingInput.of(1, 1, List.of(new ItemStack(Items.DIAMOND_BLOCK)));
+// The generic wildcard on the recipe holder should then extend CraftingRecipe.
+// This allows for more type safety later on.
+Optional<RecipeHolder<? extends CraftingRecipe>> optional = recipes.getRecipeFor(
+        // The recipe type to get the recipe for. In our case, we use the crafting type.
+        RecipeType.CRAFTING,
+        // Our recipe input.
+        input,
+        // Our level context.
+        serverLevel
+);
+// This returns the diamond block -> 9 diamonds recipe (unless a datapack changes that recipe).
+optional.map(RecipeHolder::value).ifPresent(recipe -> {
+    // Do whatever you want here. Note that the recipe is now a CraftingRecipe instead of a Recipe<?>.
+});
+```
+
+Alternatively, you can also get yourself a potentially empty list of recipes that match your input, this is especially useful for cases where it can be reasonably assumed that multiple recipes match:
+
+```java
+RecipeManager recipes = serverLevel.recipeAccess();
+CraftingInput input = CraftingInput.of(1, 1, List.of(new ItemStack(Items.DIAMOND_BLOCK)));
+// These are not Optionals, and can be used directly. However, the list may be empty, indicating no matching recipes.
+Stream<RecipeHolder<? extends Recipe<CraftingInput>>> list = recipes.recipeMap().getRecipesFor(
+    // Same parameters as above.
+    RecipeType.CRAFTING, input, serverLevel
+);
+```
+
+Once we have our correct recipe inputs, we also want to get the recipe outputs. This is done by calling `Recipe#assemble`:
+
+```java
+RecipeManager recipes = serverLevel.recipeAccess();
+CraftingInput input = CraftingInput.of(...);
+Optional<RecipeHolder<? extends CraftingRecipe>> optional = recipes.getRecipeFor(...);
+// Use ItemStack.EMPTY as a fallback.
+ItemStack result = optional
+        .map(RecipeHolder::value)
+        .map(recipe -> recipe.assemble(input, serverLevel.registryAccess()))
+        .orElse(ItemStack.EMPTY);
+```
+
+If necessary, it is also possible to iterate over all recipes of a type. This is done like so:
+
+```java
+RecipeManager recipes = serverLevel.recipeAccess();
+// Like before, pass the desired recipe type.
+Collection<RecipeHolder<?>> list = recipes.recipeMap().byType(RecipeType.CRAFTING);
+```
+
+## Other Recipe Mechanisms
+
+Some mechanisms in vanilla are generally considered recipes, but are implemented differently in code. This is generally either due to legacy reasons, or because the "recipes" are constructed from other data (e.g. [tags]).
+
+:::warning
+Recipe viewer mods will generally not pick up these recipes. Support for these mods must be added manually, please see the corresponding mod's documentation for more information.
+:::
+
+### Anvil Recipes
+
+Anvils have two input slots and one output slot. The only vanilla use cases are tool repairing, combining and renaming, and since each of these use cases needs special handling, no recipe files are provided. However, the system can be built upon using `AnvilUpdateEvent`. This [event] allows getting the input (left input slot) and material (right input slot) and allows setting an output item stack, as well as the experience cost and the number of materials to consume. The process can also be prevented as a whole by [canceling][cancel] the event.
+
+```java
+// This example allows repairing a stone pickaxe with a full stack of dirt, consuming half the stack, for 3 levels.
+@SubscribeEvent
+public static void onAnvilUpdate(AnvilUpdateEvent event) {
+    ItemStack left = event.getLeft();
+    ItemStack right = event.getRight();
+    if (left.is(Items.STONE_PICKAXE) && right.is(Items.DIRT) && right.getCount() >= 64) {
+        event.setOutput(Items.STONE_PICKAXE);
+        event.setMaterialCost(32);
+        event.setCost(3);
+    }
+}
+```
+
+### Brewing
+
+See [the Brewing chapter in the Mob Effects & Potions article][brewing].
+
+### Extending the Crafting Grid Size
+
+The `ShapedRecipePattern` class, responsible for holding the in-memory representation of shaped crafting recipes, has a hardcoded limit of 3x3 slots, hindering mods that want to add larger crafting tables while reusing the vanilla shaped crafting recipe type. To solve this problem, NeoForge patches in a static method called `ShapedRecipePattern#setCraftingSize(int width, int height)` that allows increasing the limit. It should be called during `FMLCommonSetupEvent`. The biggest value wins here, so for example if one mod added a 4x6 crafting table and another added a 6x5 crafting table, the resulting values would be 6x6.
+
+:::danger
+`ShapedRecipePattern#setCraftingSize` is not thread-safe. It must be wrapped in an `event#enqueueWork` call.
+:::
+
+## Data Generation
+
+Like most other JSON files, recipes can be datagenned. For recipes, we want to extend the `RecipeProvider` class and override `#buildRecipes`, and extend the `RecipeProvider.Runner` class to pass to the data generator:
+
+```java
+public class MyRecipeProvider extends RecipeProvider {
+
+    // Construct the provider to run
+    protected MyRecipeProvider(HolderLookup.Provider provider, RecipeOutput output) {
+        super(provider, output);
+    }
+ 
+    @Override
+    protected void buildRecipes() {
+        // Add your recipes here.
+    }
+
+    // The runner to add to the data generator
+    public static class Runner extends RecipeProvider.Runner {
+        // Get the parameters from GatherDataEvent.
+        public Runner(PackOutput output, CompletableFuture<HolderLookup.Provider> lookupProvider) {
+            super(output, lookupProvider);
+        }
+
+        @Override
+        protected abstract RecipeProvider createRecipeProvider(HolderLookup.Provider provider, RecipeOutput output) {
+            return new MyRecipeProvider(provider, output);
+        }
+    }
+}
+```
+
+Of note is the `RecipeOutput` parameter. Minecraft uses this object to automatically generate a recipe advancement for you. On top of that, NeoForge injects [conditions] support into `RecipeOutput`, which can be called on via `#withConditions`.
+
+Recipes themselves are commonly added through subclasses of `RecipeBuilder`. Listing all vanilla recipe builders is beyond the scope of this article (they are explained in the [Built-In Recipe Types article][builtin]), however creating your own builder is explained [in the custom recipes page][customdatagen].
+
+Like all other data providers, recipe providers must be registered to `GatherDataEvent` like so:
+
+```java
+@SubscribeEvent
+public static void gatherData(GatherDataEvent event) {
+    DataGenerator generator = event.getGenerator();
+    PackOutput output = generator.getPackOutput();
+    CompletableFuture<HolderLookup.Provider> lookupProvider = event.getLookupProvider();
+
+    // other providers here
+    generator.addProvider(
+            event.includeServer(),
+            new MyRecipeProvider.Runner(output, lookupProvider)
+    );
+}
+```
+
+The recipe provider also adds helpers for common scenarios, such as `twoByTwoPacker` (for 2x2 block recipes), `threeByThreePacker` (for 3x3 block recipes) or `nineBlockStorageRecipes` (for 3x3 block recipes and 1 block to 9 items recipes).
+
+[advancement]: ../advancements.md
+[brewing]: ../../../items/mobeffects.md#brewing
+[builtin]: builtin.md
+[cancel]: ../../../concepts/events.md#cancellable-events
+[codec]: ../../../datastorage/codecs.md
+[conditions]: ../conditions.md
+[customdatagen]: custom.md#data-generation
+[customrecipes]: custom.md
+[datagen]: #data-generation
+[event]: ../../../concepts/events.md
+[ingredients]: ingredients.md
+[streamcodec]: ../../../networking/streamcodecs.md
+[tags]: ../tags.md
diff --git a/versioned_docs/version-1.21.3/resources/server/recipes/ingredients.md b/versioned_docs/version-1.21.3/resources/server/recipes/ingredients.md
new file mode 100644
index 00000000..95b17612
--- /dev/null
+++ b/versioned_docs/version-1.21.3/resources/server/recipes/ingredients.md
@@ -0,0 +1,162 @@
+# Ingredients
+
+`Ingredient`s are used in [recipes] to check whether a given [`ItemStack`][itemstack] is a valid input for the recipe. For this purpose, `Ingredient` implements `Predicate<ItemStack>`, and `#test` can be called to confirm if a given `ItemStack` matches the ingredient.
+
+Unfortunately, many internals of `Ingredient` are a mess. NeoForge works around this by ignoring the `Ingredient` class where possible, instead introducing the `ICustomIngredient` interface for custom ingredients. This is not a direct replacement for regular `Ingredient`s, but we can convert to and from `Ingredient`s using `ICustomIngredient#toVanilla` and `Ingredient#getCustomIngredient`, respectively.
+
+## Built-In Ingredient Types
+
+The simplest way to get an ingredient is using the `Ingredient#of` helpers. Several variants exist:
+
+- `Ingredient.of()` returns an empty ingredient.
+- `Ingredient.of(Blocks.IRON_BLOCK, Items.GOLD_BLOCK)` returns an ingredient that accepts either an iron or a gold block. The parameter is a vararg of [`ItemLike`s][itemlike], which means that any amount of both blocks and items may be used.
+- `Ingredient.of(Stream.of(Items.DIAMOND_SWORD))` returns an ingredient that accepts an item. Like the previous method, but with a `Stream<ItemLike>` for if you happen to get your hands on one of those.
+- `Ingredient.of(BuiltInRegistries.ITEM.getOrThrow(ItemTags.WOODEN_SLABS))` returns an ingredient that accepts any item from the specified [tag], for example any wooden slab.
+
+Additionally, NeoForge adds a few additional ingredients:
+
+- `BlockTagIngredient.of(BlockTags.CONVERTABLE_TO_MUD)` returns an ingredient similar to the tag variant of `Ingredient.of()`, but with a block tag instead. This should be used for cases where you'd use an item tag, but there is only a block tag available (for example `minecraft:convertable_to_mud`).
+- `CustomDisplayIngredient.of(Ingredient.of(Items.DIRT), SlotDisplay.Empty.INSTANCE)` returns an ingredient with a custom [`SlotDisplay`][slotdisplay] you provide to determine how the slot gets consumed for rendering on the client.
+- `CompoundIngredient.of(Ingredient.of(Items.DIRT))` returns an ingredient with child ingredients, passed in the constructor (vararg parameter). The ingredient matches if any of its children matches.
+- `DataComponentIngredient.of(true, new ItemStack(Items.DIAMOND_SWORD))` returns an ingredient that, in addition to the item, also matches the data component. The boolean parameter denotes strict matching (true) or partial matching (false). Strict matching means the data components must match exactly, while partial matching means the data components must match, but other data components may also be present. Additional overloads of `#of` exist that allow specifying multiple `Item`s, or provide other options.
+- `DifferenceIngredient.of(Ingredient.of(BuiltInRegistries.ITEM.getOrThrow(ItemTags.PLANKS)), Ingredient.of(BuiltInRegistries.ITEM.getOrThrow(ItemTags.NON_FLAMMABLE_WOOD)))` returns an ingredient that matches everything in the first ingredient that doesn't also match the second ingredient. The given example only matches planks that can burn (i.e. all planks except crimson planks, warped planks and modded nether wood planks).
+- `IntersectionIngredient.of(Ingredient.of(BuiltInRegistries.ITEM.getOrThrow(ItemTags.PLANKS)), Ingredient.of(BuiltInRegistries.ITEM.getOrThrow(ItemTags.NON_FLAMMABLE_WOOD)))` returns an ingredient that matches everything that matches both sub-ingredients. The given example only matches planks that cannot burn (i.e. crimson planks, warped planks and modded nether wood planks).
+
+:::note
+If you are using data generation with ingredients that take in a `HolderSet` for the tag instance (the ones that call `Registry#getOrThrow`), then that `HolderSet` should be obtained via the `HolderLookup.Provider`, using `HolderLookup.Provider#lookupOrThrow` to get the item registry and `HolderGetter#getOrThrow` with the `TagKey` to get the holder set.
+:::
+
+Keep in mind that the NeoForge-provided ingredient types are `ICustomIngredient`s and must call `#toVanilla` before using them in vanilla contexts, as outlined in the beginning of this article.
+
+## Custom Ingredient Types
+
+It is possible for modders to add their custom ingredient types through the `ICustomIngredient` system. For the sake of example, let's make an enchanted item ingredient that accepts an item tag and a map of enchantments to min levels:
+
+```java
+public class MinEnchantedIngredient implements ICustomIngredient {
+    private final TagKey<Item> tag;
+    private final Map<Holder<Enchantment>, Integer> enchantments;
+    // The codec for serializing the ingredient.
+    public static final MapCodec<MinEnchantedIngredient> CODEC = RecordCodecBuilder.mapCodec(inst -> inst.group(
+            TagKey.codec(Registries.ITEM).fieldOf("tag").forGetter(e -> e.tag),
+            Codec.unboundedMap(Enchantment.CODEC, Codec.INT)
+                    .optionalFieldOf("enchantments", Map.of())
+                    .forGetter(e -> e.enchantments)
+    ).apply(inst, MinEnchantedIngredient::new));
+    // Create a stream codec from the regular codec. In some cases, it might make sense to define
+    // a new stream codec from scratch.
+    public static final StreamCodec<RegistryFriendlyByteBuf, MinEnchantedIngredient> STREAM_CODEC =
+            ByteBufCodecs.fromCodecWithRegistries(CODEC.codec());
+
+    // Allow passing in a pre-existing map of enchantments to levels.
+    public MinEnchantedIngredient(TagKey<Item> tag, Map<Holder<Enchantment>, Integer> enchantments) {
+        this.tag = tag;
+        this.enchantments = enchantments;
+    }
+
+    // Check if the passed ItemStack matches our ingredient by verifying the item is in the tag
+    // and by testing for presence of all required enchantments with at least the required level.
+    @Override
+    public boolean test(ItemStack stack) {
+        return stack.is(tag) && enchantments.keySet()
+                .stream()
+                .allMatch(ench -> EnchantmentHelper.getEnchantmentsForCrafting(stack).getLevel(ench) >= enchantments.get(ench));
+    }
+
+    // Determines whether this ingredient performs NBT or data component matching (false) or not (true).
+    // Also determines whether a stream codec is used for syncing, more on this later.
+    // We query enchantments on the stack, therefore our ingredient is not simple.
+    @Override
+    public boolean isSimple() {
+        return false;
+    }
+
+    // Returns a stream of items that match this ingredient. Mostly for display purposes.
+    // There's a few good practices to follow here:
+    // - Always include at least one item, to prevent accidental recognition as empty.
+    // - Include each accepted Item at least once.
+    // - If #isSimple is true, this should be exact and contain every item that matches.
+    //   If not, this should be as exact as possible, but doesn't need to be super accurate.
+    // In our case, we use all items in the tag.
+    @Override
+    public Stream<Holder<Item>> getItems() {
+        return BuiltInRegistries.ITEM.getOrThrow(tag).stream();
+    }
+}
+```
+
+Custom ingredients are a [registry], so we must register our ingredient. We do so using the `IngredientType` class provided by NeoForge, which is basically a wrapper around a [`MapCodec`][codec] and optionally a [`StreamCodec`][streamcodec].
+
+```java
+public static final DeferredRegister<IngredientType<?>> INGREDIENT_TYPES =
+        DeferredRegister.create(NeoForgeRegistries.Keys.INGREDIENT_TYPE, ExampleMod.MOD_ID);
+
+public static final Supplier<IngredientType<MinEnchantedIngredient>> MIN_ENCHANTED =
+        INGREDIENT_TYPES.register("min_enchanted",
+                // The stream codec parameter is optional, a stream codec will be created from the codec
+                // using ByteBufCodecs#fromCodec or #fromCodecWithRegistries if the stream codec isn't specified.
+                () -> new IngredientType<>(MinEnchantedIngredient.CODEC, MinEnchantedIngredient.STREAM_CODEC));
+```
+
+When we have done that, we also need to override `#getType` in our ingredient class:
+
+```java
+public class MinEnchantedIngredient implements ICustomIngredient {
+    // other stuff here
+
+    @Override    
+    public IngredientType<?> getType() {
+        return MIN_ENCHANTED.get();
+    }
+}
+```
+
+And there we go! Our ingredient type is ready to use.
+
+## JSON Representation
+
+Due to vanilla ingredients being pretty limited and NeoForge introducing a whole new registry for them, it's also worth looking at what the built-in and our own ingredients look like in JSON.
+
+Ingredients that are objects and specify a `neoforge:ingredient_type` are generally assumed to be non-vanilla. For example:
+
+```json5
+{
+    "neoforge:ingredient_type": "neoforge:block_tag",
+    "tag": "minecraft:convertable_to_mud"
+}
+```
+
+Or another example using our own ingredient:
+
+```json5
+{
+    "neoforge:ingredient_type": "examplemod:min_enchanted",
+    "tag": "c:swords",
+    "enchantments": {
+        "minecraft:sharpness": 4
+    }
+}
+```
+
+If the ingredient is a string, meaning `neoforge:ingredient_type` is unspecified, then we have a vanilla ingredient. Vanilla ingredients are strings that either represent an item, or a tag when prefixed with `#`.
+
+An example for a vanilla item ingredient:
+
+```json5
+"minecraft:dirt"
+```
+
+An example for a vanilla tag ingredient:
+
+```json5
+"#c:ingots"
+```
+
+[codec]: ../../../datastorage/codecs.md
+[itemlike]: ../../../items/index.md#itemlike
+[itemstack]: ../../../items/index.md#itemstacks
+[recipes]: index.md
+[registry]: ../../../concepts/registries.md
+[slotdisplay]: index.md#slot-displays
+[streamcodec]: ../../../networking/streamcodecs.md
+[tag]: ../tags.md
diff --git a/versioned_docs/version-1.21.3/resources/server/tags.md b/versioned_docs/version-1.21.3/resources/server/tags.md
new file mode 100644
index 00000000..7b013db0
--- /dev/null
+++ b/versioned_docs/version-1.21.3/resources/server/tags.md
@@ -0,0 +1,290 @@
+# Tags
+
+A tag is, simply put, a list of registered objects of the same type. They are loaded from data files and can be used for membership checks. For example, crafting sticks will accept any combination of wooden planks (items tagged with `minecraft:planks`). Tags are often distinguished from "regular" objects by prefixing them with a `#` (for example `#minecraft:planks`, but `minecraft:oak_planks`).
+
+Any [registry] can have tag files - while blocks and items are the most common use cases, other registries such as fluids, entity types or damage types often utilize tags as well. You can also create your own tags if you need them.
+
+Tags are located at `data/<tag_namespace>/tags/<registry_path>/<tag_path>.json` for Minecraft registries, and `data/<tag_namespace>/tags/<registry_namespace>/<registry_path>/<tag_path>.json` for non-Minecraft registries. For example, to modify the `minecraft:planks` item tag, you would place your tag file at `data/minecraft/tags/item/planks.json`.
+
+:::info
+Unlike most other NeoForge data files, NeoForge-added tags do generally not use the `neoforge` namespace. Instead, they use the `c` namespace (e.g. `c:ingots/gold`). This is because the tags are unified between NeoForge and the Fabric mod loader, at the request of many modders developing on multiple loaders.
+
+There are a few exceptions to this rule for some tags that tie closely into NeoForge systems. This includes many [damage type][damagetype] tags, for example.
+:::
+
+Overriding tag files is generally additive instead of replacing. This means that if two datapacks specify tag files with the same id, the contents of both files will be merged (unless otherwise specified). This behavior sets tags apart from most other data files, which instead replace any and all existing values.
+
+## Tag File Format
+
+Tag files have the following syntax:
+
+```json5
+{
+    // The values of the tag.
+    "values": [
+        // A value object. Must specify the id of the object to add, and whether it is required.
+        // If the entry is required, but the object is not present, the tag will not load. The "required" field
+        // is technically optional, but when removed, the entry is equivalent to the shorthand below.
+        {
+            "id": "examplemod:example_ingot",
+            "required": false
+        }
+        // Shorthand for {"id": "minecraft:gold_ingot", "required": true}, i.e. a required entry.
+        "minecraft:gold_ingot",
+        // A tag object. Distinguished from regular entries by the leading #. In this case, all planks
+        // will be considered entries of the tag. Like normal entries, this can also have the "id"/"required" format.
+        // Warning: Circular tag dependencies will lead to a datapack not being loaded!
+        "#minecraft:planks"
+    ],
+    // Whether to remove all pre-existing entries before adding your own (true) or just add your own (false).
+    // This should generally be false, the option to set this to true is primarily aimed at pack developers.
+    "replace": false,
+    // A finer-grained way to remove entries from the tag again, if present. Optional, NeoForge-added.
+    // Entry syntax is the same as in the "values" array.
+    "remove": [
+        "minecraft:iron_ingot"
+    ]
+}
+```
+
+## Finding and Naming Tags
+
+When you try to find an existing tag, it is generally recommended to follow these steps:
+
+- Have a look at Minecraft's tags and see if the tag you're looking for is there. Minecraft's tags can be found in `BlockTags`, `ItemTags`, `EntityTypeTags` etc.
+- If not, have a look at NeoForge's tags and see if the tag you're looking for is there. NeoForge's tags can be found in `Tags.Blocks`, `Tags.Items`, `Tags.EntityTypes`, etc.
+- Otherwise, assume the tag is not specified in Minecraft or NeoForge, and thus you need to create your own tag.
+
+When creating your own tag, you should ask yourself the following questions:
+
+- Does this modify my mod's behavior? If yes, the tag should be in your mod's namespace. (This is common e.g. for my-thing-can-spawn-on-this-block kind of tags.)
+- Would other mods want to use this tag as well? If yes, the tag should be in the `c` namespace. (This is common e.g. for new metals or gems.)
+- Otherwise, use your mod's namespace.
+
+Naming the tag itself also has some conventions to follow:
+
+- Use the plural form. E.g.: `minecraft:planks`, `c:ingots`.
+- Use folders for multiple objects of the same type, and an overall tag for each folder. E.g.: `c:ingots/iron`, `c:ingots/gold`, and `c:ingots` containing both. (Note: This is a NeoForge convention, Minecraft does not follow this convention for most tags.)
+
+## Using Tags
+
+To reference tags in code, you must create a `TagKey<T>`, where `T` is the type of tag (`Block`, `Item`, `EntityType<?>`, etc.), using a [registry key][regkey] and a [resource location][resloc]:
+
+```java
+public static final TagKey<Block> MY_TAG = TagKey.create(
+        // The registry key. The type of the registry must match the generic type of the tag.
+        Registries.BLOCK,
+        // The location of the tag. This example will put our tag at data/examplemod/tags/blocks/example_tag.json.
+        ResourceLocation.fromNamespaceAndPath("examplemod", "example_tag")
+);
+```
+
+:::warning
+Since `TagKey` is a record, its constructor is public. However, the constructor should not be used directly, as doing so can lead to various issues, for example when looking up tag entries.
+:::
+
+We can then use our tag to perform various operations on it. Let's start with the most obvious one: check whether an object is in the tag. The following examples will assume block tags, but the functionality is the exact same for every type of tag (unless otherwise specified):
+
+```java
+// Check whether dirt is in our tag.
+// Assume access to Level level
+boolean isInTag = level.registryAccess().lookupOrThrow(BuiltInRegistries.BLOCK).getOrThrow(MY_TAG).stream().anyMatch(holder -> holder.is(Items.DIRT));
+```
+
+Since this is a very verbose statement, especially when used often, `BlockState` and `ItemStack` - the two most common users of the tag system - each define a `#is` helper method, used like so:
+
+```java
+// Check whether the blockState's block is in our tag.
+boolean isInBlockTag = blockState.is(MY_TAG);
+// Check whether the itemStack's item is in our tag. Assumes the existence of MY_ITEM_TAG as a TagKey<Item>.
+boolean isInItemTag = itemStack.is(MY_ITEM_TAG);
+```
+
+If needed, we can also get ourselves a set of tag entries to stream, like so:
+
+```java
+// Assume access to Level level
+Stream<Holder<Block>> blocksInTag = level.registryAccess().lookupOrThrow(BuiltInRegistries.BLOCK).getOrThrow(MY_TAG).stream();
+```
+
+### Tags for Static Registries During Bootstrap
+
+Sometimes, you need to get access to a `HolderSet` during the registry process. In this case, for static registries **only**, you can obtain the necessary `HolderGetter` via `BuiltInRegistries#acquireBootstrapRegistrationLookup`:
+
+```java
+// Assume access to Level level
+HolderSet<Block> blockTag = BuiltInRegistries.acquireBootstrapRegistrationLookup(BuiltInRegistries.BLOCK).getOrThrow(MY_TAG);
+```
+
+## Datagen
+
+Like many other JSON files, tags can be [datagenned][datagen]. Each kind of tag has its own datagen base class - one class for block tags, one for item tags, etc. -, and as such, we need one class for each kind of tag as well. All of these classes extend from the `TagsProvider<T>` base class, with `T` again being the type of the tag (`Block`, `Item`, etc.) The following table shows a list of tag providers for different objects:
+
+| Type                       | Tag Provider Class                     |
+|----------------------------|----------------------------------------|
+| `BannerPattern`            | `BannerPatternTagsProvider`            |
+| `Biome`                    | `BiomeTagsProvider`                    |
+| `Block`                    | `BlockTagsProvider`                    |
+| `CatVariant`               | `CatVariantTagsProvider`               |
+| `DamageType`               | `DamageTypeTagsProvider`               |
+| `Enchantment`              | `EnchantmentTagsProvider`              |
+| `EntityType`               | `EntityTypeTagsProvider`               |
+| `FlatLevelGeneratorPreset` | `FlatLevelGeneratorPresetTagsProvider` |
+| `Fluid`                    | `FluidTagsProvider`                    |
+| `GameEvent`                | `GameEventTagsProvider`                |
+| `Instrument`               | `InstrumentTagsProvider`               |
+| `Item`                     | `ItemTagsProvider`                     |
+| `PaintingVariant`          | `PaintingVariantTagsProvider`          |
+| `PoiType`                  | `PoiTypeTagsProvider`                  |
+| `Structure`                | `StructureTagsProvider`                |
+| `WorldPreset`              | `WorldPresetTagsProvider`              |
+
+Of note is the `IntrinsicHolderTagsProvider<T>` class, which is a subclass of `TagsProvider<T>` and a common superclass for `BlockTagsProvider`, `ItemTagsProvider`, `FluidTagsProvider`, `EntityTypeTagsProvider`, and `GameEventTagsProvider`. These classes (from now on called intrinsic providers for simplicity) have some additional functionality for generation that will be outlined in a moment.
+
+For the sake of example, let's assume that we want to generate block tags. (All other classes work the same with their respective tag types.)
+
+```java
+public class MyBlockTagsProvider extends BlockTagsProvider {
+    // Get parameters from GatherDataEvent.
+    public MyBlockTagsProvider(PackOutput output, CompletableFuture<HolderLookup.Provider> lookupProvider, ExistingFileHelper existingFileHelper) {
+        super(output, lookupProvider, ExampleMod.MOD_ID, existingFileHelper);
+    }
+
+    // Add your tag entries here.
+    @Override
+    protected void addTags(HolderLookup.Provider lookupProvider) {
+        // Create a tag builder for our tag. This could also be e.g. a vanilla or NeoForge tag.
+        this.tag(MY_TAG)
+                // Add entries. This is a vararg parameter.
+                // Non-intrinsic providers must provide ResourceKeys here instead of the actual objects.
+                .add(Blocks.DIRT, Blocks.COBBLESTONE)
+                // Add optional entries that will be ignored if absent. This example uses Botania's Pure Daisy.
+                // Unlike #add, this is not a vararg parameter.
+                .addOptional(ResourceLocation.fromNamespaceAndPath("botania", "pure_daisy"))
+                // Add a tag entry.
+                .addTag(BlockTags.PLANKS)
+                // Add multiple tag entries. This is a vararg parameter.
+                // Can cause unchecked warnings that can safely be suppressed.
+                .addTags(BlockTags.LOGS, BlockTags.WOODEN_SLABS)
+                // Add an optional tag entry that will be ignored if absent.
+                .addOptionalTag(ResourceLocation.fromNamespaceAndPath("c", "ingots/tin"))
+                // Add multiple optional tag entries. This is a vararg parameter.
+                // Can cause unchecked warnings that can safely be suppressed.
+                .addOptionalTags(ResourceLocation.fromNamespaceAndPath("c", "nuggets/tin"), ResourceLocation.fromNamespaceAndPath("c", "storage_blocks/tin"))
+                // Set the replace property to true.
+                .replace()
+                // Set the replace property back to false.
+                .replace(false)
+                // Remove entries. This is a vararg parameter. Accepts either resource locations, resource keys,
+                // tag keys, or (intrinsic providers only) direct values.
+                // Can cause unchecked warnings that can safely be suppressed.
+                .remove(ResourceLocation.fromNamespaceAndPath("minecraft", "crimson_slab"), ResourceLocation.fromNamespaceAndPath("minecraft", "warped_slab"));
+    }
+}
+```
+
+This example results in the following tag JSON:
+
+```json5
+{
+    "values": [
+        "minecraft:dirt",
+        "minecraft:cobblestone",
+        {
+            "id": "botania:pure_daisy",
+            "required": false
+        },
+        "#minecraft:planks",
+        "#minecraft:logs",
+        "#minecraft:wooden_slabs",
+        {
+            "id": "c:ingots/tin",
+            "required": false
+        },
+        {
+            "id": "c:nuggets/tin",
+            "required": false
+        },
+        {
+            "id": "c:storage_blocks/tin",
+            "required": false
+        }
+    ],
+    "remove": [
+        "minecraft:crimson_slab",
+        "minecraft:warped_slab"
+    ]
+}
+```
+
+Like all data providers, add each tag provider to the `GatherDataEvent`:
+
+```java
+@SubscribeEvent
+public static void gatherData(GatherDataEvent event) {
+    PackOutput output = generator.getPackOutput();
+    CompletableFuture<HolderLookup.Provider> lookupProvider = event.getLookupProvider();
+    ExistingFileHelper existingFileHelper = event.getExistingFileHelper();
+
+    // other providers here
+    event.getGenerator().addProvider(
+        event.includeServer(),
+        new MyBlockTagsProvider(output, lookupProvider, existingFileHelper)
+    );
+}
+```
+
+`ItemTagsProvider` has an additional helper method called `#copy`. It is intended for the common use case of item tags mirroring block tags:
+
+```java
+// In an ItemTagsProvider's #addTags method, assuming types TagKey<Block> and TagKey<Item> for the two parameters.
+this.copy(EXAMPLE_BLOCK_TAG, EXAMPLE_ITEM_TAG);
+```
+
+### Custom Tag Providers
+
+To create a custom tag provider for a custom [registry], or for a vanilla or NeoForge registry that doesn't have a tag provider by default, you can also create custom tag providers like so (using recipe type tags as an example):
+
+```java
+public class MyRecipeTypeTagsProvider extends TagsProvider<RecipeType<?>> {
+    // Get parameters from GatherDataEvent.
+    public MyRecipeTypeTagsProvider(PackOutput output, CompletableFuture<HolderLookup.Provider> lookupProvider, ExistingFileHelper existingFileHelper) {
+        // Second parameter is the registry key we are generating the tags for.
+        super(output, Registries.RECIPE_TYPE, lookupProvider, ExampleMod.MOD_ID, existingFileHelper);
+    }
+    
+    @Override
+    protected void addTags(HolderLookup.Provider lookupProvider) { /*...*/ }
+}
+```
+
+If desirable and applicable, you can also extend `IntrinsicHolderTagsProvider<T>` instead of `TagsProvider<T>`, allowing you to pass in objects directly rather than just their resource keys. This additionally requires a function parameter that returns a resource key for a given object. Using attribute tags as an example:
+
+```java
+public class MyAttributeTagsProvider extends TagsProvider<Attribute> {
+    // Get parameters from GatherDataEvent.
+    public MyAttributeTagsProvider(PackOutput output, CompletableFuture<HolderLookup.Provider> lookupProvider, ExistingFileHelper existingFileHelper) {
+        super(output,
+                Registries.ATTRIBUTE,
+                lookupProvider,
+                // A function that, given an Attribute, returns a ResourceKey<Attribute>.
+                attribute -> BuiltInRegistries.ATTRIBUTE.getResourceKey(attribute).orElseThrow(),
+                ExampleMod.MOD_ID,
+                existingFileHelper);
+    }
+
+    // Attributes can now be used here directly, instead of just their resource keys.
+    @Override
+    protected void addTags(HolderLookup.Provider lookupProvider) { /*...*/ }
+}
+```
+
+:::info
+`TagsProvider` also exposes the `#getOrCreateRawBuilder` method, returning a `TagBuilder`. A `TagBuilder` allows adding raw `ResourceLocation`s to a tag, which can be useful in some scenarios. The `TagsProvider.TagAppender<T>` class, which is returned by `TagsProvider#tag`, is simply a wrapper around `TagBuilder`.
+:::
+
+[damagetype]: damagetypes.md
+[datagen]: ../index.md#data-generation
+[registry]: ../../concepts/registries.md
+[regkey]: ../../misc/resourcelocation.md#resourcekeys
+[resloc]: ../../misc/resourcelocation.md
diff --git a/versioned_docs/version-1.21.3/worldgen/_category_.json b/versioned_docs/version-1.21.3/worldgen/_category_.json
new file mode 100644
index 00000000..019b3d56
--- /dev/null
+++ b/versioned_docs/version-1.21.3/worldgen/_category_.json
@@ -0,0 +1,4 @@
+{
+    "label": "Worldgen",
+    "position": 10
+}
\ No newline at end of file
diff --git a/versioned_docs/version-1.21.3/worldgen/biomemodifier.md b/versioned_docs/version-1.21.3/worldgen/biomemodifier.md
new file mode 100644
index 00000000..9034534c
--- /dev/null
+++ b/versioned_docs/version-1.21.3/worldgen/biomemodifier.md
@@ -0,0 +1,717 @@
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# Biome Modifiers
+
+Biome Modifiers are a data-driven system that allows for changing many aspects of a biome, including the ability to inject or remove PlacedFeatures, add or remove mob spawns, change the climate, and adjust foliage and water color. NeoForge provides several default biome modifiers that cover the majority of use cases for both players and modders.
+
+### Recommended Section To Read:
+
+- Players or pack developers:
+    - [Applying Biome Modifiers](#applying-biome-modifiers)
+    - [Built-in Neoforge Biome Modifiers](#built-in-biome-modifiers)
+
+
+- Modders doing simple additions or removal biome modifications:
+    - [Applying Biome Modifiers](#applying-biome-modifiers)
+    - [Built-in Neoforge Biome Modifiers](#built-in-biome-modifiers)
+    - [Datagenning Biome Modifiers](#datagenning-biome-modifiers)
+    - [Targeting Biomes That May Not Exist](#targeting-biomes-that-may-not-exist)
+
+
+- Modders who want to do custom or complex biome modifications:
+    - [Applying Biome Modifiers](#applying-biome-modifiers)
+    - [Creating Custom Biome Modifiers](#creating-custom-biome-modifiers)
+    - [Datagenning Biome Modifiers](#datagenning-biome-modifiers)
+    - [Targeting Biomes That May Not Exist](#targeting-biomes-that-may-not-exist)
+
+
+## Applying Biome Modifiers
+
+To have NeoForge load a biome modifier JSON file into the game, the file will need to be under `data/<modid>/neoforge/biome_modifier/<path>.json` folder in the mod's resources, or in a [Datapack][datapacks]. Then, once NeoForge loads the biome modifier, it will read its instructions and apply the described modifications to all target biomes when the world is loaded up. Pre-existing biome modifiers from mods can be overridden by datapacks having a new JSON file at the exact same location and name.
+
+The JSON file can be created by hand following the examples in the '[Built-in NeoForge Biome Modifiers](#built-in-biome-modifiers)' section or be datagenned as shown in the '[Datagenning Biome Modifiers](#datagenning-biome-modifiers)' section.
+
+## Built-in Biome Modifiers
+
+These biome modifiers are registered by NeoForge for anyone to use.
+
+### None
+
+This biome modifier has no operation and will do no modification. Pack makers and players can use this in a datapack to disable mods' biome modifiers by overriding their biome modifier JSONs with the JSON below.
+
+<Tabs>
+<TabItem value="json" label="JSON" default>
+
+```json5
+{
+    "type": "neoforge:none"
+}
+```
+
+</TabItem>
+<TabItem value="datagen" label="Datagen">
+
+```java
+// Define the ResourceKey for our BiomeModifier.
+public static final ResourceKey<BiomeModifier> NO_OP_EXAMPLE = ResourceKey.create(
+    NeoForgeRegistries.Keys.BIOME_MODIFIERS, // The registry this key is for
+    ResourceLocation.fromNamespaceAndPath(MOD_ID, "no_op_example") // The registry name
+);
+
+// BUILDER is a RegistrySetBuilder passed to DatapackBuiltinEntriesProvider
+// in a listener for GatherDataEvent.
+BUILDER.add(NeoForgeRegistries.Keys.BIOME_MODIFIERS, bootstrap -> {
+    // Register the biome modifiers.
+    bootstrap.register(NO_OP_EXAMPLE, NoneBiomeModifier.INSTANCE);
+});
+```
+
+</TabItem>
+</Tabs>
+
+### Add Features
+
+This biome modifier type adds `PlacedFeature`s (such as trees or ores) to biomes so that they can spawn during world generation. The modifier takes in the biome id or tag of the biomes the features are added to, a `PlacedFeature` id or tag to add to the selected biomes, and the [`GenerationStep.Decoration`](#Available-Values-for-Decoration-Steps) the features will be generated within.
+
+<Tabs>
+<TabItem value="json" label="JSON" default>
+
+```json5
+{
+    "type": "neoforge:add_features",
+    // Can either be a biome id, such as "minecraft:plains",
+    // or a list of biome ids, such as ["minecraft:plains", "minecraft:badlands", ...],
+    // or a biome tag, such as "#c:is_overworld".
+    "biomes": "#namespace:your_biome_tag",
+    // Can either be a placed feature id, such as "examplemod:add_features_example",
+    // or a list of placed feature ids, such as ["examplemod:add_features_example", minecraft:ice_spike", ...],
+    // or a placed feature tag, such as "#examplemod:placed_feature_tag".
+    "features": "namespace:your_feature",
+    // See the GenerationStep.Decoration enum in code for a list of valid enum names.
+    // The decoration step section further down also has the list of values for reference.
+    "step": "underground_ores"
+}
+```
+
+</TabItem>
+<TabItem value="datagen" label="Datagen">
+
+```java
+// Assume we have some PlacedFeature named EXAMPLE_PLACED_FEATURE.
+// Define the ResourceKey for our BiomeModifier.
+public static final ResourceKey<BiomeModifier> ADD_FEATURES_EXAMPLE = ResourceKey.create(
+    NeoForgeRegistries.Keys.BIOME_MODIFIERS, // The registry this key is for
+    ResourceLocation.fromNamespaceAndPath(MOD_ID, "add_features_example") // The registry name
+);
+
+// BUILDER is a RegistrySetBuilder passed to DatapackBuiltinEntriesProvider
+// in a listener for GatherDataEvent.
+BUILDER.add(NeoForgeRegistries.Keys.BIOME_MODIFIERS, bootstrap -> {
+    // Lookup any necessary registries.
+    // Static registries only need to be looked up if you need to grab the tag data.
+    HolderGetter<Biome> biomes = bootstrap.lookup(Registries.BIOME);
+    HolderGetter<PlacedFeature> placedFeatures = bootstrap.lookup(Registries.PLACED_FEATURE);
+
+    // Register the biome modifiers.
+    bootstrap.register(ADD_FEATURES_EXAMPLE,
+        new AddFeaturesBiomeModifier(
+            // The biome(s) to generate within
+            HolderSet.direct(biomes.getOrThrow(Biomes.PLAINS)),
+            // The feature(s) to generate within the biomes
+            HolderSet.direct(placedFeatures.getOrThrow(EXAMPLE_PLACED_FEATURE)),
+            // The generation step
+            GenerationStep.Decoration.LOCAL_MODIFICATIONS
+        )
+    );
+})
+```
+
+</TabItem>
+</Tabs>
+
+
+:::warning
+Care should be taken when adding vanilla `PlacedFeature`s to biomes, as doing so may cause what is known as a feature cycle violation (two biomes having the same two features in their feature lists, but in different orders within the same `GenerationStep`), leading to a crash. For similar reasons, you should not use the same `PlacedFeature` in more than one biome modifier.
+
+Vanilla `PlacedFeature`s can be referenced in biome JSONs or added via biome modifiers, but should not be used in both. If you still need to add them this way, making a copy of the vanilla `PlacedFeature` under your own namespace is the easiest solution to avoid these problems.
+:::
+
+### Remove Features
+
+This biome modifier type removes features (such as trees or ores) from biomes so that they will no longer spawn during world generation. The modifier takes in the biome id or tag of the biomes the features are removed from, a `PlacedFeature` id or tag to remove from the selected biomes, and the [`GenerationStep.Decoration`](#Available-Values-for-Decoration-Steps)s that the features will be removed from.
+
+<Tabs>
+<TabItem value="json" label="JSON" default>
+
+```json5
+{
+    "type": "neoforge:remove_features",
+    // Can either be a biome id, such as "minecraft:plains",
+    // or a list of biome ids, such as ["minecraft:plains", "minecraft:badlands", ...],
+    // or a biome tag, such as "#c:is_overworld".
+    "biomes": "#namespace:your_biome_tag",
+    // Can either be a placed feature id, such as "examplemod:add_features_example",
+    // or a list of placed feature ids, such as ["examplemod:add_features_example", "minecraft:ice_spike", ...],
+    // or a placed feature tag, such as "#examplemod:placed_feature_tag".
+    "features": "namespace:problematic_feature",
+    // Optional field specifying a GenerationStep, or a list of GenerationSteps, to remove features from.
+    // If omitted, defaults to all GenerationSteps.
+    // See the GenerationStep.Decoration enum in code for a list of valid enum names.
+    // The decoration step section further down also has the list of values for reference.
+    "steps": ["underground_ores", "underground_decoration"]
+}
+```
+
+</TabItem>
+<TabItem value="datagen" label="Datagen">
+
+```java
+// Define the ResourceKey for our BiomeModifier.
+public static final ResourceKey<BiomeModifier> REMOVE_FEATURES_EXAMPLE = ResourceKey.create(
+    NeoForgeRegistries.Keys.BIOME_MODIFIERS, // The registry this key is for
+    ResourceLocation.fromNamespaceAndPath(MOD_ID, "remove_features_example") // The registry name
+);
+
+// BUILDER is a RegistrySetBuilder passed to DatapackBuiltinEntriesProvider
+// in a listener for GatherDataEvent.
+BUILDER.add(NeoForgeRegistries.Keys.BIOME_MODIFIERS, bootstrap -> {
+    // Lookup any necessary registries.
+    // Static registries only need to be looked up if you need to grab the tag data.
+    HolderGetter<Biome> biomes = bootstrap.lookup(Registries.BIOME);
+    HolderGetter<PlacedFeature> placedFeatures = bootstrap.lookup(Registries.PLACED_FEATURE);
+
+    // Register the biome modifiers.
+    bootstrap.register(REMOVE_FEATURES_EXAMPLE,
+        new RemoveFeaturesBiomeModifier(
+            // The biome(s) to remove from
+            biomes.getOrThrow(Tags.Biomes.IS_OVERWORLD),
+            // The feature(s) to remove from the biomes
+            HolderSet.direct(placedFeatures.getOrThrow(OrePlacements.ORE_DIAMOND)),
+            // The generation steps to remove from
+            Set.of(
+                GenerationStep.Decoration.LOCAL_MODIFICATIONS,
+                GenerationStep.Decoration.UNDERGROUND_ORES
+            )
+        )
+    );
+});
+```
+
+</TabItem>
+</Tabs>
+
+
+### Add Spawns 
+
+This biome modifier type adds entity spawns to biomes. The modifier takes in the biome id or tag of the biomes the entity spawns are added to, and the `SpawnerData` of the entities to add. Each `SpawnerData` contains the entity id, the spawn weight, and the minimum/maximum number of entities to spawn at a given time.
+
+:::note
+If you are a modder adding a new entity, make sure the entity has a spawn restriction registered to `RegisterSpawnPlacementsEvent`. Spawn restrictions are used to make entities spawn on surfaces or in water safely. If you do not register a spawn restriction, your entity could spawn in mid-air, fall and die.
+:::
+
+<Tabs>
+<TabItem value="json" label="JSON" default>
+
+```json5
+{
+    "type": "neoforge:add_spawns",
+    // Can either be a biome id, such as "minecraft:plains",
+    // or a list of biome ids, such as ["minecraft:plains", "minecraft:badlands", ...],
+    // or a biome tag, such as "#c:is_overworld".
+    "biomes": "#namespace:biome_tag",
+    // Can be either a single object or a list of objects.
+    "spawners": [
+        {
+            "type": "namespace:entity_type", // The id of the entity type to spawn
+            "weight": 100, // non-negative int, spawn weight
+            "minCount": 1, // positive int, minimum group size
+            "maxCount": 4 // positive int, maximum group size
+        },
+        {
+            "type": "minecraft:ghast",
+            "weight": 1,
+            "minCount": 5,
+            "maxCount": 10
+        }
+    ]
+}
+```
+
+</TabItem>
+<TabItem value="datagen" label="Datagen">
+
+```java
+// Assume we have some EntityType<?> named EXAMPLE_ENTITY.
+// Define the ResourceKey for our BiomeModifier.
+public static final ResourceKey<BiomeModifier> ADD_SPAWNS_EXAMPLE = ResourceKey.create(
+    NeoForgeRegistries.Keys.BIOME_MODIFIERS, // The registry this key is for
+    ResourceLocation.fromNamespaceAndPath(MOD_ID, "add_spawns_example") // The registry name
+);
+
+// BUILDER is a RegistrySetBuilder passed to DatapackBuiltinEntriesProvider
+// in a listener for GatherDataEvent.
+BUILDER.add(NeoForgeRegistries.Keys.BIOME_MODIFIERS, bootstrap -> {
+    // Lookup any necessary registries.
+    // Static registries only need to be looked up if you need to grab the tag data.
+    HolderGetter<Biome> biomes = bootstrap.lookup(Registries.BIOME);
+
+    // Register the biome modifiers.
+    bootstrap.register(ADD_SPAWNS_EXAMPLE,
+        new AddSpawnsBiomeModifier(
+            // The biome(s) to spawn the mobs within
+            HolderSet.direct(biomes.getOrThrow(Biomes.PLAINS)),
+            // The spawners of the entities to add
+            List.of(
+                new SpawnerData(EXAMPLE_ENTITY, 100, 1, 4),
+                new SpawnerData(EntityType.GHAST, 1, 5, 10)
+            )
+        )
+    );
+});
+```
+
+</TabItem>
+</Tabs>
+
+
+### Remove Spawns
+
+This biome modifier type removes entity spawns from biomes. The modifier takes in the biome id or tag of the biomes the entity spawns are removed from, and the `EntityType` id or tag of the entities to remove.
+
+<Tabs>
+<TabItem value="json" label="JSON" default>
+
+```json5
+{
+    "type": "neoforge:remove_spawns",
+    // Can either be a biome id, such as "minecraft:plains",
+    // or a list of biome ids, such as ["minecraft:plains", "minecraft:badlands", ...],
+    // or a biome tag, such as "#c:is_overworld".
+    "biomes": "#namespace:biome_tag",
+    // Can either be an entity type id, such as "minecraft:ghast",
+    // or a list of entity type ids, such as ["minecraft:ghast", "minecraft:skeleton", ...],
+    // or an entity type tag, such as "#minecraft:skeletons".
+    "entity_types": "#namespace:entitytype_tag"
+}
+```
+
+</TabItem>
+<TabItem value="datagen" label="Datagen">
+
+```java
+// Define the ResourceKey for our BiomeModifier.
+public static final ResourceKey<BiomeModifier> REMOVE_SPAWNS_EXAMPLE = ResourceKey.create(
+    NeoForgeRegistries.Keys.BIOME_MODIFIERS, // The registry this key is for
+    ResourceLocation.fromNamespaceAndPath(MOD_ID, "remove_spawns_example") // The registry name
+);
+
+// BUILDER is a RegistrySetBuilder passed to DatapackBuiltinEntriesProvider
+// in a listener for GatherDataEvent.
+BUILDER.add(NeoForgeRegistries.Keys.BIOME_MODIFIERS, bootstrap -> {
+    // Lookup any necessary registries.
+    // Static registries only need to be looked up if you need to grab the tag data.
+    HolderGetter<Biome> biomes = bootstrap.lookup(Registries.BIOME);
+    HolderGetter<EntityType<?>> entities = bootstrap.lookup(Registries.ENTITY_TYPE);
+
+    // Register the biome modifiers.
+    bootstrap.register(REMOVE_SPAWNS_EXAMPLE,
+        new RemoveSpawnsBiomeModifier(
+            // The biome(s) to remove the spawns from
+            biomes.getOrThrow(Tags.Biomes.IS_OVERWORLD),
+            // The entities to remove spawns for
+            entities.getOrThrow(EntityTypeTags.SKELETONS)
+        )
+    );
+});
+```
+
+</TabItem>
+</Tabs>
+
+
+### Add Spawn Costs
+
+Allows for adding new spawn costs to biomes. Spawn costs are a newer way of making mobs spawn spread out in a biome to reduce clustering. It works by having the entities give off a `charge` that surrounds them and adds up with other entities' `charge`. When spawning a new entity, the spawning algorithm looks for a spot where the total `charge` field at the location multiplied by the spawning entity's `charge` value is less than the spawning entity's `energy_budget`. This is an advanced way of spawning mobs, so it is a good idea to reference the Soul Sand Valley biome (which is the most prominent user of this system) for existing values to borrow.
+
+The modifier takes in the biome id or tag of the biomes the spawn costs are added to, the `EntityType` id or tag of the entity types to add spawn costs for, and the `MobSpawnSettings.MobSpawnCost` of the entity. The `MobSpawnCost` contains the energy budget, which indicates the maximum number of entities that can spawn in a location based on the charge provided for each entity spawned.
+
+:::note
+If you are a modder adding a new entity, make sure the entity has a spawn restriction registered to `RegisterSpawnPlacementsEvent`.
+:::
+
+<Tabs>
+<TabItem value="json" label="JSON" default>
+
+```json5
+{
+    "type": "neoforge:add_spawn_costs",
+    // Can either be a biome id, such as "minecraft:plains",
+    // or a list of biome ids, such as ["minecraft:plains", "minecraft:badlands", ...],
+    // or a biome tag, such as "#c:is_overworld".
+    "biomes": "#namespace:biome_tag",
+    // Can either be an entity type id, such as "minecraft:ghast",
+    // or a list of entity type ids, such as ["minecraft:ghast", "minecraft:skeleton", ...],
+    // or an entity type tag, such as "#minecraft:skeletons".
+    "entity_types": "#minecraft:skeletons",
+    "spawn_cost": {
+        // The energy budget
+        "energy_budget": 1.0,
+        // The amount of charge each entity takes up from the budget
+        "charge": 0.1
+    }
+}
+```
+
+</TabItem>
+<TabItem value="datagen" label="Datagen">
+
+```java
+// Define the ResourceKey for our BiomeModifier.
+public static final ResourceKey<BiomeModifier> ADD_SPAWN_COSTS_EXAMPLE = ResourceKey.create(
+    NeoForgeRegistries.Keys.BIOME_MODIFIERS, // The registry this key is for
+    ResourceLocation.fromNamespaceAndPath(MOD_ID, "add_spawn_costs_example") // The registry name
+);
+
+// BUILDER is a RegistrySetBuilder passed to DatapackBuiltinEntriesProvider
+// in a listener for GatherDataEvent.
+BUILDER.add(NeoForgeRegistries.Keys.BIOME_MODIFIERS, bootstrap -> {
+    // Lookup any necessary registries.
+    // Static registries only need to be looked up if you need to grab the tag data.
+    HolderGetter<Biome> biomes = bootstrap.lookup(Registries.BIOME);
+    HolderGetter<EntityType<?>> entities = bootstrap.lookup(Registries.ENTITY_TYPE);
+
+    // Register the biome modifiers.
+    bootstrap.register(ADD_SPAWN_COSTS_EXAMPLE,
+        new AddSpawnCostsBiomeModifier(
+            // The biome(s) to add the spawn costs to
+            biomes.getOrThrow(Tags.Biomes.IS_OVERWORLD),
+            // The entities to add the spawn costs for
+            entities.getOrThrow(EntityTypeTags.SKELETONS),
+            new MobSpawnSettings.MobSpawnCost(
+                1.0, // The energy budget
+                0.1  // The amount of charge each entity takes up from the budget
+            )
+        )
+    );
+});
+```
+
+</TabItem>
+</Tabs>
+
+
+### Remove Spawn Costs
+
+Allows for removing a spawn cost from a biome. Spawn costs are a newer way of making mobs spawn spread out in a biome to reduce clustering. The modifier takes in the biome id or tag of the biomes the spawn costs are removed from, and the `EntityType` id or tag of the entities to remove the spawn cost for.
+
+<Tabs>
+<TabItem value="json" label="JSON" default>
+
+```json5
+{
+    "type": "neoforge:remove_spawn_costs",
+    // Can either be a biome id, such as "minecraft:plains",
+    // or a list of biome ids, such as ["minecraft:plains", "minecraft:badlands", ...],
+    // or a biome tag, such as "#c:is_overworld".
+    "biomes": "#namespace:biome_tag",
+    // Can either be an entity type id, such as "minecraft:ghast",
+    // or a list of entity type ids, such as ["minecraft:ghast", "minecraft:skeleton", ...],
+    // or an entity type tag, such as "#minecraft:skeletons".
+    "entity_types": "#minecraft:skeletons"
+}
+```
+
+</TabItem>
+<TabItem value="datagen" label="Datagen">
+
+```java
+// Define the ResourceKey for our BiomeModifier.
+public static final ResourceKey<BiomeModifier> REMOVE_SPAWN_COSTS_EXAMPLE = ResourceKey.create(
+    NeoForgeRegistries.Keys.BIOME_MODIFIERS, // The registry this key is for
+    ResourceLocation.fromNamespaceAndPath(MOD_ID, "remove_spawn_costs_example") // The registry name
+);
+
+// BUILDER is a RegistrySetBuilder passed to DatapackBuiltinEntriesProvider
+// in a listener for GatherDataEvent.
+BUILDER.add(NeoForgeRegistries.Keys.BIOME_MODIFIERS, bootstrap -> {
+    // Lookup any necessary registries.
+    // Static registries only need to be looked up if you need to grab the tag data.
+    HolderGetter<Biome> biomes = bootstrap.lookup(Registries.BIOME);
+    HolderGetter<EntityType<?>> entities = bootstrap.lookup(Registries.ENTITY_TYPE);
+
+    // Register the biome modifiers.
+    bootstrap.register(REMOVE_SPAWN_COSTS_EXAMPLE,
+        new RemoveSpawnCostsBiomeModifier(
+            // The biome(s) to remove the spawn costs from
+            biomes.getOrThrow(Tags.Biomes.IS_OVERWORLD),
+            // The entities to remove spawn costs for
+            entities.getOrThrow(EntityTypeTags.SKELETONS)
+        )
+    );
+});
+```
+
+</TabItem>
+</Tabs>
+
+
+### Add Legacy Carvers
+
+This biome modifier type allows adding carver caves and ravines to biomes. These are what was used for cave generation before the Caves and Cliffs update. It CANNOT add noise caves to biomes, because noise caves are a part of certain noise-based chunk generator systems and not actually tied to biomes.
+
+<Tabs>
+<TabItem value="json" label="JSON" default>
+
+```json5
+    {
+    "type": "neoforge:add_carvers",
+    // Can either be a biome id, such as "minecraft:plains",
+    // or a list of biome ids, such as ["minecraft:plains", "minecraft:badlands", ...],
+    // or a biome tag, such as "#c:is_overworld".
+    "biomes": "minecraft:plains",
+    // Can either be a carver id, such as "examplemod:add_carvers_example",
+    // or a list of carver ids, such as ["examplemod:add_carvers_example", "minecraft:canyon", ...],
+    // or a carver tag, such as "#examplemod:configured_carver_tag".
+    "carvers": "examplemod:add_carvers_example"
+}
+```
+
+</TabItem>
+<TabItem value="datagen" label="Datagen">
+
+```java
+// Assume we have some ConfiguredWorldCarver named EXAMPLE_CARVER.
+// Define the ResourceKey for our BiomeModifier.
+public static final ResourceKey<BiomeModifier> ADD_CARVERS_EXAMPLE = ResourceKey.create(
+    NeoForgeRegistries.Keys.BIOME_MODIFIERS, // The registry this key is for
+    ResourceLocation.fromNamespaceAndPath(MOD_ID, "add_carvers_example") // The registry name
+);
+
+// BUILDER is a RegistrySetBuilder passed to DatapackBuiltinEntriesProvider
+// in a listener for GatherDataEvent.
+BUILDER.add(NeoForgeRegistries.Keys.BIOME_MODIFIERS, bootstrap -> {
+    // Lookup any necessary registries.
+    // Static registries only need to be looked up if you need to grab the tag data.
+    HolderGetter<Biome> biomes = bootstrap.lookup(Registries.BIOME);
+    HolderGetter<ConfiguredWorldCarver<?>> carvers = bootstrap.lookup(Registries.CONFIGURED_CARVER);
+
+    // Register the biome modifiers.
+    bootstrap.register(ADD_CARVERS_EXAMPLE,
+        new AddCarversBiomeModifier(
+            // The biome(s) to generate within
+            HolderSet.direct(biomes.getOrThrow(Biomes.PLAINS)),
+            // The carver(s) to generate within the biomes
+            HolderSet.direct(carvers.getOrThrow(EXAMPLE_CARVER))
+        )
+    );
+});
+```
+
+</TabItem>
+</Tabs>
+
+### Removing Legacy Carvers
+
+This biome modifier type allows removing carver caves and ravines from biomes. These are what was used for cave generation before the Caves and Cliffs update. It CANNOT remove noise caves from biomes, because noise caves are baked into the dimension's noise settings system and not actually tied to biomes.
+
+<Tabs>
+<TabItem value="json" label="JSON" default>
+
+```json5
+{
+    "type": "neoforge:remove_carvers",
+    // Can either be a biome id, such as "minecraft:plains",
+    // or a list of biome ids, such as ["minecraft:plains", "minecraft:badlands", ...],
+    // or a biome tag, such as "#c:is_overworld".
+    "biomes": "minecraft:plains",
+    // Can either be a carver id, such as "examplemod:add_carvers_example",
+    // or a list of carver ids, such as ["examplemod:add_carvers_example", "minecraft:canyon", ...],
+    // or a carver tag, such as "#examplemod:configured_carver_tag".
+    "carvers": "examplemod:add_carvers_example"
+}
+```
+
+</TabItem>
+<TabItem value="datagen" label="Datagen">
+
+```java
+// Define the ResourceKey for our BiomeModifier.
+public static final ResourceKey<BiomeModifier> REMOVE_CARVERS_EXAMPLE = ResourceKey.create(
+    NeoForgeRegistries.Keys.BIOME_MODIFIERS, // The registry this key is for
+    ResourceLocation.fromNamespaceAndPath(MOD_ID, "remove_carvers_example") // The registry name
+);
+
+// BUILDER is a RegistrySetBuilder passed to DatapackBuiltinEntriesProvider
+// in a listener for GatherDataEvent.
+BUILDER.add(NeoForgeRegistries.Keys.BIOME_MODIFIERS, bootstrap -> {
+    // Lookup any necessary registries.
+    // Static registries only need to be looked up if you need to grab the tag data.
+    HolderGetter<Biome> biomes = bootstrap.lookup(Registries.BIOME);
+    HolderGetter<ConfiguredWorldCarver<?>> carvers = bootstrap.lookup(Registries.CONFIGURED_CARVER);
+
+    // Register the biome modifiers.
+    bootstrap.register(REMOVE_CARVERS_EXAMPLE,
+        new AddFeaturesBiomeModifier(
+            // The biome(s) to remove from
+            biomes.getOrThrow(Tags.Biomes.IS_OVERWORLD),
+            // The carver(s) to remove from the biomes
+            HolderSet.direct(carvers.getOrThrow(Carvers.CAVE))
+        )
+    );
+});
+```
+
+</TabItem>
+</Tabs>
+
+### Available Values for Decoration Steps
+
+The `step` or `steps` fields in many of the aforementioned JSONs are referring to the `GenerationStep.Decoration` enum. This enum has the steps listed out in the following order, which is the same order that the game uses for generating during worldgen. Try to put features in the step that makes the most sense for them.
+
+|           Step           | Description                                                                             |
+|:------------------------:|:----------------------------------------------------------------------------------------|
+|     `raw_generation`     | First to run. This is used for special terrain-like features such as Small End Islands. |
+|         `lakes`          | Dedicated to spawning pond-like feature such as Lava Lakes.                             |
+|  `local_modifications`   | For modifications to terrain such as Geodes, Icebergs, Boulders, or Dripstone.          |
+| `underground_structures` | Used for small underground structure-like features such as Dungeons or Fossils.         |
+|   `surface_structures`   | For small surface only structure-like features such as Desert Wells.                    |
+|      `strongholds`       | Dedicated for Stronghold structures. No feature is added here in unmodified Minecraft.  |
+|    `underground_ores`    | The step for all Ores and Veins to be added to. This includes Gold, Dirt, Granite, etc. |
+| `underground_decoration` | Used typically for decorating caves. Dripstone Cluster and Sculk Vein are here.         |
+|     `fluid_springs`      | The small Lavafalls and Waterfalls come from features in this stage.                    |
+|   `vegetal_decoration`   | Nearly all plants (flowers, trees, vines, and more) are added to this stage.            |
+| `top_layer_modification` | Last to run. Used for placing Snow and Ice on the surface of cold biomes.               |
+
+
+## Creating Custom Biome Modifiers
+
+### The `BiomeModifier` Implementation
+
+Under the hood, Biome Modifiers are made up of three parts:
+
+- The [datapack registered][datareg] `BiomeModifier` used to modify the biome builder.
+- The [statically registered][staticreg] `MapCodec` that encodes and decodes the modifiers.
+- The JSON that constructs the `BiomeModifier`, using the registered id of the `MapCodec` as the indexable type.
+
+A `BiomeModifier` contains two methods: `#modify` and `#codec`. `modify` takes in a `Holder` of the current `Biome`, the current `BiomeModifier.Phase`, and the builder of the biome to modify. Every `BiomeModifier` is called once per `Phase` to organize when certain modifications to the biome should occur:
+
+| Phase               | Description                                                              |
+|:-------------------:|:-------------------------------------------------------------------------|
+| `BEFORE_EVERYTHING` | A catch-all for everything that needs to run before the standard phases. |
+| `ADD`               | Adding features, mob spawns, etc.                                        |
+| `REMOVE`            | Removing features, mob spawns, etc.                                      |
+| `MODIFY`            | Modifying single values (e.g., climate, colors).                         |
+| `AFTER_EVERYTHING`  | A catch-all for everything that needs to run after the standard phases.  |
+
+All `BiomeModifier`s contain a `type` key that references the id of the `MapCodec` used for the `BiomeModifier`. The `codec` takes in the `MapCodec` that encodes and decodes the modifiers. This `MapCodec` is [statically registered][staticreg], with its id used as the `type` of the `BiomeModifier`.
+
+```java
+public record ExampleBiomeModifier(HolderSet<Biome> biomes, int value) implements BiomeModifier {
+    
+    @Override
+    public void modify(Holder<Biome> biome, Phase phase, ModifiableBiomeInfo.BiomeInfo.Builder builder) {
+        if (phase == /* Pick the phase that best matches what your want to modify */) {
+            // Modify the 'builder', checking any information about the biome itself
+        }
+    }
+
+    @Override
+    public MapCodec<? extends BiomeModifier> codec() {
+        return EXAMPLE_BIOME_MODIFIER.value();
+    }
+}
+
+// In some registration class
+private static final DeferredRegister<MapCodec<? extends BiomeModifier>> BIOME_MODIFIERS =
+    DeferredRegister.create(NeoForgeRegistries.Keys.BIOME_MODIFIER_SERIALIZERS, MOD_ID);
+
+public static final Holder<MapCodec<? extends BiomeModifier>> EXAMPLE_BIOME_MODIFIER =
+    BIOME_MODIFIERS.register("example_biome_modifier", () -> RecordCodecBuilder.mapCodec(instance ->
+        instance.group(
+            Biome.LIST_CODEC.fieldOf("biomes").forGetter(ExampleBiomeModifier::biomes),
+            Codec.INT.fieldOf("value").forGetter(ExampleBiomeModifier::value)
+        ).apply(instance, ExampleBiomeModifier::new)
+    ));
+```
+
+
+## Datagenning Biome Modifiers
+
+A `BiomeModifier` JSON can be created through [data generation][datagen] by passing a `RegistrySetBuilder` to `DatapackBuiltinEntriesProvider`. The JSON will be placed at `data/<modid>/neoforge/biome_modifier/<path>.json`.
+
+For more information on how `RegistrySetBuilder` and `DatapackBuiltinEntriesProvider` work, please see the article on [Data Generation for Datapack Registries][datapackdatagen].
+
+```java
+// Define the ResourceKey for our BiomeModifier.
+public static final ResourceKey<BiomeModifier> EXAMPLE_MODIFIER = ResourceKey.create(
+    NeoForgeRegistries.Keys.BIOME_MODIFIERS, // The registry this key is for
+    ResourceLocation.fromNamespaceAndPath(MOD_ID, "example_modifier") // The registry name
+);
+
+// BUILDER is a RegistrySetBuilder passed to DatapackBuiltinEntriesProvider
+// in a listener for GatherDataEvent.
+BUILDER.add(NeoForgeRegistries.Keys.BIOME_MODIFIERS, bootstrap -> {
+    // Lookup any necessary registries.
+    // Static registries only need to be looked up if you need to grab the tag data.
+    HolderGetter<Biome> biomes = bootstrap.lookup(Registries.BIOME);
+
+    // Register the biome modifiers.
+    bootstrap.register(EXAMPLE_MODIFIER,
+        new ExampleBiomeModifier(
+            biomes.getOrThrow(Tags.Biomes.IS_OVERWORLD),
+            20
+        )
+    );
+});
+```
+
+This will then result in the following JSON being created:
+
+```json5
+// In data/examplemod/neoforge/biome_modifier/example_modifier.json
+{
+    // The registy key of the MapCodec for the modifier
+    "type": "examplemod:example_biome_modifier",
+    // All additional settings are applied to the root object
+    "biomes": "#c:is_overworld",
+    "value": 20
+}
+```
+
+## Targeting Biomes That May Not Exist
+
+There may be times when a biome modifier needs to target a biome that is not always present in the game. If a biome modifier targets the unregistered biome directly, it will crash on world loading. The way to work around this is to create a biome tag and add the target biome as an optional tag entry by setting required to false for the entry. An example is below:
+
+```json5
+{
+    "replace": false,
+    "values": [
+        {
+            "id": "minecraft:pale_garden",
+            "required": false
+        }
+    ]
+}
+```
+
+Using that biome tag for a biome modifier will now not crash if the biome is not registered. One such use case is the Pale Garden biome, which is only created in 1.21.3 when the Winter Drop datapack is turned on. Otherwise, the biome does not exist in the biome registry at all. Another use case can be to target modded biomes while still functioning when the mods adding these biomes are not present.
+
+To datagen optional entries for biome tags, the datagen code would look something along these lines:
+
+```java
+// In a TagsProvider<Biome> subclass
+// Assume we have some example TagKey<Biome> OPTIONAL_BIOMES_TAG
+@Override
+protected void addTags(HolderLookup.Provider registries) {
+    this.tag(OPTIONAL_BIOMES_TAG)
+        // Must be a ResourceLocation representing the registry object
+        .addOptional(WinterDropBiomes.PALE_GARDEN.location());
+}
+```
+
+[datareg]: ../concepts/registries.md#datapack-registries
+[staticreg]: ../concepts/registries.md#methods-for-registering
+[datapacks]: ../resources/index.md#data
+[datagen]: ../resources/index.md#data-generation
+[datapackdatagen]: ../concepts/registries#data-generation-for-datapack-registries
\ No newline at end of file
diff --git a/versioned_sidebars/version-1.21.3-sidebars.json b/versioned_sidebars/version-1.21.3-sidebars.json
new file mode 100644
index 00000000..eac3a785
--- /dev/null
+++ b/versioned_sidebars/version-1.21.3-sidebars.json
@@ -0,0 +1,8 @@
+{
+  "mainSidebar": [
+    {
+      "type": "autogenerated",
+      "dirName": "."
+    }
+  ]
+}
\ No newline at end of file
diff --git a/versions.json b/versions.json
index cbd4557e..1681f389 100644
--- a/versions.json
+++ b/versions.json
@@ -1,4 +1,5 @@
 [
+    "1.21.3",
     "1.21.1",
     "1.20.6",
     "1.20.4"