Oblivion Stutter Remover 4.1.37

Это DLL-плагин OBSE. По сути, это взлом Oblivion.

FPS Management

Код FPS Management отслеживает частоту кадров и регулирует течение игрового времени. Это уменьшает зависания в игре, вынуждая не пропускать игровую логику Oblivion, когда возникают фризы. Кадры, которые занимают много времени, в конечном итоге оказываются замедленными. Это достигается за счет того, что Oblivion действует так, как если бы параметр iFPSClamp был установлен на MinimumFPS, но только для кадров, которые медленнее, чем MinimumFPS. Это также может улучшить стабильность. Можно устанавливать максимальную частоту кадров — некоторые люди воспринимают Обливион плавнее, когда его частота кадров не превышает половину частоты обновления, плюс это помогает высвободить ресурсы для вторичных потоков Обливиона.

Код FPS Management также может переводить основной поток Oblivion в спящий режим на короткие периоды времени, что, как было замечено, исправляет зависания для некоторых людей.

Critical Sections

Критические секции — это предоставляемые Microsoft примитивы синхронизации потоков, которые Oblivion использует внутри себя, чтобы убедиться, что потоки случайно не повреждают друг друга. OSR по умолчанию заставляет большинство критических секций пытаться играть честно даже за счет пропускной способности, гарантируя, что ни один поток не захватит ресурс, который нужен другим потокам. Однако один конкретный критический раздел переопределяется, чтобы использовать чуть менее честный метод, а другой конкретный критический раздел подавляется, так что он вообще не имеет никакого эффекта. И все это очень легко настраивается из ini-файла. 

Heap Replacement

Oblivion использует собственную реализацию динамической памяти (он же менеджер памяти, он же malloc/free), которая, похоже, была написана Bethesda специально для Oblivion. Их реализация ошибочна. В частности, она очень плохо работает с многопоточными рабочими нагрузками, что часто бывает с Oblivion. Этот плагин позволяет заменить диспетчер кучи (heap replacement) Oblivion множеством альтернатив, большинство из которых НАМНОГО быстрее на многопоточных рабочих нагрузках. К сожалению, изменение реализации может привести к тому, что у некоторых пользователей Oblivion станет нестабильным. Я не уверен, связано ли это с ошибкой в ​​моем методе замены или из-за ошибок в Oblivion, которые не приводят к сбою с ванильной кучей Oblivion.

Предлагаемое улучшение производительности велико (уменьшает зависания, сокращает время загрузки, делает некоторые меню более быстрыми, может немного улучшить FPS) для многих людей, хотя некоторые установки Oblivion, похоже, не так многопоточны. К сожалению, из-за того, что замена имеет тенденцию вызывать нестабильность, я на данный момент отключил эту функцию по умолчанию. Однако, учитывая значительный прирост производительности, который многие люди видят при этом, я бы посоветовал пользователям попробовать включить параметр, отключив его только в том случае, если у них возникнут проблемы со стабильностью.

Hashtables

В Oblivion есть куча хештаблиц для поиска чего угодно. Они используют плохую реализацию хештаблиц, но реальная проблема в том, что они никогда не изменяют размеры своих хэш-таблиц, а используемые ими размеры по умолчанию нацелены на игру без модов и часто даже для этого довольно малы. Когда хештаблица переполнена, производительность падает. Если хештаблица не заполнена, часть памяти может быть потрачена. К сожалению, большая часть кода хештаблицы встроена повсюду, и OBSE также делает различные предположения о хештаблицах, и мне совсем не ясно, какой должна быть соответствующая модель потоковой передачи, поэтому безопасно изменить их довольно сложно.

Тем не менее, у меня есть несколько хуков для хештаблиц, и они постепенно улучшаются. OSR может увеличивать размер хештаблиц, когда они переполняются. Однако изменение их размера чревато проблемами - это может вызвать сбои или баги, а методы, которые я использую, чтобы предотвратить это, могут вызвать небольшие фризы в производительности или другие сбои или баги. Тем не менее, на данный момент я думаю, что это может весьма прилично работать. В будущем я могу заменить параметр или дополнить переопределением начальных размеров некоторых хештаблиц.

