伊甸园计划 / Project Eden

把《戴森球计划》的后期产线整体拉满的 BepInEx mod。

八座万倍速巨型建筑、满级采矿机与物流站、九种新矿脉，一整条从煤和水通到有机化学的化工链 （C1 → 烯烃 → 芳烃 → 高分子，外加把一桶原油切成四个馏分的炼油线）， 逐台建筑可调的合金配比、5000 层传送带集装——所有数值都写在 JSON 里，装完就能改。

开发与测试基于游戏版本 0.10.34.28529 ／ BepInEx 5.4.17

💬 交流群（QQ）：789720138 —— 报 bug、提需求、聊平衡都在这里。

完整特性说明 —— 每一样新物品、新配方、新建筑，以及每个数值是怎么推出来的：

• 📘 中文：mod特性.md
• 📗 English: mod_feature.md

本项目在很大程度上借助 AI 完成。文中描述的引擎行为都在游戏内验证过；欢迎提 bug。

Written with heavy AI assistance. All engine behaviour described here was verified in-game; bug reports welcome.

⚠️ 先看这里：存档兼容性

装了这个 mod 之后存的档，卸载后就打不开了。 不是「缺物品图标」那种降级，是真的读不出来。

本 mod 带一个 preloader（BepInEx/patchers/ 里那个 DLL），它在游戏程序集装载前把传送带货物的 两个字段加宽了——这是「高层集装 + 满级增产剂同时成立」的前提——货物块的存档格式因此从版本 2 升到 3。

• 装 mod 之前存的老档仍然能开（会自动按老格式读），反过来不行
• 除此之外还会往存档写新物品、新配方、新矿脉类型，以及一个独立的 .moddsv 伴生文件
• 没有干净的退回原版的路。要退就回备份。

强烈建议开新档，或者动手前把 %USERPROFILE%\Documents\Dyson Sphere Program\Save 整个复制一份。

安装

1. 先装四个前置，都在 Thunderstore 上，装进同一个 profile：

缺任意一个，游戏启动即报错。

2. 导入本体：r2modman 左侧 Settings → Import local mod → 选发布包的 zip， 然后从 r2modman 点 Start modded 启动（直接开 Steam 不会加载 mod）。

手动安装的话，包里的 plugins/ 和 patchers/ 要分别落到 profile 的两个目录下：

plugins/ProjectEden.dll          →  BepInEx/plugins/ProjectEden/ProjectEden.dll
plugins/Newtonsoft.Json.dll      →  BepInEx/plugins/ProjectEden/Newtonsoft.Json.dll
patchers/ProjectEden.Preloader.dll  →  BepInEx/patchers/ProjectEden/ProjectEden.Preloader.dll

⚠️ patchers/ 里那个不能漏，也不能放进 plugins/。 放错位置不会报错： BepInEx 不去 plugins/ 里找 patcher，插件启动后发现字段没被加宽，就按降级模式继续跑 （集装退回 255、超过 63 层的增产剂被夹断），日志里写一行就过去了。

3. 确认装对了：BepInEx/LogOutput.log 里应该有这两行——

Project Eden v1.6.0 已加载
Cargo.inc / Cargo.stack 已加宽为 Int16（结构体 36 字节）：…

第二行是判断 preloader 有没有生效的唯一依据。完整说明见 部署.md。

改了什么

内容是按真实化学与物理推的

这不是风味文案，是每个数值的来源。新物品的属性全部推导而来，不是挑出来的：

• 配方配比来自配平的化学方程式 —— 2 Al₂O₃ + 3 C → 4 Al + 3 CO₂ 就是矿 ×2 + 煤 ×3 → 铝块 ×4 + CO₂ ×3
• isFluid 看常温常压下的相态；fuelType 看它现实中到底烧不烧
• 热值按燃烧焓换算，全表锚在原版煤一个点上（2.7 MJ ↔ 393.5 kJ/mol）
• 用哪台机器看反应类别，不看方便：MTO 是脱水不是氧化还原，所以它留在原版化工厂

