Xedit doubts and bashed patch

[Himself]

Heya, me again!  xD

 

New to these programs (xedit and wrye flash) and have some doubts wich I hope are common to new users, so please answer if you can...

First see this image here: https://postimg.org/image/8pzx2md2l/
 

I've numbered those "models and alternate texture" fields from 1 to 7.

(1-6 being plugins and 7 a bashed patch)

 

As you can see, numbers 3-4-6 have entries, and 1-2-5-7 are empty.

 

Doubt 1 - Since fields for 7 are empty, once I start the game and play, will the game use the information contained in 6, or will it use the empty from 7?

 

Doubt 2 - If the answer to previos doubt was "it will use the empty from 7" read on, otherwise jump to doubt 3.
Number 6 being the last plugin has what is supposed to be the most precise entries (lets assume that in this case yes, it has the most up-to-date information and was created taking into account all the previous plugins), however if the game uses the empty fields from 7, that is a bad thing right??

 

Doubt 3 - Theres an entry the bashed patch has overwriten and is using the entry from number 5 instead of the entry from 6 (look above number 7 in the image -> first entry that has text, you can see its the same as number 5, but different from 6). Is that supposed to happen? How does the bashed patch decides that 'the right thing to do' is ignore info from 6 and preserve those from number 5?

 

 

Doubt 4 - I've got the bash tagger (not used it yet) from pinned topic in this area, https://forum.step-project.com/topic/6841-wip-bash-tagger-detects-up-to-49-bash-tags/

selected download and it came as "fireundubh_-_bash_tagger_v1_3_9_1.pas.txt"

assuming I've to remove the .txt in the end so it matches all other .pas filetype in xEdit\Edit Scripts folder.

in the pinned topic it says:

 

Roadmap:

• v1.1 - Initial release (based on zilav's BASH tags autodetection v1.0 script)
• v1.4 - Mostly complete TES4 and TES5 support
• v2.0 - No bugs whatsoever

However my version is NOT 2.0, it even says so when opening the file and looking at its top info:

Purpose: Bash Tagger

Game: FO3/FNV/TESV

Author: fireundubh <fireundubh@gmail.com>

Version: 1.3.9.1 (based on "BASH tags autodetection.pas" v1.0)

 

Is there a version 2.0 somewhere else?

 

Doubt 5 - What exactly does a Bash Tag do and "should I try to add bash tags to as many of my plugins as possible" or "follow only the bash tags from LOOT/BOSS guides" and leave the rest alone cause I need more advanced knowledge to understand how/when bash tags can do more harm than good. (and if so is there a guide or topic for that).

 

Hoping these questions have simple enough answers, seems like most new users would ask this anyway..

Thanks to anyone taking the time to read and reply! :)

Edited November 30, 2015 by Himself

[hishutup]

hmm, this isnt something that one can really patch from looking at the records because the alternative textures are dependent on the MODL file.

I can't explain it because its somewhat complex and I don't understand it completely myself.

[GrantSP]

Yeah, this is a good example of why conflict resolution isn't always straight forward.

 

To answer your queries as best I can, this is what will happen in game.

With your "bashed patch" loaded, #7, the records will match the vanilla game as shown in #1 and also #2.

Removing your "bashed patch" will mean FWE and the WMK patch for FWE will be used and the RH Ironsights stuff will cause issues with some weapons. There is some further discussion around here about the Blackhawk and how to get "ironsights" for this weapon and it will show you that it is far from an easy task.

 

As for the "Bash Tagger" script, the author had a run in with some people on Reddit and in a fit of frustration has removed all his code from the various places he had it hosted. Although while looking through the Bethesda forum today I did see him posting recently so maybe he will release it again, I wouldn't count on it though.

[Kelmych]

Starting at the end:

Hoping these questions have simple enough answers, seems like most new users would ask this anyway..

 

The questions are reasonable. Most of the answers are unfortunately not simple. There are some helpful references about portions of Wrye Bash (the STEP Wrye Bash pages, Wrye Bash Readme and Advanced Readme in particular). Bethesda doesn't publish a reference for all the plugin record and subrecord types used in their games, so users need to discover this through trial and error. I've never seen a tutorial or a fairly complete reference document that covers the harder questions such as when a bash tag is appropriate or inappropriate (note that it depends on the collection of mods being used, not just the details of an individual mod plugin). Bash tags indicate which portions of the records in a plugin should override the same record types in later loading plugins. Bash tags are useful, but they only cover a portion of the record and subrecord types used in Bethesda games and they are not always very precise (a single tag may cover multiple record/subrecord types).

 

Doubt 1: yes, in general the records in the last loading plugin overwrite all previous plugins (with exceptions for a few record types). For the example you show the last plugin wins everything.

 

Doubt 2: sometimes the blank fields are the right ones to use. In your example the use (or non use) of alternate textures depends on the details of the model (mesh file) for the object, and different plugins may be using different models for the same object. This is, for example, a big problem with Fallout 3 weapon plugins where there are several different incompatible approaches used for weapon models.

 

Doubt 4: the latest bashed tag script is version 1.5.1.1 . This script does a very good job of detecting candidate bash tags, and its results can be used more than 90% of the time. An example of when it might not be correct happens in Fallout 3 with the records that provide the details of NPC faces. In Fallout 3 we usually use Project Beauty to provide the face details and we don't want later loading mods overwriting these. The bash tagger script might notice that a plugin changes some aspect of NPC faces and is a candidate for one of the associated bash tags. Here we would not want the facial-related bash tags added to these mods even when the bash tagger notes it is a candidate.

 

