keithinhanoi

I don't think it's entirely fair to make direct comparisons between JK's City/Town overhauls and ETaC. While they both make numerous cosmetic changes and additions, and add NPCs, the main difference is that ETaC makes significant changes to the positions of houses / buildings and adds quite a few as well. This does bring along compatibility concerns of course, which are mostly addressed in the amazingly long list of available patches. REGS is a guide after all, and as with any guide, it's up to each individual to decide to follow it exactly or not. In any event, to answer the question about whether ETaC is finished - the answer is definitely no, according to her, but it is fully functional in it's current version.

The thing is - if it was an MO issue, I would expect no replacement sound mods to work. However, when NomenNescio tried my test of a "mod" using renamed sound files extracted from Skyrim - Sounds.bsa, he heard the goat sound I had renamed to be used as a bow shoot sound. Then after I removed the timecode data from the three AOS bow sounds, which was the only thing different I saw in terms of the file format, they still didn't play for him. This says to me that it's something in those files that on his system, won't play in Skyrim - though keep in mind all of them play fine when using the "open" feature in MO to load them into VLC (his default audio player.) So, I can't rule out MO has something to do with it, unless the last test I sent is unpacked directly into the real Skyrim / Data folder, and then Skyrim is run without Mod Organizer. So, NomenNescio, if you still have test #3, can you try that? Copy the Sound folder directly into the "real" Skyrim / data directory. If you've cleaned out your /data directory to use MO, then there shouldn't be any Sound folder in there, so I expect no message about replacing the folder, etc. After copying that Sound folder into Skyrim / data, then run Skyrim using the Skyrim Launcher - don't run MO at all. If the bow shoot sounds play, then Mod Organizer is involved in some way, and if they don't play, then MO is not part of the issue. Troubleshooting should involve discovering what factors are not involved in the issue - Sorry that I didn't think of this test before!

Back again, with some initial feedback. First off, I LOVE the MCM menu ( ), and especially the addition of the compass settings. I've got a few suggestions about layout and functionality: The first thing I noticed is that the Compass Settings and Map Marker Options sections are trying to horizontally, while everything else is in vertical groups. So I suggest changing it to look something like this (excuse my GIMP hack cut-and-paste work): Organizing these sections like this seems more logical to me to keep groups of options in only one of the two columns (as divided by the grey center line). Another advantage is that organizing it this way opens up some space in the left column to re-work the Map Marker Options section. For that section, my suggestion is to change how those three global options are set. Either make it: a toggle button with the text "Global Marker Behavior" and the button text to the right cycles through "REVEAL ALL", "NO MARKERS", and "DEFAULT", or three tick box options, with select only one logic applied: Reveal all markers on map <> No markers <> Discover markers (default) <> In both cases, what is displayed or shown as ticked should match the current setting. In addition to changing the options GUI for Map Marker Options, I think there would still be room to add some explanatory text. In the least there should be text explaining the change will only take effect after the MCM menu is closed. It would also help to have text warning the user that the "Revealing all markers on map" option is irreversible ( - that's still true, isn't it?) Then down in the toggle settings for the specific groups of different kinds of markers, I noticed strange MCM GUI behavior. With most of the mods I use with MCM menus, if there's a toggle text option, you can click the text to switch the option again immediately, without moving the cursor. With your Atlas Map Markers menu, after I click to change the option for any of the marker groups, the focus halo for that line disappears, and I have to move the cursor away and then back to the line to toggle it again. It comes off as being confusing / unresponsive. Also - I wonder if it's possible to add "REVEAL" as a third option for the groups of markers? Or maybe that functionality is not built into the mod, and it's a reveal all or nothing situation? In the least, if the global setting of "No markers" or "Default" is currently selected, then the setting of all the specific groups of markers should change to display the same as well. This would be nice if the user just wants to set a few groups to the default - they could select the global "No Markers" setting to toggle all of the groups, and then change individual ones back to "Default". That's about as far as I got with it. I don't know if this test version is intended to work if dropped in as a replacement for the current (books-based) version in an already started save game, but I'll give it a try, in addition to starting a new game with it. I hope that all helps - this is great work, really appreciated!

Heads up, everyone - AOS v2.2 has been released. There's quite a few improvements since v2.1, and LoRd KoRn has tried to "polish" the sound even further in this new release. I've updated the installer - which is now BAIN (Wyre Bash) compatible, with thanks to a1t3rn1ty - and most of the patches. There's some new patches, too, and some important USKP fixes that came out after v2.1 are now rolled into the main AOS.esp plugin. Unfortunately, I missed something in two region records that should have been carried forward from Dawnguard to the Skyrim+DG and Skyrim+DG+DB versions of the AOS.esp plugin, so a hot-fix will be released as soon as LoRd KoRn is able to upload it. Due to this, I'd advise people to wait until tomorrow (Sunday) before downloading it.

@NomenNescio: That is really strange, and not what I expected. Because I re-saved those files, I totally expected them to play in-game for you. There must be something else about their format that isn't working. I'm quite busy this weekend, so it will take me a while to get back to you. By the way, AOS v2.2 has been released, though there's a "hot" fix coming soon, so if you were to try downloading it to see if it works any better, you should wait a day or so. I don't expect it to change anything, but I suppose it's worth a try - I know this has gone beyond frustrating at this point! :confused:

Great news, krypropyr - thanks for sharing this. I'll give it a try during a break between the piles of work I had to bring home!

That's the first I've heard that BSAs could overwrite loose files in Skyrim. I'd love a link that explains more about this phenomenon, just for future reference - thanks for the correction. @NomenNescio So, now we know that only the AOS sounds are not working for you. I looked at them in an audio editor, and discovered they have an extra "track" of information, which is a timecode. This is obviously not a problem for 99.9% of users, because people would have posted comments immediately, but maybe it doesn't work on your system for some reason. I have removed the timecode data from the AOS bow shoot sounds, and resaved them as .wav in the exact same format as before. So this is a third test "mod" to try, after removing test 2. You can grab it here. If the sounds in this third test, then I'd have to guess that there's something about the AOS .wav file format that isn't working on your system for some reason.

Yeah, no big surprises in your findings, kyd462, from everything I've read and my own experiences. I used to use all the multi-core / multi-thread .ini settings when I was using my iMac with a quad i7, but then after some discussions with the author of Queue, the author of SSME, and some deep forum scouring, I found that all the settings with HWThread should only be used if you've got a processor with 6 or 8 physical cores. The last update of Skyrim was definitely quad / duo core aware, and multi-threaded, so no other tweaks are needed. However, the bMultiThreadMovement and all the bUseThreaded_xxx settings, despite the apparent "boost" they give to game responsiveness, shouldn't be used, because TESV.exe already has all processes set as multithreaded that can be. By turning all the "threaded" options on, you are playing with fire because they run the risk of causing race conditions with threads that are dependent on each other, which leads to more frequent memory exception errors - in other words, more CTDs at very random and inopportune moments. On this point people could argue about it until the end of time, but I always go back to the logic of if they really made things work better without any crashes, those settings would be on by default. Just remember if you experience more frequent random CTDs, try turning these ones off and play for a while to see if things "calm down." Otherwise, if you are looking for settings to make your experience smoother and less "stuttery" and CTD-free, I'd suggest more testing with the following: ExpandSystemMemoryX64=trueSetting this to false reduces CTDs for some people. It will not, however, make things work any faster. I have done extensive research on what this setting does, and all it does is change where in TESV.exe's memory space certain heap blocks are allocated, to the "top" of the memory space if set to "true." The particular Windows system code that accomplishes this was only ever meant for testing application compatibility on 64-bit systems. ReservedMemorySizeMb=512According to Boris, in more recent ENB binary releases, things have been optimized such that this value can be reduced from the 512MB that was previously recommended. Try 256 or 128 to see if there is less (or more!) stuttering. VideoMemorySizeMb=16384The big question with setting this value so high is whether your system RAM ever actually gets used as VRAM while playing in-game. Boris has always maintained setting this to be the same as the amount of physical VRAM is the best way to go. In your case it would be 2048 (2GB, same as your VRAM). So that's something to try, if you haven't already. But if you use higher resolution textures, and usage of your 2GB of VRAM is getting maxed out often with this set to 2048, then it's better to set this above 2GB. How much higher shouldn't matter much with the amount of RAM you have. If you only had 6 or 8GB then it would be a concern. But I highly doubt that you'll ever see even 8GB of RAM being used by several instances of enbhost.exe, so there's little danger of using up all available memory.

