Towards the end of a tightening down of my fo4 modding setup. Tracked down some bad materials crashing the game... people insist that a bad texture or material can't do that, but ime it definitely can. Still messing with lighting overhauls, but have yet to find one that doesn't break SOMETHING, even when there is no conflict.
My big project is dealing with all of my textures.
With bethesda games you can replace textures in two ways. Number one is loose files. This has the advantage of allowing you to add/remove individual texture files within a pack or prioritize different packs over one another, while allowing textures that are unique to them to still come through. In Vortex, you can even prioritize
individual textures from a pack that is overwritten over the ones from the pack it overwrites. Like, it couldn't be easier. You get a list of all of the textures and next to them is a drop down for all of the mods you have installed containing that texture. Pick the one you want. It's handy to be able to mix and match, and know what's loading from what. The downside is that it hurts performance big time when you're deploying a lot of them. I've replaced just about, if not every single texture in the game at this point with a loose one. This causes general micro stutter and little jitters when loading new cells. It also increases load times. But it's a compromise I had to make in order to get my textures loading how I wanted to. On my rig, it generally works out just fine.
The other option is to losslessly compress them into archives, which are then deployed by a dummy ESP plugin, much like scripted mods or mods that change data entries. The only problem is you lose almost all control over how they're deployed. There is no way for you to detect conflics, which the game
can see, but handles extremely poorly.
Say you have two texture packs that are compressed into archives. Each has about 100 textures in them. Between the two of them, they share just one, single texture. The rest are unique to those archives. Whichever one loads last will be the only one to load. The other 99 from the pack that came first won't load, even though there is no conflict with those textures. Basically, if there is any conflict between two archives, the one that loses never loads at all. Now, you CAN control which one wins the conflict by changing the load order, but even that sucks. On the older Mod Organizer 2 it's pretty straightforward. You can just drag and drop them where you want them. But I use Vortex, which in every other way is vastly superior, but it uses this infuriating automated, priority-based system for sorting plugins. I cannot simply go in and say "load this before this." You instead flag the plugins in question and just *hope* that it A. actually does it, and B. doesn't cause other load order conflicts. I hate it and I never use it. If I have two plugin-based mods that conflict, I go into the ESP's to change the conflicting entries or build a patch for them. I'll never understand why they did that. It just creates work that shouldn't be needed. At times I've gotten frustrated and edited the conflicts out of the mods themselves... like, I literally just deleted the data entry I wanted to have as the loser. And now I can't remember which, so there are mods I can simply reinstall that will break large parts of my setup now
Same thing would happen if I disabled the mod that was supposed to win, because the one I edited is now potentially missing vital data. Whoops! I basically have to pray I never accidentally update my game and have to update those! That would be fun to trace back... better off just pulling yesterdays backup of the whole drive at that point.
I refuse to get away from Vortex. The older managers use virtual deployment, which is always wonky. I could never get it working right with FO4, no matter how many different install guides I tried. Some stuff just doesn't load right, or at all. Not to mention it has other drawbacks, such as not allowing changes to deployed files. It's just sensitive... you have to use it for everything you do and hope the program does it right... no manually fixing things. You have to do it all through that buffer. Vortex actually uses hardlinks, so that the stuff in the game folder is actually the same file stored in vortex's archives. So if I edit, say a plugin from my game folder, it carries over to what vortex has. Not to mention it just always works because it's just a 1:1 index of a single file. I swear the performance is better too... it at least doesn't have to redeploy every time you load the game. You deploy once and the links are always there. Being that all it's doing is adding a second index for the file stored along with Vortex, they also pull back completely cleanly, so you can quickly and easily swap entire mod setups if you want. I even deploy my ENB this way, so I can have different ENB settings, or even turn it off without going through the process of finding all of the files and deleting them from the game folder. You can safely alter everything in the game folder with this method. I like it a lot. MO2 was great for Skyrim SE, which I still use it for, but Vortex is on another level of development now, and it goes beyond this. At some point I'm going to import my MO2 profile for Skyrim SE into Vortex, because it can actually do that!
Anyway... when loading a lot of textures, you really ought to have them compressed, but I hate how so many mod authors only offer their massive, wide-reaching packs in compressed form. Meaning they're making you choose one or the other. All I'm going to do is extract all of them and mix them together lol. All that you're doing is creating work for me, and anyone else who wants to mix your pack with another archived pack.
It's like, according to best practices all of your textures should be compressed, but due to the engine's severely mod-unfriendly limitations, it doesn't work out that way in 'actual practice'. They're technically right, but I think it's actually stupid. Just give people the loose files. I feel the same about 4k. You may insist that you can't see the difference on 1080p and you can make all of the technical arguments you want, but depending on the the polygons it's stretched over, you absolutely can. My favorite is when they say "A well made 1k pack is better than shitty 4k ones." It's like, yeah no shit! But a well-made 4k would be even better! Wowie! And the thing is... you can downscale 4k textures to whatever you want. Compress the shit out of them and make them look like crap, too. But there's no making heavily compressed 1k textures into viable 4k ones.
I hate that... how some them decide for everyone else how they should run things. It feels like they're telling me how to mod my games. I appreciate the fact that they're giving us the product of free labor, but some of them are so stubborn about the simplest little things. You can't even ask nicely for them, even providing everything possible to help make it easy, without getting chewed out. And it's like, if I could do it myself, I would? But I can't without the source files so... yeah.
I guess it all goes back to bethesda. If their engine could better deal with these conflicts, there would be little issue with having all modded textures be archived... so long as there is also a way for modding software to read the archives too and communicate to the game what overwrites what. There's no way it isn't possible. The team behind Vortex could do it... there's just no point if the game can't. All it would take was a simple, logic-based indexing system... could be pretty lightweight if done right.
FO4 really just isn't that mod-friendly. Go back to the precombine problem I talked about a while back. That system is even more limiting. Say I want to edit a worldspace... remove objects or move them around. In doing so I will break the precombine and if I'm lucky will only kill frame rates in that one area. Say I were to properly rebuild it and clean-up the mod file to make it run stable and smooth. Right as rain. Changes stick and everything works. Say somebody else wants to edit something ELSE in that same worldspace. In doing so they will break the precombine again. Okay... so they fix it the proper way. But now what happens is the first edit is no longer applied. Only the second mod flies. You have to merge the precombine for that cell to include both sets of changes. Not doing so either makes one not work or makes the world crumble. Now imagine, thousands of mods actually work by breaking and fixing precombines. Who is going to make a patch to account for the thousands of precombine fixes, so that you can use more than one of them together without tanking performance and stability? But hey, it's not that simple! There needs to be a rebuilt precombine for every single possible combination of those mods! And then you would need to look at what mods you have and track down the exact one you need to hold the precombine system together. So we're theoretically talking about millions of these things that would need to be made for all of those mods to play nice.
What people do instead is use an ini command to completely disable the precombine system and simply accept running the game at 30-40 FPS on thier high-end machines. There is literally no other way to run multiple mods that break precombines, which is pretty much any of the heavier ones. You're going to have at least one or two if you get into this stuff... probably more than you even realize.
Fortunately, I'm at a point now where I'm pretty settled on all of my textures. There are a few that need fixing... at one point I was mixing and matching brick textures, but I mismatched the normal maps so with certain ones they don't line up with the diffuse maps lol. Gotta work that out and get a few other odds and ends covered. I have the files, but I need to pull them out of this huge 4-part pack. After that, I'm gonna go through all of my 4k textures, compress the normals to 2k, and speculars to 1k. That's an old trick that was often done to make them run better, and it still works, but not many who release 4k packs bother. The visual difference is minimal, but the performance difference is not.
Some of them could probably be better compressed, too. There are many different types you can use for different types of textures. Normal and specular maps can benefit a lot from certain algorithms that greatly reduce filesize but utterly soupify diffuse maps, but have little perceivable effect on speculars and normals. Even with the diffuse maps, there are ways to tighten them down better than Bethesda does. Thier HD texture pack is a travesty in that regard. Some of them are literally 4x larger than they need to be in file sizer for no appreciable benefit. Even the base-game ones are pretty bad for their size. You can find packs that are literally just those better compressed, at like half of the file size or better. A lot of modders are kinda lazy about it with thier 4k textures, too. They can compress them better with little to no loss in quality... it just takes A LOT longer.
Once that's done, I have to go into my game folder and pack ALL of my loose textures into archives. I have no idea how long this will take... I'm betting too long. Hence why I've been putting it off. But it really needs to be done. I'd bet around 300 of my mods are actually texture mods. Probably worth archiving them, heh...
I turned on ultra godrays and can't go back. It does have a slight FPS hit at points, but there are some tweaks to greatly reduce the performance hit. I set up my ini to run them in a set of console commands when the game starts, just like I do for my FOV settings. Ultra godrays in FO4 really do look good, but only on Ultra, which wrecks pretty much any machine. If you turn it down to high, the resolution goes so low you get that god awful mosaic effect on the outlines of the rays and objects that occlude them. Glad to have a workaround that pads it out a bit. Basically it just cuts down on the samples and makes the rays that are cast wider. Ultimately looks the same, but asks foir less of your hardware. Bethesda could've done it this way, but I really do question their competency with the number of terrible implementations in their engine. I bet if you went into the code you'd see a ton rookie errors... maybe that's why Boris, the guy who actually works on that level to create and expand his ENB framework is always so grumpy when it comes to any problems with bethesda games
He did manage to get screen space reflections working in the latest version... looks hypeworthy in screen shots. But when you actually play the game... oh it is so bad. Harsh, shimmery, popping in and out. And there's noooo fixing that! I can't imagine the trouble he went through to achieve it though... I feel bad.
From what I've seen, the performance hit with godrays, similar to with shadows, is drawcall related. Drawcalls are higher in the day with them on... only slightly increased at night. They shoot up by as much as 5x with godrays maxed. So I go from 2000 to 10000. Completely insane! No doubt that's a CPU nut-crusher. I wonder if my upcoming CPU upgrade might help with that. We shall see.
I also cleaned up my ini's. And I may never use bethINI again. For some reason FO4 uses 4 ini files. One is fallout4prefs.ini, which is in the game folder. Mostly this contains settings you can change in the launcher or from the pause menu. It's just the bare defaults, and it always remains that way. And then in the user's documents folder are 3 more. Fallout4.ini, which is meant to be sort of a default profile for under-the-hood parameters, a second fallout4prefs, which takes priority over the game folder one for your game options - this is the one that gets changed by the game when you change an in-game setting, and then the most important one, fallout4custom.ini, which takes priority over all other inis. The premise is twofold. The user folder ones are there so different windows users can run different settings for the game and have their own saves. Fallout4custom exists for when you want to make edits to the ini without having to worry about losing working defaults if something goes wrong, handy when you're messing with parameters the game doesn't usually give you access to outside of temporary console commands. Or, say you made one change to a default parameter in the custom ini and it didn't pan-out. You can delete that particular entry and it'll load the original value stored in the other inis. If you delete the whole file, it'll simply load the untouched fallout4.ini and fallout4prefs.ini... the latter of which again contains the settings you change in the game, so that you never lose things like difficulty, audio, subtitles, and basic graphics settings no matter how much you tweak/fuckify.
It sounds convoluted and it kind of is, but the logic to it makes things easy once you understand how they all relate. Basically any tweaks you make are to be done in fallout4custom.ini... the game will always favor whatever is in there, if it exists at all. But bethini, for some stupid reason will randomly drop them in whatever ini it wants, sometimes even duplicating them across inis. Meaning your manual edits become impossible to keep track of. It also randomly changes the formatting, eliminating the spacing between sections so you can't read shit. And it doesn't cover everything, so you do still have to do manual edits sometimes. I ended up deleting all of them, letting the game rebuild the default ones, and starting from scratch. It just became such a nightmare to determine what's happening where, not to mention you're losing the defaults that the other ini's are supposed to contain. I know the software itself uses backups, but you don't have control or oversight on it, so that can fuck you, too. There's no stopping it from touching the other ini's either. If you set them to read only it'll just override. I'd have to go into windows permissions to block it out, but I don't know what will happen when the game itself needs to access or change them if I do that. Seems like a lot of bullshit to deal with. I'll never understand why bethini works this way. I can see no good reason with FO4. Maybe a carryover from older games, of which there are many ports of this same editor for. The original from however many years ago does it because it needed to, so now the offshoots do too, even if it doesn't help anything.
Like, I had all sorts of settings that were just wrong that I couldn't sift through. For one, subsurface scattering was turned-off... which makes skin look like the outside of an almond. Could never figure it out. Now I know. Never trust an app to do for you what you can do yourself!
Annnd just as I go back to the game I fall between a wall and a flight of stairs and get stuck! Gotta love it lmao. Fortunately I can go into the console turn off clipping to phase out of it. What do console players do when that happens? Cry? Load a save from however far back? Or do they actually use autosaves without it eventually messing up their save? IIRC you don't have access to the console... on console.
It mixes micro and macro management in a pretty cool way, Aven is mostly just macro at least from what I could gather in the 6 hours I played it. Couldn't get into it. But yes, lots of similarities otherwise. SM might be more complex but has a great learning curve, good hint system too. Had no problems, just surprises 