Doubt 5: Ideally the bash tags listed by LOOT were recommended by advanced users who looked carefully at what the plugin does and how it fits with other mods used in the game. There can be errors, of course, and the LOOT database is incomplete. Because of this the bash tagger script can be used to try to fill in the holes, but its recommendations are often correct but sometimes they aren't the best choice. When I look at the output of the bash tagger script I add the tags to the plugin, run Wrye Bash/Flash, and then examine the effects using xEdit.

 

I used Fallout 3 references because some of the examples are easier to find there (vs. Skyrim) and because Wrye Flash for Fallout currently handles many more bah tag types than Wrye Bash for Skyrim.

 

Maybe Mator's new Mator Smash will solve all of this for us.

[Himself]

Okay thanks guys!
I'll make some general assumptions to see if I get it, please correct anything that is wrong, hopefully other new users can also read this and clear doubts! ^^

 

1 - In the case of that example, bashed patch did the correct thing by leaving empty fields and overwrite last entry (#6) by a previous one, since this "prevents" bugs/weirdness from happening to another main mod (the Ironsights for FO3), while still maintaining a stable enough build. Ohh nice! Seems the little program is smart enough =]

 

2 - Would I be correct in thinking that the difference between a 'bashed patch' and a 'merged patch' is that a merged for the most part only "flattens" load order while 'trying to solve conflicting entries' (www.youtube.com/watch?v=uPK7R71zcwM&feature=youtu.be&t=1363), but is not as robust/capable of using the same sort of "logic" that wrye flash uses in a bashed patch? (like for example preserving selected sections from given plugins)

 

3 - I'll probably just leave the bash tagger out for now since it being correct 90% of the time is not sufficient for me, if I was an accomplished modder or long time user/player that knows enough about editing the game around (and supposed content of plugins) to fix the remaining 10%, I would go for it, however I dont think I'm comfortable/knowledgeable enough at this stage. Probably gonna follow tags suggested by LOOT. Does LOOT auto-check for updates and retrieves its information listings online? Does it do it automatically or I must force the program to do it?

 

 

GrantSP - The use of Blackhawk weapon as example was completely random on my part, I just opened the bashed patch and checked on a weapon to see if it had conflicts wich I could adress as examples for this thread. As you can see from the image theres a lot of "red" in my bashed patch lol, hopefully its due to the ironsights deal you mentioned.

 

 

And now the part for becoming self-sufficient:

 

When a plugin contains little information inside, but I know I really need/want/isOK for that plugin to be active AND also need to reduce plugins/load order amount, I open it in xedit together with its "main plugin" (assuming it has one), and just copy or insert the info of the small plugin on top/overwrite that of the main plugin, so as to eliminate the need of that small plugin, taking enough care so that the replaced entries are nothing major or prone to problems.

 

Should I check that both entries (former and new one) have the same FormID/EditorID or that is not necessary? (It doesnt seem like it can be wrong in Xedit anyway)

I've read that alterations in NavMesh need the plugin be opened in the game editor and then saved only to "rebuild it correctly" or some such, is it that simple or should I just avoid messing with NavMesh editing?¿

(and does above procedure goes for xedit in all 4 games?)

 

Lastly, there are some changes (small details) I wanna do to the game, for example the face of an NPC that I've modified to my liking or the amount/shape of light from a source or statistics for a weapon, I'm placing those changes in a small plugin that I load by last and I'm constantly editing this plugin (so I don't include it in a bashed or anything and always leave it by last), seems to work fine so far and dont show any problems, however is there any advice to this practice or I just gotta "play it smart" and test often and generally avoid biting more than I can chew ^^

 

Again thanks to all of you who read and/or comment, this probably clears most simple doubts and steps!
(If anything else is more or less correct, please at least answer the blue text!   )

Edited November 30, 2015 by Himself

[Kelmych]

2. The purpose of both merging plugins and the bashed patch are to reduce the number of plugins used. Wrye Bash/Flash has some logic which allow it to handle a small set of (but not all) conflict types better than a merged patch. Both Mator's Merge Patch plugin and Wrye Bash/Flash have a lot of logic to handle different situations, but there are still many limitations.

 

3. LOOT automatically checks for and downloads updates to masterlist.yaml, but remember that this file is manually created by the LOOT team based on inputs from mod users. You can always click the icon in LOOT for it to check again for updates.

 

 

There is a brief discussion, and an external reference, of FormIDs in this advanced guide. Mator's Merged Plugin can handle merges where there are no conflicts between Navmesh entries. In simple cases the Creation Kit <shudder> can be used to resolve simple conflicts between Navmesh entries (KeithinHanoi described this in some posts a while ago). You might also want to read some of the discussion on STEP and the articles in the Nexus page for the Immersive Citizens mod concerning navmeshes; some of these discussions cover more complex situations.

 

Changing the entries in master files isn't a good practice, especially since the master files can be updated and the changes are lost and need to be recreated. I build one fairly small patch file (or sometimes a few) with the changes I want, making notes on what I did so the next time one of the master files is updated I know what to check for. ElminsterAU (the author of xEdit) suggests building a set of small compatibility patches, each for a few mods, and then merging these into one (or more) overall compatibility patches (the guide mentioned above has a reference to this).  These patches load last, usually after but sometimes just before the bashed patch. The bashed patch can merge entries in subrecords for FormIDs and Leveled Lists, which would otherwise need to be done manually in the small personal patch so sometimes I let the bashed patch do this. A perhaps more elegant way to create the compatibility patches would be to separate the FormID/Leveled List subrecord entries into a patch which loads before the bashed patch (and is then merged by the bashed patch), with the rest of the patch records merged into a separate patch (or patches) that load after the bashed patch.