奥丁之矛，可在符文桌打造。内部可容纳你的法杖，并可切换为你所选的任意一柄。

冈格尼尔法杖

一个瓦尔海姆模组，添加了 昆古尼尔，奥丁之矛——一件迷雾之地级别的武器，其内蕴藏其他法杖，并且 变为 你选中的那个。

基于 BepInEx 5.4.23.3 + 尤顿 2.29.2，目标选择 net462 （Jötunn框架和Valheim的Unity Mono运行时使用的）。

源： https://github.com/Dasone/Valheim-mod-Gungnir-staff

---

模组功能

冈格尼尔可在升级后的 符文台 在手中表现为长矛——拥有完整的原版攻击、投掷、动画和碰撞体，因为该物品是原版长矛的运行时克隆体，并在此基础上应用了自己的模型、伤害和风味文本。

它自己的把戏就是 员工架：一个内置在物品里的单行库存。将一根法杖放入架中，选中槽位，冈格尼尔就会变成那根法杖——它的攻击、伊特尔消耗、投射物、技能经验、图标和持握模型都会变成那根法杖的。收起来，它又变回长矛。新的冈格尼尔有四个架槽，每次升级增加两个（4 → 6 → 8），所以物品的品质决定了它能携带多少根法杖。

矛柄末端的晶体按法杖种类区分颜色，并配有相应的光芒和一群微粒环绕，让你一眼就能看出装填的是哪种法杖。

---

布局

GungnirStaff.sln Directory.Build.props # 所有机器路径都在这里 Environment.props.example # 复制为 Environment.props 以覆盖路径 GungnirStaff/ GungnirStaff.csproj # 引用、嵌入资源包、部署目标 Plugin.cs # BepInEx 入口点，Harmony 补丁/卸载 ModConfig.cs # 所有面向用户的设置 Inputs.cs # 可重新绑定的键盘快捷键 Localizations.cs # $token 翻译 Alive.cs # “模组是否存活？”状态报告 Commands.cs # `gungnir` 开发者控制台命令 Blueprint.cs # 一次性导出原版预制件的组件 GungnirItem.cs # 物品预制件，从原版长矛克隆而来 GungnirStandalone.cs # 同一预制件从零构建，无需克隆 GungnirRecipe.cs # 配方 + 三个升级等级 GungnirVisual.cs # 从 AssetBundle 中替换自定义模型 StaffRegistry.cs # 什么算作法杖 StaffContainer.cs # 架子库存，持久化在 m_customData 中 StaffSwitcher.cs # m_shared 投影，以及耐久度回写 GungnirBar.cs # 架子 UI，从原版 InventoryGrid 克隆而来 CrystalColors.cs # 每根法杖的水晶颜色配置 CrystalGlow.cs # 为水晶材质着色并投射光源 CrystalParticles.cs # 代码构建的水晶周围微粒和火花 Patches/PlayerPatches.cs # 生成钩子，快捷栏抑制 Patches/InventoryGuiPatches.cs # Ctrl+点击将法杖放入架子 Patches/RecipePatches.cs # 每级精确升级成本 Assets/gungnir # AssetBundle（嵌入到 DLL 中） art/ # Blender 源文件、FBX 导出、图标源文件 tools/ # Dump-GameType.ps1、Verify-Patches.ps1 Thunderstore/manifest.json # 打包元数据

---

制作

出自于 加尔dr台，2级 ——一张升级后的桌子，与基础法杖不同。

材料	制作	等级2	等级 3
世界树之木	30	15	25
精炼的埃特尔	30	20	30
雷石	3	2	4
黑色核心	2	1	2
装备槽位	4	6	8

三个等级而非四个，因为等级的存在是为了购买架子槽位，而架子在第三级时就已经满了。8个槽位的上限本身受到以下因素的限制： 备用+1…替换+8 快捷键，因此第四次升级本来只会消耗材料，却毫无收益。

黑色核心需要真正深入被感染的矿洞才能获得，而不是在地表收集。

香草将升级需求计算为 数量 1级时以及 (等级 - 1) * m_amountPerLevel 在它上方，有一条曲线，无论怎么设置都无法产生雷石递进 1、2、3、4。 食谱补丁.cs 根据需求替换确切的数字 实例，因此游戏中的其他配方都不会受到影响。

