Guide:Wrye Bash

Installing & Maintaining S.T.E.P Using Wrye Bash

By z929669 & the S.T.E.P Team

---

Wrye Nomenclature

Wrye was a prominent TES (The Elder Scrolls) enthusiast, modder and developer that created Wrye Bash as a tool to help other modders deal with the idiosyncrasies of modding for Oblivion (TES4). Wrye also later created an implementation that he called Wrye ‘Mash’ for Morrowind (TES3). Wrye Smash is simply Wrye ‘Bash’ implemented for Skyrim (TES5), so it is Wrye Bash. For the sake of brevity and consistency, this guide will henceforth refer to Wrye Bash as ‘WB,’ and its analogues will likewise be referred to as ‘WS’ and ‘WM’ for Wrye Smash and Wrye Mash, respectively.

Purpose of This Guide

This guide assumes that the reader has reviewed the most updated, relevant documentation available for the WB program. If that is not the case, the authors strongly encourage a review of that documentation. Understanding--in a basic sense--what WB does and why it is useful are important concepts providing a context necessary for the reader to maximize the benefit of using this guide with respect to a fresh install of the most current major STEP (Skyrim Total Enhancement Project) release. Additionally, the guide will be modified and updated to reflect ongoing changes in each forthcoming major release of STEP. The novice WB user will likely find substantial value in following the guide as an actual working example of several sound techniques for implementing WB; nevertheless, much of the material covered in the following pages will be best understood with a baseline level of experience that exceeds “null” by at least a small margin, please familiarize yourself with the program before getting started.

Background - Basic Modding Principles

As with all TES games, modding Skyrim--in the most raw sense--can be accomplished by simply placing compatible files within the Steam/SteamApps/common/skyrim/Data directory (henceforth, referred to as “Data directory”). These files usually come packaged as a “mod” in an archive that facilitates simple decompression into the Data directory. Due to the vast number of mods and their incredible variety, the task of manual extraction and installation is a tedious process with lots of potential for error. Furthermore, it is difficult to “undo” what has been done, since it is difficult to keep track of the source of each file as the number of mods and files in the Data directory increases.

One must take care to read each mod’s documentation to understand exactly what it does and how it does in in at least a very general sense. Why? Because it is important to create a customized Skyrim that suits the tastes of the individual modder. Strictly defined, two mods are compatible if they do not attempt to alter the same game variable. Likewise, two mods that affect the same game variable are strictly defined as incompatible, which is more often termed a conflict. Said variable could be a mesh or a texture as well as a plugin or INI file. Even a game setting affected by a plugin while also being altered by an INI setting or a configuration script represents a conflict. Under the strict definitions of mod compatibility and conflict, many mods are incompatible and thus, have conflicts.

Fortunately, this is usually not really a problem, because most of the time, a conflict is inherently resolved by one mod “winning;” that is, one mod overwrites or overrides the other. For example, two particular versions of a texture file could attempt to occupy the same logical space in the Data/textures directory, in which case the second texture to be written to that space during installation will naturally overwrite the first; however, if one of those texture copies resides in a compressed BSA while the other exists as a “loose file,” then neither will physically overwrite the other upon installation, but rather one will override the other in-game upon execution of Skyrim.

The STEP Solution

One can spend hundreds of hours just searching for mods before actually getting down to the business of installing them. As mods increase in number and complexity and mod creators produce more and more mods that alter game play, interface and settings, the probability of game-crashing conflicts increases. The STEP project takes care of the heavy lifting associated with sifting through thousands of mods and selecting the ones that significantly enhance and improve the vanilla experience without detracting from it with as little cost as possible in terms of performance. Users are able to follow TheCompiler’s detailed, step-by-STEP manual-installation instructions and be confident that all components have been individually and communally tested and the results verified. STEP also facilitates customization by providing details of changes affected by each mod so that the user can choose to omit or change the order of STEP’s’. This cuts down on a vast amount of time and headache dealing with sampling, testing, troubleshooting, etc.

Limitations of STEP

Regardless of the huge time savings, efficiency boost and piece of mind that STEP offers, it is still a large manual process with many, well … steps. It can therefore take a while, and problems can and will occur for many users with increasing frequency as mod numbers and complexity increase, so STEP will only go so far to reduce the job of maintaining a viable setup with each new mod or mod update. In order to allow better scalability of STEP as it evolves, it is necessary to simplify and condense the procedure into more manageable components. Mod organizers in general help in this regard by keeping track of files installed and package installation order. In particular WB enables the most configurable interface for mod management, and is thus the recommended choice for installing, configuring and maintaining the STEP setup with each new alteration in the mod configuration.