Striker879

How large is your save after this? I have the 'collector disease' (long story) ... my ESS saves generally run around 5450 to 5500 KB and the OBSE co-saves about 620 KB. When I enter a cell that contains a lot of my 'two legged trinkets' it will take a while for the cell to load (almost all of those 'trinkets' have been Blockheaded, which doesn't exactly speed up the loading process).

With your item selected in the Render window hit the F key to ground it.

Loading your mod below the bashed patch is a troubleshooting and mid-development trick (I know it's a pain to re-BOSS and re-bash each time you want to quickly check something). Putting your mod back into it's correct spot in your load order is a step for closer to the conclusion of finalising your mod. If your game is using one of the Better/Open Cities mods then you will need to have those as a master for your mod (either via CSE or the WB ESMify/ESPify methods). That will also dictate load order (your mod will need to lower than it's masters). - Edit - When your character enters one of the Open cites (and probably one of the Better ones as well ... not sure don't use any of them myself) you aren't entering one of the vanilla (i.e. Oblivion.esm) city worldspaces.

The first one is for seeing stuff like forts, ruins, buildings etc. in the distance (like how you can see the IC and White Gold Tower from pretty well anywhere). The second does similar but for the landscape (i.e. the actual ground you walk on). Two different things.

A suggestion ... remake your mod using a vanilla tree instead of one from Lush and Gaudy and see if that works. If it does work then your problem is related to how you are using the Lush and Gaudy resource, if it doesn't work then your problem is related to how you are trying to add the tree. - Edit - If it has a check in Wrye Bash then it is activated. For testing make sure your new ESP is below the bashed patch in the Mods tab list (which will ensure that WB isn't to blame for the missing tree via something in the bashed patch).

What Construction Set version are you using? Mods made with CS version 1.0 will be silently ignored by game version 1.2.0416 ... you must use version 1.2.404 of the CS. What was the master of your mod, Oblivion.esm? If in fact it was another mod's ESP (e.g. JoesReallyReallyCoolTrees.esp) then you are running into something called mod de-isolation (in a nut shell another mod's ESP can't be the master for your mod's ESP). Either use Construction Set Extender or learn how to ESMify/ESPify using Wrye Bash. - Edit - After seeing your mod description I think you need to spend some time studying up on mod de-isolation ... De-Isolation Tutorial will get you started.

I'm by no means an expert on reading Message Logger logs, but it seems to me that the warnings in the first block are related to OOO (mod index 03 is the ESM and index 52 is OOOExtended). Next comes some Better Cities warnings (mod index 06) followed by more OOO warnings. The block of warnings that comes after the first block of debug messages may be related to your LOD generation (mod index seems to be 00, which is Oblivion.esm). Can't be of much help deciphering the script warnings section ... no mod index to help ID where the source of the warning is (some of the script names suggest your Harvest Flora mod to me). If it was me, I'd start by uninstalling everything OOO related and Better Cities related and see how that affects the Message Logger log. That said, here's some other general observations ... Installing mods is a process, and in my experience nothing has more value in that process than thorough testing at each step of the way. Simple mods can make do with just enough testing to make sure the mod has loaded correctly. More complex mods require considerable testing to insure that they are working properly along with your load order up to that point. Mods that have settings that can be adjusted (most often via an INI) take the longest to test in my experience (unless you are satisfied with whatever it's default settings give I suppose ... not something I'm well known for). I was easily more than two weeks getting my current character's load order set up and tested. To an outsider many of my 'test sessions' would have appeared more like 'play sessions' due to their length, but in each of those cases I was starting the session from my outside the sewer exit testing save and exploring a specific aspect of the current setup. Because of the time spent testing as I installed mods I had a very good feel for how each mod affected game performance and stability. After the load order was set it was only small tweaks to the INIs for Realistic Fatigue + Basic Physical Activities to get their interaction fine tuned to my liking (but my testing had given me a very good feel for how they interacted and what each setting affected). Not everyone has the desire (nor the time) to 'be Striker', but everything you put into working in that direction will have benefits. Now after all that, something I held off chipping in because it may or may not be relevant ... In my own game I occasionally run into exactly what you've described (repeatable crashes at exactly the same spot). Bottom of the hill coming towards Bravil, just past where the bandits hang out is one. I have done the same as you, and taken a circuitous route around the 'crash site' and then been able to continue without problem. Sometimes I've observed a particular NPC just coming into the area from the Leyawiin direction. I've done some test sessions where rather than try to pass the 'crash site' or bypass it I've just chilled until the NPC comes into sight past the Bravil gate and it seems to then allow me to pass the spot. Other times, in other 'problem spots' (e.g. rounding the Anvil city wall going towards Fort Strand) it only takes an exit to desktop and load the save and all is good. There are certain places on the map where I will try to remember to make a save before passing a certain point. Now I consider my game 'stable' by Oblivion standards (at least now that I have more capable hardware ... the load order started out on 2 GB RAM and an 896 MB video card ... 8 GB RAM and 4 GB video makes such a nice difference). I admit I have made INI selections on one mod that aren't recommended by the original mod author (NPCs Yield - Refined), and at times I'm certain that I've had crashes related to those choices. I'm also a great one for 'console necromancy' (along with amassing collections of bandits, marauders, conjurers and necromancers ... I am the embodiment of 'save game bloat'). My point is that between mod selection, game setup selections and gameplay choices we will affect the stability of a game that isn't known to be rock stable in vanilla flavour. Find a balance point that you find satisfying. - Edit - Something else that may be relevant ... the Message Logger log is chronological. Right at the end (timestamp 17:51:45) are a bunch of script errors. Most seem to involve AASkins1Product if you can figure out what mod that comes from (other script names associated with it suggest Harvest Flora).

