TechAngel85

I have created a companion mod to resolve some of the conflicts that would be in the Guide. What I've released either has open permissions or I already received permissions. I'm still waiting on a reply from Gamwich regarding several of his mods.

Discussion topic: ENBSeries Glow re-Maps by TechAngel85 Wiki Link Provides texture patches for mods with glow maps. These patches relocate ENBSeries' control of their glow from its WindowLight feature to its ObjectGlow feature. This decouples these glow maps from the window glow. In turn, this allows authors and users to alter the window glow without affecting the glow of dozens of other things that would normally get wrapped up into the WindowLight feature. This mod is meant to companion Particle Patch's "Glow Maps for ENB" optional file. Suggested Installation For testing for Step, this mod should overwrite everything, since these glow maps are modifications of those provided by (winning) mods in Step: Particle Patch ... Skyrim Realistic Overhaul Particle Patch - Glow Maps for ENB ... ENBSeries Glow re-Maps (overwrites all conflicting mods)

@z929669 I think it would be good to install the "Glow Maps for ENB" Optional File for our Post-processing users. This basically decouples many of the glowmaps from [WINDOWLIGHT] and moves them to [OBJECTGLOW], where they should be. This allows ENB authors (aka, Step) and users to adjust the WindowLight settings without affecting a magnitude of other actors/harvestables/objects/weapons that are also using glowmaps and getting caught up in ENBSeries' processing of the WindowLight feature. I would overwrite SRO, but allow the rest to be overwritten (I just hid the one conflict with SMIM in this Glow Maps addon and placed it under SRO). It appears the alpha needs to be black for this to work so each mod would need to be checked, individually, and it's not likely any would be compatible with the move to to ObjectGlow; meaning they would stay connected to WindowLight unless a patch is made. This would be for ~18 objects with over 90 without any conflicts, so still worth it.

I too have a custom ICC profile on my monitor from RTings. I was fortunate enough to have a monitor they've reviewed and provided a calibrated profile for. The lighting and weather sections were decided to be all or nothing for the Guide a few releases again to reduce overhead. We're already making CACO, CCOR, TCIY, and WCCAF optional, which creates multiple patches to maintain. Lighting, weather, and Post-processing are all optional for the Guide. Their sections are simply all or nothing vs providing more than a single patch for each picking and choosing the mods to install within their sections. Granted the Lighting & Weather section is vanilla-friendly so any ENB that works for vanilla lighting and Cathedral Weathers should look okay with the Lighting & Weather mods. We do use Ambiance, but it's not than far off from vanilla; which is why I keep saying 'vanilla lighting'. As for the Post-processing section, it's just a generic setup to incorporate ENB-compatible mods into the Guide. So you are feel to try other ENBs than the Step ENB. The Step ENB is simply made, specifically, for Ambiance/Cathedral Weathers combo. The grass is one of the few made to work well with Cathedral Landscapes and we've made it work with ENB ComplexGrass on our own. If there is something off with it, please do provide feedback so that we can improve it.

I can't say it's an answer to all of that, but a think a good chuck of it can be explained by the fact that ENB Light is old and some of the other mods have since came out with their own versions. For example, all of the LeanWolf's weapons have ENB options already available in the LeanWolf installer. No need for the ENB Light files there.

Just to let you know, I've been playing a bit and have noticed how dark the ENB is making the game too. One of the main issues is the current ENB nearly nullifies the ambient lighting. However it got to be like that, we've done some editing that will restore some of the intended visuals from Ambiance; which isn't normally too dark without ENB. The goal of the Step ENB is to "enhance" what the Guide is already providing. So when something like this happens as a result of the ENB, we have to readjust settings to bring it back into balance. The next update of the ENB files will improve upon some of these issues. Also keep in mind that the outcome of the ENB can be setup-dependent due to graphics cards and monitor quality. We've discovered from taking screenshots from our own, individual, systems that it's not always the same visual outcome from system to system. Therefore, we're attempting to achieve more of an average with the settings, so they will look right on the most systems possible. It could take some tweaking on an individual basis to fine tune the ENB to the individual system. We may put together a quick reference, linked from the Guide; since it's an easy process to adjust a few settings up or down.

Updated OP

Yes! That's the same one I have linked on my wiki profile and the one I use now. They have one for Fallout 4 and Starfield, as well; following the same naming scheme.

Sevencardz came back and updated this mod. I think it would be worth switching back to it as it's now SKSE & SPID, so there's no worrying about conflicts with edited vanilla scripts. Also the author of the one we're currently using has updated their mod page to state their "fix" is mostly redundant. The new version of the original by Sevencardz should be a complete fix and a better one. I also think we should be supporting the original versions of mods when they work for the Guide.

