DoubleYou

I think we should at least increase the size of lod32 so that the map can benefit. It won't really show up in the worldspace anyway.

Despite the content pointing to this thread, our guide xLODGen settings differ between the current guide and the dev guide and the settings I am seeing in this thread. Also, is it just me, or does the texture size recommendations seem random? I would think that the higher level LOD should, generally speaking, have a larger resolution than the lower level LOD to account for the effective doubling of their respective sizes (e.g., 4 lod4 squares fit in 1 lod8 square, so for the resolutions to be equal, the size would double for each lod level).

Yeah, I was getting some huge frame drops from NGIO today. I normally stay very close to 72fps, but it would suddenly dip down to 35 for a second because of loading all the extra LOD, which is not okay. I'd rather not even have grass LOD if I have to endure that kind of issue. I was able to tweak my INIs down to where the dip would only hit 50 fps every once in a blue moon, which is somewhat acceptable, but I'm not even on an ENB and having that kind of issues on rather good hardware.

You just gotta keep lowering LOD settings until it disappears, or lowering the settings for the generated LOD. NGIO is very performance demanding. I have big frame drops myself if I don't play along.

I just looked into this a bit. It seems that with the new Grass LOD loaded into Object LOD, some systems will not be able to quite keep up with the generally accepted TerrainManager settings used by most people. These settings can be tweaked within the DynDOLOD MCM menu, and the most important one is the first block distance. [TerrainManager] fBlockLevel0Distance=35000 fBlockLevel1Distance=70000 fBlockMaximumDistance=250000 fSplitDistanceMult=1.5 Tweaking these settings, especially the first one, will help users the most with their new Grass LOD performance. Just some quick tweaking on my setup, I changed mine to the following, and I'm getting much better performance. I'll be playing with this more to see what kind of balance I can strike up.

Ok. I must be misunderstanding then. Correct path IS Data\Grass. Loaded it up the other way and no grass lol.

I never knew to do this. I thought NGIO would yell at me if it was in the wrong place. I have it inside the Data\Grass folder. So the directory structure should be Data\SKSE\Grass?

Ah. I didn't know that about the grid system. It's great to hear such good feedback! Keep up the good work!

We might be better off using the Bootstrap grid system for this instead of flexbox.

You must use it. It is not optional. It is required for other mods to function.

Real Wood Textures is gone too.

Fallout4Custom.ini will never overwrite Fallout4Prefs.ini. BethINI does read FalloutCustom.ini, however. See my reply to your other thread for more details.

Fallout New Vegas is the oddball. Fallout New Vegas does not natively support a custom.ini file, but just about everyone uses the JIP LN NVSE Plugin mod for Fallout New Vegas, which adds the ability to use a FalloutCustom.ini file to overwrite any and all INI settings set in Fallout.ini or FalloutPrefs.ini. For the rest of the games, the order is game.ini, gameCustom.ini, custom plugin INIs (INI files that accompany a mod plugin), and then gamePrefs.ini. In other words, gameCustom.ini will overwrite any setting in the main game.ini file, but not any setting that is validly placed in the gamePrefs.ini file. However, only a select few settings of the many thousands of available INI settings are valid in the gamePrefs.ini file. You can see the lists of valid settings for each of these games within BethINI, or through our wiki guides, or my several threads listing all valid INI settings for each of the games. Here is the one for Fallout 4 for instance: Therefore, since iLocation X and iLocation Y are invalid within Fallout4Prefs.ini, as long as a plugin INI file is not overwriting the values, it will use the value assigned within FalloutCustom.ini. If you are unsure at any time if an INI setting is being applied by the game, you can easily verify it in the console with the following commands: getini "setting:section" An example in this case would be: getini "iLocation X:Display" Which should return 0 if you are using the setting displayed above.

I would right-click, All Mods, check all for update, and you should see in the log where mods are not found IIRC.

OK. I don't think it is an animation issue, as I would think it should also happen in Solstheim. I think it is more likely one of your mods that is not playing nicely with the rest, one that is affecting Tamriel. Pretty much the only way to figure that out is by process of elimination, which will take some time. You're going to need to disable plug-ins probably 5 at a time or some sort until the crash goes away, and then when it works, figure out which one is at fault. You will have to be careful to avoid missing masters doing this. It is more likely for it to be a patch than anything, as they often don't get updated with one of the mods it is patching, throws an error cannot be resolved, and crashes the lot.