Master\bReplaceHeap: (по умолчанию 0, подумайте о включении на 1)
Это по-прежнему отключено по умолчанию, потому что некоторые люди испытывают нестабильность при его использовании. Однако включение параметра улучшает производительность. Величина, на которую он повышает производительность, зависит от того, насколько многопоточности пытается добиться ваша копия Oblivion — если она пытается выполнять многопоточность, то эта настройка может привести к действительно огромным улучшениям. Это также помогает при некоторых серьезных проблемах с производительностью, которые возникают в более длительных игровых сессиях при игре в сильно модифицированную игру в Oblivion на Windows XP. Если у вас возникли проблемы с включенным Master\bReplaceHeap, вы можете попробовать разные варианты, изменив Heap\iHeapAlgorithm, который обычно должен быть равен 1, 5 или 3.

FPS_Management\MaximumFPS: (по умолчанию 30, подумайте о включении на 0 или другие значения)
Некоторые люди не хотят, чтобы их частота кадров была ограничена. Вы можете отключить ограничение FPS, установив для этого параметра значение 0. Кроме того, если частота обновления экрана при игре в Oblivion не равна 60 Гц, вы можете попробовать изменить это значение на частоту обновления экрана, половину частоты обновления экрана или одну треть экрана. Этот параметр не будет действовать, если Master\bManageFPS изменен на 0.

Hashtables\bAllowDynamicResizing: (по умолчанию 0, подумайте о включении на 1)
Включение этого параметра может значительно улучшить общую производительность / FPS в сильно модифицированных играх. К сожалению, это может вызвать состояние гонки и общий хаос, особенно когда скрипты, использующие определенные команды OBSE, выполняются в каждом кадре. Я попытался свести вероятность возникновения проблем почти к нулю, но... это может потребовать дополнительной работы. Между тем эта функция по умолчанию отключена. Этот параметр не будет действовать, если Master\bHookHashtables изменен на 0.

Critical Section Suppression: (особые)
По умолчанию OSR выключает один конкретный критический раздел, без которого Oblivion работает лучше. Существует еще один связанный критический раздел, который некоторые пользователи, по-видимому, могут выключить, не вызывая проблем, но у других пользователей могут возникнуть CTD при переходах из интерьеров в экстерьеры.

Это дает лишь небольшое улучшение производительности, поэтому я обычно не рекомендую включать параметр, но вы можете, если хотите. Найдите строку с надписью «CallerAddress = 0x70172A» в вашем ini-файле и добавьте сразу после нее новую строку с надписью «Mode = 5». Обратите внимание, что здесь важен регистр... это должен быть "Mode", а не "mode". Этот параметр не будет действовать, если для Master\bHookCriticalSections или CriticalSections\bUseOverrides установлено значение 0.

OSR хранит свои настройки в файле Data\obse\plugins\sr_Oblivion_Stutter_Remover.ini
Если этот файл отсутствует, просто запустите Oblivion с установленным OSR и OSR сгенерирует новый файл с настройками по умолчанию для вашей версии OSR. Если вы что-то испортили в своих настройках или хотите вернуться к настройкам по умолчанию, просто удалите этот ini файл и запустите Oblivion.

Обратите внимание, что формат ini файлов OSR меняется между основными версиями OSR - вы не должны использовать ini файл OSR версии 3 с OSR версии 4 и т.д. В OSR4, ini файл организован в секции типа "SectionName { SettingName = Value }". Конкретная настройка может быть названа SectionName\SettingName, чтобы отличить ее от других настроек с таким же именем в разных разделах. В общем случае настройки с именами, начинающимися с буквы "i", представляют собой целые значения (т.е. числа без десятичной точки), настройки с именами, начинающимися с буквы "b", представляют собой булевы значения (т.е. либо 0, либо 1), а настройки, начинающиеся с буквы "f", представляют собой числа, в которых могут быть десятичные точки (т.е. 3.14). Некоторые параметры не начинаются ни с одной из этих букв, и в этом случае может быть неясно, какой тип значений является правильным.

Вот настройки и их текущие значения по умолчанию (могут быть не на 100% актуальны):

Section: Master{}

Этот раздел содержит опции для отключения каждой основной категории OSR , плюс несколько настроек для вещей, которые не относятся ни к одной конкретной категории OSR .