哪种还原剂能炼哪种矿，是按 Ellingham 图判的，不是按平衡感： 一氧化碳还原不了氧化铝，乙烯可以——判据是裂解后给不给得出单质碳。

每条配方的化学依据都逐条写在特性文档里（中文 ／ English）。

已知取舍

不是 bug，是上面那些改动的必然副作用：

• 采矿机可以叠放，代价是它也能叠进别的建筑里，而且不能再原地重建/替换
• 普通采矿机也能采原油（放行的两处代码指令特征完全相同，没法只放开一处）
• 原版化工厂也能做新增的「原油X射线裂解」（配方按类型生效，不按建筑）
• 传送带直连喂不满巨型建筑 —— 请用它自带的物流站喂料
• 巨型建筑的 30 个储物格看不到也调不了（点开是配方面板，两个面板会互相顶掉）——格位按当前配方自动铺，本来也不用手动配
• 分拣器摆臂速度没有改，改的是集装层数和传送带速度
• 掉落过滤与信号选取窗口画不出第 14 列以后的物品（物品选取窗口有搜索框，不受影响）

兼容性

• 创世之书（GenesisBook）：检测到就自动停用本 mod 的巨型建筑相关功能，避免同一台建筑被两套逻辑重复驱动
• 银河尺度（GalacticScale）：新矿脉通过兼容层工作；另外顺手修了 GS2 一个会让存档读不出来的问题
• 其余 mod 未系统测试

配置

配置是 JSON 嵌入在 DLL 里的，装完的包里看不到单独的文件。两种改法：

• 不用编译：在 profile 里新建 BepInEx\config\ProjectEden\<同名>.json，它会盖掉内嵌的那份，重开游戏生效
• 改源码重新编译：内容类配置（矿种、配方、数值）本来就跟着版本走，一般走这条

用了覆盖文件的话，日志里每次都会打一条 WARNING 把路径写出来—— 一份忘了删的覆盖文件会让之后所有对内嵌 JSON 的修改看起来「没生效」。

出问题了

BepInEx/LogOutput.log 里搜 ProjectEden。

本 mod 的每一处改动都会打一行确认；匹配失败会打 ERROR 而不是静默失效， 所以那份日志基本能直接指出是哪一块没生效——反馈问题时请带上它，比截图有用得多。

许可

这个仓库不是单一许可的，代码和美术分开。

版权

Copyright (C) 2026 RobertWangWang and Project Eden contributors
Copyright (C) 2022-2026 Awbugl and ProjectGenesis contributors

本项目基于创世之书（ProjectGenesis）开发，代码部分经其作者授权使用。 按 GPL 的要求，上游的版权声明完整保留；哪些文件属于其衍生作品、 哪些只是借鉴思路，逐文件列在 NOTICE 里，相关文件头也各自写明。

代码：GPL-3.0

ProjectEden/src/、ProjectEden.Preloader/、tools/ 下的全部源码，以及 ProjectEden/data/ 下的 JSON 配置，采用 GNU GPL v3.0。

美术：仅授权用于《戴森球计划》的 mod

ProjectEden/assets/icons/ 下的全部 77 张图标（均由 tools/make_icons.py 生成）， 以及运行时程序化生成的建筑几何与贴图（ProjectEden/src/Model/），授权范围是：

可以自由用在任何《戴森球计划》的 mod 里，包括修改与再分发。 不授权用于本游戏之外的任何用途。

⚠️ 这条限制和 GPL-3.0 是有张力的，下游需要知道。 GPL 要求整体可被任何人自由再分发和修改、不附加额外限制； 「仅限某个游戏的 mod」是一条额外限制。两者可以并存——代码归代码、美术归美术—— 但这意味着打包后的整体不是纯 GPL，在 FSF 的口径下属于非自由软件。 引用本项目时请分别标注，不要笼统写成「GPL 项目」。

全部美术均为自绘

assets/icons/ 下的 77 张图标全部由 tools/make_icons.py 生成（矢量源码在仓库里）， 建筑的外形与贴图由 ProjectEden/src/Model/ 在运行时程序化生成。

本仓库不含任何第三方美术资源。

八座巨型建筑的图标刻意做成和它们的 3D 模型同一个轮廓—— 建造栏里认出来的，就是地上那一座。

分子画结构式、芳环画成六边形加内圈、笼形分子和馏分照实物画—— 每一处取舍的理由都写在 tools/make_icons.py 的函数注释里。

关于创世之书

本项目是在《创世之书》（GenesisBook）的基础上做起来的。 这里的大部分非平凡机制都参考了它的实现， 遇到问题时第一件事就是去看它当初怎么解决同一个问题的。

• 代码部分已获得创世之书作者授权。 在此致谢。
• 美术资源未获授权，也没有使用——本仓库的图标与模型全部自绘，见上一节。

反过来也一样：创世之书，以及任何其他《戴森球计划》的 mod，都可以自由 fork 本仓库。 代码遵循 GPL-3.0 的条款；自绘美术按上面那条授权，用在 DSP mod 里不需要另行取得许可。

致谢

• 创世之书 / GenesisBook（作者 Awbugl）—— 本项目的起点。

• CheatEnabler / UXAssist（作者 Soar Qin，MIT） —— 作弊开关的设计参考了 CheatEnabler；英文本地化的做法参考了 UXAssist.Common.I18N （往 Localization 的字符串表里注册键，并在语言加载后补写）。

  是参考不是照搬，两处实现都走了另一条路，理由写在特性文档里： 「无间距」CheatEnabler 是把判定里的常量全局换掉，而本作版本里那个常量有三处是炮塔间距， 一律替换会把炮塔规则一起废掉，所以本 mod 改成事后擦除建造预览的拒绝条件； 本地化则没有用 CommonAPI 的 RegisterString，因为它对已存在的键照写不误， 会覆盖掉原版的翻译，本 mod 自己加了一道防撞检查。

参与开发

• 部署.md —— 装给别人用怎么装、发新版怎么打包（含 preloader 的离线校验流程）
• CLAUDE.md —— 架构说明与踩过的坑。读 IL 胜过猜，这份文档里的每一条机制都是这么来的

dotnet build                                   # 编译并部署插件到 profile
dotnet build ProjectEden.Preloader/ProjectEden.Preloader.csproj -c Release
powershell -ExecutionPolicy Bypass -File tools\verify_preloader.ps1 -Config Release
python tools\pack_release.py                   # 打发布包

preloader 改动后必须跑 verify_preloader.ps1。 它在游戏程序集交给 CLR 之前重写它， 写错的表现是游戏启动失败、报一个不指向本仓库任何代码的 CLR 类型加载错误—— 到那一步，平时那套「读 IL、报匹配数、匹配为 0 就大声失败」的办法一个都用不上。

更新日志

1.12.8

大型采矿机的产量上限，现在和轨道采集器一样了：600,000,000/秒。

起因是「气态行星采集器有多快，采矿机能不能跟它一致」。查下来两个数差了 3600 倍， 而差距的成因不在开采速度上——开采速度早就顶满了，一点余量都没有。

原版的产出是一句整除：件数 = time / period。每 tick 往 time 上累加 速度 × 采矿倍率 × 矿脉数，而 time 是 32 位整数，所以累加量必须留在 20 亿以内：

每 tick 产量 = 累加量 ÷ period ≤ 20 亿 ÷ period

分子这个 mod 早就顶满了（「按满级科技工作」做的就是这件事）。日志里的实测数字把话说死了：

抽水站产量：period=720000，当前约 166,667/秒；该建筑的理论上限约 178,957/秒——受 time 为 Int32 约束
行星 Delta Delphini II号星 气体采集速率：600000000/秒 / 69495750/秒 / 600000000/秒

只剩 7% 余量，所以再怎么调速度都动不了。剩下唯一能动的是分母。

现在 period 从采集器那个数倒推。采集器的速率被夹在「一 tick 填满一个储物格」 （stations.json 的 collectorMaxPerTick，没配就退回 slotCapacity），也就是 1000 万/tick； period = 20 亿 ÷ 1000 万 = 200，采矿机于是也落在 1000 万/tick。 两边不是各填一个凑出来的数，而是共用同一个锚、按构造相等。 抽水站和原油萃取站跟着各自的 boostWaterPumps / boostOilExtractors 一起走。

这个数在两边都是「产量不再是瓶颈」的意思，不是真的每秒搬六亿件。 一 tick 就把机内缓存 和物流站槽位填满，之后卡在网络取货的速度上——采集器今天就是这样。想退回原版刻度， 把 advancedminer.json 的 minerPeriod 改成 0。

动之前核对过的三件事

• period 全程只有三处写——Import、SetEmpty、NewMinerComponent（后者取自 PrefabDesc.minerPeriod）。没有任何 UI 能写它，所以运行时可以双向对齐， 而不是「配置值只是默认值」那一类。
• 它进存档，而且 Import 不从 proto 重新推导，所以已建成的采矿机必须在运行时补齐。
• 另外 13 处读它的全是显示与统计（参考速率、理论产能、星球/恒星面板、采矿机面板、 两个采集器面板），period 在它们的算式里同样位于分母，所以面板会跟着一起变大—— 那是对齐，不是被改坏。

物流：配送运输机运载量 5000，两种飞机的基础速度各 ×10

stations.json 新增三个旋钮。

courierCarries: 5000 —— 配送运输机（从配送器/综合物流枢纽飞出来、把货送到机甲手上那种） 的单次运载量，原版基础值 5。它和 droneCarries 是两种飞机：后者管的是物流站之间搬货的 行星内物流运输机（配置里一直是 10000），这一项以前根本没人管。 性质相同——存在 GameHistoryData 里、由科技累加、进存档——所以同样双向对齐，调低也生效。 CourierData.itemCount 是 Int32，5000 没有宽度问题（这一条是查过的，不是想当然）。

droneSpeedMultiplier: 10 / courierSpeedMultiplier: 10 —— 两架飞机的基础速度，各自 ×10（运输机 8 → 80，配送机 10 → 100）。

最终速度 = 基础 × 科技倍率。两架飞机结构完全一样，所以代码里是同一个函数—— 同一段推理抄两遍，早晚有一份跟不上另一份。两边的写入点都枚举过：

也就是说科技从不碰基础值，所以改基础值和科技不打架。 代价说清楚：往后每一级速度科技的收益也跟着放大了，因为它加成的基数变大了。

实现上是「原版基础 × 倍率」算绝对值，绝不在现值上乘。 这个字段进存档 （Export @0345 / Import @074F），在现值上乘的话第二局就是 100 倍、第三局 1000 倍， 而且一个字都不报。原版基础值（运输机 8 / 配送机 10）是活取 Configs.freeMode——SetForNewGame 自己就是从那儿取的；写死数字会在游戏更新改了它之后静默失准。

开机汇总行现在把三种运载量和两种实际速度（基础 × 科技）一起打出来， 两条「基础速度改了」的日志各有各的标志位——共用一个的话先跑的会把后跑的那行吃掉， 而「另一架改了没有」恰恰是要看的。

修复：蓝图复制了几座重叠建筑，粘贴就建几座

报障：「建筑可以堆叠，蓝图框选也框得到，但一粘贴就只建出来一座」。

蓝图数据是全的，被关掉的是粘贴预览。 BuildTool_BlueprintPaste.ArrangeOverlapBP 专门找同一位置的多个预览（判据是 (a.pos − b.pos).sqrMagnitude < 0.25f，即 0.5 米）， 命中之后成对写两个字段，四处形状一致（@0244 / @025F / @037C / @0397）：

V_8.bpgpuiModelId = -1;                                 ← 真正拦住建造的是这个
V_8.condition     = EBuildCondition.BlueprintBPOverlap; // 51

而 CreatePrebuilds 的第一道闸就是它，排在 condition 检查之前：

0030: if (bp.bpgpuiModelId <= 0) continue;
003B: if (bp.condition != Ok && bp.condition != NotEnoughItem) continue;

所以只清 condition 一点用都没有——已有的「建造条件放行」作弊清的正是 condition， 这就是为什么那个开关开着也照样只建一座。现在两个一起还原。

还原成什么值是快照来的，不是猜的：bpgpuiModelId 除了 ArrangeOverlapBP， 只有 .ctor / ResetAll（都写 −1）、Clone（原样复制）和蓝图复制建预览时会写， 所以正确的原值就是「ArrangeOverlapBP 跑之前的那个」——前置拍快照，后置按快照还原。

而第三个字段 coverbp 必须留着不动，这一条是反直觉的。 「成对写的要成对还原」会让人想把三个字段全清掉，那样反而会坏： CheckBuildConditions @256D–2584 拿 coverbp 当豁免—— if (a.coverbp == b) goto skip; 的意思是「这两个是已知的重叠对，互相不判碰撞」。 清掉它，刚还原的那个会立刻被重新判成重叠打回去。它是通行证，不是标记。

开关跟着「是什么让建筑能堆起来」走：cheats.json 的无碰撞，或 advancedminer.json 的 allowMinerOverlap。两个都没开时不动原版——那时候重叠建筑本来就摆不下去， 放行只会粘出一片建不成的预览。

巨型建筑提速：组装类 ×6、其余 ×3

问的是「万倍速的巨型建筑还能不能再快」。量下来结论是：能，但现有两个旋钮一个都不是杠杆。

• assemblerSpeed 是 1e8，早就比任何配方的 timeSpend 高一两个数量级，一次调用必定填满，再高无效。
• cyclesPerTick 配的是 60，而十六座里只有冶铸熔炉一座够得着。

卡住其余十五座的是原版自己的产出闸，写在 AssemblerComponent.InternalUpdate @0138–0184， 按 recipeType 分三档：冶炼 已产出 + 每次产量 <= 100、组装 已产出 <= 每次产量 × 9（上限 10）、 其余 × 19（上限 20）。现在那两档乘法闸对巨型建筑抬到 cyclesPerTick：

冶炼那一档故意没动：它的闸是加法形状，上限 100 ÷ 每次产量，单次产量 1 时是 100， 本来就高过 60——它从来不是被闸卡住的，改了没有收益，却要多算一层乘法。

判定用「速度 ≥ 巨型阈值」，和 MegaTick 认巨型建筑是同一个判据，所以存档里每一台普通装配机 一个字节都不受影响——这很重要，因为这个方法服务着全存档的装配机。

匹配点是先数后写的。 全方法里 9 / 19 / 100 一共出现 9 次，按指令形状 （ldelem.i4 ; ldc ; mul ; ble）分类正好是 7 处乘法闸 + 2 处冶炼加法闸 + 0 处其他用途； 转译器断言 7，对不上一处都不改。这份枚举留成了 tools/check_output_gate.ps1， 游戏更新之后离线跑一次就能重新确认，不用进游戏。

代价是背压，要知道它会挪到哪。 这道闸同时是产出缓冲的背压——「闸 20」就是产物攒到 20 倍单次产量停手。抬到 60 意味着缓冲深三倍，而下游是物流站槽位和取货速度。 所以抬开的是「机器算得慢」，接下来先顶上来的会是「货运不走」。

顺带修好一个一直在报大的诊断：本星球普查那行原本拿 cyclesPerTick 直接乘台数当「等效普通装配机」， 完全不知道产出闸的存在，于是报大了 3 到 6 倍。现在逐台按各自配方类型算， 而且读的是转译器用的同一个函数，所以诊断和行为不会各说各话。

修复：本 mod 的建筑在电力统计里没有自己的分项

电力统计的分项不是按建筑现算的，而是查一张表：

ProductionStatistics.RefreshPowerConsumptionDemandsWithFactory @0054–006D
    conDemands[ powerConId2Index[protoId] ] += requiredEnergy

而 ItemProto.InitPowerFacilityIndices 是这两张表唯一的构建者，调用点也只有一处—— VFPreload/<PreloadThread>d__51::MoveNext @08D8，而 LDBTool 挂的 InvokeOnLoadWorkEnded 在同一个方法的 @0E11。所以表建好时 LDB 里一个 mod 的 proto 都还没有； LDBTool 的 post-patch 清单里没有它，CommonAPI 没有，profile 里其他插件也都没有（逐个 DLL 搜过）。 这是 InitFluids / InitTurretNeeds / itemStackCount 那一族的第四张表。

它不崩，只是记错账。 两张表都是定长 new int[12000]，而本 mod 的物品号在 6500 多、落在界内， 于是读到的是数组默认值 0——而下标 0 是构建者开头 Add(0) 预留的占位行（查不到任何 proto）。 结果是本 mod 每一座耗电/发电建筑的功率全被汇进那一行无名无图标的占位行。

总量一直是对的：totalConDemand 在查表之外无条件累加，所以总发电/总耗电和曲线都准， 错的只有「按建筑分项」那张列表。

修法和同族前三张一样：在 PostAddDataAction 上把原版自己的构建器再跑一遍（它整表重建，幂等）。

时机是这件事里唯一需要想的部分，而且不能往后挪。 ProductionStatistics.Init @0084/@0089 用这两张表的长度给 genCapacities / conDemands / genCount / conCount 定容，而它来自 GameStatData.Init / Import——每次开局或读档，排在 PostAddDataAction 之后。 挂在这里，表先变长、统计数组随后按新长度分配；挂到 GameData.Import 那种更晚的位置， 就会拿新下标去写老长度的数组，直接 IndexOutOfRangeException。

核对的是末态：凡是打了 isPowerGen / isPowerConsumer 的 proto 都必须映射到非 0 下标 （真实建筑永远从 1 起，0 被占位行占掉了），有一个落在 0 就报名字出来。

一处连带修复

原版往传送带吐货的堆叠层数是 (36000000 / period × 采矿倍率) / 1800 + 1，period 也在分母上。 周期调小之后这个值会算到两万多，而 Cargo.stack 加宽后的上限是 8191。 所以它从「只抬高」改成了「抬高并封顶」——不封的话 Int16 回绕成负数， 就是本仓库记过的「自动集装机吃货、面板显示负数」那一类，而且一个字都不报。

顺带：产量上限那行日志原本整局只打一次，于是三种设备（采矿机 / 抽水站 / 原油萃取站） 里只有最先 tick 的那一种留下记录——而「另外两种是多少」恰恰是这次最需要看的数。 改成按建筑种类各报一次。

⚠️ 行星放大仍然默认开着（1.12.1 起），所以在 1.12.0 或更早版本下存的档， 用这一版打开就废了。要继续用老存档，在 profile 里新建 BepInEx\config\ProjectEden\planet.json 写 { "enabled": false }，重开游戏即可。

已知缺口（同上一版）

按半径 200 写死的常量很可能还有。到目前为止修掉的五处都是被具体症状逼出来的， 不是系统排查出来的。最可疑的是 GameCamera.Logic。 碰到「放大之后某个东西行为怪异」请直接报。

这个文件只写当前版本。往期更新日志在仓库的 ProjectEden/CHANGELOG-history.md： https://github.com/RobertWangWang/dysonsphereprogram-ProjectEden/blob/main/ProjectEden/CHANGELOG-history.md