材料名称是根据ObjectDB来解析的，而不是假设的——Valheim的资产清单同时包含两者 雷石 和 雷石，而其中只有一个是该物品。

---

控制

默认设置——所有绑定均可在配置管理器（F1）中重新绑定。

输入	动作
Alt + 1…8	再次按下当前法杖可将其收起，请选择该法杖
Alt + 0	收起——昆古尼尔变回普通长矛
右键点击一个架子槽位	挥舞那根法杖
左键点击槽位	拾取或拖拽，与任何物品栏操作完全相同
Ctrl + 左键点击你物品栏中的法杖	快速把它放进架子里
鼠标中键拖动装备栏槽位（背包打开时）	将进度条移动到屏幕上的新位置

Alt，不是Ctrl，因为Ctrl是《英灵神殿》里的蹲伏键—— Ctrl+3 也让角色进入潜行。Alt键是空闲的：原版物品栏只将Shift（分堆）和Ctrl（快速移动）识别为点击修饰键。当快捷栏快捷键触发时，原版快捷栏会被抑制，所以 Alt+3 选择法杖，而不是两者都做。

香草 移动 只知道两个目的地——打开的容器，或者玩家——如果没有打开的容器，它会直接掉落到地上。 库存界面补丁.cs 声称只有在一个机架可用时才会出现这种情况，这正是 Ctrl+单击放入机架能够生效的原因。

---

配置

一切都落在 BepInEx/config/dev.samspel.gungnirstaff.cfg 并且可在配置管理器（F1）中的以下位置实时编辑 冈格尼尔法杖.

区段	里面有什么
通用	已启用 主开关， 详细日志记录
员工栏	槽位数量 （0=跟随升级等级）， 激活 （携带/已装备）， 可见性 （当冈格尼尔激活时/仅限库存/始终）， 位置X, 纵坐标, 缩放, 移动条鼠标按键, 显示快捷键, 槽位键缩放
外观	独立预制体, 基础武器预制体, 员工立场正常化、模型偏移/缩放/握持高度、长矛与法杖姿态旋转、背部槽位放置、水晶粒子模式/速率/缩放/亮度、武器发光效果
水晶颜色	每名员工一种颜色，由ObjectDB延迟绑定
按键	状态键, 收起法杖, 选择槽位1…选择槽位8

水晶颜色条目每名员工绑定一个 实际上在ObjectDB中找到，因此F1菜单列出的正是本安装所拥有的法杖——包括其他模组添加的法杖——而不是一个会过时的硬编码集合。它们以十六进制字符串存储，因为BepInEx没有内置的转换器来处理 UnityEngine.Color，并且十六进制值在配置文件中能完整往返转换。

基础武器预制体 下次游戏启动时生效：手持模型来自预制体，该预制体在加载时注册一次。

正常化员工立场 无论选择哪根法杖，Gungnir的持握方式都保持不变。投射法杖时会将其 动画状态 此外，并非每件魔法物品都是法杖形状——亡者复苏是一个头骨，原版会让角色摆出与之匹配的姿势，因此一个模仿它的冈格尼尔被当作头骨来携带。想要的姿态是 测量 从实际安装的法杖中（多数决，若无法决定则回退到 法杖) 而不是硬编码的，所以即使修改了员工套装，仍然会移动那个不合群的个体，而不是整组。仅 动画状态 在SharedData的私有副本上被覆盖，整个游戏恰好只有两处读取该字段—— 类人生物.设置动画状态 用于姿势和 更新按键提示 关于提示。伤害、施法、灵质或物品放入哪只手都不受影响。

构建预制体的两种方法

默认（独立预制体 = true) 昆古尼尔是从虚无中构建的 贡格尼尔独立版.cs，作者明确编写了每一项属性——数值均取自真实长矛的实测数据，而非凭空猜测——因此该物品完全不依赖任何原版武器。

StandalonePrefab = false 切换回原始路径：一个原版长矛的运行时克隆，为你提供可用的攻击、动画、碰撞体以及一百多个 共享数据 免费字段。它在两种意义上都作为后备方案保留——要么有意设置它，要么当独立构建未能完成时，模组会自动降级到它并在日志中说明。

攻击动画无论如何都不是依赖项： 长矛戳刺 是玩家自身动画控制器中的一个状态，所以命名它没有任何代价。

