All Roads Lead to Rome

配置档：

如果你想直接使用现成配置，现在提供了默认配置档；所有配置档都经过测试，确保不会造成破坏游戏体验的改动。
配置档：LIGHT、BALANCED（默认）、AGGRESSIVE（性能提升最大）、CUSTOM。 

1. 无法到达的目标缓存：当生物对目标进行 A* 搜索耗尽预算仍一无所获时，会在 20 秒内跳过对该目标的重试（LIGHT / AGGRESSIVE 配置档分别为 10 秒 / 30 秒）。只要目标所在区块中的方块发生变化，该缓存条目就会立即清除，因此门和桥能马上正常使用。（括号中的数字分别代表 LIGHT 和 AGGRESSIVE 配置档）

2. 寻路限流：每个游戏刻最多启动 3 次寻路（4 次 / 2 次），以平缓村民在黎明时的寻路高峰；只有实际运行的搜索才会计入次数，被要求等待的生物也不会被视为寻路失败。

3. 搜索深度上限：A* 最多访问 300 个节点（400 个 / 200 个）。失败的搜索在访问 800 多个节点时最消耗 CPU，而村庄里的寻路通常不会超过 300 个节点。

4. 远距离寻路重算：距离所有玩家超过 36 格的生物（48 格 / 24 格），最多每 5 秒（3 秒 / 8 秒）刷新一次寻路。

5. 远距离 AI 游戏刻优化：远处生物的目标选择器，以及闲置或休息中的村民和类似生物的大脑，每 6 个游戏刻才运行一次（4 个 / 8 个游戏刻），并错开执行；移动和导航仍会在每个游戏刻运行，因此行走依然流畅。（与实体剔除兼容，且推荐搭配使用）

6. 村民床铺和工作站重试：原版大约每 12 秒就会无限次重试无法到达的床铺和工作方块，而 ARLR 会逐渐延长等待时间，最长可达 60 秒（40 秒 / 120 秒）；发现新的床铺或工作站时，仍会立即认领。

7. 重复行走寻路：村民找不到通往行走目标的路径时，原版可能会在下一个游戏刻再次搜索同一地点；ARLR 会等待 2 秒（1 秒 / 5 秒）后，才会重试该确切地点。

安全性：

* 位于配置档设定的玩家距离范围内的生物，会使用原版 AI 和寻路刷新频率；其他设置则适用于任何距离的生物。
* 有攻击目标，或在过去 10 秒内受到过伤害的紧急状态生物，不受限流和搜索深度上限影响，也不会因行走寻路而减速或被阻止。
* 水中或熔岩中的生物始终以完整频率运行 AI，确保它们持续游泳，不会溺水。
* 正在处理闲置或休息以外活动（工作、恐慌或模组添加的活动）的大脑，会以完整频率运行；计时记忆也会按时过期。
* 限流不会阻止村民搜索床铺和工作站。

Fabric 用户还可选择安装Forge Config API Port，以在游戏内调整配置选项；否则默认配置档将为 BALANCED。

兼容性

• Lithium会优化不同层面（它降低每次 A* 节点评估的开销；ARLR 则减少 A* 的运行频率和搜索深度），两者可以一起使用。
• 目标选择器钩子使用 MixinExtras @WrapOperation，因此其他模组对相同调用进行封装时，可以顺畅地串联运行，而不会发生冲突。
• ARLR 会注入到PathNavigation.createPath、 PathNavigation.recomputePath、 Brain.tick、 Mob.serverAiStep和 Level.setBlock。

注意：ARLR（之前名为 path finder）会继续获得更新。由于该模组现已稳定，并解决了 Minecraft 中开销最大的功能之一，后续更新会间隔更长，并且只会尝试在现有基础上添加小幅但可靠的改进，以免破坏模组。

问答

问：如果这些配置档都不会破坏游戏机制，它们之间有什么区别？为什么不总是选择 AGGRESSIVE？

A：虽然 AI 逻辑得以保留，但使用 aggressive 这类配置文件最多会让许多行为减慢 2-5 倍，不过这种变化对我们玩家来说其实并不明显，除非你恰好身处一个有着 100 多个村民的地方，并且需要他们每个 tick 都做特定的事情，但在绝大多数游戏过程中你甚至不会注意到这些变化，这也是我推荐选择 aggressive 配置文件而非 balanced 或 light 的原因。

Q：这会不会和其他做同样事情的模组冲突？

A：不太可能，ARLR 的构建目标就是针对其他优化模组通常不会针对的路径，以确保兼容性，但即使真的发生这种情况，你也只会得到重复的调用，性能可能会稍微下降一点。

鸣谢

本模组深受 Pathwright 的启发