z929669

From the Flashing Savegame Fix Nexus page:

From the Flashing Savegame Fix Nexus page:

Yes, I assume the mesh changes are 'good' and just wanted to note that the ones I indicated were modified relative to those I had previously from the patch. As far as the dates go, it does appear that they are the identical to those in the archives, but I have no recollection of updating this mod since shortly after you posted it in 2021 aside from this latest update I acquired last night.

Fixed. There's some changes introduced with v1.07 relative to the version I'm running (v1.04). Nevertheless, there's no changelog history I can see for either of these versions. It's hard to say if it matters though. This is the diff of the two versions. I think the dates are misleading and represent my local file create dates rather than the actual create dates of the files, so I'm ignoring them for the most part.

We'll be using BethINI Pie in the next guide.

If you follow our BethINI instructions, you will not get these settings in skyrim.ini: fGrassMaxStartFadeDistance=7000.0000 fGrassMinStartFadeDistance=0.0000 Are you running BethINI or BethINI Pie? The above is true if using either, so not sure how you have those settings if you deleted your game INIs before running BethINI. They are stored in the BethINI 'Setup' path. Regardless, test with a new game, and set grass fade to 20272 (fGrassFadeRange=20272)

I don't see how BethINI would cause of this ... @DoubleYou? I think it's the MO VFS obfuscating the state of the CC downloaded content if the game is launched via MO instead of the Steam launcher after doing the cleaning. I suspect that using the Steam launcher once after downloading the CC content effectively 'sets' the correct state, but I'm not certain.

Since the latest updates, BGS has fixed (accidentally?) some of the vanilla masters, so 28 CC is currently correct. The others have no ITMs/UDRs now.

First, I suggest you use BethINI to get all of your game settings in order. Some of the GRASS values you have in skyrim.ini only work in skyrimprefs.ini, IIRC. Also, Cathedral Grass works well with (in skyrimprefs.ini): fGrassStartFadeDistance=6144.0000 and in skyrim.ini: fGrassFadeRange=14128.0000 (but I think DoubleYou recommends also testing with 20272.0000 now) Also see this topic if you are using a grass mod with shorter grasses.

I suggest you either make certain that your grass distance/fade game INI settings are correct or use BethINI Pie to do so. The INI settings in your third video essentially is not set to fade with those tweaks. IIRC, this can help with performance ... but I do recall that LOD out/full in (walking forward) might have better transitions than LOD in/full out (waling backward). Also, I think that player movement speed must be < 250 for proper LOD load/unload ("player.setav speedmult" in console). Then use Grass Cache Helper NG, generate grass LOD (mode 1), and post that video for comparison. Maybe this is what you posted in your first video in the original post? Just want to confirm you had all recommended game INI settings for grass fade with LOD and DynDOLOD Mode 1 with Crass Cache Helper NG. I think it's normal to see some transition effects when moving backwards or during cell load/unload (game limitations, it's not perfect).

How?

I assume you have animation mods active in the mod list that are not showing up in Pandora? What version of the game are you running? Make sure your mod list is compatible with your game runtime version. If you are running the latest version of the game, be sure you are also running Backported ESL Support. Seems like you have compatibility issues if I had to guess.

In MO: Vortex will do the same thing, I think, but you need to explore the UI.

I think the same thing happened to be once, but I somehow got it working correctly by doing what I described. No clue why, and I don't have the time to test exactly what causes this. Someone else around here may know the cause. I plan on repeating the process entirely before working on the next guide update and likewise updating the related guide instructions accordingly.

Go through the cleaning process again as instructed. Copy the cleaned masters into your MO mod, and confirm they are all clean again using LOOT. Close MO, and use Steam to validate your game files. Then instead of restoring the backups from xEdit Output, launch the game from the Steam launcher, click 'Play', and load into the main menu. This should invoke the CC download process again. Once that finishes, you should have all of the valid CC content under the Steam game ..\Data directory. You can test this by launching again through Steam and clicking 'Play' (the game should start this time without downloading. Use console 'qqq' command to quit). Now go back to MO, enable your cleaned masters mod, and you should be good. Test by launching the game and selecting 'New'. I think it's re-downloading all the plugins again, because of the MO VFS somehow before it flags all files as having been downloaded. Be certain that you have followed the BethINI Setup instructions properly before ding all that^

You don't have Papyrus installed or it is not enabled or is the incorrect version, or you are not using DynDOLOD DLL NG. See DynDOLOD Requirements Install the latest DynDOLOD Alpha ENBSeries has nothing to do with DynDOLOD, so something else changed.

