加载器命令行

玩家通过 Copper Launcher 使用 Copper，不需要命令行。本页面向需要直接运行加载器 Jar 的场景：调试模组、写脚本，或把加载器集成进自己的启动方式。

准备

1. 游戏 Jar：官方发布的桌面版 Jar，例如从 Mindustry 官方仓库 Release 下载的 Mindustry-Desktop-xxx.jar，或 MindustryBuilds 的 BE 构建。
2. 加载器 Jar：从 MDTCopper/loader 的 Release 下载桌面端产物——带版本号的发行版 desktop-<版本>.jar（固定不动，例如 desktop-0.2.0.jar），或者每次 push 都会重建的快照 desktop-snapshot.jar（两者区别见下文）。android-<版本>.jar / android-snapshot.jar 是 Android 端用的构建器产物，桌面端不需要。本文后续示例统一把桌面产物写作 CopperLoader.jar。
3. Java 17–27：Copper 的 Mixin 引擎要求 Java 17+，加载器当前声明的支持范围是 17 到 27。这个范围写在 loader 仓库 gradle.properties 的 javaVersionRange 里，构建时连同版本号一起写进 Jar 内的 version.properties，供启动器与工具判断该配哪版 Java。低于 17 会直接失败并抛出 UnsupportedClassVersionError；高于 27 同样不行——Mixin 解析标准库类时读的是运行中 JRE 的 modules，而加载器内置的 ASM 只认到 Java 27 的类文件版本，详见启动报错 · Java 版本问题。游戏本身的要求更高：Mindustry v9 起要求 Java 25，游戏 Jar 换成 v9 之后，请把这里的 java 也换成 JDK 25 或更高（上限 27），否则同样会因为版本过低而启动失败。

启动

把两个 Jar 放在同一个目录，执行：

java -jar CopperLoader.jar -G mindustry.jar

启动时控制台会打印类似下面的日志，表示加载器已初始化：

CopperLoader v0.2.0
Game info: Desktop Release 8.159.7
Found N mods.
Launching game.

首次启动

首次启动时，Copper 会在模组文件夹中自动释放核心模组（copper-core.jar）。不要删除它，它是加载器的组成部分。

发行版与快照

首行就是加载器的版本标签，据此可以分辨手里这份是哪种构建：

构建	首行
发行版（-Prelease 构建）	CopperLoader v0.2.0
快照，且它对应的 commit 远程上有	CopperLoader snapshot+a1b2c3d
快照，工作区有改动或提交只有本地有	CopperLoader snapshot+custom

-v / --version 打印的是同一个标签。

快照不显示数字版本

不带 -Prelease 的构建一律是快照，只带 commit 或 custom 标记。它内部仍然带着 gradle.properties 里声明的数字版本——那是给模组依赖检查比较用的：模组声明 "loader": ">=0.2.0" 时按它判断，与显示出来的标签无关。

参数

参数	长参数	说明
-G <path>	--game-jar	游戏 Jar 或目录的类路径（必填，可重复）
-D <path>	--game-data	游戏数据目录（默认当前工作目录下的 .mindustry）
	--main <class>	指定游戏主类（默认按游戏 Jar 自动识别）
	--init	创建数据目录与模组文件夹后退出，不启动游戏
-d	--debug	输出调试级日志
	--verbose	输出更详细的日志
-v	--version	打印加载器的版本标签后退出
	--vanilla	原版模式：只加载原版 Mindustry 模组、核心模组与 Copper 插件（见下文）
	--mixin-log <modId>	为指定模组启用 Mixin 审计日志
	--mixin-flag <modId,flag1,...>	为指定模组添加 Mixin 环境标志
	--mod-debug-jar <path>	要调试的模组已安装的 Jar 路径（见下文）
	--mod-debug-classpath <path>	该模组的编译输出（目录或 Jar），调试时用它取代 Jar 里的同名类

三个容易踩的点

