6 files changed, 61 insertions, 21 deletions
diff --git a/doc/auth_backends.md b/doc/auth_backends.md
index 59c453f..ce9dc2b 100644
--- a/doc/auth_backends.md
+++ b/doc/auth_backends.md
@@ -1,14 +1,17 @@
 # Authentication backends
 
 ## Supported backends
+
 All backends prefixed with `mt` are implementations of the upstream backends.
 They store ban information in `ipban.txt` in the Minetest format.
 
 ### files
+
 This is the default authentication backend unless specified otherwise
 in the [config](https://github.com/HimbeerserverDE/mt-multiserver-proxy/blob/main/doc/config.md).
-It creates a directory named `auth` in the proxy directory. It contains subdirectories
-for each user. These are home to several files (created on demand):
+It creates a directory named `auth` in the proxy directory.
+It contains subdirectories for each user.
+These are home to several files (created on demand):
 
 * `salt`: The binary SRP salt of the user.
 * `verifier`: The binary SRP verifier of the user.
@@ -24,13 +27,15 @@ and providing future expandibility. It's also very simple and easily readable
 for humans or shell scripts.
 
 ### mtsqlite3
-This backend is partially compatible with regular Minetest `auth.sqlite` databases.
+
+This backend is partially compatible with regular Minetest `auth.sqlite` DBs.
 The proxy is able to run using this backend and the authentication information
 can be converted by [mt-auth-convert](#mt-auth-convert).
 However storing a player's last server is not supported with this backend
 and no conversions involving it will ever output server information.
 
 ### mtpostgresql
+
 This backend provides partial compatibility with regular Minetest PostgreSQL
 databases. The proxy is able to run using this backend and the authentication
 information can be converted by [mt-auth-convert](#mt-auth-convert).
@@ -42,6 +47,7 @@ The proxy uses a configuration value for this
 while the converter gets them from command-line arguments.
 
 ## Dealing with existing Minetest databases
+
 If possible you should always convert your existing database
 to the `files` format. An alternative is to reconfigure the proxy
 to use the existing format directly at the cost of reduced functionality.
@@ -49,9 +55,14 @@ This method currently does not support storing the last server
 a user was connected to, for example.
 
 ## mt-auth-convert
+
 There's a tool that is able to convert between the supported backends.
 
 ### Installation
+
+If you didn't install all tools using the command in [README.md](https://github.com/HimbeerserverDE/mt-multiserver-proxy#readme),
+manually run the following command to install `mt-auth-convert`:
+
 ```
 go install github.com/HimbeerserverDE/mt-multiserver-proxy/cmd/mt-auth-convert@latest
 ```
@@ -59,7 +70,9 @@ go install github.com/HimbeerserverDE/mt-multiserver-proxy/cmd/mt-auth-convert@l
 Please specify the version explicitly if @latest differs from your proxy version.
 
 ### Usage
-1. Move the binary to the directory the proxy binary is located in. The same rules apply regarding symlinks (see [README](https://github.com/HimbeerserverDE/mt-multiserver-proxy#readme)).
+
+1. Move the binary to the directory the proxy binary is located in.
+The same rules apply regarding symlinks (see [README.md](https://github.com/HimbeerserverDE/mt-multiserver-proxy#readme)).
 2. Move or copy the source database to the directory.
 3. Stop the proxy.
 4. Run the conversion tool.
diff --git a/doc/build_env.md b/doc/build_env.md
index 4533374..4ba68cd 100644
--- a/doc/build_env.md
+++ b/doc/build_env.md
@@ -1,14 +1,17 @@
 # Build environment
 
 ## `go version`
+
 ```
 go version go1.21.4 linux/amd64
 ```
 
 ## Build commands
+
 All commands are run in the project root directory.
 
 ### Compile development version to check for errors
+
 ```
 go build -race ./cmd/mt-auth-convert
 go build -race ./cmd/mt-build-plugin
@@ -16,11 +19,13 @@ go build -race ./cmd/mt-multiserver-proxy
 ```
 
 ### Install and run latest version
+
 ```
 go install github.com/HimbeerserverDE/mt-multiserver-proxy/cmd/...@latest && mt-multiserver-proxy
 ```
 
 ## Formatting
+
 ```
 goimports -l -w .
 # go fmt
diff --git a/doc/config.md b/doc/config.md
index ce2c64f..e1eed63 100644
--- a/doc/config.md
+++ b/doc/config.md
@@ -1,12 +1,15 @@
 # Configuration file
 
 ## Location
+
 The configuration file is automatically created in the working directory.
 The file name is `config.json`.
 
 ## Example
+
 This is an example configuration file with two servers. Remember to install
-[the chat command plugin](https://github.com/HimbeerserverDE/mt-multiserver-chatcommands) and to configure the permissions.
+[the chat command plugin](https://github.com/HimbeerserverDE/mt-multiserver-chatcommands)
+if you need it and to configure the permissions.
 
 ```json
 {
diff --git a/doc/dynamic_servers.md b/doc/dynamic_servers.md
index 459c8da..31e5086 100644
--- a/doc/dynamic_servers.md
+++ b/doc/dynamic_servers.md
@@ -1,6 +1,7 @@
 # Dynamic servers
 
 ## About
+
 While servers are traditionally defined in the config
 plugins have the ability to add new servers at runtime.
 Dynamic servers can be deleted when they are no longer needed
@@ -13,17 +14,23 @@ This feature can be useful to implement things like starting
 minigame servers as needed.
 
 ## Adding servers at runtime
-A plugin may call [AddServer](https://pkg.go.dev/github.com/HimbeerserverDE/mt-multiserver-proxy#AddServer) to dynamically create a server at any time.
+
+A plugin may call [AddServer](https://pkg.go.dev/github.com/HimbeerserverDE/mt-multiserver-proxy#AddServer)
+to dynamically create a server at any time.
 It returns a boolean indicating success.
 
 ### Conditions
+
 * Server name is not taken
 * Media pool contains at least one static member
 
 ## Removing servers at runtime
-A plugin may call [RmServer](https://pkg.go.dev/github.com/HimbeerserverDE/mt-multiserver-proxy#RmServer) to dynamically delete a dynamic server at any time.
+
+A plugin may call [RmServer](https://pkg.go.dev/github.com/HimbeerserverDE/mt-multiserver-proxy#RmServer)
+to dynamically delete a dynamic server at any time.
 It returns a boolean indicating success or an already inexistent server.
 
 ### Conditions
+
 * Server was dynamically added
 * No player connections
diff --git a/doc/media_pools.md b/doc/media_pools.md
index d2bf68b..fd0fa9c 100644
--- a/doc/media_pools.md
+++ b/doc/media_pools.md
@@ -4,6 +4,7 @@ All servers must be part of a media pool. By default the name of the server
 is used.
 
 ## Background
+
 When the proxy sends any content-related packets to the client,
 it prefixes any content names such as node names or media file names
 with the media pool of the current server and an underscore.
@@ -11,12 +12,15 @@ The purpose of this is to allow servers to have different media
 with the same name and to avoid some other multiplexing issues.
 
 ## When to use media pools?
+
 In general, custom media pools are not required.
 There are reasons to use them:
-- reducing memory and storage usage on the client
-- dynamically adding servers
+
+* reducing memory and storage usage on the client
+* dynamically adding servers
 
 ### Reducing RAM and disk usage
+
 The client has to store all media it receives in memory and in its cache.
 Minetest doesn't do this very efficiently: Identical files with different
 names will not share memory, a copy will be made. Even if they did share
@@ -35,15 +39,17 @@ unneeded files too. This isn't as big of a problem as the cache isn't
 inexperienced players are going to wonder where their disk space is going.
 
 ### Dynamic servers
-These are a whole other mess but all you need to know is that they won't work
-without media pools. The reason is that connected clients can't get the new
-content without reconnecting due to engine restrictions. Media pools are
+
+Dynamic servers always require the use of media pools.
+The reason is that connected clients can't get the new
+content without reconnecting due to engine limitations. Media pools are
 pushed to the client when it connects. This requires the first server of the
 media pool to be reachable. This means you can make a dummy server for the
 media and prevent players from connecting to it, or just use a hub server
 as the media master.
 
 ## How to use media pools?
+
 Simply specify the name of the media pool you'd like the server to be part of
 in the MediaPool field of the server definition. All server you do this for
 will be part of the pool. Alternatively you can specify the name of another
diff --git a/doc/plugins.md b/doc/plugins.md
index 5417446..dc91957 100644
--- a/doc/plugins.md
+++ b/doc/plugins.md
@@ -1,10 +1,12 @@
 # Plugins
+
 mt-multiserver-proxy loads all plugin files in the `plugins` directory
 on startup. Any errors will be logged and do not prevent other plugins
 from being loaded. Plugins **cannot** be (re)loaded at runtime, you
 need to restart the proxy.
 
 ## Installing plugins
+
 The recommended way to install plugins is cd'ing into the `plugins` directory,
 downloading the source code (e.g. using `git clone`) into it
 and starting the proxy without setting the `NoAutoPlugins` config option
@@ -14,9 +16,8 @@ The proxy will detect its own version automatically
 and attempt to build the plugin against it, making this the easiest way
 for end users to deal with versioning.
 
-This won't work in development builds.
-
 ### Manual installation
+
 To install a plugin manually, clone the repository, cd into it and run:
 
 ```
@@ -27,6 +28,7 @@ A .so file will be created. Copy or move this file into the `plugins`
 directory. Restart the proxy to load the plugin.
 
 ### Automatic version management
+
 To make dealing with version issues easier for end users
 the `mt-build-plugin` tool is provided. It automatically detects
 the correct proxy version and builds the plugin in the working directory
@@ -39,6 +41,7 @@ mt-build-plugin
 ```
 
 ## Developing plugins
+
 A plugin is simply a main package without a main function. Use the init
 functions instead. Plugins can import
 `github.com/HimbeerserverDE/mt-multiserver-proxy` and use the exported
@@ -49,6 +52,7 @@ Crucially, symbols may be renamed or deleted and fields may be deleted
 from type definitions.**
 
 ## Common issues
+
 If mt-multiserver-proxy prints an error similar to this:
 
 ```
@@ -74,6 +78,15 @@ My build environment can be found in
 [build_env.md](https://github.com/HimbeerserverDE/mt-multiserver-proxy/blob/main/doc/build_env.md).
 
 ## Using plugins with development builds
+
+The `mt-build-plugin` tool as well as the proxy itself are capable of
+handling development versions, but the former only works if it's located
+in the same directory as the proxy executable. See
+[Automatic version management](https://github.com/HimbeerserverDE/mt-multiserver-proxy/blob/main/doc/plugins.md#automatic-version-management)
+for details.
+
+### Manual version management
+
 You can build a development version by following the instructions in
 [README.md](https://github.com/HimbeerserverDE/mt-multiserver-proxy/blob/main/README.md#development-builds).
 
@@ -84,10 +97,3 @@ edit the go.mod file of your plugin. Find the line that says
 and copy everything excluding the `require `. Then append a new line:
 `replace github.com/HimbeerserverDE/mt-multiserver-proxy SOMEVERSION => ../path/to/proxy/repo/`.
 Now rebuild and install the plugin and it should be loaded.
-
-### Automatic development version management
-The `mt-build-plugin` tool as well as the proxy itself are capable of
-handling development versions, but the former only works if it's located
-in the same directory as the proxy executable. See
-[Automatic version management](https://github.com/HimbeerserverDE/mt-multiserver-proxy/blob/main/doc/plugins.md#automatic-version-management)
-for details.