feat(docs): Update client section

docs/resources/client/i18n.md

@@ -114,7 +114,7 @@ Translation keys are the keys used in translations. In many cases, they follow t
 
 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. These can not only be queried, but also overridden if needed. A common use case are items that have different names depending on their [NBT][nbt] value. These will usually override the variant of `#getDescriptionId` that has an [`ItemStack`][itemstack] parameter, and return different values based on the stack's NBT. Another common use case are `BlockItem`s, which override the method to use the associated block's translation key 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 the items have different names depending on their [NBT][nbt] value, these can be overriden by setting the `CUSTOM_NAME` 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.
@@ -148,31 +148,31 @@ public class MyLanguageProvider extends LanguageProvider {
     @Override
     protected void addTranslations() {
         // Adds a translation with the given key and the given value.
-        add("translation.key.1", "Translation 1");
+        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.
-        add(MyBlocks.EXAMPLE_BLOCK.get(), "Example Block");
-        addBlock(MyBlocks.EXAMPLE_BLOCK, "Example Block");
+        this.add(MyBlocks.EXAMPLE_BLOCK.get(), "Example Block");
+        this.addBlock(MyBlocks.EXAMPLE_BLOCK, "Example Block");
         // Adds an item translation.
-        add(MyItems.EXAMPLE_ITEM.get(), "Example Item");
-        addItem(MyItems.EXAMPLE_ITEM, "Example Item");
+        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.
-        add(MyItems.EXAMPLE_ITEM_STACK.get(), "Example Item");
-        addItemStack(MyItems.EXAMPLE_ITEM_STACK, "Example Item");
+        this.add(MyItems.EXAMPLE_ITEM_STACK.get(), "Example Item");
+        this.addItemStack(MyItems.EXAMPLE_ITEM_STACK, "Example Item");
         // Adds an entity type translation.
-        add(MyEntityTypes.EXAMPLE_ENTITY_TYPE.get(), "Example Entity");
-        addEntityType(MyEntityTypes.EXAMPLE_ENTITY_TYPE, "Example Entity");
+        this.add(MyEntityTypes.EXAMPLE_ENTITY_TYPE.get(), "Example Entity");
+        this.addEntityType(MyEntityTypes.EXAMPLE_ENTITY_TYPE, "Example Entity");
         // Adds an enchantment translation.
-        add(MyEnchantments.EXAMPLE_ENCHANTMENT.get(), "Example Enchantment");
-        addEnchantment(MyEnchantments.EXAMPLE_ENCHANTMENT, "Example Enchantment");
+        this.add(MyEnchantments.EXAMPLE_ENCHANTMENT.get(), "Example Enchantment");
+        this.addEnchantment(MyEnchantments.EXAMPLE_ENCHANTMENT, "Example Enchantment");
         // Adds a mob effect translation.
-        add(MyMobEffects.EXAMPLE_MOB_EFFECT.get(), "Example Effect");
-        addEffect(MyMobEffects.EXAMPLE_MOB_EFFECT, "Example Effect");
+        this.add(MyMobEffects.EXAMPLE_MOB_EFFECT.get(), "Example Effect");
+        this.addEffect(MyMobEffects.EXAMPLE_MOB_EFFECT, "Example Effect");
     }
 }
 ```

docs/resources/client/particles.md

@@ -16,7 +16,7 @@ public class MyParticleTypes {
 
     // 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 DeferredHolder<ParticleType<?>, SimpleParticleType> MY_PARTICLE = PARTICLE_TYPES.register(
+    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
@@ -127,7 +127,7 @@ A mismatched list of sprite set particle factories and particle definition files
 :::
 
 :::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`, `PARTICLE_SHEET_TRANSLUCENT`, and `PARTICLE_SHEET_LIT`.
+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
@@ -199,6 +199,11 @@ public class MyParticleOptions implements ParticleOptions {
 
     // 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
+    }
 }
 ```
 
@@ -225,7 +230,7 @@ public class MyParticleType extends ParticleType<MyParticleOptions> {
 }
 ```
 
-... and reference it during registration:
+... and reference it during [registration][registry]:
 
 ```java
 public static final Supplier<MyParticleType> MY_CUSTOM_PARTICLE = PARTICLE_TYPES.register(
@@ -234,6 +239,20 @@ public static final Supplier<MyParticleType> MY_CUSTOM_PARTICLE = PARTICLE_TYPES
 );
 ```
 
+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.
@@ -245,5 +264,5 @@ As a reminder from before, the server only knows `ParticleType`s and `ParticleOp
 [datagen]: ../index.md#data-generation
 [event]: ../../concepts/events.md
 [modbus]: ../../concepts/events.md#event-buses
-[registry]: ../../concepts/registries.md
+[registry]: ../../concepts/registries.md#methods-for-registering
 [side]: ../../concepts/sides.md

docs/resources/client/sounds.md

@@ -27,16 +27,18 @@ public class MySoundsClass {
             DeferredRegister.create(BuiltInRegistries.SOUND_EVENT, "examplemod");
 
     // All vanilla sounds use variable range events.
-    public static final DeferredHolder<SoundEvent, SoundEvent> MY_SOUND = SOUND_EVENTS.register(
-            "my_sound", // must match the resource location on the next line
-            () -> SoundEvent.createVariableRangeEvent(ResourceLocation.fromNamespaceAndPath("examplemod", "my_sound"))
+    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 DeferredHolder<SoundEvent, SoundEvent> MY_FIXED_SOUND = SOUND_EVENTS.register("my_fixed_sound",
+    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.
-            () -> SoundEvent.createFixedRangeEvent(ResourceLocation.fromNamespaceAndPath("examplemod", "my_fixed_sound"), 16)
+            registryName -> SoundEvent.createFixedRangeEvent(registryName, 16f)
     );
 }
 ```

docs/resources/client/textures.md

@@ -37,7 +37,10 @@ Texture metadata can be specified in a file named exactly the same as the textur
                 "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.