Diagnostics

English | 中文

诊断追踪与重放

诊断系统解决一个问题：订单下下去行为不对，怎么把"当时到底发生了什么"变成可提交的证据。三件工具围绕一条"轨迹"（trace）工作：

1. 录制（trace）——游戏内对一次合成请求做全称记录：决策点、每次提取、样板展开、计划结果，落盘为带哈希链的文件；
2. 重放（replay）——用同一条轨迹重算一遍，对比计划是否一致（复现计算层问题）；
3. 模拟（simulate）——用忠实复刻 AE2UEL 合成 CPU 的离线集群跑一遍计划，判定会不会卡死（复现执行层问题，见CPU 模拟判定）。

设计原则：轨迹只由人工触发（玩家主动开启录制，普通游玩零开销零痕迹）；自动脱敏（名称在记录边界即替换为 token，映射表永不上传）；证据防篡改（事件哈希链 + 载荷摘要）。

游戏内指令

全部为服务端命令 /ae2vm trace …，原版客户端即可执行；所有回执只有执行者本人可见。

指令	谁能用	作用
/ae2vm trace record next	任何人	预备一次性录制：你的下一次下单会被完整记录（记一单即止）
/ae2vm trace record on / off	op	开/关全局录制窗口：窗口期内所有人的下单都记录（复现机器/库存维持器下单的问题时用）
/ae2vm trace list	任何人	只列出你自己的轨迹（玩家与 op 一致）；一行一条带三色状态，[下载]/[上传] 按钮可点击直接执行；追加页码翻页
/ae2vm trace list all	仅 op	列出本服所有人的轨迹（额外显示来源列）
/ae2vm trace show <id>	本人或 op	聊天栏输出某条轨迹的摘要
/ae2vm trace download <id>	本人或 op	下发轨迹到客户端（见下文存放位置；需客户端装本 mod）
/ae2vm trace upload <id>	本人或 op（受 traceUploadEnabled 开关）	上传 mclo.gs 出短链——无 mod 玩家拿证据的主通道；上传前已脱敏

典型用法：玩家发现订单异常 → record next → 手动重新下一单 → list 找到轨迹 → upload 拿短链发 issue。机器下单的问题由人类 record on 开窗复现。

取证报障的完整步骤见取证与报障。

轨迹文件在哪

• 轨迹统一存放于 aevm/traces/（gzip JSON：版本元数据 + 事件哈希链 + 内嵌子样板字节码 + 多样板选择归因（REPAIR_CHOICE））——客户端在 .minecraft/aevm/traces/，服务器在服务端目录的 aevm/traces/；
• token 映射表（vault）在同级的 aevm/vault.json，永不上传；
• 留存双上限惰性清理：traceRetentionCount（默认 20 条）+ traceRetentionMaxBytes（默认 100 MiB），超限删最旧。

重放入口

• 游戏外 CLI（推荐）：mod jar + 随 Release 附带的 replay-shim jar，两个文件即可重放并给出模拟判定——命令与退出码见CPU 模拟判定。
• 服务器内重放（规划中）：/ae2vm trace replay <id>，在当前服务器环境直接重算，无需任何外部装配。

配置项

配置	默认	说明
traceSessionEventCap	100000	单次录制会话的事件数上限（环形驱逐，超限丢最旧）
traceRetentionCount	20	轨迹文件留存条数
traceRetentionMaxBytes	104857600	轨迹留存总字节（100 MiB）
traceUploadEnabled	true	关闭后 upload 对所有人禁用
language	en_us	指令回执语言（en_us / zh_cn）
stallWatchdogTicks	0（关）	看门狗：连续 N tick CPU 指纹不变且 waitingFor 非空 → dump 该 CPU 的 NBT 现场到 aevm/（排查无法手动复现的时序型卡死时由服主显式开启）