原版体验

Vanilla Like Experience

厌倦了那些名为 Vanilla 或 Vanilla+ 的服务器？ 它们多半运行在 PaperMC 核心上。 它们一点也不原版。

我基于 Fabric 核心搭建了一个真正原版的服务器。 Fabric 本身不改变原版机制——它只是提供了一个服务器修改层，不会严重干扰红石机制和生物生成速率。

我做了一个玩家无需下载的整合包。 所有模组仅在服务端运行，在不干扰游戏体验的前提下提供最高性能。

我的整合包与其他整合包有何不同？

当你下载 Vanilla-Like-Experience.mrpack 时，你得到的不仅仅是一堆模组。 你得到的是一个预先配置好、开箱即用的服务器环境。

我没有把一堆模组堆在一起然后祈祷它们不会破坏原版，而是只收集了针对真实问题的精准解决方案：区块生成、网络、内存、安全。

重点在于：没有任何一个模组触碰原版机制。 红石、生成速率、生物行为——一切都和原版一样。

如何安装？

.mrpack 是一种现成的整合包格式。 本质上，它是一个可以用 7-Zip 或 WinRAR 打开的普通压缩包。

如果你在本地搭建服务器：

1. 下载 Vanilla-Like-Experience.mrpack
2. 将它拖入任何支持 .mrpack 的启动器：Modrinth Launcher、Prism Launcher、ATLauncher
3. 启动器会自动下载所有模组并将它们放入正确的文件夹

完成。

该整合包专为面板游戏主机托管而构建。

1. 进入 Modpacks 板块
2. 安装 Vanilla-Like-Experience.mrpack 整合包
3. 从以下地址下载 Fabric 服务端核心：https://fabricmc.net/use/server/
4. 通过 文件管理器 将核心移动到 /files 文件夹
5. 启动服务器。完成。

许可证

MIT——一切开放，一切透明。

处理器

以下是我用于测试整合包的测试平台。

重要： 对于高玩家数，我建议设置 simulation-distance=4 和 view-distance=10。 在默认设置下，可承载的玩家数会更低。

内存

得益于 FerriteCore 模组，整合包对 RAM 的消耗较为适中。

重要： 请务必使用 Chunky 模组预先加载区域

实际情况： Ryzen 9 7950X 在 9 GB RAM 下承载了 50 名玩家。但为了可靠性，我推荐 12 GB。

存储

世界大小计算器： https://onlinemo.de/world 在预生成之前，使用此网站计算你世界的准确大小。

最终最低要求

该整合包也能在较弱的硬件上运行。 主要限制在于单核频率，而非线程数量。 RAM 相对不那么关键——关键在于处理器能够胜任。

安装模组： https://modrinth.com/mod/immersive-optimization

Minecraft 的基本规则是一切都在单线程上处理。 服务器必须每秒更新一切 20 次。一个更新周期就是一个刻（tick）。 矿车、漏斗、生物 AI、生物农场和红石机制。 所有这些加在一起必须每一刻都进行刻更新（每秒 20 次）。

当玩家出现以下情况时，问题就开始了：

• 建造大型生物农场，数百个实体的生成、死亡和掉落物。
• 探索世界并无意中加载了数百只深藏在地下洞穴中的生物。

这些生物也在不断刻更新，用它们的 AI 和逻辑给服务器带来负载。 所有这些都对服务器主线程造成了巨大负载。

Immersive Optimization 做了什么？

这个模组很聪明。

当一个生物在墙后时——模组给它更少的刻。玩家反正看不到它，所以没必要运行它的逻辑。 当你有数百只动物时——玩家当前正在互动的那些会更频繁地刻更新。 当一个生物在远处时——模组检查距离并让该生物更少地刻更新。 与其在单次刻中处理上千个实体——模组分摊负载：每个轮流刻更新。

为什么我的整合包里没有这个模组？

我的整合包旨在提供最大化的原版 100% 体验。 最重要的是稳定性和可预测性。

Immersive Optimization 做的恰恰相反。 是的，它很强大。是的，它带来疯狂的提升。

但代价是：

