build(deps): bump click from 8.4.1 to 8.4.2 in /docs in the patches group (#4143)

Dockerfile

@@ -43,7 +43,7 @@ RUN easy-add --var os=${TARGETOS} --var arch=${TARGETARCH}${TARGETVARIANT} \
   --from ${GITHUB_BASEURL}/itzg/{{.app}}/releases/download/{{.version}}/{{.app}}_{{.version}}_{{.os}}_{{.arch}}.tar.gz
 
 # renovate: datasource=github-releases packageName=itzg/mc-monitor
-ARG MC_MONITOR_VERSION=0.16.7
+ARG MC_MONITOR_VERSION=0.16.8
 RUN easy-add --var os=${TARGETOS} --var arch=${TARGETARCH}${TARGETVARIANT} \
   --var version=${MC_MONITOR_VERSION} --var app=mc-monitor --file {{.app}} \
   --from ${GITHUB_BASEURL}/itzg/{{.app}}/releases/download/{{.version}}/{{.app}}_{{.version}}_{{.os}}_{{.arch}}.tar.gz

docs/mods-and-plugins/index.md

@@ -42,6 +42,19 @@ There are optional volume paths that can be attached to supply content to be cop
 `/mods`
 : content in this directory is synchronized into `/data/mods` for server types that use mods, [as described above](#mods-vs-plugins). For special cases, the source can be changed by setting `COPY_MODS_SRC` and destination by setting `COPY_MODS_DEST`.
 
+!!! example "Loading mods from a local directory"
+
+    This is the most basic example, where `./mods` is mounted as `/mods`. If the directory with the server's mods is located somewhere else, `./mods` can be modified accordingly.
+
+    ```yaml
+        environment:
+          EULA: "TRUE"
+          TYPE: "NEOFORGE"
+        volumes:
+        - "./data:/data"
+        - "./mods:/mods"
+    ```
+
 `/config`
 : contents are synchronized into `/data/config` by default, but can be changed with `COPY_CONFIG_DEST`. For example, `-v ./config:/config -e COPY_CONFIG_DEST=/data` will allow you to copy over files like `bukkit.yml` and so on directly into the server directory. The source can be changed by setting `COPY_CONFIG_SRC`. Set `SYNC_SKIP_NEWER_IN_DESTINATION=false` if you want files from `/config` to take precedence over newer files in `/data/config`.
 

docs/mods-and-plugins/packwiz.md

@@ -13,6 +13,8 @@ docker run -d --pull=always \
 
 packwiz modpack definitions are processed before other mod definitions (`MODPACK`, `MODS`, etc.) to allow for additional processing/overrides you may want to perform (in case of mods not available via Modrinth/CurseForge, or you do not maintain the pack).
 
+If the pack ships a `.env` file that you reference with `LOAD_ENV_FROM_FILE`, that file is re-loaded immediately after the packwiz installer runs, so the freshly downloaded values are applied to the remaining startup stages. Note that `TYPE` and `VERSION` are resolved earlier (before the deploy is dispatched), so a pack-provided `.env` cannot change those from within packwiz; use `LOAD_ENV_FROM_GENERIC_PACK` or `LOAD_ENV_FROM_ARCHIVE` for those.
+
 !!! note 
 
     packwiz is pre-configured to only download server mods. If client-side mods are downloaded and cause issues, check your pack.toml configuration, and make sure any client-only mods are not set to `"both"`, but rather `"client"` for the side configuration item.

docs/requirements.txt

@@ -1,4 +1,4 @@
-click==8.4.1
+click==8.4.2
 colorama==0.4.6
 deepmerge==2.1.0
 ghp-import==2.1.0

scripts/start-setupModpack

@@ -50,6 +50,16 @@ function handlePackwiz() {
       logError "Failed to run packwiz installer"
       exit 1
     fi
+
+    # packwiz may have just downloaded/updated the env file referenced by
+    # LOAD_ENV_FROM_FILE. The initial load in start-configuration happened
+    # before this point, so re-load it now to pick up the pack's values for
+    # the remaining setup stages (server.properties, JVM args, etc.).
+    if [[ ${LOAD_ENV_FROM_FILE:-} ]]; then
+      if ! loadEnvFromFile "${LOAD_ENV_FROM_FILE}"; then
+        exit 1
+      fi
+    fi
   fi
 }