Yes, these instructions make sense, but only after doing the "first launch", so I think the instructions on this mod page and others like it should be omitted and essentially moved into the First Launch area of our guides. It sounds like you might be advocating that these configs be stored under the SKSE mod, but I do see the wisdom of using an SKSE Output mod just to partition things as Tech alludes. But then there's a difference with SKSE mods that don't ship with a config file versus those that do. Those that do will have such files in the source mod, while those that don't will have them in Overwrite (or an existing mod for those of us that set that up). The instructions really depend upon the user experience. We don't really set things up from scratch but rather build upon existing builds, so many of the little 'gotchas' get overlooked. I plan on rebuilding everything from scratch to get a better feel for what we tend to take for granted. This also pertains to cleaning the vanilla masters and such. So @Brambleshire, I'm hoping there's enough info here such that you get the idea about how there's potential variation in how to organize mod assets and leverage some handy MO features. There's really no one 'correct' way. Nevertheless, we should be as consistent and clear as possible in our instructions. It will all be (re)polished in the not-so-distant future.

This doesn't make any sense if you are following our guide. This is the feedback topic for the Step SSE guide.

Keep in mind that our current recommendations predate some of the latest enhancements to the game (namely Grass Cache Fixes NG and DynDOLOD support for use of *.cgid rather than *.gid). Our deprecated instructions are necessary to properly utilize our current grass cache, and that will all be changing along with a lot of other deprecated (but not incorrect) instructions.

The settings we recommend for NGIO are optimal and should be used. If you are running 1.5.97, then NGIO will persist in your mod list, and those grass settings apply. If you are running SSE 1.6.xxx, then NGIO will not persist, and those settings should be applied to the game INIs (which is why I said to use BethINI ... it ensures your game INIs have the correct values for grass fade/density regardless of NGIO).

We use RS (Relighting Skyrim) ... for changes to existing lights (bulbs). We use Ambiance for lighting tone/behavior.

I do the same, and it's probably something we should add to the guide. We've discussed it before though, and I recall it being a sticky point for some of the other curators who advocate using Overwrite. Overwrite never gets used in my setup. This was the convoluted compromise outcome. The idea is to make it simple by avoiding recreation of the directory structure. Effectively, install the same mod twice under two different names (original and CONFIG) and simply delete all of the folders/files that are not wanted in the 'config' version. This is arguably less error prone than recreating the dir structure manually. I advocate doing what Greg mentioned and not even creating the somewhat redundant "CONFIG" mods. Simple. I actually send all of my SKSE output into my SKSE64 mod, because when it's updated, only the Scripts folder is touched, and none of the runtime output we are discussing conflicts with this. So whether or not you manually install SKSE scripts or install/merge with MO, it works (now that SKSE is on Nexus with "Mod Manager Download" option). Even my grass cache output lands in my SKSE mod. This is what I'd like to recommend for all of our applicable Bethesda guides. We've discussed this before, and I got pushback at the time from other admins :\ The argument was that if it goes into Overwrite, it forces the user to consider it and it's source so that it could be dealt with accordingly. Meh. It's always runtime output related to Script Extender when following our guides. EDIT: Actually, I think the full argument is to leverage the built-in MO mechanism in dealing with this output (MO exclamation warning indicator when content is detected in Overwirte forces the user to acknowledge and deal with it on a case-by-case basis). Otherwise, one could just use "Create mod" from Overwrite when something winds up there. I don't like this, because it's possible to get a mixed bag of stuff in Overwrite such that the mod being created is also a variable mixed bag. Sending all such runtime output to the Script Extender mod is the cleanest approach, IMO and applies to most Bethesda games, IIRC. Sending to a separate Script Extender Output mod also works fine, but it is one additional mod and basically redundant. There are many ways to skin this cat, and I'm all for removing the CONFIG mod instructions and anyting having to do with Overwrite maintenance from our guides. EDIT2: Is it still even necessary to create the SKSE.ini file and populate it as such (see below)? Is the same true for the other Bethesda games utilizing Script Extender variants??

Most people will find the runtime-generated files in Overwrite (unless they are assigning a mod to hold all such runtime-generated files, which I do) once the game is launched. Such files+paths can then be moved into the custom 'config' mod from Overwrite. This only matters if you edit said files with custom changes and prevents losing said changes if the mod is updated or makes it simpler to keep track of your mod-editable files. For Fuz, the comparison would look like this: For mods that ship with the config file, you would obviously see this file in both mods, but your custom mod overrides the original so that you have one safe place to make changes without worry of losing them (or just for keeping track of these things).

Yes, that's probably the case. The INI file for this particular mod isn't generated until you launch the game while this mod is installed. Doing this is totally optional though. It's just a good practice for anything with an INI a configuration or other editable file shipping with the mod. This way it won't be overwritten when updating and merging the mod. For this mod and others that don't ship with the INI file, it's actually a bit redundant.

Are you following the Grass LOD Guide? Game INI settings matter as do other settings mentioned. Use BethINI for the correct grass distance (and all other) settings.