-
Posts
755 -
Joined
-
Last visited
-
Days Won
10
Everything posted by godescalcus
-
See, this is what I mean is confusing. You say "normally are in \meshes\actors\character\facegendata" - "normally" implies exceptions... You never know. And no guide I've read or seen so far is more peremptory about which meshes do need to be optimized as head parts. It's always "normally", or "for example..." or "such as..." or something similar. It seems like we're acting on a hunch. So at the moment I know I can't trust my own ports, and I don't know if I can trust anyone else's. This shouldn't be tragic, I agree with Lexy - if we need to change mods from the classic guide we change, and a good reason for it is not being able to trust a ported mod. But most mods on the SE are actually ports. Maybe a handful state very clearly that they were completely remade for the SE, and a few may have been originally made for it (like Majestic Mountains). The rest are ports, and that's the "tragedy" Sure, we have been using them for a month here. Some we may say that work because we've not seen anything wrong with them so far. That's not so bad... Oh, maybe I'm just tired. About to rebuild from scratch for the fourth time since I can't determine what's causing the CTD I'm getting in Dawnstar - which is not SSoS, checked that and double-checked, Talos included. As a consolation I feel we're breaking gound here. And I see Lexy's move to making this guide having an effect on the current dynamics around SSE. So, end of rant and back to work :P
-
Then you must be right. In fact I always did like you say and only read you could do it in bulk. I guess I was being too optimistic! That brings back another problem, the hover text you quoted is also the only indication I have on what constitutes head parts: "Use this for ONLY head parts, such as head, ear, mouth and hair meshes". It gives me little consolation that they say "such as", as it doesn't imply that "head, ear, mouth and hair meshes" are all the head parts there is. And where exactly ARE those meshes? I assume the whole lot under "facegen" is always to be processed as head parts. But "hairs" are packed everywhere possible by different authors (but mostly in its own folder next to armors, body, etc). It's a mess that the CK doesn't force authors to pack those meshes in some particular way. You need to inspect the whole lot of meshes and, as I've been doing, sometimes move folders around so you can recursively process the remainder instead of going into each individual folder. For example, many mods have a character folder inside the meshes folder, with body parts directly inside it and then armors, hairs, even weapons foders and whatever you can think of. If you want to process the body parts and NOT hairs, you need to disable "recursive" when you process the parent character folder (so you get the nifs directly in that folder), then process each of the contained folders individually, according to its type of mesh. Or you move the head parts, like hairs, one level up, process them separately and then the character folder recursively, then move the head parts back in. Either way, it's very prone to error. And I have INDEED read in places that you DON'T process hairs as head parts! One of these is a user who has almost 300 follower ports on nexus. That's 2% of the currently available files for the SE. Makes you realize why so many mods aren't well ported at all, even though the files I've used from this user seem to work fine, even against my own ports that weren't so good. And what about other meshes, are helmets and circlets and earrings also considererd "head parts"? Where's the definitive list and, by the way, a justification for this differentiated processing so we can know what we're doing... I guess I'll have to dig further and not be satisfied with any one guide. Thanks for your thorough testing to clear this out.
-
How do you guys play the game, mostly - in 1st person or 3rd person? I ask this because I only ever play in 1st person, as I did with oblivion, Morrowind, NV. For me these games were designed as 1st person RPGs, their mechanics works better that way, melee combat can work in 3rd person but ranged attack is nigh impossible without a targeting system independent of the central crosshair. For me, aiming with the camera is just clumsy. But I know a lot of people do prefer to play in 3rd person for whichever reasons. When tweaking this build to my liking in some little details I always find myself looking for a wider field of view than 86 and thought that for 3rd person users 86 might well be enough, for the camera behind the character add a little more peripheral vision. I also feel, as a 1st person camera user, I don't really get to enjoy the care and detail put into animations like DSR (not in SE yet, but for the sake of example) and a few others, even 360 walk and run is pretty useless if you don't play in 3rd person. Most other animations are also less impacting if you're not in 3rd person. So I began to wonder... Is this guide optimized for enjoying 3rd person camera view? ;) As someone who went through Ultima Underworld, Wolfenstein 3D, Ultima 9 and so forth up to Skyrim, I think this might even be a generational thing, that RPG and FPS have become distinct niches and people more attached to one tend to reject the other. I also played Ultima VI, VII, VIII, Ultima Online, Dungeon Siege, all Diablos, only didn't go to ESO because I don't have time for online playing anymore LOL so I'm well acquainted with 3rd person perspective, only don't really know how it fits with Bethesda games and think at least some people who prefer it may be trying to bring the games closer to their generally preferred game type.
-
SRLE Extended: Legacy of The Dragonborn
godescalcus replied to Darth_mathias's topic in Skyrim Revisited (retired)
Hey guys, wanted to ask about the Heads-Up Display merge. Lexy told me recently that one should be careful about merging mods with dlls. But Equipment HUD has a dll and is in the merge, so why isn't AZMoreHud also in? -
This could actually be an interesting course of action. Taking a lot of discipline as we all have our favourite mods from classic, and some digging and testing to find proper SE replacements but it might lead to a differentiation between this guide and the classic guide, making them two different beasts.
-
It's one way of doing it. Head parts can't be processed with the same parameters as other meshes, so NIF optimizer gives you the option to do it separately. If you process head parts FIRST (this is important) by ticking the "head parts only" option, the second run on the same folder/subfolders will ignore those because they're already optimized, so just UNCHECK "head parts only" and do a second run. The other way is to process the subfolders insider the main meshes folder separately, carefully picking the ones containing head parts and doing those with "head parts only" selected, and the others without (I think this is what Weasel did in the first video I watched for this). But this is very prone to error and I've never been sure of which meshes are "head parts" (should be facegen only, but what about hairs and stuff?). So the two step using the "recursive folders" option on both steps and processing from the main meshes folder is the best way to go, just never forget to do head parts first. Once those are optimized, you can optimize a second time and the program will ignore the meshes that have already been optimized. You can verify all of this by checking the log file in the NIF optimizer folder after each run.
-
I have got a confirmation that the bashed patch likely doesn't include sound records conflict-resolved by load order - I mean, it will contain sound records if the merged files have sound, but if there are unmerged files loading later that don't make it into the merge, their values get overridden by the earlier-loading esp's that made it into the bashed patch. The two options I see are 1) make a specific cr for audio that will hopefully be melted in the bashed patch, carrying the final records, or 2) make the cr load after the bashed patch, which means it shouldn't contain leveled list edits. In my opinion, first option is better overall.
-
Actually I need to correct the information I provided above, as I was misinterpreting alt3rn1ty's post which you can read from the link I added. Textures packed in the new ba2 format will NOT be automatically converted to BC7, what alt3rn1ty says is that they will probably have the mipmaps packed separately from the main texture and that should boost performance by itself. Anyway, I also feel my SSE build is more stable without optimizing any textures so far.
-
I'm also trying Immersive Sounds Compendium (with patch provided by AO2) and I must say I like it so far, especially the weapon sounds. I really don't know what happens with mods that DON'T make it into the bashed patch, like an overall CR probably won't. Patches merging into the bashed patch will override it, or does the bashed patch check for overrides and incorporate them in the merge? I tend to believe it handles these conflicts, but will try to get a confirmation. If it doesn't, probably a specific audio CR would be best as it would probably also make it into the bashed patch and the latter will then be conflict resolved. The skyproc patcher page mentions DSR - is it going to make it into the guide? I'm just curious as I didn't use it in the classic, since I never play in third person... Only see the back of my character during horse rides, mining or kill scenes.
-
Add more to the previous post: upon further reading, it seems that mods that were repacked for the SSE using the official archiver (probably all or most that have their assets packed in the BA2 format) would have their textures converted to BC7 format, so check for that in mods that you want to optimize, namely those I mentioned that require optimization according to the classic guide. In the light of this fact, I'd say all mods released originally for SSE and many mods that were ported and packed using the official tools won't require/allow optimization using either Optimizer Textures/Ordenador or DDSOpt. These are tools made for the 32bit version that have not been updated to work with SSE's new assets' formats. Source: https://www.afkmods.com/index.php?/topic/4950-optimized-vanilla-textures/
-
I'm not an expert in DDSOpt as I've become acquainted with it only recently by following the classic version of this guide. I do advise you to use it as a reference, as it contains instructions on some textures that need optimization and links to the STEP article describing in detail the procedure you should use, how to set up DDSOpt and the different options for optimization. I've never used Optimizer Textures/Ordenador but I've read about it and conclude that it's more direct and user friendly, while DDSOpt gives you much more fine control and results in greater quality (optimized) textures. In the classic guide there are a few mods that have textures requiring optimization, and those are clearly pointed out (examples, Falskaar, Helgen Reborn or bethesda's own textures - if you prefer to do the optimization yourself instead of downloading the pre-made optimized packs also linked in the guide). From my experience in porting mods to SSE, I'd bet people (mod authors as well as mod users) will convert the plugins and havok animations, optimize meshes and, more recently (only mod authors) recompile dll's for SKSE64. Since textures are pretty much directly usable in SSE, most will probably leave them as in the original classic Skyrim mod. SOOOOO - I *assume* that those mods that the classic guide points out as needing optimization will also benefit from the same procedure in this build. If you want you can ask the author or try reading around to find whether or not it's really necessary, but as a rule of thumb you can always try to optimize and if it doesn't yield any gain, the textures were probably already optimized. While optimizing, I'd advise you to try first using the maximum quality constraints (8k x 8k, lossless compression, check the setup guide with images). Many textures will benefit by simply being arranged in an optimal way and those settings will achieve you that, with zero loss in quality. If you need further reduction to save more VRAM try using other compression options or even downsampling textures by using stricter constraints (like 2k x 2k or lower). An important thing about DDSOpt is that it allows you to optimize color maps, normal maps and other types of textures separately, only by using wildcards when selecting which textures to optimize - this procedure is described in the links provided in the classic guide for optimizing bethesda textures, you need to pay full attention to not miss any detail in the instructions. You absolutely DON'T HAVE TO optimize different maps using different settings; only if you need further reduction, downsampling normal maps, for example, while leaving color maps in full resolution may achieve you enough VRAM saving with minimal loss in quality. And DDSOpt gives you that much control. This was not a direct answer to your question but I thought I might add this much. I don't know if BC7 textures will be skipped or not. My suggestion would be to ask in the DDSOpt download page, where, by the way, @alt3rn1ty has recently relinked the documentation wiki which had its link down in the description page. "Might" be worth reading ;) Add: another useful link concerning DDSOpt: https://www.darkcreations.org/forums/topic/1639-rel-vanilla-reduced-textures/
-
With the right ENB and weather mods you could even picture yourself in MARS Hey, maybe that's where that nasty darkside came from! :P I for one don't dislike grey stone; first and foremost, because grey offers a good contrast to the already colourful landscape. As I said before, the darkside textures are stunning, but I get tired after admiring them for a while. There's too much information there for something that your brain should process as background. The second reason is realism. Let's face it, most of the rocks in the world have neutral or very unsaturated tones. There are exceptions, of course, but to have a whole landscape uniformly built as something that should be an exception, again, is too much for me. Grey uniformity is the lesser of two evils, being the neutral one, you just forget about it and get on with playing the game. Darkside is too distracting. In the ideal world you could have different rock textures for different regions, depicting some natural variability, but to have all red hell is too much for me. Skyrim would be filled with prospectors since it would be brimming with elements such as I or K. I confess I like Northfire's Photoreal mountain textures better. Even its more colorful main version (as opposed to grey vanilla style, also available) was less imposing than Majestic's darkside. If it weren't for the pain of combining it with One Mountain's meshes, that would still be my way to go.
-
The only issue I have on WB with SE (using the python version) is that when the bashed patch is done and the stdout/stderr window pops, I can't activate it. If I was doing something else while the bashed patch was building, it seems it crashed but if I context-in to the main WB window and click ok on the log, a few seconds later I'm able to also close the stdout/stderr window. How many plugins did it take from your load?
-
Running the latest wrye, Darth? Older ones like the beta1 at nexus are not for SSE. I also remember that wrye bash within MO2 was broken last summer but I think it has since been fixed... Don't know. It doesn't crash at all when used standalone. Still, I'll be reading about the smash testing as I'm curious about it. Now that I'm beginning to get used to CR'ing, SRLE-style :P
-
Not exclusive to MO, Merge Plugins Standalone has the same problem. It seems the game now uses a different way of reading the load order and the plugins.txt file (located at %Appdata/Local/Skyrim Special Edition) now does NOT include Bethesda's plugins. Since MPS (and, apparently, MO) expects those to be present, they somehow inject them into the load order but completely misplace them, messing the whole thing up. The workaround I use is to have a txt file containing *Skyrim.esm*Update.esm*Dawnguard.esm*HearthFires.esm*Dragonborn.esm I open the text file, select all, copy, open plugins.txt (have shortcuts for both files in my start menu), paste at the top of the file, CTRL+S (save), DON'T CLOSE OR SWITCH TO ANOTHER APP that causes plugins.txt to update (such as Wrye Bash), instead open Merge Plugins Standalone (have a shortcut in the start menu right beside the basted .txt files) and everything's normal. I'm sorry I don't remember where I've got this info but I've tried to replicate it exactly as I do, not that much of a hassle if you have your shortcuts at hand. This applies to Merge Plugins Standalone, I have no idea if MO's issue has the same origin since I'm using it only as a FOMOD extractor and as a safety net to run the CK from, but I do confirm the load order is all messed up. Using the "sort" button on top of the right pane seems to fix it, though-

