godescalcus

AFIK the only known issue with that specific cell is that ELFX flickers like hell, all by itself... Most of us have got used to it since it isn't game breaking, but I think someone mentioned a fix not long ago, but I can't remember exactly.

On what specific record did you see it? Not sure but it may be doing that to prevent flickering. Every mesh can only respond to up to six light sources, I think. ELFX adds sometimes more than that (and splits vanilla meshes so that in general each one can't be affected by more than six light sources). Maybe Snazzy added stuff either has different meshes or gets added in places where you can't work around with ELFX and thus have to disable it? Did you see the patch disabling lighting effects on specific rooms, or on the game in general? I'm sifting through my Snazzy patches merge and haven't found a conflict so far.

Made it more than once, too... And I agree, but hand-holding would actually be making a mod with the replaced meshes and putting it up for download ;) The way I see it you won't be taking away the users' opportunity to learn if you ask them to create a new empty mod instead of a folder inside SSOS. I prefer it and do it myself, the downside being that it's possible to make a mistake and not take notice immediately. And some people don't like to have many asset overwrites for MO to choke on (it shouldn't be an issue, FAIK).

What do you think of the suggestion of placing the meshes as a new replacer mod after NSUTR instead of deleting them from NSUTR (with an Idiot's Check all the same, but that way people wouldn't CTD and it would be up to them to detect and fix lower poly meshes). I know SSOS is done like that since at least Neo's guide, but it has always been one of the sections people have issues with the most. Maybe that way it would require less frequent support here.

I did download that behemoth, just didn't install it yet ;) What kept me back was the fact that I'm trying really hard to not go crazy on textures that go over 2k. I'm actually running vanilla landscape textures. In Skyrim LE, I just use the optimized vanilla (unfortunately the version available for SSE is done with Ordenador, but I still use it, though not always) and then the "Bethesda Performance Textures" pack. No other texture pack is so consistent, unfortunately, though some textures are interesting when considered individually, they all fail to blend perfectly in the big picture. That's true, IMHO, of Noble, Vivid Landscapes, aMidianBorn landscapes, Skyland, luxor's or any others that I've tried. Maybe if you use low grass density values you can, to some extent, not see that they fail to blend, but I keep my grass at 60/70. Blending is mostly why I still use Cabal's aMidianBorn caves and forts with SSE, although for some reason they don't look so strikingly beautiful as in legendary (shader issue?). They still look far more balanced and blended than any others. About the ice caves' snow floor, I've tried enabling and disabling the improved snow shader in both bethini and directly in the ini, but haven't achieved any difference. Maybe I missed something? The issue seems so persistent I'm now wondering if there might be something baked in the savegame that affects it. I don't know if those things happen only with hardcoded placement of objects or other aspects, too. The more I look at gopher's image, the more it seems to me like he's using a plain specular map for that texture, maybe even plain diffuse and normal maps. His snow looks like a regular, reflective surface, and later in the video when you see his torch reflecting on the walls and floor, it's just more striking than what I'm getting overall... Some people may consider it unrealistic but I find it creates an interesting atmosphere...

I've tried different weather combinations with Lexy's guide. I've actually made a few different merges with Dolomite and combinations of Vivid with and without Wonders of Weather (I have an "issue" with that one... Despite people saying that it has improved a lot regarding the usage of scripts, I actually find the rain splashes distracting and too bright (they don't react to lighting the same way as other things, so in a pitch dark night they're like sparkes as far as the eye can see). They also don't occlude properly... So I made a merge without it and and renamed the esp to be exactly the same as Lexy's. Did the same with Obsidian weathers and could certainly do the same with NAT. That way I can compare them by just activating/deactivating in MO; if I take care to activate the new one before deactivating the previous, I don't even have to re-run loot or note down its place in the load order. One thing I like about Vivid that all other weather mods fail to do in some extent, is how it achieves much better "white balance" in the picture in general. Skyrim has a native "greenish/blueish" tint that Vivid undoes (probably by warming up the colors in general). After getting used to Vivid weathers, all others just seem to have green filters on the camera. My sweet spot would be a less saturated Vivid, perhaps with less contrast (Vivid makes shaded areas too dark, even ENB adaptation won't improve much on that). But I haven't tried NAT in a long time... Might give it a whirl.

Just to clarify the SSOS other people referred to earlier, the installation procedure requires you to create new folders to match the mod "No Snow Under The Roof"'s folder structure, where you'll copy the meshes that will be used by that mod. Later, when you install NSUTR, you delete its original meshes to prevent it from overwriting the better quality ones. If you fail to do the earlier step correctly (either skipping it or by making typo mistakes when creating the new folders and renaming the mesh files) the game will not find the required mesh and you'll CTD as soon as it looks for it. One way to make this not so tough is the following: 1) When following the instructions for Stunning Statues of Skyrim, instead of creating the Prometheus folder inside that mod, make a new empty mod with MO2, name it something like "NSUTR statues", and inside it, create a "meshes" folder, inside that a "prometheus" folder, etc... (following the rest of the instructions exactly, placing and renaming the copied mesh files). 2) Fetch the talos statue mesh from "LeanWolf's Better-Shaped Talos Statue with Greatsword SE" and copy it/move it to your new mod, in the same folder as the rest of the statue meshes. 3) Place that new mod immediately after "No Snow Under The Roof" in your left pane order and, when installing NSUTR, don't delete the "statuessnow" folder. That way, your new meshes will simply overwrite the original ones and if you fail something in the process, you won't get a CTD (just a lower quality mesh). Of course, if you do mess up in the process, it will be more difficult to detect it since you won't get a CTD and will have to look closely at the statues to notice it's a lower poly mesh being used.

Oh, are you both acquainted with Mogo Mead?!! Been told it's a bit more than bit-guinness...

Sorry for bringing this up here, but if someone could help me nail down my ice cave textures, I posted a request on the STEP support forum. Ice caves look amazing in Gopher's SSE video series and I just can't get there, tried different textures and even fiddled with game, ENB and GPU settings. Please, take a look at the post if you think you can help! Thanks!

I've never merged all ETAC mods, did you do the merge yourself? It sounds like some navmesh fixing would be required after the merge, as merging two or more plugins containing navmesh will break the navmesh for most. Jenna does have a rather long article explaining how to do it in the CK but I've never done it, really. I just don't merge two navmeshed plugins together. Merge Plugins Standalone should allow for merging merged mods, but you'll need resolve any conflicts in xEdit prior to merging or the "rule of one" will determine that the last mod wins any override. It's usually a good practice before making any merge, anyway. It's also possible to run mator's Smash and make a smashed patch for the plugins you'll be merging, then check that everything's consistent in xEdit and merge the smashed patch in as well. It may happen that the smashed patch doesn't have any records, that would mean there are likely no conflicts within the mods you're trying to merge. Naturally, you don't need to merge the smashed patch in if it doesn't have any records.

Hi guys, first and foremost, an apology. This may be more of an aesthetic issue than technical, but I'm at a loss and can't achieve the result I want... I'm trying to make my ice caves look like they do in Gopher's ongoing SSE video series. If you want you can check his episode 33, the Yngvild run starts at about 23:26. I'm posting a sequence of images to show what I'm after and what I'm getting. First picture is a screenshot of Gopher's video. Notice how the snow/ice floor is smooth and reflects the light coming from the entrance. I know some people find it "plastic" but to me it adds to the atmosphere of the place and definitely beats my best attempts with the most popular texture replacers. Second picture is with my current setup, I followed Lexy's SSE guide for those of you who know it. I'm using Phoenix ENB performance preset. Third picture is without ENB; I also installed the ELFX enhancer to darken the dungeon interiors a bit, because it's probably what Gopher has (either that or the hardcore version) and the ambient light seems to match (more or less). I've tried different texture replacers, such as Noble and aMidianBorn, and also vanilla. Could this be a GPU or even a game ini setting instead of a different texture? Texture filtering? AA? Sharpening? I'm using Ultra settings in Bethini, too. I tried the improved snow shader (on and off). I never get rid of what seems, in the middle image, to be an excessive contrast between the brightest spots and the main texture. I also never get any sort of refraction of light, maybe I need a different texture map with refraction? Is there a game setting to activate/regulate the amount of reflection/refraction, either in game, GPU or ENB? Edit: In the middle image I seem to get SOME degree of refraction, in the sense that there are "more bright spots" in the same area where in Gopher's video you see a clear light refraction. Thanks in advance for all your suggestions.

Hum... Why does this sound like you're keeping Sofia company for a tad too long? [iC]: Suspicious behaviour indeed! [OOC]: naked people usually happen in my game if I have armours added to the levelled lists that don't have versions for both genders. Not sure, but I think LADX might be one of them. Strange that it happened with legion soldiers... Do you think you'll be updating the guide with a new set of rules suited to the new loot?

Might try reinstalling SKSE scripts and binaries. Check if it's the latest version. Maybe also try reinstalling SkyUI. Also, if using Windows 10, check if your dll's aren't being blocked by the OS. I read about a problem where Windows blocks certain downloaded executables from running and the way to fix this, but didn't need it myself and I can't find it now... Claralux doesn't have MCM and Convenient Horses, if I recall, doesn't fire right out of the box, it takes a while for a quest to start where you gradually unlock its functionality.

Right pane (plugin list) is usually ordered by priority, by default, unless one needs to find a plugin in which case you temporarily shift to alphabetical. In the pre-smashed patch you can have your list in priority order prior to selecting the disabled plugins. Ctrl+click (selecting) every disabled plugin and then dragging any of them works for me all the time, it just block-drags the lot to wherever you want (should be the bottom of the load order if merging).

Actually, if you look at Neovalen's original SRLE (that "started it all", now a bit outdated) you have all the instructions for each user to manually patch everything. Every record, every edit, with justification. The fact that pack authors like lexy provide CR patches with all the work done takes a huge amount of load from most users. Only if you want to go your own way and customize your build do you need to go in and fix those conflicts yourself. Still, in many cases you can get away with simply checking and editing Lexy's patches. I'd say this guide makes it easier for most people, despite using a few more advanced tools (and SSE is pretty unforgiving if you want to use mods that you're used to from LE - no way around using the CK, NIF Optimizer and if you want to port animations, which you can, you need the batch to easily convert those havok files, too) than Neovalen's, which is the most taxing in time (and probably the one that will push a beginning user's modding skills the furthest). On a side note and as a personal opinion, methinks it might be easier for both Lexy and the people who do their own modding, while still relying on the guide as a backbone, if CR were handled in a more modular way and relied on the final CR merge to wrap it all up. The final merge could still be provided especially for users who build everything exactly as the guide says, but probably wouldn't even be necessary as by then people should be handling merging mods rather easily. If, that is, all the patches don't conflict within themselves. Otherwise, smash'em and xedit'em LOL This is the perfectionist's paradise.

