Sharlikran

LOOT does not analyze plugins. So when you see warnings like, "this plugins has errors" then that's hand entered text that shows up when the plugin is in your data folder. xEdit check for errors checks for things like out of order subrecords, missing references which show up as , and records that should not be part of certain subrecords like when you see Found a NULL reference, expected: ACHR,ACRE,PBEA. There could be 10 really important issues that users should be aware of in any plugin and I will bet xEdit doesn't check for any of them. The only tool with actual error checking is the CK. I suggest reviewing The Method. There is a new section with dangers on compacting plugins. Because sheson's answer was RTM and possibly rebuild the mreged mods. No modding tool authors can work with broken plugins.

307.202002061758 Latest nightly with the DynDoLod friendly changes. Currently using the changes that remove libloot python but I have seen it work correctly. If there are any bash tags not being recognized please post that in the Wrye Bash discord after looking at the LOOT masterlist first. There are different versions of the masterlist for the different syntaxes. Zanderat and DarthVitrial see how that version works for you.

I can't comment on specific versions because I make changes for personal use. I don't always note the differences. If I have then I do on GitHub. For the versions I linked they were to address two issues Sheson mentioned. This is explained in the first two sentences above the links. Other then that, the versions I provide are very close to the current nightly. I just updated the links in this post because those versions are equal to the current nightly but include the DynDoLod friendly changes.

No I am not addressing you or a specific solution to anything you have been discussing with Sheson. I am simply posting those versions because Sheson mentioned to me that there persistent cell data was causing issues and that large ref data was in the bash patch when it should not be there. So those issues are addressed in those versions to make the bash patch more DynDoLod friendly.

Latest builds still using libloot python: Both versions work with Loot 15.x and are backwards compatible with previews versions of LOOT. This is the proposed workaround to prevent persistent cells from being written to the bash patch and it prevents the bash patch from having large refs in world cells. For Windows 7 and 8.1 users. Built with pyinstaller rather then py2exe.: Win 7 and 8.1 LOOT 15.x For Windows 10 users. Built with py2exe: Win 10 LOOT 15.x

This will be tedious but, I need to request it and since this is a fairly big issue I would appreciate it if you could try this. The other day someone had a cell issue. I had him go through something similar and he found a mod, that was not listed as a master of the Bash Patch importing improper data. Please build a bash patch with the DLC only and see if it still happens. If so let me know. If not then after building one with only the DLC, build a bash patch with a few mods at a time until you find the mod causing the issue. I just double checked and this fix has made it into the official wrye bash so my versions, or the official version should not be doing that.

Windows 10 Only: 307.202001101724 Windows 7 and 8.1 Only: 307.202001101603 See if either of those work. If not post here please.

Thanks for the two of you mentioning that. I wish more people had seen this because I just had yet another person say: I don't know if they missed the What's New document included with the download or what. They keep saying they need updated information when using 4.0.2. I can't figure out what information they need though. They are using Fallout 4 and for Fallout 4 4.0.x is required! Using an older version will make Fallout 4 plugins that have incorrect record formats. While trying to troubleshoot reports from people on Discord I would use the FO4 CK and the plugin would crash it until Elminster fixed some aspect of the record. I have told people over and over the Gambit77, Elminster, and other top developers of Fallout 4 use the program so much they reported all the issues with Fallout 4 and other game modes they use.

