The download can be found on http://fallout3nexus.com/downloads/file.php?id=637

If you are looking for FO3MasterUpdate, read the release notes for http://www.gamesas.com/bgsforums/index.php?s=&showtopic=973747&view=findpost&p=14343272.

http://www.gamesas.com/bgsforums/index.php?showtopic=915003
http://www.gamesas.com/bgsforums/index.php?showtopic=973747

FO3Edit is an advanced graphical module viewer/editor and conflict detector.

When started it will automatically find your Fallout 3 Data directory. You then get a dialog to select which modules you want to load with the current selection from your plugins.txt as default value. Once you have confirmed that dialog the selected modules will start loading in the background. Depending on your system it should take 30 seconds to a few minutes (!) for all modules 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 modules in their correct load order. By navigating that tree view you can look at every single record in any of your modules.

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 modules which contain it. The left most column is the master. The right most column is the module that "wins". This is the version of the record that Fallout 3 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).

Background color:
White - Single Record
Green - Multiple but no conflict
Yellow - Override without conflict
Red - Conflict

Text color:
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 loser

Conflict detection is not simply based on the existence of multiple records for the same FormID in different modules 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.

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.

Important:
If you get an error about d3dx9_*.dll not being installed, you need to update your DirectX to at least the March 2008 Version.

The most current DirectX version can be found here:
http://www.microsoft.com/downloads/details.aspx?familyid=2DA43D38-DB71-4C1B-BC6A-9B6652CD92A3&displaylang=en
or here:
http://www.microsoft.com/downloads/details.aspx?FamilyID=740ac79a-5b72-447d-84f9-ee6407ed1a91&DisplayLang=en (make sure to install it after unpacking it).

Here are all the release notes of all TES4View / TES4Edit / FO3Edit versions since Jul 6 2007. This covers pretty much all features beyond plain minimal conflict detection and viewing:

=========
What's new in Version 2.5.1?

Bug Fix: floating point comparison is now less "fuzzy". This can result in some floating point numbers now comparing as unequal even though they are within the limit of the accuracy of single (4 byte) floating point values. But it will prevent cases where floats that should be unequal compared as equal.

=========
What's new in Version 2.5.0?

Some minor record definition fixes.

Merged Patch creation and FO3MasterUpdate are now considered stable.

=========
What's new in version 2.4.9 EXPERIMENTAL?

• Merged Patch generation has been overhauled. It should now correctly handle RACE records (and in general any record with 2 or more mergeable lists) and OrderedList FLSTs.
  
• MIC2 subrecords are now supported in ARMA and ARMO records
  
• DEST(ruction) subrecords are now correctly handled in WEAP and CONT records

=========
What's new in version 2.4.3 BETA?

• DEST(ruction) subrecords are now support in NPC record
  
• MICO subrecords are now supported in ARMA records
  
• Context menu on file node in navigation treeview -> Renumber FormIDs from...

Renumber FormIDs from will change all FormIDs of records belonging to that file (but not any override records which might be contained in that file) so that they start at the specified value.

This is useful if you have multiple modules that you plan to update in the future, but also want to always provide a merged version (e.g. using FO3Plugin). By assigning non overlapping FormIDs to the different modules, you can make sure that no FormID reassignment of conflicting FormIDs has to take place when merging.

WARNING: changing the FormIDs of an existing module will make it savegame incompatible and will break any other module that uses this module as master. If you have any dependant modules, you need to have them all loaded into FO3Edit at the time you change to FormIDs so that they will all be updated accordingly.

=========
What's new in 2.4.1 BETA?

• FO3MasterUpdate is now considered BETA. No problems specific to FO3MasterUpdate have been reported in the last couple of days.
  
• Fallout3.Hardcoded.esp has been renamed.

=========
What's new in 2.4.0 EXPERIMENTAL?

This version adds a support for FO3MasterUpdate mode.

MasterUpdate mode is the solution to the bugs introduced in Patch 1.5 in regards to plugins.

When running in MasterUpdate mode, the following operations are performed without further user interaction:

• all modules in the Data folder are assigned into 2 groups, masters and plugins, based on their file extension (.esm or .esp)
  
• the modules in each group are sorted by file modification date/time
  
• all module files are redated, first all masters, then all plugins, in 1 minute intervals
  
• all active modules are then loaded, the ESM flag set in the file header if not yet present, the ONAM subrecords build if required
  
• any temporary overriding worldspace record that have at least one previous version that is persistent are marked as persistent
  
• all modified modules are saved.

This makes it possible to take an existing setup using patch 1.4 or older which contains mods that are broken by the bugs in patch 1.5 to be updated to patch 1.5, and used with existing savegames without being messed up by the bugs in Patch 1.5.

As this function is still considered EXPERIMENTAL, please make sure you have a full backup of your Data folder and your save games before using it.

I'll not take any responsibility if your computer explodes, gains sentience and start chasing you around the room or anything else that might happen.

You can run it in MasterUpdate mode by passing the parameter "-masterupdate" when running FO3Edit.exe or you can simply rename the exe to FO3MasterUpdate.exe

There is also a MasterRestore mode which removes the ESM flag again from all .esp files. You can run in MasterRestore mode by passing "-masterrestore" as parameter or renaming the exe to FO3MasterRestore.exe

=========
What's new in 2.3.5 EXPERIMENTAL?

• support for DEST(ruction) subrecord in TERM(inal) records.

=========
What's new in 2.3.0 EXPERIMENTAL?

• support for BrokenSteel.esm and Patch 1.5
  
• large number of small fixes to record definition, resulting in many more cases of records correctly identified as "identical to master" and a very significant reduction in potential false positives in the "Check for Errors" function.
  
• on the fly conversion of outdated records to the most current format. This means that you will see fields show up as modified that you didn't modify yourself (mainly in Fallout3.esm and the DLC.esm's, GECK created files should already be up to date). It is possible to disable this function by starting FO3Edit with -nofixup as parameter. It is also possible to just hide these modifications (but still keep the fixups) by starting FO3Edit with -hidefixup as paramter.
  
• Automatically update ONAM subrecord when saving ESM's (header flag, not file extension)
  
• New function to copy idle animations:
  
• Complete overhaul of the "build unreachable info" function
  
• Bugfix to prevent dialog choices from being sorted by FormID
  
• The "Remove 'Identical to Master' Record" function will now remove also the NAVM records (but only NAVM records) that show up as benign conflict, so there is no longer a need to do that manually
  
• The Undelete and Disable function will set the Player ACHR [00000014] as Enable Parent with the "Set Enable State to Opposite of Parent" flag set. Given that the player should never end up being disabled, that should properly remove them from the gameworld, even if they are persistent references and the enabled state has already been stored in the savegame.
  
• The Undelete and Disable function will also now properly list all affected references, just like the "Remove 'Identical to Master' Record" function does.
  
• The selection dialog now allows double clicking an entry, this will automatically select that entry, deselect all others and close the dialog as if the OK button had been pressed.

Some important notes about the "Build Reachable Info" function

After you've run that function, you'll see that some records are displayed striked-through. These records are considered to be "not reachable".

There are some limits to this. The "not reachable" classification is only true if you:

• start a new game with exactly the mods you've currently loaded
  
• do not use the console in any way
  
• there are no FOSE scripts involved that use some dirty tricks to get hold of a reference to something without that something showing up in the SCRO's of the script.

Also the meaning of "reachable" is sometimes a bit gray. e.g. for Activator's, Statics, Weapons, Armor, and so on it means that the player character should be able to get somewhere from where he can see the object and/or somehow get it into his inventory. For Quests it means that the quest either starts enabled or that there is probably some way how it can become enabled or at least that somewhere the variables belonging to the quest script get accessed. For DIAL's and INFO's it means that it's probably possible to select the topic somewhere or hear the response somewhere. For CELL's and WRLD's it means that the player character is probably somehow able to enter it. And so on.

