|
|
35534b1564
|
feat: get_block_info —— 方块信息查询（Java 侧回答，Python 只路由）
新增 cmd=blockinfo（两代后端编译通过、实测）：
返回 block 名（含 mod 方块）、stateId、属性、isAir/isSolid、
光照/硬度、贴图缺失的程序化判据、是否来自 mod。
★ 修掉一个真实缺陷（附录 D 的语义区分落到了实处）：
未加载区块原先返回 void_air（known=true），实测发现两个 API 都不可用：
- ClientLevel.hasChunk() 反编译实测**恒返回 true**
- ChunkSource.hasChunk() 走 getChunk(...,false)，而 ClientChunkCache
覆写后在该参数下返回 emptyChunk（占位，非 null）⇒ 也恒 true
正解：getChunk(..., requireChunk=**false**) 判 null
（反编译：return requireChunk ? emptyChunk : null;）
⇒ 现在未加载明确回 known=false + reason=chunk_not_loaded
实测（1.20.1）：
草地 → minecraft:grass_block props={'snowy':'false'} missing=False
原木 → minecraft:oak_log props={'axis':'y'}
空气 → minecraft:air
远处 → known=false reason=chunk_not_loaded ← 与空气区分
实测（1.21.1 + mod）：
mts:mtsofficialpack.fancydirt_block mod=True tex=mtsofficialpack:block/fancydirt
createbigcannons:steel_block mod=True tex=createbigcannons:block/steel_block
⇒ mod 方块同样能查到正确贴图名与 fromMod 标记
顺带修 gen_1_21 两处世代差异（ChunkStatus 换包、bridge 编译顺序）。
测试：69 项全绿（新增 test_get_block_info 6 条判据）
|
2026-09-26 00:24:29 +08:00 |
|
|
|
16f2e04fff
|
架构重构：差异全部下移到 Java，Python 只做路由
用户口径：差异放在 Java 层，Python 相当于路由。
下移到 Java（新增 cmd=setblocks）：
Python 只发 RLE（[[stateId,count],...]），Java 用官方 API 完成
调色板组装 / 位打包 / 官方序列化 / 入 cache / 渲染。
★ 意外收益：走 ClientboundLevelChunkPacketData(chunk).getReadBuffer()
+ replaceWithPacketData(...) 这条官方路径，两代签名完全一致
⇒ 原先的 Storage.chunks 反射注入**整段删掉**。
新增 cmd=capacity：世界尺寸（sectionsCount/minSection/defaultBiome）
由运行时回答，Python 不再硬编码 24/-4（1.16 时代是 16/0）。
Python 侧删除（防回归，见 test_import_surface）：
render_bridge.py（旧桥，无世代概念）
render._pack/_long_array/_encode_paletted/_encode_chunk/_varint
anvil.encode_block_section/encode_chunk_payload/save_chunk_to_payload
合计 454→374 行（render.py）、300→177 行（anvil.py）
保留在 Python（都是「不随版本变」的知识）：
RLE 压缩（rle_encode/rle_decode，具名可测）
存档读取（region/NBT）
方块名→id 的路由（查询在 Java）
NDJSON 协议
测试：62 项单元 + 6 项渲染联测全绿
新测试反映新架构：RLE 边界、运行时容量、世代分派、新路径渲染
test_anvil 里原有 8 项协议位打包测试已删（那已下移到 Java，
由两代后端各自的编译验证覆盖）
新增 scaffold/ARCHITECTURE.md（分层原则 + 加新世代步骤 + 防回归清单）
|
2026-09-25 19:21:45 +08:00 |
|
|
|
253146cffe
|
gen_1_21 实测启动成功 + provision 工具
决定性验证：gen_1_21 后端在 1.21.1 上收到 {"event":"ready"}
⇒ 世代分派架构成立：同一套 Python 层，两个独立编译的 Java 后端
运行时发现第 12 处世代差异（编译期看不出）：
1.20.x registryAccess 是可变 LayeredRegistryAccess → 事后反射替换
1.21.x registryAccess 是 final RegistryAccess$Frozen → 反射抛
"Can not set final field"
处理：gen_1_21 改为先载注册表 → 经 CommonListenerCookie.receivedRegistries
传入 → 再构造 listener。比 1.20 的反射做法更干净。
新增 mcfold/provision.py（从官方 manifest 装任意版本，版本无关）：
- 跳过音频资源：1.21.1 实测 3911 条里跳过 3744 条
- natives 两种形态都认（1.21 起是独立库条目，非 classifiers）
- 实测 1.21.1：274 文件 / 200MB / 32s / 0 失败
|
2026-09-25 18:35:28 +08:00 |
|
|
|
8c7d5b9d38
|
世代分派体系：Python 层 switch + 各世代独立编译的 Java 后端
用户定向：在 python 层写 switch，调用不同 java 后端（而非一个文件里 switch）。
新增：
mcfold/backends/{__init__,base,gen_1_20,gen_1_21}.py 后端体系与分派
scaffold/java/gen_1_20/ 对 1.20.x client jar 编译
scaffold/java/gen_1_21/ 对 1.21.1 client jar 编译（✅ 实测编译通过）
scaffold/java/VERSION-DIFFS.md 实测差异全表
判据：DeltaTracker 类是否存在（1.21 引入，正是 render 签名变化的根源）
⇒ 比硬编码版本号稳
实测差异共 11 处（21 个检查点里 13 个跨世代完全一致）：
setLevel / GameRenderer.render / countRendered* / createPackRepository /
ResourceLocation 构造 / enableDataFixerOptimizations(移除) / User 构造 /
ChunkStatus 包路径 / ClientPacketListener 构造(参数个数语义都变) /
loadEffect(变 private)
为什么必须分后端：DeltaTracker 在 1.20.x jar 中不存在，
两代调用无法共存于一份源码（实测编译报 cannot find symbol）。
1.21.1 反混淆已验证（29MB named jar，DeltaTracker 3 处）
|
2026-09-25 18:21:08 +08:00 |
|
