rolandito

I'm probably among the last of the Legendary Edition holdouts, but as my kiddos are approaching the point where Skyrim becomes age-appropriate, I'm considering using SE for their installations. I'm not remotely interested in any of the Anniversary Edition update content, so I purchased just SE from GOG (currently $7.99!) My question for the community is around which STEP SE guide should I base my builds on? Would it be easier to go with v2.0.0 and update individual mods in the guide as appropriate? Or to follow the latest v2.2.0 guide and make manual adjustments for the "missing" (ugh) CC content? I'm not a mod author, but I am a programmer and have been working with all the modding tools that we all know and love for years; which is to say that manual conflict resolution doesn't scare me, but I'd rather know up front whether the juice is worth the squeeze. Thanks in advance for your thoughts and opinions. Donning my flamesuit now!

Anyone have thoughts/comments on their experience running Realistic AI Detection in STEP LE? I see that it's part of the loadout for STEP SE and wondered if there were some specific conflict or other reason it wasn't included in the LE guide?

I just reinstalled LE using the STEP v3 guide a few weeks ago and was successful on first launch (to my surprise). Post your modlist & load order, I'll compare against mine.

In Section 16 of the STEP:LE guide, the Font Overhaul mod should be removed, as the mod author has hidden the LE version on Nexus. https://www.nexusmods.com/skyrim/mods/72015

I'd like to recommend this recently-released mod be tested for inclusion in the STEP portfolio. It's pretty phenomenal work. https://www.nexusmods.com/skyrim/mods/82468/?

I just installed the latest USLEEP and update to the STEP Compilation + Patches (2.2.9.2m) and I'm wondering whether I need to re-run the DynDOLOD processes to regenerate its data? If so, is this something that needs to be done with every update?

This. You video card just doesn't have the muscle to run STEP. Skyrim is old, but your card was already ancient when the game was first released. Mine is a 4-year-old nVidia GTX660, with more than twice the memory bandwidth and thrice the texel fill rate as yours...and it barely runs 55-60fps consistently.

Zarok, I ran into a similar issue. Assuming you're doing an EXTENDED installation, and that you've installed SMIM and RFF, below is the list of plugins that the STEP Compilation installer is checking for in order to mark the patch as eligible: Dawnguard.esm HearthFires.esm Unofficial Skyrim Legendary Edition Patch.esp Clothing & Clutter Fixes.esp Cutting Room Floor.esp Guard Dialogue Overhaul.esp Invisibility Eyes Fix.esp Weapons & Armor Fixes_Remade.esp Complete Crafting Overhaul_Remade.esp RealisticWaterTwo.esp aMidianBorn_ContentAddon.esp Elemental Staves.esp ExplosiveBoltsVisualized.esp Animated Weapon Enchants.esp DeadlySpellImpacts.esp dD - Enhanced Blood Main.esp Book Covers Skyrim.esp AOS.esp Improved Combat Sounds v2.2.esp ADS.esp Bring Out Your Dead - Legendary Edition.esp TheChoiceIsYours.esp The Paarthurnax Dilemma.esp BetterQuestObjectives.esp I think I had disabled the "Invisibility Eyes Fix" on my installation, which was causing the installer not to flag the patch as eligible. Once I re-enabled that mod and re-ran the installer, it worked as expected. To uninstall a mod in MO, just find it in the left-pane list, then right-click it and select "Remove Mod." EDIT - Saw you tagged the post as STEP:Extended, so I changed the plugin list accordingly.

Some more experimentation: I disabled CBBE, Bodyslide, and Sporty Sweat (just a specular map), then started a new game. I picked the Breton female character and played to the point in Helgen Keep when your hands are cut free. Then I cheated myself an ebony helmet and tried to equip it. No dice, hair just vanished. I pulled up the racemenu and cycled through the races, and the helmet rendered just fine on every damned one of them except the Breton female. Wondering if it might be some sort of cached data issue (since my main character is a Breton female), I started another new game and chose the default Nord female and repeated the whole process. This time the helmet rendered fine on ALL races, including Breton. Curious, I tried with a Guard Helmet, since that one causes only the top of the hair to vanish, leaving the longer fringes in place. The Guard Helmet does not render for any of the humanoid female races, but it renders fine for the Argonian & Khajiit females, and for ALL of the male races. I then loaded up my current game character in Breezehome, used racemenu to change her to the default Nord female with an ebony helmet (rendered fine), then walked her outside. I called up the racemenu again and switched her back to a Breton, albeit the default one. The helmet rendered just fine. I called up racemenu again and made a few changes to the nose/chin/hair using the sliders, and when I tried to equip the helmet, it was back to Mr. Clean. I repeated the process, only this time I made the slider changes to my character while the ebony helmet was equipped, and it seemed to work fine. So I have no idea what's happening.