The only ESPs that Seamless for OCOv2 includes are replacements for the extra ESPs added by EVE, and I seriously doubt that those will touch males at all. The only option for you that I know of is to fire up the Construction Set and try to fix what you want without breaking anything else in the process (not a simple task). You may be able to fix just the height using TES4Edit ... can't say for certain as I've never tried something like that in TES4Edit myself.

Right you are ... just looked at it in TES4Edit and you can see that Wood Elves are male height 0.90 weight 0.95 female height 1.00 weight 0.90 in Oblivion.esm while in OCOv2 the male height is changed to 1.00 (with male weight and female stats remaining vanilla). With the current bashed tags assigned the OCOv2 changes are carried over into the bashed patch. I do see bashed tags Body-Size-F and Body-Size-M listed in Wrye Bash Advanced Readme.html but can't really say how you'd apply those in the current situation (i.e. can bashed tags be applied to Oblivion.esm??). I know that editing anything to do with NPCs in the Construction Set is a minefield morass of unintended changes happening once to touch one thing.

In the Wrye Bash Mods tab right click on the column header named File and select List Mods. In the dialogue box that opens select everything in the box from the start of the spoiler tag (including the square brackets) to the very end and Ctrl+c to copy ... then in your post here Ctrl+v to paste it into your post.

Think you'll be looking at either TES4Edit or the Construction Set ... but are you certain it's OCOv2 to blame? The reason I ask is because this is the first time I can recall this issue being raised in relation to OCOv2, plus I use OCOv2 and different races have different heights (Altmer are tall, Bretons are short etc).

According to Tiawar (the author of EngineBugFixes) it was meant to primarily affect custom armor that some mods add to the game that cover all of the slots, same as the Black Hand robe does. Read Tiawar's reply to Blackhole11 at the top of this page.

Looking at the UESP Wiki page Tes4Mod:Script Functions there is SetItemValue which accepts a single integer as a parameter. I've never tried it myself, but my guess is you'd need the refID of the item you wanted to change, not a simple thing to do with a clothing/armor item in game using the console. The simple solution is to create a mod giving the Black Hand robe a proper value using the Construction Set.

Here's the one I used myself. My own tests indicated that until I ran it on both obse_loader.exe and Oblivion.exe it didn't make any difference in the reported memory usage in Task manager (i.e. when I ran it on Oblivion.exe alone it made no difference when running the game via obse_loader.exe). Note that I run the disk version of the GotY ... can't say for certain how that would translate to other versions such as Steam or GOG.

HUD Status Bars (or if you prefer HUD Status Bars Enhanced) has an optional compass designed for DarN, amoung other things. Edit - This may be of some help.

Did you run the game before installing any mods (and the UOPs are just mods)?

Will the ability to page back through recently edited/added mods be implemented again? Currently the new layout's New This Week only shows that ... new this week. It was nice to be able to work back through the pages to access a non-tracked mod's page without needing to wrestle with Search.

Have a look at the Bugs section near the bottom of this UESP Wiki page.