I was wondering how would the site overall between the different moderators be able to handle this. With the latest release of xedit the proper way to clean a file is to use a command line parameter that we've listed in the documentation. With version 4.0.2, we have removed the apply filter for cleaning, remove identical to master records, and undelete deleted references. Because of the cleaning improvements you actually would have to do more than those three steps now in order to thoroughly clean the file. That is to say if you know all the steps and setting changes that need to be made you could still clean manually safely and thoroughly. In fact one of the settings that you need to change, which you would uncheck simple records, requires a restart of xedit. And then when you're done cleaning all your files it might be a good idea to check that again because it takes more time to calculate the complex records. The problem is that all of that guessing and steps and clicking and everything that a user would have to do is all taken care of with the Quick Auto clean procedure. In addition to that the quick clean procedure eliminates the need for detailed documentation and videos. What example of the variety of different skill levels that users have, is one user currently doesn't understand what to answer when asked the question there are x amount of cash files would you like to remove them yes or no. So really the Quick Auto clean procedure he's a way to create a user-friendly method for everybody of all skill levels. So the reason that I'm giving all of that explanation and asking the question how could this be handled is because I'm looking for away to do something that I'm unsure of how you guys would react to it. Basically I'm wondering if the moderators can contact either the authors of the guides or if the moderators can alter the guide at the request of our team. I would like to request that all of the manual cleaning steps are removed from all the guides. This is an issue because even as recently as yesterday, but this is been happening ever since the release of 4.0.0, a user contacted us and showed us the link to the step guide he was using. A simple polite statement of all videos and guides prior to the release of 4.0.0 are outdated in regards to manual cleaning. I stressed the point that if you see a guy that tells you to install a variety of over a hundred mods that's fine the guide itself is not outdated. Only the section of a guy that might tell you to manually clean a file is the part that you would want to ignore. The user persisted in following the guide even after we told him maybe three times not to follow that part. His main concern was that he wanted to make sure that he was doing everything correctly so that the results would be the same as shown in the guide. And we stressed that the guy didn't need to be followed and that it was outdated. And that the Quick Auto cleaning procedure handled all of the steps automatically that you would need to have done in the past. That the new procedure would also change settings and perform extra operations that make the new cleaning procedure more thorough. And after doing so he was still following the guide trying to make sure that you did it right. Having to repeat that, seeing his reaction of what he was looking for for this reassurance that he was doing it right, made it very difficult to get him past all that. We even have a cleaning video that goes over a lot of the questions that people have and have had for the past 6 years. Questions like loot it says that I am going to remove 50 identical to master records, yet when I read the cleaning procedure I removed 70 why is that? Another question like loot says that I have to clean a file, and I know the author already cleaned it with an earlier version, so why do I have to clean it with the new version? Mod authors that are well-known typically complete all of their mods and you would never have to do so, but loot is telling me I'm going to be able to remove some identical to master records, xedit has to be broken because why would I have to do that? In the video answers all of that kind of stuff. I'm not going to go through all the answers because it's in the video but just do at least to get at the part about cleaning files again with the latest version of xedit, it's simply because there's no time machine for the authors to go back and clean their mod that they released three years ago with the current version, and the current version uses a better system that cleans the mod more thoroughly. And what's concerning myself and what's difficult for elminster to deal with is the repeat questions of, am I doing this right because there's this guide that says... And it's getting a little redundant to repeat over and over that the Quick Auto clean procedure handles all of the steps automatically and you know that it's finished when it prints out the report that you would provide to the loot team it says that it's finished. What's it stops at that point it's done and the file has been cleaned correctly. And the program just sits there and waits for you to close it, so that you can review what was cleaned out of it. Giving you an opportunity if you need to, if you have any concerns to restore a backup. Because everyone knows we do put a copy of the file that was cleaned into a backup folder. So having all of the manual cleaning information scattered throughout all of the various guides specifically step guides, is just causing a lot of extra question and answer and users repeatedly asking did I do this right or users asking I'm following a guide and I can no longer find the option in the program to do the cleaning. Can your site is a whole help with that and either get guide authors to remove that from their guides, or four authors that may not be updating their guides or may not frequent the site, can the moderators that have access to that kind of editing remove that from the guide. Please Sorry about the post not having as much punctuation or having a few wrong words. I'll change it later. I'm about to go to work and I'm doing this from my phone for right now. Since I'm going to be basically working or commuting for 10 hours this way there's some time for me to see what kind of feedback I get from the moderators and what your overall feeling is about it.