Archive invalidation shouldn't have anything to do with this, because AOS doesn't include a .bsa archive. Okay. Well the goat sound is correct, and your results pointed out that I made a mistake when renaming the two of the three bow sounds, so hearing the goat a third of the time is exactly what you would expect. So, this means the problem is not that no loose file sounds are working - just the ones included with AOS. I've made a second test, which is simply just AOS' three bow fire sounds in a .7z archive. If you delete the first test, and install this one, again with no other mods on except Skyrim and the DLCs, then that should show if there's a problem specific to AOS' audio files on your system. These sounds work just fine for me when I try the same test, so in theory they should work for you. You can grab it < edit: link removed >.

Okay, sorry for the delay - I've been very busy with work. I've created a very simple "mod" which provides replacement sound files for the 3 bow firing sounds. The origin of the sounds is from Skyrim - Sounds.bsa, but I'm not going to say what sounds they are, so that way we can make sure it works! You can grab it from < edit: link removed >. Install it manually in MO (the box with CD icon in the top left corner), and then disable all other mods, even AOS, except for this test set of sounds, and Skyrim and the DLCs. When you go in game, try shooting a bow, and the let me know what you hear - if anything. Depending on what happens I think I may know what to try next.

Okay, well that shows that MO is loading the plugin just fine, but then although the sound files aren't corrupt, they either aren't being recognized or not allowed to play when they're accessed in-game. There's a remote possibility that the format of AOS' .wav audio files is different from the ones included in Skyrim's Sounds.bsa archive, and for some reason that audio format won't play on your particular system. Since AOS' sounds still didn't play even when you completely disabled the AOS.esp plugin, it would be helpful to test if "replacement" sounds extracted from Sounds.bsa play in-game as expected. I'm thinking maybe take a very different sound file from Sounds.bsa and rename it to the bow shooting sound(s) and then manually add that as a mod in MO to see if it plays in-game. If you want to try that, I could make a .zip file with a sound file to manually install like that.

By the way, "Guard", "Thane", & Daedric Prince are just cute "titles" STEP users have based on how many posts they've made. The actual username is just above that, in the lighter grey bar, here: Anyhow, let's review what you have confirmed up to now: The AOS.esp plugin does load correctly when active because you see the extra "Waterfalls and Rapids" sound volume slider in Skyrim's Sound Settings menu. So this tells us MO is working correctly as far as the .esp plugin is concerned. The AOS sound files exist in the AOS mod folder in your Mod Organizer/Mods/ directory You can see the AOS sound files listed in Mod Organizer's preview of its virual Skyrim /data directory, as seen in the Data tab of MO's right-hand pane. For example, you confirmed seeing .wav sound files from AOS listed in /data/sound/fx/amb/. When the AOS.esp plugin in is completely disabled (not just deselected) in the load order, sounds such as bow shooting sounds and footstep sounds still don't play. If you completely disable the AOS mod in MO, then the vanilla sounds play as normal.If all of these things are true, then it points to the MO .wav sound files as being the problem somehow. I suppose the next step is to try playing some of them straight out of Mod Organizer. Try this: In the Data tab of MO's right-hand pane, open up the /sound directory and find /sound/fx/wpn/bow/fire/There should be 3 .wav audio files in that folder, named wpn_bow_fire_01.wav, wpn_bow_fire_02.wav, and ...03.wav.Right click on each one and select Open / Execute to play them in your default audio player application for .wav files.Do you hear anything?If you do hear the sounds, then there must be something happening where Mod Organizer is not allowed to access those sound files to play them. I also would recommend to check one more time that when the AOS.esp plugin is active in MO, you see the "Waterfalls and Rapids" sound volume slider in Skyrim's Sound Settings menu. That is very important in terms of troubleshooting the problem.

