|
|
6827f4d0e1
|
实测 Fabric 客户端可启动 + 加载器后端设计文档
用户判断：mod 支持分 fabric/forge，且不同版本还有差异 ⇒ 各有独立后端。
实测支持此结论，且差异比方法签名更深一层。
实测成功（关键）：
Fabric Loader 0.19.5 完整启动 1.20.1 客户端
'Loading Minecraft 1.20.1 with Fabric Loader 0.19.5' + Mixin 子系统 + 12 个资源图集
★ 必须剔除 1.20.1 自带的 asm 9.2/9.6，改用 Fabric 的 9.10.1
（否则 Knot.<clinit> 抛 duplicate ASM classes）
架构结论：后端身份是 (加载器, API 世代) 二元组
因为 Fabric/Forge 下**我们不拥有启动流程**（Loader 起游戏+跑主循环），
与我们「不跑主循环+手动喂数据」的模型根本冲突。
两条可行路线已写入 scaffold/LOADERS.md（A: 作为 mod 被加载；
B: 只借 Fabric 的注册表与资源包，保留我们的渲染循环）——均待实测。
已实现（零加载器，两个 vanilla 后端编译通过、待实测）：
cmd=mods：Java 侧自己扫 jar/注册占位方块/挂资源包
覆盖：外观 ✅ state id ✅ 变体 ⚠️ 行为 ❌ Iris ❌
|
2026-09-25 19:55:13 +08:00 |
|
|
|
d0fb5517a0
|
修复 gen_1_21 渲染：1.21 的 gameLoadFinished 门禁（第 13 处世代差异）
症状：gen_1_21 启动成功、数据注入成功（loadedChunks=49），
但 chunksRendered=0、画面停在 Mojang 加载屏（distinctColors≈199）。
根因（1.21 GameRenderer.render 内部，编译期看不出）：
boolean ok = minecraft.isGameLoadFinished();
if (ok && renderLevel && level != null) renderLevel(...);
该标志只在 reloadResourcePacks 回调（onResourceLoadFinished）里置 true。
我们不跑异步 reload（会死锁）⇒ 恒 false ⇒ 世界永不渲染。
1.20.x 无此门禁 ⇒ gen_1_20 从未受影响。
修法：gen_1_21 的 McfoldBridge 加 markGameLoadFinished（反射置位），
在 boot 里 shader 编译后调用 —— 差异留在 Java 侧。
★ 教训：这类差异不崩不报错，只是画面不对 ⇒ 判据必须用
chunksRendered/distinctColors，不能只看进程活着。
顺带修：tick 异常不再静默吞掉（try{tick()}catch(ignore){} → 打印第一帧异常）
新增诊断字段：screenNow/overlayNow/levelNow/playerNow/noRender
实测：gen_1_21 现在 chunksRendered=25、has_world_content=True
（草地/天空/太阳/HUD 正常）
|
2026-09-25 19:45:24 +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 |
|
|
|
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 |
|
