Reserved

Reserved -----

@utumno Hope im allowed to reply, but yes you were right, something was a tad wrong with my python install and reinstalling it fixed it. Thanks

Reposted from http://www.gamesas.com/topic/1510638-wrye-bash-thread-101/?p=23911501...

The information so far has been very helpful. However, I noticed that the code for the Oblivion records and the patcher for Actors which covers the Actors.ACBS Bash Tag was not changed between 304.3 and 304.4. Which means that although there is a definite change in the Bash Patch as viewed in TES4Edit, and an obvious change in game, the code for Wrye Bash did not change in regards to any of the records or the patchers. So in essence, Utumno can't go back and compare the code and then offer a fix for it because again, there was no change in the code. So the question is, what changed?

Bash Tags, Fig 1.

Looking at the code verifies what I see in the http://sharlikran.github.io/wrye-bash.github.io/Wrye%20Bash%20Version%20History.html. The BOSS 2.0 API was updated to use the BOSS 3.0 API. That part of the code is what is responsible for managing the Bash Tags. The BOSS 2.0 API uses masterlist.txt from BOSS and the taglist.txt that is generated by a script and packaged with Wrye Bash. The file taglist.txt provides automation so that Wrye Bash has access to the Bash Tags from BOSS. However, that file is not the only place Bash Tags are obtained from because it can be out of date. Wrye Bash gets tags from the masterlist.txt and taglist.txt, the plugin's header, and manual bash tags. However, as shown in Fig .1 on any of the lines that start with * From Manual, manual Bash tags override everything.

The change from using the BOSS 2.0 API and the BOSS 3.0 API means that 304.4 and newer use masterlist.yaml and taglist.yaml. Those two files are basically LOOT. For those who were not around for the all the drama behind the change from BOSS 3.0 to LOOT it happened because of everyone's confusion with the load order sorting from BOSS 3.0. Which lead to a temporary halt on it's development and later the name change to LOOT to separate LOOT from BOSS.

I was there for all that and assisted in some of the conversion of the masterlists from BOSS to LOOT. The Bash Tags were imported from the old BOSS masterlist into the BOSS 3.0 which later became the LOOT masterlist. When the script is run for the LOOT API it will generate the same kind of taglist.yaml that 304.3 uses but now it's generated from LOOT's masterlist and not BOSS's masterlist. Can this cause an issue with bash tags? Yes it can.

If you are using 304.3 and if you have the latest version of https://github.com/boss-developers/boss/releases/tag/v2.3.0 then you will have all the tags that BOSS has. Again as long as you have not assigned any tags manually as that overrides all other sources. If you use 304.4 or higher then you would need https://github.com/loot/loot/releases/tag/v0.7.0-beta.4 installed to have access to any Bash Tag changes from the LOOT masterlist.yaml that are not in the most likely outdated taglist.yaml packaged with 304.4. Will there be differences between the BOSS and LOOT masterlists? Most defiantly. This is the current issue in maintaining two versions of the mod sorting tools. For those who dislike how LOOT works and use BOSS instead, they will not have the same bash tags that LOOT does. Most of the time it will be the same, just not always.

Volunteers can now use the same repository or internet site that WrinklyNinja uses for BOSS and LOOT development. https://github.com/loot/loot.github.io/wiki/How-To-Contribute. As long as they are valid updates they will be merged into the masterlist. This creates the possibility for anyone to contribute to the masterlists and keep them current because volunteers are now scarce. LOOT is the currently supported masterlist so any remaining volunteers pretty much only update LOOT and never touch the BOSS masterlists. Any hard core BOSS fans that have updated the BOSS masterlists probably do the same and don't update the LOOT masterlist. The Wrye Bash script used to make the taglist.yaml which helps in adding the Bash tags automatically only uses the LOOT masterlist. This means that they can easily get out of sync unless someone goes and verifies all the changes between both BOSS and LOOT.

Now that creates a lot of questions.

Q1. Do you need the most current taglist.txt or taglist.yaml file?
A1. No, because if you have the current version of BOSS or LOOT the masterlist is used in conjunction with the taglist.

Q2. Do I have to have both LOOT and BOSS installed?
A2. Depends. If you use any version 304.3 or earlier/lower then you need BOSS installed. If you use 304.4 or higher you need LOOT installed.

Q3. What if I prefer LOOT instead of BOSS but I still want to use an older version of Wrye Bash (304.3 or earlier) because some things don't seem to work with newer versions. Do I need both LOOT and BOSS installed?
A3. Yes. However, if you prefer LOOT over BOSS but you use 304.3 or earlier then you have to manually apply any differences with the Bash Tags shown in Wrye Bash compared to what LOOT suggests. There is no workaround since the BOSS and LOOT masterlists and taglists use a different format.

Q4. What if I prefer BOSS over LOOT, do I still need both installed for 304.4 or higher?
A4. Yes. You would have to update both the BOSS and LOOT masterlist, sort with BOSS, manually apply needed bash tag changes not in the BOSS masterlist, then build a Bash Patch. Again, BOSS 2.x API is 304.3 or earlier and Wrye Bash 304.4 or higher uses LOOT.

Q5. What if use 304.4 or higher but I prefer to use BOSS over LOOT and there are differences in the Bash Tags. Do I need to apply the Bash Tags manually?
A5. Yes you do. Because 304.4 or higher doesn't look for or care about the BOSS masterlist or taglist.

