🚀 d321d8b Fix build: Publish libraries on smithed (#889)

1.20/generated/smithed_readmes/lib_brewing.md

@@ -0,0 +1,110 @@
+# lib_brewing
+lib_brewing is a mcfunction library that allows other datapacks to replace custom potions with splash and lingering potions when brewed in a brewing stand. This is used to prevent the `Uncraftable Splash Potion` and `Uncraftable Lingering Potion` items from being obtainable.
+
+## Uses
+### Splash and Lingering Conversions
+This library automatically catches splash and lingering potion conversions to allow datapacks to properly replace those potions. This means whenever a potion is brewed into a splash potion using gunpowder, a set of functions will be run to replace the Uncraftable Splash Potion with a custom splash potion. Similarly, whenever a splash potion is brewed into a lingering potion using dragon's breath, a set of functions will be run to replace the Uncraftable Lingering Potion with a custom lingering potion.
+
+Each brewing stand has a marker to track these changes. When splash and lingering potions are created, each potion is checked by calling the `#gm4_brewing:insert/splash` or `#gm4_brewing:insert/lingering` function tags (once per potion, so if there are 3 potions in the brewing stand, that function tag gets called for each potion). The full item nbt for each potion is saved into the nbt of the marker in `data.gm4_brewing.insert.tag.<ITEM_NBT>`. For example if the brewing stand has the nbt `{Items:[{Slot:0b,id:"minecraft:potion",Count:1b,tag:{my_custom_potion:1b}}]}`, the marker would have the nbt `{data:{gm4_brewing:{insert:{Slot:0b,id:"minecraft:potion",Count:1b,tag:{my_custom_potion:1b}}}}}` when it's checking the first potion. This is how you should check for your custom potions
+
+To utilize this function, two functions tags, two functions, and two loot tables should be created. Below are the files for splash potions, and can be copied for lingering potions by replacing all instances of `splash` with `lingering`
+
+1. create a single loot table to check the potion type and drop the proper splash potion:
+
+loot table `MODULE_ID:technical/brewing_stand/splash`
+```json
+{
+  "pools": [
+    {
+      "rolls": 1,
+      "entries": [
+        {
+          "type": "minecraft:alternatives",
+          "children": [
+            {
+              "type": "minecraft:loot_table",
+              "name": "LOOT TABLE PATH TO SPLASH POTION 1",
+              "conditions": [
+                {
+                  "condition": "minecraft:entity_properties",
+                  "entity": "this",
+                  "predicate": {
+                    "nbt": "{data:{gm4_brewing:{insert:{tag:{INDICATION NBT FOR POTION 1}}}}"
+                  }
+                }
+              ]
+            },
+            {
+              "type": "minecraft:loot_table",
+              "name": "LOOT TABLE PATH TO SPLASH POTION 2",
+              "conditions": [
+                {
+                  "condition": "minecraft:entity_properties",
+                  "entity": "this",
+                  "predicate": {
+                    "nbt": "{data:{gm4_brewing:{insert:{tag:{INDICATION NBT FOR POTION 2}}}}"
+                  }
+                }
+              ]
+            }
+          ]
+        }
+      ],
+      "functions": [
+        {
+          "function": "minecraft:set_nbt",
+          "tag": "{gm4_custom_potion:1b}"
+        }
+      ]
+    }
+  ]
+}
+```
+
+2. Create a function to call the splash potion loot table when the library catches a splash potion conversion:
+
+function `MODULE_ID:brewing_stand/splash`
+```mcfunction
+# @s = brewing stand marker with a custom potion to be converted to a splash potion
+# run from #gm4_brewing:insert/splash
+
+loot spawn ~ ~ ~ loot MODULE_ID:technical/brewing_stand/splash
+# uncomment this line to completely clear the potion VV
+# execute if <...> run scoreboard players set $insert gm4_brewing_data -1
+```
+
+3. Add your function to the library API call that runs when the library catches a splash potion conversion:
+
+function tag `#gm4_brewing:insert/splash`
+```json
+{
+  "values": [
+    "MODULE_ID:brewing_stand/splash"
+  ]
+}
+```
+
+
+### Changing Splash and Lingering Outcomes
+- In the two created functions (`/brewing_stand/splash.mcfunction` and `/brewing_stand/lingering.mcfunction`) additonal commands can be run before the `/loot` command to change the outcome of the loot tables. For example, if you want potions to turn into a water bottle if the brewing stand is surrounded by water, you could set a score and have the loot table check for that score.
+
+- Using the following command will clear the potion from the brewing stand (should typically be used with a check so only certain custom potions are deleted):
+```mcfunction
+scoreboard players set $insert gm4_brewing_data -1
+```
+
+### Additional Brewing Functions
+Every time a brewing stand completes a brew, the function tag `#gm4_brewing:finish_brew` runs AFTER the default interactions of creating splash and lingering potions. This allows further checks and modifications to potions (but is still restricted to the vanilla hardcoded brewing rules; i.e. it doesn't allow using dirt as a brewing ingredient). The `Items` nbt of the brewing stand is saved 1 tick before the potions finish brewing (when `#gm4_brewing:finish_brew` is called), so the brewing ingredient and original potion data is available inside the marker nbt. To test for items in the brewing stand, use the entity data from the marker: 
+
+```mcfunction
+execute if entity @s[nbt={data:{gm4_brewing:{previous_items:[BLOCK_DATA]}}}]
+```
+
+For example, this is the code that checks if a splash potion should be created: 
+```mcfunction
+execute if entity @s[nbt={data:{gm4_brewing:{previous_items:[{Slot:3b,id:"minecraft:gunpowder"}]}}}] ...
+```
+
+
+## License
+This library, and the contents of the `lib_brewing` directory on the [github repository](https://github.com/Gamemode4Dev/GM4_Datapacks), is licensed under the MIT License.

1.20/generated/smithed_readmes/lib_custom_crafters.md

@@ -0,0 +1,111 @@
+# Custom Crafters
+This library, based upon the old Gamemode 4 Module of the same name, adds for a dropper-based custom crafter for custom item crafting purposes. The use of a dropper instead of a barrel ensures that the crafter can be used without a resource pack. Structured as a library, and gamemode 4 modules that require custom item crafting can include this library and come with the custom crafter features bundled. 
+
+## How to Use
+Custom Crafters have a function tag used to check recipes: `#gm4_custom_crafters:check_recipes`. Data packs should use this to set up recipes to be crafted in a custom crafter. Custom Crafters run every 16 ticks automatically checking for recipes and replacing them with their appropriate output.
+
+Below are specific details in implementing a `check_recipes` function. Custom Crafters will only run recipe checks if all slots have the same item count.
+
+### Check that no other recipes have been completed
+
+`execute if score $crafted gm4_crafting matches 0 store result score $crafted gm4_crafting`
+### Check the slot count
+This should be set to the number of filled slots. For example if a recipe has 2 empty slots, the slot count should be 7 (9-2).
+
+`if score $slot_count gm4_crafting matches <number>`
+
+### Check the stack size
+This should be set to the maximum count of the input items. For example if you have a recipe that will create 4 items for each single recipe (like log -> planks), then this should be set to `..16`, since 16*4 = 64, which is the maximum stack size for planks. This means only up to 16 items in each slot will work for this recipe.
+
+`if score $stack_size gm4_crafting matches ..<number>`
+
+### Check the Items
+This checks the `Items` block data (moved to storage for efficiency), which represents the recipe input. Note that `Count` should not be checked here, since multi-crafting is supported by setting the `stack_size`
+
+`if data storage gm4_custom_crafters:temp/crafter {Items:[<...>]}`
+
+Note that the Custom Crafter automatically supports recipes placed anywhere in the grid, as long as the storage check assumes the recipe is inputted with alignment to the top-left. So for example, crafting a crafting table from planks will work in any 2x2 corner, but the storage check to check the items needs to check slots 0, 1, 3, and 4. The code will automatically shift the recipe in storage before the recipe checks are performed.
+
+### Loot Replace
+`run loot replace block ~ ~ ~ container.0 loot MODULE_NAMESPACE:crafting/RECIPE_NAME`
+
+- afformentioned loot table:
+```json
+{
+  "type": "minecraft:generic",
+  "pools": [
+    {
+      "rolls": 8,
+      "entries": [
+        {
+          "type": "minecraft:item",
+          "name": "minecraft:air"
+        }
+      ]
+    },
+    {
+      "rolls": 1,
+      "entries": [
+        {
+          "type": "minecraft:loot_table",
+          "name": "LOOT_TABLE_TO_ITEM",
+          "functions": [
+            {
+              "function": "minecraft:set_count",
+              "count": "MULTIPLIER"
+            }
+          ]
+        }
+      ]
+    }
+  ]
+}
+
+```
+- It is convention to put the recipe output in the last slot, but this loot table can be flexible, as long as it replaces all 9 slots. Loot tables pools are run in order, so multiple items can be outputted (such as emptying a water bucket and replacing it with an empty bucket).
+
+### Set the Multiplier
+When setting the outputs with the loot table, the count determines how much the item stack will be multiplied by. For example setting the count to 4 will output 4 of that item per recipe (like the log -> planks example from earlier).
+
+## Recipe Check Function Example
+a function that is called by `#gm4_custom_crafters:check_recipes`:
+```mcfunction
+# 1 white wool -> 3 string (shapeless)
+execute if score $crafted gm4_crafting matches 0 store result score $crafted gm4_crafting if score $slot_count gm4_crafting matches 1 if score $stack_size gm4_crafting matches ..21 if data storage gm4_custom_crafters:temp/crafter {Items:[{id:"minecraft:white_wool"}]} run loot replace block ~ ~ ~ container.0 loot gm4_craft:crafting/string
+```
+the loot table `gm4_craft:crafting/string`:
+```json
+{
+  "type": "minecraft:generic",
+  "pools": [
+    {
+      "rolls": 8,
+      "entries": [
+        {
+          "type": "minecraft:item",
+          "name": "minecraft:air"
+        }
+      ]
+    },
+    {
+      "rolls": 1,
+      "entries": [
+        {
+          "type": "minecraft:item",
+          "name": "minecraft:string",
+          "functions": [
+            {
+              "function": "minecraft:set_count",
+              "count": 3
+            }
+          ]
+        }
+      ]
+    }
+  ]
+}
+```
+In the example above, the `stack_size` is set to 21 because the output for a single craft is 3 string and the maximum stack size for string is 64, so 64/3 = 21.3 maximum input items (then round down since 22 would exceed the max stack size of string). The loot table ensures that all items are deleted and the last slot of the dropper is replaced with the output for one craft.
+
+## License
+This library, and the contents of the `lib_custom_crafters` directory on the [github repository](https://github.com/Gamemode4Dev/GM4_Datapacks), is licensed under the MIT License.

1.20/generated/smithed_readmes/lib_forceload.md

@@ -0,0 +1,45 @@
+# lib_forceload
+lib_forceload is a mcfunction library adding a forceloaded chunk with common utlities. Available utilities are:
+* yellow-shulker-box for inventory manipulations
+* sign for text resolution
+* jukebox for single item storage
+* repeating command block for sub-tick execution
+* armor-stand for tool-based loot table context
+
+## How to Use
+This library forceloads the chunk `29999999 7134`, which lies beyond the maximum world size, in every dimension - including custom defined dimensions. Each dimension initializes its forceloaded chunk when a player first logs into that dimension.
+
+### Yellow Shulker Box
+Every dimension gets a `yellow_shulker_box` placed at `29999998 1 7134` for use with inventory manipulations. This library follows the "yellow-shulker-box" convention, including the standard loot table.
+
+example:
+```
+# move item from shulker box to output barrel
+loot insert ~ ~ ~ mine 29999998 1 7134 air{drop_contents:1b}
+```
+
+### Birch Sign
+Every dimension gets a `birch_wall_sign` placed at `29999998 1 7133`. This can be used to resolve json text components and retrieve the resulting string. 
+
+example:
+```
+data modify block 29999998 1 7133 front_text.messages[0] set value '[{"text": "killed by "},{"storage":"my_storage:register", "nbt":"my_text.name"}]'
+data modify entity @s CustomName set from block ~ ~ ~ front_text.messages[0]
+```
+
+### Jukebox
+Every dimension gets a `jukebox` placed at `29999998 1 7132`. The item contained within can be used for whatever the developer wishes.
+
+### Unique Dimension ID
+In each dimension, a marker entity with the tag `gm4_dimension` is summoned. This marker has a unique scoreboard value stored in the objective `gm4_dimension`, and a name matching the dimension's string ID. 
+
+This score can be used to dynamically store a dimension on an item, such as for a recall ability, or for your datapack to support an arbitrary number of dimensions, added by other datapacks.
+
+### Repeating Command Block
+The overworld dimension has a repeating command block running the function tag `#gm4_forceload:command_block_tick`. Adding functions to this tag lets their contents to be run at a different subtick than ordinary functions. This is commonly used to intercept item drops before a player has the change to pick them up, but may be used to properly time other datapack code.
+
+### Armor Stand
+The overworld dimension has a armor stand with the static uuid `344d47-4-4-4-f04ce104d`. This can be used with loot tables that utilize the `match_tool` predicate which require an entity with a mainhand slot. 
+
+## License
+This library, and the contents of the `lib_forceload` directory on the [github repository](https://github.com/Gamemode4Dev/GM4_Datapacks), is licensed under the MIT License.

1.20/generated/smithed_readmes/lib_lore.md

@@ -0,0 +1,122 @@
+# lib_lore
+lib_lore is a mcfunction library that allows other datapacks to easily search, remove, insert, and replace lines of lore on items.
+
+## How to use
+There are 4 operations that can be applied. Each operation uses data storage and scoreboards as inputs and outputs.
+
+### Inputs
+There are three data storage inputs, along with two scoreboard inputs. Below are their terminologies (will be used further in this document), as well as their uses and the command to set them.
+
+`Source`: This is a list of the lore that will be modified, typically this would be extracted directly from the item being modified, but can be set manually to a desired set of lore.
+```mcfunction
+data modify storage gm4_lore:temp Source set from <...>
+```
+
+`Target`: This is a single json item (i.e. a single 'line' of lore) that will be found during the operations. This sets the line of lore to be searched, removed, inserted after, or replaced.
+```mcfunction
+data modify storage gm4_lore:temp Target set from <...>
+```
+
+`Input`: This is list of the lore that will be inserted or replaced. This should not be set when simply searching or removing and will be ignored if set while using the search or remove operation.
+```mcfunction
+data modify storage gm4_lore:temp Input set from <...>
+```
+
+`start`: This is an integer that determines where the operation will start. It is essentially the offset for the operations. More specific use cases can be found under each specific operation description.
+```mcfunction
+scoreboard players set $start gm4_lore <value>
+```
+
+`extra`: This is an integer that determines the extra lines to be removed after the initial line. This is only used during the remove operation and will be ignored otherwise. More specific use cases can be found under the remove operation description.
+```mcfunction
+scoreboard players set $extra gm4_lore <value>
+```
+
+### Outputs
+There are three outputs to work to work with after running an operation. Each operation uses the three outputs differently, which can be found under the specific operation description. Below are their terminologies (will be used further in this document), as well as their general uses and the command to get them.
+
+`Source`: This is the modified version of the input Source.
+```mcfunction
+data get storage gm4_lore:temp Source
+```
+
+`Dump`: This is extra info about the operation that was used, usually the line of lore that was modified.
+```mcfunction
+data get storage gm4_lore:temp Dump
+```
+
+`index`: This is the index of the lore where the operation took place.
+```mcfunction
+scoreboard players get $index gm4_lore
+```
+
+
+### Operations
+Below are the four operations and how to utilize them. Note that every operation requires `Source` and `Target` to be set.
+
+#### Remove
+Removes a specified line of lore
+
+- `start` determines where the removal will start when it finds the `Target` line; this can be negative to start removing before the line or positive to start removing after the line. Defaults to 0.
+- `extra` determines how many more lines to remove after the first target line is removed. Must be positive. Defaults to 0. If set to -1, every line after the first target line will be removed.
+
+```mcfunction
+function #gm4_lore:remove
+```
+
+- `Source` is the updated `Source` without the `Target` line.
+- `Dump` is the removed line of lore.
+- `index` is the location of first line that was removed.
+
+
+#### Search
+Finds the index of a specified line of lore
+- `start` determines where the search will start; must be a positive number. Defaults to 0.
+
+```mcfunction
+function #gm4_lore:search
+```
+
+- `Source` remains unchanged.
+- `Dump` is the found line of lore (`Target`).
+- `index` is the location of first line that was found.
+
+
+#### Insert
+Inserts lines of lore after a specified line of lore
+
+- `Input` determines the lines of lore to add after the `Target` line
+- `start` determines where the insertion will start when it finds the `Target` line; this can be negative to insert before the line or positive to insert after the line. Defaults to 0.
+
+```mcfunction
+function #gm4_lore:insert
+```
+
+- `Source` is the updated `Source` with the added lore.
+- `Dump` is the added lines of lore (`Input`).
+- `index` is the location of first line that was added.
+
+
+#### Replace
+Replaces a specified line of lore with one or more new lines of lore
+
+- `Input ` determines the lines of lore to replace the `Target` line
+- `start` determines where the search for the `Target` line will start; must be a positive number. Defaults to 0.
+
+```mcfunction
+function #gm4_lore:replace
+```
+
+- `Source` is the updated `Source` with the replaced lore
+- `Dump` is the replaced line of lore (`Target`)
+- `index` is the location of first line that was replaced.
+
+
+Please note that the `example_pack` must be started by calling `#load:load`, as a proper load implementation is not included.
+
+## Technical Details
+- Technically the item isn't modified directly, this means the `Source` and be added to the lore of the item using the default `data modify` operations.
+- These operations are technically not limited to lore, but can also be used for any type of list.
+
+## License
+This library, and the contents of the `lib_lore` directory on the [github repository](https://github.com/Gamemode4Dev/GM4_Datapacks), is licensed under the MIT License.