https://github.com/Wrye-Code-Collection/wrye-bash/releases has the latest version to fix that issue. Please test it when you have time.

There is another update at the link provided. Test it when you have time please.

Fixed that error "AttributeError: 'unicode' object has no attribute 'items' " in 307.201903192049

How authors release mods, understanding the mods you have installed, and how to resolve conflicts can be improved on. If anyone would like to join the xEdit discord and talk with others about functionality then download the latest version and click the Discord button. With all the tools available such as LOOT, Wrye Bash, and xEdit, anyone should be able to have a stable game regardless of whether or not you have less or more then 255 mods. There is also a new xEdit feature to make a delta patch but I have not tried it yet. Some people are testing it out today on YUP to see if it does what Elminster expected it to do. If I understand correctly it shows you a diff between mods. You probably have to have the old file installed and the new one with a new name but I'm not sure since it's new and I haven't tried it. The result is a file with only the changes between the two plugins. There are people with mods ranging from 350 to 550 that have spoken with the xEdit team or are currently using the dev version of Wrye Bash and don't notice any issues at this time. I am sure issues will show up as more people us the tools. With xEdit Elminster has been resolving the issues since he has made the changes. For Wrye Bash I hope I can make corrections because my python skills are limited. There is a new volunteer that has been working with LOOT and Wrye Bash though it has been a pleasure to work with. There are probably many unused features in xEdit. Modgroups for one which diff plugins that are in the group. I have been experimenting with it to provide a better walk through similar to how Miax and JustonOther did for the original Fallout Training Guide. Examples are available on the xEdit GitHub. There is no reason to merge mods with Wrye Bash for games that have ESL capability because of the limited functionality. Files only qualify to be merged if they contain overrides of the masters. They cannot have new records. An ESL flagged mod can have overrides and new records. People might not even know that. I don't know where all the posts are (don't need any links though) but Elminster was very surprised as to how complicated people make ESL files out to be. It is something he consistently corrects people on if they say anything contrary to what he had me add to the xEdit docs. Just having him back and the progress made with xEdit has really changed my view about how mods work in FO4 and SSE. Users may still feel that with over 255 mods that leveled lists can have any amount of entries, and that's not true, it's limited to 255 entries. That the Bash Patch can save files at FE xxx, when it can't, it's still limited to 255 masters like it has been in the past. Using mods and patches made with xEdit should prevent the Bash Patch from becoming overloaded. With a patch flagged with the ESL flag, if it's records are the winning record, then it should not end up in the Bash Patch. Thus allowing potentially 550 or more mods installed with no issues. People with a more modest amount of mods, say around 100 will still have the same benefits as those with more mods. I set up a modgroup for just two mods and after I did so and asked about what I was looking at. Elminster and others in the xEdit channel showed me where the differences were and making a patch at that point took minutes because I was not seeing as many records anymore. I was only looking at was different between the mods loaded. I have even been experimenting with mods that are clearly incompatible like NPC overhauls or NPC AI overhauls. Between the two of them there still may be no way to resolve all changes, but it's shown me the value of the process. If users can pick up on it and follow the examples I am working on, they can make patches quickly and easily and won't have to bother mod authors at all. Once the patch is made and becomes an ESL flagged file, they can then load other mods and continue. I can't even imagine how hard it must be to maintain a merged mod of over 100 modules and know everything you put into the merge. Say all your weather merges. What if the author comes out with a new version? How do you overwrite the change into the merged mod? Rather then explain it, consider, you no longer even have to. If it can be an ESL then make it one. If it's a patch and could have been merged it can have the ESL flag. Elmisnter has over 450 modules and told me he is approaching 500 mods installed, no merging, and no bash patch and he has no issues. He makes all his micro patches starting with the merge patch. When he makes a micro patch for two or three mods he only loads those mods. Which many people want to just load the entire load order. Makes no sense. What's unfortunate is modgroups and all the things Elminster is sharing has been around for over a decade. Even the docs I added to a website are just an HTML version of the Fallout 3 training manual that I have been altering. Most of the same Fallout 3 mods are available and when I can I install them and just make new screen shots. Everything Miax and JustinOther showed about xEdit could have been something someone could have used this whole time but probably never bothered to look at. Simply for the fact that some people don't read the description page or look at wiki pages or see that there was a PDF. I don't know there is also the possibility that some might have seen the PDF, and may have thought it was for Fallout 3 and Fallout NV and dismissed it as useful to Skyrim. I don't know but I just never see people reference the PDF but now I am starting to see people reference the online documentation. I'd like to see it where people don't have to worry about troubleshooting failed merges, searching google for solutions, posting comments and not getting an answer, or having to wait on anything useful. What I am trying to drive users toward with xEdit, LOOT, and Wrye Bash, is... install, test, play, and when needed, update and play. Somehow more time playing, less time working to make it so you can play.

