Tannin requested our help. Quick Tip MO feature explained, ini tweaks option.

[GSDFan]

Back a few versions, Tannin introduced a feature called ini tweaks. You may have seen it when you view the information for a mod in the lower left of the of the “INI-Files†tab. Most if not all mods do not have anything listed in there. The following information is accurate as I see it and has been verified in MO v1.0.5 RC6.

 

Back then, anafuineluva, on 09 February 2013 asked this question, “Does ini tweaks apply over skyrim.ini only? Is there a way to apply them to skyrimprefs.ini too?â€

 

To which Tannin replied, â€ini tweaks do not change skyrim.ini or skyrimprefs.ini, they are used instead of them. This means that if a setting exists in ini tweaks, that setting is used over any other ini. In fact, as it stands right now, ini tweaks should even override settings from other ini files, i.e. skse plugins, but I've never tested thatâ€.

 

I have made use the ini tweaks for the settings that S.T.E.P. recommends and also for the fonts entry needed for DARNui in newvegas. I set up a mod with them and installed it, this way when I switch profiles, I just enable it and do not have to worry about editing the ini itself. Nice feature.

 

To set up a new custom tweak you can do a couple of things. With MO closed create a new empty folder in the Mods directory and restart MO. MO will now show the new folder as a greyed out mos. An easier way to do this in the current version of MO, is if you have an empty overwrite folder to double click on it open it up and right click and create a new folder, you do not need to rename it. Click close to exit the overwrite folder dialog.

 

With that done you will be able to right click on the overwrite folder and select “Create Mod†from the right click menu. Give it a name that reflects what you want, something like Custom ini Tweaks and press OK. You now have a new mod named Custom ini Tweaks.

 

In either case double click on the new mod to open the information pane and select the INI-Files tab. Click in the lower left box and right click to get the “create Tweak†fly out menu. Enter the name of the tweak in the dialog that pops up and click OK.

 

Say you want to do the fonts from Darnified Ui. Name the tweak Darn fonts and click OK. Click on the new entry and in the big box on the right copy and paste the whole section from the readme starting with the [Fonts] header. The save button will become active, click it to save the tweak and close the information pane. Re-open the information pane and the new tweak will now have a check box next to it, click it to put a check in the box to activate it.

 

Another option is if a mod needs a certain entry for the mod to function right you can just open the mod and create the tweak for it there. The iMaxGrassTypesPerTexure=XX in Skyrim Flora Overhaul by vurt comes to mind. Don’t forget the [grass] before it. This way the tweak will be enabled when the mod is.

[phazer11]

No. I've never had the launcher change my Mod Organizer .ini's it'd have to have a whole lot of permissions it shouldn't able to get to change files in Mod Organizer's folder but that's a whole other story.

[Tannin]

This issue has been on my backlog for a while now. Sorry it took me so long to reply. I'm a bit at a loss on how to approach this problem, maybe some of you have good ideas: the initweaks.ini is created at time of game start by combining the individual ini fragments (aka tweaks) from mods so its temporary and used as an "overlay" whenever the game reads ini settings. Now the problem happens as the game writes ini settings (potentially with the same values read before). Now what's the right place to put these writes?

 

a) the regular skyrim(prefs).ini file which is where the game intends to write. This is what currently happens. It is confusing and broken because read accesses will still go to the initweaks.ini. This means that settings made through ini tweaks become effectively read-only (which may be a good thing), though the vanilla inis still get changed.

 

b) the initweaks.ini file. In this case the settings get modified for this session but thrown away on every restart which would still be confusing.

 

c) the ini fragment which was integrated into initweaks. This would persist the setting while keeping those settings out of the vanilla files, but it means the ini fragments get modified which is probably a bad thing (*). Also it would be a ton of work for me.

 

d) a whole new ini file (in the overwrite directory?). This would be consistent with how other file modifications end up in overwrite but it would be another layer of ini virtualisation so not exactly easier to comprehend.

 

(*) Modifying the ini fragments is a bad thing because they are set for a reason. Usually ini tweaks are made because a mod requires a certain setting so bundling this setting with the mod is a cool feature (the whole point of the initweaks actually). If you could inadvertently change the setting from the game ui you might break a mod and never find out why.

[MilesTeg]

I would vote for d)

