mirror of
https://github.com/loot/libloot.git
synced 2026-07-27 14:16:01 -07:00
Readme appendix updates.
This commit is contained in:
+19
-27
@@ -167,7 +167,7 @@ Visual C++ Redistributable for Visual Studio 2013 (x86)</a>. BOSS can be install
|
||||
Clicking on a plugin in the list will display the editing panel, where its load order related metadata can be edited. The <q>Show only conflicting plugins</q> checkbox filters the plugin list so that only plugins which can be validly added to the <q>Load After</q> list and either contain conflicting records or (if the selected plugin loads a BSA) load BSAs that <i>may</i> contain conflicting resources. The checkbox must be ticked before plugins can be added to the <q>Load After</q> list, which is done by drag 'n' dropping them from the plugin list, and it must be unticked to select another plugin for editing. The priority value is explained <a href="#editingPriority">below</a>.
|
||||
<p>If the <q>Apply</q> button is clicked, BOSS does one of two things: if no edits were made, then it immediately applies the load order, but if edits were made, then it repeats the sorting process with the new edits applied. If the <q>Cancel</q> button is clicked, then the load order and any edits made are discarded.
|
||||
<p>BOSS then generates a report and displays it either in a new window or in your default browser, according to the value of the <a href="#settingsViewReports">relevant setting</a>. Any errors encountered during the sorting process will be displayed in this report, including those due to graph cycles, missing dependencies or installed incompatible plugins. See the next section for more information on the report.
|
||||
<p>BOSS is able to sort plugins ghosted by <abbr title="Wrye Bash, Wrye Flash or Wrye Flash NV">Wrye *ash</abbr>, and can extract Bash Tags and version numbers from plugin descriptions. Provided that they have the <code>Filter</code> Bash Tag present in their description, BOSS can recognise filter patches and so avoid displaying unnecessary error messages for any of their masters that may be missing.
|
||||
<p>BOSS is able to sort plugins ghosted by Wrye Bash, and can extract Bash Tags and version numbers from plugin descriptions. Provided that they have the <code>Filter</code> Bash Tag present in their description, BOSS can recognise filter patches and so avoid displaying unnecessary error messages for any of their masters that may be missing.
|
||||
<p>While reading very large plugins, such as the game's main master file, BOSS may appear to stop responding: this is not an issue. The time it takes for BOSS to sort your load order depends primarily on the size of the masterlist being used, the total size of the files in your load order, and the number of plugins in your load order. The first run is likely to be longer than subsequent runs as BOSS needs to download the full masterlist, rather than just the changes made by updates. In testing, it was found that sorting ~90 plugins with a total size of ~350 MB and a 5 MB masterlist takes around 15 seconds, though performance will vary with computer hardware.
|
||||
|
||||
|
||||
@@ -234,7 +234,7 @@ Clicking on a plugin in the list will display the editing panel, where its load
|
||||
<li>The <var>language</var> is the language BOSS runs in that the message will be displayed for. For example, if the message language is set to <q>English</q> and BOSS is running in German, then the message will not be displayed. If left unspecified, the message will be shown no matter what language BOSS is running in.
|
||||
</ul>
|
||||
<p>If a message's condition determines that it should not be displayed, then it will not be displayed, no matter the language. However, if a message's condition determines that it should be displayed, but the language is specified and doesn't match the language BOSS is running in, the message will not be displayed.
|
||||
<tr><td>Bash Tags<td>A list of Bash Tags. These are used by the <abbr title="Wrye Bash, Wrye Flash or Wrye Flash NV">Wrye *ash</abbr> utilities when generating a Bashed Patch. BOSS's metadata includes Bash Tag addition and removal suggestions, and any Bash Tags that came with the plugin are also displayed.
|
||||
<tr><td>Bash Tags<td>A list of Bash Tags. These are used by Wrye Bash when generating a Bashed Patch. BOSS's metadata includes Bash Tag addition and removal suggestions, and any Bash Tags that came with the plugin are also displayed.
|
||||
<p>As BOSS can suggest Bash Tags be added or removed, it is possible for the same Tag to appear twice, being suggested for addition and removal. In such cases, removal overrides addition.
|
||||
<p>Each Bash Tag has three sub-fields:
|
||||
<ul>
|
||||
@@ -315,7 +315,7 @@ Clicking on a plugin in the list will display the editing panel, where its load
|
||||
|
||||
<p>General discussion and the submission of questions, suggestions and metadata takes place in BOSS's official threads for <a href="http://forums.bethsoft.com/topic/1434397-rel-boss-for-oblivion/">Oblivion</a>, <a href="http://forums.bethsoft.com/topic/1485022-relz-boss-for-skyrim/">Skyrim</a>, <a href="http://forums.bethsoft.com/topic/1282711-relz-boss-for-fo3-thread-4/">Fallout 3</a> and <a href="http://forums.bethsoft.com/topic/1483857-rel-boss-for-fallout-new-vegas/">Fallout: New Vegas</a>.
|
||||
|
||||
<p>Information on dirty plugins is very welcome, but for such information to be useful we require at least the filename and the CRC of the dirty plugin. The CRC may be calculated using <abbr title="Wrye Bash, Wrye Flash or Wrye Flash NV">Wrye *ash</abbr> or 7-zip, with other sources being unverified as correct. In the case of 7-zip, the <q><em>CRC checksum for data</em></q> is the one required. In addition to the CRC, the number of records removed (the ITM count) and/or undeleted (the UDR count) are also welcome.
|
||||
<p>Information on dirty plugins is very welcome, but for such information to be useful we require at least the filename and the CRC of the dirty plugin. The CRC may be calculated using Wrye Bash or 7-zip, with other sources being unverified as correct. In the case of 7-zip, the <q><em>CRC checksum for data</em></q> is the one required. In addition to the CRC, the number of records removed (the ITM count) and/or undeleted (the UDR count) are also welcome.
|
||||
|
||||
|
||||
<h2 id="translate">Translating BOSS</h2>
|
||||
@@ -454,43 +454,35 @@ A copy of the license is included in the file named "GNU FDL v1.3.txt".</blockqu
|
||||
<h2 id="appendix">Appendices</h2>
|
||||
<h3 id="appendix-intro">Introduction To Load Orders</h3>
|
||||
<p>This appendix provides a general overview of load ordering in the games BOSS supports for those who are unfamiliar with the concept. For simplicity, <q>the game</q> will be used when the text refers to any of the games that BOSS supports.
|
||||
<p>Mod plugins for the game are files that end in <code>.esp</code> or <code>.esm</code>. These files are created by the game's official editing tools, or by third party modders' tools. They contain various data entries, which can either be brand new additions or changes to the entries added by another plugin, including the game's main master file (Oblivion.esm, Skyrim.esm, Fallout3.esm or FalloutNV.esm depending on the game). These entries cover almost all aspects of what is in the game, eg. NPCs, items, races, interiors, worlds, quests, etc.
|
||||
<p>When the game is run, it loads each of the plugins you have installed one by one. The order in which it loads them is, unsurprisingly, what is referred to as the load order. The load order is important for two reasons:
|
||||
<p>Mod plugins for the game are files that end in <code>.esp</code> or <code>.esm</code>. These files are created by the game's official editing tools, or by third-party modders' tools. They contain various data <em>records</em>, which cover almost all aspects of what is in the game – NPCs, items, races, interiors, worlds, quests, etc. – and can either be new or changes to the records added by another plugin.
|
||||
<p>When the game is run, it loads each installed plugin one by one in a certain <em>load order</em>. The load order is important for two reasons:
|
||||
<ul>
|
||||
<li>Dependency resolution.
|
||||
<li>Conflict resolution.
|
||||
<li>If one plugin changes a record added by another plugin, the former must load after the latter. If it doesn't, the game will crash on launch.
|
||||
<li>The game can only apply one version of a record, so if multiple plugins contain the same record, the last-loaded plugin's version overrides all others. This is known as the <em>rule of one</em>, and it holds true for almost all record types. Some overrides can cause problems in-game, and a good load order is one that arranges plugins to avoid such problems.
|
||||
</ul>
|
||||
<p>A plugin which changes the entries added by other plugins is dependent on those other plugins, and the game requires all of the latter plugins to be loaded before the former. If they aren't, the game will crash on launch.
|
||||
<p>The game can only apply one version of any one entry (this is known as the <q>rule of one</q>). Therefore, when more than one plugin changes the same entry, the load order is used to decide which plugin's changes are applied. Put simply, the last loaded plugin's changes are applied. The one exception to the <q>rule of one</q> is that the contents of cells (the physical space in which your character moves) can be changed by any number of plugins, so different plugins can add objects to cells, move them around or remove them and all will see their changes applied by the game.
|
||||
<p>By changing the load order, you can change which plugins override and which are overridden, and so reduce detrimental conflicts. You cannot actually reduce how much is overridden through load order alone, but it is often the case that some overrides are acceptable while others cause problems in game. Setting a good load order is the process by which you seek to maximise the former instead of the latter.
|
||||
<p>Further compatibility between mods is then possible through the use of patches, which are made to address incompatibilities between specific mods, and through the use of Wrye Bash, which can create a <q>Bashed Patch</q> that allows you to select between types of changes for different mods. For example, two mods change a piece of armour, but one changes how it looks and the other changes its effectiveness: through load order alone you could only ever get one change, but using Wrye Bash you can get both, because they change different things in the same armour entry.
|
||||
<p>There are a few hardcoded rules that trump load order in many cases:
|
||||
<p>There are a few hardcoded rules related to load order:
|
||||
<ul>
|
||||
<li>Master plugins always load before non-master plugins.
|
||||
<li>Master plugins always load before non-master plugins. The difference between the two plugin types isn't really relevant, except that a plugin's type is decided by a setting inside it, and not by its file extension (even though <code>.esm</code> stands for Elder Scrolls Master).
|
||||
<li>There is a limit of 255 active plugins that can be loaded by the game. This isn't strictly a load <em>order</em> thing, but is worth mentioning.
|
||||
<li>In Skyrim, <code>Skyrim.esm</code> always loads before all other plugins.
|
||||
<li>In Skyrim, if <code>Update.esm</code> is present, it is always loaded. If it has no load order position set, it loads after all other master plugins. That might sound a bit odd, but thanks to Skyrim's load order mechanism, it is possible for it to have no set load order position, even though it is always loaded.
|
||||
<li>In Skyrim, if <code>Update.esm</code> is present, it is always loaded. It loads after all other master plugins, unless it has another position explicitly set.
|
||||
</ul>
|
||||
<p>A plugin's position in the load order is often displayed by mod managers as a hexadecimal number, from 00 to FE (0 to 255 in decimal). The plugin with position 00 loads first, and the plugin with position FE is loaded last. Hexadecimal numbers are used to display the load order positions of plugins because these numbers form the first two digits of the code that the game uses to reference the entries that the plugin adds, so knowing the numbers allows modders and mod users to determine from which plugin an entry is from.
|
||||
<p>That's all that you as a mod user <em>need</em> to know about load orders. If you want to find out more about the actual mechanism by which the game decides the load order, read on.
|
||||
<p>Oblivion, Fallout 3 and Fallout: New Vegas all share the same mechanism for deciding load order. Skyrim, since the 1.4.26 patch, uses a different mechanism.
|
||||
<p>Load order for Oblivion, Fallout 3 and Fallout: New Vegas is decided by the modification date timestamps of the mod plugins. The active plugin with the earliest date loads first, with plugins being listed in descending date order (earliest to latest). It's a bad idea for a plugin that isn't the game's main master file to load first.
|
||||
<p>Skyrim's mechanism uses the order that plugins are listed within its <code>plugins.txt</code> file as its load order (from top to bottom). This file is the one in which the list of active plugins is stored, so only active plugins can be strictly said to have a load order.
|
||||
<p>A plugin's position in the load order is often displayed by mod managers as a hexadecimal number, from 00 to FE (0 to 255 in decimal). The plugin with position 00 loads first, and the plugin with position FE is loaded last. Hexadecimal numbers are used to display the load order positions of plugins because these numbers form the first two digits of the code that the game uses to reference the records that the plugin adds, so knowing the numbers allows modders and mod users to determine from which plugin a record is from.
|
||||
|
||||
<h3 id="appendix-dirty">Dirty Edits, Mod Cleaning & CRCs</h3>
|
||||
<p>Dirty edits are often a side-effect of mod creation, and are often due to bugs in the utilities Bethesda has provided to create mods, rather than bad practice by mod authors. Dirty edits can cause a wide range of issues, including incorrect game settings, missing content, broken quests and crashing to desktop. The more dirty edits there are in a mod, and the more mods with dirty edits you use, the more likely you are to experience issues.
|
||||
<p>Thankfully there is a way to remove dirty edits from mods relatively easily, a process known as <i>mod cleaning</i>, using TES4Edit (for Oblivion), FO3Edit (for Fallout 3), FNVEdit (for Fallout: New Vegas) or TES5Edit (for Skyrim). A detailed set of instructions and information on mod cleaning can be found on the CS Wiki's <a href="http://cs.elderscrolls.com/constwiki/index.php/TES4Edit_Cleaning_Guide">TES4Edit Cleaning Guide</a> (the page also largely applies to Fallout 3, Fallout: New Vegas and Skyrim). <abbr title="Wrye Bash, Wrye Flash or Wrye Flash NV">Wrye *ash</abbr> can also scan plugins for dirty edits and return their ITM and UDR counts, though at the time of writing it cannot clean plugins itself.
|
||||
<p>Thankfully there is a way to remove dirty edits from mods relatively easily, a process known as <i>mod cleaning</i>, using TES4Edit, FO3Edit, FNVEdit or TES5Edit (for Oblivion, Fallout 3, Fallout: New Vegas and Skyrim respectively). Detailed instructions and information on mod cleaning are available for <a href="http://cs.elderscrolls.com/constwiki/index.php/TES4Edit_Cleaning_Guide">Oblivion</a> and <a href="http://www.creationkit.com/TES5Edit_Cleaning_Guide_-_TES5Edit">Skyrim</a>, with the process being largely the same for the others.
|
||||
<p>The problem of dirty edits is largely a problem of ignorance on the part of mod authors and users alike of the problems dirty mods can cause. As such, there are community efforts to raise awareness of dirty edits and cleaning. BOSS plays a key role in these efforts, as it holds the complete list of all known dirty mods, and it uses this information to provide notification messages to users for any dirty mods they have installed.
|
||||
There are three key pieces of information that are used to accurately describe and identify an unclean mod. They are:
|
||||
<p>BOSS identifies and describes unclean plugins using four key pieces of information. They are:
|
||||
<ul>
|
||||
<li><i><abbr title="Identical To Master">ITM</abbr> Count</i>: ITM records are a type of dirty edit where a mod has overwritten something in the game without actually changing anything. If another mod lower in the load order makes an intentional change to that thing, it will have its effect cancelled out by the ITM record, which can cause problems. The ITM count is the number of ITM records found and corrected in the mod plugin.
|
||||
<li><i><abbr title="Cyclic Redundancy Check">CRC</abbr> value</i>: CRC values are a highly accurate way of identifying files based on their contents, as if the contents change, so does the CRC value. BOSS identifies an unclean plugin by comparing the installed plugin's CRC value against the CRC values for known unclean versions of that plugin. This identification method has the limitation that it can't detect unclean plugins that aren't already known as such, and won't detect unclean but edited plugins, but it's a lot faster than actually checking for dirty edits in the plugin.
|
||||
<li><i><abbr title="Identical To Master">ITM</abbr> Count</i>: ITM records are a type of dirty edit where a mod has overwritten something in the game without actually changing anything. If another mod higher up in the load order makes an intentional change to that thing, it will have its effect cancelled out by the ITM record, which can cause problems. The ITM count is the number of ITM records found and corrected in the mod plugin.
|
||||
<li><i><abbr title="Undeleted and Disabled Reference">UDR</abbr> Count</i>: Deleting records is a significant cause of crashes and game bugs. UDRs are records that the mod deleted from the game or from another mod that have been corrected safely by undeleting them and disabling them instead, which has the same intended effect without causing issues. The UDR count is the number of deleted reference records found and corrected in the mod plugin.
|
||||
<li><i>CRC</i> or <i>Checksum</i>: A file's CRC is a highly accurate way of identifying it, and is a number calculated from the file's contents. If the contents of a file changes, so will its CRC. BOSS uses CRCs to check if a user's mods are dirty by checking their CRCs against pre-determined CRCs of known dirty mods. This lets BOSS give precise notification messages for any dirty mods it detects. BOSS can calculate the CRCs of all your installed plugins if run from the GUI with the <q>Display File CRCs</q> option enabled.
|
||||
<li><i>Deleted Navmesh Count</i>: Like deleting records, deleting navmeshes can cause crashes. However, these cannot be automatically corrected, and require manual cleaning. Navmeshes don't exist in Oblivion, so this information doesn't apply.
|
||||
</ul>
|
||||
<p>However, not all unclean mods have all or any of these pieces of information. For unclean mods whose ITM and UDR counts have not been reported, BOSS cannot give them. For unclean mods whose CRCs have not been reported, BOSS cannot give precise notification and so prints a message whether or not the user has cleaned their mod.
|
||||
<p>BOSS and the modding communities rely on user contribution of this information to progress. For information on how to contribute, see the <a href="#contrib">Contributing To BOSS</a> section below. If you find that a mod is dirty, you should also report this to the mod's author so that they can fix it.
|
||||
<p><b>Note:</b> TES4Edit et al. will include a variety of <em>junk records</em> in the ITM count for a plugin, such as new empty cells that are automatically generated by the Construction Set and are almost impossible to remove. These junk records are non-harmful, and BOSS will inform users when a mod contains these to avoid confusion. This is also the source of any discrepancies between the counts produced by TES4Edit and those produced by <abbr title="Wrye Bash, Wrye Flash or Wrye Flash NV">Wrye *ash</abbr>. The latter's counts are more technically accurate, but both are acceptable for use.
|
||||
<p>There is also another type of unnecessary edit, known as a wild edit, that can also cause problems. These edits are neither Identical To Master edits nor deleted records, so cannot be automatically cleaned. Cleaning must be manually done in TES4Edit/FO3Edit/FNVEdit. BOSS can still check for plugins with these edits if the CRCs of the plugins with wild edits are known, and it can provide notification of these edits and some information on fixing them if they are reported in an official BOSS thread.
|
||||
<p>In addition to the above, there is another type of dirty edit known as a <em>wild edit</em>. These are any edit that is unrelated to the purpose of the mod, and so provide unnecessary opportunity for conflicts with other mods that do need to change the same thing. It can be difficult to tell if an edit is a wild edit, and so they cannot be automatically cleaned. BOSS can still notify users of wild edits and link to information on fixing them if the CRCs of plugins with wild edits are reported, along with details on what needs cleaning.
|
||||
<p>BOSS and the modding communities rely on user contribution of this information to progress. For information on how to contribute, see <a href="#contrib">Contributing To BOSS</a>. If you find that a mod contains dirty edits, you should also report this to the mod's author so that they can fix it.
|
||||
<p><b>Note:</b> TES4Edit et al. will include a variety of <em>junk records</em> in the ITM count for a plugin, such as new empty cells that are automatically generated and are almost impossible to remove. These junk records are non-harmful, and BOSS may inform users when a mod contains these and no true ITMs to avoid confusion.
|
||||
|
||||
<h3 id="appendix-permissions">File Permissions</h3>
|
||||
<p>If you are running Windows Vista or a later version of Windows, BOSS (and other modding programs) may be prevented from working correctly by the UAC security feature. There are four common workarounds to this problem:
|
||||
|
||||
Reference in New Issue
Block a user