湮没之影脚本优化

这个模组的目标是通过优化游戏中的脚本来提升性能。
每一帧，后台都会运行数百甚至数千个脚本，处理这些脚本需要消耗大量 CPU 算力。
游戏原版脚本的编写侧重于可读性而非优化，这导致它们的运行速度比实际可能达到的要慢。
可读性在游戏中并无实际益处，因此本模组旨在改进脚本的优化，使其执行时消耗更少的处理时间，从而提升性能。
从功能上看，这些脚本完全保持不变，因此没有任何负面影响。

你可以在这里找到关于该模组的官方讨论：http://www.bethsoft.com/bgsforums/index.php?showtopic=753010

这会提高我的表现多少？

对于大多数运行《上古卷轴 4：湮没》的电脑来说，显卡通常是性能瓶颈。而性能瓶颈决定了帧率高低。不过，在加载新区域时，当游戏需要处理大量 AI 程序包或后台运行许多模组时，CPU 往往会暂时成为性能瓶颈。由于本模组降低了 CPU 的脚本负载，这种瓶颈出现的频率会降低，严重程度也会减轻。

对于大多数电脑来说，这个模组会略微提升《上古卷轴 4：湮没》的整体帧率，但主要的性能提升并不在于帧率。
使用这个模组可以预期的主要性能提升是游戏体验会更加流畅，因为突然出现的 CPU 瓶颈将变得不那么明显，这些瓶颈在游戏中表现为随机卡顿和更长的加载时间。
安装这个模组后，这些影响将会减弱，从而带来更流畅的游戏体验，尤其是当你运行大量模组，或者你的 CPU 性能相比显卡较弱时。

在我的电脑上，通过长时间基准测试发现整体帧率提升了 0.3-0.4。
但这些提升主要出现在原本会出现帧率骤降的场景中。

虽然性能提升幅度不大，但效果相当显著，而且这个模组没有任何缺点，因为脚本功能完全相同，在任何方面都没有质量损失，仅仅是性能得到了提升。

警告

首先，警告，你应该首先加载这个 mod，而不是第二个，绝对要第一个加载，没有任何 mod 应该排在它之前加载，非官方的湮灭补丁也不行，任何 mod 都不行（除了那些不能排在 esp 之后加载的 esm 文件）。每个脚本优化只带来非常微小的性能提升，而这微小的提升远不如其他可能修改脚本的内容重要，比如错误修复就重要得多。（注意这里我指的是 esp 文件，你不能在 esm 文件之前加载这个 mod）。通过首先加载这个 mod，该 mod 对脚本所做的任何更改都会被覆盖，这意味着不会发生任何冲突。

说明

有些人可能不相信重写脚本可以减少 CPU 消耗。因此，这里将解释它是如何实现的，不过需要一些脚本编写经验才能理解。以下是一个脚本优化前后的示例。

之前：

如果计时器 = 0 && 获取阶段 MQ15 == 58 && 奥瑟参考.获取死亡 == 0
    将计时器设置为5
    对玩家说 MQ15Eldamil警告
结束条件
如果计时器 = 0 && 获取任务阶段 MQ15 == 66 && 获取距离 玩家 < 1000
    如果自杀 == 0
        设置计时器以对玩家说MQ15EldamilWarning
        将自杀设置为1
    结束条件
结束条件
如果自杀 == 1 && 获取任务阶段 MQ15 == 66 && 计时器 = 0
    设置任务阶段 MQ15 67
结束如果

优化前，无论发生什么情况，该脚本始终会在 if 语句中检查 9 项内容。这些内容包括：

• 计时器 = 0
• 获取阶段 MQ15 == 58
• OrtheRef.getdead == 0
• 计时器 = 0
• 获取阶段 MQ15 == 66
• 获取玩家距离 1000
• 自杀 == 1
• 获取阶段 MQ15 == 66
• 计时器 = 0

如你所见，这里存在相当多的重复检查，而且有些检查并非总是必须执行的。

优化后，采用以下内容：

如果计时器 = 0
    如果任务阶段 MQ15 == 58
        如果OrtheRef.getdead == 0
            将计时器设置为5
            对玩家说 MQ15Eldamil警告
        结束如果
    否则如果获取任务阶段MQ15等于66
        如果玩家距离小于1000
            如果自杀 == 0
                设置计时器以向玩家 MQ15EldamilWarning 发送消息
                将自杀设置为1
            否则如果自杀 == 1
                设置任务阶段 MQ15 67
            结束条件
        结束如果
    结束如果
结束如果

优化后，脚本不会总是检查所有选项，因为这并非必要。在某些情况下，游戏只会检查一个条件，并且只有在得到特定结果时才会继续。让我们来看看这些可能性：

• 选项 1: 计时器 > 0
  这里只需要 1 个问题，减少 8 个问题。
• 选项 2: 计时器 = 0 && 获取任务阶段 mq15 == 58 || 引用对象.获取死亡状态 == 1
  需要 3 个问题，还差 6 个问题。
• 选项 3: 计时器 = 0 && 获取阶段 mq15 == 58 || 引用对象.获取死亡状态 == 0
  需要 3 个问题，少 6 个问题。
• 选项 4: 计时器 = 0 && 获取任务阶段 mq15 != 58 && 获取任务阶段 mq15 == 66 && 获取距离 玩家 >= 1000
  需要 4 个问题，已有 5 个问题。
• 选项 5: 计时器 = 0 && 获取任务阶段 mq15 != 58 && 获取任务阶段 mq15 == 66 && 获取距离 玩家 < 1000 && 自杀 == 0
  需要 5 个问题，已减少 5 个问题（原需 10 个）。
• 选项 6: 计时器 = 0 && 获取任务阶段 mq15 != 58 && 获取任务阶段 mq15 == 66 && 获取距离 玩家 < 1000 && 自杀 == 1
  需要 5 个问题，问题数量减少（原需 10 个）。
• 选项 7: 计时器 = 0 && 获取任务阶段 mq15 != 58 && 获取任务阶段 mq15 != 66
  需要 3 个问题，还差 6 个问题。

你可以看到它并不关心具体是哪个选项，它只需较少的问题/检查就能确定是否满足特定条件。
脚本编写者会注意到，无论变量如何变化，脚本执行的操作完全相同，但检查次数更少。
而每次检查总是比不检查消耗更多的 CPU 资源。

有趣的是，“timer = 0”几乎总是为假，因此其他检查只需要每隔几秒执行一次，而不是每帧都检查。在旧脚本中，每次检查都是每帧进行的，而现在每帧只需要执行一次检查。

部分检查也更容易执行，“if timer = 0”是一个简单的变量检查，几乎不耗时，而“getdistance player 1000”涉及计算，会消耗更多性能。通过将较重的检查隐藏在较简单的检查之后，可以提高性能，特别是当简单检查几乎从未通过时。

请注意，诸如“if timer = 0 && getstage MQ15 == 66 && getdistance player < 1000”这样的语句在大多数编程语言中会先执行第一个检查，如果第一个条件为假则忽略其他条件。但大量测试表明，《上古卷轴 4：湮没》引擎无论如何都会执行所有三个条件判断。通过嵌套这些条件语句可以解决此问题。更多信息请参见此处的讨论：http://www.bethsoft.com/bgsforums/index.php?showtopic=753010。

安装

只需将其解压到你的 oblivion/data 文件夹中，使用 obmm 或类似工具优先加载它，激活后即可完成。