Here's something to try and isolate where the problem is happening: Because many of the sound files AOS provides are replacements for "vanilla" sounds, they will still play even if the AOS.esp plugin is disabled. If you want to test this, to completely disable the AOS plugin, you should: double-click on the AOS mod in MO's priority list (left-hand pane) to open its mod info window click on the Optional ESPs tab click on AOS.esp and then click the UP arrow to move it into the Optional ESPs list. There should be no plugins in the available ESPs list at all. Close the information window and run Skyrim Try shooting with the bow because that is definitely one of the vanilla replacement sounds that AOS provides.If you're hearing a sound, then the next step is to disable the whole AOS mod and then listening for whether the sound is different (which would confirm that the AOS sound files were replacing vanilla sounds in Mod Organizers virtual file system. If yes, then the problem has something to do with plugins. If no, then it's likely the sound files. I just wanted to note here that as I am working with LoRd KoRn to update all patches for AOS, I can confirm that any relevant USKP fixes that have been added since AOS' last release in May will be incorporated in the upcoming AOS update.

I see that Moon & Star has been updated to v1.13 with a small fix, but more importantly, there is now a compatibility patch for Aurora Village (which was removed from REGS when M&S was added.) The patch includes landscape and navmesh fixes, so if you don't mind the two villages being rather close to each other, it is now possible to do so. However, note that if for some reason you are using Undeath (which is also no longer part of REGS), it's still not compatible with Aurora Village.