My reasons for the change: Plugins that qualified as mergable were not allowed to have new recordsFiles with the ESL flag can have new records if they are within the range specified by Bethesda 0x800 to 0xFFFMerged plugins had to be left in the Data folder for each time you rebuilt the Bashed Patch, but disabled.Conflict resolution cannot occur with disabled plugins in xEdit. You have to load all the plugins to look for conflicts. Many users do not do this and complain about unexpected values appearing in the Bash Patch. For the most part the unexpected values came from disabled, imported or merged plugins.A Merge Patch, Smashed Patch, or a Bashed Patch cannot exceed a byte for the count of masters. I don't know if the game will allow 00 to 254 or 00 to 255 nobody has ever had that kind of file and actually had a working game.

Some report they have a version of Windows 10 that causes this to appear. Some also say they have practically the same version but with Windows updates. I'd give more specifics but it is unclear why the error shows up at all and from the comments from other Wrye Bash users, it seems like using Windows 10 1803 is your best option. Then also you can use the version development version linked in the pinned post.

Use Valda's version and tell me if the same thing happens please.

If you are using Skyrim SE or Fallout 4, I would go to the pinned message and try the developmental version. Otherwise for original Skyrim then the same will still occur because you have things merging into the Bash patch. Which as Shadriss mentioned, you have to go to the build menu, select merge patches, and then uncheck what you don't want to be merged.

307.20181012 - [APP] Updated layout for Installers tab - Package Context Menus. - [skyrim] Handle Truncated Records in Skyrim.esm - [sSE] Enabled additional patchers - [ALL] Fix C.Regions ITM & ITPO - [ALL] Add Persistent Cells to Patcher Check - [TES4] Add C.Regions support to Oblivion - [All] Updated Advanced Readme - Bash Tag section - [All] LOOT Bash taglists updated to v0.13 - [skyrim, SSE] Added new cell bash tags C.GridFlags, C.MaxHeight & C.LockList. - [skyrim, SSE] Updated class MelModel - [sSE, FO4] ESL flagged files do not count toward max plugin count of 255 - [sSE] Added ESLify in plugin context menu. - [sSE] Added ESL qualification check - [sSE, FO4] Disable Merge Plugins - [sSE] Update messages to display ESL rather then Mergable - [FO4] Disable ESLify flagging and ESL verification support - [ALL] Fix Exterior Cells x,y cords Order in Cell Patcher - [skyrim, SSE] Tweak to NamesPatcher to remove FACT because it would not copy other subrecords. - [skyrim, SSE] Remove unused Alias Patcher - [ALL] Remove Add master from all versions - this does not renumber FormIDs - [skyrim SE] Update MreLens - [skyrim SE] Updated MreLeveledListBase with extra flag for Skyrim SE 307.20181013 - [FO4] Update Fallout 4 Leveled List patcher to evaluate more fields 307.201810141217 - [FO4] Fix error in Bash Patch generation where Wrye Flash for Fallout 4 would create duplicate FormIDs and GRUP records for certain groups. 307.201810221913 - [FNV/FO3] Record updates for MelModel and Leveled Creatures. EXE Installer Standalone EXE Python Source Just some more experimentation with the code if anyone is willing to try it out. Wrye Bash Discord

