z929669

What? Sorry, not understanding what is referenced. how about some links? I don't know what two pages/sections are being referenced here, even after reading DY's post preceding this one.

see my previous edit What?!? the four mystery settings go into skyrim.ini and NOT skyrimprefs.ini (sD3DDevice, uLastAspectRatio, bShowAllResolutions, bEnableFileSelection) ... at least the way you have it worded in the above post (which is why I made a clarification post ... see yellow text. Syntax can be subjective and some can extrapolate better than others, so better to word in a way that cannot be subjectively interpreted) ... now you are really confusing me.

OK, so the four mystery settings are no mystery at all. They are not game INIs at all either. They are effectively launcher menu config settings, and I can see why they belong only in skyrim.ini. So I thought Tannin's initweaks.ini was temporary and that it wrote to MO-profile-specific versions of skyrim.ini and skyrimprefs.ini ... ? EDIT: Also, when using colored text, could you stick with the following 'standards' for better readability? then we can update what you are currently using (mainly for red) in various places: #9eb8ee (blue-ish) - Call out text relating to addition, enhancement, or confirmation. #90e0a0 (green-ish) - Call out text relating to fixes, functional, or relevant. #ff7878 (red-ish) - Call out text relating to removal, non-functional, or irrelevant. #d8e058 (yellow-ish) - Call out text relating to issues or unknowns #e6b69e (peach-ish) - Call out important text relating to special instructions #dddddd (white-ish) - Call out important text (alternative to above)

OK, I see what you are doing on your User page, but why replicate there? Just edit the Skyrim INIs guide itself (it will not break anything unless you mess up the transclusion tag references for the STEP Guide). Then I am fine with renaming it to "Skyrim Configuration Guide" (with redirect)

No need to rename it if there is a way to smoothly incorporate this information into the new INI guides you are making. Ideally, we should have a detailed guide from which we extract information for the STEP Guide, rather than your new and highly detailed guides as well as the existing detailed guide, which I am thinking will be effectively redundant once the new ones are complete. Then we can just delete it. If it is not interfering with your current work, we can just leave it until you are finished with your guides. Then I will figure out a way to merge everything and delete this guide.

Trying to comprehend what you are saying here ... if I understand correctly, those four settings need not be called out, since they are not valid in skyrimprefs.ini (even though one might think they should be, since they are settings defined within the Skyrim Launcher). Confirming everything in a different way to be sure I understand correctly: Settings in skyrim.ini can override ALL 'default' settings hard coded within the game EXE (i.e., effectively ALL game settings if no other INIs exist)Settings that are user configurable (i.e., skyrimprefs-specific settings) ...Are ONLY configurable from skyrim.ini and skyrimprefs.iniThose in skyrimprefs.ini override those in skyrim.ini if defined in bothAre invalid when defined from Plugin INIs, and thus have no impact and cannot be overriddenCan effectively be overridden via MO INI Tweaks (presumably because MO applies the respective INI tweak to the most applicable Game INI)ONLY settings that are NOT user configurable (i.e., are NOT skyrimprefs-specific settings) are valid in Plugin INIs, where they will have highest priority ([except or including] the four mysterious GUI settings, sD3DDevice, uLastAspectRatio, bShowAllResolutions, bEnableFileSelection)MO INI Tweaks override everything ([except or including] the four mysterious GUI settings, sD3DDevice, uLastAspectRatio, bShowAllResolutions, bEnableFileSelection)

Agree. Something in the code is blocking specific tweaks if they exist within skyrimprefs.ini. My guess is that valid skyrimprefs.ini parameters exist as some explicit list somewhere and any INI params not predefined for skyrimprefs.ini (or as valid User-Preferences settings) are ignored by the routine that processes skyrimprefs.ini. Good find.

Got it, thanks. Just wanted to get diffs on the record for posterity

Thanks for the template ... Doesn't the HighslideGallery plugin already handle this?

(see my previous post)

