Fallout Stutter Remover
version 4.0.6
by SkyRanger-1

Forum thread: http://www.gamesas.com/bgsforums/index.php?showtopic=1069833
TESnexus page: http://tesnexus.com/downloads/file.php?id=23208

This is an FOSE plugin, and it will not work without a recent version of FOSE.

This will only work with Fallout 3 version 1.7.


====================================
0. Contents:
====================================

0. Contents
1. Overview
2. Installing
3. Uninstalling
4. Common Settings Changes
5. All Settings
6. Version History
7. How This Works
8. Credits


====================================
1. Overview:
====================================

This plugin makes Fallout 3 not "stutter" as much, and generally feel smoother or perform better. It prevents or mitigates a number of issues related to stuttering and framerates, and can reduce the frequency of stutter related crashes. For more detail, see Section 7: How This Works.

Note however that this generally will not fix anything wrong with your drivers, hardware, or codecs - if you have fundamental reasons for for poor performance, this probably won't help much.

This is a port of the Oblivion Stutter Remover (OSR) to work for Fallout. So far, it does not work as well as the original Oblivion Stutter Remover, but it should help some.

This should be compatible with everything. The only caveat is that mods that monitor FPS will not be able to accurately measure FPSes outside of the target range set by this plugin (10 to 30 by default). In fact, even FPSes that merely come close to FSR targets may be difficult to measure.


====================================
2. Installing:
====================================

The installation process is:

1.A. If the version of FSR you are installing came as a .zip file, simply drag the "Data" folder from the zip to your Oblivion folder.

1.B. If the version of FSR you are installing did NOT come as a .zip file then you need to place the file sr_Fallout_Stutter_Remover.dll in to your Fallout\Data\fose\plugins folder. If you don't have such a folder, create it. If you had an older version of FSR installed, delete its ini file (Data\fose\plugins\sr_Fallout_Stutter_Remover.ini). If there is no existing FSR ini file then FSR will generate a new ini file with settings appropriate for your version the next time you run Fallout.


====================================
3. Uninstalling:
====================================

Simply delete the sr_Fallout_Stutter_Remover.dll file from your Data\fose\plugins folder.
Moving that file to another directory would also be sufficient.


====================================
4. Common Settings Changes
====================================

In general, FSR attempts to have decent default settings so that users are not required to monkey with them. However, there are a few settings where the default values might not be appropriate for you, either because the default values do not match your tastes or because FSR is makes incorrect assumptions about your computer.

FSR keeps its settings in the file Data\fose\plugins\sr_Fallout_Stutter_Remover.ini
If that file is not present, simply launch Fallout with FSR installed and FSR will generate a new one with default settings for your version of FSR. If you have screwed something up in your settings or otherwise want to revert to default settings, simply delete this ini file and launch Fallout.

You can find general information about settings in section 5, as well as more complete information on each individual setting.

The settings you are most likely to want to change are:

FPS_Management\MaximumFPS: (defaults to 30, consider changing to 0 or other values)
Some people don't want their framerate limited at all. You can turn off FPS limiting by setting this to 0. Also, if your screen refresh rate when playing Fallout is not 60 Hertz, you might try changing this to your screen refresh rate, or half your screen refresh rate, or one third your screen refresh rate. This setting will have no effect if Master\bManageFPS is changed to 0.

Hashtables\bAllowDynamicResizing: (defaults to 0, consider changing to 1)
Turning this on can improve general performance / FPS significantly on heavily modded games. Unfortunately, it may cause race conditions and general mayhem, particularly when scripts using certain fose commands are running every frame. I've attempted to reduce the chance of problems to near zero, but... it may require more work yet. Meantime this feature defaults to disabled. This setting will have no effect if Master\bHookHashtables is changed to 0.

Critical Section Suppression: (special)
By default FSR suppresses one particular critical section that Fallout seems to work better without. There is another related critical section which some users seem to be able to suppress without causing problems, but other users experience CTDs on interior->exterior transitions or other problems when its suppressed. That one only produces a small improvement to stuttering, so I don't normally recommend suppressing it, but you can if you want to. To suppress it, find the line that says "CallerAddress = 0x70172A" in your ini file and add a new line right after it that says "Mode = 5". Note that case is important there... it should be "Mode" and not "mode". This setting will have no effect if Master\bHookCriticalSections or CriticalSections\bUseOverrides are set to 0.
note: the portion of the readme immediately above this that is crossed out was for Oblivion, not Fallout; there is an equivalent for Fallout, but I haven't gotten around to looking up the precise values for it yet. For the moment, ignore that.


