辐射口吃去除剂

辐射口吃去除剂
版本4.0.7
SkyRanger-1

论坛主题：http://www.bethsoft.com/bgsforums/index.php?showtopic=1069833
TESnexus页面：http://www.fallout3nexus.com/downloads/file.php?id=8886

这是一个FOSE插件，它只适用于FOSE 1.2 beta 1或更高版本。

这只适用于辐射3 1.7版本。




0.内容：
====================================

0.内容
1.概述
2.安装
3.卸载
4.常见设置更改
5.所有设置
6.版本历史
7.这是如何运作的
8.学分



一、概述：


这个插件让辐射3不那么“口吃”，通常感觉更流畅或表现更好。它可以防止或减轻许多与口吃和帧速率相关的问题，并可以降低口吃相关崩溃的频率。有关更多详细信息，请参见第7节：这是如何工作的。

但是请注意，这通常不会修复您的驱动程序、硬件或编解码器的任何问题——如果您有性能不佳的根本原因，这可能不会有太大帮助。

这是遗忘口吃去除器(OSR)的一个端口，用于辐射。到目前为止，它的效果不如最初的遗忘口吃去除剂，但它应该会有所帮助。

这应该兼容一切。唯一需要注意的是，监控FPS的mod将无法准确测量这个插件设置的目标范围之外的FPS（默认为10到30）。事实上，即使仅仅接近FSR目标的FPSE也可能难以测量。



2.安装：
====================================

安装过程为：

1.A.如果你正在安装的FSR版本是一个.zip文件，只需将“数据”文件夹从zip文件拖到你的遗忘文件夹。

1.B.如果您正在安装的FSR版本不是.zip文件，那么您需要将文件sr_Fallout_Stutter_Remover.dll放入Fallout\Data\fose\plugins文件夹中。如果您没有这样的文件夹，请创建它。如果安装了旧版本的FSR，请删除其ini文件（Data\fose\plugins\sr_Fallout_Stutter_Remover.ini）。如果没有现有的FSR ini文件，那么FSR将在下次运行辐射时生成一个新的ini文件，其设置适合您的版本。



3.卸载：


只需从Data\fose\plugins文件夹中删除sr_Fallout_Stutter_Remover.dll文件。
将该文件移动到另一个目录也足够了。



4.常见设置更改
====================================

一般来说，FSR试图有体面的默认设置，这样用户就不需要摆弄它们。但是，在一些设置中，默认值可能不适合您，要么是因为默认值不符合您的口味，要么是因为FSR对您的计算机做出了不正确的假设。

FSR将其设置保存在文件Data\fose\plugins\sr_Fallout_Stutter_Remover.ini中
如果该文件不存在，只需在安装了FSR的情况下启动辐射，FSR将为您的FSR版本生成一个具有默认设置的新文件。如果你在你的设置中搞砸了，或者想恢复到默认设置，只需删除这个ini文件并启动辐射。

您可以在第5节中找到有关设置的一般信息，以及有关每个单独设置的更完整信息。

您最可能想要更改的设置是：

FPS_Management\MaximumFPS：（默认为30，考虑改为0或其他值）
有些人根本不希望自己的帧率受到限制。您可以通过将其设置为0来关闭FPS限制。此外，如果你在玩辐射时的屏幕刷新率不是60赫兹，你可以尝试将其更改为你的屏幕刷新率，或者一半的屏幕刷新率，或者三分之一的屏幕刷新率。如果Master\bManageFPS更改为0，此设置将无效。

Hashtables\bAllowDynamicResizing：（默认为0，考虑改为1）
打开这个可以显著提高大量修改游戏的整体性能/FPS。不幸的是，它可能会导致竞争条件和普遍的混乱，特别是当使用某些fose命令的脚本每帧都在运行时。我试图把出问题的几率降到零，但是...这可能需要更多的工作。同时，此功能默认为禁用。如果Master\bHookHashtables更改为0，此设置将无效。