Only your video card is 'hurting' ... your CPU and architecture are up to par, and I think shadows are CPU dependent more than GPU ... and FPS I think is more directly dependent on GPU clock rather than VRAM, so you still may not notice much performance impact on your rig. I agree that the built-in game settings are the actual default settings (by definition, game settings in INIs should only be necessary for deviations from the baseline default settings). I would call Tannin's proposed "Default INIs" simply "Example INIs" (or "Performance Baseline INIs") and Tannins "Base INIs" might be better named as "System Baseline INI" (skyrim.ini) and "User Preferences INI" (skyrimprefs.ini) I thought all MO-specific INI changes were supposed to be compiled into respective System Baseline and User Preferences INIs inside Overwrite ... ? What about mods that don't have any plugins? They can still have INI tweaks. I would remove the paperclip from plugins and represent this ONLY in mods analogous to other file types icons used in the left pane (BSA, textures, meshes, etc). This is more consistent. I think you mean that the 'saveini' console command only fetches decimal rounded to four sig digits, whereas Arisu's method fetches the floating-point numbers (or the 8+-digit rounded decimals?) Strange that only the 'distance' settings created in the GUI preferences go into skyrim.ini and all others into skyrimprefs.ini ... would like to make sense of that logic. Again, maybe you are referring to floating point rather than decimal ... meaning that the number must be accurate to a min decimal place (or transcendental numbers like Pi are not really defined explicitly but must be dynamically passed inside the EXE) iPresentInterval proves this statement, but we just don't know what other settings behave in the same manner and why (given previous assumptions). I'll bet bReflectLODLand, bReflectLODObjects, bReflectLODTrees, and bReflectSky all behave this way too though.

Ahh, I see. I am even less privy to the beastly CK (whom I hate so much but so desperately appreciate)

OK, I see it is a plugin ... but how does one 'paint' a record? I am assuming that this is an opacity setting? EDIT: Examining in TesEdit shows "vertext height map" changes to "alpha layer" ... so seems to be adjusting opacity (but I do not pretend to understand how) Looks like an essential fix that we need to use (the only conflicts seem to be skyrim.esm and update.esm) Marked for testing

Anybody know if this is a retexture, a mesh fix or a plugin-based or other fix? A retexture obviates it for STEP, and mesh might as well, because it will likely conflict with current and vital mods in STEP. However, if the fix is by some other mechanism, then it seems very applicable.

OK, let's once again list all of the INI types the game can handle (denoting those from the MO perspective). This post and subsequent posts get into this, and the thread was 'resolved', but I think all concepts as laid out in that thread are still semantically unclear and confusing. Is this covered better in the MO guide? Let's do it here and get it into a preface to the skyrim INI guide (or the MO guide). Following is Tannin's revision of my original proposed INI nomenclature from that thread ... what did Tannin ultimately implement in MO?? (and is it documented in our guide?): Game INIs:Default INIs: the _default INIs located in /skyrim Base INIs: The standard game INIs located in %USERPROFILE%/My Games/SkyrimMO Profile INIs: The MO-profile-specific Base INIsINI Tweaks: Mod-specific INIs that exist in an INI Tweaks folder at the top level of the mod packageINI-Tweak Composite: [ The temporary combined ini tweaks generated from combining the ini tweaks ] Plugin INIs: INIs loaded with like-named plugins (just like BSAs). [ Presence should be indicated by the paperclip on the mod in MO (left pane). ] Plugin INIs should have the paperclip within the plugins list (right pane) as is now the practice. Now back to how the INIs work to clear things up in this thread (and hopefully update our wiki doc on this subject where appropriate). Trying to understand, and differing semantics are making it unclear: All game settings have default values hard coded in the game files Some game settings are configurable via the game GUI. [ These changes are saved out as INI settings ] Some INI settings are apparently ineffective, regardless of where they exist. [ (they are either mistakes [invalid or redundant] or imperceptible under normal playing conditions) ] All effective INI settings have an impact (i.e., are valid) when defined within skyrim.iniSome effective INI settings are ONLY impactful (i.e., valid) when defined within skyrim.ini (e.g., iPresentInterval). Also, performance impact of bShadowsOnGrass and bTreesReceiveShadows can be pretty significant on low/low-mid systems I think.