Thanks, Greg. I actually did read and follow the advice in Nazenn's post prior to reporting the issue. Most of the mods I've added atop Core are the packrat mods (General Stores itself, plus the mods for player homes that enable GS activators), and a couple of gameplay mods (Thieves' Guild Redone, Helgen Reborn). AFAIK, nothing modifies any armor in any way. I noticed the bald-head guards before those were installed, though. I wanted to play the first part of the game as the "vanilla" experience, so I didn't install them until after I'd already purchased Breezehome. I've gone through with TES5Edit, loading all plugins and looking for conflicts, but not knowing the full details of how the engine renders things in-game, I only knew to look for the obvious, such as a conflict with the Ebony Helmet or Guard Helmets (see attachments). What else should I be looking for? Thanks again for any advice.

I think it's a time-based limitation. I've been able to edit posts within 30 minutes of original posting, but coming back hours later the option to edit is no longer available.

Please disregard this thread. The issue is with certain helmets, not actor hair. I've opened a new topic with much more specific detail.

What I thought was an issue with one of the hair mods seems to actually be a problem with some of the helmets. Specifically, none of the hold guard helmets render on female guard NPCs. Nor do they render on Lydia, nor on my Breton female player character. Instead of a helmet appearing when it's equipped, the actor's hair disappears. I went to the Riften barracks and found two female guards sleeping with their bald heads (i.e. their Riften Guard Helmet was equipped), and ran this battery of tests for all of the helmets that are modified by the Improved Closed Face Helmets mod: Steel Plate HelmetDwarven HelmetEbony HelmetDaedric HelmetGuard Helmet (Whiterun - 21615 )Dragon Priest Mask ( Morokei - 61CB9 )Nightingale Hood ( NPC version - 487D8 ) All of the helmets rendered properly, with the exception of the guard helmet and ebony helmet. This was also true when I tested them on my player character and on Lydia. When equipping the ebony helmet, the actor's hair completely vanishes, leaving them looking like Mr. Clean...but equipping any of the hold guard helmets results in a bald dome surrounded by long stringy hair, making them look like Friar Tuck or a reverse-Skrillex. Interestingly, the ebony helmet DID render properly for one of the female Riften guards, but did NOT for the other one (she had the "bald head" result). Guard REFID 4583F = Successful render of ebony helmetGuard REFID 45841 = NO render of ebony helmet (actor's hair vanishes only) I followed the STEP:Core mod installation instructions to the letter. LOOT has run, Bashed Patch has been created, etc. I don't see any obvious conflicts when I load everything in TES5Edit, but I'm not a mod author or expert. I'm stumped, and would appreciate any guidance. ModOrganizer profile data is attached.plugins.txt modlist.txt loadorder.txt

It gets weirder... I went to Jorrvaskr and used the console to add and equip each Companion with a standard (no enchantments or improvements) Ebony Helmet. They all rendered as expected, both males and females. Aela and Nadja are both Nord women, and Ria is an Imperial. The helmet rendered just fine on their heads. I tried again on Lydia, who is also a Nord...no go. No helmet appears, just her bald chrome dome. Same with my Breton character...looks more like the Last Airbender than the Last Dragonborn. I'm at a loss with this lack of consistency. Any thoughts on how to isolate the problem?

Thanks, TA. Yep, I've double-checked the mod installation, and re-run LOOT just for grins. No good. Playing around a bit more, it seems that some of the female armor helmets aren't rendering in-game. Specifically, the female holds' guard helmets and the ebony helmet (so far). The male helmets don't seem to be affected. I tried switching to 3rd-person view and putting the ebony helmet on my own (female Breton) character, and no helmet appeared...but her hair vanished and she stood there looking like Mr. Clean.

OK, I think perhaps it's something to do with the Closed-Face Helmets mod. I just gave Lydia the ebony helmet that I looted off a mouthy mercenary, and instead of the helm, I see a totally bald-headed Lydia! Seriously, she looks like Telly Savalas!

