DoubleYou

Texture mods must install to: \Documents\My Games\Starfield\Data This is being forced currently due to Photo Mode and Message of the Day being automatically generated there at game startup, and the game reads the first top level directory, in this case Textures, from the My Games location first, disregarding all the rest.

OP updated with the missing settings I was working on adding. There were 732 settings that had retrieved NOT FOUND values from the console but actually seem to work in game via the preset ini files.

I have not. I've been busy documenting about ~600 settings currently missing above that presumably can be set via the preset inis. It is proving very difficult, as I don't really have a way to retrieve a default value for the settings.

They did some very strange things to make the in-game preset thing work, which makes things a real PITA for manual tweakers. Basically the presets for each setting (e.g. Shadows) loads the Shadows settings from the corresponding preset ini file (e.g. low). What I intend to implement via Bethini Pie is make everything rely on Ultra.ini file, and just edit it as an additional ini file.

I am testing a few settings I missed. I see I have a fFlightCameraFOV:FlightCamera setting that I missed. It likely can only work if you put it in your preset ini file (these ones that don't work in the console seem to only work in the preset ini files) such as Ultra.ini in the game folder. No idea what the default setting is.

Typically in Bethesda games, FOV changes via ini settings have always had limitations/issues such as you describe, and are typically solved later with a mod to fix those issues, typically with a FOV slider in a MCM menu. I haven't toyed too much with the FOV settings at this point, however, you can easily see if any of the settings will help you fix by using the setini console commands for the setting, as they typically will take effect in-game without needing to reload: setini "setting:section" value

Thanks for the report. Old BethINI is being replaced with Bethini Pie, so this will undoubtedly be solved then.

Discussion topic: Real Flashlight by DoubleYou Wiki Link

The meta.ini file would be made by Mod Organizer, and it really doesn't matter if it is there or not.

Discussion topic: Enhanced Blood Textures by dDefinder Wiki Link

In Mod Organizer Settings, got to Paths tab. That shows where your profiles are stored. Typically go to the base directory location noted up top, and you should see the Profiles folder, with the Step Skyrim SE profile folder inside it.

Beside "INI Path," select the browse option and browse to your profile location for the ini files. The automatic Mod Organizer detection is not 100% reliable.

Starfield Default Values for All Known Valid INI Settings Get the Bethini Pie Performance INI Editor for Starfield and other games here, which will be updated as more and more useful tweaks are found: https://www.nexusmods.com/site/mods/631 Starfield doesn't seem to allow dumping all of the in-game settings via the saveini console command as allowed in previous titles. Therefore, this list may not be entirely complete/accurate. This was compiled from strings dumped from the executable, and the default values then retrieved using the getini console command. getini "setting:section" That being said, this list should be very close to complete, barring any mistakes on my part, or any additional settings that may be added via official patches. Any additional suspected settings must be verified, typically using the console command above, before being added to this list. If it returns "NOT FOUND," that means the ini setting is most likely invalid, but not necessarily so. Renderer Quality ini settings cannot be retrieved via the in-game console. Starfield makes major departures in handling of INI files versus previous games, but some rules are the same. Therefore, I have broken it down below in the order in which they override one another: Starfield.ini located in the game directory Appears to allow all settings to be set in it except for Renderer Quality settings. It is recommended to avoid editing this file as it may be reverted if your game is updated. Your language ini file in the game directory (e.g., Starfield_de.ini) This ini file appears to follow the pattern of whatever language string is set in the sLanguage:General setting, so since default is en, it will look for Starfield_en.ini in the game directory and load it if found. Obviously Starfield_en.ini does not exist unless you create it (which you probably shouldn't do). This is obviously intended to set the language settings. It may be possible to set other settings in these files, but should be avoided for obvious reasons. StarfieldCustom.ini in the Documents\My Games\Starfield directory It is recommended to use this ini file for most of your edits. Appears to allow all settings to be set in it except for Renderer Quality settings. Plugin ini files Plugin ini files appear to behave the same as previous games, where it will load an ini file that has the same name and location as the plugin. As in previous games, it is expected that it can set any setting that is NOT valid in StarfieldPrefs.ini and is not a Renderer Quality setting. StarfieldPrefs.ini in the Documents\My Games\Starfield directory Only a select set of settings can be set via this file. Some of the settings listed below as in StarfieldCustom.ini file are likely also valid here, but this is not the case for a large quantity of them. Only settings that are verified as working here are mentioned below. Determines what Renderer Quality ini file(s) are loaded as detailed below. Renderer Quality ini files These are the Low.ini, Medium.ini, High.ini, and Ultra.ini files in the game directory These files are special and are designed around the in-game settings menu to facilitate setting most of the important settings that affect performance. How these are loaded is very complex, but I will try to explain it as simply as possible. The game will load one or more of these INI files based off the Renderer Prefs Quality settings as set in StarfieldPrefs.ini or as loaded from the default values. The Renderer Prefs Quality settings are all the settings in the [Quality] section as detailed in the StarfieldPrefs.ini. The Global or default ini that is loaded is determined by uGlobalRendererQuality:Quality. The values for all the quality settings work like so: 1 equals Low 2 equals Medium 3 equals Ultra 5 equals whatever setting is set in the uGlobalRendererQuality:Quality For all Renderer Prefs Quality settings, each corresponds to a Section in the relevant Renderer Quality ini file. So, for example, uShadows:Quality if set to 2 will load all settings in the [Shadows] section of the Medium.ini file. If set to 5, it will load according to uGlobalRendererQuality:Quality. So if uShadows:Quality is 5 and uGlobalRendererQuality:Quality is 1, it will load [Shadows] from the Low.ini file. This means that if you want to manually edit things cleanly, you need to pick a singular Renderer Quality ini file and set all the Renderer Prefs Quality settings to it. Bethini Pie does this automatically when you use its presets, and uses the Ultra.ini file as the singular Renderer Quality INI file to be used. As an added bonus to how complicated these are, none of these settings can be set in any other ini file, and none can be manipulated via the in-game console. Do NOT use these as your INI files. This is for reference only. StarfieldCustom.ini StarfieldPrefs.ini Renderer Quality INI Settings (Low.ini, Medium.ini, High.ini, Ultra.ini)

In the game console, type the following and report the value: getini "iFPSClamp:General"

I don't object. Just want to test it.

Probably most important is to check in-game to see what it looks like, most notably looking for any difference in z-fighting around water, and transition from full cell to lod cell. This may be somewhat difficult to show in screenshots. It would seem that Optimize Unseen can significantly impact number of vertices, so in a heavy lod game with lots of 3d tree lods, it probably does have a noticeable performance impact.

Below is a copied post by aers as relates to the reference handle cap. Posting it here, because having this information only on Reddit is not the best idea. The way the engine handles this internally is pretty simple: all persistent references are loaded into memory before you even hit the main menu, and temporary references are loaded on-demand from your files as needed (for example, if a cell becomes active all its temporary references will load). The majority of these temporary references will then unload when they're no longer needed by the game. Reference Handle Limit Reference handles are how the rest of the engine looks up loaded reference objects (the technical details are pretty unimportant here; just know that every reference will have a handle). There's a cap of 220, or 1048576, active reference handles at any time. If you hit the cap, the game will either get stuck loading or just outright CTD or really do any number of things. The Problem 220 is a pretty high limit and something you probably shouldn't hit during gameplay: there's only a limited number of cells actually loaded, and the vast majority of references are temporary, not persistent. Until you actually look at the load process and realize that temporary reference loading/unloading is exclusive only to masters and not regular plugins. All temporary references from regular plugins are loaded into the game before the main menu. This includes if you overwrite a master's temporary reference in a plugin (every light source ELFX moves? yup, loaded at the start now). To give some numbers that put this in perspective, Forgotten Dungeons SSE has 136356 temporary references. Vigilant has 110770. These two plugins alone will put you 1/4th of the way towards your game simply not working. I want to clarify that this does not mean these are bad mods - Bruma has over 130k temporary references itself, for example - the problem here is that these mods are plugins when they probably should be masters. Presumably when this system was designed however many iterations of the engine pre-Skyrim ago the idea was that anything that added so many references was going to be a master. Another thing to keep in mind is that during the course of gameplay a lot of references are created unique to your save game, so you can get to the point where your load order + your save game will start to break even if it seems like your base load order is fine. Checking Your Load Order Grab this xEdit script and put it in your *edit/Edit Scripts folder. Then load your entire load order into xEdit and right click -> Apply Script -> choose count_loaded_refs_in_load_order and click OK. This will take a few minutes to run, and then print out a log of all the refs in your load order that will load before you hit the main menu. Found 0 temporary and 41433 persistent (41433 total) loaded references in [00] Skyrim.esm. ... Found 67275 temporary and 125 persistent (67400 total) loaded references in [16] EnhancedLightsandFX.esp. ... Found 112449 temporary and 4585 persistent (117034 total) loaded references in [67] Vigilant.esp. ... Found 365172 temporary and 140045 persistent loaded references, for a grand total of 505217 loaded references. The script isnt perfect but it will get a very close approximation (in this test load order I'm using, its ~2000 under what is actually reported in-game). If your total references is near 1048576, and honestly even if its above 900k~, you're in pretty dangerous territory. When Ralgor discovered his own load order was causing crashes due to hitting the reference handle cap, he was at ~1million and trying to enable DynDOLOD, which adds a bunch of references, was causing his game to break. Solutions One solution would be a plugin that raises the reference handle cap. CK fixes does this in the CK because its the only way to feasibly load a large worldspace plugin, since the CK has to load all temporary references as persistent anyway. Doing the same in SSE itself is a lot harder because of differences in compiler options. Another potential solution is to hook the game engine to treat every plugin as a master for purposes of loading. I've been exploring this solution with the help of the xEdit team but there's nothing concrete decided yet. The 'easy' solution then if you're at the limit or very close and its making your game unstable is to either remove the heaviest offenders from your load order or turn them into masters via xEdit. Keep in mind that making a plugin a master means it now has to load at the top of your load order with the other masters, before any plugins, which is why this might not be an easy solution depending on what the plugin in question is. TL;DR Temporary references in plugins don't behave the same way as temporary references in masters so you can easily hit the reference cap of 1048576 with a lot of plugins that add references. Use this xEdit script to scan your load order. If you're dangerously close to the cap remove the heaviest offenders or convert them into masters. Realistically you want to be nowhere near it because the longer you play the game the more references end up in your save game and the closer you could end up to hitting the limit. Thanks to Ralgor for throwing together the xEdit script.

Marked for Testing.

Marked for Testing.

Marked for Testing.

Marked for Testing.

Marked for Testing.

Marked for Testing.

Marked for Testing.

Agreed. Sorry if my commentary seemed reproving. xLODGen has option to create mipmaps or not. It is impossible to tell if the game uses the mipmaps without alterring the individual mipmaps to represent different colors so you can see them switch at different distances. Say you make the top mipmap level green, and all other mipmap levels red, blue, yellow, etc. If it is green at all distances, the mipmaps are unused. If they are any other colors based off distance, the mipmaps are used. It is simply a testing technique. See this video as an example of utilizing this technique: