輻射口吃去除劑
作者：skyranger-1最後更新：2014-05-25 00:02:071.1M258KB
模組介紹
FOSE是必需的。 改善口吃和/或表現。
輻射口吃去除劑
版本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推薦給我，但還沒有抽出時間去嘗試。
版本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，此設置將無效。
臨界區抑制：（特殊）
注意：自述文件正上方被划掉的部分是為了遺忘，而不是輻射； 輻射有一個等價物，但我還沒有找到它的精確值。 暫時忽略這一點。
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推薦給我，但還沒有抽出時間去嘗試。
本工具由三方[bufftool]提供
立即下载模组
安裝 LagoFast，啟動 Fallout 3 - Game of the Year Edition 並暢玩你喜愛的模組。