临界区抑制：（特殊）
默认情况下，FSR抑制了一个特定的关键部分，没有这个部分，辐射似乎工作得更好。还有另一个相关的关键部分，一些用户似乎能够抑制而不会引起问题，但其他用户在抑制时会遇到内部->外部过渡上的CTD或其他问题。那只会对口吃产生很小的改善，所以我通常不建议抑制它，但如果你想的话，你可以。要抑制它，请在ini文件中找到写着“CallerAddress=0x70172A”的行，并在它后面添加一个写着“Mode=5”的新行。请注意，案例在那里很重要...应该是“模式”，而不是“模式”。如果Master\bHookCriticalSections或CriticalSections\bUseOverrides设置为0，则此设置无效。
注意：自述文件正上方被划掉的部分是为了遗忘，而不是辐射；辐射有一个等价物，但我还没有找到它的精确值。暂时忽略这一点。



5.所有设置
====================================

FSR将其设置保存在文件Data\fose\plugins\sr_Fallout_Stutter_Remover.ini中
如果该文件不存在，只需在安装了FSR的情况下启动辐射，FSR将为您的FSR版本生成一个具有默认设置的新文件。如果你在你的设置中搞砸了，或者想恢复到默认设置，只需删除这个ini文件并启动辐射。

请注意，FSR ini文件的格式在FSR的主要版本之间会发生变化——您不应该将FSR版本1的ini文件与FSR版本2等一起使用。在FSR2中，ini文件被组织成类似“SectionName{SettingName=Value}”的部分。特定设置可以被称为SectionName\SettingName，以将其与不同部分中具有相同名称的其他设置区分开来。一般来说，名称以“i”开头的设置是整数值（即没有小数点的数字），名称以“b”开头的设置是布尔值（即0或1），以“f”开头的设置是可能有小数点的数字（即3.14）。有些设置不是以这些字母之一开头的，在这种情况下，可能不清楚正确的值类型是什么。

以下是设置及其当前默认值（可能不是100%最新）：

节：主{}
本节包含一个禁用FSR每个主要子系统的选项，以及一些不属于FSR任何特定子系统的设置。

Master\bManageFPS（默认值：1）
将此设置为0将禁用所有FPS管理内容，使FPS_Management部分中的每个设置都变得毫无意义。

Master\bHookCriticalSections（默认值：1）
将其设置为0将禁用所有关键部分内容，使CriticalSections部分中的每个设置都毫无意义。

Master\bHookLightCriticalSections（默认值：1）
将其设置为0将禁用所有Light CriticalSections部分的内容，使LightCriticalSections部分中的每个设置都变得毫无意义。

Master\bHookHashtables（默认值：1）
将其设置为0将禁用所有哈希表内容，使CriticalSections部分中的每个设置都变得毫无意义。

Master\bReplaceHeap（默认值：0）
将其设置为1将启用堆替换，从而使堆部分中的设置变得有意义。

Master\bLogToConsole（默认值：0）
FSR将各种信息记录到其日志文件中。将此设置更改为1将导致FSR也将该信息打印到控制台。
日志文件是辐射目录中的sr_Fallout_Stutter_Remover.log。每次安装了FSR的辐射运行时，都会创建或覆盖它。

Master\bFix64Hertz（默认值：1）
将此设置为1可以修复辐射中导致“微口吃”的问题。这个问题有时被称为“64赫兹问题”。具体来说，问题是辐射游戏逻辑定时通常以1/64秒的分辨率发生，当vsync受限时，屏幕刷新率通常允许辐射每秒绘制60帧。当帧速率达到最大时，这种组合产生了一种节拍频率，其中每秒4帧的游戏时间是56帧的两倍。FSR应用的修复强制辐射以1/1000秒的分辨率使用时间，而不是1/64秒。

Master\bFlushLog（默认值：1）
这告诉FSR立即将任何日志消息写入其文件，而不是将它们缓冲在内存中。由于磁盘访问次数较多，它可能会稍微降低性能，但它会使与崩溃前不久发生的问题相关的任何消息更有可能成功写入日志文件。

Master\iSchedulingResolution（默认值：1）
FSR将请求Windows调度程序以这么多毫秒的分辨率运行。将此设置为1时，FSR和辐射通常工作得更好。然而，这可能会稍微缩短笔记本电脑的电池寿命。

章节：FPS_Management{}
此部分包含调整FSR如何管理您的帧速率和游戏时间流的设置。

FPS_Management\bAllowSlowMotion（默认值：1）
将此设置为0将防止FSR试图覆盖正常的游戏时间流。在过去，FSR这样做会导致一些错误（最臭名昭著的是附近的NPC死亡细胞转换错误），但这些现在被认为已经被修复了。万一你怀疑可能有问题，你可以用这个设置强制禁用所有FSR游戏时间调整。尽管名字如此，将其设置为0也会阻止FSR快进游戏时间，尽管FSR只在非常罕见的设置和环境组合下尝试这样做。

FPS_Management\MaximumFPS（默认值：30）
这是FSR不允许辐射超过的最大FPS。我通常将其设置为足够高的帧速率，这样我就不会太关心每秒任何额外的帧数。请注意，FSR在这里并不真正处理“每秒帧数”，而是将该值转换为每帧毫秒数，并单独考虑每个帧。如果一个帧完成得太快，那么FSR将导致辐射主线程进入睡眠状态，直到经过正确的毫秒数。将Fallouts主线程置于睡眠状态可以释放资源，供Fallouts后台线程或可能在后台运行的其他程序使用。如果没有东西想使用额外的资源，那么你的CPU和/或GPU将运行得更冷，使用更少的电力。

FPS_Management\MinimumFPS（默认值：10）
这是FSR不允许辐射低于的最低FPS。然而，这不是处理真实的秒，而是处理游戏时间的秒。因此，如果你的电脑真的很慢，你仍然可以有1的FPS，但这会将游戏时间减慢到正常时间的10%，这样游戏时间总是至少有每秒10帧。所有的数字都只是一个例子，基于1的真实FPS和10的最小FPS设置（默认值）。还要注意，像MaximumFPS一样，这实际上是在单帧的基础上工作的，处理每帧的毫秒数，而不是每秒的帧数。
我通常把它设置为我觉得可以远程玩的较低的FPS。这个设置的最大目的是防止当FPS过低时，辐射游戏逻辑变得疯狂。这防止的问题包括不可能的战斗，因为敌人可以在帧之间绕着你跑，搞砸了控制，因为辐射认为攻击键在整个帧内关闭或在整个帧内没有关闭，这可能会导致在攻击意图时发生强力攻击，以及许多其他类似的问题。

FPS_Management\iSmoothFrames（默认值：0）
如果将此设置为0，则“平滑”逻辑不执行任何操作。要打开平滑逻辑，请尝试将其设置为2。然而，报告表明，平滑逻辑并没有多大价值。平滑逻辑旨在防止由口吃和帧速率的其他快速变化引起的各种问题。如果bAllowSlowMotion为0，则平滑逻辑将不起作用。

FPS_Management\iSmoothMode（默认值：0）
这应该是0、1、2或3。如果它是0或1，那么它将启用一些额外的逻辑，试图从时间流中过滤掉口吃事件。如果FPS突然下降，这种逻辑可能会导致游戏时间的总量与实时时间的总量不完全相等。如果是2或3，那么额外的逻辑位被禁用。0/2和1/3之间的差异是一个非常微妙的问题，即哪些帧在它们之间如何重新分配时间。