====================================
5. All Settings
====================================

FSR keeps its settings in the file Data\fose\plugins\sr_Fallout_Stutter_Remover.ini
If that file is not present, simply launch Fallout with FSR installed and FSR will generate a new one with default settings for your version of FSR. If you have screwed something up in your settings or otherwise want to revert to default settings, simply delete this ini file and launch Fallout.

Note that the format of FSR ini files changes between major versions of FSR - you should not use an FSR version 1 ini file with FSR version 2, etc. In FSR2, the ini file is organized in to sections like "SectionName { SettingName = Value }". A specific setting may be refered to as SectionName\SettingName to distinguish it from other settings with the same name in different sections. In general settings with names that begin with an "i" are integer values (ie a number with no decimal point), setting with names that begin with a "b" are boolean values (ie either 0 or 1), and settings that begin with an "f" are numbers which may have decimal points in them (ie 3.14). Some settings do not begin with one of those letters, in which case it may not be clear what the proper type of values are.

These are the settings and their current default values (may not be 100% up to date):

Section: Master{}
This section contains an option to disable each major subsystem of FSR, plus a few settings for things that don't belong to any particular subsystem of FSR.

Master\bManageFPS (default: 1)
Setting this to 0 will disable all FPS management stuff, making every setting in the FPS_Management section meaningless.

Master\bHookCriticalSections (default: 1)
Setting this to 0 will disable all Critical Section stuff, making every setting in the CriticalSections section meaningless.

Master\bHookLightCriticalSections (default: 1)
Setting this to 0 will disable all Light Critical Section stuff, making every setting in the LightCriticalSections section meaningless.

Master\bHookHashtables (default: 1)
Setting this to 0 will disable all Hashtable stuff, making every setting in the CriticalSections section meaningless.

Master\bReplaceHeap (default: 0)
Setting this to 1 will enable heap replacement, making the settings in the Heap section meaningful.

Master\bLogToConsole (default: 0)
FSR logs various bits of information to its log file. Changing this setting to 1 will cause FSR to also print that information to the console.
The log file is sr_Fallout_Stutter_Remover.log in the Fallout directory. It is created or overwritten each time Fallout runs with FSR installed.

Master\bFix64Hertz (default: 1)
Setting this to 1 fixes a problem in Fallout that causes "microstutter". This problem is sometimes known as the "64 Hertz issue". Specifically the issue is that Fallout game logic timing normally occurs at a resolution of 1/64th of a second, and screen refresh rates normally permit Fallout to draw 60 frames per second when vsync limited. This combination creates a kind of beat frequency when the framerate is maxed out in which 4 frames each second have twice the amount of game time pass as the 56 frames. The fix that FSR applies forces Fallout to use time at a resolution of 1/1000th of a second instead of 1/64th of a second.

Master\bFlushLog (default: 1)
This tells FSR to write any log messages to its file immediately instead of buffering them in memory. It can reduce performance slightly due to larger number of disk accesses, but it makes it more likely that any messsages pertaining to problems that occur shortly before a crash will successfully get written to the log file.

Master\iSchedulingResolution (default: 1)
FSR will request that the Windows scheduler run at a resolution of this many milliseconds. With this set at 1, FSR and Fallout generally work better. This can slightly reduce the battery life of laptops however.

Section: FPS_Management{}
This section contains settings that adjust how FSR manages your framerate and the flow of game time.

FPS_Management\bAllowSlowMotion (default: 1)
Setting this to 0 will prevent FSR from attempting to override the normal flow of game time. In the past bugs have arison from FSR doing so (most infamously, the nearby-NPCs-drop-dead-on-cell-transitions bug), but these are believed to be fixed now. Just in case you suspect there might be an issue though, you can forcibly disable all FSR game time adjustments with this setting. Despite the name, setting this to 0 will also prevent FSR from fast-forwarding game time, though FSR only tries to do that under very rare combinations of settings and circumstances.

FPS_Management\MaximumFPS (default: 30)
This is a maximum FPS that FSR will not permit Fallout to exceed. I generally set this to a framerate high enough that I won't really care much about any extra frames per second. Note that FSR does not really deal with "frames per second" here, it converts that value to a milliseconds-per-frame number instead, and considers each frame individually. If a frame would be finished too quickly then FSR will cause Fallouts main thread to go to sleep until the correct number of milliseconds have passed. Putting Fallouts main thread to sleep can free up resources for use by Fallouts background threads or for other programs that may be running in the background. If nothing wants to use the extra resources then your CPU and/or GPU will run colder and use less electricity.

FPS_Management\MinimumFPS (default: 10)
This is a minimum FPS that FSR will not permit Fallout to go under. However, instead of dealing with real seconds, this deals with seconds of game time. So you can still have an FPS of 1 if your computer is really slow, but this would slow down game time to 10% of normal so that there will always be at least 10 frames per second of game time. All the numbers there were just for example, based upon a real FPS of 1 and a MinimumFPS setting of 10 (the default value). Also note that like MaximumFPS this actually works on a single-frame basis dealing with millisecond per frame instead of frames per second.
I generally set this to the lower FPS that I find remotely playable. The big purpose of this setting is to prevent Fallouts game logic from going berserk when the FPS gets too low. Issues that this prevents include fights that are impossible because enemies can run circles around you between frames, screwed up controls because Fallout thinks that the attack key is down for an entire frame or not down for an entire frame which may cause a power attack to occur when an attack was intended, and lots of other similar issues.

FPS_Management\iSmoothFrames (default: 0)
If this is set to 0, the "smoothing" logic doesn't do anything. To turn on the smoothing logic try setting this to 2. However, reports suggest that the smoothing logic isn't really worth much of anything. The smoothing logic is intended to prevent a variety of issues that arise from stutters and other rapid changes in framerates. The smoothing logic will have no effect if bAllowSlowMotion is 0.

FPS_Management\iSmoothMode (default: 0)
This should be 0, 1, 2, or 3. If it's 0 or 1 then it will enable some extra logic that tries to filter stutter events out of the flow of time. That logic can end up with the total amount of gametime that passes not being quite equal to the amount of real time that passes if there was a very sudden drop in FPS. If it's 2 or 3 then that extra bit of logic is disabled. The difference betteen 0/2 and 1/3 is a very subtle issue of which frames get time redistributed between them how.

FPS_Management\iSleepExtra (default: 2)
FSR will force Fallout to sleep for this many milliseconds every second. This can help free up resources for background threads or other processes, or reduce the temperature & power consumption of computer components slightly. The main benefit is that if some background thread is struggling to get a particular resource that the main thread is hogging, this can give it a chance to get ahold of that resource once in a while.
If this is set to -1 then the FSR FPS management code will never put Fallout to sleep - if the FPS would otherwise exceed MaximumFPS then FSR will waste time in an idle loop. That mode is not recommended as is provided for testing purposes only.

FPS_Management\bFPSConsoleSPAM (default: 0)
This will cause FSR to log the amount of time it takes to complete each frame. It will do so once per frame, creating an enormous amount of logged times.

FPS_Management\iSchedulingParanoia (default: 1)
This setting is in units of milliseconds. It determines how paranoid the MaximumFPS code is about the scheduler. If the value is high, then the MaximumFPS code will never sleep, instead wasting time in idle loops. If the value is 0, then the MaximumFPS code will trust the scheduler to resume the main threads execution at exactly the requested time. Generally I compromise at 1 for a modicrum of paranoia about the scheduler but still allowing much of the spare time to be put to constructive use.

FPS_Management\iHardMaxFrametime (default: 200)
This is in units of milliseconds. It's been found that when my time flow adjusting code puts in a time that's too large at the wrong time, strange things happen. Bad things. Like, nearby NPCs randomly dropping dead. This setting prevents that, by setting an absolute maximum to the number of milliseconds FSR permits to pass at once in the normal course of things. Normally you'll hit MinimumFPS before you hit this limit, but MinimumFPS gets waived under some circumstances to prevent side effects like lip movements desynching with voices, so this acts a sort of 2nd level of MinimumFPS, the I-really-mean-it minimum FPS. Setting this too low can cause things like lip movements desynching in conversations, setting it too high can permit bugs like NPCs-dropping-dead-randomly. I set 200 as a compromise - it should not cause lips to desynch unless your framerate drops to less than 5 in a conversation. And if you are playing Fallout at a framerate of less than 5 then you need serious help.

Section: CriticalSections{}
This section deals with all the changes that FSR makes to Fallouts CRITICAL_SECTIONs. Want to know about CRITICAL_SECTION objects? Fallout uses them to prevent its various threads from accidentally killing each other. Microsoft provides the code for them. Fallout uses slightly different versions of them depending upon which version of Windows it runs on. You can read more about them on MSDN.

CriticalSections\bEnableProfiling (default: 0)
If set to 1 then FSR will record information about the timing / performance of critical section operations in Fallout. Doing so cause a small but significant penalty to performance. FSR will record the information in its log file. This can potentially produce useful information about why your Fallout is stuttering or running slowly. That info might be used to adjust the Overrides section of the FSR ini file or something.

CriticalSections\bEnableMessages (default: 0)
If set to 1 then FSR will record information about some timing / performance events of critical sections. There is very little performance cost to doing so, but it can clutter up the log file making it harder to find non-critical-section information in there.

CriticalSections\bUseOverrides (default: 1)
If this is set to 1 then FSR will use the settings in the Overrides section of the ini to determine what is should do to specific critical sections.

CriticalSections\iDefaultMode (default: 2)
This determines what FSR does to critical sections that don't have a Mode entry for them in the Overrides list.
1: it leaves that critical section at aproximately normal behavior.
2: it adjusts that critical section to improve fairness at the cost of throughput. This can prevent one thread from hogging a critical section too much, but can net rate at which operations can be done with that critical section.
3: an attempted compromise between fairness and throughput in which it usually optimizes for throughput but once in a while switches behavior to optimize for fairness.
5: that critical section is suppressed. Suppressing critical sections generally causes Fallout to crash, but also generally improves performance. Certain critical sections may be affected differently though.
6: that the main thread gets priority for that critical section.
7: that background threads get priority for that critical section.

CriticalSections\iDefaultSpin (default: 500)
This effects how long a thread will keep trying to enter a critical section before asking the scheduler to put it to sleep until that critical section becomes available. In theory a value that is too small will result in too much scheduler overhead, while a value that is too large will result in wasted CPU cycles. 500 is actually a kinda small value I think. The ideal value may increase with the number of cores / hardware threads you have.

CriticalSections\iStutterLevel (default: 4)
This parameter effecst how often critical section mode 2 switches behavior. See iDefaultMode for more about critical section mode 2. A smaller number means frequent switches, a larger number means infrequent switches. The ideal value should probably be somewhere in the range of 3 to 6.

Section: LightCriticalSections{}
This section deals with all the changes that FSR makes to a category of Fallout objects that serve a similar purpose to CRITICAL_SECTIONs but are more light-weight.

LightCriticalSections\bFullHooks (default: 0)
If set to 1 then this will turn on the more complete version of the light critical section hooks. Unfortunately, the more complete version is still buggy, so this is defaulting to disabled at the moment.

LightCriticalSections\bEnableProfiling (default: 0)
If set to 1 then FSR will record information about the timing / performance of light critical section operations in Fallout. Doing so cause a small but significant penalty to performance. FSR will record the information in its log file. This can potentially produce useful information about why your Fallout is stuttering or running slowly. That info might be used to adjust the Overrides section of the FSR ini file or something.

LightCriticalSections\bEnableMessages (default: 1)
If set to 1 then FSR will record information about some timing / performance events of light critical sections. There is very little performance cost to doing so, but it can clutter up the log file making it harder to find non-critical-section information in there.

LightCriticalSections\bUseOverrides (default: 1)
If this is set to 1 then FSR will use the settings in the Overrides section of the ini to determine what is should do to specific critical sections. The overrides will have no effect unless the full LCS hooks are enabled (bFullHooks above).

LightCriticalSections\iDefaultMode (default: 2)
This determines what FSR does to light critical sections that don't have a Mode entry for them in the Overrides list. It attempts to use a similar mode numbering scheme as the critical sections stuff - see CriticalSections\iDefaultMode above for more information. Some modes may behave rather differently depending upon whether or not bFullHooks is enabled.

LightCriticalSections\iDefaultSpin (default: 500)
This determines what FSR does to light critical sections that don't have a Spin entry for them in the Overrides list. It attempts to have a similar meaning to the critical sections stuff - see CriticalSections\iDefaultSpin above for more information. Spins meaning may be somewhat different depending upon whether or not bFullHooks is enabled.

LightCriticalSections\iStutterLevel (default: 4)
This parameter effecst how often light critical section mode 2 switches behavior. See iDefaultMode for more about critical section mode 2. A smaller number means frequent switches, a larger number means infrequent switches. The ideal value should probably be somewhere in the range of 3 to 6.


Section: Heap{}
This stuff does not really work for Fallout yet. Do not use.

Section: Hashtables{}
Fallout includes a bunch of hashtables for looking up all sorts of things. They use a generally horrid hashtable implementation, but the real problem is they never resize their hashtables. When a hashtable gets overful, performance drops. If a hashtable is underful then a tiny bit of memory may be wasted, and cache coherency may drop. Unfortunately, much of the hashtable code is inlined all over the place, and FOSE makes various assumptions about the hashtables as well, and its not at all clear to me what the relevant threading model is supposed to be, so changing them safely is quite difficult. Still, I have some hashtable hooks, and they're gradually getting better.

Hashtables\bAllowDynamicResizing (default: 0)
If this is set to 1 then FSR will increase the size of hashtables once they get overful. The act of resizing them is fraught with problems however - it can cause crashes or glitches, and the methods I use to prevent it from doing so can cause small performance stutters or other crashes or glitches. Still, at this point I think it might be working kinda decently.

Hashtables\bUseOverrides (default: 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.

Hashtables\bEnableProfiling (default: 0)
This will monitor hashtables and log information about how full they are and how much they get accessed.

Hashtables\bEnableMessages (default: 0)
If this is 1 then the hashtables code may occasionally log messages about what it is doing.

Hashtables\iHashtableResizeScale1 (default: 2)
Hashtables\iHashtableResizeScale2 (default: 4)
If bAllowDynamicResizing is 1 then iHashtableResizeScale1 will determine the minimum level of occupancy at which a hashtable will be resized, and iHashtableResizeScale2 will determine how much larger its new size will be. Both numbers are actually exponents applied to 2, so a setting of 3 means a factor of 8, and a setting of 5 means a factor of 32. In theory reducing iHashtableResizeScale1 down to 1 might improve performance more, because it would increase the size of more hashtables. iHashtableResizeScale2 should probably be set to 1 or 2 more than iHashtableResizeScale1.

Hashtables\iHashtableResizeDelay (default: 20)
This is a number of milliseconds that FSR will stall for when resizing a hashtable. The idea is that while I can't prevent another thread from accessing the hashtable while I'm busy with it, I can, hopefully, prevent them from *starting* to access the hashtable. So I delay long enough that maybe, possibly, anyone who was already accessing the hashtable will finish up, then I do my stuff. That doesn't work on FOSE unfortunately because FOSE doesn't do the same things as Fallout does, plus even when it does it doesn't use the vtables to do them. But atm I'm thinking that FOSE may only access them from the main thread, so if my resizer runs in the main thread then it doesn't have to worry about FOSE. Maybe.

Section: Overrides{}
This section contains information telling FSR how to find specific instances various types of objects that FSR knows about, and ways to treat those specific instances differently than the default settings for that type of object. Currently only things that actually get listed here are a few specific critical sections with different behaviors than most.


====================================
6. Version History:
====================================

FPS Capper version 1:
This was known as FPS Capper. All it did was FPS management. This version was integrated into a modified set of OBSE dlls.

FPS Capper version 2:
This was the first version to have its own dll seperate from OBSE. This was known as FPS Capper. All it did was FPS management.

Oblivion Stutter Remover version 3 beta 1:
The first version to be named Oblivion Stutter Remover. Sometimes freezes for several minutes at the main menu. NPC voice and face movements can screw up in dialogue.
version 3 beta 2: NPC voice and face movements can screw up in dialogue.

Oblivion Stutter Remover version 3 beta 6:
There was a long delay between beta 5 and beta 6, filled by many alpha releases. This was the first version of FSR to really do a decent job of actually reducing stutter for the average user. This is because of new features: critical section fairness tweaks, critical section suppression, and heap replacement. Unfortunately, heap replacement still has major problems for many users. bFix64Hertz was set to 0 by default in the ini, it should be 1 instead.

note: there was never a version 3 final. If there's enough demand I could make one up based off of version 3 beta 6 source code with a few fixes.

Fallout Stutter Remover version 1 beta 1:
Initial port of OSR to Fallout.

Oblivion/Fallout Stutter Remover Version 4.1.0:
Major Changes:
1. Supports both Fallout & Oblivion in the same codebase: Doesn't provide as much benefit on Fallout 3, but it does help.
2. .ini file: Completely different ini file format
3. Hashtable resizing: New feature for improving performance
4. Critical Sections & Light Critical Sections: Generalized many special cases for critical sections, now much more adjustable from the ini file. The "full hooks" of the light critical section code is still buggy.
5. Heap Replacement: Fixed a few bugs, but I think it still has problems. Still doesn't work at all on Fallout.
6. Version naming: Versions released to tesnexus are now called release versions instead of beta versions. Versions released to my ftp server are now called beta versions instead of alpha versions. The first digit of the version numer is incremented only when major changes are made to configuration or distribution format. The 2nd digit of the version number is incremented each release version. The 3rd digit of the version number is incremented once for each beta version. Whenever a digit is incremented, all digits further to the right are reset to 0.



====================================
7. How This Works:
====================================

This is an FOSE plugin dll. It basically hacks Fallout.

7.1: FPS Management:
The FPS management code monitors framerates and adjusts the flow of gametime. It mitigates stuttering by making Fallout game logic not skip ahead when it does stutter. Effectively, frames that take a long time end up being in slow motion. This is done by making Fallout act as if iFPSClamp were set to MinimumFPS, but only for frames that are slower than MinimumFPS. This may also improve stability. It can also impose a maximum framerate - some people percieve Fallout as smoother when its framerate is prevented from exceeding half the refresh rate, plus this helps free up resources for Fallouts secondary threads.

The FPS management code can also puts the main thread of Fallout to sleep for brief periods of time, which has been oberved to improve stutter for some people (though that functionality may have been made redundant by other things this plugin does).

7.2: Critical Sections:
Critical sections are microsoft-provided thread synchronization primitives that Fallout uses internally to make sure that threads don't accidentally corrupt each other. FSR by default makes most critical sections attempt to play fair even at the cost of throughput, making sure that no thread hogs a resource that other threads need. However, one specific critical section is overriden to use a slightly less fair method, and another specific critical section is suppressed so that it has no effect at all. And that's all very configurable from the ini file. Also the spincounts get overriden.

7.3: Heap Replacement:
This feature is not working properly on Fallout 3 yet.

7.4: Hashtables:
Fallout includes a bunch of hashtables for looking up all sorts of things. They use a generally horrid hashtable implementation, but the real problem is they never resize their hashtables. When a hashtable gets overful, performance drops. If a hashtable is underful then a tiny bit of memory may be wasted. Unfortunately, much of the hashtable code is inlined all over the place, and FOSE makes various assumptions about the hashtables as well, and its not at all clear to me what the relevant threading model is supposed to be, so changing them safely is quite difficult.

Still, I have some hashtable hooks, and they're gradually getting better. FSR can increase the size of hashtables once they get overful. The act of resizing them is fraught with problems however - it can cause crashes or glitches, and the methods I use to prevent it from doing so can cause small performance stutters or other crashes or glitches. Still, at this point I think it might be working kinda decently. In the future I may replace or suplement this with overriding the initial sizes of certain hashtables.


====================================
8. Credits:
====================================

This plugin was made by me (Christopher Doty-Humphrey).

It would not have been possible without the enormous efforts made by the FOSE team. In addition, Ian Patterson (an FOSE team guy) has helped me through a lot of spots where I had trouble.

The original thread that prompted me to start this plugin was started by DeviusCreed.

Numerous testers have supplied useful feedback. In particular mashani's information about which settings produced which results for him helped me understand why early versions of this were producing unexpected benefits, and led to a number of the features and settings in later versions.

I would also like to thank badhair for pointing me at overfull hashtables as a cause of performance problems.

The following tools were used in the production of this plugin:
Oblivion / Fallout, by Bethesda
OBSE/FOSE and the OBSE/FOSE source code
Microsoft Visual C++ 2008 Express Edition
IDA Free (Interactive Debugger, free version, version 4.9)
Cheat Engine (version 5.4)
Plus the obvious stuff like Windows XP, Notepad, and Firefox.

With the exception of Oblivion/Fallout and Windows XP, all of those are available free of charge.

I've also had Hex Workshop and ollydbg recommended to me but haven't gotten around to trying them yet.

Is the net result more crash or less crash? Maybe it's the icepick in my right temple but I was confused after reading the firstpost....

Sorry for the barrage of questions...

I'm getting an error in the FOSE log "HandleLoadGame: couldn't open file..." Do I need to start over from the beggining of the game in order to use the mods?

How do I tell if FSR is loading or not?

How do I adjust the settings?

Sorry for the barrage of questions...

I'm getting an error in the FOSE log "HandleLoadGame: couldn't open file..." Do I need to start over from the beggining of the game in order to use the mods?

How do I tell if FSR is loading or not?

How do I adjust the settings?

FOSE: initialize (version = 1.1.9 01070030)
patched
DoLoadGameHook: Save 8 - user, The Capital Wasteland, 00.51.06.fos
loading from C:\Documents and Settings\user\My Documents\My Games\Fallout3\Saves\Save 8 - user, The Capital Wasteland, 00.51.06.fose
HandleLoadGame: couldn't open file (C:\Documents and Settings\user\My Documents\My Games\Fallout3\Saves\Save 8 - user, The Capital Wasteland, 00.51.06.fose), probably doesn't exist
FOSE: deinitialize

launching: Fallout3.exe (C:\Program Files\Bethesda Softworks\Fallout 3\Fallout3.exe)
crc = FE5B82AE
hook call addr = 00C05F61
load lib addr = 00D9B0F0
dll = C:\Program Files\Bethesda Softworks\Fallout 3\fose_1_7.dll
remote memory = 00150000
old winmain = 006EE300
launching

jason67: The FSR dll does NOT go in the directory where the FOSE dlls go. It goes in Data\fose\plugins.

To check if FSR is being loaded properly you can try deleting the FSR log file. If a new one isn't created the next time you start Fallout then FSR did not load. Alternatively, you can examing your fose.log file. If FSR loaded correctly it will include a line like:
plugin C:\Program Files\Fallout 3\Data\FOSE\Plugins\\sr_Fallout_Stutter_Remover.dll (00000001 sr_Fallout_Stutter_Remover 00000101) loaded correctly

The settings are in the ini file mentioned above. The ini file doesn't exist until after Fallout is run once with FSR installed.

Yeah, I never noticed microstutter before Fallout 3, but now I see it in other games where I didn't before, albeit to a much lesser degree. I only have a single GPU, but I've become very sensitive to it. It definitely exists, and not just for multi-GPUs. I was able to effectively remove it from HL2 by taking reflections down a notch, and from Far Cry 2 by turning shadows off. That may not work for everyone, and probably had more to do with me having a mid range PC, but it worked for me after a lot of trial and error.

That's not "microstutter". That is simply FPS drops caused by grafics settings.
Microstutter is a very specific term used to describe a problem with MultiGPU setups and has little to do with actual grafics settings.

Yeah, I never noticed microstutter before Fallout 3, but now I see it in other games where I didn't before, albeit to a much lesser degree. I only have a single GPU, but I've become very sensitive to it. It definitely exists, and not just for multi-GPUs. I was able to effectively remove it from HL2 by taking reflections down a notch, and from Far Cry 2 by turning shadows off. That may not work for everyone, and probably had more to do with me having a mid range PC, but it worked for me after a lot of trial and error.

I do get a new log file created after each time loading up the game if I've deleted the previous one, but I don't get a line in it saying 'loaded correctly' or resembling the full line you quoted above. Does that suggest it is loaded but with errors or attempting to load but failing perhaps? The first line of the log is 'console interface not found', then about 20 lines of other items, then the last line starts 'initialize2() running in thread...'

Except that I get it even when fraps is telling me I'm at a constant 60+ fps. I know exactly what microstitter is by now. It's unmistakable.

And yes, I can also tell the difference between low fps, microstutter, and regular stutter when games load from the hard drive.

Certain graphic settings/drivers definitely have an effect on microstutter. Otherwise we wouldn't have this thread.

Except that I get it even when fraps is telling me I'm at a constant 60+ fps. I know exactly what microstitter is by now. It's unmistakable.

And yes, I can also tell the difference between low fps, microstutter, and regular stutter when games load from the hard drive.

Certain graphic settings/drivers definitely have an effect on microstutter. Otherwise we wouldn't have this thread.

No, that's a judder.
Both have technically the same effect, namely ufo (uneven frame output). But microstutter, is in general something that is applied to multi GPU setups.