From 3658e6ea8ba651f4c9b4073b9d4f5ef1211e7409 Mon Sep 17 00:00:00 2001 From: ChampionAsh5357 Date: Mon, 11 Nov 2024 22:03:47 -0500 Subject: [PATCH] fix(docs): Apply suggestions from Xfact Co-authored-by: Dennis C --- docs/items/armor.md | 6 +++--- docs/items/consumables.md | 2 +- docs/items/interactionpipeline.md | 2 +- docs/resources/server/recipes/custom.md | 4 ++-- docs/resources/server/recipes/index.md | 2 +- 5 files changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/items/armor.md b/docs/items/armor.md index 3ab3d835..86204da7 100644 --- a/docs/items/armor.md +++ b/docs/items/armor.md @@ -17,9 +17,9 @@ Armors are almost completely implemented through seven [data components][datacom - `DataComponents#MAX_DAMAGE` and `#DAMAGE` for durability - `#MAX_STACK_SIZE` to set the stack size to `1` -- `#REPAIRABLE` for repairing a tool in an anvil +- `#REPAIRABLE` for repairing an armor piece in an anvil - `#ENCHANTABLE` for the maximum [enchanting][enchantment] value -- `#ATTRIBUTE_MODIFIERS` for armor, armor toughness, and knockback +- `#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. @@ -141,7 +141,7 @@ public static final DeferredItem EQUIPPABLE = ITEMS.registerSimpleItem( // Points to assets/examplemod/models/equipment/equippable.json // When not set, does not render the equipment. .setModel(ResourceLocation.fromNamespaceAndPath("examplemod", "equippable")) - // The relative location over the texture to overlay on the player screen when wearing (e.g., pumpkin blur). + // 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")) diff --git a/docs/items/consumables.md b/docs/items/consumables.md index b878d80f..7c22b1ea 100644 --- a/docs/items/consumables.md +++ b/docs/items/consumables.md @@ -56,7 +56,7 @@ public static final DeferredItem CONSUMABLE = ITEMS.registerSimpleItem( ### `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 the `Consumable` by calling `Consumable.Builder#onConsume`. +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`. diff --git a/docs/items/interactionpipeline.md b/docs/items/interactionpipeline.md index 1decb73a..1c3a3112 100644 --- a/docs/items/interactionpipeline.md +++ b/docs/items/interactionpipeline.md @@ -33,7 +33,7 @@ When you right-click anywhere in the world, a number of things happen, depending ## `InteractionResult` -`InteractionResult` is a sealed interface that respresents the result of some interaction between an item or and empty hand and some object (e.g. entities, blocks, etc.). The interface is broken into four records, where there are six potential default states. +`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. diff --git a/docs/resources/server/recipes/custom.md b/docs/resources/server/recipes/custom.md index 33cd35de..aefaf06f 100644 --- a/docs/resources/server/recipes/custom.md +++ b/docs/resources/server/recipes/custom.md @@ -69,8 +69,8 @@ public class RightClickBlockRecipe implements Recipe { return this.result.copy(); } - // When false, will prevent the recipe from being synced within the recipe book or awarded on use/unlock. - // This should only be false if the recipe shouldn't appear in a recipe book, such as extended a map. + // 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 extended a map. // Although this recipe takes in an input state, it could still be used in a custom recipe book using // the methods below. @Override diff --git a/docs/resources/server/recipes/index.md b/docs/resources/server/recipes/index.md index 84c2bfde..add239b3 100644 --- a/docs/resources/server/recipes/index.md +++ b/docs/resources/server/recipes/index.md @@ -39,7 +39,7 @@ A full list of types provided by Minecraft can be found in the [Built-In Recipe ## Using Recipes -Recipes are registered, 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 in their entirety, instead it only sends the `RecipePropertySet`s for restricting inputs on menu slots and the `RecipeDisplayEntry`s for the recipe book. All recipe logic should always run on the server. +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 in their entirety, instead it only sends the `RecipePropertySet`s for restricting inputs on menu slots and the `RecipeDisplayEntry`s for the recipe book. All recipe logic should always run on the server. The easiest way to get a recipe is by its resource key: