太格雷科技化；尚未游玩

请务必阅读随包附带的 POST-INSTALL.txt 文件，手动添加仅在 Modrinth 上发布的模组

并查看下方描述的末尾部分，了解如何为本整合包正确配置 Java

作者希望我们并不缺少免责声明：我此生从未编写过任何一条 ChatGPT 提示词，也从未使用过任何其他类似工具。 本整合包 100% 不含任何人工智能生成痕迹 ，其中可能存在的任何问题均由作者个人手动操作造成，并由我全权负责。感谢您对此事的关注。

将时间倒回至 2022 年年中：Minecraft 1.19 刚刚发布，而 GregTech 却严格限定于 1.12 及更低版本。唯一接近的例外是《现代工业化》（Modern Industrialization，简称 MI），尽管其相比 GregTech 更加精简、大幅简化。将 MI 与《机械动力》（Create）结合的想法颇具吸引力，因为它能让玩家尽早开启自动化进程，从而取代手动制作大量小型部件的繁琐流程。MI 还采用原版风格的矿脉——以小型矿脉形式零散分布于世界各处，这种设计完美契合 Minecraft 1.18+ 的世界高度扩展与巨型洞穴系统；后期则可借助自动化采石机无限产出全部资源。 一种受《异星工厂》（Factorio）启发的工业自动化体验。

我的核心构想是构建一套全新的定位式采石机系统，使其在游戏前期即可获取，并通过多级升级不断拓展功能；同时将 GregTech 各版本及一些鲜为人知、高度专业化的整合包中最复杂的生产链，择优移植至现代版本。此举旨在为 MI 增添更多“体量内容”，并为其所蕴含的深度复杂性与物流挑战提供充分理由与支撑。

版本说明 ：当前共有两个活跃版本——“光照提速”（Lightspeed）与“梦魇”（Nightmares），何乐而不为？

• 梦魇版： 作者主要进行生存测试的版本。请注意，该版本 对硬件性能要求极高 ，主要体现在 CPU 与内存方面，而非显卡性能。目前版本已趋于稳定，经过了大量时长的实际测试。受限于整合包本身的性质以及作者个人作为玩家的习惯，通关并持续优化耗时极长 （期间作者已死亡逾 450 次……） 。本版本在 Fabric 端集成了大量模组，而精简版中未包含的模组大多尚未完成适配与调整，因此呈现出更混乱、更“大杂烩”式的特征。 请下拉至本页底部，查阅该版本的 Java 配置说明。
• 光照提速版： 本版本专为降低硬件运行压力而设计，在运算性能与内存占用两方面均更为友好，整体问题更少，属于轻度模组化体验，但仍完整保留了所有必需的自动化功能。模组总数显著减少，但进度路线完全一致，仅移除了部分严苛且恶劣的生存要素。

《格雷式类比》（Gregorian Anagogy）——即 1.20+ 版本的暂定名称——目前已处于 暂停开发 状态。我当前计划在 1.19 版本上全面测试本整合包的进度节奏与平衡性，力求实现从开局到终局的全程稳定运行。迁移至 1.21+/NeoForge 的可能性极低，目前尚无相关计划；但在我完成《格雷式梦魇》后，很可能会回归 1.7 版本的 GT6/HBM/Reika 体系。

本整合包最初基于 《渐进式工业》 （Incremental Industries）进行分叉开发（已获作者许可）。早在 1.18 版本时期，它便是首次尝试重构进度体系、整合《机械动力》与《现代工业化》的轻量级纯科技向整合包。近期， 《态技工业》 （StaTech Industry）成为一款广受欢迎且完成度极高的整合包，拥有出色的任务书，覆盖范围更广，甚至纳入了一些魔法类模组。另一方面，《机械动力》在此包中多为可选内容，模组间经精细调校以协同运作，但并未大幅偏离其原始配方与既定进度路线。