Master\bManageFPS (по умолчанию: 1)
Установка значения 0 отключает все функции управления FPS, делая все настройки в разделе FPS_Management бессмысленными.

Master\bHookCriticalSections (по умолчанию: 1)
Установка этого параметра в 0 отключает все критические секции, делая все настройки в разделе CriticalSections бессмысленными.

Master\bHookHashtables (по умолчанию: 1)
Установка этого значения в 0 отключает все возможности Hashtable, делая все настройки в разделе CriticalSections бессмысленными.

Master\bReplaceHeap (по умолчанию: 0)
Установка этого параметра в 1 включит замену кучи (heap replacement), что сделает настройки в разделе Heap значимыми.

Master\bLogToConsole (по умолчанию: 0)
OSR записывает различные биты информации в свой лог-файл. Изменение этого параметра на 1 приведет к тому, что OSR также будет печатать эту информацию в консоль.
Файл журнала находится под именем sr_Oblivion_Stutter_Remover.log в каталоге Oblivion. Он создается или перезаписывается каждый раз, когда Oblivion запускается с установленным OSR.

Master\bFix64Hertz (по умолчанию: 1)
Установка значения 1 устраняет проблему в Oblivion, которая вызывает "микрофризы". Эта проблема иногда известна как "проблема 64 герц". В частности, проблема заключается в том, что синхронизация игровой логики Oblivion обычно происходит с разрешением 1/64 секунды, а частота обновления экрана обычно позволяет Oblivion делать 60 кадров в секунду при ограниченном vsync. Эта комбинация создает своего рода частоту биений при максимальной частоте кадров, когда 4 кадра в секунду проходят в два раза больше времени, чем остальные 56 кадров. Исправление, которое применяет OSR, заставляет Oblivion использовать время с разрешением 1/1000 секунды вместо 1/64 секунды.

Master\bFlushLog (по умолчанию: 1)
Это указывает OSR записывать все сообщения журнала в файл немедленно, а не буферизировать их в памяти. Это может немного снизить производительность из-за большего количества обращений к диску, но повышает вероятность того, что сообщения, относящиеся к проблемам, возникшим незадолго до сбоя, будут успешно записаны в файл журнала.

Master\iSchedulingResolution (по умолчанию: 1)
OSR будет запрашивать у планировщика Windows разрешение на это количество миллисекунд. При установке этого значения в 1, OSR и Oblivion обычно работают лучше. Однако это может немного сократить время автономной работы ноутбуков.

Section: FPS_Management{}
Этот раздел содержит настройки, которые регулируют, как OSR управляет частотой кадров и течением игрового времени.

FPS_Management\bAllowSlowMotion (по умолчанию: 1)
Установка этого значения в 0 предотвратит попытки OSR отменить нормальное течение игрового времени. В прошлом возникали ошибки, связанные с этим (наиболее печально известная ошибка со смертью NPC поблизости при переходе в ячейку), но они, надеюсь, уже исправлены. На всякий случай, если вы подозреваете, что проблема имеет место, вы можете принудительно отключить все корректировки игрового времени OSR с помощью этой настройки. Несмотря на название, установка этого параметра в 0 также не позволит OSR перематывать игровое время вперед, хотя OSR пытается сделать это только при очень редких комбинациях настроек и обстоятельств.

FPS_Management\MaximumFPS (по умолчанию: 30)
Это максимальное значение FPS, который OSR не позволит Oblivion превысить. Обычно я устанавливаю достаточно высокую частоту кадров, чтобы меня не сильно беспокоили лишние кадры в секунду. Обратите внимание, что OSR не работает с "кадрами в секунду", плагин преобразует это значение в число миллисекунд на кадр, и рассматривает каждый кадр отдельно. Если кадр будет закончен слишком быстро, то OSR заставит основной поток Oblivions перейти в спящий режим, пока не пройдет нужное количество миллисекунд. Перевод основного потока Oblivions в спящий режим может освободить ресурсы для использования фоновыми потоками Oblivions или другими программами, которые могут быть запущены в фоновом режиме. Если ничто не планирует использовать дополнительные ресурсы, то ваш CPU и/или GPU будут работать холоднее и потреблять меньше электроэнергии.