无论选择哪条路径，都会在下次游戏启动时生效，因为预制件只在加载时注册一次。

---

员工装备架的使用方法

冈格尼尔不会像其他法杖那样作为可切换的道具——它 变成 他们。

瓦尔海姆通过以下方式保持物品的身份 掉落预制体，但驱动其所有 行为 通过 共享. 将冈格尼尔指向 m_shared 因此，存储的法杖会让所有原版系统——攻击、伊特尔消耗、投射物、技能经验、左/右/中键点击、手持模型、图标——表现得就像该法杖已装备一样，无需为每把法杖单独编写代码。该物品在保存和重新加载时仍然会显示为冈格尼尔，因为 背包.保存 写入 名称，这一点永远不会改变。

储存位于物品自身的 自定义数据 字典，原版游戏能为我们完成完整的往返转换。存储的法杖在重新登录后依然保留，跟随物品进入箱子，在物品掉落时写入ZDO，而且不需要我们自己的存档文件。

升级将替换该物品。 制作物品 不会提升你交给它的武器等级——它会卸下该武器，将其从物品栏中移除，并根据配方预制体生成一把全新且等级更高的武器，仅保留原武器的网格位置和变体。武器架位于 自定义数据，而替换版本没有这一特性，因此升级会消耗掉所有储存的员工。 制作升级补丁 先把数据复制到替换对象上，并优先收起武器，这样原版游戏读取的是昆古尼尔自身的等级，而不是投射出的法杖的等级。

冈格尼尔自身的等级也保存在自定义数据中（冈格尼尔任务），因为投射法杖会覆盖 品质 以那根法杖的等级为准。它不是装饰性数字：它决定架子的宽度，也是升级所提升的数值。

代价是：这些法杖与冈格尼尔同命相连。 它们是物品的一部分，而不是独立的容器，因此任何能摧毁冈尼尔的东西都会连同它们一起摧毁——而卸载模组会带走整个物品，包括法杖，因为预制体已不再存在可供加载。运行 冈格尼尔空了 将它们移入你自己的物品栏 之前 正在卸载。此后模组无法再挽救它们；到那时它已不再运行。

员工的定义由ObjectDB检测 按技能类型，而不是来自名称列表——因此原版员工无论有多少都能自动找到，其他模组添加的员工也一样，这里无需任何更改。

进度条可以在打开物品栏时用鼠标中键拖拽到新位置——这是光标唯一不受限制的时候，如果在光标被镜头捕获时拖拽，玩家一转动视角进度条就会被甩得到处乱飞。拖拽通过以下方式读取光标 RectTransformUtility.ScreenPointToLocalPointInRectangle 而是基于血条的父级空间，而不是直接以原始像素为单位进行操作，因此它在任何UI缩放或分辨率下都能正确追踪，并且它使用该空间中两点之间的差值，这正是它不受父级本地原点与血条自身锚点原点不同的影响的原因。结果被写回到 位置X/纵坐标 释放时保存，这样拖拽后的位置在重新登录后仍然保留，并且仍可通过F1进行编辑。 MoveBarMouseButton = -1 把它关掉。

开始拖拽时，命中检测的是实际的槽位矩形，而不是快捷栏本身的矩形。快捷栏是玩家8×4格子的克隆体，因此它的矩形比可见的那一行高出好几行——用大范围来接收掉落物品是正确的，但用于发起拖拽就不对了，因为那样会让在快捷栏上方空白处的中键点击也能把它拾取起来。

每个槽位下方都标有对应的快捷键—— Alt+1, Alt+2 以此类推。文本是从实时 键盘快捷键，因此在F1中重新绑定某个槽位会重新标注它，且该标注永远不会与实际生效的按键脱节。标注是从槽位自身的堆叠数量文本克隆而来，因此自带《英灵神殿》的字体、描边和材质，其大小根据槽位高度而非固定数值推导——所以它会跟随 缩放 以及游戏运行时的任何UI缩放比例。 槽位键缩放 相对于那个轻推它。

这个进度条是原版玩家界面的副本 物品栏网格，因此它继承了 Valheim 的栏位美术、提示框、耐久条、手柄操作和拖拽视觉效果——以及原版的 更新界面 根据绑定的库存重建槽位，因此单行网格无需布局代码。它被挂载到画布根节点而非库存面板下，因此库存关闭时仍可留在屏幕上并接受点击。