Now, in the FormLists you might see some things marked as unreachable which do technically have an effect on the player character. e.g. the repair lists will show up as unreachable. The reason for that is that if the repairlist was marked as reachable, it would automatically mark all contained records as reachable. But that's not really right. Just because something can possibly be used to repair an object that the character has doesn't meant that this something can actually ever be acquired by the player. So really, for FormLists the reachable status doesn't mean much either way.

Outside of FormLists, there shouldn't be any false negatives (meaning something marked as unreachable which has an influence on the game).

There can be false positives (something marked as reachable while it's not). e.g. it's possible for a CELL to be considered reachable even though the only way to get there is through a door which can only be opened with a key and the key is not reachable.

Or for an INFO record to be reachable even though non of the conditions attached to the responses could ever possible be true. Or the quest that the INFO belongs to will never be enabled.

Or any type of object could be reachable even though it's just used in an GetIsID check in some script (not in a CTDA, objects referenced from conditions never become reachable through that).

But overall, even with all these shortcomings and gray areas, if someone ends up being marked as not reachable, that's a very strong indication that the particular thing will not normally effect the game.

If you apply a filter after the "build reachable info" you can filter "by not reachable status" and then "only not reachable" to just see what's considered to be not reachable.

=========
Mar 26 2009, 11:59 PM
I've just uploaded version 2.2.6 EXPERIMENTAL to http://fallout3nexus.com/downloads/file.php?id=637.

This version further extends the experimental list merging implementation.

Please read the release notes for version http://www.gamesas.com/bgsforums/index.php?s=&showtopic=915003&view=findpost&p=14023046 if you haven't done so already.

Also, a couple of posts http://www.gamesas.com/bgsforums/index.php?s=&showtopic=915003&view=findpost&p=14027492 is a description of the merging algorithm that's being used.

This version now processes the following record and list types:

		CheckGroup(GroupBySignature['LVLI'], 'Leveled List Entries');	CheckGroup(GroupBySignature['LVLC'], 'Leveled List Entries');	CheckGroup(GroupBySignature['LVLN'], 'Leveled List Entries');	CheckGroup(GroupBySignature['LVSP'], 'Leveled List Entries');	CheckGroup(GroupBySignature['CREA'], 'Items');	CheckGroup(GroupBySignature['CREA'], 'Factions');	CheckGroup(GroupBySignature['CREA'], 'Actor Effects');	CheckGroup(GroupBySignature['NPC_'], 'Items');	CheckGroup(GroupBySignature['NPC_'], 'Factions');	CheckGroup(GroupBySignature['NPC_'], 'Actor Effects');	CheckGroup(GroupBySignature['CONT'], 'Items');	CheckGroup(GroupBySignature['FACT'], 'Relations');	CheckGroup(GroupBySignature['RACE'], 'Hairs');	CheckGroup(GroupBySignature['RACE'], 'Eyes');	CheckGroup(GroupBySignature['FLST'], 'FormIDs', True);

This version also introduces an important change in the handling of FLST records. Till now the FormIDs list was considered to be an ordered list. From now on it is considered to be a set. This has a number of consequences:

• the list is always displayed ordered by FormID now
  
• it is no longer possible to move a specific FormID up or down the list
  
• in the detail view the FormIDs are now lined up in the same way as leveled list entries and other sorted lists.
  
• When a FLST record which has been modified is saved, the FLST will be saved sorted by FormID

For any list for which this behavior is not wanted you will have to ensure that the EditorID of the master record ends in OrderedList, e.g. "ABCOrderedList". Any such FLST will continue to be treated as it was before and will not participate in Form List merging.

Please make sure to perform this renaming with GECK or an older version of FO3Edit. Doing it with the current or a newer version will empty the list (whenever a rename results in a change of status from Set to OrderedList or back).

I really need feedback on how well this list merging is working for you!

=========
Mar 26 2009, 09:29 AM
Let me try to verbally describe the merging algo used:

• make a list with all entries from the master record, designate as TargetList
  
• repeat for each existing override record:
  • determine the file containing this override record, designate as CurrentFile
    
  • make a list with all entries from that override record, designate as CurrentList
    
  • go through the list of master files for CurrentFile, from last to first, stop when the first is found containing an override for this record, designate as CurrentMaster
    
  • make a list with all entries from CurrentMaster, designate as CurrentMasterList
    
  • going over CurrentList and CurrentMasterList, for each entry that:
    • exists only in CurrentList, add this entry to TargetList if not yet present
      
    • exists only in CurrentMasterList, remove this entry from TargetList if present
  
  
• make a list with all entries from the winning override record, designate as WinningList
  
• compare TargetList and WinningList, if different:
  • copy the currently winning record as override into the new file, designate as TargetRecord
    
  • remove all list entries from TargetRecord
    
  • go over TargetList and for each entry add a new entry to TargetRecord

And here is the "make a list" algo (as it applies to leveled list entries) which is also important to understand what's going on:

• for each entry, generate a string representation including: Level, Reference, Count, Item Condition, Owner, Owner Rank
  
• sort generated list of strings
  
• walking over the sorted list, add numbers to duplicated entries, so suppose you have a list: A, B, B, C, D, D after this step it will be A#0, B#0, B#1, C#0, D#0, D#1

=========
Mar 25 2009, 11:58 PM
I've just uploaded version 2.2.5 EXPERIMENTAL to http://fallout3nexus.com/downloads/file.php?id=637.

This version adds a very experimental implementation of list merging.

After FO3Edit has loaded, right right click into the left hand navigation treeview and select "Create Merged Patch". Then enter a new filename when asked.

After a couple of seconds you should see this newly added file in the navigation treeview.

Please review all records in this file very very closely and report any case where you think FO3Edit this something wrong (a screenshot would be helpful) and an exact description why you think it's wrong and what you would have expected to happen instead.

Currently the following record types and lists are processed:

	CheckGroup(GroupBySignature['LVLI'], 'Leveled List Entries');	CheckGroup(GroupBySignature['LVLC'], 'Leveled List Entries');	CheckGroup(GroupBySignature['LVLN'], 'Leveled List Entries');	CheckGroup(GroupBySignature['LVSP'], 'Leveled List Entries');	CheckGroup(GroupBySignature['CREA'], 'Items');	CheckGroup(GroupBySignature['NPC_'], 'Items');	CheckGroup(GroupBySignature['FACT'], 'Relations');

=========
Mar 23 2009, 04:58 AM
Version 2.2.3 has just been uploaded to http://fallout3nexus.com/downloads/file.php?id=637.

What's new?

• Game Settings (GMST) will now be properly resolved based on EditorID, not FormID.
  
• Navigation Mesh Info Map (NAVI) will no longer be compared between different modules. While this record has always the same FormID in all modules, it is not actually handled by the engine in the same way as normal records. Instead it contains information that are always only specific to the file that contains it.
  
• Navigation Mesh (NAVM) records that are logically identical but physically different are now easier to recognize.

That last point about the NAVMs requires some explanation.

A NAVM record starts off with a list of Vertices. Each Vertex being a 3D point (x/y/z). An identifier for each vertex is implicitly given by it's position in this list of verticies.

This is followed by a list of triangles. Again, an identifier for each triangle is implicitly given by it's position in this list of triangles.

For each triangle there are 3 verticies, specified by their position in the vertex list. And there are 3 triangles which touch this triangle along the 3 edges, specified by their position in the triangle list.

The edges are a bit more complex because it is possible that a triangle borders a triangle that is defined in another NAVM. To support this there are 3 flags on each triangle (for the 3 edges) which specify if the triangle on that edge is an external connection. If this flag is set, then the number stored for that edge is NOT an index into the triangle list, instead it's an index into the "External Connections" list.

Each entry in the External Connections list contains the FormID of another NAVM and the index for a triangle in the triangle list of that other NAVM.

GECK has the annoying habit of switching around the order of the entries in this External Connections list. As a result it is possible to have 2 versions of the same NAVM record that "look" different (the External Connections will not match up and the triangles with the index into the external connections list will not match up) but are actually identical.

I've implemented 2 changes:

• When comparing the values for triangle edges which have the "external" flag set, I don't compare the index number, instead the external connection entry is resolved using the index number and the NAVM FormID and the Triangle from that entry are compared. So even if the index numbers in the external connection list have changed, as long as they resolve to the same external triangle they will show up as identical.
  
• The complete external connections list has been marked as being "benign conflicts". This is not a problem if there are REAL relevant changes to this list because they will also show up in the triangles list where the relevant edges will now compare as a conflict or override.

With these changes in place it is now possible to find these NAVMs that are identical but not automatically found using the 'Remove "Identical to Master" Records' function by applying a filter and choosing "by conflict status overall" and only "Benign Conflict". It is still necessary to have a look at these records and make sure that they really fit this pattern (the only parts of these records that show up yellow should be the external connections) before deleting them manually. But it's a lot easier to find them now then it was before.

It's important to point out here that the interaction between the NAVMs and the NAVI record is so far poorly understood and I can't guarantee that removing NAVM records while leaving the NAVI record untouched is not going to cause problems. Any feedback/experience on this topic would be very welcome.

=========
Feb 23 2009, 10:46 PM
Version 2.2.0 has been uploaded to TESNexus.

This version contains no major new functionality, but a number of bugfixes. Update is highly recommended.

Dec 27 2008, 10:06 PM
I've just uploaded Version 2.1.0 BETA to http://tesnexus.com/downloads/file.php?id=11536.

What's new?

• Inplace Editors for Flags, Enums and FormIDs (MAJOR improvement)
  
• FormID of DIAL, WRLD and CELL records can now be changed
  
• Adding new DIAL, WRLD and CELL records is possible
  
• Using the FormID search box now adds a history entry
  
• When holding SHIFT while double clicking in the detail view editable elements can be edited
  
• FormID references to any value < 0x800 will no longer result in an error (The game engine defines objects with FormIDs < 0x800 implicitly in code)
  
• Insert and Delete Key are working in both navigation treeview and detail view (under the same conditions under which Add and Remove is available in the context menu)
  
• F2 is working on the navigation treeview and opens the "Change FormID" dialog
  
• Updated function list for CTDAs to include all functions available in CS.
  
• When setting/resetting the persistent flag on references in exterior cells the record is correctly moved between the main worldspace cell and the appropriate (based on position) grid cell
  
• Undeleting a record (removing the deleted flag) now copies all values from the master record and (in case of a reference record) correctly moves the record into the correct child group
  
• New function "Undelete and Disable References" finds all reference records marked as deleted and:
  • Undeletes it
    
  • Sets "Initially Disabled" flag
    
  • Sets Z Position to -30000
    
  • Removes Persistent flag if present (this makes sure that the Initially "Initially Disabled" flag and changed Z Position is not overridden by values already stored in the save game. Also makes sure that if the mod is uninstalled the object gets reset to vanilla position and enable state).
    
  • Removes the XESP (Enable Parent) subrecord (this is required to make sure that the "Initially Disabled" flag has any effect)
    
  • Removes the XTEL (Teleport/Door Portal) subrecord (this is required to prevent GECK/CS from complaining about references to non-persistent objects)
  
  
• Records in child groups (exterior CELLs in WRLDs, References in CELLs, INFOs in DIALs) now show an additional "virtual" field in the first row which specifies the Record that owns the child group they are contained in. This has 2 functions:
  • Records that are moved into a different owner (e.g. a Reference moved from a child worldspace into the parent worldspace) but without any changes to their contents will no longer be classified as "Identical to Master" as this virtual field takes part in normal conflict detection. This prevents problems where such records have been faultily removed by the "Remove "Identical to Master" Records" function
    
  • The virtual field is editable. This allows moving records to a different owner.
  
  
• Lots of small changes and enhancements all over the place that I've forgotten to write down ;)

=========
Mar 6 2008, 05:05 PM
Version 1.2.43 BETA has just been uploaded to TESNexus.

What's New?
* PluggyLink
** Thanks to OBSE, Pluggy and a great little script that Kyoma has written it is now possible to have TES4View running on one screen while playing on the other (if you have more then one screen) and automatically show you details about whatever you currently have in your crosshair
** You need to have OBSE 14a or newer installed
** You need to have Pluggy v45 or newer installed
** Place the TES4ViewLink.esp in your data folder and activate it, load order doesn't matter
** while the game is running you can use the following keys:
*** P - pauses/unpauses the logging
*** O - when pause, writes a single log entry of whatever you are looking at
*** Shift+O - Asks for a comment which will be stored togehter with the log entry
** the log files are stored in ...\My Documents\My Games\oblivion\Pluggy\User Files\
*** PluggyTES4ViewWorld.csv contains information about whatever is in your crosshair
*** PluggyTES4ViewInventory.csv contains information about all equipped items
*** PluggyTES4ViewSpells.csv contains information about the currently active spell
** When loading TES4View, make sure to load exactly the same mods in the same order as the game engine (which is standard if you just click ok...). After TES4View is fully loaded, right click on the line at the top that identifies the currently selected record. You will get a menu:
*** Reference - the REFR, ACHR or ACRE record that places whatever is in the crosshair in the game world. Automatically falls back to Base Object if the record is a savegame record (FormID starting with FF)
*** Base Object - the record that is referenced by the NAME subrecord of the REFR, ACHR or ACRE record under the crosshair
*** Inventory - the last equipped item
*** Enchantment - the enchantment of the last equipped item
*** Spell - the currently active spell
** With one of these options active, TES4View will automatically update the current record if a new entry is written into the appropriate log file by the script in TES4ViewLink.esp
* updated modgroups
* Fixed the placement and rotation of objects placed through a script
* New script which contains the so far confirmed window placements. Thanks Leandro Conde and DuggeDank !!!

=========
Mar 2 2008, 10:38 AM
Version 1.2.42 BETA has just been uploaded to TESNexus

* Certain comparisons that should have been case sensitive where case insensitive
* DistantLOD generation for Trees should work better (please give feedback on this!)
* New option when applying filters: "Assign Persistent Worldspace Children to Cell"
** Requires that "Flatten Cell Children" is also active
** sorts the persistent references from the worldspace cell into the individual grid cells
* New menu entry on the navigation treeview: "Check for circular leveled lists".
** Checks all leveled lists for circular references, taking into account the winning records of all currently loaded mods

=========
Feb 24 2008, 03:07 PM
Version 1.2.41 BETA has just been uploaded to TESNexus

What's new?
- the scripting system introduced in 1.2.40 has been cleaned up
-- should run noticeable faster
-- using the "Apply Script into...." function will now show a selection dialog where one or more scripts can be selected. The available scripts come from 2 sources:
--- In the data path: any file that starts with the same name as one of the loaded modules and has the tes4editscript extension
--- In the program path (where TES4View.exe is): any file with the extension tes4editscript
- When starting the program with the -FixUpPGRD command line switch an additional case is handled: duplicated inter-cell connection entries are filtered.
- The apply filter dialog has 2 new options:
-- Flatten Blocks/Sub-Blocks: hides the 2 nested levels of block and sub-block groups and shows all cells together in the Cell top level group and under Worldspace records
-- Flatten Cell Children: hides the separation of Cell children into persistent/temporary/VWD groups
- Map Marker REFR's now have the Name of the Map Marker in the Name column of the navigation treeview.

=========
Feb 19 2008, 08:53 AM
Version 1.2.38/1.2.39 BETA has just been uploaded to TESNexus.

It's contains a fix for the problem described here: http://www.gamesas.com/bgsforums/index.ph...&p=11794453

EDIT: There were still some issues left which are now fixed in 1.2.39.

=========
Feb 18 2008, 03:36 PM
Version 1.2.37 BETA has just been uploaded to TESNexus.

What's new?
- updated modgroups
- new option on the navigation treeview: "Generate Object LOD":
-- make sure you have exactly the mods loaded that you start the game with and in the same order! If any mods get added/removed or their load order changed you will need to run this function again.
-- select one or more mods, this selection is only used to search through the selected mods for populating the worldspace selection list
-- context menu on the navigation treeview: "Generate Object LOD"
-- select the worldspaces that you want to generate DistantLOD for, it should be no problem to just "select all" (in context menu on the selection dialog)
-- wait till it's done

"Generate Object LOD" will directly create the required .lod files in the Data\DistantLOD folder.
lod data will be generated for all references for which a _far.nif exist. The VWD flag is no longer used!
The generated LOD data will be tailor made for your specific setup. As the .lod files include load order corrected FormIDs you need to regenerate the LOD data every time after you added, removed or changed the load order of any mod.

To best use this feature I recommend the following:

Download either Almost Everything VWD or Almost Everything VWD large. Install the included meshes and textures, but not the DistantLOD folder (it's going to be regenerated by the steps given above).

The difference between the 2 is that the "large" version includes somewhat larger (but still smaller) textures as the normal version. If you have enough VRAM I would recommend the large version.

=========
Feb 17 2008, 09:20 AM
Version 1.2.35 BETA has just been uploaded to TESNexus.

What's new?
- Support for BSA archives. Will automatically load the bsa's referenced in oblivion.ini and belonging to any .esp you're loading
- New filter option: "has visible when distant mesh" (which correctly searches through the relevant bsa's and data folder). Together with the normal "Visible When Distant" filter you can now easily see:
-- All REFRs with "Visible When Distant" turned on for which no _far.nif exists
-- All REFRs that are not "Visible When Distant" but for which a _far.nif exists.
- New option in the navitigation treeview context menu: "Set VWD for all REFR with VWD Mesh in this file" This will automatically turn on VWD for all exterior REFRs for which a _far nif exists.
- New option in the navitigation treeview context menu: "Set VWD for all REFR with VWD Mesh as override into...." similar like the one above, but will instead write overriding REFR records into a new file, generating a patch esp.

With that last option you can then do the following:
- start TES4Edit with all your mods loaded like you normally play
- multiselect all files and generate a new VWD.esp which turns on VWD for everything for which you got _far.nif's
- start TESCS, load all your usually active mods + VWD.esp (ignore any errors, we are not going to save any esp's).
- generate the LOD files for whatever worldspace(s) you want
- delete the VWD.esp (no longer required)
- play

Which should give you the maximum possible VWD depending on the _far nif's you have installed. correctly taking into account any addition/delete/movement of references by any of your mods.

=========
Feb 16 2008, 07:57 AM
Version 1.2.34 BETA has just been uploaded to TESNexus.

What's new?
- fixed a bug in the new 'Remove "Identical to Master" Records' function that could leave empty cell children groups behind
- greatly extended filter options:
-- by persistence, only keeps either temporary or persistent REFR/ACRE/ACHR records inside CELLs.
--- only possible unnecessary persistent: keeps only persistent REFR which don't need to be persistent
---- only if master is not persistent: further limits it to records that have a master and where the master is not persistent
---- or if it's the master also shows unnecessary persistent records if they don't have a master (but not the ones that have a master which is marked as persistent)
--- only if position/rotation was changed: helps tracking down any moved persistent references. **It's necessary to create scripts updating the position for all of these as the old position might already have been stored in the save game**
-- by Visible When Distant: only keeps REFRs that are VWD / not VWD
-- by Record Signature: only keeps records with specific Signatures, e.g. if you are only interested in conflicting LAND records
-- by Base Record Signature: only keeps REFR/ACRE/ACHR records that reference a record with a specific Signature, e.g. if you want to find all lights that are placed somewhere
-- by Base Record Editor ID: only keeps REFR/ACRE/ACHR records that reference a record which contains the specified text in it's EditorID (e.g. if you are searching for "Rock"'s)
-- by Base Record Name: same as above, just for the Name

=========
Feb 15 2008, 03:34 PM
Version 1.2.33 BETA has just been uploaded to TESNexus

What's new?
- new option in context menu of navigation treeview: Remove "Identical to Master" records
- EditorID and Name filters are now case insensitive
- new options in context menu of referenced by tab: (Deep) Copy as override/new record into
- solution for the PGRD problem described in this post: http://www.gamesas.com/bgsforums/index.ph...;#entry11763738
-- because this significantly increases the time to apply filter if many PGRD records are present it needs to be specifically activate:
-- start TES4Edit with -FixupPGRD as additional parameter
- fixes minor issue with ENCH records where some mods could contain an unexpected FULL subrecord

As always, approach with caution, report all irregularities, keep your backups :)

=========
Feb 14 2008, 04:41 PM
Version 1.2.32 BETA has just been uploaded to TESNexus.

What's new?
- When applying a filter it's now possible to filter on EditorID and Name
- much better handling when using "Copy as override into" between 2 mods with the same load order (after using "Compare To")
- Visible when distant can be changed for REFR records:
-- via the context menu of the navigation treeview on the left (multiselect is supported)
-- via the context menu on the "referenced by" tab (multiselect is supported)

As always, while the the new functions have been tested, there is always room for something to go wrong. Please keep your eyes open and report any problems.

=========
Feb 9 2008, 12:58 PM
Version 1.2.31 has just been uploaded to TESNexus. For changes see below:

The new version now allows "copy as override into" on all records in the Cell and Worldspace trees.

It also now distinguishes between "copy as override into" and "deep copy as override into". Depending on which specific record you have selected you may get either or both options.

The difference is:
"copy as override into" on a CELL record will just copy that single CELL record
"deep copy as override into" will copy that CELL record and all the LAND, PGRD, REFR, ACRE, ACHR, ... records that might be contained in it's child groups.
(The same applies to WRLD records)

Please test this throughly and let me know if there are any problems!

One great side effect of these changes is that the "cleanup references to injected records" is now working for everything in the Cell and Worldspace tree as well!

That means it's now trivial to completely and properly fix OOO. Specifically, the presence of references to records injected by the esp into the esm in the esm meant that you can't load ooo.esm in TESCS without also loading the ooo.esp or you got a while load of errors thrown at you. That meant it was impossible to edit another esp which depends on ooo.esm in TESCS without loading the ooo.esp as well which messes up the FormIDs written by TESCS into that other esp.

To fix OOO (takes less then 5 minutes) please follow these steps:
* Start TES4Edit with only oblivion.esm, ooo.esm and ooo.esp loaded (right click "select none", then check just ooo.esp, ok... the others will be implicitly loaded)
* apply filter, filter only "by references inject status" and "only references injected"
* you will now see all the records in ooo.esp that contain references to records injected by ooo.esp
** go through the treeview, right click on the records and select "cleanup references to injected records". This will automatically fix the problem by doing a "copy as override into" from the esm to the esp and then removing the parts of the record in the esm which references injected records from the esp.
** outside the Cell tree you can easily just multiselect all the records in each group

There are a couple of AI Package records which are not detected as referencing injected records but which still make a problem when ooo.esm is loaded alone in TESCS. The reason for that is that these records reference REFR records which exist in the esm, but are marked as temporary references and are then overridden by versions in the esp where they are marked as persistent references. The records in question are:

OOOPilgPrayDiBella3
OOOPilgPrayDiBella1
OOOPilgPrayArkay1
OOOPilgArkay1
OOOPilgKynareth3
OOOPilgDiBella3
OOOPilgDiBella1
OOOPilgPrayMara3
OOOPilgPrayKynareth3

To fix these:
* cancel filter
* Oscuro's_Oblivion_Overhaul.esm \ AI Package \ ... and look at each of these records, for each:
** copy as override into... ooo.esp
** right click on the "location" line for teh esm and select "Remove
** right click on the "conditions" line for the esm and select "Remove"
** right click on the "target" line for the esm and select "Remove"

QUOTE(dev_akm @ Feb 6 2008, 08:36 AM) *
I'd also really like to see more descriptive ref names in cells, especially for LVLC refs. I frequently use TES4Edit to debug spawn-related problem reports and it's not very easy to tell what's going on in a cell with just a ton of generic "Placed Object" entries listed. I usually end up comparing a large group and then scrolling through the list that way, so it would be a huge help if I could see the type of placed object.
ENDQUOTE

The "Name" column in the left hand treeview now shows the name of the referenced base record for REFR, ACHR and ACRE records.

QUOTE(dev_akm @ Feb 6 2008, 08:36 AM) *
Very minor request: is there any way to improve the editing of record flags like "Quest Object" and the NPC/creature bitwise settings?
ENDQUOTE

I can't easily let you edit the record flags currently. But for all other flag fields you can now right click on them, select "Edit" and you get a dialog with checkboxes where you can select the flags you want.

=========
Feb 1 2008, 06:09 AM
Version 1.2.30 has been released on TESNexus.

When started as TES4Edit it implements the "Batch Change Referencing Records" function that Wrye asked for: http://www.gamesas.com/bgsforums/index.ph...&p=11685987
(It can be found in the context menu of file nodes in the treeview on the left side.) It hasn't been extensively tested yet, so please let me know if there are any problems with it.

=========
Oct 8 2007, 11:26 AM
1.2.29 BETA has been uploaded which no longer sorts effect subrecords

=========
Sep 26 2007, 06:29 PM
I've just uploaded 1.2.28 BETA which should fix the problem reported here: http://www.gamesas.com/bgsforums/index.ph...&p=11007233
QUOTE (Wrye @ Sep 26 2007, 03:52 PM) *
Loading: 00015B93..CreatureHorsePaint..CREA.SNAM..5..

Bash is loading record with formid 00015b93, editor id "CreatureHorsePaint" of type CREA. Specifically, it's looking at the SNAM subrecord which is of length 5 (bytes).

SNAMs for CREA's are faction subrecords. They should be of length 8. The problem is that Tes4Edit is writing them as 5 byte records. The other incident that you cite is similar -- it's the SNAM record for an NPC -- again a faction subrecord, same length problem.

Solution: First trying loading the mod in TESCS and resaving. Hopefully TESCS can read it. If so, it will probably save in the right format.

Second Solution: Bug Elminster. He's even more retired than me, but he'll probably fix a simple bug like this.

FYI, the missing three bytes are (AFAIK) junk bytes. Still, they should be there. They might not be junk -- and besides its best if we (toolmakers) all stick to the same format anyway.
ENDQUOTE

=========
Aug 5 2007, 06:46 PM
1.2.27 has been uploaded.

- ammo spreadsheet should work again
- fixed bug which sometimes caused AVs when deleting records via the context menu of the header in the view tab
- the window for viewing long texts has now scroll bars and is no longer modal

=========
Aug 3 2007, 10:43 PM
1.2.26 BETA has been uploaded

- fix for "Assertion failure (P:\TES4Workbench\Context.pas, line 5826)"
- navigation treeview header has popup menu to control sorting of file nodes
- view treeview popup menu has 2 new options: move up / move down. These are only available for nodes which are contained in an unsorted array (e.g. AI Packages in NPCs). Such nodes can also be moved up/down by holding the CTRL key and pressing up or down.

=========
Jul 22 2007, 06:47 AM
1.2.25 BETA has been uploaded.

!!! This is an important bug fix release !!!

All versions before 1.2.25 sorted AI Packages in CREA and NPC_ records by FormID. As the order of the AI Packages is important (they are evaluated in the given order and the first matching one is used) that can lead to numerous problems. 1.2.25 now shows and saves AI Packages without changing the order.

There are also a few new things:
- on the view tab, fields which contain a reference to an injected record are displayed in italic.
- in the navigation treeview, records which contain any references to injected records are underlined (and now I'm out of ways to change the text style...)
- when filtering it's possible to filter on "by references injected status"
- in the navigation treeview a new option "Cleanup references to injected records" is available if the current record contains references to injected records (multiselect is supported)

"Cleanup references to injected records" first performs a "Copy as override into..." the file from which the injected records originate. Then the parts which reference the injected records are removed/changed in the selected record.

What's all this good for?

If you e.g. try to open CS with OOO.esm as it's currently included in 1.32 RC3 you'll get a whole bunch of error messages because OOO.esm contains records which have references to records that OOO.esp injects into it. With the functions added to TES4Edit it's now possible to clean up OOO.esm to the point where it's possible to use it as master without loading OOO.esp without getting any error messages.

=========
Jul 19 2007, 09:38 PM
1.2.23 has just been uploaded.

- the context menu of the navigation treeview has a new option: "build reachable info"
This will first automatically build the referenced by information for all files and the determines for each record if it's reachable by the player using "normal means". To determine this it starts at all quests which are marked as "start game enabled". These are per definition always reachable. Everything that's referenced from these quest (which includes the chargen quest which contains a script which references the cell where the player is placed at the start of a new game) is reachable and it just continues recursive from there. Everything that's referenced by something reachable is in turn also reachable. It takes correctly into account that if something that's placed in a cell is reachable the cell itself is reachable and everything it contains. If the cell is an exterior cell then it means that the containing worldspace is reachable which means that all contained cells are reachable. Only the most current version of each record is taken into consideration. So e.g. if an active mod has changed a vanila leveled list by removing a creature which was the only way how that specific creature could be placed in a reachable cell then the creature record will now be marked as unreachable.
- once the reachable info has been build unreachable records will be displayed striked out
- reachable state is inherited by parent when filtering (so if a file or group contains any unreachable data it will be shows striked out)
- once the reachable info has been build it's possible to filter by reachable status (conflicts in unreachable records don't really matter).

As the only way to get into a cell without using the console would be following a portal or by being transported using a script and both would require to reference something in that cell the unreachable detection is very reliable. Naturally it's possible to reach pretty much any place by using the console. But everything the reachable detection says it's unreachable should be impossible to reach by normal means from the cell where the character generation leaves the character when a new game is started.

=========
Jul 19 2007, 02:56 PM
1.2.22 has been uploaded.

!!! This is an important bugfix release !!!

1.2.21 and older versions did under certain circumstances not write a terminating #0 for arrays of variable length strings (meaning NIFZ and KFFZ subrecords).
This is not visisble in TES4Edit and such files can without problem be loaded in again by any version of TES4Edit. It could only happen if you actually modified the subrecord (or if it was newly created by using the "Copy as ... " function). When loading such a file in CS and saving it again it is possible for CS to add an additional string with a couple of random chars to the list (and then add the #0 terminator correctly). If that has already happend you can just delete the random string with this new version of TESEdit. From this version on, when a file is saved, all such arrays are checked for the presence of the correct terminator and if required it is added, even for subrecords which weren't explicitly modified. So if CS hasn't mangled the field yet it's enough to resave the files with this new version to fix the issue.

This version also has 2 minor additions:
- if an injected record is modified it's always considered a critical conflict
- in the view tab the column for the record which is currently selected in the navigation treeview is shaded slightly darker

=========
Jul 18 2007, 06:44 PM
1.2.21 has been uploaded.

Only a few changes this time:
- when selecting modules in the first selection list, if you forget to select any masters they will be implicitly added (so e.g. selecting just MMM for FCOM.esp will automatically load Oblivion.esm, Fran.esm, OOO.esm, MMM.esm as well)
- in the view tab, when a row contains references to multiple different records (e.g. the combat style row or script row for NPCs and creatures if different versions of the record assign different combat styles or scripts) you get a new option in the context menu: "compare referenced records in this row". This has the same effect as if you hunted down all the different records in the navigation treeview, selected them all and used "compare selected".

=========
Jul 18 2007, 08:20 AM
I've uploaded 1.2.20 BETA.

This contains an important bugfix for TES4Edit

1.2.19 broke drag'n'drop and the different "copy as .. into" functions for certain types of fields. If you are using TES4Edit I would highly recommend to update.

There is one new function in this:

In the nav treeview and on the view tab header you will get an additional "Hidden" menu entry. This is a toggle, selecting it once and you will see a check mark in front of it, select it again and the check mark is gone again. It's possible to hide single records, whole groups or even whole files this way. The hidden state is inherited from file to group to records (but if e.g. the file is marked as hidden the check mark won't show up if you have just selected a single record in that file, neither can you "unhide" a single record if the file or group it's contained in is hidden).

What are the effects of "hiding" records?

When TES4View determines which records to show in the view tab (and also internally when creating the conflict information visible in the navigation treeview) it follows these steps:

1) get the record master and all overrides and put them in a list by sort order
2) apply all active mod groups, removing records from the list as appropiate
3) while the list has at least 1 entry, starting from the beginning, remove all records which are marked as hidden

