feat: all things done except upgrade page

Author: MC-XiaoHei

docs/en/afterword.md

@@ -0,0 +1,90 @@
+---
+order: 17
+authors:
+  - JorelAli
+---
+
+# Afterword
+
+<div style="text-align: center;">
+
+## A message from the CommandAPI's author
+
+</div>
+
+Congratulations on making it to the end of the documentation! It's really long, but I did my best to make it the best (Bukkit/Spigot plugin) documentation in existence.
+
+### Intro
+
+My name is Jorel, commonly known by my Minecraft username _Skepter_. I started the CommandAPI in the summer holidays between my first and second year at university. On the 19th August, 2018 I made my first commit to the CommandAPI project - just a month and a day after Minecraft 1.13 was released.
+
+At the time, I just decided to call it "The 1.13 Command API" - it wasn't the catchiest name out there, but it sort of said what I wanted it to - it's a Command API for Minecraft 1.13, which was the update when the big overhaul to the command system was introduced.
+
+It all started as a simple idea that can be summarized in 3 bullet points:
+
+- Create an API to use the new command UI that was introduced in Minecraft 1.13
+- Make it so the developers don't have to understand/use Mojang's brigadier
+- Make it similar to Bukkit's existing API
+
+### Starting out
+
+After the release of version 1.2, two days after the initial release, I received my first GitHub issue. This was quite a shock to me - version 1.2 only had 11 total downloads so it seemed odd that someone managed to stumble upon it despite the fact that I did nothing to promote the CommandAPI. Little did I know that that one issue was the main motivation to keep this API alive after its initial release.
+
+I would never have possible imagined in my wildest dreams that 2 years later, I would still be in contact with them and know that if I had not chosen to create this API, their server would not have survived beyond Minecraft 1.13, let alone Minecraft 1.15, two major Minecraft versions later.
+
+### Reflection on the project and personal gains
+
+This project has been insane. Absolutely, utterly insane. At over 1000 commits and over 1,000,000 additions (that includes things such as lines of code, lines of generated HTML documentation etc.), I can say without a doubt that this is indeed my biggest project ever.
+
+Not only have I managed to deal with hundreds of GitHub issues, I've also had the opportunity to try all sorts of technologies that I could have only dreamt of using, such as:
+
+- Using GitHub Actions for cloud-based build checking and project status notifications
+- Using CodeFactor.io to automatically identify issues with my code
+- Publishing the CommandAPI to MavenCentral
+- Improving my understanding of Gradle to write Gradle instructions for the documentation
+- Learning Kotlin to add Kotlin examples to the CommandAPI's documentation
+- Learning TypeScript for an upcoming web-based CommandAPI command visualizer
+
+### Acknowledgements (early development)
+
+Anyway, I digress. I'd like to give credit to all of the people that have opened issues on the CommandAPI GitHub, for without these people, the CommandAPI would have only remained a shadow of what it is now. I'd like to give credit to [the people that have starred](https://github.com/CommandAPI/CommandAPI/stargazers) the CommandAPI on its GitHub page, and all of the members of the [CommandAPI Discord server](https://discord.com/invite/G4SzSxZ).
+
+I would like to personally give thanks to the following people - these are people that have made a significant contribution to the project in terms of ideas or support early in the CommandAPI's development:
+
+- **[Combustible](https://github.com/Combustible)**, who kickstarted the project by creating the CommandAPI's first issue. From this issue, this allowed the CommandAPI to have interoperability with Minecraft commands and functions which is by far the CommandAPI's most admirable feature. Additionally, Combustible helped raise awareness of the CommandAPI via the Spigot forums and Spigot issue tracker.
+- **[Draycia](https://github.com/Draycia)**, who suggested implementing lazy evaluation for argument suggestions. This has been extended to provide the CommandAPI's context-aware system for argument suggestions based on previously filled arguments.
+- **[HielkeMinecraft](https://github.com/HielkeMinecraft)**, who made three outstanding contributions to the CommandAPI. They created the suggestion of setting the result and success values of commands which improves the interoperability between commands registered with the CommandAPI and vanilla Minecraft commands. They also influenced the implementation of the requirements system to have more powerful command constraints and helped start the CommandAPI Discord server.
+- **[Minenash](https://github.com/Minenash)**, who was the driving force for the CommandAPI's 3.0 release, which added a plethora of new arguments to the CommandAPI. Minenash's research, code prototypes, documentation examples, bug testing and code review was a tremendous help to make the 3.0 release such a feature-rich version.
+- **[Michael-Ziluck](https://github.com/Michael-Ziluck)**, who created an amazing pull request that helped greatly improve the performance of the CommandAPI as well as structure the entire CommandAPI project into a multi-module Maven project which significantly improved the maintainability of the CommandAPI for the future.
+- **[portlek](https://github.com/portlek)**, who helped migrate the CommandAPI's repository to [jitpack.io](https://jitpack.io/#dev.jorel/CommandAPI). They helped debug some technical errors with remote building and tested that the repository was working throughout the process.
+- **[469512345](https://github.com/469512345)**, who redesigned and implemented the suggestions feature for arguments, bringing powerful asynchronous arguments and highly-extensible suggestions to the CommandAPI.  They also implemented the CommandTree feature to bring yet another way for developers to create commands with the CommandAPI.
+
+I'd also like to give a special mention to the following people that have helped find bugs or have supported the project in some way early in the CommandAPI's development: aianlinb, Baka-Mitai, Checkium, Comeza, DerpNerb, DogeBogey, endrdragon, EnragedRabisu, i509VCB, KieranGateley, lifespan, Loapu, Marvmallow, MatrixTunnel, Ricky12Awesome, SHsuperCM, SpaceCheetah, The_Gavster, Tinkot, vladfrangu, zedwick.
+
+### Acknowledgements (CommandAPI Discord server)
+
+I'm well aware there are lots of users that have made significant contributions to the CommandAPI that aren't listed above! Over the past four years, hundreds of users have created GitHub issues, joined the CommandAPI Discord server and submitted pull requests to contribute to the CommandAPI.
+
+I'd like to personally give thanks to my _✨Special Contributors_ in the CommandAPI Discord server - these are users that have made an exceptionally significant contribution to the CommandAPI project in general, from helping new users get started with the CommandAPI, to contributing to the CommandAPI repository directly, to bringing a liveliness to the CommandAPI Discord server as a whole:
+
+- **[willkroboth](https://github.com/willkroboth)**, the first _✨Special Contributor_, recognized for their above-and-beyond contribution to helping new CommandAPI Discord members.
+- **[DerEchtePilz](https://github.com/DerEchtePilz)**, recognized for their significant contribution of creating a Kotlin DSL for the CommandAPI (with the help of Sparky from the CommandAPI Discord server).
+- **[Hawk](https://github.com/XHawk87)**, recognized for becoming the lead developer of the CommandAPI annotation system.
+
+The CommandAPI would not be where it is currently without the community that has been established over the years in the CommandAPI Discord server. As such, I'd like to give a special thanks to some of the most active CommandAPI Discord server members that make the community feel lively:
+
+- ! AkaGiant !
+- Brought To You By
+- MineNash
+- TheGates
+- Strokkur24
+
+### Acknowledgements (Donators)
+
+I didn't really want to add a way for CommandAPI users to be able to contribute financially via donations because the CommandAPI is free for all and the cost of maintaining the CommandAPI is effectively negligible. That said, I'd like to give special thanks to those that have donated to the CommandAPI.
+
+### Final comments
+
+I never really expected more than 5 or so people to use this API, so it was truly a pleasure to see everyone's responses, issues and suggestions that has made the CommandAPI what it is today.
+
+Thank you so much for using the CommandAPI!

docs/en/contribution/intro.md

@@ -0,0 +1,13 @@
+---
+order: 1
+authors:
+  - JorelAli
+---
+
+# Introduction
+
+:::info
+
+Coming soon! In this section, I'll outline how to get started with building and contributing to the CommandAPI.
+
+:::

docs/en/contribution/project-structure.md

@@ -0,0 +1,27 @@
+---
+order: 2
+authors:
+  - JorelAli
+---
+
+# Project Structure
+
+The CommandAPI is a relatively large project (especially from the standpoint of one guy, because the CommandAPI was written by just one guy in their spare time!) and trying to figure out what everything does is a nightmare without some guidance. I've always felt that other community project structures aren't well documented and contributing to them can be daunting. Here's the CommandAPI's project structure for you!
+
+## CommandAPI submodule folders
+
+This is where all of the code is for the CommandAPI. The CommandAPI is a Maven project with multiple modules which each serve a different purpose:
+
+- `commandapi-preprocessor` - The CommandAPI uses a bit of reflection to perform things which could not normally be done (for example, allowing custom commands in datapacks). Reflection is inherently unsafe and can lead to runtime errors if specific fields or methods are not present. The CommandAPI preprocessor project is a source annotation processor that checks all declared reflection calls and looks up at compile-time whether those calls are possible - if not, it prevents the CommandAPI from building. In short, it's a compile-time reflection checker.
+
+- `commandapi-x.x.x` - The CommandAPI needs to access various NMS methods in order to operate. These are implemented for the specific version given by `x.x.x`. For example, to support Minecraft `1.16.5`, the project is `commandapi-1.16.5`. The `NMS` class implementation is done in these version-specific files.
+
+- `commandapi-core` - The main brains of the CommandAPI. This includes both the code that makes the CommandAPI run, as well as the API which developers can use.
+
+- `commandapi-vh` - The CommandAPI version handler. This is a super tiny project which simply links up all of the NMS version-specific files into the CommandAPI. This is only used for the actual running of the CommandAPI (e.g. the CommandAPI plugin or shading the CommandAPI). This ensures proper compile-time safety of NMS implementations.
+
+- `commandapi-plugin` - It's the CommandAPI plugin! This is the project which is used for releases to both GitHub and Spigot. It's the CommandAPI all in one neat package, with a few extra features such as config-based command conversion for server owners (or other non-developers)
+
+- `commandapi-shade` - It's the CommandAPI, but in shade-able format. It has none of the features of the CommandAPI plugin variant and can be shaded into your own plugins. Effectively, it's `commandapi-core` + `commandapi-vh` with all of the `commandapi-x.x.x` NMS implementations included.
+
+- `commandapi-annotations` - The CommandAPI annotations project is a small compile-time annotation processer that writes CommandAPI code for you. Using a compile-time annotation processor makes the server run so much faster than using a runtime-annotation processor, because annotation processing requires reflection to inspect class metadata.

docs/en/faq.md

@@ -0,0 +1,83 @@
+---
+order: 14
+authors:
+  - JorelAli
+---
+
+# FAQ
+
+Here's a list of questions that have come up time and time again which all have the same answer.
+
+## How do I use (insert feature here) in the CommandAPI?
+
+The CommandAPI's documentation is the place to search for anything! In the top left corner of this documentation, you can find this <i class="fas fa-search"></i> icon. You can pretty much search for anything - it'll find it!
+
+## Does the CommandAPI support reloading via `/reload`?
+
+Formally, no. If you are encountering issues with `/reload`, consider not using `/reload`. More information about reloading can be found in [Plugin reloading](./utils/reload).
+
+## Does the CommandAPI support optional arguments?
+
+As of 9.0.0, yes! Please view information on optional arguments in [Optional arguments](./create-commands/arguments/optional-arguments).
+
+## Does the CommandAPI support suggestions in the annotation system?
+
+Not yet. The CommandAPI's annotation system was actually originally a little test on writing a compile-time annotation system which actually worked out much better than I had intended. I plan to rewrite the CommandAPI's annotation system to make it much more powerful (and support suggestions!). This is stated in the [project roadmap](https://github.com/CommandAPI/CommandAPI#future-project-plans--timeline)
+
+## Can you add tooltips to literal/multiliteral arguments?
+
+No. This is a Brigadier limitation.
+
+:::info Technical reason that this is a limitation of Brigadier
+
+Brigadier's code has two classes for arguments, [`LiteralCommandNode`](https://github.com/Mojang/brigadier/blob/master/src/main/java/com/mojang/brigadier/tree/LiteralCommandNode.java) and [`ArgumentCommandNode`](https://github.com/Mojang/brigadier/blob/master/src/main/java/com/mojang/brigadier/tree/ArgumentCommandNode.java). The `ArgumentCommandNode` class contains a field `customSuggestions` of type `SuggestionProvider<S>` which is used to handle suggestions - this field is not present inside `LiteralCommandNode`, meaning that LiteralArguments cannot provide suggestions to users.
+
+We need suggestions to provide tooltips. This is because [`SuggestionProvider` provides us with an instance of `SuggestionsBuilder`](https://github.com/Mojang/brigadier/blob/master/src/main/java/com/mojang/brigadier/suggestion/SuggestionProvider.java#L13), [`SuggestionsBuilder` contains a `List<Suggestion>`](https://github.com/Mojang/brigadier/blob/cf754c4ef654160dca946889c11941634c5db3d5/src/main/java/com/mojang/brigadier/suggestion/SuggestionsBuilder.java#L20) and the [`Suggestion` class contains `Message`](https://github.com/Mojang/brigadier/blob/cf754c4ef654160dca946889c11941634c5db3d5/src/main/java/com/mojang/brigadier/suggestion/Suggestion.java#L14). This `Message` class is what is needed to display a tooltip to users.
+
+:::
+
+## Can I change the message that is sent to the user when they don't have permission to run a command?
+
+No. That message is handled client-side and isn't controlled by the CommandAPI. An alternative solution is to perform permission checking _inside_ the command and return a custom message if it's not satisfied:
+
+```java
+new CommandAPICommand("mycommand")
+    .withPermission("some.permission")
+    .executes((sender, args) -> {
+        sender.sendMessage("Hello!");
+    })
+    .register();
+```
+
+$$\downarrow$$
+
+```java
+new CommandAPICommand("mycommand")
+    .executes((sender, args) -> {
+        if(!sender.hasPermission("some.permission")) {
+            throw CommandAPI.failWithString("You don't have permission to run /mycommand!");
+        }
+        sender.sendMessage("Hello!");
+    })
+    .register();
+```
+
+## Can I change the message that is sent to the user when an argument isn't valid?
+
+No. That message is handled client-side and isn't controlled by the CommandAPI.
+
+## My suggestions on my arguments are empty or don't update. How do I make dynamic suggestions?
+
+Arguments with suggestions provided using `ArgumentSuggestions.strings(String...)` are calculated _when the command is registered_. In order to have argument suggestions calculated _when the command is being typed_, you need to use the lambda-variant of the `ArgumentSuggestions.strings(Function<SuggestionInfo, String[]> suggestions)` method instead. More information about the different methods can be found [here](./create-commands/arguments/suggestions/suggestions#the-argumentsuggestions-interface).
+
+The easiest way to do this is to add `info ->` at the start of your array:
+
+```java
+ArgumentSuggestions.strings(SomeClass.someArray);
+```
+
+$$\downarrow$$
+
+```java
+ArgumentSuggestions.strings(info -> SomeClass.someArray);
+```

docs/en/incompatible-versions.md

@@ -0,0 +1,52 @@
+---
+order: 15
+authors:
+  - JorelAli
+  - DerEchtePilz
+---
+
+# Incompatible version information
+
+There are a few arguments that are incompatible with various versions of Minecraft. This page outlines the full list of incompatibilities that the CommandAPI has with what versions of Minecraft.
+
+## Argument changes with respect to Minecraft version
+
+### ChatArgument's chat preview
+
+Incompatible with Minecraft versions **less than 1.19 and greater than 1.19.2** _(Works on 1.19, 1.19.1 and 1.19.2)_
+
+### FunctionArgument
+
+Running functions generated via the `FunctionArgument` on Minecraft version **1.20.3** and **1.20.4** will always return a value of 1, regardless of whether the command succeeds, fails, or returns a result. (Works normally on 1.20.2 and below). Trying to retrieve the list of commands in a function on Minecraft version **1.20.3** and **1.20.4** will always return an empty array.
+
+## CommandAPI behavior with respect to Minecraft version
+
+### Minecraft version 1.16 and beyond
+
+In Minecraft version **1.16**, the way datapacks were loaded changed in such a way that the CommandAPI had to put in additional countermeasures to provide full support to it. To illustrate this, this was the previous loading sequence for Bukkit servers in Minecraft 1.15:
+
+$\texttt{Server loads}\rightarrow\texttt{Plugins load}\rightarrow\texttt{Datapacks load}\rightarrow\texttt{Server finishes loading}$
+
+Instead however, Minecraft 1.16 changed the loading sequence to the following:
+
+$\texttt{Server loads}\rightarrow\texttt{Datapacks load}\rightarrow\texttt{Plugins load}\rightarrow\texttt{Server finishes loading}$
+
+Because the CommandAPI used to register vanilla Minecraft commands _before_ datapacks (and thus, custom Minecraft functions), it was possible to register custom commands that can be used in functions. With this new loading sequence change in Minecraft 1.16, this meant that datapacks load first before the CommandAPI does, so custom commands are not registered and functions with custom commands would fail to load.
+
+To resolve this, the CommandAPI reloads datapacks _and recipes_ at the end:
+
+$$\begin{align}
+&\quad\texttt{Server loads} \\\\
+\rightarrow&\quad\texttt{Datapacks load} \\\\
+\rightarrow&\quad\texttt{Plugins load} \\\\
+\rightarrow&\quad\texttt{Server finishes loading} \\\\
+\rightarrow&\quad\texttt{Datapacks are reloaded} && \texttt{(by the CommandAPI)} \\\\
+\rightarrow&\quad\texttt{Recipes are reloaded} && \texttt{(by the CommandAPI)}
+\end{align}$$
+
+By doing this, this means:
+
+- Custom functions from datapacks are loaded twice
+- Recipes are reloaded twice, _including_ recipes defined by other plugins
+
+Although this sounds pretty bad (since reloading these things twice can be time consuming, thus contributing to the server start-up time), it is the only way to make custom functions work in Minecraft 1.16 and beyond.