DeerFolia 是一个基于 Folia 的 Minecraft 服务器核心,它们是由 Mojang 的 Minecraft 服务器核心修改而来。
而 Folia 是由 Paper 修改而来,Paper 核心修复了很多原版 Minecraft 的有趣特性,由于 Folia 直接继承自 Paper,因此也同时继承了这些消失的特性。这也是为什么很多服主选择了 Purpur,不过 Purpur 官方已经明确表示不会基于 Folia 开发一个新的具备原版特性的分支。
- 还原了 刷沙机制(虽然 paper 已支持刷沙,但由于 folia 的特性,paper 的刷沙开关在 folia 是无效的);
- Dynamic Activation of Brain (Pufferfish);
- Async Path Finding (Pufferfish);
- Kaiiju Entity Throttling (Kaiiju);
- Kaiiju Skip Empty Listeners Event;
通过动态调整实体的激活频率,减少了不必要的计算,提升了服务器的性能。
# config/deer-folia.yml
dynamic-activation-brain:
enabled: true
start-distance: 12
activation-distance-mod: 8
maximum-activation-prio: 20enabled:是否启用;activation-distance-mod:递减倍数;maximum-activation-prio:最大停顿(如果设置为20则表示无论多远,每20tick都至少计算一次);start-distance:开始递减的距离;
如果刷怪塔收到影响可以尝试减少
activation-distance-mod或者增加start-distance。 通常情况下,activation-distance-mod推荐设置为 7 或 8,start-distance推荐设置为 12。
引入异步路径查找和相关的机制,提升了路径查找的性能和响应速度。
# config/deer-folia.yml
async-pathfinding:
enabled: true
async-pathfinding-keep-alive: 60
async-pathfinding-max-threads: 20enabled:是否启用;async-pathfinding-keepalive:单个线程最大活跃时间;async-pathfinding-max-threads:用于异步寻路的线程池大小;
线程池本质上为虚拟线程,与cpu物理核心无关。过少的线程池大小可能会对性能提升不明显,过多通常不会有明显的负面影响但是可能会影响java的GC。 推荐
async-pathfinding-max-threads为 10-20 之间。
引入了 Kaiiju 的实体节流机制,提升了服务器的性能。
# config/deer-folia.yml
kaiiju-entity-throttling: true
# config/kaiiju-entity-throttling.yml
ZombifiedPiglin:
limit: 1000
removal: 3000kaiiju-entity-throttling:是否启用 Kaiiju 实体节流机制;limit:实体数量限制,超过该数量后实体每 3 tick 才会被更新一次;removal:实体移除限制,超过该数量后实体最先生成的实体会被逐步移除;
- 克隆本仓库到本地;
- 在终端执行
./gradlew applyAllPatches应用补丁; - 完成后会在项目目录下生成
DeerFolia-server和DeerFolia-api,前者即为源码目录; - 执行
./gradlew createMojmapPaperclipJar,完成后会在DeerFolia-server/build/libs下生成服务器核心文件;
- 修改
DeerFolia-server或DeerFolia-api中的源码; - 在
DeerFolia-server或DeerFolia-api目录中将修改内容添加git add .并提交git commit,填写补丁信息; - 在根目录运行
./gradlew rebuildAllServerPatches,将刚才提交的修改生成为新补丁;
- 在
DeerFolia-server/src/main/java中新增相关文件; - 直接提交
git add .并提交git commit,填写补丁信息即可;
通过将与上游源码无关的新增文件独立开,减少对上游修改 patch 文件的长度使得项目更易于维护。
修改已有的补丁步骤相对复杂:
这种方法的工作原理是暂时将 HEAD 重置为所需的提交,然后使用 git rebase 进行编辑。
❗ 在编辑过程中,除非您 同时 将对应模块重置为相关提交,否则将无法编译。就 API 而言,您必须重新应用 Server 补丁,如果正在编辑 Server 补丁,则必须重新应用 API 补丁。还要注意的是,这样做时任何一个模块都可能无法编译。这不是一个正常的现象,但这种情况时有发生。请给 Paper 官方提交 ISSUE !
- 在
DeerFolia-server或DeerFolia-api目录中执行git rebase -i base,应该会输出 这样的 内容。 - 将你需要修改的补丁由
pick替换为edit然后保存退出;- 一次只能修改 一个 文件!
- 对你需要修改的补丁作出新的修改;
- 使用
git add .添加补丁,再使用git commit --amend提交;- 确保添加了
--amend选项 否则将会创建一个新补丁而不是修改原补丁。 - 此处提交时也可以修改补丁信息。
- 确保添加了
- 终端执行
git rebase --continue应用更新; - 再在跟项目目录执行
./gradlew rebuildPatches生成新的补丁;
如果你只是在编辑一个较新的提交,或者你的改动很小,那么在 HEAD 上进行改动,然后在测试后移动提交可能会更简单。
这种方法的好处是可以编译测试你的改动,而不必弄乱你的 HEAD。
- 修改相应位置源码;
- 提交修改(可以不写提交内容);
- 在
deer-folia-server或deer-folia-api目录中执行git rebase -i base,将刚才的提交移动到你想要修改的补丁提交下方; - 将新提交的
pick修改为如下内容:f/fixup:将你的新修改合并到补丁内,但不改变补丁信息;s/squash:将你的新修改合并到补丁内,并用新的补丁信息替换原补丁信息;
- 在跟项目目录执行
./gradlew rebuildPatches应用补丁更新;
- 修改相应位置源码;
- 提交修改内容
git commit -a --fixup <要修改的补丁 hash 值>;- 如果希望更新补丁信息,你可以使用
--squash替换--fixup; - 如果你不知道要修改的补丁 hash 值,你可以使用
git log查看; - 如果你只知道补丁的名称,你可以使用
git log --grep=<补丁名称>查看;
- 如果希望更新补丁信息,你可以使用
- 执行
git rebase -i --autosquash base,这将会自动将你的修改移动到对应的补丁下方; - 在跟项目目录执行
./gradlew rebuildAllServerPatches应用补丁更新;
- 在终端执行
./gradlew updateFoliaRef更新上游 Folia 修改; - 应用更新的补丁:
./gradlew applyAllPatches。 - 如果存在冲突,解决冲突后执行
git add .将解决完的文件添加到暂存区;- 如果遇到
invalid object错误,可以使用git apply --reject <patch file>手动应用补丁; - 会生成
.rej文件,可在其中查看冲突内容,手动解决冲突; - 完成后删除
.rej文件,然后执行git add .;
- 如果遇到
- 然后运行
git am --resolved继续应用补丁; - 如果存在新的冲突,重复步骤 3 和 4;
- 全部补丁应用完成后,更新补丁:
./gradlew rebuildAllServerPatches。