Well .... iPresentInterval ONLY has impact when placed in Skyrim.ini. It has no effect when placed in SkyrimPrefs.ini. I did extensive testing to confirm this (so did Tech), and the evidence is in the bugs thread I think. What do you mean here? I understand the INI hierarchy, and this theoretically should mean that ALL INI settings can be placed into Skyrim.ini. Only in cases where one is running under multiple user profiles (thus validating use of SkyrimPrefs.ini) or loading specific plugins that depend upon specific INI settings (thus validating plugin INIs) have need of the other INI files. EDIT: a good way to invoke ENB-specific INI settings may be to use a dummy plugin or dummy mod with the INI overrides. Unfortunately, settings like iPresentInterval break the supposed rules (perhaps you mean Skyrim.ini??), which tells me that there are INI settings that are hard coded into the game EXE (or DLLs?) that can only be overridden from Skyrim.ini and nowhere else. Additionally, we have to assume that not all INI settings are created equally: ?most? settings can be invoked from any valid INI file. These settings must have default values coded within the EXE that can be overridden; however, other "higher-level" settings can only be invoked from Skyrim.ini (e.g., iPresentInterval), so these settings must have special treatment for some reason ... ultimately, I don't trust that the general hierarchical INI rules apply in all cases. By the same token Yes, this was my understanding of how that setting was supposed to work (and it should not affect grass rendering at all ... as you show here, the save game has that data). It does cause a significant performance hit though in terms of FPS. Good performance tip.

Yeah, it may be worth checking though to see if the textures we do use are better (i.e., like Recolored Pines) and trim down this version and reupload. Vurt had me as a contributor, since I created the Recolored Pines + LOD and added that a long while ago. He has since cleaned up his files and contributors I assume, so I am kicked ATM.

I seem to remember reading that this setting causes a performance hit when enabled (it's a toggle), but I don't recall that the effect was perceptible at all. Intuitively, it seems like it should enable rendering of object shadows on the grass, but I recall that it may have had more to do with grass itself casting shadows. Not sure why it would matter to ENB. My gut tells me to have this setting disabled (set to zero) in all cases. We may want to test if it should be in Skyrim.ini or SkyrimPrefs.ini. Many settings should be confirmed that they belong in either of the respective INIs just as we found with iPresentInterval

It may be time to look at SFO 2.x versions now. vurt has updated very recently

It would be nice to know what FOMOD attributes are causing the crashes though ... do the bug reports provide the details on this?

We have simple instructions for installing the BAIN version. I can see the FOMOD not playing nicely with newer versions of MO if MO has adhered to a standard from which the FOMOD deviates. It could be a very simple code fix in the installer.

Thanks for creating the INI guides! The existing "Skyrim INIs Guide is for use with the STEP Guide. It contains transclusion tags that transclude relevant peices into the main guide. It may be wise to move these pages underneath the new INI guides and transclude from there though so that it is all together. Be careful though and note how the transclusion is working (I can work on this too at some point). Regarding the new guides you made ... the main page formats and categories are correct, but if you could move all settings to subpages under subcat "INI Settings", that would align with the ENB INI guides and categorize everything consistently (see cats fop examples). Again, I can help with this if you are not inclined.

Try clearing your cache or restarting your browser

Agree that "not loading something" is probably a bit more optimal than "loading nothing". We heed to look at all the mods referenced here for STEP.

@Sparrow I have not had a chance to look and compare the reduced normals to the originals ... is there indeed a problem that you can confirm? This would then apply to all of the performance versions of his mods. All of his mods look good for STEP testing, but only if this issue is resolved, since many of our users require performance versions.