obrother

I found a few things that may be relevant: In the SSE Engine Fixes special instructions, part 2 refers to an EngineFixes.ini. Unless I did something wrong, it appears this is now called EngineFixes.toml. I didn't see Wet and Cold in the install list, but I also didn't find anything that says there was a decision to remove it (e.g., incompatibility or redundancy with AI Overhaul SSE); I see the notes for AI Overhaul SSE says that it includes weather behavior for all individuals, but also says it is compatible with Wet and Cold. Just pointing this out in case the omission was unintentional. Installing Cathedral Weathers for those that take the optional weathers route appears to overwrite Night Skies and Smooth Sky mesh. I'm assuming this is fine, but if not there would need to be instructions either to change the load order or hide files (or I might have missed these instructions). The HD Road Signs patches for Cutting Room Floor and Point the Way are currently overwritten based on install order... I'm assuming there should be instructions for this, such as to change the load order and move the patches down with the other patches (or maybe this is already there and I just missed it).

This seems like a good option if it was promoted effectively. I would use it. Nexus would probably need to be willing to support a mechanism to manage and redistribute your donation pool, but then that's probably the case regardless with any solution that relies on lots of little donations.

I think the issue is that the modding community -- e.g., Nexus -- has failed to develop an effective solution for collecting donations that matter. The donate button can't really be an effective model for this. Let me share my perspective as an example: I can afford to donate money to mod authors, and I have to some, but understanding mod authors don't get many donations, it feels insulting to donate some small amount to an author for their hard work. I can see where some mod authors would appreciate it regardless, but it just feels wrong... "Thanks for the hundreds of hours of work... here's a dollar for your time". When I've donated in the past, I try to donate an amount that seems more commensurate with the time and effort I know they've put into it their work. The problem is I've downloaded thousands of mods, I have hundreds of active mods, most of which are outstanding (that's why I use them), and the math doesn't add up, even if you're just donating a dollar. Since I can't justify spending hundreds of dollars to give money to everyone, I don't really donate to anyone even knowing deserve it. By contrast, if making contributions was a more prominent focus of a community resource like Nexus, and if a large percentage of this community would be willing to make some contribution knowing they're doing their part to support the work of the authors of the mods they use and like, regardless of how small that contribution, it would seem the numbers could add up pretty quickly, even if it's just lots of little numbers. I also think the key to understanding and dealing with the new pay area is that it will depend on the cooperation of the mod authors who develop the outstanding mods we use. Many of those authors are here and on other community forums, reading these posts and posting themselves. They are members of this community -- some of its most influential members -- and even those that have uploaded mods to the pay area take that community membership seriously (which should be obvious if you read what they have to say). Attacking them obviously isn't the answer, and I would argue that working together in some organized fashion probably is the answer, not only because it might offer some more effective model than the donate button, but also because it would deprive the pay area of the resource it depends on for content.

Here are some comparisons from the eye mods I've looked at: High Quality Eyes by Xenius (reduced to 512) > Natural Eyes (512 version) > The Eyes of Beauty > True Eyes (reduced to 512) By the way, these are the "same" amber eye from vanilla (True Eyes needs the texture renamed from eyeambre.dds to eyeamber.dds). All of these options look great. To me the Xenius eyes look the most natural, but I think it probably comes down to personal preference.

The STEP installation instructions and STEP Patches both say that Realistic Ragdolls and Force is not required if using the STEP Extended Patch. The mod Realistic Ragdolls and Force includes meshes that do not appear to have been included in the STEP Extended Patch. It seems that either the original mod would still be required for the meshes (and the ESP disabled/deleted) or the meshes would need to be included in the STEP Patch.