My concern with this is the same as it was for "Cleaned Skyrim SE Textures". Looks good on the surface, but when you start digging how is it? Cleaned Skyrim SE Textures pretty much used a single or couple upscale models to achieve what they did. The issue with that is the results are all over the place. We didn't add Cleaned Skyrim SE Textures because many of the texture had issues that weren't present in vanilla such as pixelation, removed details, fake looking averaging and sharpening, color shifting, re-adding fake shadowing, etc. This is mainly caused by not adjusting to use the best model for the texture because the best model for a stone texture isn't going to be the best model for a fur texture, and so on. This mod does make the claim of editing textures post-upscale to further fix them, so I have a bit more faith that it will be better than Cleaned Skyrim SE Textures was. In fact, I had started working on doing the very exact thing. If it's good, I guess I don't need to worry about that work anymore.

Use the new one, if you use one.

Nice list! It'll be good to go over these for the next release.

Nothing in the Guide affects the difficulty of the game besides maybe Uncapper, but that is default unless you set it up. Uncapper could help you in your situation too. The issue your having with difficulty is because you've level so much and the game difficulty is adaptable to your levels. Sounds like you've unbalanced your game by farming so Uncapper may not be of any use now.

Discussion topic: Better Crystals by Lo2k Wiki Link

Discussion topic: Step NoMansSky Guide Resources: Nexus Mods Please submit feedback or bug reports about the 3.5 Guide to this topic.

It's possible to tie this one into all of that, but I didn't want to have the mod tied to quests or anything of the sort; making it a toggle like the others was the next best solution. Tying it into the building of Goldenhills would also mean that you couldn't turn it off once active; which some may wish to do for things like another mod adding to the exterior that would overlap the chimney model, etc.

VLC - References.esm This plugin holds all Object References that are changed in any way by VLC. Regardless if the objects are large references or not, all changes to Object References are placed within this master file to prevent any potential large reference bugs from occurring. Currently, the plugin houses mostly road and rock changes. The following are considerations for this master file: USSEP changes to exterior Cell records should be forwarded. These are the ones with coordinates under Tamriel Worldspace. USSEP changes to Object References is case by case. Unless you did the work on the mod, assume VLC should win all conflicts with Object References. Load order does not matter in regards to Majestic Mountains ESM, since there are no conflicts and the MM ESP will always load after. Load order only matters for other ESM plugins that contain conflicts with the included Object References; in which case, VLC should win said conflicts. Conflicts with the included Object References with other ESL/ESP plugins will require a patch to allow VLC to win said conflicts. Changes to this plugin will often require regenerating object LODs with DynDOLOD. Vanilla Landscape Corrections.esp This plugin holds all Landscape changes included in VLC. This includes changes to landscape shape, textures, and vertex colors. Though this plugin could be flagged as ESL, it currently isn't due to ongoing development. There should not be any Object References included in this file. The following are considerations for this plugin file: USSEP changes to exterior Cell records should be forwarded. VLC should lose conflicts with other mods in regards to the exterior Cell, or a patch created that forwards the other mod's Cell changes and VLC's Landscape changes. Load order does not matter in regards to Majestic Mountains ESP, since there are no conflicts with and the MM ESM will always load before. Load order only matters for other ESL/ESP plugins that contain conflicts with the included Landscape records. Choosing a "winner" in such cases is not always straightforward. If the conflict is with a mod that is included in VLC or VLC is designed to work with (LFfGM) then VLC should win. In all other cases, the mods may work with VLC winning or losing some or all conflicts. It really depends on the nature of the changes made, and will often require some sort of patching to make the mods harmonize. Changes to this plugin will often require regenerating landscape LODs with xLODGen. Hopefully that answers some questions. In regards to SLSR, I would allow VLC to win all conflicts with it. Frankly, it's not needed for the sake of VLC since it was entirely absorbed into VLC and reworked. It's only being kept for the Smooth Shores patch, which I, personally, would just forget about for now. I will eventually get around to redoing that patch for VLC.

They're using the vanilla mesh and not ours so it's not really anything to worry about. The patch likely had permissions as the author's name looks familiar to me. Since RWT has been turned over to me, I would love to simply revoke all permissions handled out to 3rd party authors, but I can't really do that. The next best thing is to change asset names. This forces some of these mods to update or become obsolete and kinda tells me what is and isn't being maintained by the 3rd party authors. I have been considering pulling together some type of file that contains patches for various mod, again. I just haven't been in the modding mood for a while now.

