a4nic8er

It is right there in your first post. That is why you are getting SkyUI error 4. Change those 3 settings to the ones I gave you and error 4 will go away. If you spent some of the time wasted typing multicolour rants full of angst and emotes on actually trying the advice you are given, people like me would be less likely to think "I'm not going to bother helping this ignorant pig-headed fool again".

'Skyrim.ini' - SkyUI: Max. Memory Settings (prevent Error Code 4).Skyrim.ini[Papyrus]iMinMemoryPageSize=128 iMaxMemoryPageSize=512 iMaxAllocatedMemoryBytes=76800

Forgive me the necro, but... Looking into some issues of my own, I discovered that even new vanilla game saves contain the following Papyrus log error: Tes5Edit reveals that this particular instance of the item (Editor ID) TG05KarliahInvisibilitySpell (FormID) 000D61E2 is injected into the TG06 "Hard Answers" [QUST:00021552] quest by Update.esm However, it is also referenced in TG05 "Speaking With Silence" [QUST:00021551] by Udpate.esm & Unofficial Dawnguard patch.esp and Patch1_9_UpdateQuest [QUST:010009A3] by Udpate.esm I also found references to pTG05KarliahInvisibilitySpell (note the lower case 'p' at beginning of name) I suspect this is the source of some issues people are having with Karliah "drinking her invisibility potion" during the 'Speaking with Silence' quest. Googling 'TG05KarliahInvisibilitySpell' and 'pTG05KarliahInvisibilitySpell' results in many peoples' posts of logs containing the same above quoted warning, or very similar. The fact that these posts are often seeking help for freezing and/or CTDs worries me. It seems the devs who created the Update.esm may have released a time-bomb into the wild.

O M G 10,000 views in just under a year. I hope this thread was of some help to those that read it. Happy gaming all, a4

I would suggest that you read the readme for NMM and then ask in the Nexus Mod Manager Beta forum if you can't find the answer.

If you mean "Should I completely skip installing this mod?" the answer is no. You still want to install the resources in the mod which includes a lot of fixed meshes and a few fixed textures, and lip-sync files. Only the overwritten esp file needs to be left out (or you can install the esp file and let it get overwritten by the one in the supplimentals patch - but I prefer to have as few red + installs as possible).

Over the past couple of months I have posted a few small updates and do not intend to update this information any further. I have concluded with the reason why I believe a heavily moded Steam version of Oblivion will never run as well as a Bethesda version, at the bottom of post #5.

I did all meshes, trusting Oblivion - PyFFI Optimization Kit v7 to skip those that shouldn't be done. It seems to have worked perfectly fine for me, I have had no problems with animations or items (apart from a bad mesh included in one mod that had nothing to to with PyFFIing). I'm sorry, but I installed the PyFFI Optimization Kit without any trouble so I can't help with your specific problem. I have the PyFFI Optimization Kit (batch file and in/out folders AND everything else in that package) on a different drive too, so that is not an issue. No handlers could be found for logger "pyffi.utils.mathutils" <--- this seems to be your problem. For problems with any mod/tool/utility, you should seek help from the author via their mod's page as they are far more likely to have the knowledge and experience to interpret log results (and tell you what library/component you are missing).

I have added some more information I found about Bashed Patch choices to the bottom of the Bashed Patch section in post #2, if that is any help to you guys. Are you both using version 292 of Wrye Bash ? I went back to using 291 before I even tried building a Bashed Patch with 292. Too many bugs for my liking, and perhaps 292 has broken aspects of the Bashed Patch building process.

The "Item Interchange" esp files are not supposed to be merged into the Bashed Patch. The fact that a file may be "mergable" doesn't necessary mean that it should allways be merged. Item Interchange is a "hack" to force the Bashed Patch to import information by merging-yet-not-merging a few special esp files. To quote the Wrye Bash help file (click the "?" icon in the bottom toolbar) If you look at the four "Item Interchange" esp files in Wrye Bash, three have "Deactivate" Tag, three have "IIM" Tag, and ALL have "Filter" tag. So, the Filtering esp files MUST NOT BE ACTIVE when building the Bashed Patch. The esp files being affected by the filtering (MM, OOO, etc.) MUST BE ACTIVE (OR MERGED). The best way to ensure that is to deactivate the Item Interchange esp files (and any others that have the "Deactivate" Tag) before beginning to rebuild the Bashed Patch, so that you don't get asked in the pop-up (here is a hypothetical example)... ...to which you MUST answer yes to deactivate the Item Interchange esp files (but that will also deactivate the other esp which, although it will be merged into the Bashed patch, needs to remain active). So EITHER you answer yes and then cancel the Rebuild of patch, reactivate a4sEWVE_Full.esp, start the Rebuild Patch again OR, say yes to disabling them all, continue with the Rebuild Patch, then reactivate a4sEWVE_Full.esp after the Bashed Patch is done. Most importantly, read the questions you are asked before you click on an answer. If you don't know the answer, go and read some more to find it.

Some esp files may seem mergeable but are not, never, ever supposed to be activated while the Bashed Patch is being built or the game is running. The first pop-up when you click "Rebuild" gives you some info about those if they are active and asks if you want to deactivate them. The answer for mods that have the Deactivate Bash Tag is always yes, to disable. Mod components such as "Item interchange - Placement for FCOM.esp" (and any others that have {{BASH:Deactivate}} Tag) should never be active or your game will crash due to missing masters. Which is what you have got a lot of. ;)

It is clearly stated in one or more of the FCOM links that some aspects of OOO should not be included in the Bashed Patch. Mainly Factions and Relations, from memory. I'm actually going through this whole process second time, refining the information, so I don't have a completed install to compare your list against right now. But I will be able to look at it in a few days, if you can be patient. I see some unmerged mods there that I would merge (like all the VWalks). And I would be wary of putting two mods that modify magic in together. Definitely wouldn't do that without reading up on them to be sure it was OK. Do you replace old Bashed Patch .esp with an empty one as I explained, before running BOSS and rebuilding the bashed patch? I do every time I rebuild it. Always best to build with a clean patch.

If the bashed patch is causing crashes, your installation is faulty, you are not building it correctly, or your load order is wrong or something. Are you sure you installed the uFCOM component mods correctly? Did you use BOSS to sort your load order? (I always use latest version of BOSS). Is BOSS installed correctly? (Different versions have different paths - you need to completely uninstall it before installing the latest version). Did you read the notes for each mod in the BOSS log? (especially immediately after the uFCOM group installation (where I wrote in big red letters "Now run BOSS and check the log for errors!") When building the Bashed Patch, read what each pop-up window asks before clicking yes or no. Read the descriptions of what each section of selections does (some mods will not be imported if they are neither active nor merged. Therefore some mods need to be active when building the bashed patch, if they aren't going to be fully merged, then deactivated after the Bashed Patch is built - this leaves them with a green + instead of a tick. Conversely, some mods must be deactivated before merging. Just setting all mods to active or inactive before building the Bashed Patch will cause problems). Some aspects of some mods MUST NOT be imported into the bashed patch (some OOO mods when used with FCOM). "Importing" and "Merging" are not the same thing. When asking for help, it is recommended that you include your Installers List and Mods List as it is impossible to advise you without knowing what mods you have installed, in what order, which mods are active, and in what load order.

Yea, this ArchiveInvalidation stuff can be confusing, I'm still not 100% sure I have got my head around it. Wrye Bash adds ArchiveInvalidationInvalidated!.bsa to the \oblivio\Data\ folder. Prior to Bash 292 that bsa had Modified time which was 23 days earlier than the Steam oblivion and DLC BSAs, which (if I understand correctly) sometimes gave me problems with textures. I may be wrong, it could have been something else (like another loose mesh or texture file that was dated earlier than the .bsa files). To be safe I now just like to make sure that ALL original Oblivion and DLC bsa files are dated the same as the ArchiveInvalidationInvalidated!.bsa which is how thay are after installing Wrye Bash 292 (all are Saturday, December 31, 2005, 11:00:00 PM). Any time a .bsa is repacked by OBMM, the Modified time will be set to current and need to be adjusted again. They can easily be checked by starting BulkfileChanger, selecting the whole bunch of them and dragg'n'dropping them into the BulkFileChanger window. I'm as confused as you are now, lol. I am actually on my second run through of this and didn't do the PyFFI the first time. That has led to the PyFFI information being before the uFCOM preparation info. I had better fix that. While it is necessary to run the Fran's .exe files to create our BAIN archive, once that is done we don't have to install any mods to PyFFI them. For mods with meshes contained in .bsa files I used 7-Zip to extract the .bsa files from those archives to \oblivion\Data\ folder, used OBMM to extract the contents of those .bsa files to \Oblivion-PyFFI_Optimization_Kit_v7\in\ folder, (renamed \oblivion\Data\"x.bsa" to "ORIGINAL_x.bsa") ran the PyFFI Kit .bat file, used OBMM to build a new "x.bsa" from the IN then OUT folders, set "x.bsa" Modified date/time to same as "ORIGINAL_x.bsa", 7-Zipped "x.bsa" into an archive with same number and name as the pre-PyFFI one, (appending "+ PyFFI_" to the name so that I can spot them all easier in correct order in a folder - if the PyFFI archive contains only .bsa files, I usually put "-bsa" somewhere in the archive name). Moved the archive to "Bash Installers" folder. Deleted "x.bsa", "ORIGINAL_x.bsa", and the contents of the IN and OUT folders. For mods that contain loose meshes (not .bsa files) I just extract the whole archive to the PyFFI IN folder, run the PyFFI Kit .bat file, 7-Zip the contents of the OUT folder ( using same naming method as above). The results of both these methods give us archives containing .bsa file(s) with some meshes replaced by PyFFI versions, and/or archives with replacemnent PyFFI meshes only (not containing any meshes that haven't been optimized). I will be installing the PyFFI versions on top of the non-PyFFI versions, overwriting the .bsa files and meshes. Some mods, such as a couple of the large mesh replacers, I will use the PyFFI versions only, as the replacement contains the same number of meshes as the non-PyFFI one. Some others have only a single mesh. Some people prefer to install groups of mods and just PyFFI all the meshes in that group, archive those, uninstall and do the next group. I prefer to do each mod individually, so I can track problems and drop individual mods in and out of the installation easier.

I'm not going to say whether it should or shouldn't be used, that decision is up to the individual. For me, the fact that it has a significant effect on memory usage was enough for me to decide not to. In your case the results may be different, you may have faster DDR3 RAM and/or less mods active than I do, less mesh and texture replacers, a 32-Bit OS, whatever. I suggest you try playing in windowed mode with Windows Task Manager running ("Always On Top" selected in options) with and then without the Streamline.esp activated. Load a wilderness save and run or ride along the same path, throughseveral cells and the same creatures/NPCs and see if your memory usage is affected by Streamline. Mine was, quite dramatically and Streamline was contributing to my hitting the 1.8GB memory limit and crashing (before I applied the 4GB patch and also purchased more RAM).