The website is asking for Passwords again. I lost my HD and have no way to download the files. I was looking in guides but wanted to let someone know.

This is the same error posted in about every Wrye Bash comment section. You simply have a non English language character that has to be removed. That error has been attempted to be resolved tens if not hundreds of times. With that said though, the error is happening in a file that doesn't belong to Wrye Bash at all. So this error is more of a system issue. It could be any one of these things: 1) A char in your User name 2) A char in your Downloaded file name 3) Contents of the zip/rar download may contain a file with non ASCII chars 4) Folder names of the zip/rar download may contain a file with non ASCII chars 5) Contents or TXT, INI, HTML, XML, CSV files of the zip/rar download may have non ASCII chars I won't know where the char is and Wrye Bash can't help you find it either. Another thing you can try is changing your language settings if more then one variation of your preferred language is available from Windows. Sometimes you have only one choice, which in that case you won't be able to use Wrye Bash. One last thing though. I really hate that really small abridged log file. Unfortunatly that's all the user gets. I wish there was a more automatic way to create a more complete debug log file automatically. At the top of every Wrye Bash page is a link to a document for troubleshooting that asks you to run Wrye Bash in debug mode. For example then I would know what language you have, the version of Wrye Bash, the codepage, and so on. I would really appreciate it if users would follow the link. Here is a quick link to the section that pertains to the Standalone version. The guide says to change to "path\to\Mopy" which is telling you to change to the location where Wrye Bash is installed. Yeah you kinda need to know that. What that basically wants you to do is to run the Wrye Bash.exe with the -d command line parameter. If you ran the EXE installer there is also a Wrye Bash menu in the Windows Start menu that has a shortcut already that enables debug mode. Once you have a BashBugDump.log in your mopy folder, post it here.

Yeah it tells you what it's for on the screen. When you uncheck Automatic you are simply overriding which Relev and Delev tags are being used. If a mod author or LOOT suggests both you can uncheck Automatic and on that screen remove either Relev and Delev. To exclude a file you have to disable it from the mods tab. Which will work as long as it's not also merged into the Bash Patch.

Sorry to necro this thread, however to keep people in the know... Both of Valda's versions don't have LOOT support, only BOSS support. The BOSS master lists are locked and can't be changed. Manually tagging the mods or adding the bash tags to the plugin header are the built in ways to add tags without LOOT or BOSS.