If it proves worthwhile, it would be a simple case of adding the smash bit in the merge page, for each merge where it proves relevant. Doesn't seem hard to text it in a simple way and it might even help to get people acquainted with smash before the big final push. I'm with you there, part of what's keeping me from embracing Smash is that I trust the manual sEdit conflict resolution, not so sure about the automatic one. However, in some cases Smash may actually save you a lot of time. When I build my Weapons and Armor merge I inspect its mods for conflicts and there usually are, especially in the levelled lists which is something that supposedly both Smash and WB handle pretty well. Last time it took me about 30 minutes of painstakingly copying records around so that the levelled lists are merged - and I'm not even sure I'm doing it right. I'd like to try and smash those to see what comes. I don't expect game-breaking conflicts to show up in the mergers, or we'd have nailed them by now. Probably some consistency conflicts like the Ancano thing I found in the pre-smashed patch. If such conflicts do show up, smash might help Lexy from having to provide a consistency patch for each merge. Still, xEdit does feel like safer ground - at least until you inspect the smashed CR to see if it got the conflicts right.

Since we're already doing a CR merge by the end of the guide, which is great because it makes it more modular for people who decide to do some part(s) of the guide differently, why not take that modular approach further and install all the relevant patches for this build individually, and merge them all in the end? Just food for thought, this is probably not a priority and I'd really rather see if Omega makes it in or not. Still, it sounds like an idea...

