Chunk-Pregenerator

非常易于使用：
Chunk Pregenerator 拥有许多让用户使用起来非常方便的功能，例如：
每条命令都有完整的文档说明，
根据需要对命令参数提供自动补全和建议，
改进日志系统，使用颜色和结构化格式清晰展示当前发生的事情，
可选的 UI 功能，比纯文本更易于使用。

多线程世界生成：
Chunk Pregenerator 使用多个核心来生成一个维度，
这是通过巧妙管理 Minecraft 的后台世界生成器实现的。该生成器本身支持多线程世界生成，但默认不会自动启用。
由于各个生成步骤可以相互独立地处理，这能够显著加快世界生成速度。

多世界生成：
Chunk Pregenerator 不再由服务器线程生成区块，而是仅在服务器线程中管理区块的生成位置和顺序。
这样便可以同时生成多个维度，而不会影响彼此的世界生成速度，前提是服务器拥有足够的线程。

预生成期间仍可游玩：
Chunk Pregenerator 专为游戏运行期间使用而设计。
世界生成是一项高强度的 CPU 任务，但由于它在后台线程中运行，因此可以在后台进行。
不过，这只有在提供足够资源时才适用，否则可能会影响游戏体验。

改进的区块生成检查：
Chunk Pregenerator 采用了更加优化的区块检查方式。
这种检查比普通检查快得多，但由于可用信息有限，准确性也相对较低。
此外，较慢的检查会在后台线程中执行，因此不会影响游戏体验，并且可以随时进行或中断。

非常高效的内存管理：
Chunk Pregenerator 并不是盲目地生成区块。
它还会管理自身的内存使用情况，跟踪内存泄漏，并在必要时为 Minecraft 进行清理。
这并不完美，也无法处理其他模组造成的问题，但它能够在不引发问题的情况下，抑制 Minecraft 中已知的内存泄漏。
除此之外，预生成任务也经过了优化，其占用资源已经低到几乎不会对正常的世界生成造成影响。

重新生成：
Chunk Pregenerator 现在是 1.14 及更高版本中少数支持重新生成的模组之一。
这是通过重新创建世界生成步骤本身来实现的。
由于区块已经完全整合到世界中，该过程有一部分会在主线程上运行，因此会对服务器性能产生影响，但影响远小于普通的世界生成。

集成式分析器（1.12 或更早版本）：
Chunk Pregenerator 集成了一个基于 UI 的分析器，可以实时查看世界中正在发生的事情。
它还会提供区块更新、区块刻、活动中的方块实体/实体，以及哪些对象正在刻更新、哪些没有刻更新等信息。
这些操作同样只会在网络线程上执行，这意味着即使服务器本身卡住，也可以获取相关信息，而不会被一同卡住。

维度控制（1.16 或更高版本）：
Chunk Pregenerator 支持在游戏运行期间禁用或启用维度。
这项功能非常实用，因为维度不再能够自行卸载，并且会占用少量资源。
通常这并不是问题，但如果某个模组提供了创建大量维度的方式，而这些维度只会被使用几次，之后便被忽略，就可能造成额外且不必要的卡顿。

维度专属种子（1.19 或更高版本）：
Chunk Pregenerator 允许你为每个维度设置种子，包括模组添加的维度。
你可以在服务器配置文件夹中的 “pregen_seeds.json” 里进行配置。

本节适用于任何 Minecraft 版本。如果某些内容仅适用于特定版本，我会特别注明。
由于我多次被问到超大规模世界生成的问题，而且每次遇到这类请求时都要重复相同的警告，所以我决定把它们统一写下来。
这些警告仅针对原版，模组会大幅加剧这些问题。因此，如果你读到了这里，请务必考虑清楚模组实际上会增加多少内容。（结构类模组是其中一个特别需要注意的问题）

假设你想生成大于250区块或4000格半径的世界，比如1500区块半径甚至更大。作为玩家或服务器所有者，你需要处理好一些事项，以确保最终不会得到损坏的世界，或是因为世界占用过多内存而变得无法游玩。遗憾的是，Minecraft 的每个游戏版本中都存在一些内存泄漏问题。

首先需要知道的是：超大规模世界生成需要时间。
如果你在原版中生成一个1000区块半径的世界，可以确定这将耗时24至48小时。如果扩大到2000区块半径，耗时至少会变成4倍。但通常由于需要处理的数据量增加，耗时会达到8倍。因此，2000区块半径的世界很可能需要一周时间。具体耗时取决于整合包，可能会变成10倍、50倍，或仅增加到1.2倍。
如果你选择最大半径（25000区块半径），这将需要一整年。而且这还不是使用默认设置的情况——我的意思是在你能找到的最优化设置下，也需要整整一年。这一估算基于 i5-7500 CPU。
它不是最强的 CPU，但与服务器 CPU 相比已经相当快了。

接下来需要注意的是：确保有足够的存储空间。
我有一个 1.16.5 版本的小型世界（主世界150区块半径，下界100区块半径），即使是在非常轻量的世界生成类模组环境中，也已经占用了700MB。预生成甚至没有明显受到这些模组的影响。
所以，如果将这些数值翻倍，那么300区块半径的主世界和200区块半径的下界就已经会占用2.8GB。如果使用1000区块半径，那么仅世界本身很可能就会占用三位数的 GB 空间。（使用模组后情况会更糟）
请务必提前做好准备。如果你要进行足够大规模的世界生成，至少要预留1TB的可用空间。这只是一个建议；如果你有更好的判断，就按你的方案来做。

接下来是：不要从最终地图开始。
如果你要进行大规模预生成，不要直接从你最终想游玩的地图开始。请先使用相同的种子创建一个较小的测试地图，观察运行效果。比如先进行半径 300 区块的生成，看看会出现什么问题，因为如果在生成到 75% 时出现问题并导致地图损坏，你会浪费大量时间；而进行一次 24 小时的生成测试反而能减少损失。更棒的是，Chunk pregen 还支持扩展生成范围。因此，通过逐步生成，你可以及时发现问题并进行修复。这个过程会更慢，但你需要了解游戏需要什么才能保持稳定运行。
你也可以选择冒险一点，直接开始并祈祷一切顺利，但在这种规模下通常不会如此。即使如此，半径不超过 300 个区块通常也是安全的；虽然会出现一些内存占用影响，但对于 4–5GB 内存的配置来说，通常不会严重到造成问题。

接下来是：记录结构文件，尤其是废弃矿井（仅限 1.12）
在 1.12 或更早版本中，结构会被全局存储。这意味着它们始终会被加载。通常来说，如果结构数量不多（少于 100 个），这并不是问题。但问题在于，废弃矿井会在各处生成，而且数量非常多。
不过，为什么这是个问题呢？“废弃矿井文件只有 500KB 大小”（举例来说），对吧？问题在于，Minecraft 不仅会全局存储它们，而且还会存储两份。没错，是两份。一份是供游戏使用的格式，另一份则是未压缩的 NBT 格式，用于加快写入速度。这就造成了问题，因为原始文件的压缩率极高。所以，500KB 的文件可能已经占用 1.5–3GB 的内存。这种压缩率非常高。“data”文件夹中的所有文件都经过类似压缩。因此，如果你发现某些文件大小异常，这可能就是内存占用过高的原因，因为它们会被全局存储在内存中。（不过，模组通常只会像结构那样存储一份，而不是两份。）
那么要如何解决呢？对于原版结构，你可以直接删除这些文件，只要确保服务器当时没有运行即可。唯一不再正常工作的功能是“locate”命令，因为它实际上会使用这些文件。你只需要删除那些过大的文件即可。比如，KB 数值低于三位数的文件通常可以保留。如果你担心会导致问题，可以先将它们重命名进行测试。
不过，对于原版结构，请务必持续关注废弃矿井文件。另外，对于添加结构的模组，根据具体实现方式，它们也可能存在同样的问题。Reconcurrent complex 会将其所有结构存储在一个文件中，而这个文件通常很快就会变得非常大。

最后一点：你需要维护预生成内容。
没错，你不能只是启动生成然后等它完成，还需要持续关注进度。比如，在你不睡觉的时候，应该始终保持聊天信息窗口打开。
因为一旦出现问题，你需要及时知道。在 1.12 中，Chunk pregen 设有故障开关，会直接关闭游戏，以确保存档文件保持安全。在 1.14 及更高版本中，这类机制几乎还不存在，因为 1.12 的问题已经被分散处理，不再能够影响主游戏。
但总的来说，如果你不关注预生成过程，而某个未经检查的问题导致地图损坏，那么大多数情况下你只能从头开始。

这份列表总结了我一直提醒大家注意的、大规模生成中最常见的问题。（半径超过 300 个区块，即地图直径约 10,000 个区块）
希望这些内容能帮助你准备好尽可能多的事项，并将所有这些因素纳入考虑。

如果你想提交展示内容，它会被插入到这里：

 

Spotlight Bears Den（版本 3.0.3）：

Spotlight Bears Den 预览（版本 3.0.3）：

作者：Bears Den（版本 2.0）：

作者：Goshen（版本 1.9.0）

 

Amidst 与 JourneyMap 使用技巧（版本 1.9.2）