It's fine. VLC only used the landscape changes from the MM ESM. This mainly just paints rock landscape textures around the base of mountains and rocks for blending purposes. Vanilla did this in spots but not everywhere. MM extended this to pretty much everywhere and that is what VLC has incorporated from MM. Changes to the mountain/rock textures used isn't going to affect anything unless the textures are really, really different in color. For example there are some mods that make the mountains/rocks more brown in color. However, without also including the rock landscape textures with those sort of mods, there is going to be a mismatch between the mountain/rock color and the landscape rock color. It's up to those authors making those changes to be thorough enough to recognize such inclusions are required when making such drastic changes to the original colors of objects that may require blending with the landscape or other objects. In similar cases, Step has rejected many flora mods over the years simply because their colors didn't blend naturally into the landscape.

Looks like he's breaking some things to fix others. I never consider mods that fix one issue to cause another an actual "fix" to anything. RWT includes many of the changes but we don't remove the lighting from the water, which is the reason this mod seems to be in debate. This lighting can be turned down on the mesh itself, via the gradient system in RWT, or by adjusting ENB settings. Doing what they've done here will effect all waterfalls, everywhere. So if you have some weather outside on a very, very dark night for some reason then you're going to end up with dark waterfalls that are nearly invisible at night. Which is not realistic. They've already mentioned this is an issue in dungeons where little to no lighting is around. What is being desired, from what I gather, are just changed interiors. To do this without affecting exteriors, you'd have to create new waterfall assets with the lighting adjustments desired and replace all the interior waterfalls that are desired to be switched out. No water mod available does this. Could it be done? Certainly. Should it be done? Idk, I'd question how nitpicky we're being over visuals that aren't perfect vs playing the game; a trap most modders fall into at some point. Are we trying to make a fun gameplay experience or are we trying to make art out of the game for screenshots? The later would certainly say all those details are worth it because it creates a more realistic art piece. The former would likely hardly notice as they are running through the area killing and looting whatever is in their path, vs stopping to notice the lighting on that waterfall looks slightly off. In any case, RWT certainly could just switch out the assets with ones that have the lighting turned down and call it a day. Since they're within interiors, DynDOLOD wouldn't be affected. Honestly, there shouldn't be any lighting issue at night in exteriors in the Step Guide as we should have that controlled via the ENB. We can also include adjusted gradients, if ever needed. These two things allow changes without ever touching the RWT meshes. And, no, this mod is not compatible with RWT meshes. It would overwrite them and you'd loose all the RWT custom changes to the meshes. The patch available might make them work together, but hasn't been updated since the RWT update, recently; meaning it may be outdated by not carrying forward the name change that we did to one of our textures. This change was to force these 3rd party mods to update or become obsolete, while also making it obvious that someone is using the RWT asset. It's just one more "gotcha" designed into our assets so that we know when someone is using them without permission.

I haven't even begun to look. I haven't touched a mod in 2-3 weeks again. There is just so much real-life stuff to accomplish on my weekends that gaming and modding are put low on the priority list. Possibly. I haven't look into conflicts, yet.

Keep in mind that Post-release changes can be found at the top of the changelog.

Updated

Updated

The screenshot looks right to me. There isn't any check to see if all mods are working or not. As long as you installed them as instructed, everything should be good. There are a couple ways to do this. You can create a new profile in MO by copying the good Step SkyrimSE profile. You can also manually backup the MO Profiles and Mods folders found under AppData\Local\ModOrganizer. Instance = game; so these are only created one per game and you can have one for each game that MO supports. You switch Instances when you want to switch games that you play. Profile = modList for game; you can create as many of these as you like. They are only available for the game (instance) that is currently active so when you change instances only those profiles for that game are visible. The recommendation here is to keep the Step SkyrimSE Profile and create a new Profile from it. You can copy it within MO to a new profile and use that new profile to install additional mods. This allows you to fall back to the good profile if something goes wrong. Beyond that, there is no advice when adding additional mods. The Guides can be played as-is, but many use our Guides as a foundation to build their modLists up from. The main thing to worry about is conflicts with other mods already installed. Checking that typically takes some basic xEdit knowledge to verify that mods aren't conflicting in bad ways (conflicts are normal and often wanted; just need to make sure the results is the desired results). Any mod marked the the yellow TESTING prefix will be a candidate for v2.4. Most should also have the "2.4" tag as well. It's typically not safe because the order we have the mod groups means that some requirements of mods installed early on may not be included until later in the Guide. This is called out at the end of the Extenders mod group with a large red warning that states: "Beyond this point, DO NOT launch the game again until instructed to do so. Many of the following mods are interdependent, and launching the game prematurely will most likely result in issues or failures. Please DO NOT post on the forums for support of non-issues relating to preemptive or premature test launches." So you have the test launch right before this warning and the next isn't until the remainder of the mod list is fully installed. This is by design. I agree that it's not ideal as it would be nice to launch more often to test to see if the installation is going smoothly. This would mainly just satisfy the human nature of wanting reassurance, though, as the mass majority tend to work through the Guide fairly easily. If you'd like any more clarity or have other questions/suggestions, please feel free to ask/suggest.