FPS_Management\MinimumFPS (по умолчанию: 10)
Это минимальный FPS, ниже которого Oblivion не будет опускаться. Однако, вместо реальных секунд, это значение относится к секундам игрового времени. Так что вы все еще можете иметь FPS равный 1, если ваш компьютер очень медленный, но это замедлит игровое время до 10% от нормального, так что всегда будет по крайней мере 10 кадров в секунду игрового времени. Все приведенные здесь цифры - это просто пример, основанный на реальном FPS, равном 1, и значении MinimumFPS, равном 10 (значение по умолчанию). Также обратите внимание, что, как и MaximumFPS, этот параметр работает на основе одного кадра, то есть с миллисекундами на кадр.

Обычно я устанавливаю минимальное значение FPS, при котором я нахожу игру пригодной для игры. Основная цель этой настройки - предотвратить сбой игровой логики Oblivions, когда FPS становится слишком низким. Это предотвращает такие проблемы, как невозможные бои, потому что враги могут бегать вокруг вас между кадрами, испорченное управление, потому что Oblivion думает, что клавиша атаки нажата на весь кадр или не нажата на весь кадр, что может привести к силовой атаке, когда предполагалась атака, и множество других подобных проблем.

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)
Oblivion будет спать в течение указанного количества миллисекунд каждую секунду. Это может помочь освободить ресурсы для фоновых потоков или других процессов, или немного снизить температуру и энергопотребление компонентов компьютера. Основное преимущество заключается в том, что если какой-либо фоновый поток пытается получить определенный ресурс, который забирает основной поток, это может дать ему шанс получить этот ресурс время от времени.

Если этот параметр установлен в -1, то код управления FPS OSR никогда не переведет Oblivion в спящий режим - если FPS в противном случае превысит MaximumFPS, то OSR будет тратить время в холостом цикле. Этот режим не рекомендуется, так как предоставляется только для тестирования.

FPS_Management\bFPSConsoleSPAM (по умолчанию: 0)
OSR записывает в журнал количество времени, которое требуется для завершения каждого кадра. Он будет делать это один раз на кадр, создавая огромное количество записей.

FPS_Management\iSchedulingParanoia (по умолчанию: 1)
Этот параметр задается в миллисекундах. Он определяет, насколько параноидально код MaximumFPS относится к планировщику. Если значение велико, то код MaximumFPS никогда не будет спать, вместо этого тратя время в холостых циклах. Если значение равно 0, то код MaximumFPS будет доверять планировщику, чтобы тот возобновил выполнение основных потоков точно в запрошенное время. Обычно я выбираю компромиссное значение 1, чтобы в меру параноидально относиться к планировщику, но при этом позволить использовать большую часть свободного времени конструктивно.

FPS_Management\iHardMaxFrametime (по умолчанию: 200)
Этот параметр задается в миллисекундах. Было обнаружено, что когда мой код регулировки временного потока вставляет слишком большое время в неправильное время, происходят странные вещи. Плохие вещи. Например, близлежащие NPC случайно падают замертво. Эта настройка предотвращает это, устанавливая абсолютный максимум на количество миллисекунд, которое OSR позволяет пройти за один раз в нормальном ходе вещей. Обычно вы достигнете MinimumFPS до того, как достигнете этого предела, но MinimumFPS отменяется при некоторых обстоятельствах, чтобы предотвратить побочные эффекты, такие как десинхронизация движений губ с голосом, так что этот параметр действует как своего рода второй уровень MinimumFPS, я действительно имею в виду минимальный FPS.

Слишком низкое значение может привести к таким вещам, как десинхронизация движений губ при разговоре, слишком высокое - к таким ошибкам, как случайное падение NPC. Я установил 200 в качестве компромисса - это не должно вызывать десинхронизацию губ, если ваша частота кадров не упадет ниже 5 во время разговора. А если вы играете в Oblivion при частоте кадров менее 5, то вам нужна серьезная помощь.

Section: CriticalSections{}

Этот раздел посвящен всем изменениям, которые OSR вносит в CRITICAL_SECTIONs Обливиона. Хотите узнать об объектах CRITICAL_SECTION? Oblivion использует их для того, чтобы предотвратить случайное уничтожение друг друга различными потоками. Microsoft предоставляет код для них. Oblivion использует немного разные версии этих объектов в зависимости от того, на какой версии Windows он работает. Подробнее о них вы можете прочитать в MSDN.

CriticalSections\bEnableProfiling (по умолчанию: 0)
Если установлено значение 1, то OSR будет записывать информацию о времени / производительности операций критических секций в Oblivion. Это вызовет небольшой, но значительный урон производительности. OSR будет записывать информацию в свой лог-файл. Потенциально это может дать полезную информацию о том, почему ваш Oblivion подвисает или медленно работает. Эта информация может быть использована для корректировки раздела Overrides ini файла OSR или чего-то еще.

CriticalSections\bEnableMessages (по умолчанию: 0)
Если установлено значение 1, то OSR будет записывать информацию о некоторых событиях синхронизации / производительности критических секций. Это не требует значительных затрат производительности, но может загромождать файл журнала, что затрудняет поиск информации о некритических секциях.

CriticalSections\bUseOverrides (по умолчанию: 1)
Если это значение равно 1, то OSR будет использовать настройки в разделе Overrides ini, чтобы определить, что делать с определенными критическими секциями.

CriticalSections\iDefaultMode (по умолчанию: 2)
Определяет, что OSR делает с критическими секциями, которые не имеют Mode для них в списке Overrides.
1: оставляет критическую секцию в примерно нормальном состоянии.
2: настраивает критическую секцию для улучшения справедливости за счет пропускной способности. Это может предотвратить чрезмерное использование критической секции одним потоком, но может снизить скорость выполнения операций с этой критической секцией.
3: попытка компромисса между справедливостью и пропускной способностью, при которой обычно оптимизируется пропускная способность, но время от времени поведение переключается для оптимизации справедливости.
5: критический раздел подавлен. Подавление критических секций обычно приводит к краху Oblivion, но также обычно повышает производительность. Однако некоторые критические секции могут быть затронуты по-разному.
6: основной поток получает приоритет для этой критической секции.
7: фоновые потоки получают приоритет для этой критической секции.

CriticalSections\iDefaultSpin (по умолчанию: 1000)
Этот параметр влияет на то, как долго поток будет пытаться войти в критическую секцию, прежде чем попросит планировщика перевести его в спящий режим, пока эта критическая секция не станет доступной. Теоретически, слишком маленькое значение приведет к слишком большой нагрузке на планировщик, а слишком большое - к напрасной трате циклов процессора. 1000 - это, на мой взгляд, слишком маленькое значение. Идеальное значение может увеличиваться с количеством ядер / аппаратных потоков, которые у вас есть.

CriticalSections\iStutterLevel (по умолчанию: 4)
Этот параметр влияет на частоту переключения режима критических секций 2. Подробнее о режиме критической секции 2 см. в разделе iDefaultMode. Меньшее число означает частые переключения, большее число означает нечастые переключения. Идеальное значение, вероятно, должно быть где-то в диапазоне от 3 до 6.

Section: Heap{}

Ванильная куча (heap) Oblivion очень плохо справляется с многопоточными нагрузками. Она также имеет тенденцию внезапно и резко замедляться после длительных игровых сессий в сильно модифицированных играх. OSR может заменить кучу Обливиона на другую кучу, чтобы решить эти проблемы.

Heap\iHeapAlgorithm (по умолчанию: 5)
Параметр определяет, какую кучу OSR заставит использовать Oblivion.
1: Куча FastMM4. Требует файл BorlndMM.dll в Data\obse\plugis\ComponentDLLs, иначе она не позволит Oblivion запуститься. Эта куча быстрая и гибкая.
2: Стандартная куча Windows. Зависит от ОС. Очень плохая идея на XP, но подходит для Vista и Windows 7.
3: Куча, которую я написал под названием SimpleHeap1. Она достаточно быстрая.
4: Не используйте ее.
5: Куча, которую я написал под названием ThreadHeap2. Она достаточно быстрая.

Heap\bEnableProfiling (по умолчанию: 0)
Если этот параметр установлен в 1, то OSR будет измерять производительность кучи, которую он предоставляет, и записывать ее в журнал. Это не может измерить производительность ванильной кучи, только производительность куч, предоставляемых OSR.

Heap\iHeapSize (по умолчанию: 450)
Это влияет только на алгоритмы кучи #3 и #5 (см. iHeapAlgorithm выше) - остальные кучи сами выбирают размер и динамически изменяют его. Это количество мегабайт, которое куча резервирует для динамически выделяемых объектов в Oblivion.

Heap\bEnableMessages (по умолчанию: 0)
Если этот параметр установлен в 1, то код кучи OSR может иногда записывать немного информации в журнал.

Section: Hashtables{}

В Oblivion есть куча хештаблиц для поиска чего угодно. Они используют плохую реализацию хештаблиц, но реальная проблема в том, что они никогда не изменяют размеры своих хэш-таблиц, а используемые ими размеры по умолчанию нацелены на игру без модов и часто даже для этого довольно малы.

Когда хештаблица переполнена, производительность падает. Если хештаблица не заполнена, часть памяти может быть потрачена. К сожалению, большая часть кода хештаблицы встроена повсюду, и OBSE также делает различные предположения о хештаблицах, и мне совсем не ясно, какой должна быть соответствующая модель потоковой передачи, поэтому безопасно изменить их довольно сложно.

Тем не менее, у меня есть несколько хуков для хештаблиц, и они постепенно улучшаются.

Hashtables\bAllowDynamicResizing (по умолчанию: 0)
Если этот параметр установлен в 1, то OSR будет увеличивать размер хэштаблиц, когда они переполнятся. Однако сам акт изменения их размера чреват проблемами - он может вызвать сбои или глюки, а методы, которые я использую для предотвращения этого, могут вызвать небольшие задержки производительности или другие сбои или глюки. Тем не менее, на данный момент я думаю, что это может работать достаточно неплохо.

Hashtables\bUseOverrides (по умолчанию: 0)
Currently there are no hashtable overrides, and the syntax for specifying them is awkward and has the potential to silently fail and do something else instead if you enter the wrong value. This will get fixed up eventually though to allow ini-file-specified hooks in to the initialization of the most important hashtables to make them start out at a decent size instead of needing to be resized later.

В настоящее время нет никаких переопределений хэштейлов, а синтаксис для их указания неудобен и может привести к молчаливому отказу и выполнению чего-то другого, если вы введете неправильное значение. В конце концов, это будет исправлено, чтобы позволить заданным в 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 может повысить производительность, поскольку это увеличит размер большего количества хэш-таблиц. iHashtableResizeScale2, вероятно, следует устанавливать на 1 или 2 больше, чем iHashtableResizeScale1.

Hashtables\iHashtableResizeDelay (по умолчанию: 20)
Это количество миллисекунд, на которое OSR задержится при изменении размера хэштаблицы. Идея в том, что хотя я не могу предотвратить доступ другого потока к хэш-таблице, пока я занят этим, я могу, надеюсь, предотвратить их *начало* доступа к хэш-таблице. Поэтому я задерживаюсь достаточно долго, чтобы, возможно, все, кто уже обращался к хэш-таблице, закончили, а затем я делаю свои дела. К сожалению, это не работает на OBSE, потому что OBSE не делает тех же вещей, что и Oblivion, плюс даже когда он делает это, он не использует vtables для этого. Но сейчас я думаю, что OBSE может обращаться к ним только из основного потока, так что если мой ресайзер работает в основном потоке, то ему не нужно беспокоиться об OBSE. Может быть.

Section: Overrides{}

Этот раздел содержит информацию, говорящую OSR, как найти специфические экземпляры различных типов объектов, о которых знает OSR, и как обращаться с этими специфическими экземплярами иначе, чем настройки по умолчанию для этого типа объектов. В настоящее время здесь перечислены только некоторые критические разделы, поведение которых отличается от большинства.

• Oblivion version 1.2.416
• OBSE

Установка

1. Переместите содержимое архива в папку "Data". 
2. [Опционально] Поменяйте настройки OSR в файле OSR.ini. Путь к файлу Data\obse\plugins\sr_Oblivion_Stutter_Remover.ini

Удаление

Просто удалите sr_Oblivion_Stutter_Remover.dll file из папки Data\obse\plugins.