蓝图字符串这东西第一次拆开看的人多半会愣一下一长串看起来像乱码的字符粘进游戏却能原封不动还原出一整片工厂。做这个编辑器的起因很朴素——我在整理几套跨存档复用的产线时发现手工改蓝图实在太低效一个二百实体的小模块要换配方得在游戏里一个个点想把红线和绿线整体对调只能全拆了重连更别提把同一套逻辑套到十几种不同产物上重复劳动能把人磨到没脾气。后来索性把这串字符扒开写了个能解码、能可视化、能批量改、还能顺手调电路的编辑器。这篇就把整个过程中的结构拆解、实现取舍和踩过的坑摊开讲一遍适合两类人看一类是想自己动手写蓝图处理脚本的一类是手头有一堆蓝图想批量改造但不知道从哪下手的。代码给的是 Python 和 JavaScript思路跟语言无关看懂结构你自己换什么写都行。1. 蓝图字符串的真实结构先搞清楚手里这串东西是什么很多人以为蓝图字符串是某种加密结果其实它一点都不神秘就是一个压缩过的 JSON。之所以看起来像乱码是因为中间隔了两层封装。把这两层剥掉剩下的东西结构清晰、字段规整甚至可以直接读。理解这一点是后面所有工作的前提——只要你能拿到那个 JSON可视化、批量改、调电路全都是对普通字典做增删改查难度立刻从玄学降到写脚本。1.1 三层封装版本字节、Base64、zlib一份从游戏里导出的蓝图字符串结构是这样的第一个字符是格式版本标识现代版本导出的一律是字符0ASCII 48它不参与后面的编码剩下的部分先做 Base64 解码得到一段二进制这段二进制是标准的 zlib 压缩流解压后就是 UTF-8 的 JSON 文本。三层一层套一层没有校验和没有加密也没有私有算法。这里有个容易被忽略的细节游戏导出时可以选择是否换行导出的字符串经常带\n直接丢给 Base64 解码器会报binascii.Error: Invalid base64-encoded string。我第一版脚本就是栽在这上面对着一段明明正确的字符串怀疑人生了半小时。后来在解码前统一做一次.join(text.split())就没事了。另外有些第三方工具在传输过程中会把和/换成 URL 安全的-和_顺手做一次替换更保险末尾的补齐也别省长度不是 4 的倍数时解码器一样会翻脸。至于格式版本字节理论上它标识了蓝图格式的演进但这么多年下来一直是0实际意义不大。真正需要关心版本的地方在 JSON 内部的那个version字段那是游戏版本号编码方式后面会讲。1.2 JSON 模型实体、瓦片、连线、时刻表剥掉外壳之后顶层只有几种可能{blueprint: {...}}、{blueprint_book: {...}}以及拆除规划器和升级规划器对应的结构。日常打交道最多的是前两种。蓝图书是个容器blueprints数组里每一项又是一个带index的对象里面可能嵌套另一本蓝图书——也就是说这玩意是可以无限套娃的写遍历函数的时候必须要用递归别指望一层for循环能打穿。单个蓝图对象里的字段常用的有这些字段类型说明常见误用item字符串固定为blueprint忽略它导致把规划器当蓝图处理label字符串蓝图名称支持非 ASCII用中文时第三方工具可能乱码label_color对象RGBA 颜色三个通道的取值范围是浮点 0~1icons数组最多四个图标带index排序索引重复会导致游戏只显示一个entities数组实体列表蓝图的主体字段差异最大的部分tiles数组地砖列表坐标是格子左上角与实体不同wires数组连线信息新版本才有的扁平结构引用不存在的实体编号会加载失败schedules数组列车时刻表通过entity_number关联机车version整数游戏版本编码高位存主版本低位存补丁号实体对象的字段是整份数据里最杂的。所有实体都有entity_number和name绝大多数有position中心点坐标x、y是浮点方向类实体有direction可配置的实体有control_behavior带库存的实体有items组装类实体有recipe。entity_number是蓝图内的局部编号从 1 开始唯一且被连线、时刻表、物流条件各种地方引用——它就是这张图的主键你随手删掉一个实体但忘了清理引用这份蓝图就废了。position的坐标语义值得单独说一句因为它是后面所有几何操作的基准。坐标单位是格实体的position指的是它的中心。1x1 的实体中心在整数坐标上2x2 的实体中心落在x.5, y.53x3 的又在整数上。这个奇偶规律不是随便定的它保证了实体永远对齐在同一个格子网格里。批量平移蓝图的时候如果你对不同尺寸的实体用了不同的偏移量就会出现一部分实体落在x.0、另一部分落在x.5游戏加载后直接红块图纸放不下去。这个坑我在做局部替换功能的时候踩过一次排查了很久才反应过来是网格对齐被破坏了。2. 解码器的设计取舍与核心实现动手写之前我先试了几个现成的库结论是没必要。整条链路只有三个函数Base64 解码、zlib 解压、JSON 解析标准库全包了。用第三方库反而引入版本兼容问题而且蓝图格式在版本升级时会变字段通用库要么跟不上要么报错信息含糊出问题时你得扒库源码。自己写这三十行出问题一眼就看得出来。2.1 为什么我不用通用压缩库一把梭有个常见误区是拿zlib.decompress(raw, -15)去解理由是很多游戏用裸 deflate。这个在别的场景也许成立但这里的压缩流带 zlib 头用负数wbits会直接抛zlib.error: Error -3 while decompressing data: incorrect header check。如果你不确定可以先用默认参数试失败再换zlib.decompressobj(wbits47)——47 是15 32会自动识别 zlib 和 gzip 头容错性最好。我现在的做法是默认zlib.decompress捕获异常后回退到wbits47两年下来没见过第二种情况但兜底留着不亏。编码方向也有讲究。压缩级别用 9 能让字符串短一截代价是几百毫秒的耗时对单次导出完全无所谓但如果你要批量生成上千份蓝图级别 6 和 9 的差别就出来了我在批量生成模板的场景里用 6体积多百分之几速度快好几倍。JSON 序列化必须用紧凑格式separators(,, :)不能省因为缩进产生的空格会显著增大压缩后的体积而且游戏读的时候虽然能接受但没必要给自己找麻烦。2.2 编解码核心代码与版本号陷阱解码和编码的完整实现如下可以直接抄import base64 import json import zlib def blueprint_decode(text: str) - dict: # 1. 去掉导出时可能存在的换行与空格 s .join(text.split()) # 2. 首字符是格式版本标识现代导出一律为 0 if not s or s[0] ! 0: raise ValueError(非预期的格式标识确认是否粘贴了完整字符串) payload s[1:] # 3. 兼容 URL 安全字符集并补齐长度 payload payload.replace(-, ).replace(_, /) payload * (-len(payload) % 4) # 4. Base64 - zlib - JSON raw base64.b64decode(payload) data zlib.decompress(raw) return json.loads(data) def blueprint_encode(obj: dict, fmt: str 0, level: int 9) - str: # 紧凑序列化ensure_asciiFalse 让中文标签原样保留 raw json.dumps(obj, separators(,, :), ensure_asciiFalse) comp zlib.compress(raw.encode(utf-8), level) return fmt base64.b64encode(comp).decode(ascii)代码短但有个隐含前提JSON 里的数字不能丢精度。Python 这边没问题JavaScript 这边就要小心了因为JSON.parse会把所有数字变成双精度浮点而蓝图里的version字段是 64 位整数的高位编码量级在 2 的 48 次方左右刚好还在安全整数范围2 的 53 次方以内侥幸没事。但如果你自己往里塞了超大整数比如某些 mod 的计数回写时就会悄悄变值。我的处理原则是只读不写的字段原样保留需要改的字段显式转成数字别做整体parse再stringify之外的花活。version字段的编码规则是主版本 48 | 次版本 32 | 补丁 16 | 构建号。这个值本身不影响蓝图加载但游戏会根据它判断是否需要做数据迁移——比如某个实体在旧版本叫这个名字、新版本改名了加载时会自动转换。如果你手工拼一份蓝图却把version写得很高游戏会认为这份蓝图已经是新格式跳过了迁移逻辑结果就是一堆实体认不出来直接丢失。我吃过这个亏早期用模板拼接生成的蓝图version字段直接复制了另一份新版本蓝图的导入后传送带全部消失只剩下一堆箱子。正确做法是要么沿用你导出源的真实版本号要么把version字段整个删掉让游戏自己判断。后者更省心我现在生成的所有蓝图都不带这个字段。2.3 结构校验一份能加载的蓝图要满足什么写批量修改脚本最怕的不是报错而是能加载但内容不对。游戏对蓝图数据的容错其实挺宽松字段多了不报错字段少了会用默认值这反而让问题更隐蔽。所以我在编辑器里加了一层前置校验在生成字符串之前先跑一遍能提前拦掉大部分低级错误entity_number必须唯一且为正整数重复的话游戏只会保留其中一个其余被静默丢弃。所有wires、schedules、物流条件里的entity_number引用必须能在entities里找到对应项悬空引用会让整份蓝图加载失败且游戏不给具体行号。每个实体的position必须满足尺寸对应的奇偶对齐否则放置时变红。相邻实体的占地区域不能重叠这个校验比较重我只在手动编辑模式下开启批量脚本里靠平移的规整性来保证。带recipe的实体recipe必须是该实体允许的配方改了name但没改recipe是最常见的翻车点。这套校验看起来啰嗦实际写起来也就百来行但它把调试时间从在游戏里反复导入导出试错压缩到了看终端输出的第几行有问题。这个投入产出比做过类似工具的人都懂。3. 可视化把实体坐标画成一幅能点选的图可视化是整个编辑器里最花时间的一块也是最值得花时间的。纯文本改 JSON 不是不行但你没法直观确认这两根管子是不是接反了这条红线的端点是不是落在那个常量箱上。图画出来之后很多问题一眼就能看出来比对着 JSON 逐行数坐标快得多。3.1 坐标系与网格对齐渲染前要先做一次坐标归一化。蓝图的position可能是负数比如实体从原点向左铺开也可能整体偏移了很大一段距离。统一做法是扫描所有实体和地砖取minX、minY、maxX、maxY按实体尺寸向外扩展半个身位得到外接框。之后所有绘制都用(x - minX) * scale换算视口平移就是改minX的偏移量逻辑很干净。缩放级别要跟实体尺寸挂钩。默认缩放到 16 像素一格时1x1 的实体只有 16 像素见方图标的细节完全看不清放大到 48 像素一格一张 60x60 的蓝图就要占 2880 像素超出屏幕得靠拖拽。我最后做的是三档缩放加滚轮微调概览档 8 像素看整体布局和连线走向、工作档 24 像素看实体类型、细节档 48 像素看方向、看接口、看信号灯颜色。切换档位时保持鼠标指针下的世界坐标不动体验会好很多这个细节不写的话用户会觉得一缩放就跑偏了。地砖和实体要分层画。地砖是纯色块坐标是整数直接填scale x scale的矩形实体在它上层。顺序上先画地砖再画占地区域轮廓再画类型色块最后画方向指示和连线。方向指示一定不能省——传送带、管道、机械臂的方向决定了这套设计的对错只用色块表示的话两条反向的传送带看起来一模一样。3.2 渲染管线与命中检测我用 Canvas 2D原因是实体数量大时 DOM 会崩。实测下来3000 个实体的蓝图用绝对定位 div 渲染首次绘制要 2 秒以上滚动时明显掉帧换成 Canvas 单次全量绘制只要 30 毫秒左右差距不是一点。绘制流程分三步。第一步建索引遍历entities把entity_number作为键存进Map值里带上实体对象和它的包围盒。第二步按图层顺序绘制连线单独一层画在最上面用红绿两色区分线材类型端点画小圆点。第三步是命中检测不用遍历所有实体而是维护一个网格分桶把世界坐标按 8 格一个格子切开每个桶里存落在该范围内的实体编号鼠标移动时只算当前桶的候选集实体几千个也不影响响应速度。// 网格分桶的命中检测核心 const CELL 8; const buckets new Map(); function buildIndex(entities) { buckets.clear(); for (const e of entities) { const x0 Math.floor((e.position.x - 2) / CELL); const y0 Math.floor((e.position.y - 2) / CELL); const x1 Math.floor((e.position.x 2) / CELL); const y1 Math.floor((e.position.y 2) / CELL); for (let gx x0; gx x1; gx) { for (let gy y0; gy y1; gy) { const key ${gx},${gy}; if (!buckets.has(key)) buckets.set(key, []); buckets.get(key).push(e.entity_number); } } } } function pick(worldX, worldY) { const key ${Math.floor(worldX / CELL)},${Math.floor(worldY / CELL)}; const cands buckets.get(key) || []; // 从后往前找后画的在上面 for (let i cands.length - 1; i 0; i--) { const e byNumber.get(cands[i]); if (inBBox(e, worldX, worldY)) return e; } return null; }命中的视觉反馈也要克制。我一开始做的是选中实体高亮描边结果多选十几个之后满屏都是框根本看不清内容。改成半透明填充加细描边选中态用暖色、悬停用冷色层次立刻清楚了。3.3 上千实体时的性能处理大蓝图有两个性能瓶颈第一个是绘制第二个是属性面板的重渲染。绘制这块靠 Canvas 已经解决大半剩下的优化点是滚动和缩放时用requestAnimationFrame合帧别在mousemove里直接重绘缩放到概览档时把实体简化成纯色块跳过图标和文字能省掉一半时间连线层如果超过 5000 条改成一次性绘制到离屏 Canvas 再整体贴图。第二个瓶颈更隐蔽。刚开始我把属性面板写成任何选中变化都重建 DOM结果框选 200 个实体时页面直接卡死三秒。后来的做法是面板只显示聚合信息多少个实体、几个类型、几根线具体属性只在单选时展开多选时给一个批量编辑入口。这个改动之后框选上千个实体也是秒开。还有一个体验上的小优化值得提撤销栈。批量操作的杀伤力太大了一次误操作可能把整张图的连线全删了。我用的是快照式撤销每次批量修改前把整个 JSON 深拷贝一份压栈栈深限制 20 层。内存上确实不划算但实现在十分钟内搞定且绝对可靠比写增量 diff 划算得多。吃过亏你就知道工具的价值一半在功能一半在能后悔。4. 批量修改从手工点到写过滤器这是我做这个工具的原动力。游戏内的批量操作能力很有限替换同类实体还能靠快速替换但一旦涉及只替换某一区域内、某个方向的、带特定配方的实体就只能一个个点。把数据拿到编辑器里之后这件事变成了写谓词加映射复杂度完全是另一个量级。4.1 过滤谓词与批量替换最基础的批量操作是按名字替换。听起来简单实际要处理的关联字段不少改传送带名字底下压着的地下游入口和出口也得跟着改改组装机名字配方可能在新机器上不存在改箱子名字里面的库存物品在新箱子上可能放不下。我的做法是把替换定义成一张映射表每个条目里除了名字还带上需要联动修改的字段和可选的守卫条件REPLACE_RULES [ { match: {name: transport-belt}, set: {name: fast-transport-belt}, }, { match: {name: assembling-machine-2, recipe: electronic-circuit}, set: {name: assembling-machine-3}, }, ] def apply_rules(bp, rules): hit 0 for e in bp.get(entities, []): for rule in rules: if all(e.get(k) v for k, v in rule[match].items()): e.update(rule[set]) hit 1 break return hit这个写法很朴素但够用。真正提升效率的是把谓词做成可组合的形式按name、按recipe、按坐标矩形、按direction、按entity_number白名单任意组合取交集。这样一来把这片区域里所有朝北的机械臂换成带堆叠的版本就变成两行配置。踩过的坑在这里改名字之后必须检查control_behavior是否还合法。不同实体支持的条件字段不一样比如把普通机械臂换成带滤波的版本原来的circuit_condition结构可能对不上游戏加载时会丢弃这段配置且不报错你就得到了一堆看着没问题但行为变了的实体。我的处理是在批量替换后跑一次控制行为兼容性检查把不认识的条件字段直接剔掉宁可丢失配置也不要留下脏数据。另一个高频需求是批量改配方。这块的坑在于配方和原料不是自动关联的实体上的recipe改了items里的在制品和缓存原料不会跟着变。如果你只想改产物得把items整个删掉让游戏重新初始化否则会看到机器显示做新配方但库存里是旧的原料这种诡异状态。这个问题在换产线的时候特别容易遇到我的做法是提供一个勾选项清空在制品默认勾上。4.2 整体平移、旋转与镜像的坑平移是最简单的变换直接给所有position加偏移量即可地砖也要一起动def shift(bp, dx, dy): for e in bp.get(entities, []): e[position][x] dx e[position][y] dy for t in bp.get(tiles, []): t[position][x] dx t[position][y] dy但要注意dx、dy的取值。整数偏移对奇偶对齐没有影响奇尺寸还是整数偶尺寸还是 .5安全。如果为了对齐而用了 0.5 的偏移就会把奇尺寸实体推到x.5上整个蓝图立刻不可放置。我在 UI 上直接禁用了小数偏移只允许整数格移动就是为了堵住这个口子。旋转比平移麻烦得多。围绕一个中心点旋转 90 度坐标变换是(x, y) - (cx (y - cy), cy - (x - cx))同时direction要加 90 度对应的枚举值再取模。问题在于不是所有实体都能旋转。某些实体只能朝四个方向中的两个某些实体旋转后会破坏内部连接关系比如管道的接入方向、地下传送带的进出口位置。我做过一次整体旋转 90 度的批量功能结果几十个管道的流体连接全断了排查下来是旋转后direction变了但管道内部的连接索引没同步调整。结论是旋转只对纯实体排布传送带、机械臂、组装机可靠涉及管道、轨道、电线杆这些有连接语义的实体老老实实手动摆。镜像更是个陷阱。新版蓝图格式里确实有镜像标记字段但那是游戏在放置时做的映射你自己改坐标数组实现不了真正的镜像效果——因为实体的不对称性比如输出口在右侧的机器镜像后应该出现在左侧根本没法靠坐标取负来表达。我试过用坐标取负加方向翻转硬做结果是一堆看起来镜像了但实际不工作的设施。后来我把镜像功能砍了只保留复制一份并平移功能少一个但没人被坑。4.3 配方、物品栏与标签的联动修改批量改配方的时候我整理了一份连带字段清单改之前逐项确认修改项需要同步处理不同步的后果recipe清空或重置items库存原料与产物不匹配name机器校验配方是否合法加载后配方被清空name箱子检查库存是否超容量超出部分被丢弃label无仅显示问题icons建议同步更新图标与实际内容不符control_behavior校验字段兼容性配置被静默丢弃这里有个实践技巧改完之后不要急着导出先在编辑器里跑一次差异预览把改动前后的实体数量、类型分布、连线数量列出来对比。我靠这个抓出过好几次规则写错了导致全图实体被改成同一种的事故——如果没有预览导入游戏才发现那基本等于重做。标签和信息类的字段虽然不影响功能但对可维护性影响很大。我的习惯是每次批量生成变体时自动在label后面追加版本后缀同时在description里写清楚这份蓝图是基于哪个源改的、改了哪几条规则。半年后回头看一堆名字差不多的蓝图这个记录能救命。5. 电路调整红绿线、控制行为与信号表电路部分是我最后做的一块因为它最不直观。前四块你至少能靠肉眼看图确认对不对电路不行——两根线的区别在图上是颜色差异但在逻辑上是完全不同的信号网络。所以这块我花了更多时间在数据结构和校验上。5.1 连线数据的两种形态连线信息在蓝图 JSON 里有两种存法取决于蓝图的版本。早期版本里连线挂在实体自身的connections字段上结构是第几号连接点 - 颜色 - 端点列表每个端点记录对方的entity_number和连接点编号。新一些的版本改成了顶层wires数组每项是个三元组头两个元素是两端的实体编号第三个是线类型红线和绿线用不同的数字区分。两种形态的处理方式完全不同。老结构要遍历每个实体的connections嵌套三层才能拿到所有连线新结构就是个扁平数组过滤和生成都特别方便。我写了一个统一层把老结构读出来转换成扁平的两端点 颜色列表所有业务逻辑都基于这个统一表示最后写回时再按目标版本还原。这个中间层让后续所有功能的实现难度降了一个等级def collect_wires(bp): 统一成 [(a, b, color)] 形式color 取 red 或 green out [] for w in bp.get(wires, []): a, b w[0], w[1] color red if len(w) 3 or w[2] 1 else green out.append((a, b, color)) for e in bp.get(entities, []): for _port, colors in (e.get(connections) or {}).items(): for color, links in colors.items(): for link in links: out.append((e[entity_number], link[entity_id], color)) return out有个必须注意的点同一对实体之间同色线只能存在一条。你往数组里塞两条(3, 7, red)游戏加载时会合并成一条看起来无害但如果后续按数量做统计或做去重逻辑就会被重复项带偏。我的做法是写入前统一去重用无序对做键(min, max, color)顺便还能把自环两个端点相同的过滤掉。另一个坑是连线端点的合法性。红绿线理论上可以连接任意两个带电路接口的实体不管你隔多远但前提是两端实体都必须存在且都支持电路连接。批量生成连线时如果不做校验很容易把一根线连到传送带上——传送带没有电路接口这行数据会被游戏丢弃你得到的是少了几根线但不知道少在哪。所以生成之后一定要回读校验把无效连线列出来。5.2 控制行为的分版本差异control_behavior是整份蓝图里结构最不稳定的部分不同实体类型、不同版本之间的字段差异极大。举几个典型机械臂的启用条件在早期版本里是扁平的circuit_enabled、circuit_condition、circuit_read_hand_contents这些字段并列新版本统一收进了嵌套结构里。常量箱的变化最明显早期是一维的信号列表每项带信号名、类型、数量和排序索引新版本改成了分区 分区内信号多了一个sections层级还支持每个分区独立的生效条件。运算器和判断器的条件表达式结构也调整过。这种差异带来的直接后果是同一段处理代码在两种版本的蓝图上一个生效一个静默失效。我的应对策略是写一个探测函数先看实体里有没有sections键有就走新版分支没有就走老版分支两个分支各自维护。别想着写一套通吃的代码字段名和层级都不一样强行兼容只会让逻辑变得难以维护。def read_constant_signals(entity): 统一读出常量箱的信号列表 cb entity.get(control_behavior) or {} if sections in cb: out [] for sec in cb[sections]: for f in sec.get(filters) or []: out.append({ name: f[name], type: f.get(type, item), count: f.get(count, 0), }) return out # 老版本扁平结构 return [ {name: f[signal][name], type: f[signal].get(type, item), count: f.get(count, 0)} for f in cb.get(filters) or [] ]信号类型这一层也容易出错。信号分物品、流体、虚拟信号三类虚拟信号的名字形如signal-A、signal-0、signal-check物品和流体用的是内部名称。批量替换信号的时候如果只比对名字不看类型很可能把同名但不同类型的信号替换掉。我实际遇到过想把一组signal-A换成signal-B结果规则写得太宽把某个名字里带 A 的物品也一起改了。加了类型检查之后再没出过。5.3 批量重排信号与条件常量箱的信号排序是个高频需求。手工生成一组信号比如各种材料各留一个阈值在游戏里一个个拖顺序能耗掉半小时用脚本就是一秒钟的事。做法很简单读出信号列表按你定义的顺序重排写回时重新编号index。ORDER [iron-plate, copper-plate, steel-plate, electronic-circuit, advanced-circuit] def reorder_signals(entity, orderORDER): sigs read_constant_signals(entity) rank {name: i for i, name in enumerate(order)} sigs.sort(keylambda s: rank.get(s[name], len(order))) # 然后按目标版本的结构写回index 从 1 连续编号 ...判断器和运算器的条件表达式批量替换也是类似思路。这里的坑在于条件是一个列表可以有多条按连接方式组合每条内部又有左右两个操作数操作数可能是常量、可能是信号、也可能是每个这种特殊值。批量替换的时候必须区分对待只替换类型为信号的、且名字匹配的那些操作数别碰常量和特殊标记。这条规则听起来理所当然但我在第一版里就写漏了判断把某个条件里的数字常量也当成信号处理导出的蓝图直接报错。从那以后所有涉及control_behavior的写入操作我都强制走一次结构合法性检查——用一份已知结构去比对字段名和类型不匹配就拒绝写回宁可不改也不能产出坏数据。批量生成连线的场景也值得单独说。我做把一组常量箱串成一条线的功能时最初的实现是首尾相接生成n-1条线测试时发现超长链100 个以上在某些情况下行为异常。排查很久也没找到确定原因最后的做法是改成星形连接——选一个中心点其余全部连到它上面。这种拓扑更稳定也更容易在图上检查。如果你也要批量生成连线我建议避开超长链星形或分组星形更稳妥。6. 常见问题速查与避坑记录工具跑了两年多陆陆续续记了不少问题。这一节把这些整理成表和心得都是实际调试出来的比文档管用。6.1 问题排查速查表现象最可能的原因排查方式粘贴后解码报 Base64 错误字符串带换行或长度未补齐先去空白再补齐解压报 header check 错误用裸 deflate 解码改用带 zlib 头的模式蓝图能导入但实体消失一半version字段写高了跳过迁移删掉version让游戏自判导入后连线全断引用了不存在的entity_number校验引用完整性并清理悬空项放置时整体变红坐标奇偶对齐被破坏检查是否用了 0.5 的偏移机器显示新配方但不生产items里残留旧原料清空在制品字段配置项全部丢失control_behavior字段不兼容按版本分支处理中文标签变乱码序列化时未保留非 ASCII关闭 ASCII 转义输出 UTF-8大蓝图导入卡住实体重复编号用集合校验唯一性批量替换后图标不符只改了name没改icons同步更新图标数组这张表里出现频率最高的是前两条基本都是初学者第一次解码时踩的。后面几条属于改到深处才会遇到的类型但也往往是最难查的——因为它们不报错只是结果不对。6.2 几条踩过才知道的经验第一条是关于改动幅度的。我一开始喜欢一次性改完所有东西再导出验证后来发现这样出问题时根本定位不了是哪一步出的错。现在的习惯是分三步走先只做解码和再编码导回游戏确认原始蓝图完全一致这一步能验证你的编解码链路没有精度损失再做一次最小改动比如只改一个标签确认能加载最后才跑大批量规则。这个流程看起来慢但把排错成本从在几百个改动里找问题降到在一步改动里找问题总体是快的。第二条关于备份。批量操作前必须存一份原始字符串而且要存在文本文件里而不是剪贴板。我遇到过一次改到一半发现思路错了想回退结果剪贴板已经被覆盖原始蓝图也没在游戏里存过只能凭记忆重新拼损失了一晚上的时间。现在编辑器里有个快照按钮点一下把当前 JSON 存成本地文件文件名带时间戳。这个功能实现只要二十行但它是整个工具里我用得最多的一个。第三条别迷信能加载就是对的。游戏的加载器非常宽容很多结构错误它默默吞掉你得到一份看起来正常但行为不对的蓝图。所以我的工具里加了一层语义检查比如检查每个机械臂的朝向是否指向它面前的传送带、检查组装机的产物是否有下游接收、检查常量箱的信号是否真的被某根线引用。这些检查不保证设计正确但能抓出大部分低级错误。最后分享一个小技巧如果某个实体的字段你不确定该怎么写最快的办法是在游戏里摆一个、配置好、导出、解码、看 JSON。这比翻文档准得多因为文档可能滞后于版本而导出结果永远是当前版本的真相。我做电路部分的时候光是配置好导出看一眼这个动作就重复了二十多次每次都能发现一两个我没料到的字段。这个笨办法解决了我遇到的绝大多数这字段到底怎么填的问题。真要说这工具给我带来的最大变化不是省了多少点击而是让我对蓝图这个东西祛魅了。它就是一坨结构化的数据结构清楚了剩下的都是耐心活。你手头如果有重复度高的蓝图改造需求花一个周末把解码和可视化做出来后面的效率提升会远超预期——尤其是当你需要维护十几套变体的时候手工改和脚本生成的差距是数量级的。