I understand what you're saying. In this case the proof really is in understanding the logic of what I'm saying based on how textures work. Let me try to be more clear... I'm not an expert, but what I understand is that textures come in layers. Generally there is a color texture, which is the main file, and a normal map, which provides the relief or "bumps". There can also be other layers, such as a parallax map, a glow map, and others. The fact, though, is these layers are all components of the same image, which the game combines (and attaches to a mesh) to create color and depth in the world. The bottom line is that specific normal maps and color textures are created to go together. Terrain Bump was created to replace vanilla normal maps and go with vanilla color textures, including the HRDLC (the description for Terrain Bump says "this mod ramps up the quality and detail of the landscape vanilla normal maps"). Mods like SRO are not vanilla, they are custom (even if they look similar to vanilla in game, the exact details in the textures themselves are generally different); using a vanilla normal map with a custom color texture doesn't make sense, because their "images" would not show the same details. So, for anyone who is following the current STEP installation, Terrain Bump is overwriting the normal maps for non-vanilla textures: SRO, HQ Snow, Real Ice, and SFO. I'm just trying to point out that this seems like a mistake. These color textures and normal maps that do not match and were not intended to be used together. Terrain Bump should be used with vanilla textures, like the HRDLC. Anyone who chooses to use custom textures like SRO should probably use the normal maps that go with the mod. It's fine if you don't want to take my word for it, but you might want to bring this up or have someone use an image viewer like Irfanview to compare the textures. While I understand the value of providing screenshots in many circumstances, in this case the issue is more fundamental than how things look in the game, it's about the basics of how the game is put together. I can think of many reason why this has gone unnoticed. One is that the effect of the normal maps themselves is subtle, and even if something looks wrong in the game, it would be very hard for most people to identify a normal map as being the source (much less, what the normal map is and what mod is providing it). Also, many of the textures in question are ground textures, so who knows how much time people spend looking at them, and also some of the textures match pretty close (coastbeach01_n.dds appears to match the equivalent color texture in SRO, so this SRO texture is probably more or less copied from vanilla). Considering that mods come and go from STEP, there are going to be downstream impacts that aren't immediately apparent. SRO is the mod that provides most of the conflicts in this situation, so if SRO replaced lots of vanilla-based (e.g. HRDLC) textures when it was added, it's quite possible no one considered the conflict with Terrain Bump. Also, my sense is that the folks who work on STEP do so as a service, and aren't necessarily going to follow STEP to the letter or change their setup when a new version of STEP comes on line, so many of the people who have the knowledge to recognize and issue like this may not actually be experiencing it. Again, I appreciate the work you all do here, and I'm not trying to be difficult; I'm just trying to help. If you have any questions or if there is anything in particular you want to help confirm this, let me know. I could send or post examples of the textures, but I'm assuming you (or another moderator) would already have them on you computer and could confirm this in just a couple of minutes.

I've looked at the textures/normal maps and it's obvious they are different, so it isn't really just my "thoughts on the matter" but I wasn't planning to provide in game screenshots of the differences as proof. Anyone who uses these mods and Mod Organizer can see the conflicts and compare the textures pretty easily. For example, if the rocks in an SRO ground texture don't match the placement of the rocks in the Terrain Bump normal maps, it's pretty easy to see that in an image viewer. I appreciate the guide and I'm just trying to help out by identifying potential issues as I come across them. Feel free to ignore me if you don't think it's a problem.

I believe there is an issue with Terrain Bump as part of the current STEP setup that you might want to consider. It appears that Terrain Bump was intended to provide improved normal maps for vanilla textures, and does this really well. However, when using a texture that is different from vanilla (rather than a hi-res improvement) there doesn't seem to be a purpose in using the Terrain Bump normal maps, since the bumps don't match the color textures. STEP Core includes mods that provide improved textures, but that also differ from vanilla. SRO, HQ Snow, Real Ice, SFO all have textures that do not match vanilla, and so do not match the normal maps in Terrain Bump. These mods provide normal maps that do match their color textures, and even if the Terrain Bump normal maps were considered to be "superior", it seems like it would be better to use inferior normal maps that match the color textures than superior normal maps that do not. I've chosen to disable Terrain Bump since that seems to be the obvious answer, but I wanted to post this issue here in case it is an issue and hasn't been considered.

As of 2.2.9 DSR has been moved to the Patches section (I think before it was under Fixes), which may have created an issue. The instructions for DSR include the following: Besides the main file, also install the patches for aMidianBorn, Elemental Staffs and Skyrim Weapon De-LARP-ification Project. These patches overwrite meshes in the associated mod, so they need to be installed after the mod (e.g., the Elemental Staffs Pack installs after the Elemental Staffs mod). The problem with this is that DSR meshes now overwrite the meshes in the DSR patch for Skyrim Weapon De-LARP-ification Project (appears to be the only files that DSR overwrites), which seems to defeat the purpose of the patch. My assumption is that the patch should overwrite DSR instead (which previously would have been the case).

For SDO in Extended, the instructions include the following: Patch Do not install the SkyFalls and SkyMills Patch optional file, since it is now contained within the SkyFalls and SkyMills installer. The patch is a texture, so the equivalent texture in SkyFalls and SkyMills would just be overwritten by the non-patch texture in SDO, given the current STEP installation order. Unless I'm missing something obvious, it seems you might change the instructions to one of the following: Change the installation order of SDO and SkyFalls and SkyMills so textures in the latter overwrite the former (possibly the mod author's intent) Hide/delete the texture (Tamriel.Objects.DDS) in SDO Use the patch provided by SDO instead (it's the same file)For what it's worth, the SDO compatible version of SkyFalls and SkyMills also excludes redundant meshes between the two mods (...meshesterrainTamrielobjects), and maybe other changes I didn't notice.