FPS_Management\iSleepExtra（默认值：2）
FSR将迫使辐射每秒休眠这么多毫秒。这有助于为后台线程或其他进程释放资源，或者稍微降低计算机组件的温度和功耗。主要的好处是，如果某个后台线程正在努力获取主线程占用的特定资源，这可以给它一个偶尔获取该资源的机会。
如果这被设置为-1，那么FSR FPS管理代码将永远不会让辐射休眠——如果FPS超过最大FPS，那么FSR将在空闲循环中浪费时间。不建议使用该模式，因为该模式仅用于测试目的。

FPS_Management\bFPSConsoleSPAM（默认值：0）
这将导致FSR记录完成每个帧所需的时间。它将每帧执行一次，从而产生大量的记录时间。

FPS_Management\iSchedulingParanoia（默认值：1）
此设置以毫秒为单位。它决定了MaximumFPS代码对调度程序的偏执程度。如果该值很高，那么MaximumFPS代码将永远不会休眠，而是在空闲循环中浪费时间。如果该值为0，则MaximumFPS代码将信任调度程序在完全请求的时间恢复主线程执行。一般来说，我会在1点妥协，因为我对调度程序有一点偏执，但仍然允许大量的空闲时间被建设性地利用。

FPS_Management\iHardMaxFrametime（默认值：200）
这以毫秒为单位。人们发现，当我的时间流调整代码在错误的时间放入太大的时间时，奇怪的事情就会发生。坏事。就像，附近的NPC随机死去。该设置通过将FSR允许在正常过程中一次通过的毫秒数设置为绝对最大值来防止这种情况。通常情况下，你会在达到这个限制之前达到最小FPS，但在某些情况下，最小FPS会被免除，以防止副作用，如嘴唇运动与声音不同步，所以这是最小FPS的第二级，我真的是最小FPS。设置得太低会导致对话中嘴唇运动不同步，设置得太高会导致NPC随机死亡等错误。我把200作为一个妥协——它不应该导致嘴唇不同步，除非你的帧率在对话中下降到5以下。如果你正在以低于5的帧速率玩辐射，那么你需要真正的帮助。

节：关键节{}
本节介绍FSR对Fallouts CRITICAL_SECTIONs所做的所有更改。想了解CRITICAL_SECTION对象吗？辐射使用它们来防止它的各种线程意外地杀死彼此。微软为它们提供了代码。辐射使用略有不同的版本，这取决于它运行的Windows版本。你可以在MSDN上读到更多关于他们的信息。

CriticalSections\bEnableProfiling（默认值：0）
如果设置为1，则FSR将记录关于辐射中关键部分操作的时间/性能的信息。这样做会对性能造成很小但很大的影响。FSR将在其日志文件中记录信息。这可能会产生有用的信息，说明为什么你的辐射是口吃或运行缓慢。该信息可能用于调整FSR ini文件的覆盖部分或其他内容。

CriticalSections\bEnableMessages（默认值：0）
如果设置为1，则FSR将记录有关关键部分的一些定时/性能事件的信息。这样做的性能成本很低，但它会使日志文件变得混乱，从而更难在其中找到非关键部分的信息。

CriticalSections\bUseOverrides（默认值：1）
如果将此设置为1，那么FSR将使用ini的覆盖部分中的设置来确定应该对特定的关键部分做什么。

CriticalSections\iDefaultMode（默认值：2）
这决定了FSR如何处理在覆盖列表中没有模式条目的关键部分。
1：它使临界部分处于近似正常的行为。
2：它以吞吐量为代价调整临界区以提高公平性。这可以防止一个线程过多地占用临界区，但可以净速率可以用该临界区完成操作。
3：试图在公平性和吞吐量之间折衷，其中它通常针对吞吐量进行优化，但偶尔会切换行为以针对公平性进行优化。
5：临界区被抑制。抑制关键部分通常会导致辐射崩溃，但通常也会提高性能。不过，某些关键部分可能会受到不同的影响。
6：主线程获得该临界区的优先级。
7：后台线程获得该临界区的优先权。