That patch is only for users of Interesting NPCs, LAL, and "Hearthfire Lakeview Manor expansions" (not sure which exact mod this refers to. And it requires starting a new game. From the file download description:

To add to Gandaganza, although there are many great lighting / weather mods out there, if you learn something about patching in TES5Edit, you can really make your own mashup, taking the best of what you like. I myself have combined: RCRN (without it's .dll based post-processing to pick up FPS)ELFX (w/ELFX Enhancer but not ELFX Exteriors)Expanded Skyrim WeatherSupreme StormsSupreme & Volumetric FogVividian 6.02 Vivid ENB (w/out any of the optional weather / ELE plugins)Only Vividian claims compatibility with RCRN, and for everything else, I had to make my own patch plugin that gets it all working together. And then I'm also using a bunch of diffuse texture replacer mods for the sun, clouds, rain, snow, etc. If you are using a weather mod you like, though, there are ways to get the nights darker, including specific mods for that purpose depending on which weather mod we're talking about.

Hi all, I just wanted to report on my experience with quest-based mod The Shadow of Meresis, since I just finished it last week. I really really enjoyed it, but after completing the whole thing, I found it produced Papyrus spam - two alternating repeated error lines, like this: I'm no fan of Papyrus spam that makes it hard to see what else is going on, so I used flexcreators Save Game Scalpel to terminate those two threads. However, I do notice other Papyrus error messages related to other scripts that begin with AHeb... every time I load a save game. So, I'd recommend playing through the mod on a set of save games you don't mind deleting afterwards, or at the end of your playthrough. It's a shame though, because at the end of the quest, you receive a nice "gift".

If you are using the increase heap memory argument, "-Xmx1024m ", then the first thing I would try is restarting Windows, because Java needs contiguous heap memory allocated, and it's possible that some .dlls (dynamically loaded libraries) are fragmenting memory when javaw.exe compiles the SkyProc patcher .jar that 1024 MB can't be allocated. Restarting may clear this out. If that doesn't work, the next step is to remove the "-Xmx1024m " argument for the SkyProc patcher in MO. Then try running it to just see if it can get to the patcher's options menu. If yes, then you could try lowering the heap memory amount to something like 512 and see if it will run. If restarting Windows and removing the heap memory argument doesn't help, then something else is preventing the SkyProc from starting.

Disagree on the advice to raise block 2. The truth is that the game never accesses more than 256 for block 2, even if you set it higher. Sheson tried to figure out why this is true, but that is still unknown. Personally, I've played with block 2 fully maxed out at 256 for hours without any CTDs. Back when Sheson first introduced it and many people were running tests, it was found that for many people (myself included,) block 2 only needs to be raised to 512 when block 1 (as reported in Memblock) is set to either 768 or 1024. You will know that block 2 needs to be raised if you set block 1 higher and then Skyrim crashes on start up. My advice is to keep Memory Block Log going until you've had a chance to run through a number of areas known to push the block 1 heap usage quite high, such as around Solitude and/or Windhelm. However, based on your Memory Block usage log, your skse.ini is fine. Which means your crashes are being caused by something else. Perhaps your enblocal.ini / ENBoost settings?

...and here we go again - preparing for another onslaught of mindless "Is XXX compatible with PerMa?" in every mod's comments thread. Unrelated to that - I wonder if the release date timing was intentional...

I would not say that you don't have a lot of VRAM. Regardless of whether VideoMemorySizeMb is manually or automatically set, it refers to the same thing - memory used for caching textures and object geometry (the 3D information about things being rendered.) If VideoMemorySizeMb is set larger than your physical VRAM, then - if needed - system RAM will also be used to cache data. Whether ENB actually needs to use that much memory for cached data depends on what mods you're using, especially including higher-resolution texture replacers, and where you are located in the game (because some areas require the loading of a lot more textures than other areas.) Although you are unlikely to use it all, manually setting your VideoMemorySizeMb to 16GB when you only have 16GB of system RAM is not a good idea. Skyrim itself has already claimed 4GB, and if ENB tries to use over 12GB of system RAM, well, there's nothing left to do but start using virtual memory (the Windows "swap" file) or just crash - and I haven't even accounted for the RAM that the Windows system itself needs to run. Keep in mind that the Direct X part of the NVidia drivers is probably allotting RAM itself, up to the same as the amount of your VRAM, so in your case, very likely Video memory would show up as 4095MB if you run DXDiag. So, a safe place to start with the VideoMemorySizeMb in enblocal.ini is setting it manually to be the same as your VRAM - so 2048. As a starting point. Then there's the ReservedMemorySizeMB setting in enblocal.ini, which you didn't mention, but which can affect things, as well as EnableCompression. If you do decide to reduce VideoMemorySizeMb and find that the MS VisC++ RL errors show up again, I'd suggest toggling ExpandSystemMemoryX64 from true to false, because it doesn't necessarily "expand" system memory, but rather it changes what part of the memory allotted to Skyrim (TESV.exe) is used for cached data. For some reason, this can cause Skyrim to crash for some people with it enabled and for others with it disabled. So it's worth a try changing it for troubleshooting purposes. Finally, to answer your question about the order of the settings in enblocal.ini - there's no problem with it not matching what you see from STEP, but it certainly makes it easier to check if your order matches. I think the STEP order of the settings is the same as is found in the original ENB binary download copy of enblocal.ini, if I'm not mistaken.

I've had a series of the Microsoft Visual C++ Runtime Library error in my game before, and it was also not associated with the Dawnguard Impatience of a Saint \ Arvak quest, because I was getting it on a brand new character. I investigated into it, and it was not at all related to MS Visual C++ being installed in the wrong way. It's just a memory exception error, and the MS VisC++ Runtime Library tries to "catch" the error, but it can't. It's pretty much the same as getting CTDs, really. That all happened to me before Sheson's memory patch fix. I was at my wits end, pulling my hair out. Still, even with the memory patch active, you can make Skyrim go belly up. It depends on what you have set for the memory fix values in the SKSE .ini, and also what your other ENBoost settings are in enblocal.ini. From everything you've described, it sounds as though either Skyrim's allotted RAM or your VRAM is getting gobbled up. If you post any contents of your .ini files, please kindly use the spoiler tags to avoid mega-long forum posts - thanks!

Make it three.... that video moves way too fast. I would have to rewind and pause a lot to use it. However it's a great way to see an overview of the steps.

(In my best Dr. Frankenstein voice imitation): It's ALIVE! So, will it still (theoretically) work with any mods in one's load order? This would be great as there are so many out there which don't include LOD objects.

The ETaC Complete - CRF Patch provided by REGS is outdated if you are using the new ETaC 13.2 update. I would recommend using the ETaC Complete - CRF Patch from the ETaC 13.2.1 Complete Patches installer. Same thing for the ETaC Complete - ORS Patch, because that has also been updated for ETaC 13.2 as well.