|
|
d2b4c5029d
|
M4：事件层（可按需排空的日志 + 游标）+ 16 项判据
新增 mcfold/events.py：EventLog（环形缓冲 + seq + 游标）
- 不做回调式推送：LLM 是回合制的，回调会让事件在两次观察之间静默丢失
- drain(limit) 只取本轮、剩余留待下次（不丢）
- 细分层（block_changed❌y:z）独立可查，不污染粗粒度流
- render_events() 输出紧凑文本行，省 token
session 接线：block_change / multi_block_change / chat / damage /
entity spawn·move·destroy / held_item_slot，并加 chat()/command() 发送
修的真 bug：
- dropped 恒 0：deque(maxlen=) 丢元素无声 ⇒ 改手动计数（事件丢了必须说）
- 事件键 to_state_id 与渲染器的 to 不一致 ⇒ 显示 None，改为解出方块名；
from 区分「未加载/界外」而非裸 None
- run_tests.sh 只数 ✓ 不数 ★ ⇒ 判据少报（98 修正为 110）
实测：/setblock 后事件正确报 grass_block→stone→air，与状态层一致
判据：110 项全通过；4 项变异全部被抓
|
2026-09-26 12:27:28 +08:00 |
|
|
|
40b2e1d60f
|
M3：状态层（服务端真状态）+ 包流灌入 + 14 项判据
新增：
- mcfold/state.py WorldState / WorldGeometry / PlayerView / Entity
- mcfold/session.py StateSession：connect() 走完 login→configuration→play，
pump() 把包落进状态，on() 留 M4 事件口
修的真 bug：
- unload_chunk 协议顺序是 chunkZ 在前、chunkX 在后；按 x 先读会坐标互换，
卸载永不命中 ⇒ 区块只增不减（状态撒谎）
设计立场（防越界）：
- 只陈述观察、不做决策（nearby_blocks 给统计不给「该挖哪个」）
- 未知 ≠ 没看见：认不出的 state id 显式记账，绝不静默映射成别的方块
- 超范围拒绝并说明，不静默缩小
- 几何从服务端 dimension_type 吸收，不写死 24/384
实测：11 注册表 / 9 区块 / 生命 20 饥饿 20 / 列剖面 bedrock→dirt→grass_block
判据：91 项全通过；4 项变异全部被抓（含「变异空操作 ⇒ 假绿」的核对）
|
2026-09-26 12:21:18 +08:00 |
|
|
|
547f4beb7e
|
M1+M2：1.21.1 构建跑通 + 协议客户端进 play 阶段
M1（构建）：
- build.sh 编译 CP 加入 $OUT/fabric/*.jar，解决 net.fabricmc.* 找不到
- gen_1_21 内联 Sodium 通知改为委托共用 RenderCompat，补 reportRenderCompat
- 1.21.1 全量七步构建产物齐备（classes-intermediary.jar / names*.json / srg / inheritance.map）
M2（协议）：
- login_start 按协议数据发 UUID（1.21 必填；1.20 可选）
- login_acknowledged / serverbound 包 id 改为查表，不再写死 0x00
- send() 实现压缩帧格式（varint(dataLen)+数据，小包不压）
- configuration 双向协商：发 settings、回 select_known_packs、拒 resource_pack
- protodef 补 bitflags / entityMetadataLoop / count(ctx引用) / compareTo 路径表达式
- NBT 读取器由占位符改为真实现（anonymousNbt 支撑 registry_data）
- 坏包容错：长度前缀是帧层权威，解不开整包丢弃并布告，不断流
实测：login→configuration(11 注册表)→play，位置 (5.5,-60.0,-0.5)，map_chunk×9
判据：protodef 6→13 项（含线上真实 entity_metadata 字节回归）；全量 77 项通过
|
2026-09-26 12:15:48 +08:00 |
|
|
|
b21b869e09
|
plan.md：M0 完成（空白测试服已起并可协议级探活）
|
2026-09-26 11:12:52 +08:00 |
|
|
|
c80b06552f
|
plan.md：立起最顶层目的 —— 给 agent 一副能在 MC 里感知与行动的工具包
用户定调：插件目的是「让 agent 可以借助我们提供的工具包去玩我的世界」。
推论三条（改变工程重心）：
① API 形状要照 LLM 用法设计，不是照程序员用法
（mineflayer 是给写 bot 的人用的库；我们面向 LLM 直接调用）
② 感知 + 行动缺一不可 ⇒ 状态/事件/操作三层是正式骨架
③ 渲染是工具之一，不是全部 —— 之前把它当主线是重心错了
新增：
§1c 空白测试服（不用现役服；现役 world 15G + mods 64，测不出边界）
§1d 面向 LLM 的 API 形状（自省 / 可读返回 / 限量 / 失败要说清为什么）
§6 里程碑重排：M0 测试服 → M1 修构建 → M2 协议客户端（真正的门槛）
细渲染降到 M8（已能跑，只是接不上服务端真数据）
拍照降为 M9（验证工具包的用例，不是工具包本身）
已核实的关键事实（写入 plan）：
· mineflayer 自述 'create minecraft bots with a stable, high level API'
41 个 plugins 全是动作与感知，grep 行为树/目标选择 = 0 命中
⇒ 它是给 bot 开发者的库；决策在它之外，那是我们该留给 agent 的部分
|
2026-09-26 10:50:21 +08:00 |
|
|
|
7c7297ebad
|
plan.md：按用户口径重写 —— 粗/细渲染分工、抽象模型（参考 mineflayer）、机位降为用例
|
2026-09-26 10:32:22 +08:00 |
|
|
|
c5560765a3
|
加 plan.md：工程计划（含 ass 粗渲染与聊天拍照的新方向）
|
2026-09-26 10:25:11 +08:00 |
|
