本帖最后由 QiguaiAAAA 于 2026-8-2 14:55 编辑
天圆地方 GeoCraft
天圆地方(GeoCraft)是一个致力于通过实现多种地理系统,从而将地理要素融合进 Minecraft 的模组。模组在保证尽可能兼容原版的情况下,尽一切可能通过修改游戏机制,使 Minecraft 世界更加符合真实世界,将真正的地理规律带入 Minecraft。
模组已实现的主要内容有: - 流体物理系统(这是最完善的部分);
- 一个还不是很完善的大气系统,目前还未实现视觉效果、双端网络同步、区域天气系统等功能;
- 土壤系统;
还有许多杂七杂八的特性,具体见下文。
天圆地方仍然处于早期开发中,功能尚不全面,且不保证能够稳定运行,建议在尝试该模组前备份好存档。如遇 Bug 或想要提出建议,请前往模组的 GitHub 页面提出 Issue。 内容
流体物理 Fluid Physics
正如其名,流体物理系统让 Minecraft 中的流体更加真实。天圆地方的流体物理系统受模组 Fluid Physics 和 [WPO] Water Physics Overhaul 启发,包括对标前者的 VANILLA LIKE 模式,和对标后者的 MORE REALITY 模式。如果你不想要流体物理,也可以使用保留原版逻辑的原版模式。模组默认使用 MORE REALITY 模式。
注意,在将要到来的 0.3.x 版本中,VANILLA LIKE 模式和 MORE REALITY 模式将更名为 CLASSIC 模式(经典模式)和 FINITE 模式(有限模式),VANILLA 模式(原版模式)不变。文档后文将以新名称指代这两个模式。
有限模式 FINITE
有限模式是天圆地方默认启用的流体物理模式,其完全改变了流体的流动方式以及视觉效果,原版流体源的概念被新的层(Quanta 或 Layer)概念完全取代,这种基于层的流体存在方式在本模组中也称为有限设计(Finite Design)。在有限模式下:
- 每块流体都是真实且有限的;
- 流体在水平面上会向四周摊开;
- 流体会向低处流动(负密度流体相反),包括竖直流动和(单层/多层)坡度流动(默认禁用);
- 密度高的流体会沉到密度低的流体下方;
- 纳流/排流:被方块填充时,流体会尽可能填充进该方块,并在有剩余的情况下向四周流动而不会消失;
- 土壤系统联动(须启用土壤系统):
- 水(或其它支持的流体)会自发下渗至载流方块(需要注意,这个概念不同于含水方块),或蒸发;
- 大气系统联动(须在维度内启用大气系统以及对应特性):
- 水在地表温度低于 0℃ 时会结冰(受原版方块限制,非满格水会结冰成对应高度的雪);
- 雪、冰会在地表温度高于 0℃ 时融化;
- 下雨时若水汽充足则会随机在地面上生成一片水。
但请注意,有限模式基于的有限设计与原版采用的经典设计(用等级记录流体的流动状态,视觉体积不代表实际流体量的设计)在根本上不兼容,这意味着基于原版流体特性的红石机械、自动化农场都有很大可能失效,并带来新的学习成本。如果你体验过 1.16.5 的 [WPO] Water Physics Overhaul 以及其在 1.20+ 的继任者 Flowing Fluids,或许可以更好理解上文内容。
有限模式实现的流体物理效果,更多请见有限模式资料经典模式 CLASSIC
如果你期望使用流体物理,但难以接受有限模式带来的巨大变革,且期望能有更好的平均性能表现,则经典模式(CLASSIC)或许适合你。经典模式受 1.15.2~1.18.2 的 流体物理(Fluid Physics) 模组启发,它基于原版自有的经典设计(用等级记录流体的流动状态,视觉体积不代表实际流体量的设计),并在此基础上做出了物理化改动,即让流体源能够以符合物理规律的方式移动。具体而言: - 和原版一样,流体源的概念仍然存在;
- 流体源会在可能的情况下向低处流动(负密度流体相反),包括竖直流动和溯源流动;
- 在水平面上会保持原版的行为向四周摊开(坡度流动);
- 密度高的流体会移动到密度低的流体下方。
在性能上,经典模式在瞬时大规模流体流动目前逊色于异步压强系统驱动的有限模式,但得益于其底层基于流体源移动的方式,系统整体可以以极快的速度收敛,从而不会像有限模式一样出现长时间的卡顿。 压强系统 Pressure System
天圆地方为流体实现了一个高性能的 压强系统,用以替代单线程的坡度流动算法。压强系统默认启用,并可以占用 多个独立线程进行 异步计算,因而能够大幅降低大量流体流动时的 MSPT 值 。但由于压强计算需要存储计算数据,因此内存占用在大规模流体流动时会偏高。若开启压强系统,建议 JVM 堆内存分配至少分配 4G,否则可能 GC (JVM 的内存清理机制)会频繁地进行内存垃圾回收。
目前为止,压强系统仅支持 有限模式(FINITE),未来会支持 经典模式(CLASSIC)。
下图展示了一个由循环型命令方块创造的河流,在通过曲折的玻璃洞穴后,从左下方流出形成瀑布。其中压强系统在实现虹吸效应上起到了至关重要的作用。
大气系统 Atmosphere System
模组实现了一个基于游戏数据实时演算的大气系统,称为类地大气系统(Surface Atmosphere System)(游戏内 ID 为 surface)。该大气系统的运行独立于原版的生物群系,仅在初始化时使用生物群系的数据,其余时候会使用实时的游戏数据,这意味着玩家的活动会实实在在改变气候!
需要注意,该大气系统仍处于早期开发,对于特殊情况的模拟(例如空岛)存在较大失真,且有时会出现一些奇怪的情况,也就是 bug。类地大气系统的本质是一个极度简化的气候模型,即使短期内看起来没什么问题,仍然不适合长期游玩。除非你对气候模拟十分感兴趣并愿意进行测试,否则在长期使用该模组的情况下,建议通过配置文件切换到原版大气系统(即基于生物群系数据的静态大气系统)。
没错!除了类地大气系统,大气系统还有多种实现方式(原版大气系统[相当于原版风格],封闭大气系统[密闭且恒温大气]),且支持第三方 Mod 添加更多。未来本模组也会添加更多预设的大气系统。你也可以将某个维度的大气系统设置为 none 以完全禁用大气系统,但请注意一个禁用大气系统的维度不等于一个没有大气的维度。
性质
- 大气加载独立于区块,未加载区块也会加载大气。你可以在配置文件中配置大气加载范围,注意这不一定适用于第三方 Mod 添加的大气系统;
- 本模组提供的大气系统每 60 游戏刻更新一次,称为大气刻。每游戏刻理想情况下只会更新六十分之一的大气,因此大气系统的运行在正常情况下对性能几乎没有影响;
- 你可以在存档文件夹下找到位于 DIMx/atmosphere 的大气区域文件,这是一种用于存储大气数据的二进制文件。如果你有换回原大气系统的需求的话,请记得在更换大气系统时备份里面的文件。
下面的内容均为类地大气系统的内容:
- 水汽会在大气间输送,只有有充足水汽时才会下雨;
- 水的相态变化会影响地面、大气的能量交换。例如,覆雪的地面不仅短波反射率会升高,雪融化也会吸收热量减缓升温;
- 地面热容和反射率会影响地面和大气的温度变化;
- (待实现功能)区域天气系统。
土壤(湿度)系统 Soil (Moisture) System
天圆地方创造了“分层流体承载方块(Layered Fluid Host Block)”,简称“载流方块”的机制,在此之上构建出了土壤水文的模拟和一些其他机制。载流方块背后的 API 是一个关于流体存储和交换的接口,其定义了流体在方块中存储的结构和不同方块间交换流体的基本方式。在定义上,含水方块从集合角度讲是“载流方块”的子集(含水方块 ⊆ 载流方块)。例如:泥土、草方块、沙子都不是含水方块,但都可以透水。楼梯既是含水方块,又应该被认为是载流方块。
土壤系统会带来更新鲜的游戏玩法。例如,由于土壤可透水,在较湿润群系建设地下室成为了一项较麻烦的任务,因为你必须阻止潜在的漏水可能(需要有限模式)。但反过来,具有适宜湿度的沙子将不再容易落下,而是会形成稳定的结构。
在不同水物理模式下,土壤(包括其他载流方块)的表现比较不同。但只有在有限流体物理模式下,大多数土壤水文机制才会生效。
土壤(包括其他多数载流方块)的实现并不是通过添加新方块实现的,而是通过 Mixin 技术拓展了原有方块的方块状态,这意味着尽管本模组现在看起来没有添加任何新的方块,但你并不能随意卸载该模组,否则这些方块将变成空气。因此,如果不打算使用土壤系统,请在存档创建或进入未使用天圆地方的存档前,提前在配置文件中禁用土壤系统,否则你可能需要使用外部工具全局替换方块才能安全地卸载天圆地方。
土壤系统暂时不支持第三方模组添加的土壤,例如 [BOP] 超多生物群系 (Biomes O' Plenty) 中的草方块。目前已有长期的兼容计划。
其他杂七杂八的特性
- 为了让原版客户端也能连接添加了本模组的服务器,模组默认在服务端启用了网络通信修改功能。该功能会修改发往所有玩家的数据包信息,并将拓展的方块状态映射回原版客户端可读取的方块状态,以实现对原版客户端的兼容。但这意味着除了耕地之外,玩家将无法读取其他方块的含水量或其它信息,这会一定程度上提高游戏难度。同时,该机制可能会略微提高服务端发送网络包的性能开销;
- 雪的机制(包括雪块)有大量调整,尤其是在有限模式(FINITE)下;
- 有限模式(FINITE)下若启用土壤系统,则耕地润湿机制有大幅度调整,具体见有限模式的详细资料。
运行要求
该模组要求使用 MixinBooter 作为前置以提供 Mixin 环境。模组可以仅安装在服务端,但在双端安装下可以提供最佳效果。对于 Cleanroom 加载器,无需安装 MixinBooter 前置。
自 v0.2.7 版本开始,天圆地方开始主动兼容 Cleanroom 加载器,并同时发布针对 Forge 和 Cleanroom 的生产版本。请注意,尽管由于 Cleanroom 强大的向后兼容能力,使得天圆地方的 Forge 版本现阶段可以在 Cleanroom 上运行,但模组不保证 Forge 版本能够稳定适配 Cleanroom。若要在 Cleanroom 加载器上使用天圆地方,请考虑使用 CRL 后缀(Cleanroom Loader 的缩写)的生产版本。Forge 后缀的或无后缀的生产版本则是针对 Forge 加载器的。
由于 1.12.2 原版光照系统和渲染管线的限制,若没有进行额外的优化,即使仅有上千流体方块同时更新,光照计算仍会导致 MSPT 值飙升。安装诸如 Alfheim Lighting Engine 等光照优化模组可以解决此问题,并极大提升大量流体更新时的性能。对客户端同理,安装相关渲染优化模组可以缓解大量流体更新时的 FPS 波动,例如 高清修复。
若开启压强系统且启用多线程计算(这是默认配置),并关闭坡度流动算法,大多数情况下对 CPU 的单核性能要求可以降低,但对内存要求会显著提高,建议至少分配 4GB 的最大 JVM 堆内存。另外,压强系统满载时(例如上万流体方块同时更新)会对 CPU 的多核性能造成比较大的压力,因此请确保你的 CPU 拥有比较好的多核性能。如果你的 CPU 有比较多的核心,例如 16 核甚至 32 核,建议阅读性能相关资料以进行配置调优。
你也可以参考 MC 百科相关资料,并通过配置文件调参以调整性能。
兼容性和注意事项
- 一般情况下,模组的流体物理同样支持其它 Mod 加入的流体,但若其它 Mod 的流体重写了流动实现,则其无法具有本模组提供的流体物理效果。好消息是,有限流体物理模式下实现了对沉浸工程中混凝土的支持;
- 模组的有限流体物理实现重写了沉浸工程和工业时代2的泵抽取和流体放置逻辑,你可以在配置文件中对其进行调整;
- 你可以在配置文件中禁用指定流体的物理效果;
- 若启用土壤系统且卸载本模组,则一些通过扩展原版方块而实现的载流方块会因数据值超出原版方块状态范围而无法被识别,从而变成空气。由于这些方块在 Forge 看来仍然存在于注册表,因此卸载天圆地方后进入存档不会触发 Forge 关于方块状态丢失的警告;
- 网络通信修改机制可能会和诸如反矿透插件之类类似原理的 Mod、插件冲突。为避免此问题,你可以在配置文件中禁用该功能。注意!禁用后,若不使用其它 Mod、插件修改网络通信,则原版客户端或其它没有装本模组的客户端同样会无法识别这些拓展的方块状态,从而出现渲染卡顿、光照更新异常、双端不同步等异常情况;
- 若压强系统因多线程实现而出现无法接受的崩溃问题,请尝试禁用多线程或禁用压强系统,并最好将相关崩溃报告发送给作者;
- 该模组目前不兼容 Fluidlogged API。目前兼容工作正在推进中;
- 作者会优先在 MC 百科上更新文档,因此若其他地方(除 Github 源码)有表述与 MC 百科冲突,请以 MC 百科上的内容为准。具体优先级为:Github 源码 = MC 百科 > 其他。英文资料可以在 Github Wiki 上阅读;
Q & A
问:该 Mod 有移植到其它版本的计划吗?
答:暂时没有。
问:还可能加入什么内容?
答:外力作用啊、可再生岩浆等,反正想到什么有趣的地理机制就加什么。目前的计划(大饼)有:
- 流体混合机制(例如不同含沙量等级水的混合);
- 基于本模组拓展的玩法:光伏发电;水力发电;体温、水分系统以及相关的模组联动;
- 水循环的地下部分(地下含水层 [不是真实地形,类似于沉浸工程的矿脉]);
- 基本地质系统(断裂带)。
问:目前的更新计划是什么?
答:见 Github 上的里程碑。
问:会加入新方块、实体等内容吗?
答:会。但若这些新内容无法被映射到原版就有的内容,则会以附属的形式出现,因为加入这些内容会要求客户端也必须安装此模组,这和本模组(目前)兼容原版的目标相冲突。
问:可以加入整合包吗?
答:完全可以!但请注意该模组仍处于早期开发阶段,加入时务必小心。
问:开发附属有哪些注意事项吗?
答:本模组采用 Apache 2.0 协议开源,请在开发的时候注意不要违反该协议,例如引用代码的时候必须注明原作者和来源。另外,该模组仍然处于早期开发阶段,部分 API(尤其是大气部分)可能会发生较大变动,这些变动不会考虑 API 上的向后兼容性。更多详情请见模组的 Github 页面说明。
问:有加入含水方块吗?
答:没有,含水方块会在未来通过兼容 Fluidlogged API 实现。
问:Cleanroom 不是向后兼容吗,为什么需要专门做针对 Cleanroom 的版本?
有三个因素:
- 尽管 Cleanroom 声称 99% 的向后兼容性,但 Cleanroom 仍然会有不能兼容的地方,对于这种地方天圆地方需要专门写适配 Cleanroom 的代码;
- 对于一些热点调用路径,Java 21+ 或 Cleanroom 本身可能提供了性能更好的实现方式;
- Cleanroom 环境也有许多新的 API。
但导致分包的关键因素其实在于 Forge,不然其实可以将所有逻辑打包成一个 jar,无需发布专门针对 Cleanroom 的版本。尽管 Cleanroom 向前兼容,但 Forge 不一定向后兼容,最主要的原因是 Java 8 环境下的 Forge 可能无法正确处理一个同时包含 Java 8 和 Java 25 版本字节码的 jar,从而导致模组加载不完整,进而引发崩溃。因此模组的发布版本分成了 Forge 版本和 CRL 版本,后者在 Forge 的基础上额外包括针对 Cleanroom 平台的逻辑。
|