-G 可以重复指定：多个条目会按顺序组成游戏容器的类路径，用于游戏本体被拆成多个 Jar、需要额外补丁 Jar，或直接拿解压出来的目录当类路径的场景。Jar 与目录都认：

java -jar CopperLoader.jar -G mindustry.jar -G mindustry-patch.jar
java -jar CopperLoader.jar -G ./mindustry-extracted

-D 只影响数据目录：不指定时默认为当前工作目录下的 .mindustry，与启动器里的默认位置不是一回事（见使用桌面版 · 模组放在哪里）。

-- 之后的参数原样转发给游戏本体（Mindustry 主类），例如：

java -jar CopperLoader.jar -G mindustry.jar -- -server

--main 覆盖自动识别的游戏主类，仅在识别失败或需要自定义入口时使用。

原版模式

--vanilla 让加载器只启动原版游戏、跳过普通 Copper 模组：

• 加载原版 Mindustry 模组、核心模组，以及 Copper 插件——即声明了 "hidden": true 的 Copper 模组（见模组元数据 · hidden）；
• 自定义网络数据包不会注册（不会调用 registerPackets()），避免与原版联机协议冲突；
• 游戏内版本号会附加 (vanilla mode) 标记。

桌面端需要纯净的原版环境时，直接运行官方 Mindustry Jar 即可；希望在原版游戏中保留插件时才需要它，这也是 Android 端需要它的原因（见 Android（ART）平台）。

日志与调试

想要什么	用什么
更详细的加载器日志	-d（调试）或 --verbose（详细）
某个模组的 Mixin 注入过程	--mixin-log <modId>
为某个模组加 Mixin 环境标志	--mixin-flag <modId,flag1,...>
在 IDE 里调试某个模组（含热交换）	--mod-debug-jar + --mod-debug-classpath（见下文）
按报错找原因	启动报错

启动日志写在数据目录下的 last_log.txt，出错时可以先看它。

调试模组

在 IDE 里调试模组时，把模组已安装的 Jar 与编译输出（目录或 Jar）一起交给加载器，游戏就用你刚编译出来的类：

java -jar CopperLoader.jar -G mindustry.jar \
  --mod-debug-jar .mindustry/copper/mods/example-examplemod.jar \
  --mod-debug-classpath build/classes/java/main

两个参数必须同时给

只给其中一个会打印 ignoring mod debug request 告警并忽略整个请求，游戏照常按 Jar 里的类启动。 --mod-debug-jar 必须是加载器实际加载的那一份的路径（模组文件夹里的那个文件）；路径对不上时同样只告警，不会用调试类路径。

它能做这些：

• 改代码立即生效：重新编译后，游戏里跑的就是新代码——已经在运行的类可以热交换（不重启游戏就换掉已经加载的类），下一次调用就走新代码；改 Mixin 也一样，注入会重新应用到目标类。普通 JDK 下热交换只能改方法体，增删字段、增删方法、改继承关系要重启游戏；换成 JetBrains Runtime 并加上 -XX:+AllowEnhancedClassRedefinition 后这个限制会放宽，见快速开始 · 增强热交换；
• 只替换你调试的这个模组：其他模组与游戏本体不会用你的编译输出；你 Mixin 到它们身上的部分照常注入，也会一起更新；
• 改元数据要重新打包：copper.mod.json（id、Mixin 配置路径、依赖等）读的仍是 Jar 里的那份。

热交换由加载器自己准备，不用你加 -javaagent，也不用改启动方式。这是桌面端命令行能力，Android 端不使用。

用官方模板 mod-templete 起项目时，这条命令已经写好并包在 Debug 运行配置里，不需要自己敲，见快速开始 · 调试。

Android 端

Android 不使用这个 Jar：desktop-<版本>.jar 是桌面端产物，Android 端用的是加载器的 Android 构建器产物 android-<版本>.jar，运行方式由启动器安排。两条 Android 实现路线见 Android（ART）平台 与 android-bridge 平台。