v0.6.9 — 修净水器与水龙头残留杂质

修复: 净水器与水龙头残留杂质

UV 紫外线灯一直干净, 净水器与水龙头却总留一点点 —— 两条独立缺陷, 表象相同。根因靠读 ISIL 反编译定案 (dump/ascs/ 全是 throw null 空壳, 不可用)。

1. EmptyContainer 根本不清杂质

其 IL 全程没有出现过任何一个杂质 id 字面量, 只做 ModifyTag(容器 parts) 与 DisableTag("STRIP_TESTED_TAG") —— 它清的是容器里的**「水」(基液)**; 6 类杂质是各自独立的 part, 一个都不碰。

原净化补丁只有 EmptyContainer + AddPureWater(vol) 两步 → 基液换成了 100% 纯水, 杂质原样留着。而 UV 走 OnUVUsed → StripAllContaminants (逐类 RemoveContaminantFromContainer(minPercentage=0) 迭代到收敛), 根本不调 EmptyContainer —— 这正是两者表现不一致的原因。

2. AddWater 是「追加混合」而非替换

原水龙头补丁只把 grade 由 1 改成 0, 只保证新加的那一份是纯水; 容器原有杂质原封不动, 接水前残留多少仍是多少。

修复

补丁	改动
PatchPurifyToPure	补齐第三步: EmptyContainer + AddPureWater + StripAllContaminants
StripContaminantsOnly (新)	从 StripAllContaminants 抽出的「只剥离不补满」分支
PatchFaucetPure	Prefix 增加 GameItem __0, 改完 grade 后调 StripContaminantsOnly

水龙头处刻意用 StripContaminantsOnly 而非 StripAllContaminants —— 后者会先补满, 原生 AddWater 就无处可加了。三者现共用同一条剥离路径。

开关默认值调整

键	默认	说明
FaucetAlwaysPure	false (新改)	水龙头接出 100% 纯水

原版设计上水龙头只接得出高品质水 (grade=1), 改出纯水属于破例, 是否启用交给玩家在配置里决定; 净水器与紫外线灯是修正原生缺陷(残留杂质), 性质不同, 保持默认开启。

配置项与补丁逻辑本身不变, 仅默认值。

验证

• dotnet build -c Release: 三项目 0 警告 0 错误。
• DLL 内嵌符号校验: StripContaminantsOnly / StripAllContaminants / PatchFaucetPure / PatchPurifyToPure / FaucetWaterMarker 均在; AddPureWater / EmptyContainer / GetTotalVolume / GetFreeCapacity 未被误删。

资产

• ProgressMod.dll
• InventorySorter.dll
• NetworkUnlockMod.dll

需重启游戏才会加载新 DLL。

完整变更: v0.6.8...v0.6.9

---

自 v0.6.8 以来的其它变更

• 修库存检查器打不开 (c6661aa): NVIDIA 设计语言重构 d0e0f68 在 openCatalog 与 renderInstance 各加了一行 $('drawer').className = 'drawer';, 把 openDrawer() 刚加上的 show 类整个覆盖 ⇒ 页面变暗但抽屉不可见。图鉴「详情」不走 renderInstance 故一直正常, 解释了只有库存检查器中招。
• 读路径改快照 (487cef2): /api/mine 与 /api/inventory 原先让 HTTP 线程同步等主线程 5s, 主线程一忙则两请求同时超时; 改为非阻塞置位 + 快照读取 (RefreshSnapshots 主线程节流 120ms)。

v0.6.8 — 净化剥离到零 + 补满纯水

• 紫外线灯与净水器共用一条「剥离 + 补满」路径。
• 补满纯水：剥离后按容量补 AddPureWater（= AddWater grade 0，真 100% 纯水）。
  顺序关键 —— 容量按水的刻度算而 GetTotalVolume 计入杂质体积，先剥离再取余量，
  否则会按含杂质的体积补水而溢出容量。
• 剥离迭代到收敛（每轮用当前总量重算），单轮理论归零但实测有残余，迭代兜住。
• 多线程 accept（4 线程），修复单线程下串行化导致的并发请求排队。

新增开关（均默认开）

键	说明
PurifierFullPurify	海德拉净水器清除全部杂质
PurifyFillToFull	净化后用 100% 纯水补满容器
UvFullPurify	紫外线灯一并清除全部杂质
FilterBoost	滤嘴剥离量拉满、耐久成本降到 1