而本整合包则是一场更为狂野（也粗糙得多）的实验，旨在打破常规、彻底重塑进度逻辑。它是作者个人的试验场，用以自由验证各种创意，不受约束、不讲常理。我并非刻意追求原创或创意，我的主要工作是研习新旧（乃至非常古老）的各类整合包，复用其优秀理念，并将其重新熔铸为这座庞大、扭曲的“弗兰肯-格雷-斯坦”式巨构。

本整合包当前定位： 它始于《渐进式工业》的脚本与进度体系，融合了《机械动力》与《现代工业化》……再随意倾倒进一大锅“大杂烩”模组。作者已移植了部分 GregTech 中最复杂的加工链，相关工作仍在持续推进。如今，MI 与 Create 均已按“专家级”整合包风格进行了深度修改，涵盖标准原版物品；其内部进度逻辑亦被大幅重构。因此，本项目天然具有“实验性”。总体目标是实现资源获取与生成的便捷化，但以繁复的加工流程与更高的成本作为平衡，从而迫使玩家自游戏伊始便启用自动化。一切常规规则皆可打破，只为探索可能性之边界。整体风格混沌而刻薄，一切尚未定型。任务书正处于被彻底“涂鸦破坏”的进程中。

本包已包含《应用能源2》（Applied Energistics 2），但功能受限，灵感源自《满意工厂》（Satisfactory）游戏机制。玩家可在早期搭建一套完全无线的中心化物品栏，但仅支持向其中导出物品，且只能手动从中提取。这意味着它可用作集中存储方案，却无法通过其本身实现任何自动化。真正的自动化必须依赖完善的物流体系。

长远来看，本整合包旨在打造一款带有 GregTech 风味的“滚动发布”式作品，力求在现有条件下做到极致，奋力对抗日益分裂、彼此割裂的社区潮流。正统 GregTech 体系将继续扎根于 1.12 及更低版本。

详细说明： 本整合包的构思源于我对 GregTech 自 1.4.7 版本 GT2 起至今所有演进历程的研究。新未必优于旧，而回溯过往往往能意外发掘一座座金矿般的有趣创意。我启动本项目，是因为唯有在此处才能实现四大基础构想：

• 全新 1.18+ Minecraft 世界带来的高度扩展。MI 所采用的高频、多样化的原版风格矿脉，实为对 1.4.7 与 1.6.4 时代的致敬——在庞大的洞穴系统中探索，发现丰富资源并以实用方式加以加工。 资源常见易得，加工过程却极为复杂。 游戏前期玩家将大量消耗木材、砂砾、黏土、安山岩与石英。
• 《机械动力》在整合包中已被过度使用，但它却是替代 GregTech 繁琐工具与手工台枯燥作业的理想选择。它能立即引入自动化，而非等待漫长的前置积累；更能消除 GregTech 早期阶段常见的重复性微加工与采矿行为。它以自动化抵消了 grind（刷取/磨砺）。
• 定位式采石机可实现无限资源产出，虽初始速度缓慢，却能在游戏前期即时提供辅助，直至你完成升级并完全依赖它。它们散布于世界各处，尤以不同海拔高度及深邃洞穴内为多。玩家将面临围绕这些无限矿点构建自主专业化工厂的挑战，并通过火车、矿车或管道等物流手段将其统合一体。
• 利用 MI 更加简化、精炼的内部机制，转而将加工链的复杂性与相互交织的依赖关系推向极致。忠实移植自 Technological Journey（技术之旅）及当前 SuperSymmetry（超对称）等更硬核、更专业化 GregTech 版本的配方。同时重写任务书，使其对所有玩家（包括自动化玩法新手）都足够友好，因为 GregTech 最有趣的阶段正是学习过程。

这四大基础构想旨在融合 Minecraft 与《异星工厂》各自最精华的部分：以早期自动化抵消 grind，以节奏舒缓却稳步扩张的方式推进；在玩家熟悉前序内容后，再逐步引入新的复杂元素。