---

美术管线

Blender 源文件、其 FBX 导出文件以及图标源文件位于 美术/构建的AssetBundle为 冈格尼尔之杖/资产/冈格尼尔, 嵌入到 DLL 中 作为 冈格尼尔之杖，因此该模组以单一文件形式发布，无需部署零散资源。资源包在独立的Unity项目中烘焙，该项目不属于本仓库；它包含两个资源，即 冈格尼尔外观 预制件和 冈格尼尔图标 精灵。

只有 视觉 来自资源包——物品本身仍是原版长矛的运行时克隆，因此《英灵神殿》自身的一切行为（碰撞体、攻击、动画、投掷）都保持原样运作，资源包中无需包含任何《英灵神殿》组件。这也意味着可以在不触及模组任何逻辑的情况下重新构建资源包。

水晶粒子已内置 代码 而不是预先制作进资源包里，原因有两个：它们的颜色必须跟随所选的法杖变化，而烘焙好的粒子系统做不到这一点；而且在这里构建意味着它们可以热重载，而不必每次微调都经历一轮 Blender → Unity → 资源包的往返流程。

---

前置条件

• 瓦尔德海姆已安装于以下路径中 目录.生成.属性
• 这 体验优化 r2modman 配置文件，包含 霜巨人 已安装（该版本引用了 约顿.dll 以及BepInEx的 0Harmony.dll 完全出自那个档案）
• .NET SDK 8 — 已安装于 %LOCALAPPDATA%\Microsoft\dotnet

如果其中任何路径不同，请复制 环境.道具.示例 到 环境.道具 并进行编辑。该文件已被 git 忽略，因此永远不会冲突。

建造

dotnet build GungnirStaff.sln -c Debug

每次构建都会复制 冈格尼尔之杖.dll + .pdb 进入 …\r2modmanPlus-local\Valheim\profiles\QoL\BepInEx\plugins\GungnirStaff\.

命令	效果
dotnet build	安装到 BepInEx/plugins/GungnirStaff/ （需要重启游戏）
dotnet build -p:HotReload=true	部署到 BepInEx/脚本/ — 脚本引擎实时重载它
dotnet build -p:OverwriteInstalled=true	将构建版本放到从Thunderstore安装的副本上
dotnet build -p:Deploy=false	仅构建，不复制

每种部署模式 删除其他位置中的副本。两个相同插件GUID的副本发生冲突时，哪个会生效并不可靠，因此构建过程直接杜绝了这种情况，而不是留给你去调试。

覆盖已安装 用于测试本地构建，而 已发布 模组是从Thunderstore安装的。r2modman会安装在以下位置 插件/<作者>-<模组>/，而这两条路径都不是另外两种模式所管理的，所以如果没有它，本地构建就只是同一 GUID 的第二份副本，会与已发布版本冲突。该路径通过通配符匹配而非假定，因此无论作者命名空间是什么都能找到安装位置，并且在找不到安装时会发出警告，而不是静默地什么都不做。r2modman 不会因此受影响——它只看到自己的文件——而从 Thunderstore 重新安装或更新该模组即可将其恢复。

请注意，这会部署你所构建的任意配置，因此默认情况下是 调试，其 网络兼容性 是 未执行添加 -取消发布 当你想测试的是运输行为时。

制作 每 生成热重载——包括 Rider 的生成解决方案 (Ctrl+F9)——设置 <HotReload>true</HotReload> 在你 环境.道具这正是开发过程中需要切换的设置。

如果 Valheim 或 Jötunn 的路径错误，构建会快速失败并显示可读的消息。

公开集会

BepInEx程序集公开化构建工具 在构建时重写所引用的游戏程序集，使私有成员可访问——这就是为什么 MessageHud.m_instance 和 本地玩家 编译。编译器会生成 忽略访问检查到 放入输出程序集，因此这在运行时也是合法的，并非取巧手段。

要宣传另一场集会，请添加 公开="true" 到其 <参考>.

热重载（无需重启游戏）

ScriptEngine r11.1 已安装于 BepInEx/plugins/ScriptEngine/ 并在以下位置配置 BepInEx/配置/com.bepis.bepinex.scriptengine.cfg 与：