资产

文件	sha256
ProgressMod.dll	fc61f09b25ea17436ed13af1362bccd9dd7d00a462e47be7854928038ed563d9
InventorySorter.dll	9a720e34ce91a0e2be4ff55657f5ad8371d0650a955e380c81aa72df07bc826f
NetworkUnlockMod.dll	74912d92922c4a3457063b29e1c51a185adda0c434328a9b3105910d573052e9

后两者与 v0.6.7 逐字节相同（本版仅改 PlayerStore/ProgressMod.cs）。

纯度公式与根因来自 IL 反解与算术推导，未经实机验证；请实机确认净化结果。

v0.6.7 — 紫外线灯补全杂质清除 + 滤嘴强化

本次更新

紫外线灯现在能清除全部杂质

原版 WaterHelper.OnUVUsed 只把 microbe（微生物）归零，其余 5 类杂质
（physical_contaminant / chemical_contaminant / mineral / heavy_metal / organic_waste）
完全不处理。现在补一轮移除，照 MachinePurifier.PurifyContainer 的原生做法对
6 类杂质各调用一次 RemoveContaminantFromContainer。

滤嘴加强

滤嘴的过滤能力由 Liquid 数据表驱动：

• filterVolumeRemoved（每次剥离量）：多数杂质原为 1000 → 2000
• filterDurabilityUsage（每次耐久成本）：2 → 1
• 配合默认开启的「不消耗耐久」，滤嘴即自由过滤

开关

两个功能默认开启，可在 MelonPreferences 里关掉：

• FilterBoost — 滤嘴强化
• UvFullPurify — 紫外线灯全杂质清除

说明

• 刻意不修改 particleSize 与 FILTER_SIZE_TAG。HandleFilter 的判定是
  filterSize <= particleSize 才处理，滤嘴默认 FILTER_SIZE_TAG=22 只拦得住
  particleSize ≥ 22 的杂质；把该值调大反而会更弱，故保持原样。
• RemoveContaminantFromContainer 的收尾形态是
  max(0, max(min(c, floor), c - volumeToRemove))，floor = water × minPercentage / 100。
  传 minPercentage=0 时退化为 max(0, c - volumeToRemove)，因此传入
  GetTotalVolume(容器)（该值会遍历 Liquid.Liquids 累加全部 part，必 ≥ 任一杂质当前量）
  即可一次清空。

哈希

DLL	sha256
ProgressMod	92f8dd21bd70e5aa76ebe9b7079b34456a573b2b9743b2b070b187056c1d327b
InventorySorter	9a720e34ce91a0e2be4ff55657f5ad8371d0650a955e380c81aa72df07bc826f（同 v0.6.6，逐字节相同）
NetworkUnlockMod	74912d92922c4a3457063b29e1c51a185adda0c434328a9b3105910d573052e9（同 v0.6.6，逐字节相同）

本次仅 PlayerStore/ProgressMod.cs 一个源文件变更（+83/-1）；另两个模块源码未动，
故沿用 v0.6.6 的原始字节。

v0.6.6 — 收藏按钮点击区修复 + 死副本清理

v0.6.6

修复

• 收藏按钮点击区被标题吞掉: .card-name 用 padding-right:34px 给按钮让位, 但 padding 仍属元素自身盒子 —— h3 盒右边界压住按钮, 且因 .card>*{position:relative} + DOM 顺序在按钮之后而绘制在上, 吞掉其重叠区的点击。
  改 padding-right → margin-right (margin 才真缩盒子)。

实测 (Playwright elementFromPoint 25 点网格)

	修前	修后
首按钮命中率	9/25	25/25
与 h3 重叠	20×19 px	0
481 张卡最坏重叠面积	—	0 px²
端到端点击	—	aria-pressed false→true, localStorage 写入

清理

• 删除 InventorySorter/tscripts/xmod/items_browser.html (旧界面残留, 全仓零引用)。

产物

• ProgressMod.dll — 唯一变化项 (网页为内嵌资源)。
• InventorySorter.dll / NetworkUnlockMod.dll — 源码未变, 原样重发。
  (.NET 构建不可字节重现, 故沿用上一版原始字节, 保证内容确实一致。)