I just did a STEP:Core 2.2.9.2 installation, and I've got a weird issue that doesn't seem to have any rhyme nor reason. Some of the guards are missing the hair from a dome on top of their heads. Almost like someone gave them a Friar Tuck buzz + a mullet. I tried reinstalling both the Hair mods from the Core wiki, but no joy. Still got bald-headed hoes strolling around my holds. Any ideas WTF is going on?

This may be the issue. A vanilla installation of Windows (you didn't specify the version) may not have the required .NET framework and/or XML parsers needed by the FOMOD installer. I'd double-check that you have the latest .NET service pack installed, as well as the appropriate MS Visual C and XML parser packages installed.

Thanks, Angel, I'll do that now. Looking more closely at the deletion timestamps in my desktop recycle bin, it looks like that "resources" directory may be getting nuked on process termination, not execution.

I'm chiming in here because I just had a similar experience. I'd deleted Skyrim for a long time, as my last character was around Level 140 and I needed the space on my little 120GB SDD. I just did a STEP:Core installation, and my character was Level 3, still in the wilderness between Helgen and Riverwood. I quit because kids/life, and when I tried to re-load the savegame, I got the lovely ILS behavior. I was able to load an earlier autosave from inside Helgen Keep, but when I tried to quickload (or regular load) my current game, the load screen actually froze just as the smoke appeared. The behavior was reproducible every time I tried. The solution is an SKSE plugin called Safety Load. Apparently, the TESV engine's memory allocation function is vulnerable to unchecked race conditions, which lead to the ILS behavior. This plugin replaces it with the regular C-language malloc(). Worked like a charm.

I don't use AV software. I suppose it's possible that LOOT itself is doing this, as this whole installation is new from scratch (I've had Skyrim in mothballs for over a year). I'm guessing this is the relevant section of the MO.ini file you were referring to. I haven't changed anything from the defaults. [customExecutables] 1\title=SKSE 1\custom=true 1\toolbar=false 1\ownicon=true 2\title=Skyrim 2\custom=false 2\toolbar=false 2\ownicon=false size=8 3\title=Skyrim Launcher 3\custom=false 3\toolbar=false 3\ownicon=false 4\title=LOOT 4\custom=true 4\toolbar=false 4\ownicon=true 4\binary=C:/Games/ModOrganizer/loot/LOOT.exe 4\arguments= 4\workingDirectory= 4\closeOnStart=false 4\steamAppID= 5\title=TES5Edit 5\custom=true 5\toolbar=false 5\ownicon=true 5\binary=C:/Games/ModOrganizer/TES5Edit/TES5Edit.exe 5\arguments=-o:\"C:\\Users\\xxxxxx\\Documents\\My Games\\skyrim\" 5\workingDirectory= 5\closeOnStart=false 5\steamAppID= 6\title=Wrye Bash 6\custom=true 6\toolbar=false 6\ownicon=true 6\binary=C:/Games/TESV Skyrim LE/Mopy/Wrye Bash.exe 6\arguments= 6\workingDirectory= 6\closeOnStart=false 6\steamAppID= 1\binary=C:/Games/TESV Skyrim LE/skse_loader.exe 1\arguments= 1\workingDirectory=C:/Games/TESV Skyrim LE 1\closeOnStart=false 1\steamAppID= 7\title=DynDOLOD 7\custom=true 7\toolbar=false 7\ownicon=true 7\binary=C:/Games/ModOrganizer/DynDOLOD/DynDOLOD.exe 7\arguments= 7\workingDirectory= 7\closeOnStart=false 7\steamAppID= 8\title=DynDOLOD TexGen 8\custom=true 8\toolbar=false 8\ownicon=true 8\binary=C:/Games/ModOrganizer/DynDOLOD/TexGen.exe 8\arguments= 8\workingDirectory= 8\closeOnStart=false 8\steamAppID=

I've run into the bug/issue where I launch LOOT from within MO, and the window that comes up is an empty white box. It's unresponsive to clicks or keypresses, but it can be killed normally. I tried launching LOOT natively, and got the same result. So I reinstalled LOOT from its archive, and the problem vanished...for a while. After a couple runs, the white screen bug hit again. This time I went and looked at the LOOT installation before reinstalling, and I found that everything within the "/resources" subdirectory had been deleted. Sure enough, I found it all in my recycle bin. For some reason, MO decides to nuke that subdirectory during LOOT execution. Not always, though. I can't predictably reproduce the behavior, so I've no idea what's triggering it. It's easy enough to workaround, just re-extract the "resources" subdir from the archive...but it is an annoying PITA. Any of the MO devs care to take a look and/or shed some light on what's happening? FYI, my setup is: LOOT v0.10.3-0-g0fcf788_dev_Win32 Mod Organizer v1_3_11 Win7 x64, Core i5-3570 @ 3.4GHz, 16GB RAM, 2GB GTX660 Skyrim LE + STEP:Core

Close. Looking at the MSDN reference for memory limits in Windows, you can see that each 32-bit process running in a 32-bit Windows environment is limited to 2GB of virtual address space, or 3GB when the IMAGE_FILE_LARGE_ADDRESS_AWARE linker directive is used during build-time.  For 64-bit Windows systems, the virtual address space available to 32-bit processes is increased to 4GB when that same compiler flag is set. Since the TESV.exe CTDs seem to happen when memory usage gets around 3GB even on 64-bit versions of Windows, this leads me to think the guys at Bethesda incorporated some address range checking within their own code.  After all, it isn't Windows that's throwing allocation errors...Skyrim just exits.  If it were being caused by Windows, I suspect  (a) it would only happen on 32-bit versions, since that's where the 3GB process limit exists, and  (b) you'd see Windows throw an error message about TESV.exe attempting to perform an illegal operation. No, I suspect Bethesda set the address range checking boundaries internally during development to ensure compatibility with the limitations of the 32-bit Windows platform.  As a result, when some thread goes to perform a memory allocation that exceeds the internally-defined range, the main process exits (CTD). This could be alleviated entirely by Bethesda compiling a 64-bit version of TESV.exe, of course.  Absent that, it's anyone's guess what will or won't trip the internal program limit.  It's a minefield in there...just going by some of my Papyrus logs, there are lots of quest scripts that never get cleaned up properly during the game, and every one of them takes up CPU/vRAM.  I also suspect the high-resolution textures are likely to blame; not because the available hardware can't handle them, but because the EXE file isn't handling them efficiently.

Umm, no. Please do not post authoritative-sounding treatises on computer memory architecture without knowing the material yourself. Windows has never limited single programs to a fixed percentage of physical RAM. In the era of 32-bit architectures, Windows NT and its progeny used a virtual memory architecture that presented every process executed with 4GB of addressable memory space. In other words, each program believed it was running by itself on a machine with 4GB of RAM installed. How the virtual addresses mapped to the physical memory was handled by the Windows memory manager, and it often involved using hard-disk space as temporary storage (the paging file). As the concurrent running processes' memory demands approached the limit of installed RAM, Windows would attempt to swap more and more memory data to the paging file, causing thrashing and eventually out-of-memory errors that resulted in process crashes or system lockups. The 4GB "limit" existed because that's the maximum range that could be described (or addressed) using 32 bits when each unique combination of bits references a unique byte of memory. [2 raised to the 32nd power is 4,294,967,296] In the mid-'90s, the Physical Address Extension (PAE) architecture enhancement was developed that enabled CPUs to use 36+ bits for addressing physical RAM, up to 64GB...however, the Windows virtual memory addressing scheme remained at 32-bits, meaning each process could "see" a maximum of 4GB. In reality, each system required dedication of some memory for video addressing, memory-mapped I/O, and other system tasks, effectively limiting 32-bit personal computers to 3.0 - 3.5GB of usable physical RAM. Microsoft also introduced an artificial limit in their non-server 32-bit Windows operating system code that locks out addressing above 4GB. (See "3GB Barrier" for more detail.) In 64-bit land, none of this matters.  CPUs enter "long mode" and can address a theoretical maximum 16-exabytes of RAM when using all 64 bits, and the virtual process space in 64-bit Windows uses 48 bits for addressing, allowing each process to "see" 256 terabytes of available memory, while continuing to use mapping tables and paging file where needed to translate to physical addressing as needed.  There is no percentage limit of RAM imposed on running processes. The fact that I see CTD's playing Skyrim on my system (64-bit Win7 Enterprise on a Core i5 with 32GB RAM) means it isn't a system architecture limitation.  Understanding that TESV.exe is a 32-bit executable, the problem is very likely due to a memory allocation call being out-of-bounds in certain situations, but without knowing the compiler settings used to create the EXE file, there's no way for me to know for sure. Also, the location of any file on your hard drive has no bearing on how Windows treats the memory management for associated processes.  Moving your Steam folder out of "Program Files" simply alleviates issues that arise from the Windows7 administrator permissions model because that directory and its contents are protected.