The final list is what you will see in the view tab and what is used to generate the conflict information that the colors in the navigation treeview and filtering is based on.

What's it good for?

Suppose you want to compare MMM.esm and MMM for FCOM.esp. You need to have at least Oblivion.esm, Fran.esm and OOO.esm loaded in addtion to these 2 for TES4Edit to start. But you are not interested in any conflicts or differences between the 2 MMM files and the other files. You can simply mark the other files as hidden and can concentrate on comparing the differences between the 2 files you actually want to compare instead.

=========
Jul 17 2007, 06:18 PM
1.2.19 BETA has just been uploaded.

- columns can now be resized down to 5 pixes even when using "Compare Selected"
- the "hide no conflict rows" setting is now remembered between sessions
- on the view tab there is now a new context menu item "Column Widths" with 3 sub items:
* standard
* fit all
* fit text
The setting here is remembered between sessions and is applied when the selected record is changed. If fit all is selected then any resizing of the tab view (e.g. resizing of the application or showing/hiding of the navigation treeview) will update the column widths to always use all available space and keep all records visible.
- while the focus is on the view tab it is possible to navigate through the navigation treeview using ALT + cursor keys. This is also working if the navigation treeview has been hidden.
- when you are on the "Referenced by" tab and navigate between records which are referenced by others the referenced by tab will stay the active tab
- when jumping to a record from the referenced by tab and then using "back" you will end up on the referenced by tab again, not on the view tab
- When multiple records are selected the "Change FormID" function on the navigation treeview will work a bit different. Instead of asking for the new FormID it is asking for the load order number of a file (with the load order of the file that contains the selected records being the standard value). The FormID of all selected records will then be changed to a FormID starting with this load order. New, unused, FormIDs are allocated in the namespace of that particular file. All records that referenced the old FormID are automatically updated. This works very well to change unneccesarily injected records.
- All records which are being injected (having a FormID specifying a different file then the one that contains the record as the one the record belongs to, but there not being a record with that FormID in that file) are now shown with italic text in the navigation treeview.
- it is possible to filter by injection status to see only records which are injected or only records which are not injected
- injection status is inherited together with conflict status when filtering
- when a file node is selected it's possible to "sort masters" or "clean masters"
* "sort masters" will sort the masters in the same order as their global load order (all affected FormIDs in the file are correctly updated)
* "clean masters" will determine if there are any currently listed masters which are never referenced in any way inside the file and remove them from the master list