CriticalSections\iDefaultSpin（默认值：500）
这会影响一个线程在请求调度程序将其置于睡眠状态之前尝试进入临界区的时间，直到该临界区变得可用。理论上，太小的值会导致太多的调度程序开销，而太大的值会导致CPU周期的浪费。我认为500实际上是一个很小的价值。理想值可能会随着内核/硬件线程数量的增加而增加。

CriticalSections\iStutterLevel（默认值：4）
此参数影响临界区模式2切换行为的频率。有关临界区模式2的更多信息，请参见iDefaultMode。较小的数字表示频繁切换，较大的数字表示不频繁切换。理想值应该在3到6之间。

节：LightCriticalSections{}
本节介绍FSR对一类辐射对象所做的所有更改，这些对象的用途与CRITICAL_SECTIONs类似，但重量更轻。

LightCriticalSections\bFullHooks（默认值：0）
如果设置为1，这将打开更完整版本的轻型临界截面挂钩。不幸的是，更完整的版本仍然有缺陷，所以目前默认为禁用。

LightCriticalSections\bEnableProfiling（默认值：0）
如果设置为1，则FSR将记录关于辐射中轻临界区操作的定时/性能的信息。这样做会对性能造成很小但很大的影响。FSR将在其日志文件中记录信息。这可能会产生有用的信息，说明为什么你的辐射是口吃或运行缓慢。该信息可能用于调整FSR ini文件的覆盖部分或其他内容。

LightCriticalSections\bEnableMessages（默认值：1）
如果设置为1，则FSR将记录关于轻临界区段的一些定时/性能事件的信息。这样做的性能成本很低，但它会使日志文件变得混乱，从而更难在其中找到非关键部分的信息。

LightCriticalSections\bUseOverrides（默认值：1）
如果将此设置为1，那么FSR将使用ini的覆盖部分中的设置来确定应该对特定的关键部分做什么。除非启用了完整的LCS钩子，否则覆盖将无效（上面的bFullHooks）。

LightCriticalSections\iDefaultMode（默认值：2）
这决定了FSR如何照亮在覆盖列表中没有模式条目的关键部分。它试图使用类似于临界区的模式编号方案——有关更多信息，请参见上面的CriticalSections\iDefaultMode。根据是否启用bFullHooks，某些模式的行为可能会有所不同。

LightCriticalSections\iDefaultSpin（默认值：500）
这决定了FSR如何照亮在覆盖列表中没有旋转条目的关键部分。它试图具有与临界区相似的含义——有关更多信息，请参见上面的CriticalSections\iDefaultSpin。根据是否启用bFullHooks，旋转的含义可能会有所不同。

LightCriticalSections\iStutterLevel（默认值：4）
该参数影响轻临界区模式2切换行为的频率。有关临界区模式2的更多信息，请参见iDefaultMode。较小的数字表示频繁切换，较大的数字表示不频繁切换。理想值应该在3到6之间。


部分：堆{}
这东西对辐射还不起作用。不要使用。

部分：哈希表{}
辐射包括一堆用于查找各种内容的哈希表。他们使用一个通常很糟糕的哈希表实现，但真正的问题是他们从不调整哈希表的大小。当哈希表过满时，性能会下降。如果哈希表不足，那么可能会浪费一点点内存，并且缓存一致性可能会下降。不幸的是，许多哈希表代码到处都是内联的，FOSE也对哈希表做出了各种假设，我根本不清楚相关的线程模型应该是什么，所以安全地更改它们是相当困难的。尽管如此，我还是有一些哈希表挂钩，它们正在逐渐变得更好。

Hashtables\bAllowDynamicResizing（默认值：0）
如果将其设置为1，那么一旦哈希表过满，FSR将增加它们的大小。然而，调整它们大小的行为充满了问题——它可能会导致崩溃或故障，而我用来防止它这样做的方法可能会导致小的性能中断或其他崩溃或故障。尽管如此，在这一点上，我认为它可能工作得有点体面。

