Merge branch 'main' into mc-version-1_21_5

Author: diamond-dev1

bun.lock

@@ -22,7 +22,7 @@
     "remove-markdown": "^0.6.0",
     "string-strip-html": "^13.4.8",
     "super-sitemap": "^1.0.3",
-    "svelte": "^5.19.1",
+    "svelte": "^5.19.3",
     "svelte-check": "^4.1.4",
     "tslib": "^2.8.1",
     "typescript": "^5.7.3",
@@ -31,20 +31,20 @@
   "type": "module",
   "dependencies": {
     "@formkit/auto-animate": "^0.8.2",
-    "@iconify-json/tabler": "^1.2.14",
+    "@iconify-json/tabler": "^1.2.15",
     "@sveltejs/adapter-auto": "^4.0.0",
     "@tailwindcss/typography": "^0.5.16",
-    "@tailwindcss/vite": "^4.0.0-beta.10",
+    "@tailwindcss/vite": "^4.0.0",
     "flexsearch": "^0.7.43",
     "gray-matter": "^4.0.3",
     "nbtify": "^2.2.0",
     "rehype-autolink-headings": "^7.1.0",
     "rehype-slug": "^6.0.0",
     "remark-admonitions": "^1.2.1",
     "remark-code-titles": "^0.1.2",
-    "shiki": "^2.0.3",
+    "shiki": "^2.1.0",
     "sk-seo": "^0.5.3",
-    "tailwindcss": "^4.0.0-beta.10",
+    "tailwindcss": "^4.0.0",
     "unplugin-icons": "^22.0.0"
   }
 }

bun.lockb

@@ -56,7 +56,7 @@
 <SidebarCategory name="Datapack Files" icon={IconZip}>
   <SidebarPage label="Functions" icon={IconPennant} page="/wiki/files/functions" />
   <SidebarPage label="Predicates" icon={IconPredicate} page="/wiki/files/predicates" />
-  <SidebarPlaceholder label="Advancements" icon={IconStar} />
+  <SidebarPage label="Advancements" icon={IconStar} page="/wiki/files/advancements" />
   <SidebarPlaceholder label="Loot Tables" icon={IconChest} />
   <SidebarPage label="Recipes" icon={IconGrid} page="/wiki/files/recipes" />
   <SidebarPage label="Tags" icon={IconFilters} page="/wiki/files/tags" />

package-lock.json

@@ -9,7 +9,7 @@ import {Version, TreeRoot, TreeEntry, Highlight} from '$lib/reusables';
 
 # Page Formatting
 
-**Last Updated:** 12-13-2024
+**Last Updated:** 1-31-2025
 
 This section goes over how we format wiki pages. We like to be consistent, so please read through this section carefully
 and use these features to your advantage:
@@ -34,9 +34,9 @@ their first language!
 
 When writing, **try** to follow these guidelines:
 
-1. Use the active voice. For example, instead of `The player can use the command`, write `Players can use the command`.
+1. Use the active voice. For example, instead of `The pig is teleported by the command`, write `The command teleported the pig`.
 2. Don't use unnecessary adverbs or adjectives
