z929669

Given the penchant of many in this group for testing performance, I am inclined to ask you all to be Mod Testers. We need good testers to vet mods in the context of full STEP. Salvador makes some good points, so I would like to see some data to support or refute if anyone is willing ...

Correct' date=' unless "override skipped files" is ticked (which is not necessary, and we don't want to use the vanilla resources anyway ... just the repackaged loose files).[hr']

"Don't process ..." tells DDSopt to leave the data alone and simply copy or extract it. You would use this only when extracting BSA. Be sure that it is UNticked whenever you want to optimize textures.I guessed that was it's purpose, I'm asking at what point in the process should it be unticked to do the optimizing?Is it at point 5. in Optimizing the textures? I had this this option ticked the whole time and I was worried it might be doing nothing consequently but the produced and repacked Dawnguard BSA did come out significantly smaller... Sorry if I'm being thick... Extracting Textures 5. Click [ignore] from the main menu and tick [Don't process any of the know file types]. This will tell DDSopt to extract the contents of the BSA without performing any optimizations. ... Optimize the Textures 6. Tick [ignore] > [Dont't process any of the known file types] and be sure to click the green check mark on the browsers tab. Click [Process]to essentially move all of the filtered files eliminated in step 4 into the new directory structure without processing any of the already-optimized files. The section of the guide to which you refer is simply illustrating how DDSopt can be used as a BSA extractor, so the "Don't process ..." option should remain ticked during all iterations of these operations under "Extractin Textures". You can also combine this procedure with the following optimization procedures. We are illustrating each action separately, since there are just too many "correct" (and incorrect) ways to get the job done.

"Don't process ..." tells DDSopt to leave the data alone and simply copy or extract it. You would use this only when extracting BSA. Be sure that it is UNticked whenever you want to optimize textures. Install theseabove these

Good point, roots. We had planned on this happening during the "bandwidth blackout", but it unfortunately took longer than it should have. We should have definitely taken down the site from the old host to prevent this. However, we only lost a handful of posts, and there may be a way to get them back.

I misquoted Neovalen in my previous post ... it was you, JJ, that supported my experience of 1.8-ish GB of system RAM use allocated to TESV.exe You are missing the sensor (or GPU-z does not talk to it). I think it works better for AMD cards, but I'm not positive on that. You should only be bleeding off some relatively stable VRAM to RAM. I would guess something like 5-10% is all ... until you begin to hit your VRAM ceiling, at which point, you begin seeing more VRAM spill over. If you cannot see your dynamic VRAM (VRAM to RAM) spillover, then you cannot know that textures and resolution are costing the TESV.exe process any RAM .... unless my reasoning is flawed (I am no hardware/software expert). I'm not sure which of Neovalen's comments you are referring to. Also I'm not sure why it would be strange for this single process to use a lot of ram. I would be very happy if this is not a ram issue. z --> Fixed Yes? I'm not sure where you are coming from. I tracked the RAM (not VRAM) usage using Process Explorer (which you are familiar with); it was tracking only TESV.exe. VRAM, which was system wide, was tracked using GPUz. z --> But you can also look at GPU dedicated VRAM and dynamic VRAM (System RAM) in Process Explorer too. You have to set this ip under [View] I think. I haven't had a chance to read through your benchmark, but I will. I am more than happy to do any tests you are interested in, because I would much rather find a setup issue than reduce mod count. Unfortunately I won't have a chance until this weekend to do any real tests (meaning redoing step from scratch). I'd like to point out that my numbers, and all of my experiences with ctds, were all using attklt. z --> Bummer. I thought that this would help. Maybe try with it off or using the full version? As for whether the "bleed over", as you called it, goes into the same address space, it would seem that it does; however we have no real "proof" beyond some anecdotal evidence and the microsoft directx patch details linked to earlier in this thread. But this will be the very biggest chunk. The rest of STEP should not cost enough to get you past 1.8ish, right? Have you read through this?--> https://wiki.step-project.com/User:Z929669/Benchmarks Also, it is entirely possible I suppose that my and many others' VRAM is the majority of the "Private Bytes" (if I understand correctly),; however, us regular folks (... who might wear tennis shoes or an occasional python boot ...) are trying to keep our VRAM usage below 1 GB, so the 1.8 I see at max is very likely 1 part VRAM and 0.8 parts RAM all loaded onto TESV.exe I suppose .. duh :O_o: Anyway, read the benchmark page I created and take a careful look at the charts. This is all about how VRAM and RAM play together, and it is an interesting little dance. However, sorry for leading the thread astray, as I see now that this is probably a process-RAM problem that I don't have the VRAM to experience :P

Perfect ;)

@SSL Thanks for picking this up ... nice catch ;)

Your bash.ini looks good. Do you have UAC enabled? Can you post a screen of your Mopy directory (with path info) and another of your WB installers tab?

Have you modified your bash.ini in any way (e.g., according to the Wry Bash Guide)? Sometimes, you need to select another tab and go back to Installers to trigger a refresh. Also, click on the "Order" column header to order by this field. then the installers should be at the bottom of the list.

Thanks Kelmych! This is reassuring and not a problem right now, as HO will not be in Core STEP.