然而，拥有精心设计且正当合理的目标，并不等于已然达成目标。本整合包目前仍十分粗糙且未经充分测试。因此，随着数月来的持续开发，我愈发意识到，要将其真正打造成一款优质、令人满足的作品，尚有大量工作亟待完成；同时，它在底层技术层面也需更多支撑才能最终实现。但这已关乎个人信念——对我而言，工作的意义不在于抵达终点，而在于过程本身是否仍是一场有趣的实验，是否仍让我乐于摆弄各种概念与游戏设计。

项目启动一年后，MI 存在若干硬性问题，无法通过模组自身解决。这实际上需要 Java 编程知识，几乎不可能实现，也因此成为诸多丑陋设计的根本原因——除非直接分叉修改该模组本身。一年前项目启动时，我曾期望途中能获得协助；如今作者已深知这不会发生。因此，这些残酷的现实将从根本上阻碍本整合包达到我所认可的“良好设计”基准线。当前问题清单如下：

• 原始的无限矿脉构想需支持单个无限节点生成大型矿脉，而 KubeJS 完全无法实现此功能。
• MI 中的机器等级/外壳仅为外观装饰，不具备实际功能。相关支持虽已存在，但开发者拒绝启用。机器升级必须与外壳系统绑定，否则该系统极易被利用，导致精通者跳过大部分进度流程。
• 物品/流体可通过关闭插槽直接在机器内销毁，且配方仍会正常运行。此外，也无法通过配方优先级实现某些有趣的机制（此为次要问题）。
• 能量配方无法修改以添加副产物，例如废燃料或需导向烟囱的物质，甚至无法在源头进行合并。
• 插槽过滤功能将解锁大量新机制。其实现简单，仅需视觉上分离插槽，其余一切保持不变。
• 需支持设定机器超频容量上限，以便精确计算与规划特定配比。
• 需限制多结构体（multiblock）中仓门（hatch）的等级，防止愚蠢的滥用漏洞。
• 许多玩家抱怨管道失衡：流体管道无流量上限，使其成为运输“能量”的绝对最优解。
• 所有阻碍有意义自定义的组件：升级模块、电缆与管道均为硬编码。
• 蒸馏塔（distillation towers）与蒸馏器（distilleries）均无物品输出接口。蒸馏器可定制新机器替代，但蒸馏塔具备独特机制，单独创建多结构体将丧失全部原有行为。
• 无法修复一个缺乏进度设计的模组。例如，若所有流体储罐功能完全相同，则实践中仅有最廉价的储罐会被制造。
• 若能在多结构体所用方块激活时添加动态贴图覆盖层，将十分理想。

本整合包采用 MIT 开源协议，沿用自《渐进式工业》，就我而言，玩家可自由进行任何操作。 CurseForge 信用系统将保持禁用状态 。我的目标并非标新立异，而是实验有趣的理念。我所做的工作建立在前辈们的成果之上，因此请谨记：即便你获得了我这边的完全授权，某些内容可能仍自带其原有的法律约束与授权条款。

本整合包的进度体系 未经测试 。目前已手动逐条添加了约 170 360 420 450 700 1000 + 条配方（仅统计化学与加工链部分）。工作初期主要以 TJ/Gregicality 为基底，辅以部分 Nomifactory 与 GTNH 配方，现正转向以 SuperSymmetry （SUSY）为主要参考与架构。当前内容包括：