• 启用文件系统监视器 = true — DLL更改后1.5秒自动重新加载
• 重新加载键 = F6 — 手动装填，作为备用方案
• 加载于启动 = 假 — 故意关闭：ScriptEngine 会忽略 [BepInDependency] 当它在启动时加载，模组可能会在Jötunn准备好之前就执行Awake。监视器则会在稍后加载它，此时Jötunn已经就绪。

所以循环是：设置 <热重载>true</热重载> 在……里 环境.道具，启动一次游戏，然后只需构建。约1.5秒后游戏会自动重新加载模组——无需按键，无需重启。因为 启动时加载 关闭时，启动后的第一次构建（或按一次 F6）会在该会话中加载模组。

插件.销毁时() 呼叫 _harmony.UnpatchSelf() 这样重新加载时就不会叠加重复补丁。你创建的其他任何东西（游戏对象、协程、事件订阅、UI）也必须在那里销毁，否则每次重新加载都会泄漏。

以下内容不会热重载： 仅在以下情况下运行一次的Jötunn注册 对象数据库/区域系统 初始化——自定义物品、碎片、预制体和配方。这些仍需要重新加载世界（主菜单→返回游戏）或重启游戏。游戏逻辑、Harmony补丁、UI、水晶效果和配置更改可以正常重新加载。

这个模组还更新吗？

存活状态行 准确说明了正在运行的是哪个版本：

冈格尼尔法杖 v0.1.0 | 调试版本 2026-08-29 14:10:57 | 已修补 8 个方法

存活.宣告() 同时在三个位置显示该行文字——BepInEx 控制台窗口、Valheim 游戏内控制台（F5）以及屏幕中央。

构建时间戳在编译时由 生成构建信息 MSBuild 目标，这样热重载后你一眼就能看出新的 DLL 是否真的生效了，而不用靠猜。

它刻意保持安静。已发布的模组不应在玩家屏幕上主动显示自己，因此这行文字只在被请求时才会显示：

当	哪里	备注
游戏开始 / 脚本引擎重新加载	仅BepInEx日志	一 日志信息 行，无 HUD，无游戏控制台
昆古尼尔 在F5控制台中	日志与控制台	同时输出伤害、机架和命中反馈状态
按键/状态键	日志 + 控制台 + 抬头显示	默认无绑定 — 绑定一个按键来使用它

状态键默认并未绑定：它只是一个诊断功能，已发布的模组没有理由为此占用所有人键盘上的一个按键。绑定后，它甚至可以在以下情况下正常工作： 已启用 = false 即使菜单打开时也是如此。

BepInEx 控制台窗口已在此配置文件中开启（BepInEx.cfg → [日志.控制台] 启用 = true）。

网络兼容性

在以下项中按生成配置设置 插件.cs，这样你就永远不用记得去翻它了：

建造	等级	效果
调试	未执行 / 无	加入任何服务器，包括你自己的，即使在开发中
释放	人人必备模组 / 次要	你支持哪对CP

人人都应拥有模组 正是这个意思—— 服务器 也需要它，不只是客户。这让 [启动配置] 多人游戏契约的属性部分：插件同时声明 瓦尔海姆.exe 和 瓦尔海姆服务器.exe，因为专用服务器运行的是后者，而该属性是 BepInEx 将插件加载到哪个进程的硬性筛选条件。仅有 瓦尔海姆.exe 声明过，专用服务器可能已安装这些文件却从未加载它们，Jötunn 会在握手时发现服务器端缺少该模组，而每个安装了它的玩家都将被拒之门外。

次要版本严格 比较大小，因此 1.0.0 和 1.0.1 可以一起玩，但 1.1.0 无法。对比的版本是 模组版本 在 Plugin.cs.

该模组在其他方面表现良好，无需界面运行。 更新 立即返回且没有本地玩家，因此所有UI、模型或水晶相关工作都不会在服务器上运行；伤害补丁仅针对 玩家.本地玩家，因此攻击客户端只进行一次命中判定，并将其作为命中效果的一部分同步复制；而美术资源包则完全跳过（GUI管理器.是否为无头模式()，因为服务器没有渲染器来绘制它。

有两件事值得提前了解，免得之后措手不及：