-3. Don't use the words: _obvious, simple, basic, easy, actual, just, clear,_ and _however_
+3. Try not to use the words: _obvious, simple, basic, easy, actual, just, clear,_ and _however_
 4. Explicitly reference what you are explaining
 5. Use `'s` for indicating possession
 6. Use the [Oxford comma](https://simple.wikipedia.org/wiki/Serial_comma)
@@ -126,4 +126,4 @@ Highlighting is a way to highlight specific text. It isn't commonly used, but ex
 ## Standardized Elements
 
 The wiki uses a few elements that are standardized across the entire wiki. Right now this only consists
-of command syntax. You can find the command syntax we use in the [commands page](/wiki/concepts/about).
+of command syntax. You can find the command syntax we use in the [commands page](/wiki/command/all).

package.json

@@ -7,43 +7,34 @@ description: "This page is an introduction to our Git practices a page for the w
 
 **Last Updated:** 12-13-2024
 
-This page is an introduction to how we use Git in the wiki repository. In order to keep the wiki consistent and
+This page is an introduction to how we use Git in the [wiki repository](https://github.com/Datapack-Hub/wiki). In order to keep the wiki consistent and
 reputable, we have a few rules that we follow.
 
 Git provides a lot of features that are great for collaboration, and we try to use them as much as possible.
 
-## Branching and PRs
+:::info
+This guide assumes you already have experience using Git before.
+:::
 
-Branches are a great way to work on the wiki without introducing unfinished pages, changes, etc. Branches allow you to
-work on a page without affecting the main (production) branch and allow us to review your changes before they are
-merged.
+## Forking and PRs
 
-### Branch Naming
+Forks are a great way to work on the wiki without introducing unfinished pages, changes, etc. to main.
+You can click the ["Fork"](https://github.com/Datapack-Hub/wiki/fork) button in the top right corner of the repository to
+create a fork of the repository. This will create a complete copy of the repository that you can work on.
 
-We use `kebab-case` for branch names meaning the branch name should be all lowercase with hyphens to
-separate words. For example, if you are working on a page called "Adding New Features", the branch name should be
-`adding-new-features`.
-
-### Branch Workflow
-
-When you are ready to merge your changes into the main branch, create a pull request (PR) and assign it to a
-reviewer. The reviewer will review your changes and either approve or request changes. Once approved, the changes will
-be merged into the main branch.
-
-We recommend deleting the branch after it has been merged into the main branch. This will keep the repository clean and
-reduce confusion. An exception to this is if you are working on a very large feature that will take a while to merge, or
-if you plan to merge multiple features from one branch.
+Once you have forked the repository, you can clone it to your local machine.
 
-## Forking
+When it comes time to merge your changes, you can create a pull request, and a wiki contributor will review your contribution.
 
-Forking is another way to work on the wiki without affecting the main branch. This is useful if you are a first-time
-contributor and don't have write access. You can click the "Fork" button in the top right corner of the repository to
-create a fork of the repository. This will create a copy of the repository that you can work on.
+## Branches
 
-Once you have forked the repository, you can clone it to your local machine.
+Branches are useful additions to help separate features in your fork. We use `kebab-case` for branch names meaning the branch 
+name should be all lowercase with hyphens to separate words. For example, if you are working on a page called "Adding New Features", 
+the branch name should be `adding-new-features`.
 
-When it comes time to merge your changes, you can create a pull request in the same way as you would with a branch, just
-replace the branch name with the name of your fork's branch name.
+We do not recommend you use branches for the main repository, even if you have permissions to. 
+Branches in the repository are mainly for upcoming Minecraft versions or huge upcoming reworks, if you believe you 
+have a reason to add a branch to the main repository, let a wiki admin know.
 
 ## Commit Messages
 
@@ -63,7 +54,7 @@ Whenever you start working on a new branch or features, pull the latest changes
 will ensure that you have the most up-to-date changes.
 
 You will likely run into an issue with the `search.json` file, which is used to generate the search index. This file is
-generated automatically and should not be manually edited. A solution to this is to remove the `search.json` file and
+generated automatically and should not be manually edited. A solution to this is to remove the `search.json` file and optionally
 run the search index generation script. This will regenerate the file and you can commit it.
 
 ```
@@ -76,8 +67,6 @@ bun ./gen_search_indexes.js
 
 ## Other Important Information
 
-- Always use the `main` branch as the base branch for your PRs. This will reduce the chances of conflicts and ensure
-  that your changes are merged correctly.
 - Make a description of your changes in your PR.
 - Reviewers: Proofread changes before approving them.
 - Reviewers: It's not required, but it's recommended the changes follow American English for consistency sake.

src/lib/sidebar/tabs/WikiPages.svelte

@@ -30,6 +30,8 @@ These people have written or edited pages for the wiki or guides.
 
 - Diamond
 - HeDeAn
+- SuperAnt_
+- SwitchedCube
 
 :::note
 If you're contributing, feel free to add your username to this page! You can contribute by clicking the Edit

src/routes/contribute/formatting/+page.svx

@@ -82,7 +82,7 @@ always ran as an entity (or as the Server) and at a position
 :::
 
 Let's get started by writing one simple function. In
-traditional programming fashion, let's make a function to show you "Hello World" when it is ran.
+traditional programming fashion, let's make a function which sends "Hello World" to chat.
 
 1. Create a folder in your datapack called `data`.
 2. In the `data` folder, create a new folder. This folder is your **namespace** - it will contain all the data specific
@@ -97,7 +97,7 @@ You should now have a folder structure that looks something like this:
 ```
 
 :::warning
-In versions earlier than 1.21, the function folder should be called functions, due to some pesky name changes
+In versions earlier than 1.21, the function folder should be called `functions`, due to some pesky name changes
 Mojang introduced in a recent update.
 :::
 

src/routes/contribute/git-practices/+page.svx

@@ -65,13 +65,13 @@ call the raycast function again _(recursion)_.
 
 ```mcfunction:raycast.mcfunction
 # Remove one from the raycast limit
-scoreboard players remove .raycastlimit raycast 1
+scoreboard players remove .raycastLimit raycast 1
 
 # Optional: display a particle
 particle minecraft:flame
 
 # Check if the raycast has hit an entity's hitbox
-execute positioned ~-.99 ~-.99 ~-.99 as @e[dx=0,tag=!raycaster] positioned ~.99 ~.99 ~.99 as @s[dx=0] run return run <namespace>:hit
+execute positioned ~-.99 ~-.99 ~-.99 as @e[dx=0,tag=!raycaster] positioned ~.99 ~.99 ~.99 as @s[dx=0] run return run function <namespace>:hit
 
 # If the raycast has not hit a wall, and the limit has not been reached, move the raycast forward and run the function again
 execute if block ~ ~ ~ #minecraft:replaceable if score .raycastLimit raycast matches 1.. positioned ^ ^ ^0.1 run function <namespace>:raycast