I'm another one who has read your readme in the past yet somehow missed your reference to Lucien (just re-read that section of the readme). This goes right along with all the "Vilja won't wear such and such" or "Vilja keeps saying I'm naked when I'm wearing such and such" comments from Emma's mod page. The answer was always the same ... zero value items screwing up the works. Never could understand the gameplay value added by zero value stuff. Now if there was some way to get NPCs to not equip their armor when they go to bed and have a sleep package that includes unequip weapons and armor flag ... (if you want an example of the stuff you need to do to get them to not equip armor before bedtime take a look at the scripting David Brasher needed to do with Olga Companion Mod)

Well that got me poking through the CS ... turns out there are actually three Lucien references used in the game. Lucien refID 177d2 is found in the DarkBrotherhoodHoldingPen (which is located roughly half way between Nenyond Twyll and Nisin Cave but far under the playing surface), refID 2fd77 is located in Fort Farragut and refID 34b0 is located just inside the Anvil city gate (Anvil World, Anvil Exterior 07). Looks like the UESP Wiki missed one. As far as I could tell the Lucien you first meet is refID 177d2, refID 2fd77 is the Lucien you meet at Fort Farragut a the start of The Purification quest. What is a bit of a mystery is the purpose of the third Lucien refID 34b0, which is the only one that doesn't use the baseID 244ed as a parent (it uses the 34af parent). At no point (as far as I know) will you ever meet up with the refID 34b0 Lucien (you are sent to Anvil by the Farragut Lucien but told to meet him at Applewatch). In looking through the scripts looking for clues I saw a lot of commented out stuff from when they were working on getting the quests to work correctly ... maybe the 34af/34b0 Lucien is a leftover from their WIP on the DB questline. In any case looks like my theory of a mod's script mucking things up wasn't very good (in as far as the refID 177d2 Lucien goes ... he's as vanilla as they come).

Continuation from the Bevilex' mod list mod comments discussion ... Just to clarify, my 'solution' wasn't a 'scripted' solution. It is simply a console command workaround. Your use of the term 'scripted' got me thinking though, and I believe I know why FormID Finder and TES4Edit aren't showing any mod touching Lucien (which is supported by the refID you posted ... if a mod ESP was affecting him that refID would have something other than 00 as the first two digits). What I believe is happening is you have a mod in your load order that uses a script to disable the original Lucien (who has baseID/formID 000224ed and refID 0002fd77 ... baseID is the parent object of the reference object you see in the game) and then using the script places a new Lucien in the game. It probably still uses the original baseID as parent, or possibly not ... I'm no scripter so I can't say for certain how you would/could go about that. So what I'm saying is the mod's script disables Lucien refID 0002fd77 and then creates a new Lucien who has refID 000177d2. If the mod disabled the original Lucien and then created a new one using the Construction Set and an ESP, his new refID would start with the first two digits of that mod's position in your load order (so if it was fifth down in your load order his refID would be 050177d2). All this doesn't get any closer to resolving your situation in a more 'non-workaround' way. Only way I know to identify which mod is load each of your mods in the CS and examine each of their scripts looking for one that touches Lucien ... have fun doing that (just kidding ... not something I'd be willing to do if my 'workaround' solution worked).

In my opinion 'obsolete' can also mean 'we want you to buy this new thing' (which doesn't necessarily have anything to do with the 'obsolete' thing not working). I live in the World of Salt, and use many grains in my daily explorations and discoveries. By default the game uses date stamps to determine which thing should be used. For ESPs this works flawlessly. The vanilla game, however, will relentlessly use it's assets from the vanilla BSAs in complete disregard for date. The earlier methods of archive invalidation used non-date related methods to work around this, but they each had problems that required ongoing correction by the user. Then it was discovered that the game only seems to care about the first BSA file found in the list of BSAs in Oblivion.ini (found at SArchiveList in the [Archive] section). What BSA Redirection does is put a dummy BSA with a single unused file in it at the start of the list, and magically the game then decides to use date stamps to determine which assets to use (amazing the stuff I learn following along on DrakeTheDragon's posts). The best part about BSA Redirection is that it requires no ongoing tinkering to keep it working.

If Pk's suggestion doesn't fix things all I can suggest is to start out with a completely vanilla re-install and install one mod at a time and test thoroughly in between. When you add one mod to a working game and then it breaks knowing where to start troubleshooting becomes a trivial task.

Use BOSS to sort Oblivion load orders.

The vanilla game BSA dates will need to be changed for certain ... not sure about whether or not Oblivion.esm will need to be changed but I doubt it will cause any grief set to the same date in year 2006. The dates set on all of the ESP files (whether from mods or from DLCs) will determine the load order. Best bet is to use BOSS to take care of them. I have used File Date Changer 1.61 in the past and it worked well.