Fix some misspellings in guidebook (#7903)

Co-authored-by: shartte <shartte@users.noreply.github.com>

API.md

@@ -46,7 +46,7 @@ Keys can be saved to from NBT using `toTagGeneric`, which also stores a referenc
 `AEKey.fromTagGeneric` can restore the key of the correct type. The same mechanism can be used for packets with
 `AEKey.writeToPacket` and `AEKey.readKey`.
 
-Sicne Java 16, the following patter makes it easy to work with generic keys when your code only supports items:
+Since Java 16, the following pattern makes it easy to work with generic keys when your code only supports items:
 
 ```java
 if (key instanceof AEItemKey itemKey) {
@@ -61,7 +61,7 @@ AE2's core systems work by building grids from grid nodes that are created and o
 entities or parts. Grids are never created directly. They form and disband automatically by creating grid nodes, and
 connecting or disconnecting them.
 
-**NOTE:** Grids a purely a server-side concept. They do not exist on the client.
+**NOTE:** Grids are purely a server-side concept. They do not exist on the client.
 
 ### Node Owners and Listeners
 

guidebook.md

@@ -92,7 +92,7 @@ page is in AE2s guidebook, all ids automatically use the `ae2` namespace, unless
 #### Column / Row Layout
 
 To lay out other tags (such as item images) in a row or column, use the `<Row></Row>`
-and `<Column></Column>` tags. You can set a custom gap betwen items using the `gap` attribute.
+and `<Column></Column>` tags. You can set a custom gap between items using the `gap` attribute.
 It defaults to 5.
 
 Example:
@@ -198,7 +198,7 @@ The tag also supports the following attributes:
 
 #### Game Scenes
 
-To show a real-time renderered in-game scene, use:
+To show a real-time rendered in-game scene, use:
 
 ```
 <GameScene>

guidebook/ae2-mechanics/autocrafting.md

@@ -80,7 +80,7 @@ There are several different types of pattern for different things:
 ***
 
 *   <ItemLink id="processing_pattern" />s are where a lot of flexibility in autocrafting comes from. They are the most generalized type, simply
-    saying "if a pattern provider pushes these ingredients to adjacent inventories, the ME system will recieve these items at some point in the
+    saying "if a pattern provider pushes these ingredients to adjacent inventories, the ME system will receive these items at some point in the
     near or distant future". They are how you will autocraft with almost any modded machine, or furnaces and the like. Because they are so
     general in use and do not care what happens between pushing ingredients and receiving the result, you can do some really funky stuff, like inputting
     the ingredients into an entire complex factory production chain which will sort out stuff, take in other ingredients from infinitely-producing
@@ -96,7 +96,7 @@ your smelting setup every operation instead of one at a time.
 
 There is actually an even more "general" form of "pattern" than a processing pattern. A <ItemLink id="level_emitter" /> with a crafting card can be set
 to emit a redstone signal in order to craft something. This "pattern" does not define, or even care about ingredients.
-All it says is "If you emit redstone from this level emitter, the ME system will recieve this item at some point in the
+All it says is "If you emit redstone from this level emitter, the ME system will receive this item at some point in the
 near or distant future". This is usually used to activate and deactivate infinite farms which require no input ingredients,
 or to activate a system that handles recursive recipes (which standard autocafting cannot understand) like, for example, "1 cobblestone = 2 cobblestone"
 if you have a machine that duplicates cobblestone.

guidebook/ae2-mechanics/bytes-and-types.md

@@ -33,7 +33,7 @@ take up more space than 64 stone.
 
 Again, each item is 1 bit, so 8 items equals 1 byte. For fluid cells, this is 8 buckets per byte.
 
-Many people complain about the limited number of types a cell can hold, but they are a ***neccessary limitation***.
+Many people complain about the limited number of types a cell can hold, but they are a ***necessary limitation***.
 Cells store their data in an NBT tag on the item itself, which makes them rather stable. However, this means putting too much
 data on a cell can cause too much data to be sent to a player, causing an effect similar to "Book Banning" in vanilla minecraft.
 Additionally, having too many different types in your system increases the load on sorting and item handling. However, this

guidebook/example-setups/level-emitter-autostocking.md

@@ -49,7 +49,7 @@ You can of course make your network craft continuously, by omitting the level em
 
 1. If the amount of the desired item in [network storage](../ae2-mechanics/import-export-storage.md) is below the quantity specified in the
    <ItemLink id="level_emitter" />, it will emit a redstone signal.
-2. Upon recieving a redstone signal (and due to the <ItemLink id="crafting_card" /> and being set to not use stocked items),
+2. Upon receiving a redstone signal (and due to the <ItemLink id="crafting_card" /> and being set to not use stocked items),
    the <ItemLink id="export_bus" /> will request that the network's [autocrafting](../ae2-mechanics/autocrafting.md) craft
    more of the desired item, then export it.
 3. Upon having an item pushed into it (and not being configured to have anything in its internal inventory), the <ItemLink id="interface" /> will push that item into network storage.

guidebook/getting-started.md

@@ -150,7 +150,7 @@ automate some processing.
 
 A great example of this is to place a <ItemLink id="export_bus" /> on the top of a furnace to
 dump in ores, and a <ItemLink id="import_bus" />
-on the bottom of the furance to extract furnaced ores.
+on the bottom of the furnace to extract furnaced ores.
 
 The <ItemLink id="export_bus" /> lets you export items from the network, into the attached
 inventory, while the <ItemLink id="import_bus" /> imports items from the attached inventory into

guidebook/items-blocks-machines/cables.md

@@ -128,7 +128,7 @@ into them, all they do is connect AE2 [devices](../ae2-mechanics/devices.md) tog
 </GameScene>
 
 <ItemLink id="fluix_glass_cable" /> is the simplest cable to make, transfers power
-and up to 8 [channels](../ae2-mechanics/channels.md). It comes in 17 diffrent colors, the default
+and up to 8 [channels](../ae2-mechanics/channels.md). It comes in 17 different colors, the default
 being Fluix, and can be dyed any color using any of the 16 dyes.
 
 To craft colored cables surround a dye of any type with 8 cables of the same

guidebook/items-blocks-machines/level_emitter.md

@@ -55,13 +55,13 @@ is crafting some specific item through <ItemLink id="pattern_provider" />s. This
 power-hungry automation setups while they are actually being used.
 
 The second option, "emit redstone to craft item", is extremely useful for specific use cases like infinite farms and
-automation setups that only have a chance of making an output, instead of a guranteed output.
+automation setups that only have a chance of making an output, instead of a guaranteed output.
 This setting creates a virtual [pattern](patterns.md) for [autocrafting](../ae2-mechanics/autocrafting.md) to use, for whatever item
 is in the emitter's filter slot.
 (For correct functionality, an actual pattern for the same item **should not exist** in your <ItemLink id="pattern_provider" />s)
 
 This "pattern" does not define, or even care about ingredients.
-All it says is "If you emit redstone from this level emitter, the ME system will recieve this item at some point in the
+All it says is "If you emit redstone from this level emitter, the ME system will receive this item at some point in the
 near or distant future". This is usually used to activate and deactivate infinite farms which require no input ingredients,
 or to activate [a system that handles recursive recipes](../example-setups/recursive-crafting-setup.md) (which standard autocafting cannot understand)
 like, for example, "1 cobblestone = 2 cobblestone" if you have a machine that duplicates cobblestone.

guidebook/items-blocks-machines/patterns.md

@@ -43,7 +43,7 @@ There are several different types of pattern for different things:
 ***
 
 *   <ItemLink id="processing_pattern" />s are where a lot of flexibility in autocrafting comes from. They are the most generalized type, simply
-    saying "if a pattern provider pushes these ingredients to adjacent inventories, the ME system will recieve these items at some point in the
+    saying "if a pattern provider pushes these ingredients to adjacent inventories, the ME system will receive these items at some point in the
     near or distant future". They are how you will autocraft with almost any modded machine, or furnaces and the like. Because they are so
     general in use and do not care what happens between pushing ingredients and receiving the result, you can do some really funky stuff, like inputting
     the ingredients into an entire complex factory production chain which will sort out stuff, take in other ingredients from infinitely-producing

src/main/java/appeng/api/networking/crafting/ICraftingSubmitResult.java

@@ -13,7 +13,7 @@ default boolean successful() {
     }
 
     /**
-     * @return A not-null error code if the auto-crafting request was not submitted succesfully.
+     * @return A not-null error code if the auto-crafting request was not submitted successfully.
      */
     @Nullable
     CraftingSubmitErrorCode errorCode();

src/main/java/appeng/api/networking/energy/IPassiveEnergyGenerator.java

@@ -37,7 +37,7 @@ public interface IPassiveEnergyGenerator extends IGridNodeService {
     double getRate();
 
     /**
-     * Set to true to indicate this generator is supressed by another on the same energy grid.
+     * Set to true to indicate this generator is suppressed by another on the same energy grid.
      */
     void setSuppressed(boolean suppressed);
 

src/main/java/appeng/helpers/externalstorage/GenericStackInv.java

@@ -359,7 +359,7 @@ public void readFromList(List<@Nullable GenericStack> stacks) {
     }
 
     /**
-     * Begin a section where change notifications are supressed until {@link #endBatch()} is called. If a change after
+     * Begin a section where change notifications are suppressed until {@link #endBatch()} is called. If a change after
      * calling this method would cause a notification to occur, a <strong>single</strong> change notification will occur
      * upon calling {@link #endBatch()} instead.
      */