Update to 1.21.4

docs/advanced/featureflags.md

@@ -170,7 +170,7 @@ This file differs from the one in your mod's `resources/` directory. This file d
             "examplemod:experimental"
         ]
     },
-    "pack": { ... }
+    "pack": { /*...*/ }
 }
 ```
 

docs/blockentities/ber.md

@@ -60,74 +60,16 @@ public static void registerEntityRenderers(EntityRenderersEvent.RegisterRenderer
 }
 ```
 
-## `BlockEntityWithoutLevelRenderer`
+## Item Block Rendering
 
-`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.
+As not all block entities with renderers can be rendered using static models, you can create a special renderer to customize the item rendering process. This is done using [`SpecialModelRenderer`s][special]. In these cases, both a special model renderer must be created to render the item correctly, and a corresponding registered special block model renderer for scenarios when a block is being rendered as an item (e.g., enderman carrying a block).
 
-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",
-    // ...
-}
-```
+How to do so can be found within the [client item documentation][special].
 
 [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
+[special]: ../resources/client/models/items.md#special-models

docs/blocks/index.md

@@ -120,7 +120,7 @@ public static final DeferredRegister<MapCodec<? extends Block>> REGISTRAR = Defe
 
 public static final Supplier<MapCodec<SimpleBlock>> SIMPLE_CODEC = REGISTRAR.register(
     "simple",
-    () -> simpleCodec(SimpleBlock::new)
+    () -> BlockBehaviour.simpleCodec(SimpleBlock::new)
 );
 ```
 

docs/concepts/events.md

@@ -197,12 +197,12 @@ Then, during `InterModProcessEvent`, you can use `InterModComms#getMessages` to
 
 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` 
+- `RegisterColorHandlersEvent.Block`, `.ItemTintSources`, `.ColorResolvers` 
 - `ModelEvent.BakingCompleted`
 - `TextureAtlasStitchedEvent`
 
 :::warning
-Most of these events are planned to be moved to the main event bus in a future version.
+Most of these events are planned to be moved to the game event bus in a future version.
 :::
 
 [modbus]: #event-buses

docs/concepts/registries.md

@@ -43,14 +43,14 @@ We can then add our registry entries as static final fields using one of the fol
 ```java
 public static final DeferredHolder<Block, Block> EXAMPLE_BLOCK_1 = BLOCKS.register(
         // Our registry name.
-        "example_block" 
+        "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" 
+        "example_block",
         // A function creating the object we want to register
         // given its registry name as a ResourceLocation.
         registryName -> new SlabBlock(...)
@@ -64,14 +64,14 @@ The class `DeferredHolder<R, T extends R>` holds our object. The type parameter
 ```java
 public static final Supplier<Block> EXAMPLE_BLOCK_1 = BLOCKS.register(
         // Our registry name.
-        "example_block" 
+        "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" 
+        "example_block",
         // A function creating the object we want to register
         // given its registry name as a ResourceLocation.
         registryName -> new SlabBlock(...)
@@ -236,7 +236,10 @@ public static void registerDatapackRegistries(DataPackRegistryEvent.NewRegistry
             // 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
+            Spell.CODEC,
+            // A consumer which configures the constructed registry via the RegistryBuilder.
+            // May be omitted, which is functionally identical to passing builder -> {}.
+            builder -> builder.maxId(256)
     );
 }
 ```

docs/datastorage/attachments.md

@@ -3,7 +3,7 @@ sidebar_position: 3
 ---
 # Data Attachments
 
-The data attachment system allows mods to attach and store additional data on block entities, chunks, and entities.
+The data attachment system allows mods to attach and store additional data on block entities, chunks, entities, and levels.
 
 _To store additional level data, you can use [SavedData][saveddata]._
 

docs/gettingstarted/index.md

@@ -55,7 +55,7 @@ You should always test your mod in a dedicated server environment. This includes
 [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-ModDevGradle
-[ngmdk]: https://github.com/NeoForgeMDKs/MDK-1.21-NeoGradle
+[mdgmdk]: https://github.com/NeoForgeMDKs/MDK-1.21.4-ModDevGradle
+[ngmdk]: https://github.com/NeoForgeMDKs/MDK-1.21.4-NeoGradle
 [neogradle]: https://docs.neoforged.net/neogradle/docs/
 [properties]: modfiles.md#gradleproperties

docs/gettingstarted/modfiles.md

@@ -12,6 +12,9 @@ Most values are also explained as comments in [the MDK's `gradle.properties` fil
 |---------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------|
 | `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.parallel`     | Whether Gradle should fork JVMs to execute projects in parallel.                                                                                                                                                                                     | `org.gradle.parallel=false`                  |
+| `org.gradle.caching`      | Whether Gradle should reuse task outputs from previous builds.                                                                                                                                                                                     | `org.gradle.caching=false`                  |
+| `org.gradle.configuration-cache`  | Whether Gradle should reuse the build configuration from previous builds.                                                                                                                                                                                     | `org.gradle.configuration-cache=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)`    |