It`s a clean solution imho. And a simple doc/graphic would be nice that explains the relations. s.th. like:

 

Skyrim Main Game ini

\_ Profile ini\_ Mod inis\_ overwrite ini

 

 

And some spontanous ideas/suggestions about ini editing (involving hopefully relatively slight code changes):

- make the configurator the default ini editor.

- if the user or game want's to edit the ini, always write changes to overwrite

- add a general reset button that reverts all user/game changes back to the vanilla+mods settings.

- add a button to open the (resulting merged) ini within the default text editor. User can apply changes and easily search by hand for keys/values. After the editor gets closed write all changes into overwrite dir.

 

I think with the virtual file system you could easily add another (cool?) feature:

- within the overwrite you could create a simple versioning system (skyrim_1.ini, skyrim_2.ini etc.). This way the user can just skip back to an older setting if things go south. So in the GUI just add two arrows (like webbrowsing history) and the date of the last change.

 

also with all those layers, would it be a lot of work to add the skyrim presets for "low, normal, high" (+ maybe even community accepted) settings?

[wolverine2710]

I have moved the thread from the 'Mod Organizer - Key Threads for Wiki' subforum to the main forum. I had the feeling this very important thread and the request by Tannin deserves more attention. Please let Tannin know what your preferred solution is.

 

Edit: Tannin on the issue tracker 'confirmed' a few days back there (sometimes) is a problem with ini files. See for more details see 'Bug report #453  -  Ini-Tweaks not reverting to default values when deactivated' in the issue tracker. You must be logged in to see the comments made to the original post.

[z929669]

I would vote for option B ... initweaks.ini for storing the INI rewrites. I don't care if the tweaks do not persist. This is consistent with all the resto f MO. Nothing persists, and that is the whole point. As long as the references persist, that is all that matters. The INI Teaks folde contains the references (as does the plugin INI tweak) ...

 

We really need to nail down the nomenclature, or we can't communicate effectively:

• Game INIs
  • Skyrim INIs: The standard game INIs located in %USERPROFILE%/My Games/Skyrim
  • MO Profile INIs: The MO-profile-specific Skyrim INIs
• Mod INIs - 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.
  • INI Teaks: Mod-specific INIs that exist in an INI Teaks folder at the top level of the mod package.
  • Plugin INIs: Mod-specific INI tweak analogs of the plugin that loads them. These sit beside the plugin in the /Data directory.

OT, sort of, but tangentially related: It is currently not possible to know which mods in MO (left pane) are associated with files hidden or plugins marked as optional. Once such files are filed away (presumably to remove the unneeded noise), it is nearly impossible to use said files if they ever become relevant (unless one makes notes about these 'quarantined' assets and their related mods). Like INI tweaks, these and all other mod-level functional tweaks should have a marker to indicate said tweaks so that they can be easily reverted if necessary.

[EssArrBee]

I would vote for option B ... initweaks.ini for storing the INI rewrites. I don't care if the tweaks do not persist. This is consistent with all the resto f MO. Nothing persists' date=' and that is the whole point. As long as the [i']references[/i] persist, that is all that matters. The INI Teaks folde contains the references (as does the plugin INI tweak) ...

It would not be initweaks.ini, that is what gets generated by MO, you mean that in the INI tweaks folder you place Skyrim.ini and Skyrimprefs.ini with the STEP tweaks.

 

We really need to nail down the nomenclature, or we can't communicate effectively:

• Game INIs
  • Skyrim INIs: The standard game INIs located in %USERPROFILE%/My Games/Skyrim
  • MO Profile INIs: The MO-profile-specific Skyrim INIs
• Mod INIs - 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.
  • INI Teaks: Mod-specific INIs that exist in an INI Teaks folder at the top level of the mod package.
  • Plugin INIs: Mod-specific INI tweak analogs of the plugin that loads them. These sit beside the plugin in the /Data directory.

I agree with these (short of the spelling errors :p ), but lets have the MO guide be the place where this worked out and then we just use MO Notes template on the STEP guide and copy paste their directions if we need to standardize the terminology and wording.

 

OT, sort of, but tangentially related: It is currently not possible to know which mods in MO (left pane) are associated with files hidden or plugins marked as optional. Once such files are filed away (presumably to remove the unneeded noise), it is nearly impossible to use said files if they ever become relevant (unless one makes notes about these 'quarantined' assets and their related mods). Like INI tweaks, these and all other mod-level functional tweaks should have a marker to indicate said tweaks so that they can be easily reverted if necessary.

Plugins that include the their own tweaks, Plugin INIs, will show a paper clip icon in the plugins tab of the left pane.

 

I think you can make notes for personal use if you want and there will be a little notepad icon listed in the same column as the overwrite icon in the right pane. I wonder if we can include our own notes so MO will show the icon for that. It would mean that we include our own meta.ini with a mod, and I have no clue if that works, but we shouldn't rule out using any advanced features of MO if it helps the end users. Hidden files show up in the DATA tab I believe with a strikethrough.

 

As far as the way these are loaded, the problem may be that we have to many places to create INI edits. You can do it manually, have one included with a mod, make an edit in the info pop up of a mod in MO, and included an INI tweaks folder. That may just be to many and there is no hierarchy that will really be the best option. A mod with specific INI edits should probably be used since the author is putting them their for a good reason. Knowing that though, STEP should not overwrite any of those INI edits (the plugins with the paper clip icon) for any reason. 

[z929669]

I was responding to this post:

https://forum.step-project.com/showthread.php?tid=3581&pid=61391#pid61391

 

and option b is to place into the initweaks.ini file.

[EssArrBee]

Yeah, we need to drop half the INI words we are using, I can't keep up with all of them.

[Tannin]

tbh I consider solution b) unacceptable. It would mean for example that you can't change your audio volume in game. Or graphic settings. Or controls. You would have to go through MO tools for everything. Even if we improve this solution to "only settings provided in initweaks are written back to initweaks, everything else goes to the regular inis", the same could still happen: Every setting provided by an ini tweak would effectively break the corresponding control in all configuration tools except MO. This would appear to users like a bug.

 

I'm currently working on solution d: If a settings provided by an initweak is set and the value is the same as in the tweak, nothing happens. If a setting provided by an initweak is set and the value is different then it is written to a new ini file located in the profiles directory. This ini file will also be applied like an ini tweak and will thus become active in future sessions. There will also be a warning notification if this file exists advising to integrate those settings into a "regular" ini file or a regular ini tweak.

[EssArrBee]

How does MO handle the vanilla INIs if they are read-only, which is what they are by default for Fallout? Can that cause problems for initweaks.ini?

 

The notification icon is a good idea since it could be hard to keep track of which mods even make a tweak. Maybe one problem is that there are so many ways to create INI tweaks through tools and added INIs in mods. There has to one that wins out, so it will probably break the others in some way. Maybe combining them somehow would be the best option.

[z929669]

tbh I consider solution b) inacceptable. It would mean for example that you can't change your audio volume in game. Or graphic settings. Or controls. You would have to go through MO tools for everything.

Even if we improve this solution to "only settings provided in initweaks are written back to initweaks, everything else goes to the regular inis", the same could still happen: Every setting provided by an ini tweak would effectively break the corresponding control in all configuration tools except MO.

This would appear to users like a bug.

 

I'm currently working on solution d: If a settings provided by an initweak is set and the value is the same as in the tweak, nothing happens.

If a setting provided by an initweak is set and the value is different then it is written to a new ini file located in the profiles directory. This ini file will also be applied like an ini tweak and will thus become active in future sessions.

There will also be a warning notification if this file exists advising to integrate those settings into a "regular" ini file or a regular ini tweak.

Option D works best then, I agree. As long as there is also a way to scrap the "option D" INI under the profile from MO (did I mention that we need a stable nomenclature for MO INI 'methods'?)

[Tannin]

Option D works best then I agree. As long as there is also a way to scrap the "option D" INI under the profile from MO (did I mention that we need a stable nomenclature for MO INI 'methods'?)

My proposed modifications to your naming:

 

* Game INIs:

   - Default INIs: the _default inis located in the game directory

   - Base INIs: The standard game INIs located in %USERPROFILE%/My Games/Skyrim

   - MO Profile INIs: The MO-profile-specific Skyrim INIs

* INI Tweaks: Mod-specific INIs that exist in an INI Tweaks folder at the top level of the mod package

* INI Tweak Composite: The temporary combined ini tweaks generated from combining the ini tweaks

* Plugin INIs: 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.

 

 

Rationale:

a) MO isn't Skyrim only so I can't talk of "Skyrim INIs". Base INIs is reasonable imho insofar as all profile inis are based on those inis ...

b) ... unless the user chooses to base them on the default inis

c) Mods are bundles of plugins, assets and ini tweaks (in MO: left pane). One mod can have zero, one or many plugins. Therefore we also have to clearly distinguish mod and plugin

d) a mod can have zero, one or many ini tweaks, whereas a plugin can have only zero or one plugin inis

e) Ini tweaks can be disabled, plugin inis can not.

[DoubleYou]

I believe this has been settled, so I'm unpinning this.

[z929669]

Thanks for reviving, DY.

 

For the record, I think Tannin's final proposal is a good one