Looks like we need to update the pointer for this thread and the guide once you guys give the go ahead that the changes are realistic and that all is working as expected. (thanks kryptopyr )

We need to make a note that [behave] > [Raise foliage-map opacity each mip level] is UNticked for SFO and possibly any foliage other than vanilla (not tested). I believe that this is what causes the "painted look" that techangel was describing somewhere in these forums. In fact, there may be a lot of variation in the applicability of the added special features that Ethatron built into DDSopt. All we can say is that those settings apply to vanilla and thus may be a good starting point for everything ... then later note these exceptions. SRO is an example of a texture mod that is properly mipped already, and treating mips further just blurs the details.

That's certainly not my experience. The proof is in the pudding if you look at the benchmarks I point to up there. Would anybody getting these huge spikes mind replicating a couple of these benchmarks on their systems? I'd like to see the diffs of Vanilla versus bench after section G versus bench after section M using the intro sequence. This will be more solid evidence of the dynamics between VRAM and RAM on your systems. Others have similar benchmarks on their user pages (see Kelmych and techangel85), and I have not seen anything that is inconsistent with my own... yet.

Reading through this thread, I am not convinced that this is a RAM issue at all (and I echo Neovalen's JudgmentJay's comment about system RAM allotted to TEXV.exe being higher than 1.8 GB). Something strange is happening if people are getting system RAM usage that high from this single process. Are we certain about these RAM allocations being specifically tied to TESV.exe? Skyrim does not allocate much VRAM to RAM until it runs out of VRAM. Even then, it is not so much that it could additively boost my Skyrim RAM use to more than 3 GB. My benchmarks are pretty detailed in this regard. Furthermore, is it a fact that this "bleed over" VRAM is in fact charged against the TESV.exe-allocated RAM usage? Sounds like ATTK could help out here (not), regardless, but I would also not rule out a setup issue at this point. I have had 300+ mods installed in Morrwind, Oblivion and Skyrim, and I have never had CTDs related to RAM caps ... they were always related to setup issues. (also, try using Process Hacker. It is even better than Process Explorer)

@WilliamImm You are correct about the install order ... by bad. So this should not be an issue for STEP users if they follow the guide. However, the installer IS buggy since there are several mods that are co-dependent with Closer Quivers, and many users will not have those co-dependencies installed beforehand. Autodetection and autoselection based on DLC is one thing, but based on other community-provided mods is quite another. What if all installer scripts used these methods with co-dependent mods that won't always exist in the Data directory? The wizard is partially broken in its current form, and it wouldn't be hard to change it to include those options. Just sayin'.

If you want to suggest any mods for SR, please do so in the Mods forum. The Mods forum is our central repository of mod suggestions for STEP and other guides. This enables all of our members and guide creators a "one-stop-shop" for referencing or commenting on mods. HINT: Use the tagging system, and tag mods you like for SR as 'Skyrim Revisited'. Neo and others can then do an Advanced Search using that tag. We even have built-in "Prefix Tags" to distinguish mods suggested for a particular game: [sKYRIM] [OBLIVION] [FALLOUT 3] [FALLOUT NV] [MORROWIND] etc. Tags and prefixes can be chosen or added during thread creation ... or they can be added by the thread creator by using "the full editor". This may seem like a PITA to some of you, but having a centralized 'repository' of all mod discussions pertaining to whatever guide(s) reduces clutter and consolidates information in as logical a fashion as possible in the forum format.

The mod is technically still in beta it seems, but that is not a problem. For inclusion into STEP, we'll need some definitive testing done. If someone proficient in the CK/TESVEdit can look at potential conflicts, taht would be a great start for testing. Else, testing will largely consist of a lot of play with all DLCs, changing worldspaces and examination of save games and papyrus logs. IOW, this mod will require more sophisticated testing than most others. ...it looks good though (I like dynamic, scripted mods a lot if they are done well).

Any news on this one? SFO created a patch, so it must be getting some attention .. ?

Hmm, I defer to the hardware experts that lurk these forums; however, it is plausible that the issue is not really memory usage at all. This could be a side effect of the problem. More likely, it is a setup issue. Are you checking memory usage of TESV.exe using Process Explorer?

@WI, do you mind fixing to allow all options or ask qualifying questions during install like: Do you plan to install xxxx?

Still need another person to verify the behavior of the installer with DLC present and without EBV. This will be a common occurrence among STEP users installing STEP for the first time or reinstalling.

OK, I see what it is doing now. It appears as though the wizard is configured to assume that all of the prerequisites will be installed first. I see now that my Dawnguard options are indeed selected, although I was never presented any choices on those options: Note "Dawnguard official DLC detected. Installing compatible versions of the Dawnguard arrows. If you do not want these, deselect the Dawnguard Arrows subpackage before you install." Else Note "Dawnguard official DLC NOT detected. Not installing Dawnguard arrows or Closer Bolts. You can still install the closer Dawnguard Arrows or any of the Closer Bolt files by selecting the appropriate subpackage, but they will have no effect unless you have the DLC installed and enabled."In the install order for STEP, Explosive bolts should be installed after Closer Quivers, so that is going to be a problem for novice users I would think. Can someone else on their way through the serial STEP installation process verify? Also would like verification that the aforementioned notes aren't being triggered in the logic. Just to be certain that I am not missing something.