Jump to content

Step Guide-Mod Testing


Recommended Posts

  • Replies 75
  • Created
  • Last Reply

Top Posters In This Topic

Each mod should be checked inside Bash (and later tes5gecko and tes5edit when they are available) for errors in the structure of the esp/esm, up to the limits of the program.

 

Each mod should be run in skyrim in full debug mode and the log posted with the review.

Link to comment
Share on other sites

  • 2 weeks later...
  • 1 month later...

Yeah methodology is important. I have basic idea of the workflow, it being bottom up approach, but my real issue is saves. I dont have a vanilla skyrim, nor do i have a pure STEP setup either. Which are same of the basic save profiles we need. I hope to outsource this to some others though. Or i need to set a weekend aside which is tricky atm.

 

I have been spotty in forum attendance and wiki work because im supposed to complete my masters degree by September, so new administrative and course loads keep popping up, not to mention my half baked thesis i need to complete. And due to that added pressure, ive been de-stressing by socializing IRL, so computer based projects are getting a bit dusty unfortunately. With no holiday its a bit of a mess lol. All i have been able to do lately is some light forum work and testing a mod or two for specific issues.

 

So atm, i have been chipping away at it, i think most of the sections are present, if not filled fully, but the real vacuum is in the strict methodology part. I have no issues with anyone else contributing, so please feel free, and it would speed things up. In fact, id like to discuss some of the specific workflow for in game testing so i can flesh out the sub sections a little more.

 

1. The start --> 1st step in the guide for the in game testing part i think. Unless anyone has another idea of how to start this part?

i) use intro sequence

ii) use LAL

 

Im unsure about the start. Should we recommend that people follow through with the intro sequence? The advantage of this is that if a mod destabilizes skyrim, it may already manifest in the intro sequence. I cant back this up with sources, but im sure i have read quit a few threads about random mods breaking the intro. Its also fps and script intensive, so its easier to observe if a specific mod is the straw that breaks the camels back.

 

The advantage to LAL is evident. It cuts down on repetitive testing fatigue, and is more attractive to mod testers, so it may be easier to convince people to test mods by letting them use LAL.

 

Im not set for either one, in fact a fusion of the two might even be best. We certainly dont want mod testing to only happen once. So if we ask that you start a new game at least 3 times before you are sure the mod is stable, we could recommend both starting scenarios.

 

2. Testing locations.

Had some great ideas in the thread already, but as a rule of thumb what would be a good amount? If we take all the DDSOPT testing locations as well as others mentioned, it would be too much. I dont want a wall of text, which might scare some testers away. We need to agree on a couple.

 

3. Quant. Measurement

VRAM: I like z92 method, so thats already in my notes. 60s run through, with waiting roughly 30s to allow gpu/ cpu to equilibrate.

Scripting: no idea to quant this, not even possible i think? this may just have to be qualitative, coupled with pap log output. Also, 60s will not be enough for this. If its a heavy script based mod i think we may have to recommend just completing the quest, or smithing something, etc etc.

GPU: same as vram with gpu-z

RAM: anyone know a good log system for RAM use?

Link to comment
Share on other sites

Nice to hear your doing well on the school and RL stuff, I've actually been busy rediscovering my love of outdoor summer concerts :) for the past few weeks, so I haven't done any wiki editing for a bit either.

 

On all the points you made I am pretty much in agreement.

 

Use of SIS for multiple Skyrim installs will be a must.

 

Testing the install with Wrye Bash and Mod Organizer will be a must, while we are in bash we can check the mods internals a bit. And add other more extensive testing utilities as they become available.

 

Mods need to be tested first with vanilla skyrim with the full scripted start, than make a savegame, uninstall the mod, load the savegame and check both the logs for script errors.

 

If it passes those initial tests move on to a full STEP Skyrim with a few additional mods like LAL to help aid the phase 2 in depth and compatibility testing process.

 

On locations and measurements we'll need to discuss that stuff a bit but we got a lot to work with already.

Link to comment
Share on other sites

Thanks for mentioning SIS, completely forgot about that. Will def be in the guide. It will get its own section.

 

Ok, good idea regarding the mod utilities. 1st steps in workflow should be loading mod up in MO or WB. Will also get its own section.

 

Sounds good fri, can already start on those parts :)

 

Edit: regarding the wiki. I have several sections, but i dont have the option to edit a particular section. I have seen this on the other wiki pages, but atm, i have to edit the entire mass of text. Anybody know what i did wrong, or how to implement this?

Link to comment
Share on other sites

I have been thinking about starting a new STEP installation just for the fun of it, and my installation now has all kinds of other non STEP stuff and out of control experimentation going on. So it's time to get back to the basic STEP. Are there any suggestions or instructions you would like me to keep an eye on during my install? And should I use The 1.6.89.0 version?

 

I'm not sure if this is important or not. But I would like to try using Wrye bash 299 exclusively as I'm not sure if different installers might cause some mods to install differently.?

Link to comment
Share on other sites

Ill handle acronyms in a simple way. If a term has an acronym, i will first spell it out in full, and then in parentheses right after will add the acronym. From there on, the acronym will be used.

 

For example;

 

Run Wrye Bash (WB). Click on the Installer tab in WB...

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.