A graphical .esp viewer and conflict detector utility. It's similar to what is included in Oblivion Mod Manager. So for those who do not use OMM (???) and are troubleshooting mod issues, this may help.
TES4View is an advanced graphical esp viewer and conflict detector.
When started it will automatically find your Oblivion Data directory. You then get a dialog to select which masters/plugins you want to load with the current selection from your plugins.txt as default value. This is followed by a second dialog which lets you choose which records not to load. By default this is LAND, PGRD, ROAD and REGN because these records are very large and usually not very interesting to look at. Once you have confirmed that dialog the selected plugins will start loading them in the background. Depending on your system it should take 30 seconds to a few minutes (!) for all plugins to load. You can follow the progress in the message window. (Don't panic if it seems to freeze, it just takes time).
The tree view on the left side now shows all active masters and plugins in their correct load order. By navigating that tree view you can look at every single record in any of your masters or plugins.
Once a record has been selected the detailed contents of that record is shown on the right side. The detail view shows all versions of the selected record from all plugins which contain it. The left most column is the master. The right most column is the plugin that "wins". This is the version of the record that Oblivion sees.
Both the detail view and the record list use the same color coding to signal the conflict state of individual fields (in the detail view) and the record overall (in the record list).
White - Single Record
Green - Multiple but no conflict
Yellow - Override without conflict');
Red - Conflict
Black - Single Record
Gray - Hidden by Mod Group
Purple - Master
Gray - Identical to Master
Orange - Identical to Master but conflict Winner');
Green - Override without conflict
Orange - Conflict winner
Red - Conflict looser
Conflict detection is not simply based on the existence of multiple records for the same FormID in different plugins but instead performs a comparison of the parsed subrecord data.
The record tree view on the left side has a context menu where you can activate filtering. Filtering is based on the same conflict categorization as the background and text color.
Yes, filtering will take a while. It has to decode and compare the contents of every single record which turns up more then once.
What's new in 1.1?
- Game Settings are handled correctly now
- Function Type and Params in Conditions are decoded completely
- Mod Groups (more about that later)
- Settings (records to skip, mod groups, filter) are loaded/saved into a .tes4viewsettings file with the same path and name as the plugins.txt (or the plugin list passed on the command line)
- Possible range check error when loading a file with errors should be gone
What are Mod Groups?
The answer to the "I installed FCOM and everything is red! What do I do now?" question.
There are groups of mods that, while raising heaps of conflict warnings, should be considered as non-conflicting. e.g. if you've installed FCOM then you are not interested in seeing conflicts between the mods that make up FCOM. The solution for this is to define a mod group. Mod groups are stored in a TES4View.modgroups file in the same directory as TES4View.exe. There already is such a file included with a few example mod groups defined. This is just an example and not meant as a guarantee that these specific mod groups are "clean" and conflicts can safely be ignored.
Not all mod groups defined in that file will necessarily show up in the selection list. Mod groups for which less then 2 plugins are currently active are filtered. If the load order of plugins doesn't match the order in the mod group it is also filtered.
What's the effect of having a mod group active?
When the detail view for a record is generated and multiple files of the same mod group modify this record, then only the newest of the files in that modgroup will be shown. So instead of seeing 5 different files with numerous conflicts you are only seeing the newest file in that mod group. This also affects conflict classification.
It's worth pointing out here that if a record is overriden by both plugins in a mod group and other plugins that normal conflict detection will still work perfectly.
Basically this system can be used to reduce a lot of noise from the conflict reports.
What's new in 1.2?
- Filtering the first time should be noticable faster
- Filtering a 2nd time should be over almost instantly
- New conflict category "Hidden by Mod Group" which can be filtered on
- When sorting by EditorID or Name the files get sorted by filename instead of load order
- Improved parsing of Path Grids
- A lot of "unknown" fields and flag values now have a proper name
- Selection dialog (used for files, record to skip, mod groups, ..) has a context menu with "Select all", "Select None" and "Invert Selection"
- added a couple more mod groups for the official plugins
- Bugfix: Filtering could wrongly filter out records with conflicts if their parent is also a record (not a group) and didn't contain a conflict
- numerous tweaks to the mechanism which assigns conflict classifications
- When filtering it is possible to "Build reference information" (adds quite a bit of additional processing time). After this has been done a new tab "Referenced By" is available if the currently selected record is referenced by any other records.
- Mod groups are applied better under certain circumstances.
- double clicking on a row in the right side treeview will open a window that shows the text of that field in a multi line memo. So you can now easily read scripts or books
- everything I've forgotton about ;)
Be warned, this program uses a lot of memory. Performance on a system with less then 2GB of RAM will most likely be sub-optimal. Activating the filtering uses even more memory.