Hashtables\bUseOverrides（默认值：0）
目前没有哈希表重写，指定它们的语法很笨拙，如果输入了错误的值，有可能会默默失败并执行其他操作。不过，这最终会得到解决，允许ini文件指定的钩子进入最重要的哈希表的初始化，使它们以一个合适的大小开始，而不是以后需要调整大小。

Hashtables\bEnableProfiling（默认值：0）
这将监控哈希表，并记录关于它们有多满以及它们被访问了多少的信息。

Hashtables\bEnableMessages（默认值：0）
如果这是1，那么哈希表代码可能会偶尔记录关于它正在做什么的消息。

Hashtables\iHashtableResizeScale1（默认值：2）
Hashtables\iHashtableResizeScale2（默认值：4）
如果bAllowDynamicResizing为1，则iHashtableResizeScale1将确定哈希表调整大小的最小占用级别，iHashtableResizeScale2将确定其新大小将大多少。这两个数字实际上都是应用于2的指数，因此设置3意味着8的因子，设置5意味着32的因子。理论上，将iHashtableResizeScale1减少到1可能会进一步提高性能，因为这会增加更多哈希表的大小。ihasTableResizeScale2可能应该比ihasTableResizeScale1多设置1或2。

Hashtables\ihashtableSizeDelay（默认值：20）
这是调整哈希表大小时FSR将暂停的毫秒数。这个想法是，虽然我不能阻止另一个线程在我忙于哈希表时访问它，但我可以，希望，阻止他们*开始*访问哈希表。所以我延迟了足够长的时间，也许，可能，任何已经访问哈希表的人都会完成，然后我做我的事情。不幸的是，这在FOSE上不起作用，因为FOSE不做辐射做的事情，而且即使做了，它也不使用vtables来做这些事情。但是atm我认为FOSE可能只从主线程访问它们，所以如果我的resizer在主线程中运行，那么它就不必担心FOSE。也许。

部分：覆盖{}
本节包含的信息告诉FSR如何找到FSR知道的各种类型的对象的特定实例，以及如何将这些特定实例与该类型对象的默认设置不同。目前，这里真正列出的只有几个特定的关键部分，它们的行为与大多数不同。



6.版本历史：
====================================

FPS封盖器版本1：
这被称为FPS封盖机。它所做的只是FPS管理。这个版本被集成到一组修改过的OBSE DLL中。

FPS封盖器版本2：
这是第一个拥有独立于OBSE的dll的版本。这被称为FPS封盖机。它所做的只是FPS管理。

遗忘口吃去除器版本3 beta 1：
第一个版本被命名为遗忘口吃去除。有时在主菜单上冻结几分钟。NPC的声音和面部动作会在对话中搞砸。
版本3 beta 2：NPC的声音和面部动作会在对话中搞砸。

遗忘口吃去除器版本3 beta 6：
在beta 5和beta 6之间有很长的延迟，被许多alpha版本所填补。这是第一个真正为普通用户减少口吃的FSR版本。这是因为新特性：临界区公平性调整、临界区抑制和堆替换。不幸的是，堆替换对于许多用户来说仍然存在重大问题。bFix64Hertz在ini中默认设置为0，它应该是1。

注意：从来没有版本3的最终版本。如果有足够的需求，我可以在版本3 beta 6源代码的基础上做一些修正。

辐射口吃去除器版本1 beta 1：
OSR到辐射的初始端口。

遗忘/辐射口吃去除版本4.1.0：
主要变化：
1.在同一代码库中支持辐射和遗忘：在辐射3中没有提供太多的好处，但它确实有帮助。
2..ini文件： 完全不同的ini文件格式
3.哈希表大小调整： 提高性能的新功能
4.临界截面和轻临界截面：概括了关键部分的许多特殊情况，现在可以从ini文件中进行更多的调整。轻临界区代码的“全钩子”仍然有问题。
5.堆替换： 修复了一些bug，但我认为它仍然有问题。对辐射还是不起作用。
6.版本命名：发布到tesnexus的版本现在被称为发布版本，而不是测试版。发布到我的ftp服务器的版本现在被称为beta版本，而不是alpha版本。仅当配置或分发格式发生重大更改时，版本号的第一位数字才会递增。版本号的第二位数字在每个发行版本中递增。对于每个测试版，版本号的第三位数字递增一次。每当一个数字递增时，右边的所有数字都会重置为0。




