GUIDE Step Guide-Mod Testing

[frihyland]

Added a link to the wiki in the OP

[stoppingby4now]

I noticed on the 'Mod testing Guide' under the 'Computer stability and settings' tab. Concerning defragmenting it should be noted that Solid State Hard drives don't need and probably should not be defragmented.

Not just probably, they definitely should not be defragmented. As you mention, they don't need it, and doing it significantly increases the write cycles that occur, which is what defines the life span of these drives.

[MadWizard25]

I noticed on the 'Mod testing Guide' under the 'Computer stability and settings' tab. Concerning defragmenting it should be noted that Solid State Hard drives don't need and probably should not be defragmented.

Thanks for that bitdman, added it. Im very happy you noticed this, if you spot anything else that should be included or is wrong, mostly regarding content at the moment, please feel free to post here 

 

Added a link to the wiki in the OP

Thanks as well fri :)

[MadWizard25]

OK. Basic workflow expansion in short.

 

General - Make sure gamebooster, defragging, driver updating, etc is all done (refer back to relevant pages)

 

1. Enable script logging.

2. Switch to vanilla profile using SIS.

3. Inspect mod using WB for structure and conflicts. (thinking about recommending that all BSA archives are unpacked, hence conflicts/ overwrites are easier to spot, dont know if this is a good idea. Its should work fine as extracted, but correct me if im wrong)

3a. When tool such as TES5Edit are released, will probably add those steps here-ish.

4. Install mod using WB or MO and activate.

5. Make sure default medium or high ini for vanilla have been generated (should be part of SIS profile, unless im mistaken, still have not explored the program fully)

6. Start GPU-Z, enable monitors for VRAM, fps, gpu load (any other monitors? Also need to detail logging)

7. Start game, play through introduction until all the way to riverwood until you get the quest to go to whiterun.

 

It for now, let me know if any corrections/ clarifications, switching of certain steps, are needed.

[frihyland]

step 3 should be to assess the zip structure and make sure its gonna install correctly, after installed assess the esp with a utility (bash for now, then soon tesvgecko, or tesvedit or tesvjedit).

 

just need to play through the introduction until you get inside the cave and it collapses, after that load up Lal and test in various start locations, then a few different savefiles.

[MadWizard25]

Ah, yeah, i meant using WB to asses the zip structure. And how does one asses the esp in bash? Something along the lines of running BOSS, seeing if correct bash tags are applied by WB? I was under the impression that WB cant really examine skyrim esps

 

I was thinking that up until the cave would be fine, but then remembered that the path from the guardian stones to riverwood is very crash happy if you have an unstable mod(s), as well as one of the most resource intensive areas I have found so far, hence i think we should recommend either all the way from helgen intro to riverwood; Im not the only one who has had issues with that area. Its especially sensitive to mods that run a lot of scripts constantly, or mods that change/ increase spawns, as well as vram loading.

 

Or we can have it as a LAL run through. Coc riverwood command is perfect for it.

[frihyland]

There are a whole variety of options when you right click on an esp in bash, check them out. Check for udr is the one I use most frequently, the rest may not be fully skyrim compatible yet, need to do some testing of bash there. Anyway the other tools are coming along nicely we'll have something useful soon.

[LeetMiniWheat]

There also appears to be a vanilla CTD bug in the path from the stones to riverwood that Tormentor and I have both discovered, so keep that in mind when stability testing those areas.

 

Edit: something about "DialogueRiverwoodIntroScene" in logs. I don't think we've narrowed it down to exactly what causes it, since it doesn't always happen on every new save.

Edit2: could actually be the lvlpredator script bug too

[torminater]

i personally think that a testing round should always go up to dragonsreach and then checking vram stutter and z-fighting with slower and rapid turns and jerks of the camera for at least 20 seconds. performance drops fairly low. the reason i say dragonsreach is, that my ratio of ctds for general exterior world spaces in skyrim augments to about a billion percent if i close in on the periphery of whiterun. i have never had nowhere as many ctds as right at those couple of in-game acres.

