DoubleYou

fInteriorShadowDistance fInteriorShadowDistance sets the distance that shadows are cast from the player while indoors. Wherever no shadows are cast, the place is put in a perpetual shadow, effectively decreasing the light cast indoors. See fShadowDistance for the outdoor shadow distance. fInteriorShadowDistance=0fInteriorShadowDistance=500fInteriorShadowDistance=3500Default is 3000. fInteriorShadowDistance=(0,0.0001,...)

I'm not worried, cause it will get hacked. This is a big enough thing that someone will "jailbreak" Windows 10 forced updates. It's easy enough to screw up updates so they won't install already, so this won't even be hard to hack. And then Microsoft will either be forced to give us the option or let users hack their Windows. Me? I'll upgrade to it. BUT... I'm going to dual-boot. I own two Windows licenses - Windows 8 I'll upgrade and Windows 7 run alongside.

fShadowDistance fShadowDistance sets the distance that shadows are cast from the player, using the resources allotted by iShadowMapResolution. If fShadowDistance is set to 0, shadows will not show up, but it will not impact performance, because this merely determines how far from the player that the shadows will be cast. For good systems, it is recommended to be set to 4000 or higher, with a corresponding increase in iShadowMapResolution to improve the quality of the shadows cast. Note the visible line of shadow quality stages in the videos below (iShadowMapResolution is set to its default value of 1024). fShadowDistance=0fShadowDistance=1500fShadowDistance=2500fShadowDistance=3500fShadowDistance=4000fShadowDistance=8000Default is 2500. Low is 2000. Medium is 2500. High is 4000. Ultra is 8000. fShadowDistance=(0,0.0001,...)

@GrantSP I fully understand and agree with you, and have tried to reflect that in my analysis. I have tried to temper such statements with key phrases such as "is believed to be unused" and "does not appear to have any effect." These are the statements that I have verified through empirical analysis, which means "Relying on or derived from observation or experiment. Verifiable or provable by means of observation or experiment." This is also why such settings are marked in yellow. These are the ones believed to be unused that I cannot prove are unused, as, like you say, they may rely on other settings/circumstances or may not do what one would think. Now the settings marked in red is another story altogether. These settings can be proven with limited analysis of the game code and through console commands to be nonexistent and ineffective. Then again, some settings may be observed by observing them on older versions of Skyrim and similarly older games running the Creation engine that employ the setting.

iShadowMode iShadowMode is believed to be unused by the game. It is recognized by the game, but does not appear to have any effect. This has been empirically verified through extensive testing with various values, all producing the exact same shadow effects. Default is 3. iShadowMode=(...,-1,0,1,...) bDrawShadows bDrawShadows is believed to be unused by the game. It has been empirically verified that this setting does not disable or enable shadows. It is recognized by the game, but does not appear to have any effect. Default is 1. bDrawShadows=(0,1)

iShadowMaskQuarter iShadowMaskQuarter is a shadow setting that cannot be altered, whose default value is 4, and shall forevermore be 4. This value is written and rewritten to the INI file every time the game is run, needed or not. Indeed, setting the file to read-only mode is the only way to change the setting and it not be altered, but even then, the game still will only use a value of 4! It is impossible to change this setting's value! Default is 4. Low and Medium presets are 3 (which will be replaced with 4 upon first run of the game). High and Ultra presets are 4. iShadowMaskQuarter=4

iShadowFilter iShadowFilter toggles the shadow filter on and off. If set to a value between 0 and 4, the shadow filter is on. If set to any other value, be it below 0 or above 4, the shadow filter is turned off, which causes buggy shadows that induce CTDs. It is recommended to leave at its default value, since all values between 0 and 4 produce the same result. iShadowFilter=0, 1, 2, 3, or 4 iShadowFilter=Any value other than 0, 1, 2, 3, or 4 The buggy shadows produced by turning the shadow filter off. Default is 3. iShadowFilter=(0,1,2,3,4,5)

If you translated the file paths and did not do so for the folder structure as well, that would explain this.

That dot should NOT be there. Fixed.

Looks like a UAC issue or file is set to read-only issue.

I did it that way on purpose, Tech, so that each link would open in a new tab automatically.

I use Hjerim with my own custom modifications I created in the Creation Kit. One of these days I'll release it as a mod.

I've always wanted this core, but we should have a look at SparrowPrince's Fixas as well.

Make sure all your BSAs are ticked in the Archives tab and the ArchiveInvalidation BSA is at the top. I have heard that MO might not work with the Steam version, but I'm not sure.

I had the impression there was a thread for this already.

This template potentially could have more uses than just for the INI TOC, which is why I named it the Columns template.

I understand the sentiment, and agree, but in practice, we do with what we got. All you would need to do in this case is Verify Steam Cache and the uncleaned files would restored. And the "MO stuffed my game" mentality is always a legitimate possibility that all modders must accept. If you mod your game, you will crash at some point. It's just the way modding goes. One needs to learn to deal with that and remember that the mods are free. And yes, it is moot once Tannin changes the hook. The only way that this could be "fixed" is by having two separate hooks with an advanced toggle between both to remove MO "replace file via guess" functionality, which I would be highly in favor of. If that happened, we could probably allow DynDoLOD create its files into Overwrite naturally.

It isn't a significant change. It's been like this for a long time with the hooking procedure of MO. MO uses a guess procedure connected to time, if I remember correctly from Tannin explaining it, that enables MO to replace a file. All that would require for behavior to act different in cases like this would be a subtle difference, say an addition to fix some other random thing, to add a little more time between file creation and the guess timeout to create this phenomenon. And the changes in this kind of behavior have never appeared on the changelog as far as I can remember (and that has been a while - back when 0.12.9 was the stable version...). And it probably has never been something intentional. I suspect that the optimizations that Tannin made to the hook with the 1.2 series changed the behavior because of the speed difference, and a change in the 1.3 series just added a little more time to it that changed it for us with slow HDDs. But... since SSDs have been mentioned... that opens up another possibility. Perhaps MO will not change the files, but merely overwrite them, when the MO program is located on a different drive than the file being modified. Whatever the case, it seems that both are possible outcomes, and it is simple to merely support both possibilities.

My question is how well does the splash of rain sound effects mesh with the new AOS sound effects for rain indoors?

Makes sense. Marked as solved.

If you really want to have the "mod," you can simply copy the ESM and put it in the mods directory inside a new folder.

Might not the larger basket possibly introduce clipping issues at some locations? Also, what is the vanilla appearance?

What do you mean by "MO does not register the change of the update.esm." The file is cleaned, is it not? That's the whole end goal. I will try to revise the guide to account for this irregularity.

Where do you have Oblivion and Mod Organizer installed?

No. Because of your SSD, yours is too fast so it DOES pick it up. I have a HDD, and it doesn't. At least, that's my theory.