My point was this: are those mods completely redundant for Smash, or aren't they? If you merge them before running Smash, their records will be carried into the merge based on the "rule of one" by Merge Plugins Standalone. If there were any conflicts that Smash could have resolved in a more detailed manner, they're lost once you switch those plugins for the merge and run Smash on your build. So Mator's suggestion is that a "mini-Smashed patch" could be made for each merge (not just the pre-smashed patch merge, but all of the merges as long as they have conflicts within those mods that Smash can handle) and that resulting "mini-patch" would be merged with the rest (Mator's quote in my post above). This, of course would only be relevant if there are indeed conflicts withing that group of mods, that Smash could resolve better than just a simple "rule of one" merge. So I tested with the pre-smashed patch and got that one Ancano record, not very relevant maybe, but perhaps other merges would yield more impressive results. I'm thinking, for example, about the weapons and armor merge since I'm using DeserterX's Legendary Armors and its levelled lists conflict with pretty much every other armor mod. Don't know if I got the idea through this time. I'm still trying to figure out how Smash works since I don't want to abandon my tried and tested Wrye Bash unless I know what I'm doing...

So I did the test above, with smash.all for only the pre-smashed patch plugins prior to merging. The smashed patch for only those plugins contains all of them as masters but only one record, the NPC Ancano. If I clean masters, the only master that's left is the main SRCEO plugin (which isn't in the redundant group). I checked the records and all Smash did was to pick the Conjure Frost Atronach spell from SRCEO instead of vanilla. In all other respects, it simply follows MLU - NPC Retexture Conflict Resolution.esp but it does get that spell from NPC Retexture - Conflict Resolution.esp. I don't know what you guys make of this - for one, it seems like smash.all almost doesn't do any change, but that one little edit (which I don't know if it's relevant or not, it could have been included in MLU - NPC Retexture Conflict Resolution.esp if that were Lexy's intention) makes me wonder if this could become relevant depending on build and if it would matter in other merges as well.

Seems like this is something to consider when doing the pre-smashed patch (from Mator's description): Q: How should I use Smash and Merge Plugins together? A: Creating a smashed patch for just the plugins you're merging prior to merging (and including the patch in the merge) can make your merges "better", assuming the resulting smashed patch has any records in it. Your full load order smashed patch must be regenerated whenever your load order changes, so you will want to get your merging out of the way prior to generating it. It does sound like a good idea for all of our merges, actually. One could test for each merge and see if any records come in the partial smashed patch, and, if so, include it in the merge instructions. For the pre-smash patch in particular, has anyone tested this? One thing that's been bugging the crap out of me is feeling that by using Merge Plugins standalone before running smash, we're crunching a lot of mods with the "rule of one" and thus not using smash to its full potential in resolving conflicts. I actually don't understand if we aren't losing what bit of conflict resolution Wrye Bash would have done with those mods, or if they're entirely irrelevant to the process. Seems like the easiest way to figure this is to do a test, following the pre-smashed patch instructions but running smash over the block of inactive plugins after we move them to the bottom, and see the smashed patch contains any records in it.

I was going to finish my updated build and switch to playing that... But I'll wait for Omega because it sounds pretty promising. I had read about it in Enairim... More like skimmed through both, actually. Since I still have my other build to play, I might as well keep playing LOL And watching Gopher :P

I would edit that NPC altogether and hire some thugs to teach modders not to create such unbalanced characters. What's the point in making a 200 NPC?!

I'd say that since both mods add an access to the same cell, and that access has to be navmeshed or NPCs won't be able to cross, those navmeshes are conflicting in that cell and only the last one to load will count. So, if we move one of the accesses and they are both accessible, only one will be linked by navmesh to the other side (assuming it's not the moved one and that navmesh doesn't break in the process). Supposedly, that's something you can restore in the CK by making a patch that will have a complete navmesh... I've never done it and have dropped many mods simply because of this. It would be really cool if someone could actually do some navmesh mojo in this case. One thing I've read about this is that navmesh triangles have to be in exactly the same number and that the order (position in the sequence) of the triangle that connects to the other cell has to be the same, because that's how it's also referenced in that cell's record. So that would have to be assured for both passages.

Do you know how to fix that? Making a patch for moving the entrances about is not that hard but probably there's already a navmesh conflict as well...

Maybe they'd look good on Inigo!