have you thought about including a "disable vsync"-step including triplebuffering etc.? might come in handy for testers with high-end-rigs if they can't notice any performance drop using vsync.

also i would say that a tester should generate a personal set of vanilla with and without highresdlc accumulated data of this testing process, so the effects of the mods can easily be traced.

[MadWizard25]

Nice ideas LMW and torm. I plan to recommend areas that are ctd prone when testing using LAL + coc commands.

 

Well, i think vsync should be on while testing for a few reasons. The first is that most testers and user of the mod will have it on by default. I already recommend default ini files at either medium or high settings. We need to reduce complexity as much as possible for the testing. Im also recommending that even people with end end rigs testong on medium or high, because most step users run a those settings. Additionally, disabling vsync on high end rigs, I have heard it can cause issues if you fps goes over 60 w/o vsync on. Weird physics and timescale issues or something.

 

It is totally possible to have a test scenario for people with high end rigs, but that will only be added after the guide is done i think.

 

Torm, im not sure what you mean by vanilla with hi res dlc, and vanilla without hi res dlc for testing, in regards to tracing the effects of mods?

[torminater]

not the mods, no. it's that the "tester" knows how his system handles higher vram-taxation and what impact the bethesda hires dlc has on his system.

for example, if vram issues are already present with only hires dlc installed, there is no way the tester is going to be able to test a mod with all of the step mods installed at higher quality, which might be a problem if he wants to assess the ingame-effect of a mod that adds tons of new textures (huge castle, lots of people,...) for example. the tester would have to refer the chosen mod to someone who is capable of verifying the compatibility/playability with step.

the bethesda hires dlc isn't the best option for this "stress-test" but it's probably the most convenient one.

if a single mod adds about 500 MB to your vram-usage compared to vanilla, it's definitely not the same, if it would add the same amount to the hires dlc run through. also if you have a monitored run through with hires dlc of the standard testing procedure, you'll be able to more or less "read" when there is a lot more/less stress on your machine f.e. when it's loading new textures.

i may have written it out a bit too much, but it's kinda late here and i'm going off to bed right now. so sry and cya ;)

[LeetMiniWheat]

I see what tormentor is saying, some testers know the limit of their rigs and what it can handle - but a unified testing methodology has it's benefits. Maybe using the Hi-Res DLC Optimized @ 1024 should be default just for testing to eliminate any potential bottlenecks? Though a few levels of tests (medium, high, ultra) would effectively cover all ground.

 

I'm down for testing whenever a finalized mod list and testing methodology is available. (I've skimmed through the wiki somewhat already and been loosely following this thread.)

[bitdman]

Those who use Steam get stuff installed by or almost by default if you know what I mean. And there are too many users like that to determine what sort of user group to put them in. I don't envy you guys. The task you have chosen is a "Long and windy road" but you are heroes to many of us that can appreciate what you are accomplishing.I Salute you!

 

Maybe STEP should just stick to Low, medium,and Highend rigs. Arrange the mod list with those criteria. But have a "select" group of people make the determination of what is considered Low,Medium, or High. Or just Low and High. to be honest anyone playing Skyrim with a low end PC should not use but a very small and undemanding list of mods!!!

 

My$.02

[frihyland]

Maybe STEP should just stick to Low' date=' medium,and Highend rigs. Arrange the mod list with those criteria. But have a "select" group of people make the determination of what is considered Low,Medium, or High.[/quote']

That's already been done in the new STEP guide, which is complete btw and ready for testing as soon as we have procedures and volunteers in place.

[torminater]

Maybe STEP should just stick to Low' date=' medium' date='and Highend rigs. Arrange the mod list with those criteria. But have a "select" group of people make the determination of what is considered Low,Medium, or High.[/quote'']

That's already been done in the new STEP guide, which is complete btw and ready for testing as soon as we have procedures and volunteers in place.

:) sign me up for testing! i'ld love to!