If you feel this is getting slightly off topic, please move this and your post as needed, and I apologize. If not and if it's still on topic enough because it is about the OPs error, then... What the xEdit team has mentioned in the past is that the game can see and handle the differences between Skyrim SE records (Form Version 44) and older formats at run time. The same basic idea as the Windows compatibility mode for Windows 98 or XP when running under Windows 7 or higher. It has nothing to do with how many bytes there are in the plugin be it 8 or 12. I have seen Zilav talk about used data from old Skyrim plugins. Specifically when the old Skyrim record has used data in it that was shifted because of the updates that Bethesda made to the Skyrim SE records. That would go for required data that didn't previously exist in old Skyrim Records. When the data that is shifted or required is not manipulated correctly and the record is the same size as Form Version 44, but the Form Version is something other then 44, it is guaranteed to cause an issue. If I remember correctly. The misunderstanding came from conversations about Form Version 44 in Skyrim SE. No version of xEdit has ever changed the Form Version or record format when making a Merge Patch. No version of Wrye Bash has ever saved the Form Version into the Bash Patch because the original code was for Oblivion which didn't have a Form Version. Since the Wrye Bash code has for the most part remained Oblivion specific it just stayed as it has always been. In xEdit if the Form Version was 20 in Skyrim.esm and the size of the record was 8 bytes but the new size was 12, xEdit would save it as 12 bytes and Form Version 20 instead of 43 or whatever. That was for the merge Patch for sure, I can't remember if updating a record from 8 bytes to 12 changes the Form Version when you are just editing a record. Since it had been that way since Elminster made xEdit it was left that way. It was never about editing records in their existing format regardless of whether or not they were Form Version 43, 40, 20, 30 or whatever. It was about Merge Patches, the Bash Patch, record truncation, the lack of the proper Form Version in the plugin header, and possible save game corruption as a result. That conversation went from a simple question, to a hypothesis, to if there is not proper Form Versions and if the records are not saved in the proper format that it is an affront to modding. There was mention that the Bash Patch not having a Form Version was leading to save game corruption. People shared other posts from other sites about the issue and that those posts contained reports of random crashes as a result of mods not being Form Version 44. I was even told personally that at least 5 prominent mod authors "that know what they are doing" (they never spoke to me though) had crashes because of mods not being Form Version 44 and because the Bash Patch didn't have a Form Version. The position of some that believed it was a serious issue mentioned that all mods without Form Version 44 and that the Skyrim SE version of Wrye Bash should be removed from the Skyrim SE Nexus until the issue was addressed. You can read all that in the official WB thread if you really have to see it. I am just trying to answer your question and eliviate the concern you have toward the warning and why the warning is present. Aside from that I ask that we don't start the conversation up again in the official thread or comment too much further. Although, I will be respectful of your comments and concerns of course. Because the conversation really got out of hand. There were people complaining to me that I had to find a solution, complaints toward others and sometimes with expletives or harsh words. In the end it lead to rewriting how Wrye Bash saved the Bash Patch header. The Form Version is now added to the Bash Patch. I can't remember what changes if any were made to xEdit. So in the end, even though I am reiterating a few things. Wrye Bash has always had an error or warning that the record is not the size that is expected, period. It existed prior to Skyrim SE. What Wrye Bash does when the record size is incorrect is it won't process that record. What lead to the warning was that users started posting the error and asking how to fix it. Since there is no fix except that the author updates the plugin, I added additional verbiage for the records that changed in Skyrim SE. In other words if the plugin has no records that changed, and doesn't have any Form Version 44 records, the warning will not appear. That way people know why it was happening, that Wrye Bash would not be addressing it (but never had), and a simple solution if the mod user chose to do so. My personal opinion is that if Bethesda changed the record that the plugin should be saved with the CK and then the mod author should compare the plugins to ensure the mod still does what author intended. There is a "compare to..." option for plugins in xEdit. The CK no longer corrupts one of the records used by weather mods, one of the shaders, I forget which one. So saving the plugin is more stable then before. If none of the records changed, I still feel the mod should be saved but don't have any definitive position on plugins without records that changed between Skyrim and Skyrim SE. I have not experienced the extreme issues reported by some, but I have had my game run much smoother once I updated the plugin and tested all assets and updated them with the 3rd party tools as needed. There is merit to the reports I just feel they may be exaggerated.

The record verification has always been there and xEdit has a warning as well but in xEdit it is worded different. There are two warnings. 1) For Skyrim SE only that tells users that to correct the missing bytes it needs to be loaded into the CK. I felt this wasn't as derogatory as telling the user that the author had uploaded an old Skyrim plugin as a Skyrim SE mod without saving it in the CK. Besides we decided not to update old Skyrim plugins automatically when saving from SSEEdit. We tried that once before by converting BODT to BOD2 with TES5Edit in one of the very early versions 3.0.25. We were not able to keep plugins from breaking. We had to remove it and upload 3.0.26. 2) The second warning is simply when any record or subrecord is a different size then expected which has always been present in WB. Never the less, Wrye Bash can't take 8 bytes when in needs 12 and compare nothing to other records that have 12 bytes and determine which to use. That is like trying to add 1/8 to 1/12 without finding a common denominator. Nor can it properly decide what to add for those extra 4 bytes. With some of the records that changed, Bethesda added bytes to the record effectively shifting any important data like FormIDs.