z929669

If you are using ACMoS, then it correctly handles all LOD32 settings that really matter. The guide shows manual adjustments for those at the bottom if you want. The settings in the 2.4 guide are 'better' for both TexGen and DynDOLOD, but still not finalized. Just follow the instructions and optionally make the manual adjustments to match. This only impacts a few unique resources around WR that you likely will not notice unless you specifically look for them. Either way, you will be good.

The flashes look to be torchbugs, I'm guessing. Probably the glow mesh interacting with ENB/weather or some texture incompatibility. It probably would happen without the LOD patch. Use MO data tab to filter textures/meshes for 'torchbug' to see what mod they are coming from. If using ENB, toggle it off for a while using Shift + F4 to see if that resolves.

The CC download prompt happens if your skyrimprefs.ini has [General] bFreebiesSeen=0 Changing that value to '1' disables the prompt to download CC content. BethINI purposefully does not set that value to allow the game to handle it gracefully when needed. As soon as you click the 'OK' to download the CC content, the game itself sets the value to '1', and it stays there unless you re-validate files again via Steam. Your MO launch issue is almost certainly not caused by BethINI and more likely has to do with the apps you are using to launch under Linux (I can't help there). You may find some answers on the topics following:

This template now points to Template:Hsg, based upon the update HighslideGallery extension.

So are you assuming BethINI broke your MO2 launcher? That's not likely, but I have never used either tool under Linux. BethINI Pie should be launched from inside MO2 as an executable.

You can try our updated TexGen/DynDOLOD settings in the dev 2.4 guide. It's expected you are using BethINI Pie earlier in the guide to establish correct game INI settings for visuals and distant objects. ENB grass will never blend perfectly with LOD grass in all weathers and all ToD though, but these settings should get you closer.

I don't think its a 'bug' but rather an interpretation of how the plant might look after its been harvested.

Yes

It should be, yes.

Try reading this OP.

Yeah, lighting like this varies by each system/display/drivers, so what may not look too dark on one system may look too dark on another. The issue is with ENB ultimately. We could create a new "brighter nights and interiors" version of each preset, but we're in the midst of testing Community Shaders, which may ultimately be a simpler post-processing paradigm while also being better in many regards. TBD.

Unfortunately, corporate interests always trump human interests. ...eventually, after initial success ...upper management focused on quarterly revenues, middle management bucking for position, people doing the actual work having little to no influence on the bigger picture (making a great game), yada, yada, yada

The name is arbitrary. As long as 'SKSE' is in the name somewhere, it should be enough to tell you where to look for SKSE-related output.

Thanks. We'll look into this, but these errors are only FYI in case there is an issue you notice with the LOD in the game. They can often be ignored. The conflicting MM LOD nifs use a different texture than vanilla, so that's probably why you are seeing the texture match warnings.

The grass is TexGen Direct/Ambient too high. If you are using complex grass, set Direct to 0, and only use Ambient 100+. For normal grass, try Ambient 10 and Direct 100+.

I should mention that LOD32 should be 'none` unless you are using ACMoS: mountain,Level0,Level0,Level1,none,FarLOD,Unchanged,1

In DynDOLOD, order of operations matters. First set the mesh rule for mountains: mountain,Level0,Level0,Level1,Level0,FarLOD,Unchanged,1

I see now that the mod you referenced is only terrain LOD. It would not touch mountains. You either need pregenerated mountain LOD matching probably Tomato's or use DynDOLOD to generate object LOD with those terrain assets (if you aren't already doing that). The terrainmanager settings will only be noticeable for the mountains when you have object LOD.

Check your [TerrainManager] settings in skyrimprefs.ini, or just use BethINI to get your view distances properly set for your resolution. Following are the correct settings for the BethINI 'Ultra' preset (possibly slightly different for the latest version). [TerrainManager] bShowLODInEditor=1 fBlockLevel0Distance=57344 fBlockLevel1Distance=147456 fBlockMaximumDistance=327680 fSplitDistanceMult=1.0 fTreeLoadDistance=0 If you drop that mod and use xLODGen and DynDOLOD, you should get the best result, but I assume you don't run those mods in favor of the pregenerated LOD.

Because we forward ICH's ARMA records into the Step CR Patch to get the ICH effect. Those records are unique to ICH. Example: The CR patch itself doesn't rely on ICH, but the CR-WACCF Patch does rely on it, and that file has the CR patch as a master. You should definitely begin your cleanup by using the Remove Unused Masters tool in xEdit to clear any masters we manually set to ensure proper LO of the Step Patches.

Possibly a missing DLL, an incorrect version of DLL or an incompatible DLL in your base game folder. ENB expects only d3d11.dll and d3dcompiler_46e.dll. It could also be something about your video drivers or related background processes. It's hard to say with Linux-Windows emulation for this game. Try reviewing this topic.

I use CentOS 8 or Stream 9 (RHL based) for server-centric Linux, but it also has various GUI options. I prefer RHL-based Linux personally, because I know it better. For more PC-GUI Linux, Ubuntu is probably the most popular, but I prefer Linux Mint, which is probably best as a transition from Windows (or Zorin OS). The latter are all Ubuntu based, which is Debian-based, but Mint also has a pure Debian-based flavor (rather than Ubuntu). Expect lots of tinkering and shell work with Linux, but it's very powerful and much better than windows for custom fitting to your needs. Gaming, drivers, and compatibility is always complicated under Linux, but there's tons of options and support. Things are much better now than they were a decade ago.

The only way to really know what plugins conflict is by viewing your LO in xEdit. There's too many to provide any clear guidance here other than USSEP conflicts with most other plugins in some way or another (and USSEP should be overridden in most cases except where it shouldn't ... I know that's vague, but everything is circumstantial). As I usually suggest to people wanting to do a custom build based on a Step build (or our build process/baseline): First install Step completely (except the LOD patches, which are strictly LO specific, but still worth generating to fully validate the build). If you KNOW you don't want to use a particular mod, leave that out UNLESS it's required by one of the Step Patches. Once you have the Step build validated as 'working', then you can go about removing masters (Step Patch dependencies) one at a time (review this topic for good methods of ding that in xEdit). Sort your LO using LOOT every time you make changes to the LO. Once you have those dependencies cleared, you can disable each of those mods and begin adding mods you want, one at a time, beginning with the simplest plugins (those likely to have the smallest number of potential conflicts). Save the big ones for last, as they will likely require some patching with your custom mods added previously. If you have your definitive mod list, you can always load them all at once, sort, and review/patch conflicts, but that is a bit daunting, since there will be lots of conflicts. It helps to only load plugins with conflicts to reduce noise (or eliminate shown conflicts using xEdit modgroups).

Thanks. I'll test this one.

I haven't notice any issues, but I rarely use flame spells. You be the judge and let us know if there's a difference.