STEP:Mod Testing: Difference between revisions

From Step Mods | Change The Game
 
(492 intermediate revisions by 7 users not shown)
Line 1: Line 1:
[[Category:Guides]]
[[Category:Step Guides]]{{PageTitle|logo=delta|title=Step Guide-Mod Testing|subtitle=An in-depth manual to mod testing for Step Modifications|author=The Step Team|forumtid=271}}
{{Warning|This page is under construction!}}
{{TOC}}
{{Notice|This is a WIP, and editors are encouraged to verify content and contribute additional content.}}
To ensure consistent and reliable mod testing, it's essential to minimize variations that can lead to a range of issues and inconsistencies. This guide will outline standardized techniques for mod testing that Step Modifications employs for evaluating all mods featured in our official modding guides. The recommendations provided progress through system and software setup before delving into the mod testing process.
''Mod Testing for S.T.E.P. -- by the S.T.E.P. Team and Wiki Editors''
:Updated: {{ #time: G:i:s j F Y "(UTC)" | {{REVISIONTIMESTAMP}} }}
[http://forum.step-project.com/showthread.php?tid=321 '''GUIDE FORUM THREAD''']


'''
== Understanding Mod Testing ==
= Introduction =
Mod testing encompasses various aspects. However, in the context of this guide, it refers to the assessment of mods for potential inclusion in a curated mod list. This evaluation involves several key components:
'''
# '''Stability Testing:''' assesses a mod's stability when integrated with other mods in the mod list. It aims to identify any conflicts or issues that may arise from mod interactions.
# '''Functionality Testing:''' mod functionality is scrutinized to ensure it operates as intended. Any deviations from the mod's intended purpose are noted and addressed.
# '''Mod Comparison:''' mods with similar content are compared to determine which one provides the best solution.
# '''Lore and Mandate Assessments:''' mods are evaluated against Elder Scrolls lore to ensure they align with the established lore and adhere to the Step Mandates. This ensures that the mod fits seamlessly into the Elder Scrolls universe.


==General Information==
It's important to acknowledge that mod testing can be a time-consuming and meticulous task. Nevertheless, it can also be rewarding and enjoyable. Mod testing is ideally suited for individuals who are genuinely dedicated to the process. Consequently, turnover rates among users involved in official testing are high, as many underestimate the demands of mod testing; quickly become overwhelmed by the complexity of the task.
This guide will attempt to lay out good practices for testing mods to recommend for S.T.E.P. as well as for testing mods should this be asked for or required by TC and S.T.E.P. team. With a guide as complex as S.T.E.P., it is beneficial to reduce as much variation as possible, since complexity can breed a host of issues. This guide will try to recommend standardized testing techniques. The approach will be bottom-up, meaning recommendations will begin at the hardware level, progressing to software and then to mods.


=== Outline ===
Following is described the detailed process required for testing mods in a manner that ensures consistency and facilitates recommendations (or not) for a Step Game Guide. Our aim is to maintain a process that is straightforward and efficient, yet given the complexity and extensive nature of some mods, this process may not encompass every conceivable mod testing scenario. While common scenarios are provided, it's crucial for testers to exercise best judgment when faced with situations not explicitly covered.


* Read the Description page and make pertinent notes.
== System Preparation ==
* Read the Bethesda, Nexus, and Steam forums to develop a sense of user satisfaction and a list of possible bugs to attempt to confirm or deny.
Before embarking on mod testing, it is essential to establish a stable system and game installation. Without them, distinguishing whether a mod is incompatible with the mod list or the system becomes significantly more challenging. Testers should have their systems configured according to one of the Step Game Guides. Nevertheless, here are some general reminders and best practices to ensure the environment is adequately prepared for mod testing.
* Examine the documentation of the mod, note any lack of clarity, installation and uninstallation directions, and general completeness.
* Validate the archive package, naming scheme, directory structure, and installation procedure.
* Use TES5edit to determine quality of edits in any plugin files and the scope of mod.
* DDSopt used to determine quality of texture compression.
* Examine files in game  (to accomplish this we need to research a quick and easy way of identifying the actual name of the (texture, mesh, etc) file corresponding to what we see in game.
* Examine script source of mods for reliability and compatibility (if not available ask the author).
* All mods with scripts must include methods for installing and uninstalling in game or at the very least stopping scripts with a console command.
* Review Papyrus logs for script issues.
* Each mod is examined in multiple ways in game to confirm functionality and compatibility.
** Test in various key spots of the world using savegames.
** Test in various key points of quest development using savegames.
** Test as a solo mod and with a full current STEP installation.
** Test with a new game and with adding it to an existing game with full STEP.
** Note qualitative changes to the game Appearance, Gameplay, etc.
** Note quantitative changes like VRAM, GPU, CPU, RAM, and FPS usage.
* Complete the Mod Testing wiki form and submit.
* Contact mod authors with hard evidence and constructive criticism to improve any area's in need of improvement before becoming a STEP recommend.


=== General Setup ===
* Ensure the [[Guide:System_Setup_Guide|System Setup Guide]] is complete
* Ensure a clean and ''pure'' installation of the Step Game Guide for which testing is being performed
*: {{fc|instruction|A ''pure'' installation means nothing exists within the mod list that isn't included in the Game Guide; the installation should be 100% within the bounds of the Guide.}}


= Quick Start Guide =
=== Game Settings ===
=== Quick Start Guide ===
All game INIs, launcher, and in-game settings should be configured according to the Game Guide for which testing is being performed. Therefore, any post-installation changes should be reverted back to the Guide's instructions for the duration of testing.
: ''Reference the [[Guide:Skyrim Installation|Skyrim Installation Guide]] as needed ... this is required reading for all mod testers''. Peruse (or post questions to) the [http://forum.step-project.com/forumdisplay.php?fid=54 mod testing forum] ... guessing is not standard procedure.
<ol><li> Ensure a clean install of Steam and Skyrim (non-windows directory) </li>
<li> Use [http://www.creationkit.com/TES5Edit_Mod_Cleaning_Tutorial TES5Edit to clean any relevant DLC content] present </li>
* Optional: use [http://forum.step-project.com/showthread.php?tid=228&pid=2517#pid2517 DDSopt to fix the vanilla textures]
<li> Install ''and properly configure'' utilities and extenders </li>
* [http://skyrim.nexusmods.com/mods/12744 Skyrim Unplugged] (activate!)
* [http://skse.silverlock.org/ SKSE]
* [http://skyrim.nexusmods.com/mods/6 BOSS]
* [http://skyrim.nexusmods.com/mods/1840 Wrye Bash] and/or [http://skyrim.nexusmods.com/mods/1334 Mod Organizer]
* [http://skyrim.nexusmods.com/mods/25859 TES5Edit]
* DDSopt ([https://github.com/downloads/Ethatron/ddsopt/DDSopt_v080pre5b-SSE3.zip v80pre5b-SSE3])
* [http://skyrim.nexusmods.com/mods/19034 SIS] (Skyrim Installation Swapper)
<li> Start a new game and save at first opportunity after character creation. </li>
<li> Within SIS, name current #1 profile to "Single Mod Test" </li>
<li> Copy/save profile to #10 slot, naming as "Vanilla" using SIS </li>
<li> Copy/save profile to #2 slot, naming as "STEP Mod Test", then select as "Active Profile" using SIS </li>
<li> Install Core STEP mods expected in next release (list provided by admin in [http://forum.step-project.com/forumdisplay.php?fid=54 mod testing forum]) </li>
<li> Become familiar with the mod to be tested: </li>
* Read the mod-site description
* Carfully review any available documentation (i.e., within mod package and relevant mod forums)
<li> In SIS, activate the Single Mod Test profile and install the mod to be tested using WB or MO. Provide feedback by completing the ModTest Form on the wiki (in development) </li>
<li> In SIS, activate the STEP Mod Test profile and install the mod to be tested using WB or MO. Provide feedback by completing the ModTest Form on the wiki (in development) </li></ol>


= Computer Stability & Settings =
=== Mod Organizer Profile Setup ===
'''
Step Modifications' officially supported mod manager is Mod Organizer, and it proves itself more helpful than other managers for mod testing. Follow these instructions to set up two new profiles in Mod Organizer for testing:
# Open Mod Organizer and select the instance for the game for which testing is being performed
# Select the {{icon|moprofile|30}} icon
# Copy the Step Game Guide profile
# Name the new profile: <code>Vanilla</code>
#* Make sure the '''Local Savegames box''' is not checked for the testing profiles
#* Make sure the '''Automatic Archive Invalidation box''' is selected for the testing profiles
# Name the new profile: <code>GuideName vX.X Testing</code>
#* Make sure the '''Local Savegames box''' is not checked for the testing profiles
#* Make sure the '''Automatic Archive Invalidation box''' is selected for the testing profiles
# Select the newly created '''Vanilla''' profile and ensure no mods are enabled


==General Information==
=== Vanilla Save ===
A stable computer is crucial to testing a new mod. Without a stable computer, it will much harder to determine if the mod itself is incompatible or buggy with other mods or Skyrim, or if the mod is incompatible with your computer. Here are some tips to increase stability.
Though playing through vanilla content may be at the top of anyone's list, this step is ''not optional''. A vanilla save point is required for some comparisons, as well as, providing a default environment from which to start the majority of testing.
# Select the '''Vanilla''' profile
# Start a new game from this Vanilla profile
# Play through any introductory quests until the first point is reached that allows for free roaming of the game
# Once at a free roaming point, save the game
#* '''Fallouts:''' play until at the starting vault's exterior
#* '''Skyrim:''' play until at the exterior of Helgen cave
#* '''Starfield:''' play until the Frontier can be freely piloted and save at NA Spaceport
#:: {{fc|yellow|'''''Tip:''' Use the console to create a save with a custom name for quick reference.''}} (<code>save SaveName</code>)
<br>


==Specifics==
== External Testing Procedures ==
All testing begins outside the game. Each of the following steps should be completed and notes taken from each before proceeding to in-game testing.


'''Device Driver Updates'''
=== Step 1 - Forum Mod Topic ===
'''Read the mod's topic opening post (OP)'''
: The mod's topic OP often contains an outline of what needs to be tested for a particular mod. Make note of this and use it when in-game testing begins. If nothing is outlined in the OP, it's likely the mod has not been tested or reviewed enough to include it. In such cases, testers will establish a outline by editing the OP. This outline should include what mod options should be tested, how to test, steps for making the mod compatible with other mods, etc. Most of this information will be gathered from the actual testing process below.


A driver is a computer program that allows other computer programs to interact with hardware (device). Most drivers are update relatively frequently, especially drivers for graphic devices such as AMD's or Nvidia's graphic cards. Driver updates fix bugs and offer performance improvements. As such, it is quite important to have an up to date set of drivers for all your computer's hardware devices.
=== Step 2 - Nexus Page ===
'''Read the Nexus Page in its entirety'''
* '''Description:''' make note of any special installation/uninstall instructions, any known internal or mod compatibility issues, and of any potential conflicts with supported DLCs and other mods within the Step Game Guide.
* '''Posts:''' a complete read is not necessary; however, testers should attempt to develop a sense of user satisfaction. Posts can also reveal a list of possible bugs not listed within the Bugs section. Unless a mod is fully developed with few to no bugs being reported, some sort of interaction from the mod author is preferred to ensure the mod isn't abandoned.
* '''Changelog:''' changelogs often provide a sense of what direction the mod it headed, how often issues are addressed, features being edited, etc.
* '''Bugs:''' review any active bug reports. Too many bugs may disqualify a mod from being included within a Step Game Guide.


If your computer is pre-built, for example, you bought an off the shelf computer under a brand (vendor) name such as HP or ACER, a program(s) is usually included that assists in vendor specific driver updates. If this is the case it is important to use this program(s), as many brand name off the shelf computers have drivers specifically designed for their hardware devices, rather than generic drivers. Consult the manual or the website for information on how to do this on your computer.
=== Step 3 - Validation ===
'''Validate the archive package using MO or 7zip'''
: Observe if the downloaded archive is properly structured and configured for installation or not. For more complex installations, Mod Organizer FOMODs are preferred; however, MO can install BAIN type installations as well. FOMODs can be validated using an online validation tool, [https://www.w3schools.com/xml/xml_validator.asp XML Validator], or by using [https://www.nexusmods.com/skyrim/mods/75140 FOMOD Validator]. When installing mods using Mod Organizer, the bottom pane will also have a report of potential issues with the package.


If your computer is custom made <s>then you probably dont need to read this</s>, then there are several excellent programs to assist with this. A great tool is [http://www.driver-soft.com/ Driver Genius], which will download up to date list of drivers for almost all hardware devices, scan your computer with that list, and specify which need to be updated. The freeware version will do all of this. If you upgrade to the paid version, then the program will also download and install the drivers for you.
=== Step 4 - xEdit ===
'''Inspect plugins using xEdit'''
: Knowledge of xEdit and conflict resolution is required for this step. Load the entire Step Game Guide and the mod being tested with xEdit. Review and note any issues of the mod failing to carry forward changes from DLCs, mods, and patches included within the Step Game Guide. These notes help with creating correct conflict resolution via official patches.


'''Overclocking'''
=== Step 5 - Installation/Uninstall ===
* Validate installation procedure listed on the Nexus page.
* Validate uninstallation procedure listed on the Nexus page.


If you are currently overclocking your computer it is recommended setting everything to its default stock settings. This goes for the CPU, GPU, and RAM. Although the chances are low, it is possible for a new mod that is resource intensive to instigate stability issues, even if you previous overclock settings were stable. CPU and RAM overclocks can be managed from your motherboard's [http://www.pcstats.com/articleview.cfm?articleid=1804&page=6 BIOS], and GPU overclocks are managed by a variety of programs. A recommended program for GPU overclock management is [http://event.msi.com/vga/afterburner/index.htm MSI Afterburner].
=== Step 6 - Inspection ===
'''Inspect the installation in MO'''
# Install the mod as it will be used for testing
# Run LOOT and note information
#: Unless the mod is new on the scene, LOOT will recognize it and provide some valuable information such as if the mod is clean or dirty, requires other mods, etc.
# Using Mod Organizer, take note of any asset conflicts that appear against vanilla files and other mods in the Step Game Guide.
#: Extract any BSAs to ensure the conflicts are being read. {{fc|instruction|BSAs should not remain extracted unless required for further testing. Otherwise, remove the extracted BSA contents before continuing any testing.}}


'''Ghosts in the Machine'''
=== Step 7 - Mandate ===
The final step is to evaluate the mod against the [[STEP:Mandate|Step Modifications Mandate]]. Ensure the mod does not fall into the "...not about" sections. If it does, no more testing is required. Post findings why the mod doesn't fit the Mandate to the mod's topic. If the mod succeeds in passes this step, continue on to the remainder of testing the mod.


Over time a computer will generate many redundant files that at the minimum will do nothing harmful, and at worst will cause stability issues. These files can include temporary files or redundant registry keys. It is recommended to use a program such as [http://www.piriform.com/CCLEANER CCleaner] to clear these files, as well as to fix registry issues.


To ensure proper registry key cleaning, it is recommended to restart your computer after program installation and uninstallation, and any computer driver related changes. It is important to restart your computer because Windows will do some registry cleaning of its own when the computer restarts. Once you have logged in, you can safely clean the registry as well as remove redundant files.
: ''{{fs|larger|{{fc|instruction|Testers should update the mod's topic OP on the forums with any relevant information gathered from the above testing.}}}}''
<br/>


'''Disk Fragmentation'''
== In-Game Testing Procedures ==
This process is the most important and will detail steps required for testing mods in a consistent way so they may be recommended (or not) for a Step Game Guide. It will be as simple and streamlined as possible, however, with the complexity, breadth, and depth that mods can be, this process will never be able to cover all mod testing scenarios. Below we provide the most common of scenarios, however, when the scenario isn't covered best-judgment must be used.


On hard disk drive (HDD), over time files that are regularly used by the computer will fragment, increasing read times and potentially causing stability issues. It is good practice to make sure the computers drives are defragmented before testing a mod. It is a good idea to defrag your computer after installing a new mod, especially with large mods such as texture overhauls. A recommended program is [http://www.piriform.com/defraggler Defraggler], which allows full drive defragmenting or specific file and folder defragmenting.
{{AlertSmall|type=notice|text=The process for capturing comparison screenshots can be found following these procedures; which are for gameplay testing.}}<br>


If you use a solid state drive (SSD), please disregard the defragmentation advice detailed above. Defragmenting a SSD will have adverse affects and may damage the drive.
=== Pretesting Setup ===
'''Enable the testing profile'''<br>
Testing for Step Game Guides should be completed from the profile set up, above, for that Guide in Mod Organizer: <code>GuideName vX.X Testing</code>.


'''Background Processes'''
=== Step 1 - The Vanilla Experience ===
It's important to be familiar with the original content whether it be textures, quests, game mechanics, etc. Therefore, if there is no familiarity with the changes being tested, the original content should be experienced first. If familiarity does exist this step may be skipped. To complete this step:
# Load the ''Vanilla'' profile in MO, launch the game, and load the ''Vanilla'' save
# Fast travel to or use the command console to load the area closest to the mod's altered content
#: '''''Tip:''' before starting the content, make a new save that can be used later for faster testing''
# Play the game for a period of time to experience or view the vanilla content
# Close the game and review findings for the next step


Background processes will take up resources, also potentially introducing stability issues when playing or testing Skyrim. A great program for eliminating as many of these background processes as possible is [http://www.iobit.com/gamebooster.html Game Booster]. This will close redundant programs as well as services, and is optimized towards games. Another program that is useful is [http://bitsum.com/prolasso.php Process Lasso], which acts as a much expanded task manager. This will allow you to set Skyrim's CPU and I/O priority to high.
=== Step 2 - Experience the Mod ===
# Relaunch Mod Organizer and select the ''Testing'' profile
# Activate the mod being tested
# Relaunch the game and load the ''Vanilla'' save or a save created for testing from Step 1
# Allow the mods to initialize
# Play the game for a period of time; assessing the mod:
#* Does it work as intended?
#* Does it look as intended?
#* Does it fit in with the game's content/ambiance/environment?
#* Are there any issues?
# Close the game and review the findings


'''TESV.exe Properties'''
=== Final Step - Review ===
# Gather the findings from all testing sources including the External testing.
# Summarize a review and post this on the mod's topic on the Step Forums. Content to include are, but not limited to:
#* Issues with file structure and installation
#* Conflicts with vanilla or guide content (and solutions, if any)
#* Whether the mod met or fell below expectations
#* Any in-game issues
#* Personal assessment of whether the mod should or shouldn't be included in a Step Game Guide


These settings will ensure that when Skyrim runs, Windows Aero Theme will be disabled, freeing up VRAM, since Aero may use between [http://en.wikipedia.org/wiki/Windows_Aero 64 to 128MB] of VRAM. To access these settings navigate to your skyrim folder, right click on TESV.exe, and then click on the Compatibility tab. Tick the Disable Visual Themes and Disable Desktop Composition boxes, as shown in the image below.
{{alert|type=notice|text='''Be mindful to remain objective.''' Do not write anything that will reflect upon the mod's author in a personal manner. Only review the craftsmanship, reliability, operation, etc of a mod, itself. Mods are assessed for guide inclusion, ''not'' for judgment against authors!}}
<br/>


[[File:Recommended Settings.png|250px|thumb:'''Figure 1.''' TESV.exe Properties Settings]]
== Capturing Comparison Sets ==
When testing mesh and/or texture based mods, comparison screenshots are required and are to be posted for the community to review. These shots are not for the staff to use for evaluation, since in-game testing should be completed, but rather they are for the community's benefit and staff reference.


= Skyrim Stability & Settings =
Screenshots and videos are provided them from in-game sources. {{fc|instruction|Do not use "studio" or "editor" applications!}} In-game lighting conditions and rendering can change the appearance of many game assets; therefore, it's important to capture these comparisons from within the game, itself. Any capture software may be used as long as the saved image is a 1:1 match in color and quality to the in-game image. Some recommendations can be found within the [[#External_Tools|External Tools]] header below.


==General Information==
{{Alert|type=Warning|text='''Do not''' use PNG as the file format when posting compares on the forums. They tend to be large files, which in turn cause long loading times on pages. JPG/JPEG should be sufficient and is about one quarter the payload of PNGs. Only use PNG when transparency is required.}}
This section will describe best practices to ensure a stable Skyrim platform to work from. It will also detail various tips for debugging, error tracking, etc.


==Specifics==
=== Capture Procedure ===
Comparison shots and videos need to include:
# Vanilla reference
# current Guide reference
# mod reference
This process will allow captures to be of the exact same reference point, in each capture, with the only difference being asset replacements.
# Active a HUD mod that auto-hides the HUD for all MO profiles, including Vanilla (i.e, for Skyrim active Immersive HUD). This will auto-hide the HUD so that it doesn't have to be done manually from the console. If the Game Guide doesn't include one of these mods, the HUD will have to be manually hidden or remain present in the captures.
# Load the '''Vanilla''' profile and '''Vanilla''' save file
#: ''The mod being tested should '''only''' be active in the Testing profile.''
# While in-game, locate the vanilla reference(s) that need to be captured.
# Once the reference is found, line the capture up in the frame
#* ''Pay attention to lighting and angles to make sure the capture will be good for compares.''
#* ''Ensure nothing will interfere in the shot such as an NPC walking into the frame.''
# Once the capture is lined up, create a new save
# Now load the save that was just created
#: {{fc|warning|'''''Do NOT touch the mouse!''' Doing so may cause the capture to because misaligned.''}}
# Once loaded, ensure there is no temporary text on the screen and the HUD has been hidden
#: ''Manually hide the HUD (see [[#Helpful_Console_Commands|commands below]]) or simply leave it in the capture when no mod exists for auto-hide.''
# Take the capture using the hot key for the capture software being used
# Exit the game
# Switch to the '''Game Guide''' profile
# Repeat steps 6-9 above for the Guide captures
# Switch to the '''Testing''' profile
# Active the mod being tested and ensure its conflict resolution is as desired
# Repeat steps 6-9 above for the mod captures


'''Launcher Settings'''
=== Posting Captures ===
Post the comparison capture(s) on the Step Forums. Repeat this process for all assets that require a comparison set for any given mod. When only one asset is being tested, it is encouraged to provide several captures from various angles/locations/lighting situations for a more complete review.


Choose Medium or High settings in the Launcher. Then select a screen resolution. If you can, try to select 1920x1080, as this may be the most [http://store.steampowered.com/hwsurvey?platform=pc common], at 25%, screen resolution at the moment. However, if you are unable to do so, do not worry. Full HD (1920x1080) users are by no means a large majority. Other common screen resolutions to test at are 1680x1050, 1366x768, and 1280x1024. AA should be set to 4x, and AF to 8x. All view distances can be maxed out. Distant object detail should be high or medium, FXAA disabled (unchecked), and all water reflection options should be disabled (unchecked).
When posting captures on the Step Forums:
* Please use the Editor buttons/functions on the forums to post.
* Use a 3rd party service to host captures. '''{{fc|warning|Do not store your captures on the Step Wiki!}}'''
** [https://imgur.com/ Imgur] and [https://postimg.org/ Postimage] have proven to be an excellent, free image hosting sites for uploading screen captures to.
** Use [https://youtube.com/| YouTube] for hosting video captures.
**: ''Other services have proven themselves annoying for community members to use; most requiring an account to view the videos.''
<br/>


'''INI Settings'''
{{Alert|type=notice|text=The remainder of the guide contains helpful console commands, tips, tools, and more.}}
<br/>


It is recommended to test a mod on medium or high settings, and once verified, test on ultra if possible. Testing on ultra may skew the results of the testing, especially if others may want to use the mod. The majority of Skyrim users will not have high end computer setups which are able to run on ultra settings.
== Helpful Console Commands ==
Provided is a list of helpful console commands to use while testing. ''They are specific to Bethesda games.''<br>
To open the in-game console press the <kbd>~</kbd> (tilde) key, which is normally located just below the <kbd>Esc</kbd> (escape/exit) key on a standard keyboard. Press it again to close the console.


The easiest way to achieve this is to use Wrye Bash's INI Edits function. Make sure you generate a default Skyrim.ini and SkyrimPrefs.ini. This can be done by deleting your current ini's (remember to back them up first) in your Documents folder. Once deleted, generate new inis by changing your settings to either medium or high in the Skyrim Launcher, as mentioned above. Once these default inis have been generated, back them up. Navigate to the INI Tweaks folder in Skyrim's Data folder. This folder will only be present if you have installed Wrye Bash. Create two new text files and name one Default Medium (or High) Mod Test Skyrim.ini, and the other Default Medium (or High) Mod Test SkyrimPrefs.ini. Make sure that you two text files change from .txt to .ini. Once these have been created, copy the contents of the newly generated ini's into their respective ini files you just created. The same should be done for you normal setting that you play Skyrim with, but name the resulting ini's differently, such as My Skyrim.ini, or My SkyrimPref.ini
===Toggles===
* '''tmm 1'''
*: Toggles all map markers on; thus allowing fast travel to any location. Enter '''0''' in place of '''1''', to reset to default.  
* '''tgm'''
*: Toggles God Mode on/off. While in God Mode the PC will be invincible with unlimited health, magicka, and stamina.
* '''tcl'''
*:Toggles collisions on/off; thus allowing the PC to walk through anything.
* '''tfc'''
*:Toggles Free Camera Mode on/off. '''tfc 1''' will pause the camera.
* '''tm'''
*: Toggles menus on/off. Useful when taking captures.
* '''tai'''
*: Toggles all NPC AI on/off. NPC will typically not move when toggled off.
* '''tcai'''
*: Toggles all NPC Combat AI on/off. NPCs will interact normally, but will not actively attack the player.


This will allow you to easily switch between mod testing ini's and your normal ini settings. To apply the ini settings, right click on the ini file in Wrye Bash and chose apply. Be warned that if you would like to remove the applied ini settings, you cannot do so from Wrye Bash. For example, if you apply your normal ini settings to your mod testing ini setting, you will overwrite many ini settings. However, if you mod testing ini settings contain entries that do not exist in your normal inis, then these entries will remain. Only enteries that exist in both will be overwritten. It is easier just to copy your settings from your normal ini files, delete the text inside your Skyrim.ini and SkyrimPrefs.ini, and paste the copied text inside if you wish to revert back to your personal settings. This can also be done from your backups.
===Player Commands===
* '''player.additem formID ###'''
*: Adds the item to the player's inventory.
*: Replace '''formID''' with the baseID of the item. These IDs can be found [https://www.skyrimsearch.com/items.php here]. Replace the '''###''' with the number of items to add.
*: For example, to add gold in Skyrim: '''player.additem f 200'''
*:: '''''Tip:''' leading zeroes can be dropped from IDs. So '''0000000f''' becomes just '''f'''.''
* '''player.addspell formID'''
*: Adds a specified spell to the player's spell list. Spell IDs can be found [https://www.skyrimsearch.com/magic.php here].


'''uGrids'''
===Targeted Commands===
Targeted commands require the reference to be selected in the console. To target a reference, use the mouse to click on it while the console is open.
* '''disable'''
*: Disables a targeted, enabled reference.
* '''enable'''
*: Enables a targeted, disabled reference.
* '''Kill'''
*: Kills a targeted NPC.
* '''Resurrect'''
*: Resurrects a dead NPC.
* '''unlock'''
*: Unlocks a targeted object (doors, chests, etc).


This ini setting MUST be set to the default value of 5. For those of you who use a value of 7 and above, be warned that these higher values are 100% inherently unstable. It may be stable as a rock for you, but please don't test a mod with anything but the default value of 5. The chance that a new mod may cause stability issues with higher uGrids values is quite high, and again, most Skyrim players will be using the default value. To easily switch between uGrids values, create the relevant ini files in the INI Tweaks folder for WB as mentioned in the section above.
===Other Commands===
* '''coc locationName'''
*: Transports the player to a specified location. Replace '''locationName''' with the name of the location.
*: A list of Skyrim location names can be found [https://www.skyrimsearch.com/cells.php here] and [https://elderscrolls.wikia.com/wiki/Console_Commands_%28Skyrim%29/Locations here].
*: '''coc qasmoke''' is Skyrim's developer testing hall with containers for all game items.
* '''killall'''
*: Kills all non-essential NPCs within the player's vicinity.
* '''set timescale to ##'''
*: Changes the timescale of the game.
*: Change '''##''' to the desired value. '''20''' is default. ''Setting below '''10''' may cause issues.''


Should you attempt to test a mod on a save game that used to have a higher uGrids value, you will be unable to load it. There are three solutions. The first is to start a new game, which is highly preferred. The second is to use a Bat file to revert to the default value. These can be obtained from the [http://donotargue.com/cfg-makers/skyrim/ DNA INI Generator] site. Once there, navigate to the green panel called Downloads, and follow the instructions there. The third option is to use a selection of vanilla saves and STEP complete saves that can be downloaded under the save game section.
== External Tools ==
=== Capture Software ===
Feel free to use the preferred program for captures. Some 3rd party software used by the staff include:
* [https://fpsmon.com/ FPS Monitor]
* [https://fraps.com/ FRAPS] - doesn't play well with some Windows features


Default uGrids Settings (Skyrim.ini)
==== Screen Captures ====
<pre>
The preferred format for screen captures is PNG due to its lossless nature. JPEG can be used as an alternative and is recommended for large comparison sets to reduce page loads. Do '''''not''''' use GIF format for screen captures! The simple solution for screen captures for some games will be to utilize their own built-in capture feature:
[General]
* '''Skyrim:''' use BethINI to set the capture path and use the <kbd>PrtSc</kbd> (print screen) key
uGrids=5
* '''Fallout 4:''' hotkey the photo mode capture key
uExterior Cell Buffer=32
</pre>


'''Papyrus Logging'''
==== Video Captures ====
The preferred formats (containers) for video captures are AVI, MKV, or MP4. Using one of these formats or a higher quality one is important for proper video captures in high definition. Capture in at least 1080p for fullHD, but ''always'' in a 16:9 format. Also use the following information for encoding:
* Use '''H.264 codec'''; MPEG-4 as a second option
* '''Audio:''' no less than a 48khz sample rate and no less than a 128kbps bit rate (96khz sample/384kbps bit rate is recommended for true HD audio)


These ini tweaks will allow you to see if and mod issues are caused by errors in the mods scripts. Not all mods will contain scripts though. Again the easiest way to apply these is create a sperate ini file in Wrye Bash's INI Tweaks folder. This tweak is applied to the Skyrim.ini file. The log files can be found where your save games are, in the Scripts folder.
===Texture Viewers===
 
* [https://www.gimp.org/ Gimp]
Papyrus Logging (Skyrim.ini)
*: A DDS plugin is [https://code.google.com/archive/p/gimp-dds/downloads available for download]. For BC7 support, [https://forums.eagle.ru/showthread.php?t=236816 see these instructions].
<pre>
* [https://software.intel.com/en-us/articles/intel-texture-works-plugin Intel Texture Works Plugin]
[Papyrus]
*: Plugin for DDS formats for Adobe Photoshop.
bEnableLogging=1
* [https://www.getpaint.net/ Paint.NET]
bEnableTrace=1
* [https://developer.nvidia.com/nvidia-texture-tools-exporter Nvidia Texture Tools]
bLoadDebugInformation = 1
*: Standalone tool and Adobe Photoshop plugin available.
</pre>
 
'''Mod Tracing'''
 
At the moment, in game mod tracing is very basic. Currently for textures, you can open the command console by pressing the ~ key, and click on the texture that you are interested in. In the console command screen you will see its name and reference ID (eight hexadecimal characters, ie "001C8F02"). The name and/ or the reference ID may be useful in tracing the object or texture of interest.
 
= Skyrim Testing Profiles =
 
==Skyrim Installation Swapper==
 
This is an essential utility for mod testers.
 
To quote the author; "Skyrim Installation Swapper (SIS) let's you create up to ten individual skyrim installation "profiles" which can be swapped in and out easily, via GUI or hotkey. (Kinda like MOM/mTES4 do for Oblivion, but not copying all the vanilla game files, the addition of hotkeys to swap, pick your storage location, et al.)
 
A "profile" consists of any files in the skyrim game folder that are NOT a vanilla game or CK file, as well as the contents of the mydocs\my games\skyrim folder and the appdata\local\skyrim folder." - RedStapler/ Kristijn
 
The use of this utility is important regarding STEP, because the mod must be tested against a vanilla skyrim setup (no other mods at all), and a full STEP modded skyrim setup. This program makes it much easier to switch between the two without the hassle of multiple re installs.
 
[http://skyrim.nexusmods.com/mods/19034/ SIS at Skyrim Nexus]
 
=== Basic Testing Installation ===
 
* Skyrim installed in a non windows directory.  Preferably something like E:\Games\Steam\steamapps\common\skyrim
* All DLC's installed and cleaned with TES5edit.  (Just what you own, you don't need to buy stuff just to test)
* All Unofficial Patches installed  (Just for DLC's you own)
* All ini's with Vanilla Ultra settings.
 
==== Utilities Installed ====
 
* SKSE
* BOSS
* Wrye Bash
* Mod Organizer
* TES5edit
* DDSopt
* SIS
 
= Mod Organizing Programs =
 
==General Information==
The mod should be first inspected by a mod organizer program such as Wrye Bash (WB) or Mod Organizer (MO). The Nexus Mod Manager (NMM) will not be enough due to inability of the program to show the internal structure of the mod package. Using these programs will let you know if the mod is suitably constructed, and in the case of WB, whether it conflicts with other mods.
 
'''[[Guide:Wrye_Bash|Wrye Bash]]'''
 
For testing mods, WB is recommended. Regarding testing, the major advantage of WB is the ability to observe if two more mods conflict. The S.T.E.P. guide recommends installing mods in particular order. This is because the mod installed last will overwrite mods installed before if these mods modify the same file. With WB, it is very easy to observe which STEP mods conflict with the mod being testing. This can then be reported to TC or the S.T.E.P. team. The S.T.E.P. wiki has an excellent WB guide which covers everything from the programs installation to mod management.
 
In particular, when analyzing the zip or rar file for structure, refer to the "[[Guide:Wrye_Bash#tab=BAIN_Installers|Package Structure & Interpretation]]" subsection in the BAIN Installers section.
 
'''[[Guide:Mod_Organizer|Mod Organizer]]'''
 
MO can also be recommended, but for a different reason than WB. MO creates virtual folders when installing mods, which means it will keep the skyrim directory clean. This can help in troubleshooting. It can also create profiles, similar to SIS. If you use MO as your default mod program, then you can choose between SIS and MO.
 
= In Game Testing Procedure =
 
==General Information==
This section is the most important and will detail the steps required to test a mod in such a way that it can be recommended for test. It will be as simple and streamlined as possible. However, regarding the complexity, breadth and depth of mods for skyrim, this guide will never be able to cover all testing scenarios. Ultimately, this guide should cover the majority of mod testing scenarios.
 
==Testing Procedure==
 
To begin with, the mod you have chosen to test will be examined using several tools to asses viability.
 
Next, the mod will be tested on a vanilla skyrim profile.
 
Thirdly, the mod will be tested on a STEP complete skyrim profile.
 
Lastly, the mod testers is encouraged to write a small review.
 
==External Assesment==
 
'''Mod Package Structure Assessment'''
 
Using WB or 7zip, observe if the downloaded mod package is properly structured or configured for installation. Detailed information on proper mod package structure can be found [[Guide:Wrye_Bash#tab=BAIN_Installers|here]].
 
'''Conflicts & Overwrites Assessment'''
 
Using WB, take note of any conflicts that appear against vanilla skyrim files. Information on how to do so can be found under the "[[Guide:Wrye_Bash#tab=BAIN_-_Installing_Mods|Package Installation]]" subsection of the BAIN - Installing Mods section of the WB guide.
 
For true conflict and overwrite information, it is best to extract the contents of the BSA archives, and use the extracted files instead of the BSA archives. Instructions on how to do this can be found here in the DDSOpt guide.
 
'''Plugin Assessment'''
 
Using WB, asses the plugin. Right-click on the .esp or .esm plugin and highlight "Mod Cleaning". In the drop down box, select "Scan for UDR's". This will indicate if the mod is clean or dirty, which should be noted in the review. Once additional programs such as TESVEdit, TESVJedit, and TESVGecko are released a more detailed explanation will be added.
 
'''Enable a Vanilla Skyrim Profile'''
 
Enable your vanilla version of skyrim using SIS or MO. Do not start the game yet.
 
'''Generate Default Skyrim.ini & SkyrimPrefs.ini Files'''
 
If you have not already done so using SIS or MO, generate default ini files on medium or high settings with the relevant modifications by following the instructions in the [[Guide:Mod_Testing#tab=Skyrim_Stability__26_Settings|Skyrim Stability and Settings]].
 
'''Papyrus Logging'''
 
During all stages of mod testing, papyrus modding should be enabled. Activate it by changing the relevant ini values in the Skyrim.ini file under Documents/My Games/Skyrim/ (for Win7).
 
 
'''Testing Locations'''
 
Testing Hall
 
Riften
 
Whiterun
 
Riverwood
 
Mod Specific
 
'''Console Commands'''
 
coc
 
tgm
 
tcl
 
tfc
 
tfc 1
 
= Save Game Archive =
 
==Vanilla Saves==
 
==S.T.E.P. Complete Saves==
 
= In Game Tools =
 
==General Information==
Several in-game tools will be specified here. These tools will for the most part be mods that are particularly useful when it comes to mod testing.
 
 
'''[http://skyrim.nexusmods.com/mods/2006 Elys MemInfo]''' is a SKSE plugin that is very useful for displaying in game resource usage. Currently it is able to show RAM, Pagefile, Virtual Manager, Handles, and VRAM use and utilization by Skyrim. This is most useful when testing mods that affect graphics, such as texture mods, FXAA Injectors, ENB presets, and lighting and shadow tweaks and mods. For example, when testing out texture omptimizer, such as DDSOpt, it is possible to see how much VRAM use has decreased in certain areas. If you are hitting your graphic cards VRAM limit, it is useful to know that the optimizations have lowered VRAM use. Since Elys MemInfo displays this information in game, there is no need to minimize the game to bring up alternative resource use tools such as GPUZ or the Task Manager.  (Requires [http://skse.silverlock.org/ SKSE])
 
 
'''[http://skyrim.nexusmods.com/mods/9557 Alternative Start - Live Another Life]''' is an extremely useful in game testing mod. As explained before, mod testing is best done by starting a new game. One of the issues with testing out one, or many, mods quickly when starting out a new game, is the requirement by Skyrim to watch and play the opening sequence of the game. This mod allows mod testers to simply skip the rather long introduction sequence. For reducing the time required for testing mods, Life Another Life is an invaluable addition. It is also a safe and clean mod, and will not break any quest lines.
 
 
'''[http://skyrim.nexusmods.com/mods/12625 No Boring Sleep Wait Menu]''' allows the tester to wait up to 31 days quickly and easily, which is not possible using the vanilla waiting system. Skyrim requires a 31 day in-game wait time before as many cells as possible can be reset. Cell resets are useful when mod testing for several reasons. A cell may be badly generated, or you wish to install a mod without starting a new game for testing. In both cases a cell reset will potentially generate a proper cell, and the new mod may be integrated properly, especially if the mod affects spawns.
 
= External Tools =
 
==General Information==
This page contains a list of programs that will be recommended for use during the testing procedure.  
 
==Generic Programs==
 
'''[http://www.techpowerup.com/gpuz/ GPU-Z]''' is an amazing lightweight program that offers a plethora of ifnormation regarding any type of gpu you have, as well as allowing logging and graphing of gpu related processes such as vram load, temperature, clock speeds, and far more. This will be the main tool for testing graphic related mods, as its logging ability is very useful here.
 
 
'''[http://downloads.guru3d.com/NVIDIA-Inspector-1.94-download-2612.html Nvidia Inspector]''' (NI), is a program that allows for in depth gpu information of Nvidia graphics cards. It allows for very fine profile tuning for skyrim, as well as monitors for a range of process such as gpu temperature and vram use.
 
'''ATI Tools'''
 
==Skyrim Focused Programs==
 
* [http://skyrim.nexusmods.com/mods/6491 Skyrim Performance Monitor]
* [http://forums.bethsoft.com/topic/1392239-wipz-tes5dumpfuture-tes5edit/ TES5Edit]
* [http://www.darkcreations.org/forums/topic/1536-wipz-tesvgecko/ TES5Gecko]
* [http://forums.bethsoft.com/topic/1376366-wipz-jtes5edit-java-tes5edit-using-skyproc/ TES5Jedit]
* [http://forums.bethsoft.com/topic/1392239-wipz-tes5dumpfuture-tes5edit/ TES5Dump]
* [http://code.google.com/p/esedit/ esEdit]
 
= Mod Review =
 
'''Images'''
 
'''Videos'''
 
= Notes/ Ideas =
- Camera mod
 
- DDSopt if testing texture mods, link to DDSopt guide.
 
- videos
i. fraps
ii. youtube
 
- gifs
 
-image galleries
i. hosting sites
 
- compatebility checking
i. tes5edit, tes5gecko when released
ii. ck workarounds
 
- wrye bash
i. esmfy esps to fix ctds/ tesvsnip.
 
- INI tweaks / WB ini tweaks
i. medium default settings for stability
a. maybe upload WB ini wteaks files.
ii. papyrus logging
iii. mod tracing (need to test)
 
- saves
i. multiple save files from vanilla and STEP setup, heavy exterior areas, heavy interior.
ii. link to total cell clear in troubleshooting guide
iii. z92's suggestions for 60s run throughs.
 
- in game tools
i. elysmeminfo
ii. camera mod
 
- software tools
i. nvidia inspector, skyrim performance monitor, gpu-z, FPS background booster.
 
 
<headertabs/>

Latest revision as of 22:20, January 2, 2024

Delta c.png

Step Guide-Mod Testing

An in-depth manual to mod testing for Step Modifications

by: The Step Team  | Forum Topic

To ensure consistent and reliable mod testing, it's essential to minimize variations that can lead to a range of issues and inconsistencies. This guide will outline standardized techniques for mod testing that Step Modifications employs for evaluating all mods featured in our official modding guides. The recommendations provided progress through system and software setup before delving into the mod testing process.

Understanding Mod Testing

Mod testing encompasses various aspects. However, in the context of this guide, it refers to the assessment of mods for potential inclusion in a curated mod list. This evaluation involves several key components:

  1. Stability Testing: assesses a mod's stability when integrated with other mods in the mod list. It aims to identify any conflicts or issues that may arise from mod interactions.
  2. Functionality Testing: mod functionality is scrutinized to ensure it operates as intended. Any deviations from the mod's intended purpose are noted and addressed.
  3. Mod Comparison: mods with similar content are compared to determine which one provides the best solution.
  4. Lore and Mandate Assessments: mods are evaluated against Elder Scrolls lore to ensure they align with the established lore and adhere to the Step Mandates. This ensures that the mod fits seamlessly into the Elder Scrolls universe.

It's important to acknowledge that mod testing can be a time-consuming and meticulous task. Nevertheless, it can also be rewarding and enjoyable. Mod testing is ideally suited for individuals who are genuinely dedicated to the process. Consequently, turnover rates among users involved in official testing are high, as many underestimate the demands of mod testing; quickly become overwhelmed by the complexity of the task.

Following is described the detailed process required for testing mods in a manner that ensures consistency and facilitates recommendations (or not) for a Step Game Guide. Our aim is to maintain a process that is straightforward and efficient, yet given the complexity and extensive nature of some mods, this process may not encompass every conceivable mod testing scenario. While common scenarios are provided, it's crucial for testers to exercise best judgment when faced with situations not explicitly covered.

System Preparation

Before embarking on mod testing, it is essential to establish a stable system and game installation. Without them, distinguishing whether a mod is incompatible with the mod list or the system becomes significantly more challenging. Testers should have their systems configured according to one of the Step Game Guides. Nevertheless, here are some general reminders and best practices to ensure the environment is adequately prepared for mod testing.

General Setup

  • Ensure the System Setup Guide is complete
  • Ensure a clean and pure installation of the Step Game Guide for which testing is being performed
    A pure installation means nothing exists within the mod list that isn't included in the Game Guide; the installation should be 100% within the bounds of the Guide.

Game Settings

All game INIs, launcher, and in-game settings should be configured according to the Game Guide for which testing is being performed. Therefore, any post-installation changes should be reverted back to the Guide's instructions for the duration of testing.

Mod Organizer Profile Setup

Step Modifications' officially supported mod manager is Mod Organizer, and it proves itself more helpful than other managers for mod testing. Follow these instructions to set up two new profiles in Mod Organizer for testing:

  1. Open Mod Organizer and select the instance for the game for which testing is being performed
  2. Select the Profiles MO.png icon
  3. Copy the Step Game Guide profile
  4. Name the new profile: Vanilla
    • Make sure the Local Savegames box is not checked for the testing profiles
    • Make sure the Automatic Archive Invalidation box is selected for the testing profiles
  5. Name the new profile: GuideName vX.X Testing
    • Make sure the Local Savegames box is not checked for the testing profiles
    • Make sure the Automatic Archive Invalidation box is selected for the testing profiles
  6. Select the newly created Vanilla profile and ensure no mods are enabled

Vanilla Save

Though playing through vanilla content may be at the top of anyone's list, this step is not optional. A vanilla save point is required for some comparisons, as well as, providing a default environment from which to start the majority of testing.

  1. Select the Vanilla profile
  2. Start a new game from this Vanilla profile
  3. Play through any introductory quests until the first point is reached that allows for free roaming of the game
  4. Once at a free roaming point, save the game
    • Fallouts: play until at the starting vault's exterior
    • Skyrim: play until at the exterior of Helgen cave
    • Starfield: play until the Frontier can be freely piloted and save at NA Spaceport
    Tip: Use the console to create a save with a custom name for quick reference. (save SaveName)


External Testing Procedures

All testing begins outside the game. Each of the following steps should be completed and notes taken from each before proceeding to in-game testing.

Step 1 - Forum Mod Topic

Read the mod's topic opening post (OP)

The mod's topic OP often contains an outline of what needs to be tested for a particular mod. Make note of this and use it when in-game testing begins. If nothing is outlined in the OP, it's likely the mod has not been tested or reviewed enough to include it. In such cases, testers will establish a outline by editing the OP. This outline should include what mod options should be tested, how to test, steps for making the mod compatible with other mods, etc. Most of this information will be gathered from the actual testing process below.

Step 2 - Nexus Page

Read the Nexus Page in its entirety

  • Description: make note of any special installation/uninstall instructions, any known internal or mod compatibility issues, and of any potential conflicts with supported DLCs and other mods within the Step Game Guide.
  • Posts: a complete read is not necessary; however, testers should attempt to develop a sense of user satisfaction. Posts can also reveal a list of possible bugs not listed within the Bugs section. Unless a mod is fully developed with few to no bugs being reported, some sort of interaction from the mod author is preferred to ensure the mod isn't abandoned.
  • Changelog: changelogs often provide a sense of what direction the mod it headed, how often issues are addressed, features being edited, etc.
  • Bugs: review any active bug reports. Too many bugs may disqualify a mod from being included within a Step Game Guide.

Step 3 - Validation

Validate the archive package using MO or 7zip

Observe if the downloaded archive is properly structured and configured for installation or not. For more complex installations, Mod Organizer FOMODs are preferred; however, MO can install BAIN type installations as well. FOMODs can be validated using an online validation tool, XML Validator, or by using FOMOD Validator. When installing mods using Mod Organizer, the bottom pane will also have a report of potential issues with the package.

Step 4 - xEdit

Inspect plugins using xEdit

Knowledge of xEdit and conflict resolution is required for this step. Load the entire Step Game Guide and the mod being tested with xEdit. Review and note any issues of the mod failing to carry forward changes from DLCs, mods, and patches included within the Step Game Guide. These notes help with creating correct conflict resolution via official patches.

Step 5 - Installation/Uninstall

  • Validate installation procedure listed on the Nexus page.
  • Validate uninstallation procedure listed on the Nexus page.

Step 6 - Inspection

Inspect the installation in MO

  1. Install the mod as it will be used for testing
  2. Run LOOT and note information
    Unless the mod is new on the scene, LOOT will recognize it and provide some valuable information such as if the mod is clean or dirty, requires other mods, etc.
  3. Using Mod Organizer, take note of any asset conflicts that appear against vanilla files and other mods in the Step Game Guide.
    Extract any BSAs to ensure the conflicts are being read. BSAs should not remain extracted unless required for further testing. Otherwise, remove the extracted BSA contents before continuing any testing.

Step 7 - Mandate

The final step is to evaluate the mod against the Step Modifications Mandate. Ensure the mod does not fall into the "...not about" sections. If it does, no more testing is required. Post findings why the mod doesn't fit the Mandate to the mod's topic. If the mod succeeds in passes this step, continue on to the remainder of testing the mod.


Testers should update the mod's topic OP on the forums with any relevant information gathered from the above testing.


In-Game Testing Procedures

This process is the most important and will detail steps required for testing mods in a consistent way so they may be recommended (or not) for a Step Game Guide. It will be as simple and streamlined as possible, however, with the complexity, breadth, and depth that mods can be, this process will never be able to cover all mod testing scenarios. Below we provide the most common of scenarios, however, when the scenario isn't covered best-judgment must be used.

Info-Logo.png
NOTE:
The process for capturing comparison screenshots can be found following these procedures; which are for gameplay testing.


Pretesting Setup

Enable the testing profile
Testing for Step Game Guides should be completed from the profile set up, above, for that Guide in Mod Organizer: GuideName vX.X Testing.

Step 1 - The Vanilla Experience

It's important to be familiar with the original content whether it be textures, quests, game mechanics, etc. Therefore, if there is no familiarity with the changes being tested, the original content should be experienced first. If familiarity does exist this step may be skipped. To complete this step:

  1. Load the Vanilla profile in MO, launch the game, and load the Vanilla save
  2. Fast travel to or use the command console to load the area closest to the mod's altered content
    Tip: before starting the content, make a new save that can be used later for faster testing
  3. Play the game for a period of time to experience or view the vanilla content
  4. Close the game and review findings for the next step

Step 2 - Experience the Mod

  1. Relaunch Mod Organizer and select the Testing profile
  2. Activate the mod being tested
  3. Relaunch the game and load the Vanilla save or a save created for testing from Step 1
  4. Allow the mods to initialize
  5. Play the game for a period of time; assessing the mod:
    • Does it work as intended?
    • Does it look as intended?
    • Does it fit in with the game's content/ambiance/environment?
    • Are there any issues?
  6. Close the game and review the findings

Final Step - Review

  1. Gather the findings from all testing sources including the External testing.
  2. Summarize a review and post this on the mod's topic on the Step Forums. Content to include are, but not limited to:
    • Issues with file structure and installation
    • Conflicts with vanilla or guide content (and solutions, if any)
    • Whether the mod met or fell below expectations
    • Any in-game issues
    • Personal assessment of whether the mod should or shouldn't be included in a Step Game Guide
Info-Logo.png

NOTE

Be mindful to remain objective. Do not write anything that will reflect upon the mod's author in a personal manner. Only review the craftsmanship, reliability, operation, etc of a mod, itself. Mods are assessed for guide inclusion, not for judgment against authors!


Capturing Comparison Sets

When testing mesh and/or texture based mods, comparison screenshots are required and are to be posted for the community to review. These shots are not for the staff to use for evaluation, since in-game testing should be completed, but rather they are for the community's benefit and staff reference.

Screenshots and videos are provided them from in-game sources. Do not use "studio" or "editor" applications! In-game lighting conditions and rendering can change the appearance of many game assets; therefore, it's important to capture these comparisons from within the game, itself. Any capture software may be used as long as the saved image is a 1:1 match in color and quality to the in-game image. Some recommendations can be found within the External Tools header below.

Warning-Logo.png

NOTE

Do not use PNG as the file format when posting compares on the forums. They tend to be large files, which in turn cause long loading times on pages. JPG/JPEG should be sufficient and is about one quarter the payload of PNGs. Only use PNG when transparency is required.

Capture Procedure

Comparison shots and videos need to include:

  1. Vanilla reference
  2. current Guide reference
  3. mod reference

This process will allow captures to be of the exact same reference point, in each capture, with the only difference being asset replacements.

  1. Active a HUD mod that auto-hides the HUD for all MO profiles, including Vanilla (i.e, for Skyrim active Immersive HUD). This will auto-hide the HUD so that it doesn't have to be done manually from the console. If the Game Guide doesn't include one of these mods, the HUD will have to be manually hidden or remain present in the captures.
  2. Load the Vanilla profile and Vanilla save file
    The mod being tested should only be active in the Testing profile.
  3. While in-game, locate the vanilla reference(s) that need to be captured.
  4. Once the reference is found, line the capture up in the frame
    • Pay attention to lighting and angles to make sure the capture will be good for compares.
    • Ensure nothing will interfere in the shot such as an NPC walking into the frame.
  5. Once the capture is lined up, create a new save
  6. Now load the save that was just created
    Do NOT touch the mouse! Doing so may cause the capture to because misaligned.
  7. Once loaded, ensure there is no temporary text on the screen and the HUD has been hidden
    Manually hide the HUD (see commands below) or simply leave it in the capture when no mod exists for auto-hide.
  8. Take the capture using the hot key for the capture software being used
  9. Exit the game
  10. Switch to the Game Guide profile
  11. Repeat steps 6-9 above for the Guide captures
  12. Switch to the Testing profile
  13. Active the mod being tested and ensure its conflict resolution is as desired
  14. Repeat steps 6-9 above for the mod captures

Posting Captures

Post the comparison capture(s) on the Step Forums. Repeat this process for all assets that require a comparison set for any given mod. When only one asset is being tested, it is encouraged to provide several captures from various angles/locations/lighting situations for a more complete review.

When posting captures on the Step Forums:

  • Please use the Editor buttons/functions on the forums to post.
  • Use a 3rd party service to host captures. Do not store your captures on the Step Wiki!
    • Imgur and Postimage have proven to be an excellent, free image hosting sites for uploading screen captures to.
    • Use YouTube for hosting video captures.
      Other services have proven themselves annoying for community members to use; most requiring an account to view the videos.


Info-Logo.png

NOTE

The remainder of the guide contains helpful console commands, tips, tools, and more.


Helpful Console Commands

Provided is a list of helpful console commands to use while testing. They are specific to Bethesda games.
To open the in-game console press the ~ (tilde) key, which is normally located just below the Esc (escape/exit) key on a standard keyboard. Press it again to close the console.

Toggles

  • tmm 1
    Toggles all map markers on; thus allowing fast travel to any location. Enter 0 in place of 1, to reset to default.
  • tgm
    Toggles God Mode on/off. While in God Mode the PC will be invincible with unlimited health, magicka, and stamina.
  • tcl
    Toggles collisions on/off; thus allowing the PC to walk through anything.
  • tfc
    Toggles Free Camera Mode on/off. tfc 1 will pause the camera.
  • tm
    Toggles menus on/off. Useful when taking captures.
  • tai
    Toggles all NPC AI on/off. NPC will typically not move when toggled off.
  • tcai
    Toggles all NPC Combat AI on/off. NPCs will interact normally, but will not actively attack the player.

Player Commands

  • player.additem formID ###
    Adds the item to the player's inventory.
    Replace formID with the baseID of the item. These IDs can be found here. Replace the ### with the number of items to add.
    For example, to add gold in Skyrim: player.additem f 200
    Tip: leading zeroes can be dropped from IDs. So 0000000f becomes just f.
  • player.addspell formID
    Adds a specified spell to the player's spell list. Spell IDs can be found here.

Targeted Commands

Targeted commands require the reference to be selected in the console. To target a reference, use the mouse to click on it while the console is open.

  • disable
    Disables a targeted, enabled reference.
  • enable
    Enables a targeted, disabled reference.
  • Kill
    Kills a targeted NPC.
  • Resurrect
    Resurrects a dead NPC.
  • unlock
    Unlocks a targeted object (doors, chests, etc).

Other Commands

  • coc locationName
    Transports the player to a specified location. Replace locationName with the name of the location.
    A list of Skyrim location names can be found here and here.
    coc qasmoke is Skyrim's developer testing hall with containers for all game items.
  • killall
    Kills all non-essential NPCs within the player's vicinity.
  • set timescale to ##
    Changes the timescale of the game.
    Change ## to the desired value. 20 is default. Setting below 10 may cause issues.

External Tools

Capture Software

Feel free to use the preferred program for captures. Some 3rd party software used by the staff include:

Screen Captures

The preferred format for screen captures is PNG due to its lossless nature. JPEG can be used as an alternative and is recommended for large comparison sets to reduce page loads. Do not use GIF format for screen captures! The simple solution for screen captures for some games will be to utilize their own built-in capture feature:

  • Skyrim: use BethINI to set the capture path and use the PrtSc (print screen) key
  • Fallout 4: hotkey the photo mode capture key

Video Captures

The preferred formats (containers) for video captures are AVI, MKV, or MP4. Using one of these formats or a higher quality one is important for proper video captures in high definition. Capture in at least 1080p for fullHD, but always in a 16:9 format. Also use the following information for encoding:

  • Use H.264 codec; MPEG-4 as a second option
  • Audio: no less than a 48khz sample rate and no less than a 128kbps bit rate (96khz sample/384kbps bit rate is recommended for true HD audio)

Texture Viewers