Luinithil

Nakakita's issue looks similar to mine-- I did check though and I am using none of the mods listed above. The only mods I have that add things to \DistantLOD are the UOP and Artifacts. It happens whether using 2.2.2 or 3.0.15. Log snippet from the end of LODGen 3.0.15's process, it usually fails around this point-- either replacing the Toddland LODs or Sheogorath's realm. [00:19] Background Loader: [D:\Program Files\Steam Games\SteamApps\common\Oblivion\Data\] Setting Resource Path. [00:19] Background Loader: finished [00:20] LOD Generator: starting [00:20] LOD Generator: Replacing Tamriel [WRLD:0000003C] [02:48] LOD Generator: Replacing Toddland [WRLD:00000858] [02:52] LOD Generator: Replacing ToddTestLand2 [WRLD:00000879] [02:52] LOD Generator: Replacing MQ15TestWorld3 [WRLD:0000145B] [02:52] LOD Generator: Replacing EmptyWorld [WRLD:0000568F] [02:52] LOD Generator: Replacing SEWorld "Realm of Sheogorath" [WRLD:00009F18] [02:52] LOD Generator: <Error: Out of memory> Screenshots taken during the process:

@Uhuru: Not that I think it matters now to TESLODGen whether AI is on, since I checked and did have Archive Invalidation working on two of the profiles I tested with previously, have managed to get it up and running properly currently on all profiles as far as I can tell-- and yet LODGen is using insane amounts of memory and running out of it same as usual when called from MO, which it *doesn't* when run on its own. Somewhere somehow something is leaking memory I think.

Copied ArchiveInvalidationInvalidated!.bsa over into the Data folder and registered it manually in the INI, so Automatic Archive Invalidation appears to be working now. I think.

Sorry for the delay: I've just had the time and surety to revert my installation to vanilla tonight after ironing out the last kinks in my Wrye Bash backup install. I'm now looking at a brand new, fresh Oblivion.ini and a Data folder that has nothing more in it except OBSE plugins; looking at your coloured text above, I see the difference is in Oblivion-Invalidation.bsa. Where would I get such a file? As you can see below, my new INI file hasn't got any such file listed, it's got ArchiveInvalidation.txt instead. How do I create one? Edit to ask: If I copy over ArchiveInvalidationInvalidated!.bsa from my previous Wrye Bash managed install, and edit my INI files to use that, will it work the same? [Archive] SMasterMiscArchiveFileName=Oblivion - Misc.bsa SMasterVoicesArchiveFileName2=Oblivion - Voices2.bsa SMasterVoicesArchiveFileName1=Oblivion - Voices1.bsa SMasterSoundsArchiveFileName=Oblivion - Sounds.bsa SMasterTexturesArchiveFileName1=Oblivion - Textures - Compressed.bsa SMasterMeshesArchiveFileName=Oblivion - Meshes.bsa SInvalidationFile=ArchiveInvalidation.txt iRetainFilenameOffsetTable=1 iRetainFilenameStringTable=1 iRetainDirectoryStringTable=1 bCheckRuntimeCollisions=0 bInvalidateOlderFiles=1 bUseArchives=1 SArchiveList=Oblivion - Meshes.bsa, Oblivion - Textures - Compressed.bsa, Oblivion - Sounds.bsa, Oblivion - Voices1.bsa, Oblivion - Voices2.bsa, Oblivion - Misc.bsa

Nice list there WilliamImm, I'm using a fair few of them currently. I should note that there's an ESPless book jacket replacer out that can be used in place of the book jackets mods.

Installation priority-- you mean the left pane? I think you could copy the modlist.txt from your old profile over to the new one-- that should do it. Otherwise for the load order you want plugins.txt.

Installing mods for Oblivion through MO, I encountered an issue where TES4LODGen (needed to run Really AEVWD, which is an object LOD mod) consistently runs out of memory when generating LOD files. Memory use as reported by Task Manager in Windows 7 shows the memory use balloons up to > 30000000 K, at which point LODGen usually fails. Nothing was significantly changed in my mod setup between Wrye Bash and MO except the addition of a few house mods, which AFAIK should not have added many (if any) LOD items to be generated. If I run LODGen through MO with only the official plugins and a small handful of mods, the LOD files are successfully generated; however at some point it starts choking on lack of memory. I have 8GB of RAM on my laptop, and an i7 CPU and frankly I don't see why this should even be an issue. I've found no solution to this problem, since it doesn't seem to be any particular mod I've installed and thus have had to switch back to using Wrye Bash for the time being since installation and behaviour overall seem to work better with Oblivion. I would also note that when I've run TESLODGen after installing mods in Wrye Bash, all LOD files are generated with no problems and in less than 5 minutes, and RAM usage for LODGen never breaks 500 - 600K. I'm not sure what's going on here, since LODGen is a 32-bit app. In the absence of anything else, I am wondering if the absence of correct archive invalidation settings might be at fault (see my other thread on the subject in this subforum) ? I'll admit this is reaching, but it was already at the point where Oblivion simply wouldn't start but crashed before the main menu. So I decided to head back to Wrye Bash. This is highly frustrating, because I'd had 90% of my install already configured in MO--INI tweaks and such. In any case I am planning on trying to migrate to MO again, just not quite so soon as I've only just managed to get my Wrye Bash install done.

Installing mods for Oblivion through MO, I encountered an issue where TES4LODGen (needed to run Really AEVWD, which is an object LOD mod) consistently runs out of memory when generating LOD files. Nothing significantly changed in my mod setup between Wrye Bash and MO except the addition of a few house mods, which AFAIK should not have added many LOD items to be generated.

jyujinkai: this page on the Nexus forums might be relevant: https://forums.nexusmods.com/index.php?/topic/473728-mod-organizer/page-448

Running BUM from MO this evening, when I got this message, right after the log had been generated and shown in my browser: ************** Exception Text ************** System.ArgumentOutOfRangeException: InvalidArgument=Value of '0' is not valid for 'index'. Parameter name: index at System.Windows.Forms.ListView.SelectedListViewItemCollection.get_Item(Int32 index) at BOSS_Userlist_Manager.BumUserlist.get_SelectedItems(Int32 index) at BOSS_Userlist_Manager.BUM.msRunBoss_Click(Object sender, EventArgs e) at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e) at System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e) at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e) at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e) at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met) at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met) at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea) at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.ScrollableControl.WndProc(Message& m) at System.Windows.Forms.ToolStrip.WndProc(Message& m) at System.Windows.Forms.MenuStrip.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) ************** Loaded Assemblies ************** mscorlib Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.2012 (RTMLDR.030319-2000) CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll ---------------------------------------- BOSS Userlist Manager Assembly Version: 6.6.0.0 Win32 Version: 6.6.0.0 CodeBase: file:///C:/BOSS%20Userlist%20Manager/BOSS%20Userlist%20Manager.exe ---------------------------------------- Microsoft.VisualBasic Assembly Version: 10.0.0.0 Win32 Version: 10.0.30319.1 built by: RTMRel CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/Microsoft.VisualBasic/v4.0_10.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll ---------------------------------------- System Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.2001 built by: RTMLDR CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll ---------------------------------------- System.Core Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.450 built by: RTMLDR CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll ---------------------------------------- System.Windows.Forms Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.2003 built by: RTMLDR CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll ---------------------------------------- System.Drawing Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.2001 built by: RTMLDR CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll ---------------------------------------- System.Runtime.Remoting Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.1 (RTMRel.030319-0100) CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Runtime.Remoting/v4.0_4.0.0.0__b77a5c561934e089/System.Runtime.Remoting.dll ---------------------------------------- System.Configuration Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.2022 (RTMLDR.030319-2000) CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll ---------------------------------------- System.Xml Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.2022 built by: RTMLDR CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll ---------------------------------------- UtilityLib Assembly Version: 3.0.0.0 Win32 Version: 3.0.0.0 CodeBase: file:///C:/BOSS%20Userlist%20Manager/UtilityLib.DLL ---------------------------------------- System.Web Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.2026 built by: RTMLDR CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_32/System.Web/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Web.dll ---------------------------------------- [/code]

Hmm. I might have something to add about OBMM and MO; I don't know if anyone else has had a similar issue, but when I tried installing Darnified UI via manual install, it refused to work in the game; curiously the version I installed from .omod via OBMM through MO works just fine, with the files landing in \overwrite and thence to their own folder. Sheer voodoo.

I'll be detailing my experiences with using MO to install Oblivion in a bit, but currently I have a bit of a problem, which ties in with a thread I made earlier. Running MO from a new pristine install, no saves at all or anything except the usual Oblivion.ini and other INIs in C:\...\My Games\Oblivion, I created a new MO profile for my character. When I attempt to set up local savegames and automatic archive invalidation, I find that the option for archive invalidation is greyed out, see the attached pics. Since documentation for using MO with Oblivion is sadly lacking, I'd like to ask if back-dating the BSAs AND selecting the option to force hide plugins is needed? Or is the greyed out option for archive invalidation a sign that I've done something wrong with MO installation in this case? Thanks! ETA: Yes, I forgot back there that backdating BSAs is only a valid alternative to archive invalidation for Skyrim. Still can't get AI in Oblivion MO however.

I use Cobian Backup for my savegames and MO folder. Works well so far, and can be set to automatically backup every day at a specific time. Just make sure it's not going to do so while you're in game. ;)

I believe I said much of what I wanted to earlier, but for articles I'd like to see: I'd think that breaking out the various sections within the Advanced tab into their separate sections and fleshing them out, possibly merging some, would be a good idea. As the Advanced page stands at the moment, it looks and feels like a temporary dumping ground for information that doesn't neatly fit anywhere else as yet. Personally I think that certain sections that are currently in the Advanced tab could probably stand to be merged into a different section of the wiki; e.g. the INI tweaks would logically fit better under the Installing Mods section, since installing those INI tweaks is part of the workflow in installing mods, be it for a specific mod or tweaking the base INI. Say I want to install Darnified UI and it involves putting in the right INI tweaks; rather than having to look around and find (or not find, depending) the relevant information in a different tab of the wiki, all the relevant installation info I need to get this mod up and working will be there on the same page.

I gave up using MO the last time, because I needed my game up and working in a hurry; and for some reason Oblivion was failing to pick up on MO and its installed mods no matter what I did. I'll be attempting to try and get Oblivion working properly with MO this time; Wrye Bash install worked, but was horrifically clunky in its conflict handling and generally everything, compared to what I'm used to now from MO. Since a bad mod's just made the whole thing blow up, forcing me to nuke my entire game, I'll be starting from a fresh install. A friend has already managed to update her previous MO-Oblivion setup to the current version of MO and have everything work, so I know it can be achieved. Will be taking notes on the process this time.

The section on the virtualisation and the VF is fairly understandable; but my command of English IS fairly high as is my understanding of the terminology surrounding the programs used, so... Still, the terminology used can't really get much simpler than this; if they can figure out how to use MO, your readers should be able to figure out what you mean, and it is after the Advanced tab. I'd also like to add my voice to suggestions for subpages to tidy up the Advanced tab: currently finding anything in there is difficult and messy. Slightly off topic: Extending the section on running other games with MO, if possible would also be appreciated-- might need a subpage of its own I think. Personally, I've just gotten into playing and modding Oblivion, and was using Wrye Bash to do so at first, because I had trouble trying to get Oblivion working with MO due to lack of knowledge on the issues that cropped up. Even now I'm still working out kinks, and the process has been difficult, because the relevant scraps of info are scattered everywhere from here to the Nexus and out of date in some cases.

D'oh! Thank you. I am the derpiest derp to ever derp, really. How'd I miss that? :facepalm: ETA: I forgot to ask earlier, but should I unpack all my Oblivion BSAs like I did for Skyrim? I had that mysterious archive limit issue with MO in Skyrim, and wonder if it might happen again in Oblivion.

Currently attempting to get a brand new install of Oblivion up and running in a new MO install with a handful of mods. What puzzles me is that when I go looking for a setting in MO to see if archive invalidation as an option is on, I don't see it. I see there's a "backdate BSAs" button in the Workarounds section, but I've also seen it said by Tannin on the Nexus forums that backdating the BSAs isn't a sufficient replacement for AI outside of Skyrim. I understand that Wrye Bash uses BSA-redirection to get around the issues archive invalidation is supposed to prevent in Oblivion. What I'd like to know now is that if I start playing Oblivion now, with all my mods cleaned and installed as usual for MO, without backdating any BSAs or suchlike, will I run into trouble down the road? Thanks!

I'm already at 1k for most things, I don't crash often either.

Uhm, the BOSS GUI is already a part of the BOSS program by default. BUM actually can do more than the BOSS GUI can, that's why we use it. Sure BOSS GUI is easier to use, but when you're managing rules for more than say, 10 plugins, BUM's usefulness shines. Besides, all of what you use BOSS GUI to do, BUM can do as well, albeit not quite as quickly as the native interface.

Sorry I took this long to get back to you-- haven't been on here in a bit. CNHF support for various vanilla and DLC armors is still pretty much in progress: what you see is what you'll get on the mod downloads as well as links to other conversions (soutear and MistriliaSysmic have done a few in addition to Calyps's ongoing work). Meanwhile, vanilla armors and most modded armors will work fine, as long as they're not revealing/skimpy. CNHF 2 when released will be providing support for UNP textures and armors; thus most popular armor mods that support UNP/UNPB will work fine with CNHF, though the body shape will necessarily follow UNP's. This however does mean that the current version 1 armor conversions will need some fixing up as well to fit properly with CNHF 2. Not sure when v2 will arrive, to be honest. I think Calyps is still stomping out some mesh quirks. Meanwhile, those looking at body texture replacers might want to look at Nuska's thoughts on the subject: https://nuskamods.tumblr.com/post/55274076012/oh-lots-of-****-i-learned-from-this-entire-body

I'm using Better Males, but planning on trying out Schlongs. Meanwhile I substituted CNHF for UNPB, and am very happy with that choice.