Create项目中的列车调度系统崩溃问题分析与解决方案

问题背景

在Create模组的列车调度系统中，发现了一个可能导致游戏崩溃的严重问题。当计算机模组(CC:Tweaked)尝试为一个没有有效调度表的列车设置调度时，系统会崩溃。这个问题特别容易在玩家使用Lua脚本通过计算机接口操作列车调度时触发。

技术分析

崩溃根源

问题的核心在于currentEntry变量被设置为-1，而系统没有正确处理这种边界情况。具体来说：

1. 当调度表为空时，ScheduleRuntime#setSchedule方法中的以下代码会导致问题：

currentEntry = Mth.clamp(schedule.savedProgress, 0, schedule.entries.size() - 1);

2. 由于clamp方法的实现是：

public static int clamp(int value, int min, int max) {
    return Math.min(Math.max(value, min), max);
}

3. 当调度表为空时，entries.size()为0，导致max参数为-1，最终currentEntry被设置为-1。

调用链分析

正常情况下，大多数调用setSchedule的地方都会进行空表检查，如：

• StationBlockEntity#applyAutoSchedule
• ScheduleItem#handScheduleTo
• BlazeBurnerInteractionBehaviour#handlePlayerInteraction

然而，计算机接口的实现(StationPeripheral)存在验证不足的问题。它虽然检查了"entries"映射表是否为空，但存在两个关键缺陷：

1. 键名大小写敏感性问题：代码检查的是"entries"而非"Entries"，而Create内部使用的是"Entries"（首字母大写）

2. 更严重的是，toCompoundTag方法会将所有键名转换为蛇形命名法(SnakeCase)，导致各种大小写变体("entries", "Entries", "eNtRiEs"等)都能通过解析，但无法通过验证

解决方案

针对这个问题，可以从以下几个层面进行修复：

1. 输入验证强化：在计算机接口中严格验证输入的调度表格式，确保必须包含正确大小写的键名和有效的条目

2. 边界条件处理：在设置currentEntry时增加额外的检查，确保其值永远不会小于0

3. 键名规范化：统一内部使用的键名格式，避免大小写不一致导致的问题

4. 错误处理改进：为无效输入提供更清晰的错误信息，帮助用户理解问题所在

技术启示

这个问题给我们几个重要的技术启示：

1. 防御性编程：即使上层调用应该保证输入有效性，底层实现仍需处理所有可能的边界情况

2. 数据验证：对外部输入（如来自Lua脚本的数据）必须进行严格验证，包括类型、格式和业务逻辑层面的检查

3. 命名一致性：在跨系统交互时，键名/字段名的大小写和格式必须严格一致

4. 错误隔离：一个组件的错误不应导致整个系统崩溃，应有适当的错误隔离机制

总结

Create模组的列车调度系统是一个复杂而精密的机制，这次发现的问题提醒我们在处理外部输入和边界条件时需要格外小心。通过加强输入验证、改进错误处理和确保内部一致性，可以显著提高系统的健壮性和用户体验。对于模组开发者而言，这类问题的解决不仅修复了当前缺陷，也为未来开发提供了宝贵的设计经验。