From 9bb34f55f1632d46136ea2b57f767791255d6090 Mon Sep 17 00:00:00 2001 From: ChampionAsh5357 Date: Fri, 18 Oct 2024 13:54:24 -0400 Subject: [PATCH] feat(docs): Update client section --- docs/resources/client/i18n.md | 28 ++++++++++++++-------------- docs/resources/client/particles.md | 27 +++++++++++++++++++++++---- docs/resources/client/sounds.md | 12 +++++++----- docs/resources/client/textures.md | 5 ++++- 4 files changed, 48 insertions(+), 24 deletions(-) diff --git a/docs/resources/client/i18n.md b/docs/resources/client/i18n.md index ec06c0a4..93bdd1f6 100644 --- a/docs/resources/client/i18n.md +++ b/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,7 +148,7 @@ 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. @@ -156,23 +156,23 @@ public class MyLanguageProvider extends LanguageProvider { // 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"); } } ``` diff --git a/docs/resources/client/particles.md b/docs/resources/client/particles.md index 3d8a6fc6..51ec1145 100644 --- a/docs/resources/client/particles.md +++ b/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, SimpleParticleType> MY_PARTICLE = PARTICLE_TYPES.register( + public static final Supplier 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 { } ``` -... and reference it during registration: +... and reference it during [registration][registry]: ```java public static final Supplier MY_CUSTOM_PARTICLE = PARTICLE_TYPES.register( @@ -234,6 +239,20 @@ public static final Supplier 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 diff --git a/docs/resources/client/sounds.md b/docs/resources/client/sounds.md index 61dde22d..fc278133 100644 --- a/docs/resources/client/sounds.md +++ b/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 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 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 MY_FIXED_SOUND = SOUND_EVENTS.register("my_fixed_sound", + public static final Holder 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) ); } ``` diff --git a/docs/resources/client/textures.md b/docs/resources/client/textures.md index c3bc5f52..0f3541cd 100644 --- a/docs/resources/client/textures.md +++ b/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.