fix(docs): Apply suggestions from Xfact

Co-authored-by: Dennis C <[email protected]>

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<Item> 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"))

docs/items/consumables.md

@@ -56,7 +56,7 @@ public static final DeferredItem<Item> 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`.
 

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.
 

docs/resources/server/recipes/custom.md

@@ -69,8 +69,8 @@ public class RightClickBlockRecipe implements Recipe<RightClickBlockInput> {
         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

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: