SkullKnight

Thanks, that's good to know!. If I end up having too much free time, I might try taking a look at some of the mods that ended up getting official conversions and see if they managed to get compressed BSAs to work - and if so, how they differ from my version.

So I've done a few oldrim conversions for personal use and come across some strange issues that I haven't seen mentioned in any conversion guides. I've been unpacking the original mod's BSA, optimizing the appropriate meshes using ousnius's tool, and then repacking the mod's files using the new Archive.exe included with the SSE CK. The ESM/ESP were loaded and re-saved in the new CK with the multiple masters fix applied, and I verified that records were updated to version 44 in xEdit. However, I ran into some reproducible bugs that *appeared* to be caused by me compressing the new BSA while repacking. The converted mod failed catastrophically - CTDs, non-interactable NPCs - if I compressed the BSA, but appeared to work fine if I left the BSA uncompressed. I'm going to use Wyrmstooth here as an example. While using the compressed BSA, I loaded a save file at the Solitude docks and journeyed to the island, resulting in a reproducible CTD within 15 seconds of arriving. However, when I used an uncompressed Wyrmstooth.bsa with the same save file and ESM, the CTD was gone and I could go to the village and start the next quest with no issues. I've seen plenty of converted oldrim mods that use compressed BSAs successfully, so I'm thinking that it's probably something I'm doing wrong on my end. I'm not running short on hard disk space or anything, but any help in figuring this out would be appreciated lol :).

Ok thanks. Yeah I'm lvl 46 and completed most major vanilla and dawnguard quests, so theres a large amount of data to keep track of. I'm just hoping my game will hang in there when I add the dragonborn DLC.

My save file is around 15mb, which I decided was a bit too much. First, I waited 30 days in an interior space for cells to reset. It didn't have much of an effect on my save size. Then I picked up the items I didn't want from my house storage chest (possibly around 100 separate items), stuffed them into an empty container, and ran "removeallitems" on the container. The items went away, but the size of my save file didn't budge. I'm thinking that either items in a container contribute minimally to save file size, or that "removeallitems" doesn't purge the items from save data. I'm also not running any mods that are known culprits for causing save file bloat (well, that I know of). Anyone have suggestions for what else I could do? I'm not getting CTDs due to save file size yet, but I'm concerned that it may become a problem in the future.

The package I downloaded was labeled "FCOM Convergence 1.00.7z", so I think its just the internal numbers werent updated. If all else fails, I can reduce it down to just OOO or MMM or something and see if I can make it run.

I think the version I installed was FCOM 1.0 (This). The guide I used was: Here. I do have a couple patches that are listed as "worked on 0.99, not yet confirmed on 1.0", which I could try disabling to see if it fixes the CTDs (not now, as its getting rather late :/). However, is there anything that looks glaringly out of place in my mod list/load order? Or perhaps I have an incorrect bashed patch config?

So recently I installed Oblivion on this computer and decided to install mods on it. I installed UOP, then FCOM, then my other mods before making a new game. However, I found to my dismay that when I walked into an exterior cell, the game would just CTD. It seems to work fine if I'm indoors or inside a city though. I found that only if I disable FCOM entirely, I can walk outside without my game blowing up. At this point, after hours of attempts, I still don't know what exactly is the culprit. Load Order: I took off the OOO/MMM compat patches for COBL because I read that they were outdated. Even with those enabled, the game still crashes though. Help would be appreciated.

Im not aware of any mods that cause freezes rather than straight CTDs, but keeping the ini settings should be better than not using them (unless you did them wrong, of course). Without the ini edits, I was getting rampant freezing even on an unmodded game. Did you edit the right file and put the edits in the right place (theyre under "General")? I am really not sure what fallout_default.ini in the install folder does, so I would suggest you change that one back. Only make edits to fallout.ini in the My Games area.

Extracting a whole archive into data is generally a bad idea, as some mods may have several layers of folders inside the archive. Extract all of the needed plugin files (esp, esm) and resource folders (meshes, textures, sounds) into "Data". If the archive contains a fomod folder, then FOMM should be used to install it. The only files that will show up in the launcher are the plugin files (esp, esm) located directly under the "Data" folder.

Im running windows 7 and I always install games to the default location with no problems. I just select the whole game folder and give all users full control so UAC doesnt get in the way. That has the side effect of letting all users edit it, but thats fine for me cause my comp has no non-admin accounts lol. The exclamation marks definitely mean missing mesh or incorrect mesh path. So, either the files arent there, or the game cant find them (probably in the wrong place). I assume the mods installed with FOMM have everything in the correct place, so I would go ahead and look over the other mods for file locations. Some mods include the Data folder, while others directly contain the Meshes and Textures folders, so you should watch out for that.

What version of FOMM are you using to install MMM btw? Version 12.x is known to cause weird texture issues due to some scripted install incompatibility, so I would suggest using 11.9 to install MMM. Some of the texture files dont install properly with 12.x, causing the problems you described. It doesnt have anything to do with archive invalidation. Dragging and dropping would also fix the problem.

The file you should be editing is "fallout.ini", located under <User>\Documents\My Games\Fallout3. bUseThreadedAI is a boolean, so "2" would be an invalid value. You have to add the line iNumHWThreads=2 yourself, as its not present in the ini by default. Just press enter and add it right under bUseThreadedAI=1. So, when done it should look like: <other stuff> bUseThreadedAI=1 iNumHWThreads=2 <other stuff>

Scripted mod packages made for the older versions of FOMM may have issues installing on the newer 12.x series, due to some new processing fixes. Until those packages are updated to work with the newer versions, you may need to revert back to FOMM 11.9 to install them, or install them manually.

So, is the game freezing or crashing? Freezing is a common problem when running FO3 with a quad-core computer. Using the following fallout.ini settings generally fixes the problem: bUseThreadedAI=1 iNumHWThreads=2 Crashing can be caused by a variety of things. Bad data files or load order can cause crashing, as well as running out of RAM. Automatic sorting is usually ok for load order, except for the mods it doesnt recognize. I see that you have a patch at the end to resolve conflicts. That should help with preventing problems as long as its done correctly. I personally recommend http://www.fallout3nexus.com/downloads/file.php?id=11336 for dealing with merging stuff and resolving conflicts. With a 64-bit OS, the large address aware patch can help with RAM-related crashes. It can be done on a 32-bit OS as well, but some other adjusting will be needed.

Usually a crash on launch is caused by a missing master file. Go through all of your mods and check to see that every active plugin has its required masters loaded as well.