• 由于可变延迟，不同区块中的漏斗以不同速度运行。
• 红石机制的时序会波动。
• 如果你有一个按精确的每刻计算设计的生物农场——一切都会乱掉。

这个模组就是这样运作的。

结论

Immersive Optimization 是一个很棒的模组——只是不适合这个整合包。

如果你重视不计代价的性能——安装它。 如果你重视机制的稳定行为——保持整合包原样。

我选择稳定性和可预测性。

Velocity 是一个代理服务器，让你可以将数十个服务器组合成一个网络。 玩家连接到 Velocity，进行一次身份验证后，即可在服务器之间切换而无需重新登录：

• Fabric——原版
• NeoForge——科技整合包
• Forge——冒险整合包

这让玩家能够无缝切换服务器，无需重新登录。

它是如何工作的？

Velocity 接收玩家，每个服务器上的 FabricProxy-Lite 转发他们的数据（昵称、UUID、皮肤、IP）进一步传递。 没有 FabricProxy-Lite，Velocity 无法知道是谁加入了 Fabric 服务器。 模组链接：https://modrinth.com/mod/fabricproxy-lite

文件夹结构

/velocity/
├── velocity.toml
└── forwarding.secret

/fabric-server/
├── mods/
│   └── fabricproxy-lite.jar
└── config/
    └── FabricProxy-Lite.toml

设置

1. 配置 Velocity

打开 velocity.toml，找到这一行： player-info-forwarding-mode = "modern"

打开 forwarding.secret，复制密钥。你会需要它来配置 Fabric。

2. 配置 Fabric

将 FabricProxy-Lite.jar 模组放入 mods/ 文件夹。 启动一次服务器——config/FabricProxy-Lite.toml 会生成。 打开它并粘贴来自 forwarding.secret 的密钥： secret = "your_key"

3. 启动

先启动 Velocity，再启动 Fabric 服务器。 完成。玩家加入 Velocity → 选择服务器 → 到达 Fabric 时已完成身份验证。

重要

• 代理设置不触碰原版机制
• 一切都在连接层面工作，而非游戏层面

用简单的话解释，不涉及神经网络。 模组是什么，以及我在它们中改了什么。

优化和性能

C2ME (Concurrent Chunk Management Engine) 区块生成为异步工作。减轻主线程负载。

我做了什么： 限制为 2 个线程。 在测试中，过度的多线程产生了相反的效果。 玩家加入时出现峰值，MSPT 不稳定。

globalExecutorParallelism = 2
threadPoolPriority = 3

[noTickViewDistance]
maxConcurrentChunkLoads = 3
chunkSendingSpeedMultiplierPercentage = 150

[ioSystem]
chunkDataCacheSoftLimit = 2048
chunkDataCacheLimit = 8192

[generalOptimizations]
midTickChunkTasksInterval = 100000

Lithium 优化物理、生物 AI 和红石。不干涉游戏机制。

FerriteCore 通过优化数据存储减少 RAM 使用。

VMP (Very Many Players) 在高玩家数下优化实体和网络部分。

Noisium 优化世界生成。

Krypton 优化网络部分。

Async——添加了实体的异步操作。 与 Carpet 冲突。Carpet 改为用于诊断。

保护和安全

AntiXray X 射线防护。压缩包中已包含预配置的配置文件。

EasyAuth 离线服务器的身份验证。

我做了什么：

premium-auto-login=false           # 整合包面向离线游戏
floodgate-auto-login=false         # 暂不计划 Bedrock
vanish-until-auth=true             # 未验证的玩家被隐藏
session-timeout=1800               # 30 分钟——舒适的超时时间

Vanish（由 DrexHD 提供）——已添加。 vanish-until-auth=true 生效所必需。 在数据包层面工作——玩家不会察觉到自己被观察。 也适用于管理。

EasyWhitelist 解决离线玩家的 UUID 问题。 在 Fabric 上，离线玩家没有 UUID（与 Paper 不同）。 命令按昵称而非 UUID 工作。 如果你有正版服务器——请与身份验证一起移除它。

SkinRestorer——切换为手动模式。