=========
Jul 16 2007, 07:12 PM
1.2.18 has been uploaded.

- view tab has a new menu item: "Hide no conflict rows". Does exactly what it says (it's a toggle switch, the setting is remembered as you move from record to record)
- column in the view tab can now be resized down to 5 pixels
- left click on the first column (the one with the row titles) header resizes all other columns to fit on the current screen
- rigth click on the first column (the one with the row titles) header resizes all other columns to fit the text they contain (same as double clicking each column separator)
- SHIFT + left click on the first column (the one with the row titles) header resizes all other columns back to the standard width of 200 pixels.
- holding SHIFT while resizing a column applies the same resize to all columns
- right clicking on the splitter between navigation treeview and view tab hides the navigation treeview. clicking on it again (it's now at the left side of the screen) makes the navigation treeview visible again
- the view treeview will now autoscroll during drag'n'drop operations.

=========
Jul 15 2007, 06:16 PM
1.2.16 BETA has just been uploaded.

There are a couple more changes besides the small stuff listed in the posts above:

- you can now save at any time by pressing CTRL + S. The files will be saved as "*.es?.save.yyyy_mm_dd_hh_nn_ss". If TES4Edit is normally closed they will be renamed to *.es? and the original file will be renamed to "*.es?.backup.yyyy_mm_dd_hh_nn_ss" like it's already happening. If for whatever reason TES4Edit isn't closed correctly you can always rename the .save. file by hand.
- if you have any unsaved changed that are older then 5 minutes you will get a dialog box reminding you that it would be good to save your changes (additional saves create additional files, so you don't need to worry that you can't go back. save often.)

- if you are using "Compare Selected" then in addition to "Remove" you will be offered "Remove from selected records" in the view context menu. "Remove from selected records" is the same is if you would be clicking on each cell in that row and if you have the remove menu item available click it.

- when using "Compare Selected" the text color will now be based on comparisons of cell values against the currently focused record. So as you move the focus between records you can very easily see which other records have the same or different values then the currently focused record.

- in the view and spreadsheet tabs the currently focused row is shaded a bit darker
- in the view tab columns can be resized to optimal width by double clicking on the resize line in the header (that was already and still is working in the spreadsheet tabs)

- as always, whatever else I forgot wink.gif

EDIT: *arg* last change added a bug.. I pulled 1.2.16 and will upload 1.2.17 in a couple of minutes...
EDIT2: ok.. 1.2.17 is up

=========
Jul 14 2007, 06:21 PM
1.2.15 has just been uploaded. It contains numerous important bug fixes in regards to copying records, drag'n'drop, writing files, ... highly recommended update.

- when multiple records are selected in the navigation treeview there is new option on the context menu: compare selected. This will display the selected records side by side.
- when comparing records in that way a double click on the row title in the first column will sort the displayed records by that row
- same function is available via the popup menu entry "sort" in the view tab.
- naturally it's possible to CTRL + click jump to referenced records, the back function restores the comparison view.
- batch editing: when multiple records are selected in the navigation tree view (no matter if compare selected was used or not) it's possible to click on any cell in the view tab and select "copy to selected records". This will copy that field to all selected records (you get a selection dialog where you can remove records from the selection, but by default they are all selected). If the field has sub fields (e.g. you selected a cell in the the "ACBS - Configuration" row for an NPC) then all these fields will be copied (just like drag'n'drop).

=========
Jul 13 2007, 08:08 PM
1.2.13 BETA was just uploaded.

This is a big one. Pretty good chance I've broken something, so keep your eyes open and report anything that's strange.

All these changes should only apply to TES4Edit, not TES4View:

- Oblivion.esm can no longer be edited
- it's not possible to select records to be skipped anymore
- building reference information for all files except oblivion.esm is mandetory and is done by the background loader on startup (oblivion.esm can still be build manually later if you need/want it)

- file nodes have a "add masters" menu item (which correctly updates all FormIDs in the file to take the added master into account)
- file nodes have a "add" submenu allowing adding of missing top level groups (except CELL, WRLD, DIAL)
- top level groups have a "add" submenu allowing adding of new records

- when using drag and drop and the target file is missing required masters it will be offered to automatically add the required masters
- in the view tab, the column headers have a popup menu with
* copy as override into...
* copy as new record into...
* remove

The copy menu items will show a dialog with all files that this record could possibly be added to (taking into account where it already exists and if the required masters can be added to the file or not). It also offers a "new file" option which will ask for a filename and add creates a new plugin file. The "as override" adds the file with a FormID that makes it an override record of the existing one. The "as new record" option will generate a new FormID in the file that the record is copied to. For "as new record" you will be asked for a different EditorID.

These 2 copy options are also available on the left side navigation treeview, including support for multiselect and selecting complete groups. If multiple nodes are selected and/or a group is selected you will be asked for a prefix/suffix for the EditorID instead of a specific EditorID.

If the record is a leveled list (creature, item or spell) you get an additional option: "copy as wrapper into". What this does is best explained by an example:

Before:
CODE
LL1Wolfs100
1 1 Wolf1
1 1 Wolf2
1 1 Wolf3
...

After:
CODE
LL1Wolfs100
1 1 LL1Wolfs100New ---> LL1Wolfs100New
1 1 Wolf1
1 1 Wolf2
1 1 Wolf3
...


- everything I've forgotten once more wink.gif

EDIT: I've just noticed a few small bugs that slipped through and will update 1.2.14 soon
EDIT2: 1.2.14 uploading.. sorry 'bout that

=========
Jul 11 2007, 03:47 PM
1.2.11 BETA is uploaded.

** Contains important fixes to how CELL and PGRD records are written **

The main focus of this version is the Spreadsheet mode.

There are now 3 Spreadsheet tabs:
- Weapon
- Armor
- Ammunition

Now the changes:
- The navigation treeview is hidden while on a spreadsheet tab
- The file selection dialog when first selecting one of these tabs remembers the last selection now.
- If you switch to another tab and back you don't get the file selection dialog again, but there is a context menu on the spreadsheet tree where you can select "rebuild" to get the file selection dialog again
- Spreadsheet shows Enchantment if any
- holding SHIFT while moving the mouse over a field which is only partially visible will show a tooltip with the full text
- holding CTRL while moving the mouse over a field which links somewhere (the FormID or Enchantment columns) will show the text in that cell as hyperlink, clicking on it goes to that record. Getting back to the spreadsheet tab is easy via the Back button in the upper right corner or via the back button on your mouse (if you have one with 5 buttons)
- drag'n'drop is now supported
- incremental search is now supported (searches in the currently focused column, simply start typing)
- text in numeric columns is properly right aligned

EDIT: oops... just uploaded 1.2.12... there was a bunch of debug code left that shouldn't have been there...

=========
Jul 10 2007, 07:57 PM
1.2.10 BETA has been uploaded.

It includes the spreadsheet mode that dev_akm asked for: http://www.gamesas.com/bgsforums/index.ph...&p=10488787

- wait till the background loader is finished
- click on the spreadsheet tab
- select which modules should be represented there
- edit as much as you wish

right now it's hardcoded for weapons and a specific set of columns... I'll make that configurable in the future

EDIT: oh.. and the error message if the load order is wrong has been improved

=========
Jul 10 2007, 04:04 PM
1.2.9 BETA has just been uploaded, this is mainly a bug fix release.

- lots of small fixes to how field values are read and written
- deleting records with empty child groups will correctly delete the group
- on writing the record count in the header is correctly updated

But there are also a couple of small additions:

- navigation treeview allows multi select for "Remove".
- referenced by list allows double click to directly jump to that record
- context menu for file nodes in the navigation list has a "compare to" entry.

How does the Compare To function work?

The selected file:
- can not yet have been loaded
- is loaded with the same load order as the file you are comparing to
- has the file you are comparing to added to it's master list.

By adding (just in memory) the first file to the master list of the 2nd all the FormIDs in the 2nd file which would normally indicate that a record is a new record in that file is now interpreted as a record that overrides a master record in the first file.

That's it.

=========
Jul 8 2007, 11:08 AM
Version 1.2.8 BETA has just been uploaded.

For TES4Edit/TES4View there is just one small fix: Flags are now correctly aligned.

Big news is: There is a 3rd mode now. TES4Trans. Just rename the exe to TES4Trans.exe to get there.

In TES4Trans mode only translateable fields are shown and editing is limited to just editing (no adding, no removing) existing translateable string fields. This makes it very easy to take a mod and translate it into another language. Also, all cases where the mod should contain records from Oblivion.esm where translateable strings are different (e.g. mod was created with a German version of Oblivion, all the cell names will be in german in that mod) will now show up as overrides and can be quickly fixed.

EDIT: There is also a new conflict classification (only of interest in translation mode) "Not Defined". With that you can filter out (or see) all records which could contain a translateable string but don't.

=========
Jul 7 2007, 06:11 PM
1.2.7 has just been uploaded.

What's new?

- couple of bug fixes here and there
- TES4Edit can remove complete records (needs testing)
- quite a few usability enhancements:
* navigation treeview allows incremental search (just try to type the name of one of the files to see what I mean)
* navigation treeview will automatically use space in following columns if they are empty (you should see the effect quite well directly after load already, the file names are no longer cut off)
* for any text that still gets cut off there are tool tips available (just move the mouse over a cut off text to see the effect)
* at the top of the window the full path to the currently selected node is displayed. No more searching through the treeview to figure out in which worldspace / block / sub-block / cell /... you currently are
* view treeview also supports tooltips for cut off text, only active while you hold down the shift key (to prevent interfering with drag'n'drop and the next function)
* "follow reference". Suppose you are looking at a creature record and you see that 3 different mods set 3 different scripts for this creature. You could either write down the FormIDs and then go hunting around to track down the 3 scripts. Or you can hold down the Ctrl key and click on the first and be directly taken there. When you are done looking you can simply click on the "go back" button at upper right corner of the window. Or if you have a mouse with 5 buttons the first extra button will do the "go back" (it's the one that with microsoft mice are usually mapped to "go back" in your web browser).
- whatever else I forgot about already

=========
Jul 6 2007, 08:34 PM
I've just uploaded 1.2.6 BETA. Given the huge amount of internal changes I've done I need some feedback if I've broken anything essential.

Visible changes are:
- more conflict categories
- changed order of conflict categories
- View window uses a lighter shaded background to indicate fields that are not contained in that module (as opposed to fields which just have an empty string as text)
- memory usage should be better optimized
- filtering might be faster (or not, need feedback here!)
- building reference information should be a lot faster and is now done via it's own menu entry with possibility to select which mods to include
- everything else I forgot.. have a look around

TES4View is also TES4Edit!

Start it with -edit as parameter or just rename the exe to TES4Edit.exe to get TES4Edit.

TES4Edit is far from finished, but you can have a look at what's there already. Mainly that's the ability to edit existing records in any way imaginable.

Editing is done using:
- context menu: Add/Remove/Edit (menu items depend on which node you are on)
- F2 on a field or slow(!) double click
- drag'n'drop (that's really slick)

You don't have to worry that it will mess up your files. TES4Edit never ever opens existing files in write mode. All changes are kept in memory. When you close it you will get a list of changed files and can select which ones to save.

Saving works like this:
1) save new file, e.g. test.esp.new
2) rename existing file to (e.g.) test.esp.backup.yyyy_mm_dd_hh_nn_ss
3) rename test.esp.new to test.esp and set the same file date/time that the original test.esp had

so it's absolutely impossible that TES4Edit overwrites your existing files, they are never ever opened in write mode. Worst case if the first 2 steps succeed and the 3rd rename fails you'll have to rename the backup back by hand.

=========

Run FO3Edit, apply a filter with only the following options:

• by conflict status overall
  • Conflict
    
  • Critical Conflict
  
  
• Conflict status inherited by parent

Once you waited for the filter to finish:

• have a look at all conflicting records
  
• understand what the intentions of the change
  
• understand what the consequences are from the currently last loaded override being the only one the game engine will see
  
• decide which one should be the winning override and modify your load order accordingly
  
• if non of the record version, if being the winning override, would result in a satisfactory result, create a patch plugin using:
  • copy as override into...
    
  • drag'n'drop to manually merge the required changes

When FO3Edit/FO3MasterUpdate saves a file, it first writes a new file with .es?.save. as extension.

When you then close the program (and in case of FO3MasterUpdate, only if there weren't any errors when saving any of the files) then the existing original module files are renamed to .es?.backup. and the newest .es?.save. file for each module is renamed to .es?

I checked the OP for instructions on how to reverse FO3MasterUpdate... how is it done?

Preferably, restore the backup you made before running FO3MasterUpdate for the first time.

Alternatively, run FO3MasterRestore

How do I apply a filter?

When I first launch FO3Edit I'm greeted with a Master/Plugin Selection, I press OK to that. It then does its thing, then when it's done it says "Background loader: finished". I'm not sure where to go from here.

that would be right click and apply filter on the left hand column that lists your mods

also just to anyone who knows is it advisable to "clean" the DLC, so either undelete refs or remove identical edits, so either or both. as i know it was advisable in oblivion, however they are now esms if that makes a difference?

and quickly having at go at broken steel gives some interesting results as either edit seems to delete all but the door and one piece of fencing of the rockland car tunnel

so anyone had similar or was it just me? and should i therefore not clean them at all

thanks very much

Alright, I ran the filter. Unchecked everything except what you said to keep checked, but I'm not sure what to make of the results.

Here's what came up on the left side - http://img196.imageshack.us/img196/6141/fo3edit1.jpg

If that doesn't help, I still got FO3Edit up with all the text, I went through all of it but I don't know what to make of it.

I'm sorry to have to ask what I suspect is probably a stupid question, but I really cannot figure out what's going wrong here, so my apologies in advance if this is a PEBKAC.

Basically my porblem is


This is not happening for me (although it used to, apparently I've mucked something up between 2.3.X and my current 2.4.1). When I load the ESP I've been working with, which depends on 2 ESMs (Fallout3 of course, and BHRM--Bobblehead Remove and Move), neither the ESP, nor the additional ESM, which I've also explicitly loaded, show their entire catalog of entries, and a goodly portion of those that are shown are in "flat black" (black text on a plain background). The "flat black" entries do not show their data when selected (the columns are empty).

I have tried removing filters (although I hadn't explicitly applied any), reapplying filters with different settings, re-applying filters with no settings, and none of it has caused FO3 Edit to revert to its former behaviour of showing me everything until I tell it to filter some of the extraneous information out.

What have I done wrong and what can I do to fix it? I was just starting to get the hang of FO3Edit, or so I thought.... please help .

in the right hand view box, right click and make sure "hide no conflict rows" is unchecked

My hero! Thank you so much for the assist (it worked, of course )!

Don't do that. A friend of mine who purchased the DLCs has been having trouble with missing landscape and all sorts of stuff ever since buying them. Even after installing the 1.5 patch. I finally had time enough to drop by his place and run through some things and after pulling my hair out for hours and hours, and going through a complete reinstall of the game TWICE he finally informs me that he cleaned the DLC files shortly after installing them. Well, as it turns out, putting back the unmodified files ( after I made HIM hassle with getting the downloads back again ) solved the problems with missing landscape at the Anchorage building that was added down by the Red Racer Toy Factory. So just to confirm - I grabbed FO3Edit 2.4.3 and cleaned Anchorage again. Went back, and sure enough, the landscape and new statics that should have been there were missing. So don't clean the DLCs for identical to master records, Bad Things™ result from it. I didn't have time to hang around to see if The Pitt was fixed or not, but I'm assuming restoring the unmodified files for that will fix it too. He hasn't completed the MQ so I don't know if Broken Steel works or not, but he did get a notification that the level cap was raised which wasn't coming up before. So who knows.

Long story short. DO NOT CLEAN THE DLCs.

thanks very much Arthmoor just wanted to make sure it wasnt only me

How many mods can F03Edit load? I can't seem to get but just half of my mods loaded at one time. I have over 170 mod to edit am I missing something or doing something wrong? Is there a tut on this program anywhere?

I'm also looking for a guide to merging mods with Fo3edit. But my original reason for posting in this thread is, with the MasterUpdate function, can I use this if I have lots of mods (esp and esm files) installed and have never done the MasterUpdate before? Or does it have to be started with a fresh game install and then performed one mod at a time? Hopefully my question makes sense. Thanks for any help. I use 1.0.15 and the Unofficial and Fake Patches.

I just wanted to say thanks.
Master Update allows my mod to work with 1.5.
Thats a lot of work to get shot down by a patch.

256, one more then the game engine itself.

There is no problem running FO3MasterUpdate with a large number of mods. If you currently have a large setup that works correctly under pre-1.5, you can just run FO3MasterUpdate on it, patch to 1.5, remove the fake patch if you use it, and everything should work.

After I run FO3Edit, and after filtering and all that, if there's nothing on the left side, does that mean my load order is fine?

Assuming you applied a filter following the settings I listed above, this means that there are no direct conflicts (a records, defined by at least 3 modules, with the winning override not containing all relevant changes).

I need help with an error I am getting. When I run the filter to check for conflicts I get this message. Assertion failure (P:\TES4Workbench\frmViewMain.pas,line4255) What does this message mean?


Not sure if this helps or not but this is where it stops when I am running F03edit.

I must say thank you for the FO3MasterUpdate. It fixed all of the problems I was having with the CTDs when I used mods that conflicted with the 1.5 patch. FO3Edit is undoubtedly a godsend. So again, thank you very much.

I hope this is the right place to post praise. ^_^

Thank you for this very easy to use program! Editing FOOK with this is very easy, and fast.

Please use [ codebox ] for longer lists.

One or more of your module files contains subrecords that are not canonical subrecord order (meaning they must have been hacked together in something else then GECK or FO3Edit which both stick to the correct order). Try loading them in GECK as active module and resaving them.

Assertion failure (P:\TES4Workbench\frmViewMain.pas,line4255) What does this mean though?

I still have these in a few of the mods even after saveing them in geck. [00:34] Background Loader: Error: record CONT contains unexpected (or out of order) subrecord DATA

That something unexpected happened.

Then you still have broken module files.

I was asking here because I am tring to figure out what I need to do to fix these problems. Is it a mod doing this error or the program? I didn't even realize you are the one that made the thing, but I been reading up on the old threads. Sorry and thanks for the help in advance.

I have 9 mod out of the 184 mod that have color to them. So the others that have no color to them have no conflicts?

I know you're probably busy right now with the FO3MasterUpdate stuff, but when you get a chance can you upload the source for FO3Dump? (or alternatively just the portion of the source code with the form definitions) I'm going through and documenting the runtime side of all the forms, and it would help save a lot of time reverse engineering things that have already been done. Thanks.

The particular error messages you mentioned, almost guaranteed the mod, not the record definitions that are wrong.

If, after filtering with the "conflict status inherited by parent" option active, any mods are white in the navigation treeview, that means that they are not overriding ANY records from Fallout3.esm. I find it very hard to believe that out of 184 mods only 9 would contain any override records.

I'll send you a PM in a couple of minutes...