Q6. Is there any way to export the bash tags I used with 304.3 or earlier and import them into 304.4 or higher?
A6. No. You can only list the bash tags in 304.3 and then apply them manually in 304.4 or higher. Remember you don't have to manually apply any bash tags if they are already the same. Leave it set to automatic when possible.

Q7. When I apply a Bash tag and build the Bash Patch I don't seem to get the correct or expected results. Why is that?
A7. You can't add a bash tag, then build a Bash Patch and then expect it to work right. You need to use TES4Edit to look at the plugin, determine the correct Bash Tags, and then apply the correct bash tags. Don't apply tags because you just wanna see what will happen, because you are testing something, because you don't know if what the author suggested or what BOSS/LOOT is suggesting is correct, but because they are the correct bash tags to be using.

Q8. What if I build a Bash Patch and I change the Bash tag and now all the records have weird results in them. Is that a bug?
A8. Nope, not a bug. Proper bash tags need to be applied to all the plugins you use or the results will not be correct.

Q9. Where are the Bash tags listed?
A9. The Wrye Bash Advanced Readme.html file shows all the Bash tags for Oblivion. It is not current for Skyrim.

Q10. I looked at the bash tags and I would have no idea which ones I need to use. Is there a guide or do I have to become an overnight expert?
A10. Overnight Expert. However, it's pretty simple. If even one record needs the Bash Tag you don't have to continue looking at all the records. Stop with the current Bash Tag because you found a record it applies to and move on to another one.

Q11. What if I am pretty sure I did it right but the results are still not what I expect?
A11. In Wrye Bash you have pluginis that might be unchecked. Normally that happens when they are merged or imported into the Bash Patch. When you are looking to see where a change is coming from you have to load all the plugins in TES4Edit not just the Active ones. Then consult the Fallout Training manual Section 4. It applies to all versions of xEdit.

Q12. What if the Bash tags are not current or missing entirely for LOOT or BOSS?
A12. You are back to becoming an overnight expert in Bash Tags and you will have to apply them manually.

Good because I was about to post something in response to this.

I was going to post this:

By the way, Whats the difference between python.exe and pythonw.exe? It launches fine with both, which is why i ask the difference between the two? Thanks for the help anyway btw

This is covered in Q3, Q4, and Q5. Even if you use BOSS, if using 304.4 or higher both LOOT and BOSS are required. If there are any differences in the Bash Tags from either the masterlist.txt or the taglist.txt and their respective yaml counterparts then the Bash Tags applied will be different. That should be rare and all I am saying is that it can happen and how it will effect things.

When using WB 304.4 or higher for Oblivion and there are differences, Bash Tags would have to be applied manually because the BOSS information is never looked at. So if mhahn is updating the BOSS masterlist and you want those changes then you have to stay with 304.3 or lower for Oblivion. If you use 304.4 or higher and you want the changes mhahn has applied to the BOSS masterlist to be accessed by 304.4 or higher then mhahn would have to add/edit/adjust the bash tags for the LOOT masterlist as well.

Now one thing I noticed is that with 304.4 there is one line in bish.py that still looks at the BOSS masterlist.txt and the taglist.txt.

@mainfuncdef createTagList(inPath='masterlist.txt',outPath='taglist.txt'):    tags, bossDirtyMods = {}, {}    reFcomSwitch = re.compile('^[<>]')    reComment = re.compile(r'^\\.*')    reMod = re.compile(r'(^[_[(\w!].*?\.es[pm]$)',re.I)    reBashTags = re.compile(r'(%\s+{{BASH:|TAG\s+{{BASH:)([^}]+)(}})(.*remove \[)?([^\]]+)?(\])?')    reDirty = re.compile(r'.*?IF\s*\(\s*([a-fA-F0-9]*)\s*\|\s*[\"\'](.*?)[\'\"]\s*\).*?DIRTY:\s*(.*?)\s*$')    ins = GPath(inPath).open('r')    mod = None    for line in ins:

I don't know how that will effect things.

Irrespective of the above code, weird potential case could happen. 304.4 is looking for masterlist.txt and taglist.txt. It finds them, and uses the compiled dll files. However, the compiled dll files are looking for BOSS 3.0 and the yaml format. Because of that, it finds the BOSS format and has no idea what's going on. Since LOOT support was added with 305 then I would say 304.4 is like the red headed step child and probably should not be used for testing depending on what we are talking about. For how we are saying that 304.3 uses BOSS 2.x and then later versions of WB use LOOT then we should probably be comparing 304.3 and 305 from now on.

So I would change all my previous statements where I say 304.4 or higher to 305 or higher. I'll edit that later.

https://docs.python.org/2/using/windows.html#executing-scripts. Should apply to 2.7.8 but not sure since that is for 2.7.9.

BTW, I attempted to rebuild the bash patch via normal bashed patch (Holy crap i forgot how long normal bashed patch takes compared to cbash) and the Calc min does get transferred correctly but the Auto Calc Stats is not enabled! So this does indeed seem to be a CBash issue somewhat like what AndalayBay said. Just to throw this out there.

http://gifrific.com/wp-content/uploads/2012/07/Conan-Stand-Up-and-Claps.gif

EDIT: So where is the Auto Calc Stats thing on the Update Bash Patch menu? I don't see any Auto Calc Stats anywhere when I go to rebuild a Bash Patch with PBash or CBash. Is this a plugin thing? Is this a flag you see set in TES4Edit?