7.这是如何工作的：


这是一个FOSE插件dll。它基本上是黑客辐射。

7.1：FPS管理：
FPS管理代码监控帧速率并调整游戏时间的流程。它通过使辐射游戏逻辑在口吃时不向前跳来减轻口吃。实际上，需要很长时间的帧最终会处于慢动作状态。这是通过使辐射表现得好像iFPSClamp被设置为MinimumFPS来实现的，但仅限于比MinimumFPS慢的帧。这也可以提高稳定性。它还可以施加最大帧速率——当帧速率被防止超过刷新率的一半时，一些人认为辐射会更平滑，此外，这有助于为辐射辅助线程释放资源。

FPS管理代码还可以让辐射的主线程在短时间内休眠，这被认为可以改善一些人的口吃（尽管这个功能可能被这个插件做的其他事情变得多余）。

7.2：关键部分：
临界区是微软提供的线程同步原语，辐射在内部使用它来确保线程不会意外地相互破坏。默认情况下，FSR使大多数关键部分试图公平竞争，即使以吞吐量为代价，确保没有线程占用其他线程需要的资源。然而，一个特定的临界区被覆盖以使用稍微不太公平的方法，而另一个特定的临界区被抑制以使其完全不起作用。这一切都可以从ini文件中进行配置。旋转计数也会被覆盖。

7.3：堆替换：
这个功能在辐射3上还不能正常工作。

7.4：哈希表：
辐射包括一堆用于查找各种内容的哈希表。他们使用一个通常很糟糕的哈希表实现，但真正的问题是他们从不调整哈希表的大小。当哈希表过满时，性能会下降。如果哈希表不足，那么可能会浪费一点点内存。不幸的是，许多哈希表代码到处都是内联的，FOSE也对哈希表做出了各种假设，我根本不清楚相关的线程模型应该是什么，所以安全地更改它们是相当困难的。

尽管如此，我还是有一些哈希表挂钩，它们正在逐渐变得更好。一旦哈希表过满，FSR就会增加它们的大小。然而，调整它们大小的行为充满了问题——它可能会导致崩溃或故障，而我用来防止它这样做的方法可能会导致小的性能中断或其他崩溃或故障。尽管如此，在这一点上，我认为它可能工作得有点体面。将来，我可能会通过覆盖某些哈希表的初始大小来替换或补充这一点。


====================================
八、学分：
====================================

这个插件是我（克里斯托弗·多蒂-汉弗莱）做的。

如果没有FOSE团队的巨大努力，这是不可能的。此外，伊恩·帕特森（FOSE团队的一员）帮助我度过了很多我遇到麻烦的地方。

最初提示我启动这个插件的线程是由DeviusCreed启动的。

许多测试人员提供了有用的反馈。特别是，mashani关于哪些设置为他产生了哪些结果的信息帮助我理解了为什么早期版本会产生意想不到的好处，并导致了后来版本中的许多特性和设置。

我还要感谢badhair向我指出哈希表过满是性能问题的原因。

在这个插件的制作中使用了以下工具：
《遗忘/辐射》，贝塞斯达著
OBSE/FOSE和OBSE/FOSE源代码
Microsoft Visual C++2008 Express Edition
IDA Free（交互式调试器，免费版，版本4.9）
作弊引擎（版本5.4）
再加上像Windows XP、记事本和火狐这样显而易见的东西。

除了遗忘/辐射和Windows XP，所有这些都是免费的。

我也有Hex Workshop和ollydbg推荐给我，但还没有抽出时间去尝试。