原来是： 该模组频繁向 Mojang / Ely.by / MineSkin 发送请求。当皮肤缺失时，会生成一个带有堆栈跟踪的 not found。错误淹没了日志、内存和 Java 的垃圾回收器。结果仅缓存 60 秒——一分钟后一切重复。

现在是：

• 加入时不自动检查皮肤
• 不进行不必要的 API 请求
• 不尝试自行给玩家分配皮肤

如果玩家想要皮肤——手动设置： /skin set <nickname>

管理和实用工具

LuckPerms 权限。为 SimpleVoiceChat 安装。你还可以添加前缀。

TAB 美观的 TAB。在玩家上方显示生命值和延迟。

PlaceholderAPI 用于占位符。

Spark 性能分析。分析服务器上发生的一切。 如果卡顿或 RAM 不足——它会显示问题以及如何修复。

TAB TPS 在 BossBar 中显示 TPS、MSPT 和 PING。

Chunky 区域预生成。 重要： 在主世界和末地预生成 7000×7000，在下界预生成 900 格。 与 C2ME 配合使用——区块生成速度提高 3 倍。

FabricProxy-Lite 如果你使用 Velocity + Fabric 则需要。

语音聊天和表情

SimpleVoiceChat 便捷的语音聊天。

Emotecraft 表情。

PlayerAnimationLib Emotecraft 的库。

DynamicLights——已移除。

原来是： 在 Spark 分析中，该模组消耗了 15.94% MSPT：

ServerFunctionManager.execute() — 15.94%
Commands.executeCommandInContext() — 15.94%
EntityArgument.getOptionalEntities() — 2.68%
EntitySelector.findEntities() — 2.55%

原因： 几乎每个玩家手中总是拿着发光物品——这会每一刻触发该函数。

现在是： 该模组已被移除。玩家自行决定是否需要动态光照（客户端模组）。

库和 API

• Fabric API
• Fabric Language Kotlin
• ForgeConfigAPIPort
• MidnightLib

总结

• 所有模组不改变、不添加、不修改原版机制
• 红石机制和生物生成速率未受影响
• 有 X 射线防护和身份验证
• 语音聊天和表情纯粹为了氛围

Vanilla Like Experience

你也厌倦了名为 Vanilla 或 Vanilla+ 的服务器吗？ 它们多半运行在 PaperMC 核心上。 它们一点也不原版。

我基于 Fabric 核心创建了一个真正的原版服务器。 Fabric 本身不改变原版机制——它只是提供了一个服务器修改层，不会严重干扰红石机制和生物生成速率。

我做了一个玩家无需下载的整合包。 所有模组仅在服务端运行，在不侵入游戏体验的前提下提供最高性能。

我的整合包与其他整合包有何不同？

当你下载 Vanilla-Like-Experience.mrpack 时，你得到的不仅仅是一堆模组。 你得到的是一个预先配置好、开箱即用的服务器环境。

我没有把一堆模组堆在一起然后祈祷它们不会破坏原版，而是只收集了针对真实问题的精准解决方案：区块生成、网络、内存、安全。

重点在于：没有任何一个模组触碰原版机制。 红石、生成速率、生物行为——一切都和原版一样。

如何安装？

.mrpack 是一种现成的整合包格式。 本质上，它是一个可以用 7-Zip 或 WinRAR 打开的普通压缩包。

如果你在本地搭建服务器：

1. 下载 Vanilla-Like-Experience.mrpack
2. 将它拖入任何支持 .mrpack 的启动器：Modrinth Launcher、Prism Launcher、ATLauncher
3. 启动器会自动下载所有模组并将它们放入正确的文件夹

完成。

该整合包专为面板游戏主机托管而构建。

1. 进入 Modpacks 板块
2. 安装 Vanilla-Like-Experience.mrpack 整合包
3. 从以下地址下载 Fabric 服务端核心：https://fabricmc.net/use/server/
4. 通过 文件管理器 将核心移动到 /files 文件夹
5. 启动服务器。完成。

许可证

MIT——一切开放，一切透明。

处理器

以下是我用于测试整合包的测试平台。

重要： 对于高玩家数，我建议设置 simulation-distance=4 和 view-distance=10。 在默认设置下，可承载的玩家数会更低。

