Proofread 2025-06-15-1216.md (#132)

Emirlol · web-flow · commit 7f69a1c56c66 · 2025-06-17T15:42:06.000+01:00
diff --git a/_posts/2025-06-15-1216.md b/_posts/2025-06-15-1216.md
@@ -22,14 +22,14 @@ The following modules have been merged into other modules for simplicity:
 * `fabric-client-tags-api-v1` was merged into `fabric-tag-api-v1` ([#4647](https://github.com/FabricMC/fabric/pull/4647))
 * `fabric-blockrenderlayer-v1` was merged into `fabric-rendering-v1` ([#4675](https://github.com/FabricMC/fabric/pull/4675))
 
-The tag api changes are technically breaking for some developers who explicitly depend on these modules. The removal and merging of these modules has been done to help improve peformance when setting up a new development environment.
+The tag API changes are technically breaking for some developers who explicitly depend on these modules. The removal and merging of these modules has been done to help improve peformance when setting up a new development environment.
 
 The Fabric Rendering API previously provided a Material API, to allow modders more control of the way their models rendered. This has been removed.
 > Materials were removed ... because they were deemed to be an unnecessary part of the API design, and the breaking change induced by changes in 1.21.6 was related to materials, which made this the perfect time to remove them - PepperCode1
 
-See [#4675](https://github.com/FabricMC/fabric/pull/4675) for more info.
+See ([#4675](https://github.com/FabricMC/fabric/pull/4675)) for more info.
 
-In addition to being relocated, the `BlockRenderLayerMap` API was also updated to be more consistent out current api style:
+In addition to being relocated, the `BlockRenderLayerMap` API was also updated to be more consistent out current API style:
 ```diff
 - import net.fabricmc.fabric.api.blockrenderlayer.v1.BlockRenderLayerMap;
 + import net.fabricmc.fabric.api.client.rendering.v1.BlockRenderLayerMap;
@@ -40,7 +40,7 @@ In addition to being relocated, the `BlockRenderLayerMap` API was also updated t
 See ([#4664](https://github.com/FabricMC/fabric/pull/4664)) for more info.
 ### Breaking changes
 
-Fabric's brand new HUD api had to be tottaly rewritten in 1.21.6. The new `HudElementRegistry` provides all of the functionality provided by the old API. The following basic example shows how you can draw text after all of the vanilla HUD layers.
+Fabric's brand new HUD API had to be totally rewritten in 1.21.6. The new `HudElementRegistry` provides all of the functionality provided by the old API. The following basic example shows how you can draw text after all of the vanilla HUD layers:
 
 ```java
 HudElementRegistry.addLast(Identifier.of("example", "hud"), (context, tickCounter) -> {
@@ -51,30 +51,30 @@ HudElementRegistry.addLast(Identifier.of("example", "hud"), (context, tickCounte
 If you wish to render your custom hud element before the vanilla chat you can do the following:
 ```java
 HudElementRegistry.attachElementBefore(VanillaHudElements.CHAT, Identifier.of("example", "ud"), (context, tickCounter) -> {
-	/* Render here */
+	// ...
 });
 ```
 
 
 ### New Fabric API features
 
-Since `Item#appendTooltip` has become deprecated, Fabric API now provides the `ComponentTooltipAppenderRegistry`. This registry provides  `addAfter`, `addBefore`, `addFirst`, and `addLast` to allow you to position your tooltips relative to vanilla and other mods.
+Since `Item#appendTooltip` has become deprecated, Fabric API now provides the `ComponentTooltipAppenderRegistry`. This registry provides `addAfter`, `addBefore`, `addFirst`, and `addLast` to allow you to position your tooltips relative to vanilla and other mods.
 ```java
-record MyAmazingComponent() implements TooltipAppender {  
-    @Override  
-  public void appendTooltip(Item.TooltipContext context, Consumer<Text> textConsumer, TooltipType type, ComponentsAccess components) {  
-       textConsumer.accept(Text.literal("Amazingness Awaits!"));  
-    }  
+record MyAmazingComponent() implements TooltipAppender {
+	@Override
+	public void appendTooltip(Item.TooltipContext context, Consumer<Text> textConsumer, TooltipType type, ComponentsAccess components) {
+		textConsumer.accept(Text.literal("Amazingness Awaits!"));
+	}
 }
-ComponentType<MyAmazingComponent> myAmazingComponentComponentType = /*omitted for brevity*/;
+ComponentType<MyAmazingComponent> myAmazingComponentComponentType = /*...*/;
 ComponentTooltipAppenderRegistry.addAfter(
-	DataComponentTypes.DAMAGE, 
+	DataComponentTypes.DAMAGE,
 	myAmazingComponentComponentType
 );
 ```
-Any `ItemStack` that has your component applied will call your components appendTooltip method, allowing you to append as you wish. ([#4587](https://github.com/FabricMC/fabric/pull/4587))
+Any `ItemStack` that has your component applied will call your component's `appendTooltip` method, allowing you to append as you wish. ([#4587](https://github.com/FabricMC/fabric/pull/4587))
 
-The LootTable API has been expanded to make certain extreme usages more convenient. The  `LootTableEvents.MODIFY_DROPS` event allows modders to customize the collective output of `LootTable`s. The `LootTableEvents.MODIFY` event should still be preferred when possible, for mod compatibility reasons. This event may also recurse if you generate loot from within a listener. ([#4643](https://github.com/FabricMC/fabric/pull/4643))
+The LootTable API has been expanded to make certain extreme usages more convenient. The `LootTableEvents.MODIFY_DROPS` event allows modders to customize the collective output of `LootTable`s. The `LootTableEvents.MODIFY` event should still be preferred when possible, for mod compatibility reasons. This event may also recurse if you generate loot from within a listener. ([#4643](https://github.com/FabricMC/fabric/pull/4643))
 ```java
 var matchGetter = ServerRecipeManager.createCachedMatchGetter(RecipeType.SMELTING);
 
@@ -86,32 +86,31 @@ LootTableEvents.MODIFY_DROPS.register((entry, context, drops) -> {
 	if (!tool.isOf(Items.DIAMOND_PICKAXE)) return;
 	var world = context.getWorld();
 	var lookup = world.getRegistryManager();
-	drops.replaceAll(drop -> {
-		return matchGetter
-				.getFirstMatch(new SingleStackRecipeInput(drop), world)
-				.map(RecipeEntry::value)
-				.map(recipe -> recipe.craft(input, lookup))
-				.orElse(drop);
-	});
+	drops.replaceAll(drop ->
+		matchGetter.getFirstMatch(new SingleStackRecipeInput(drop), world)
+			.map(RecipeEntry::value)
+			.map(recipe -> recipe.craft(input, lookup))
+			.orElse(drop)
+	);
 });
-``` 
-Continuing with our conventional tag api, We added new biome tags, allowing modders to differentiate biomes based on their primary wood type.
-The `ServerChunkEvents.CHUNK_LEVEL_TYPE_CHANGE` was added to allow more control over the timing of chunk events. This event fires for changes in chunk loading level, to react to changes not previously possible without mixins. ([#4541](https://github.com/FabricMC/fabric/pull/4541))
+```
+Continuing with our conventional tag API, we added new biome tags, allowing modders to differentiate biomes based on their primary wood type.
+The `ServerChunkEvents.CHUNK_LEVEL_TYPE_CHANGE` event was added to allow more control over the timing of chunk events. This event fires for changes in chunk loading level, to react to changes not previously possible without mixins. ([#4541](https://github.com/FabricMC/fabric/pull/4541))
 
 An event was added for attachment changes, allowing reaction to an attachment value changing. This event can be recursive in nature, as if you set an attachment value from within a listener, the event will be invoked again. Modders should use proper recursion techniques to prevent infinite recursion. ([#4606](https://github.com/FabricMC/fabric/pull/4606))
 
 
-Still more events were added for Players leaving and joining the game:
+Two more events were added for players joining and leaving the game:
 ```java
-AttachmentType<Instant> JOINED_TIME = /**/; 
+AttachmentType<Instant> JOINED_TIME = /*...*/;
 ServerPlayerEvents.JOIN.register(player -> {
-    // runs on the main thread, no need to use player.getServer().execute(() -> ...);
-    player.setAttached(JOINED_TIME, Instant.now());
+	// runs on the main thread, no need to use player.getServer().execute(() -> ...);
+	player.setAttached(JOINED_TIME, Instant.now());
 });
 ```
 ```java
-List<ServerPlayerEntity> activePlayers = /**/;
-ServerPlayerEvents.LEAVE.register(activePlayers::remove); 
+List<ServerPlayerEntity> activePlayers = /*...*/;
+ServerPlayerEvents.LEAVE.register(activePlayers::remove);
 ```
 These events are designed for initializing and de-initializing state related to players, and run along vanilla code with the same purpose on the main thread, unlike the current events. ([#4642](https://github.com/FabricMC/fabric/pull/4642))
 
@@ -126,78 +125,79 @@ public static final ModelKey<BlockStateModel> HALF_RED_SAND_MODEL_KEY = ModelKey
 public static final Identifier HALF_RED_SAND_MODEL_ID = id("half_red_sand");
 
 public static void init() {
-  ModelLoadingPlugin.register(pluginContext -> {
-    pluginContext.addModel(HALF_RED_SAND_MODEL_KEY, HALF_RED_SAND_MODEL_ID, (model, baker) -> {
-      ModelTextures textures = model.getTextures();
-      return new SimpleBlockStateModel(new GeometryBakedModel(
-        model.bakeGeometry(textures, baker, ModelRotation.X0_Y0),
-        model.getAmbientOcclusion(),
-        model.getParticleTexture(textures, baker)
-      ));
-    });
+	ModelLoadingPlugin.register(pluginContext -> {
+		pluginContext.addModel(HALF_RED_SAND_MODEL_KEY, HALF_RED_SAND_MODEL_ID, (model, baker) -> {
+			ModelTextures textures = model.getTextures();
+			return new SimpleBlockStateModel(new GeometryBakedModel(
+				model.bakeGeometry(textures, baker, ModelRotation.X0_Y0),
+				model.getAmbientOcclusion(),
+				model.getParticleTexture(textures, baker)
+			));
+		});
+	})
 }
 
 public static BlockStateModel getModel() {
-  return MinecraftClient.getInstance().getBakedModelManager().getModel(HALF_RED_SAND_MODEL_KEY);
+	return MinecraftClient.getInstance().getBakedModelManager().getModel(HALF_RED_SAND_MODEL_KEY);
 }
 ```
 
-`FabricTrackedDataRegistry` has been added to allow registering of tracked data handlers for entities. This removes conflicts between mods registering tracked data handlers and ensures that the order is consistent between the client and server. If you previouly used the vanilla API the following 1 line change is all you need to take advantage of this new API:
+`FabricTrackedDataRegistry` has been added to allow registering tracked data handlers for entities. This removes conflicts between mods registering tracked data handlers and ensures that the order is consistent between the client and server. If you previously used the vanilla API the following 1 line change is all you need to take advantage of this new API:
 
 ```diff
 - TrackedDataHandlerRegistry.register(TRACKED_DATA_HANDLER);
 + FabricTrackedDataRegistry.registerHandler(TRACKED_DATA_HANDLER_ID, TRACKED_DATA_HANDLER);
 ```
 
 ### Bug Fixes
-Due to diligent developers and players, Many bugs in Fabric API were reported and patched during this update cycle. See [The Fabric Github](https://github.com/FabricMC/fabric/pulls?q=is%3Apr+is%3Aclosed+label%3Abug) for more info. 
+Thanks to the diligent developers and players, many bugs in Fabric API were reported and patched during this update cycle. See [The Fabric Github](https://github.com/FabricMC/fabric/pulls?q=is%3Apr+is%3Aclosed+label%3Abug) for more info.
 ## Minecraft changes
 ### Rendering
 Mojang is currently working on separating Minecraft's rendering pipeline into two stages:
 1. The extraction stage, where all renderable data is seperated from the game
 2. The render phase, where the previously extracted data is rendered.
 
-This process began in 1.21.2, and is still incomplete as of this update. Chunk rendering, GUI rendering and HUD rendering have all been converted to use the new separate rendering style. The ultimate goal of this separation is to enable the game to render one frame while the next is being extracted.
+This process began in 1.21.2, and is still incomplete as of this update. Chunk, GUI and HUD rendering have all been converted to use the new separate rendering style. The ultimate goal of this separation is to enable the game to render one frame while the next is being extracted.
 
-Many methods in `RenderSystem` have been removed without direct replacement.  In most cases, there isn't a one-to-one translation from the old code to the new, but the same capabilities exist by combining the new `RenderPipline`s with `RenderLayer`s
+Many methods in `RenderSystem` have been removed without direct replacement. In most cases, there isn't a one-to-one translation from the old code to the new, but the same capabilities exist by combining the new `RenderPipeline`s with `RenderLayer`s.
 
 ### NBT
 
-`BlockEntity`s now abstract saving to NBT through `(Read|Write)View`s. These views are responsible for storing errors from encoding / decoding, and keeping track of registries throughout the serialization process. You can read from a `ReadView` using the `read` method, passing in a `Codec` for the desired type. Likewise, you can write to a `WriteView` by using the `put` method, passing in a `Codec` for the type, and the value in question. there are also methods for primitives, under `get(Int, Short, Boolean, ...)` and `put(Int, Short, Boolean, ...)`. The View also provides methods for working with lists, nullable types, and nested objects. 
+`BlockEntity`s now abstract saving to NBT through `ReadView`s and `WriteView`s. These views are responsible for storing errors from encoding / decoding, and keeping track of registries throughout the serialization process. You can read from a `ReadView` using the `read` method, passing in a `Codec` for the desired type. Likewise, you can write to a `WriteView` by using the `put` method, passing in a `Codec` for the type, and the value in question. there are also methods for primitives, under `get(Int, Short, Boolean, ...)` and `put(Int, Short, Boolean, ...)`. The View also provides methods for working with lists, nullable types, and nested objects.
 ```java
 class BE extends BlockEntity {
-    private int anInt;
-    private String aString;
-    private Extra extra;
-    // ctor excluded for brevity 
-    @Override
-    public NbtCompound toInitialChunkDataNbt(RegistryWrapper.WrapperLookup registries) {
-        return createNbt(registries); // createNbt takes care of adapting to / from WriteView
-    }
-
-    @Override
-    protected void writeData(WriteView view) {
-        super.writeData(view);
-        view.putNullable("extra", Extra.CODEC, this.extra);
-        if (aString != null) // putString will eventually throw if we pass null
-            view.putString("aString", aString);
-        view.putInt("anInt", anInt);
-    }
-
-    @Override
-    protected void readData(ReadView view) {
-        super.readData(view);
-        view.read("extra", Extra.CODEC).ifPresent(extra -> this.extra = extra);
-        view.getOptionalString("aString").ifPresent(aString -> this.aString = aString);
-        view.getOptionalInt("anInt").ifPresent(anInt -> this.anInt = anInt);
-    }
-
-    record Extra(int i, int j) {
-        public static final Codec<Extra> CODEC = RecordCodecBuilder.create(instance -> instance.group(Codec.INT.fieldOf("i").forGetter(extra -> extra.i), Codec.INT.fieldOf("j").forGetter(extra -> extra.j)).apply(instance, Extra::new));
-    }
+	private int anInt;
+	private String aString;
+	private Extra extra;
+	// Ctor excluded for brevity
+	@Override
+	public NbtCompound toInitialChunkDataNbt(RegistryWrapper.WrapperLookup registries) {
+		return createNbt(registries); // createNbt takes care of adapting to / from WriteView
+	}
+
+	@Override
+	protected void writeData(WriteView view) {
+		super.writeData(view);
+		view.putNullable("extra", Extra.CODEC, this.extra);
+		if (aString != null) // putString will eventually throw if we pass null
+			view.putString("aString", aString);
+		view.putInt("anInt", anInt);
+	}
+
+	@Override
+	protected void readData(ReadView view) {
+		super.readData(view);
+		view.read("extra", Extra.CODEC).ifPresent(extra -> this.extra = extra);
+		view.getOptionalString("aString").ifPresent(aString -> this.aString = aString);
+		view.getOptionalInt("anInt").ifPresent(anInt -> this.anInt = anInt);
+	}
+
+	record Extra(int i, int j) {
+		public static final Codec<Extra> CODEC = RecordCodecBuilder.create(instance -> instance.group(Codec.INT.fieldOf("i").forGetter(extra -> extra.i), Codec.INT.fieldOf("j").forGetter(extra -> extra.j)).apply(instance, Extra::new));
+	}
 }
 ```
 
 ### Data Generation
 
-* `getOrCreateTagBuilder` should be replaced with the new `valueLookupBuilder`
+* `getOrCreateTagBuilder` should be replaced with the new `valueLookupBuilder`.