• 物品预制体是在本地玩家生成时注册的，而专用服务器上永远不会发生这种情况，因此服务器不会携带它。这是无害的： ZNetScene.CreateObject 对未知预制体返回空值 不要碰ZDO因此，掉落的冈格尼尔仍然会保留在世界上，并且仍然会在客户端之间复制——服务器只是不会在本地实例化它。
• 伤害和概率数值是普通的客户端配置，不与服务器同步。客户端编辑 闪电伤害 只影响自己的攻击判定。朋友之间无所谓；但如果开公共服务器，最好了解一下。

当模组完成后无需更改——直接构建即可 -释放 打包。

---

开发者工具

控制台

按F5打开控制台（需要 -console 在r2modman的启动参数中）。该命令本身并非作弊—— 空 和 恢复 是玩家在法杖面临风险时会求助的那两个，并将这些限制在 开发者命令 就反了。生成是单独守护的： 给 除非游戏启动时带有 控制台 和 开发者命令 已开启，因此正常通关无法召唤出冈格尼尔。

指令	效果
冈格尼尔状态	伤害、打击反馈、挂架内容与当前选择
冈格尼尔空了	将每个员工从架子上移到你的库存中—— 卸载前请先执行此操作
冈格尼尔回收	将因修复前掉落漏洞而滞留在世界中的冈格尼尔交还（仅限同一会话）
冈格尼尔法杖	列出模组检测为法杖的物品
冈格尼尔枪套	收起当前法杖
冈格尼尔发现	搜索对象数据库预制体名称
冈格尼尔给予[1-3]	在你的物品栏中放入一把冈尼尔——一个跳过配方的测试捷径。可选关卡生成时它已是升级状态，所以架子上会有4、6或8个槽位

脚本

tools/Dump-GameType.ps1 直接打印任意 Valheim 类型的真实字段和方法签名，原样输出 assembly_valheim.dll 来自塞西尔：

powershell -File tools/Dump-GameType.ps1 -Types InventoryGrid,Humanoid -Filter "Equip"

工具/Verify-Patches.ps1 检查构建后的 DLL 中每个 Harmony 补丁目标是否确实能在游戏程序集上解析——无需启动游戏即可捕获最常见的运行时故障：

powershell -File tools/Verify-Patches.ps1

调试

• 日志： …\profiles\QoL\BepInEx\LogOutput.log
• 使用以下命令启用游戏内控制台 控制台 在r2modman的启动参数中
• 详细日志记录 在配置中开启 ModConfig.Trace(...) 输出
• 可移植 PDB 与 DLL 一起部署，因此堆栈跟踪会带有行号

包装

一条命令即可生成可上传的压缩包，位于 dist/:

生成 GungnirStaff/GungnirStaff.csproj 的打包文件：dotnet build GungnirStaff/GungnirStaff.csproj -t:Package

dist/GungnirStaff-<version>.zip ├── manifest.json # 来自Thunderstore/ ├── icon.png # art/Gungnir staff.png，已重命名 ├── README.md # 本文件 ├── CHANGELOG.md # 在包页面上以独立标签页形式呈现 └── plugins/ └── GungnirStaff.dll # 发行版

CHANGELOG.md 在Thunderstore上有自己的标签页，并由r2modman显示，因此这是玩家在决定是否更新之前唯一会阅读的地方。在打包之前先编写发布条目：目标在没有该文件时拒绝构建，而版本发布时缺失的条目无法添加到已经发布的包中。

目标通过嵌套的MSBuild进行Release构建，而不是依赖常规的 建造，这会强制处理两件手动操作时容易出错的事：

• 配置已强制设为发布版。 插件.cs 开关 网络兼容性 取决于构建配置，因此调试包会附带多人握手功能 已禁用 — 这不需要其他玩家安装该模组。
• 部署 被迫关闭。 普通构建会复制到正在使用的 r2modman 配置文件中；打包过程绝不能悄悄把你正在游玩的 DLL 替换成不同配置的版本。

如果 csproj 会生成损坏的包，它宁可拒绝运行。 <版本> 以及宣言的 版本号 不同意——清单版本会在评估时从 JSON 中读取并比较——或者如果图标缺失。增加 <版本>, 模组版本 在……里 插件.cs 和 版本号 一起；前两个通过版本检查进行比较，并且 模组版本 是多人在客户端之间进行握手时比较的内容。

图标.png 必须正好是256×256，否则Thunderstore自己的验证器会拒绝上传。 艺术/冈格尼尔法杖.png 已经是了，目标在进入压缩包时会将其重命名。