v0.6.5 — 网页端死代码清理 + 回归设计语言 + 触摸端 hover 守卫

改动

本次仅动网页端（docs/items_browser.html、docs/items_data_full.js），无 C# 源码变更。但网页三个文件是内嵌资源（<EmbeddedResource> + LogicalName 前缀 web.），由 TryRouteWeb 从 GetManifestResourceStream 提供、本地 http://localhost:26880/ 自服务，故 ProgressMod.dll 字节已变。InventorySorter.dll 与 NetworkUnlockMod.dll 与 v0.6.4 逐字节相同（sha256 一致）。

1. 死代码清理（4 条，均有 grep / ast-grep 证据）

规则	判据
.card:focus-visible	card 渲染为 <article role="group">；全文件 tabindex 出现 0 次、<button class="card" 0 次 ⇒ 永不匹配
.btn:disabled	全文件 disabled 仅此 1 处（它自己的定义），JS 从不置 disabled
.btn.ok / .btn.bad	无任何赋值

注意 .toast.ok / .toast.bad（L304/L305）是活代码，未误删；nav-item.active、dot.on、dot.off、fav.on 经 grep 证明均在 classList.toggle / className 赋值中使用。

2. 回归设计语言（docs/nvdesign.md）

• 删自造色：.btn:hover{background:#8ad100} —— #8ad100 不在 nvdesign 任何 token 中，且比 :active 的 primary-dark 更亮 ⇒ 按压反馈方向反了。改回 var(--primary-dark)（#5a8d00）。
• 消除强调色稀释：原先每张卡片 3 个绿元素（生成 / 生成十个 / 详情），其中两个同权重 2px outline 抢焦点。按文档 L169 的 button-ghost-link 把「详情」降级为新 .btn.link（绿字、无边框）⇒ 绿边框由 1.94 → 0.98 / 卡，回到文档 L276 的 primary + outline 一对。

3. 缺陷修复

• .card{cursor:pointer} 是假承诺：卡片无 click handler，实测点击卡片标题抽屉不打开、无任何响应（先前删掉整卡点击后的残留），鼠标指针在骗用户 ⇒ 删除。删除后按钮仍靠全局 button{cursor:pointer} 保留手型。
• --ash 对比度不达标：#6e6e6e 实测 4.12（纯黑）/ 3.81（surface）全底色低于 AA 正文 4.5。抬到 #8a8a8a（5.63）。影响 placeholder 与 kbd 两处；此前 L187 已因同一原因修过 .card-desc:empty。
• 字面标签泄漏：items_data_full.js 中 alarm_module_transmitter 的描述含 <b>治安部</b>，经 esc() 渲染后用户看到裸标签。移除标签并同步 bump ?v=20260921 → 20260923（不 bump 则旧缓存用户看不到修复）。

4. 触摸端 hover 粘滞（@media (hover:hover)）

L356 注释自称「桌面工具, 只服务鼠标」，但 14 条 :hover 规则全部裸放，全文件无 hover:hover / pointer:fine / any-hover 守卫 —— 名实不符。触摸设备无真悬停，移动端浏览器 tap 后会「粘住」:hover（按钮/卡片停在悬停态），并与 :focus-visible 同时命中成双重高亮。整段包进 @media (hover:hover){}。

选 (hover:hover) 而非 (any-hover:hover)：后者在触屏笔记本上仍为 true，挡不住触摸粘滞。

验证

项	前	后
卡片高度	232px × 1 种	232px × 1 种（未动刻度）
字面 <b> 卡片	1	0
每卡绿边框	1.94	0.98
.card cursor	pointer	auto
--ash	#6e6e6e	#8a8a8a
img/svg/canvas/gradient	0	0（设计约束守住）

• hover 守卫双向实测：桌面 (hover:hover)=true、14 条规则仍在媒体块内生效；390×844 hasTouch 下 (hover:hover)=false / (pointer:coarse)=true，块被正确跳过，卡片边框保持 rgb(94,94,94)。CSSOM 顶层 145 条规则、大括号配平，prefers-reduced-motion 与末端规则完好。
• 三个 csproj dotnet build -c Release 均 0 警告 0 错误。
• DLL 二进制标记确认内嵌资源已更新：8ad100=0、btn:disabled=0、ash:#8a8a8a / btn.link / button-ghost-link / hover:hover 均在。

未做：游戏侧运行时测试不在本次范围；游戏内生成行为未改动。

v0.6.4 — 生成链路修复 + 主线程队列背压

改动

1. 生成链路回归云端行为（修「连上了却生成不了」）

v0.6.3 引入的本地自服务暴露出一个我自造的缺陷：我把 /api/mine 当成了生成的前置门禁，而 /api/mine 走主线程队列。/api/spawn 本身只在 HTTP 线程入队、由主线程稍后消费，两者无依赖关系 —— 这个门禁会挡掉本来可用的生成。

• 移除 4 处 if (!(await checkServer())) 门禁，checkServer 只探 /api/health
• 移除「生成中」中间态与 waitSpawned 轮询；spawnItem 不再置灰按钮或改文案
• 补上根因：Application.runInBackground = true —— 游戏失焦时主线程不跑 OnUpdate，队列永不消费，表现为「连上了却生成不了」

2. 连续生成

• 生成按钮保持可点，不再禁用、不再改文字，可连续点击十个

3. 逐件独立生成（不在物品格上显示数字）

SpawnItem 原先用 SetAmount 设数量，物品格上会显示数字。改为循环 count 次创建互相独立的物品（不堆叠）：

for (int i = 0; i < count; i++) {
    if (!TryCreateSpawnItem(id, out GameItem item)) break;
    if (!TryAcceptIntoMainInventory((GameInventory)inv, item, id)) break;
    if (first == null) first = item;
    done++;
}

部分成功时按实际 done 记录，不谎报数量。

4. 代码质量：消除重复键表

ResolveNamedTableId 原用两个 switch 各写 11 条 arm，把同一份「键集合」知识存了两处，加表必须同步改两个 switch。收敛为单个 Dictionary<string, Func<string>>，净 −18 行。

补 null 守卫：Dictionary.TryGetValue(null) 抛 ArgumentNullException，而旧 switch 对 null 走 default 返回 "" —— 这是失败模式改变而非等价重构，故显式 if (tableKey == null) return "";。差分测试 180 组 / 0 差异（覆盖 null、未知键、空值、const 抛异常四类边界）。

5. 主线程作业队列加背压（唯一够格称性能问题的项）

OnUpdate 的 while (PendingJobs.TryDequeue(...)) 无单帧上限 —— 积压时一帧跑完整队列导致卡帧。改为队列 ≥ 32 时立即拒绝：RunOnMainThread 增 overloaded 出参，过载回 503，与超时（500/500/400）区分。前端无需改动（apiFetch 已把 ok:false 渲染成 toast）。

用 PendingJobs.Count 而非自维护计数器，避免「忘记递减 ⇒ 永久 503」的泄漏面；过载分支在 new MainThreadJob 之前 return，不会走到 finally 去 Dispose 尚未存在的句柄。

顺带收窄 PlaceInto 参数：cachedRects/selfSupport 带默认值却排在 out 之后，改必填、out 归末，3 个调用点同步。

验证

• 三个 csproj dotnet build -c Release 均 0 警告 0 错误
• 内嵌网页资源与 docs/ 源文件逐字节比对 3/3 IDENTICAL（132349 / 232520 / 14365 B）
• 已删的 .dot.warn 与 .nav-item .swatch 确认不存在于 DLL 内
• 差分测试证明 tableKey 重构等价（180 组 / 0 差异）
• 静态检查：三只读路由全部接线、503 分支 3 处、timeoutMs 默认参数残留 0、/api/health 不走队列

资产

文件	说明
ProgressMod.dll	452096 B — 含内嵌网页；生成链路修复主体
InventorySorter.dll	57856 B — 参数收窄
NetworkUnlockMod.dll	8704 B

未做

• 真机验证：无运行时实测数据。背压阈值 32 为估算值（依据是单帧处理 32 个纯读作业远低于 5s 超时窗口），未经实测。
• PendingSpawns / PendingItemOps 是同形状的无界队列，故意未加上限 —— 它们是写队列，过载时拒绝会让「连续生成」的点击静默丢失（前端已弹「已生成」而实际没生成），比卡帧更糟。
• Core.cs 的长方法与循环内 Contains 仅报告，未改动。

日志看 [Spawn] 开头的行。

v0.6.3 — 网页本地自服务 + 卡片尺度回到 v0.6.1

改动

1. 本地启动自动弹（替代云端 URL）

• 三个网页资源（items_browser.html / items_data_full.js / tag_zh.js）经 csproj EmbeddedResource 内嵌进 ProgressMod.dll
• 新增 TryRouteWeb：/ 等 5 条路由从 GetManifestResourceStream 直接发出；favicon 返 204
• 自动打开由云端 high-cla.github.io 改为 http://localhost:26880/ —— 页面与 API 同源，离线可用
• 云端 Pages 保留（不开游戏时查阅图鉴用）

2. 卡片尺度回到 v0.6.1

用户指定「没有移动端适配之前的版本」。移动端适配与尺寸放大是同一次提交（d0e0f68）引入的。

• 列宽 248→268px、卡名 15px/700→14.5px/600、英文名/ID 11→12px、按钮字号 13→11px、星标 top/right 9px
• .card-desc 用 47px 而非 v0.6.1 的 38px —— 后者未计入 padding 与 border（box-sizing:border-box），内容区仅 29px 放不下两行，第二行会被切一半，是 v0.6.1 的遗留缺陷

验证

• Release 构建 0 警告 0 错误
• 反射抽取内嵌资源与 docs/ 源文件逐字节比对 3/3 IDENTICAL
• 独立 HttpListener 实测 5 条路由全 200，未知路径 404
• 浏览器实测：481 卡、数据 481 项、card-name 14.5px/600、btn 30px/11px、fav 26px、描述截断 0、卡片溢出 0、零横向溢出
• 对比度最差 6.08（AA 需 4.5）

资产

文件	说明
ProgressMod.dll	452608 B — 含内嵌网页（较上版 +382KB）
InventorySorter.dll	57856 B
NetworkUnlockMod.dll	8704 B

未做

• 真机验证：需启动游戏确认自动弹出与生成链路。日志看 [Spawn] 开头的行。

v0.5.6 — 网页端重构 + NetworkUnlockMod 补丁修复

v0.5.6

网页端重构 (docs/items_browser.html)

设计令牌：39 个硬编码色值 / 144 处颜色字面量收敛为 :root 令牌（唯一处定义）；新增 27 个类别身份色 --c-<category>；清除 8 处内联 style=；补 prefers-reduced-motion。

可访问性（WCAG AA，浏览器实测计算样式）：

• --fg-para #7a8290 → #8f95a1（卡片上 4.21 → 5.42）
• --fg-faint #6a7280 → #9096a0（最低 3.16 → 4.55）
• 分类 active 标签改用 color-mix(类别色 88%, #fff)，29 个类别全部 ≥4.5（最低 4.53），此前 12/28 不达标
• 全站 :focus-visible 焦点环；卡片/库存行 role=button tabindex=0（Enter/Space）；toast role=status aria-live=polite；aria-pressed；Escape 关闭详情

健壮性：新增 apiFetch(path, ms) 统一入口（AbortController 超时、非 JSON 容错），收敛 8 处重复 fetch 样板；esc() 补引号转义；搜索 120ms 防抖；toast clearTimeout 消除竞态；轮询 document.hidden 门控。

修真实 UX 缺陷（假成功）：/api/health 只证明 HTTP 线程存活、不触主线程，而 OnUpdate 主线程在窗口失焦/未进存档时不排空 —— 旧版据此谎报「已连接」，/api/spawn 只入队即返回 200 却报「已生成」。现增加二级探针 /api/mine 判定主线程可达（失焦显示黄点「主线程未响应」），并在生成后轮询确认 token 落地才报成功，超时明确提示「已入队但未见产物」。后端未改动。

零回归：481 卡 / 0 重复 stableId / 0 模板泄漏 / 无横向溢出；头部过期计数（写 429，实际 481）改为运行时写入。

NetworkUnlockMod 修复

• 补 [assembly: HarmonyDontPatchAll] —— MelonLoader 默认自动 PatchAll，与原显式 PatchAll 双路径叠加导致 Prefix 执行两遍
• OnPreferencesSaved 幂等化 —— 该事件为全局订阅，启动期被误触发 9 次重建 HashSet 并打日志
• 配置分隔符补 \t —— 从表格粘贴的 id1\tid2 原先被当作单个 id，静默不解锁

产物

文件	大小	配置
ProgressMod.dll	70656 B	Release
InventorySorter.dll	57856 B	Release
NetworkUnlockMod.dll	8704 B	Release

说明

• 三个 DLL 均以 dotnet build -c Release 构建，0 警告 0 错误；ilspycmd 核验为 Release 配置（Debuggable 为最小 IgnoreSymbolStoreSequencePoints）。强制 -t:Rebuild 两次字节相同，构建确定性成立。
• 与 v0.5.5 资产哈希不同（尺寸相同、源码零差异）：定位为构建环境漂移（.NET SDK / 游戏侧引用程序集更新）；嵌入 PDB 路径一致，逐字节差异仅 149/70656 B 且集中于元数据区。今日构建为权威产物。

v0.5.5

修复

提交	内容
3c68bfd	ProgressMod: SpawnedItems 只增不减导致「我的生成」幽灵条目（删除/消耗后仍列在网页，点「完整检查器」必 400）
d2df819	ProgressMod: HTTP 监听循环退出 + 超时作业弃用
43b4e93	ProgressMod: HTTP 路由跨线程 native 访问与 SpawnedItems 竞态
798edfa	InventorySorter: 消除死常量 NativeWindowId（声明未用，字面量硬编码于 6 处）
a991015	docs: 物品列表对齐 mod/item_catalog.json 权威源，429 → 451 项
b78dd7d	README: 同步物品计数与生成逻辑片段

产物

Release 构建（-c Release），0 警告 0 错误。

文件	大小
ProgressMod.dll	70656 B
InventorySorter.dll	57856 B
NetworkUnlockMod.dll	8704 B

配置核验：三者均为 DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints（Release 最小模式），非 Debug 的 Default | DisableOptimizations | EnableEditAndContinue。

上游对齐

• 容器类板条箱（evidence_box / med_box / sec_box / service_box / eng_box）补 native 兜底，对齐 ProbablyStolenItemManager 0.4.7 的 TryCreateNativeLootCrate：这些 id 只在 ContainerItemDirectory 惰性注册，不在静态物品表，ItemSpawner.Spawn 必失败。
• 物品目录以 mod/item_catalog.json（441 项）为准，网页数据源合并至 451 项。

未做

实机验证未执行 —— 需启动游戏后确认：(1) 自动排序是否触发；(2) 日志是否出现 [InvSorter] native refresh failed；(3) 生成容器类板条箱是否成功进包；(4) 删除物品后网页「我的生成」条目是否消失。

v0.5.4 — 容器类板条箱生成修复 + 发布配置纠正

v0.5.4 — 容器类板条箱生成修复 + 发布配置纠正

修复

• 容器类板条箱无法生成（PlayerStore/ProgressMod.cs）：evidence_box / med_box / sec_box / service_box / eng_box 在 ContainerItemDirectory.InitDirectory 中以惰性 Func<GameItem> 工厂注册，静态物品表查不到，故 ItemSpawner.Spawn 必然拒绝、生成静默失败。现补 TrySpawnNativeLootCrate 直调 native PreBuiltItemHelper.LootCrate* 工厂（已确证存在于本机 Assembly-CSharp.dll）。此缺口源自本端口基于 ProbablyStolenItemManager v0.4.3，而 v0.4.7 新增了 TryCreateNativeLootCrate（ItemManager.cs:3681）。
• 清理死代码：OnMachineProgressPatch.Prefix 中 int cur = ... 声明后从未使用（Debug 下会多一次无谓 IL2CPP interop 调用）。

发布配置纠正

v0.5.1–v0.5.3 的全部 release 资产均为默认 Debug 构建 —— 反编译证实带 AssemblyConfiguration("Debug") 与 DebuggableAttribute(DisableOptimizations | EnableEditAndContinue)。源码逻辑等价，但产物未优化、体积偏大、并会掩盖死码。本版起改用 -c Release，并同步修正 README 中过期的 AutoCommit 说明。

体积对照（Debug → Release）：ProgressMod 73216 → 69120（含本次新增代码；同源 Release 基线 68608）；InventorySorter 64512 → 57856；NetworkUnlockMod 8704 → 8704。

验证

• 三个项目 dotnet build -c Release：0 警告 0 错误。
• 反编译核验：AssemblyConfiguration("Release")、LootCrate* 符号齐备。
• 注意：本次修复未做实机核验，实机表现以游戏内为准。