内存

得益于 FerriteCore 模组，整合包对 RAM 的消耗较为适中。

重要： 请务必使用 Chunky 模组预先加载区域

实际情况： Ryzen 9 7950X 在 9 GB RAM 下承载了 50 名玩家。但为了可靠性，我推荐 12 GB。

存储

世界大小计算器： https://onlinemo.de/world 在预生成之前，使用此网站计算你世界的准确大小。

最终最低要求

该整合包也能在较弱的硬件上运行。 主要限制在于单核频率，而非线程数量。 RAM 相对不那么关键——关键在于处理器能够胜任。

安装模组： https://modrinth.com/mod/immersive-optimization

Minecraft 的底层规则是一切都在单线程上处理。 服务器必须每秒更新一切 20 次。一个更新周期就是一个刻（tick）。 矿车、漏斗、生物 AI、生物农场和红石机制。 所有这些加在一起必须每一刻都进行刻更新（每秒 20 次）。

当玩家出现以下情况时，问题就开始了：

• 建造大型生物农场，数百个实体的生成、死亡和掉落物。
• 探索世界并无意中加载了数百只深藏在地下洞穴中的生物。

这些生物也在不断刻更新，用它们的智能和逻辑给服务器带来负载。 所有这些都对服务器主线程造成了巨大负载。

Immersive Optimization 做了什么？

这个模组很聪明。

当一个生物在墙后时——模组给它更少的刻。玩家反正看不到它，不需要逻辑。 当你有数百只动物时——玩家当前正在互动的那些会更频繁地刻更新。 当一个生物在远处时——模组检查距离并让该生物更少地刻更新。 与其在单次刻中处理上千个实体——模组分摊负载：每个轮流刻更新。

为什么我的整合包里没有这个模组？

我的整合包旨在提供最大化的原版 100% 体验。 最重要的是稳定性和可预测性。

Immersive Optimization 做的恰恰相反。 是的，它很强大。是的，它带来疯狂的提升。

但代价是：

• 由于可变延迟，不同区块中的漏斗以不同速度运行。
• 红石机制的时序会波动。
• 如果你有一个按精确的每刻计算设计的生物农场——一切都会乱掉。

这个模组就是这样运作的。

结论

Immersive Optimization 是一个很棒的模组——只是不适合这个整合包。

如果你重视不计代价的性能——安装它。 如果你重视机制的稳定行为——保持整合包原样。

我选择稳定性和可预测性。

Velocity 是一个代理服务器，让你可以将数十个服务器组合成一个网络。 玩家连接到 Velocity，进行一次身份验证后，即可在服务器之间切换而无需重新登录：

• Fabric SMP——原版整合包
• NeoForge——科技整合包
• Forge——冒险整合包

这一切让玩家能够无缝切换服务器，无需重新登录。

它是如何工作的？

Velocity 接收玩家，每个服务器上的 FabricProxy-Lite 转发他们的数据（昵称、UUID、皮肤、IP）进一步传递。 没有 FabricProxy-Lite，Velocity 无法知道是谁加入了 Fabric 服务器。 模组链接：https://modrinth.com/mod/fabricproxy-lite

文件夹结构

/velocity/
├── velocity.toml
└── forwarding.secret

/fabric-server/
├── mods/
│   └── fabricproxy-lite.jar
└── config/
    └── FabricProxy-Lite.toml

设置

1. 配置 Velocity

打开 velocity.toml，找到这一行： player-info-forwarding-mode = "modern"

打开 forwarding.secret，复制密钥。你会需要它来配置 Fabric。

2. 配置 Fabric

将 FabricProxy-Lite.jar 模组放入 mods/ 文件夹。 启动一次服务器——config/FabricProxy-Lite.toml 会生成。 打开它并粘贴来自 forwarding.secret 的密钥： secret = "твой_ключ"

3. 启动

先启动 Velocity，再启动 Fabric 服务器。 完成。玩家加入 Velocity → 选择服务器 → 到达 Fabric 时已完成身份验证。

重要

• 代理设置不触碰原版机制
• 一切都在连接层面工作，而非游戏层面

用简单的话解释，不涉及神经网络。 模组是什么，以及我在它们中改了什么。

优化和性能

C2ME (Concurrent Chunk Management Engine) 区块生成为异步工作。减轻主线程负载。

我做了什么： 限制为 2 个线程。 在测试中，过度的多线程产生了相反的效果。 玩家加入时出现峰值，MSPT 不稳定。

globalExecutorParallelism = 2
threadPoolPriority = 3

[noTickViewDistance]
maxConcurrentChunkLoads = 3
chunkSendingSpeedMultiplierPercentage = 150

[ioSystem]
chunkDataCacheSoftLimit = 2048
chunkDataCacheLimit = 8192

[generalOptimizations]
midTickChunkTasksInterval = 100000

Lithium 优化物理、生物 AI 和红石。不干涉游戏机制。

FerriteCore 通过优化数据存储减少 RAM 使用。

VMP (Very Many Players) 在高玩家数下优化实体和网络部分。

Noisium 优化世界生成。

Krypton 优化网络部分。

Async——已移除。 与 Carpet 冲突。现在改用 Carpet 进行诊断。

保护和安全

AntiXray X 射线防护。压缩包中已包含预配置的配置文件。

EasyAuth 离线服务器的身份验证。

我做了什么：

premium-auto-login=false           # 整合包面向离线游戏
floodgate-auto-login=false         # 暂不计划 Bedrock
vanish-until-auth=true             # 未验证的玩家被隐藏
session-timeout=1800               # 30 分钟——舒适的超时时间

Vanish（由 DrexHD 提供）——已添加。 vanish-until-auth=true 生效所必需。 在数据包层面工作——玩家不会察觉到自己被观察。 也适用于管理。

EasyWhitelist 解决离线玩家的 UUID 问题。 在 Fabric 上，离线玩家没有 UUID（与 Paper 不同）。 命令按昵称而非 UUID 工作。 如果你有正版服务器——请与身份验证一起移除它。

SkinRestorer——切换为手动模式。

原来是： 该模组频繁向 Mojang / Ely.by / MineSkin 发送请求。当皮肤缺失时，会生成一个带有堆栈跟踪的 not found。错误淹没了日志、内存和 Java 的垃圾回收器。结果仅缓存 60 秒——一分钟后一切重复。

现在是：

• 加入时不自动检查皮肤
• 不进行不必要的 API 请求
• 不尝试自行给玩家分配皮肤

如果玩家想要皮肤——手动设置： /skin set <ник>

管理和实用工具

LuckPerms 权限。为 SimpleVoiceChat 安装。你可以添加前缀。

TAB 美观的 TAB。在玩家上方显示生命值和延迟。

PlaceholderAPI 用于占位符。

Spark 性能分析。分析服务器上发生的一切。 如果卡顿或 RAM 不足——它会显示问题以及如何修复。

TAB TPS 在 BossBar 中显示 TPS、MSPT 和 PING。

Chunky 区域预加载。 重要： 在主世界和末地预生成 7000×7000，在下界预生成 900 格。 与 C2ME 配合使用——区块生成速度提高 3 倍。

FabricProxy-Lite 如果你使用 Velocity + Fabric 则需要。

语音聊天和表情

SimpleVoiceChat 便捷的语音聊天。

Emotecraft 表情。

PlayerAnimationLib Emotecraft 的库。

DynamicLights——已移除。

原来是： 在 Spark 分析中，该模组消耗了 15.94% MSPT：

ServerFunctionManager.execute() — 15.94%
Commands.executeCommandInContext() — 15.94%
EntityArgument.getOptionalEntities() — 2.68%
EntitySelector.findEntities() — 2.55%

原因： 几乎每个玩家手中总是拿着发光物品——这会每一刻触发该函数。

现在是： 该模组已被移除。玩家自行决定是否需要动态光照（客户端模组）。

库和 API

• Fabric API
• Fabric Language Kotlin
• ForgeConfigAPIPort
• MidnightLib

总结

• 所有模组不改变、不添加、不修改原版机制
• 红石机制和生物生成速率未受影响
• 有 X 射线防护和身份验证
• 语音聊天和表情纯粹为了氛围