• GT6 风格矿石加工（自动化采石机矿石）
• 早期黄金线（TJ）
• 完整铂族金属线（TJ/GTNH 配方一致性）
• 高难度氨气线（TJ 中为可选项）
• 低压（LV）阶段现需镀锌钢，即以液态锌镀覆的钢材（源自 GT6）
• 环氧树脂（Epoxy）＞ 已按当前 SUSY 配方重做
• 石化工程重制（将尽力同步 SUSY 更新）
• 更复杂的铁 / 钢 / 铝 / 不锈钢 / 铬 / 银 / 钨 / 锰 / 钼等副产物（均源自 SUSY）
• 复杂的钛与钨钢线（TJ，跳过环节更少）
• 钒线（已从 Nomifactory 硬核模式中移除，此处予以保留）
• 从乙烯至聚四氟乙烯（PTFE）＋SUSY 调整，含糖/乙醇（替换 MI 原有部分）
• 长链铟线（TJ）
• 全套钠夸达（Naquadah）至合金阶段（仅缺 UHV 部分）。整合并适配了 Nomi 硬核模式的部分内容，使原本三条独立产线现已融合为同一巨型工艺流程。
• 聚苯并咪唑（Polybenzimidazole）（TJ & GTNH）＞ 已完全基于 SUSY 重做
• GTNH 独居石（Monazite）与氟碳铈矿（Bastnasite）产线
• 塔拉尼姆（Taranium）后期加工线（TJ，全部配方均已存在，但缺少若干催化剂，且当前暂未接入进度体系）
• 铌-钽（Niobium-Tantalum）加工线（SUSY，当前暂未接入进度体系）
• 全部 8 种电弧炉（EBF）线圈（最高至 Tritanium），已更新至 CEu 2.8，配方难度相较其他 GT 版本有所提升，静待 SUSY 进展
• 定制铼（Rhenium）线（当前任一公开 GT 版本均未包含，由 PCM/Schroedinger 定制，共 50 条配方）
• 更多……

部分定制机器的材质贴图取自 Jimbno，未经审慎挑选与粗略编辑，仅作临时占位之用： https://github.com/Jimbno/UU-Tex/

当前版本包含黏土采石机及配套的泥坯蒸发槽，相关代码/脚本/配方均由 Rasm 完成。

最后，一条更私人的备注：在开发过程中，我惊讶地遭遇了远超预期的公开敌意与毒性氛围，而非本应出现的合作协助与支持。

前沿尖端 —— Java 25 （更新于 2026 年 5 月 11 日）

本部分内容关乎榨取极致性能。新版 Java 原生支持 ZGC（Z Garbage Collector），作者将采用此方案。ZGC 本身并不直接提升性能，但它支持分配超过 8GB 内存，因此对于因部分模组臃肿而极度吃内存（尤其进入世界时）的 HEAVY 版本 极为有用。

Oracle 官方 Java 25 Windows 版下载直链（请注意版本号每数月更新一次，最新版为 25.0.3+9.1 ，发布于 2026 年 4 月 21 日）： https://download.oracle.com/graalvm/25/latest/graalvm-jdk-25_windows-x64_bin.zip

其他版本与发行说明地址： https://www.graalvm.org/downloads/

（Oracle 近期已终止 GraalVM 支持，但当前它仍是性能表现最佳的选择。）

启用 ZGC 需使用以下特定 JVM 参数（仅适用于 Java 24+，因其支持“紧凑头”（compact headers））：

-XX:+UnlockExperimentalVMOptions -XX:+UseZGC -XX:+UseCompactObjectHeaders -XX:+AlwaysPreTouch -XX:+ExplicitGCInvokesConcurrent -XX:+ClassUnloadingWithConcurrentMark -XX:+UseStringDeduplication -XX:+OptimizeStringConcat -XX:-OmitStackTraceInFastThrow -Dfml.readTimeout=200 -Xlog:gc+init -Dchipped.datafixers=false

ZGC 目前在 8GB 与 12GB 内存配置下均表现出色。若运行 LIGHT 版本，请将最小与最大内存均设为 8192 MiB；若运行 HEAVY 版本，建议将两者均设为 12288 MiB。

请注意：若运行 HEAVY 版本并将内存设为 12GB，则玩家的系统总内存应至少为 32GB。这是因为所设数值仅为 JVM 基础分配量，游戏实际内存占用通常会超出该值至少 20%；此外还需为操作系统及其他进程预留空间。若系统总内存为 16GB，请将启动器设置保持在 8GB，或可尝试 9GB 或 10GB 进行测试，但切勿超过此限。

在 Prism 等启动器中设置 Java 版本时，请务必启用“ 跳过 Java 兼容性检查 ”选项，否则玩家将只能使用 Java 17。