Jump to content

[WIPz] Wrye BashExp - Skyrim Patcher


Sharlikran

Recommended Posts

Wrye Bash 307-Experimental Fallout 3/Fallout New Vegas/Oblivion/Skyrim patcher Update

This thread is to discuss and troubleshoot implementation of Fallout 3, Fallout New Vegas, Oblivion and Skyrim patcher updates. This will be done using three different versions of Wrye Bash/Flash/Smash. Version 307.x will be primarily for Oblivion and Skyrim but anyone is more then welcome to test this version with Fallout. Since the current official releases for Fallout by Valda are working rather well and just need updating I will be providing links to those versions as well. I will use them as a baseline for the updates I am making to 307.x.

New releases will be on my OneDrive or a Mediafire Link. Version 307.x also marks the beginning of implementing Fallout 3 and Fallout NV support thanks to WrinklyNinja's previous efforts and starting the process for version 304.3. Valda updated Wrye Flash for Fallout 3 (30.x) and Fallout New Vegas (16.0) based off of a much older version of Wrye Bash (292 I think). Valda is not currently helping me with updates so if I can't make the changes myself they will remain unresolved. Please be patient while I wait for new volunteers that have time to help make updates.

To help with Bash Tags fireundubh has been kind enough to provide us with a beta script for xEdit that should work with all four versions. You can obtain Generate Bash Tags.pas from his GitHub repo. I am unaware of where you can post questions and bug reports at this time and I do not maintain that file so posting here will not get you the help you are looking for.

find updates to the script in this thread. Please post all bug reports and requests in that thread.

ATTN for Skyrim version: This version's Skyrim patcher is very new. Unless you know how to use TES5Edit and understand a great deal about plugins you may not want to use this version. Manual editing may be needed for the Bash patch to function correctly. Both Python and Standalone versions are available.

Fallout 3 and Fallout New Vegas: If you are using 306.x for Fallout 3 or Fallout New Vegas the Bash Patch should not have many issues since the code already existed to handle all the routines in the previous versions. Please report any issues so they can be corrected.

If you are using the official releases for FO3 and FNV they are very stable and quite usable in game. However, they do need updating so feel free to post issues you encounter with the Bash Patch.

Links to 307.x for FO3/FNV/Oblivion/Skyrim/FO4:

Wrye Bash 307.0.8_EXP - Python Source.7z - MediaFire, OneDrive

Wrye Bash 307.0.8_EXP - Standalone Executable.7z - MediaFire, OneDrive

Links to Wrye Flash by Valda:

Wrye Flash for FO3 v31.5 - Python Source.7z - MediaFire, OneDrive

Wrye Flash for FO3 v31.5 - Standalone Executable.7z - MediaFire, OneDrive

Wrye Flash for FNV v17.2 - Python Source.7z - MediaFire, OneDrive

Wrye Flash for FNV v17.2 - Standalone Executable.7z - MediaFire, OneDrive

Bethesda WIpz threads for FO3/FNV/Skyrim/Oblivion/FO4 Updates:

Skyrim

Oblivion

Fallout 3

Fallout NV

Fallout 4

STEP Thread:

Wrye Bash/Smash/Flash Experemental Patcher Updates

What kind of testing am I looking for?

I need people with a great deal of knowledge with Bash Tags and plugins to report errors with the Bash Patch for it's respective patchers. For example if a sound from a mod should have ended up in the bash patch but didn't, I need to know. The only bugs I am not interested in are Unicode related bugs. So if you go to install a mod and you get a Unicode error post that in the Wrye Bash thread.

What I am not looking for in regards to version 306.x:

The Python based patchers have never been updated that I am aware of. At least not for the last three years. If records do not carry over into the Bash Patch that clearly should be there I am not directly causing this. I am not experienced with Python enough to change the patcher's behaviour. I can only assign or update records and subrecords to their respective patchers. Once there are volunteers willing to help hopefully the patchers can be updated to produce a more accurate patch. In the meantime rather then assuming the patcher is buggy, I suggest checking all the Bash Tags by using the provided script.

In regards to CBash for Oblivion, I will consider updating the Python code that tells CBash what to do. However, if after I make updates, if the same issue is still occurring, I will not be able to update CBash itself. 99% of the time any issues with CBash will originate from flawed Python code.

Error reporting:

Post the Game you are using (FO3/FNV/TES4/TES5) the FormID of the record, what type of record it is (MGEF, INGR), the Subrecord involved, and the name of the field in xEdit. For example, "Skyrim SNDD - Sounds, Sound".

If I can't find a similar type of setup for the record in the CK/CS/GECK I may ask for a link to the mod.

Record structures:

Documentation for Fallout 3 and Fallout: New Vegas plugin file formats can be found on GitHub/fopdoc courtesy of WrinklyNinja

Documentation for Oblivion and Skyrim file formats can be found on UESP WikiBash Tags

If you have forgotten the Bash Tags most of them are in this list. As I update Wrye Bash I will update that section to reflect changes I have made.

Supported Bash tags for 306.x:

Oblivion: Body-F, Body-M, Body-Size-M, Body-Size-F, C.Climate, C.Light, C.Music, C.Name, C.RecordFlags, C.Owner, C.Water, Deactivate, Delev, Eyes, Factions, Relations, Filter, Graphics, Hair, IIM, Invent, Names, NoMerge, NpcFaces, R.Relations, Relev, Scripts, ScriptContents, Sound, SpellStats, Stats, Voice-F, Voice-M, R.Teeth, R.Mouth, R.Ears, R.Head, R.Attributes-F, R.Attributes-M, R.Skills, R.Description, R.AddSpells, R.ChangeSpells, Roads, Actors.Anims, Actors.AIData, Actors.DeathItem, Actors.AIPackages, Actors.AIPackagesForceAdd, Actors.Stats, Actors.ACBS, NPC.Class, Actors.CombatStyle, Creatures.Blood, Actors.Spells, Actors.SpellsForceAdd, NPC.Race, Actors.Skeleton, NpcFacesForceFullImport, MustBeActiveIfImported, Npc.HairOnly, Npc.EyesOnly

Skyrim: C.Acoustic, C.Climate, C.Encounter, C.ImageSpace, C.Light, C.Location, C.Music, C.Name, C.Owner, C.RecordFlags, C.Regions, C.SkyLighting, C.Water, Deactivate, Delev, Filter, Graphics, Invent, Names, NoMerge, Relev, Sound, Stats

Fallout 3: C.Acoustic, C.Climate, C.Encounter, C.ImageSpace, C.Light, C.Music, C.Name, C.Owner, C.RecordFlags, C.Water, Deactivate, Deflst, Delev, Destructible, Factions, Filter, Graphics, Invent, Names, NoMerge, Relations, Relev, Sound, Stats

Fallout New Vegas: C.Acoustic, C.Climate, C.Encounter, C.ImageSpace, C.Light, C.Music, C.Name, C.Owner, C.RecordFlags, C.Water, Deactivate, Deflst, Delev, Destructible, Factions, Filter, Graphics, Invent, Names, NoMerge, Relations, Relev, Sound, Stats, WeaponMods

Supported Bash tags for Wrye Flash FNV:

Fallout New Vegas: Body-F, Body-M, Body-Size-M, Body-Size-F, C.Acoustic, C.Climate, C.Encounter, C.ImageSpace, C.Light, C.Music, C.Name, C.RecordFlags, C.Owner, C.Water, Deactivate, Delev, Eyes, Factions, Relations, Filter, Graphics, Hair, IIM, Invent, Names, NoMerge, NpcFaces, R.Relations, Relev, Scripts, ScriptContents, Sound, Stats, Voice-F, Voice-M, R.Teeth, R.Mouth, R.Ears, R.Head, R.Attributes-F, R.Attributes-M, R.Skills, R.Description, Actors.Anims, Actors.AIData, Actors.DeathItem, Actors.AIPackages, Actors.AIPackagesForceAdd, Actors.Stats, Actors.ACBS, NPC.Class, Actors.CombatStyle, Creatures.Blood, NPC.Race, Actors.Skeleton, NpcFacesForceFullImport, MustBeActiveIfImported, Deflst, Destructible, WeaponMods

Supported Bash tags for Wrye Flash FO3:

Fallout 3: Body-F, Body-M, Body-Size-M, Body-Size-F, C.Acoustic, C.Climate, C.Encounter, C.ImageSpace, C.Light, C.Music, C.Name, C.RecordFlags, C.Owner, C.Water, Deactivate, Delev, Eyes, Factions, Relations, Filter, Graphics, Hair, IIM, Invent, Names, NoMerge, NpcFaces, R.Relations, Relev, Scripts, ScriptContents, Sound, Stats, Voice-F, Voice-M, R.Teeth, R.Mouth, R.Ears, R.Head, R.Attributes-F, R.Attributes-M, R.Skills, R.Description, Actors.Anims, Actors.AIData, Actors.DeathItem, Actors.AIPackages, Actors.AIPackagesForceAdd, Actors.Stats, Actors.ACBS, NPC.Class, Actors.CombatStyle, Creatures.Blood, NPC.Race, Actors.Skeleton, NpcFacesForceFullImport, MustBeActiveIfImported, Deflst, Destructible

Patcher Progress:

A link detailing which records are not functioning in Wrye Bash and an update of what is and isn't finished at this time is available on the Wrye Bash GitHub.

Skyrim Progress

Fallout Progress

I have a very limited knowledge of Python. I will need help if it involves more complex routines. Updating the records is pretty straight forward and sometimes the patchers make sense including reading the specific fields in a record like MGEF or whatever. So I will be able to update some things on my own. I will be posting in the Known Issues section things that have been reported that I cannot update or have not been updated.

Known Issues:

Oblivion:

None at this time.

Skyrim:

  • Keywords are not copied into the Bash Patch.
  • VMAD records from loosing plugins are not copied into the Bash Patch.
  • Some records with repeating sounds like SNDR:ANAM are not carried over into the Bash Patch.
  • Special routine needed to handle INAM for Outfits.
  • LVLD - Chance None is not always utilized. Needs verification because code does look at this value.
  • CTDA conditions not always carried over into bash patch from loosing plugins.
CELL:

Interior cells

XCLW - Field is being blanked out, which may lead to Bash adding unnecessary records. If Bash needs to make a record for the cell, set it to the huge negative value. Otherwise don't import it at all.

Fallout 3:

None at this time.

Fallout New Vegas:

None at this time.

Version numbers will start with 306 but since this is a beta and not an official release I will make incremental updates, 306.0.01, and so on.

Volunteers Needed:

Currently I am looking for volunteers to contribute Wrye Bash. The main focus is updating Wrye Bash's Skyrim Patcher. However, this version also has limited Fallout 3 and Fallout NV support. Wrye Bash is written in Python so I am looking for people who are fairly knowledgeable with that programming language. You need to have Skyrim installed on your system so that you can test your updates to the code. If you wish to help with Fallout support then you should own a copy of Fallout 3 or New Vegas.

If you wish to help please PM me with your GitHub account name and which game mode you are willing to help with. P.S. please be willing to at least proofread my attempts to write Python code for Skyrim even if you prefer not to help with that and don't own a copy of Skyrim.

Link to comment
Share on other sites

Isn't much, I know, but I tossed in 3 more cell flag patchers. C.Encounter, C.ImageSpace, C.LTemplate.

 

C.LTemplate is for the lighting template subrecord (LTMP).

SKPatches.txt

Link to comment
Share on other sites

I don't agree that C.LTemplate is needed as a separate tag, it should be handled by C.Light propagating changes from both XCLL and LTMP subrecords. The reason is the "inherit" flags located in XCLL that affect what values are used from LTMP, and what are local to cell in XCLL. This means that any mod that changes lighting in cells must always have both tags to work properly, so better to use a single C.Light for them.

C.ImageSpace is questionable too. It visually affects only lighting, and only lighting, so merging XCLL and LTMP from one mod, and pulling imagespace from another will cause unpredictable mess. I'm sure that mod authors who change lighting are designing it with imagespace, lighting template and cell lighting values together as a whole. There is no direct data connection between cell's imagespace and lighting values, but logically they are tired and C.Light should handle all of them: XCLL, LTMP, XCIM.

Link to comment
Share on other sites

  • 3 weeks later...

I have very little coding experience, I can't code from scratch but I can modify exsiting code to an extent, I can read error messages and figure out what is wrong and sometimes-most often fix it myself, I have done it for the python versions of Wrye Bash, if u think u can use me then i'm in, if not then...

 

 

....i can be a beta tester if u need any more 

i have been using WB since v291 (python) for Oblivion but  switched to the standalone version the python version was to slow with 280+mods installed. even the standalone trys to lock up with that many mods  :redface:

 

also there is another "Wrye Bash" for FO3 that will not let u create a bashed patch (patcher crashes).

here is the name: Wrye4Fallout3_V06beta-10097

Link to comment
Share on other sites

  • 1 month later...

I don't agree that C.LTemplate is needed as a separate tag, it should be handled by C.Light propagating changes from both XCLL and LTMP subrecords. The reason is the "inherit" flags located in XCLL that affect what values are used from LTMP, and what are local to cell in XCLL. This means that any mod that changes lighting in cells must always have both tags to work properly, so better to use a single C.Light for them.

C.ImageSpace is questionable too. It visually affects only lighting, and only lighting, so merging XCLL and LTMP from one mod, and pulling imagespace from another will cause unpredictable mess. I'm sure that mod authors who change lighting are designing it with imagespace, lighting template and cell lighting values together as a whole. There is no direct data connection between cell's imagespace and lighting values, but logically they are tired and C.Light should handle all of them: XCLL, LTMP, XCIM.

That is useful input. Thanks. I don't know if I will release a new version just yet, but I will try to get that changed so any future versions have it that way. C.LTemplate was added to Skyrim for the LTMP subrecord to cover the Lighting Template. However, I never knew that in Fallout NV it's part of C.Light.
Link to comment
Share on other sites

  • 6 months later...

The RequireVersions in Installers works for Oblivion, will there an equivalent for Skyrim?

This issue was closed summarily with no reason other than the comment at the end of the linked post.

I've seen many packages with nested subfolders grouped for reasons based on common sense in package ordering, perhaps someone can provide an elucidation.

Link to comment
Share on other sites

As I mentioned on the Beth Forums I have withdrawn myself from the forums. I may make an occasional post but that's about it.  If people post something there is a good chance I won't respond.

The reason that the issue ticket was closed is pretty obvious.  Wrye Bash is undergoing some refactoring which I am sure you are aware of. There is no "Team" working on Wrye Bash at this time so please only report an actual bug with the 306.xxxxx versions that Utumno is asking people to test. Make sure you explain how to reproduce the error, links to the mod causing it if it's because of a mod, and especially a traceback. If you can't do that then don't post anything.  From what I can see, all you are doing is just aggravating Utumno.  He seems extremely disinterested in questions about the program's future or feature requests.  Probably because he has been the only person making updates for almost a year now.  He might be getting burned out and may just stop working on things all together.  So I'd suggest leaving him alone and let him work because there may never be another volunteer and without volunteers the project is dead.
 
Also please don't make Wiki pages at all.  Like the one you made recently.  I had to rewrite it and and I was not particularly happy about having to do that.  Wiki Pages should be made by Team members only.  I don't know if GitHub has a way to configure permission for Team members only but if they don't they should.

For the installers I wouldn't want to update how BAIN works. People know what the structure should be and need to use that standard. If they don't then the package won't install. It might make more sense to do it another way but unless someone other then Utumno is going to program it themselves, test it, and share it as a pull request, then it's probably not going to happen. There are far more important things to be working on for now like Skyrim's patchers.

However, I'm waiting to see if the announcement for a possible Fallout from Bethesda is legitimate or not.  If it is legitimate and we are told what the name is and what the release date is, I'll be focusing on an FO4Edit if I can get into the Beta or once the program is released if i can't get Beta access--that's about it.  I have no clue if anything will ever be finished for Skyrim at this point.

 

However, now that Fallout 4 is official I'm going to be waiting for the announcement of the release date.  Then I'll be trying to get into the beta so I can get a jump on the decoding.  That's about it.

Link to comment
Share on other sites

there may never be another volunteer and without volunteers the project is dead.

 

Also please don't make Wiki pages

... :shrug:

Link to comment
Share on other sites

This issue was closed summarily with no reason other than the comment at the end of the linked post.

I've seen many packages with nested subfolders grouped for reasons based on common sense in package ordering, perhaps someone can provide an elucidation.

 

If by "Nested Sub-packages" you mean a sub-package inside a sub-package - That has never been possible in Wrye Bash

 

The boundaries of how BAINs are structured, and how wizards work with them is defined here

 

Scroll down to the box which explains "Structure" - Simple, Complex, Complex/Simple

 

 

Multiple Sub-Packages in a complex installer, are typically named numerically and then alphabetically .. Because that is the internal sequence of installing sub-packages.

 

So whichever sub-package is numerically / alphabetically last, if that sub-package has files which conflict with earlier installing sub-packages .. The last one ticked for installation has its files win

 

00 Core files required \ meshes \ *.nif

05 Plugin option 1 \ plugin.esp

05 Plugin option 2 \ plugin.esp

10 Colour Option 1 \ Textures \ *.dds

10 Colour Option 2 \ Textures \ *.dds

 

Treat all sub-packages as a uniquely named Data \ folder, at the top level of your archive.

And the only things that go in them are what files or folders you would ordinarily find in a data \ folder ( if all BSAs were extracted as loose files ) - So a meshes folder with its content is valid, a textures folder with its content is valid, and an esp or esm is valid .. Screen 13 from Wrye Bash Pictorial Guide - Installers Advanced ( Oblivion files and folders )

 

In the above example, if both 05 sub-packages are selected, then 05 Plugin option 2 \ plugin.esp will be installed ( because it conflicts with, and overwrites the same named esp in 05 Plugin option 1 \ plugin.esp which in the numerical / alphabetical sequence of installation loses )

 

 

Its also typically why when you try to teach someone who is used to creating Fomods, they initially think it strange that everything cannot be in multiple folders inside sub-packages - Fomods structure has no bearing on the installation order of files within a zip, its entirely driven by the moduleconfig script and its prioritisations.

 

A long list of sub-package overwrites may seem a bit cumbersome to manage, but when you have many BAINS with multiple complex overwrites - between BAINs - The reason for this method is to benefit efficiency of the BAIN installation, and conflict resolution of the whole installation set.

 

 

Edit : You could also have the above example sub-packages named like this ...

 

A Core files required \ meshes \ *.nif

B Plugin option 1 \ plugin.esp

C Plugin option 2 \ plugin.esp

D Colour Option 1 \ Textures \ *.dds

E Colour Option 2 \ Textures \ *.dds

 

or

 

00 Core files required \ meshes \ *.nif

05 Plugin option 1 \ plugin.esp

05 Plugin option 2 \ plugin.esp

A Colour Option 1 \ Textures \ *.dds

B Colour Option 2 \ Textures \ *.dds

 

( Numerical, then Alphabetical - I tend to stick to numerical, so that Windows does not confuse me with the folder sequence when I am building a package )

 

You can also add more numerical increments for more sub-package flexibility for options in-between

 

0-10 only has ten possible sub-packages

 

Whereas in the following there is more scope for adding sub-packages in between at a later date ( when one option has more options developed .. )

 

000

001

001

002

005

010

015

015

020

050

100

999

Link to comment
Share on other sites

If by "Nested Sub-packages" you mean a sub-package inside a sub-package - That has never been possible in Wrye Bash

The boundaries of how BAINs are structured, and how wizards work with them is defined here

Yeah thanks Alt, I'm au fait with all that.

It's just part of the original design which hasn't been reviewed in years. For anyone looking at it for the first time, it seems a little strange that we can select/deselect espms no matter where they live, but can only touch top level packages with SelectSubPackage.

It's flexibility the issue, with also a "kinder" debugging from BAIN while testing bugged installers... being sought.

 

As I mentioned on the Beth Forums I have withdrawn myself from the forums. I may make an occasional post but that's about it.  If people post something there is a good chance I won't respond.

The reason that the issue ticket was closed is pretty obvious.  Wrye Bash is undergoing some refactoring which I am sure you are aware of. There is no "Team" working on Wrye Bash at this time so please only report an actual bug with the 306.xxxxx versions that Utumno is asking people to test. Make sure you explain how to reproduce the error, links to the mod causing it if it's because of a mod, and especially a traceback. If you can't do that then don't post anything.  From what I can see, all you are doing is just aggravating Utumno.

He seems extremely disinterested in questions about the program's future or feature requests.  Probably because he has been the only person making updates for almost a year now.  He might be getting burned out and may just stop working on things all together.  So I'd suggest leaving him alone and let him work because there may never be another volunteer and without volunteers the project is dead.

I understand. I'm not testing it, so have opted for the stable 3.05 at Nexus. Did check all open and closed issues for duplication.

Utumno? Sensitive fellah. I'll leave well enough alone then.

 

Also please don't make Wiki pages at all.  Like the one you made recently.  I had to rewrite it and and I was not particularly happy about having to do that.  Wiki Pages should be made by Team members only.  I don't know if GitHub has a way to configure permission for Team members only but if they don't they should.

noun: wiki; plural noun: wikis

a website or database developed collaboratively by a community of users, allowing any user to add and edit content.

Sorry, I guess Github's definition of Wiki differs from what I thought it was (and the first one popping up in Google.)

But yeah, point taken. No touchies.

 

For the installers I wouldn't want to update how BAIN works. People know what the structure should be and need to use that standard. If they don't then the package won't install. It might make more sense to do it another way but unless someone other then Utumno is going to program it themselves, test it, and share it as a pull request, then it's probably not going to happen. There are far more important things to be working on for now like Skyrim's patchers.

However, now that Fallout 4 is official I'm going to be waiting for the announcement of the release date.  Then I'll be trying to get into the beta so I can get a jump on the decoding.  That's about it.

Fair enough, you'll have plenty on your plate then. On my todo list is learning Python 3 and rewriting the Bain Installer section with it, and then implementing all the aforesaid enhancement requests.

Yep, there's a fine list of them that won't go away, sitting in the "Closed" section of Github. :P

 

RequireVersions would also to be nice to implement for each game. That shouldn't be too difficult.

And, you bet, if no-one else does, I'll make it my Opus Majus to ensure that WB gets that long awaited a drag 'n drop feature for Installers.

Link to comment
Share on other sites

On my todo list is learning Python 3 and rewriting the Bain Installer section with it, and then implementing all the aforesaid enhancement requests.

 

A well intentioned good luck from me, Utumno is doing one hell of a job but really could do with a like minded person who is capable

 

Have you ever seen the BAIT code which Myk002 started ? - ( BAIT = Bash Asynchronous Installer Tab )

 

I dont know if it was moved as part of the project to GitHub, but that was a WIP overhaul of the Installers which was looking very promising at one time, and maybe a good design head start on what you wish to achieve.

 

Its still in the old Sourceforge Experimental folder http://sourceforge.net/p/oblivionworks/code/HEAD/tree/Programs/Wrye%20Bash/experimental/bait/

 

In the Docs is a mockup image of the proposed GUI

 

gui_mockup.png?format=raw

Link to comment
Share on other sites

  • 2 weeks later...

Well no, Deactivated does not mean the same as Deselected - There are different states at play which Wrye Bash needs to distinguish, you can deactivate to Wrye Bash's merged state ( + ), once it is merged ( which Wrye Bash automatically asks to do ) .. Which does also mean for us that the mod is effectively deselected because the whole of it has been incorporated in the bashed patch. But Wrye Bash still needs to indicate to us that it has been merged and is not just completely deselected, its a visual indicator that the merge has happened on the last rebuild of the bashed patch.

 

You may also need the whole mod package still installed because of the mods additional resources which were installed ( custom meshes / textures etc ), so having it merged and not selected at all might indicate to some that they dont need the mod at all if we did not have the + .. Which would be wrong, and you need the esp still to be there for any future rebuilds so that you still merge it everytime thereafter.

 

 

So the first statement is still correct ..

"Plugins that contain only certain types of data records can be merged into the Bashed Patch. This then allows these plugins to be deactivated, freeing up space in your load order."

 

It becomes deactivated to the merged state (+) ( not fully deselected or disabled .. Nothing in the check box )

 

And dont forget that plugins can be partially merged, instead of fully merged ; The + is for the latter not the former

 

And it no longer counts towards the maximum amount of plugins you have selected

 

 

The second statement does still apply - You just need to experience a mod which triggers it when you go to rebuild your bashed patch  :) ( look for plugins with their name coloured green )

 

oKj8V9b.jpg <-- Here's the automatic deactivation question

 

XW0s42Y.jpg <-- checkboxes ( Merge Patches Section, and Mods to Merge )

 

hENCeo9.jpg <-- After the build auto-deactivation has occurred

 

 

The above happened automatically as I would expect it to do after choosing Rebuild Bashed Patch

 

But you can manually cycle the states between no check, checked, or +, or dot for mods with imported records .. where it does apply, and I think the reason for that is probably a rare circumstance but imagine a fully merged plugin as being a master of a later loading mod, it would still need to be selected ( not any of the other Wrye Bash states ), so you can cycle through the potential states of that particular plugin after a bashed patch is made with multiple clicks on the checkbox.

 

The whole description still makes sense to me  :shrug:

 

No Check, or just a plus .. both equal Unchecked as far as other Mod Managers are concerned ( and the load order .. notice in the above screenshots the merged plugin does not have a hexadecimal load order number )

But for Wrye Bash those extra states of deactivation need to be distinguished and have purpose.

 

 

For Oblivion I used to have quite a few mods which were green ( fully mergeable ) - There are three of them in a screen I did for Wrye Bash Pictorial Guide :

 

35230-1-1343151472.png

 

The wording in these screens were discussed in detail with the Wrye Bash team on BGS Forums, so that my simplification of the Wrye Bash Readme wall of text at the time .. Did not become inaccurate

 

See also section 5 C. of the General ReadMe ( help icon on Wrye Bash Toolbar ) - Setting up load order - What Symbols & Colour mean

( Its also online, but those checkbox images need fixed at the moment http://wrye-bash.github.io/docs/Wrye%20Bash%20General%20Readme.html#load-symbols - See the following issue https://github.com/wrye-bash/wrye-bash/issues/215 )

 

( And before anyone tells me about the mod sandboxcylinderheight I am using is now an option in the Bashed Patches Tweaks ( NPC Vertical Object Detection - Does the same as that mod if you set it to x2 ) now so the mod is no longer needed .. I know but while I am experimenting with Smashed Patch I do still need it, Mator Smash does not do Wrye Bash build Tweaks )

gy6m9OY.jpg

Link to comment
Share on other sites

@Alt

Thanks for clearing it up.

The confusion arises with the statement "This then allows these plugins to be deactivated, freeing up space in your load order".

Suppose we have a plugin merged into the Bashed Patch. We click on it, and it becomes activated with a green tick. What happens then? Does the Bashed patch still merge it? On first impressions one clicks on it expecting it to be de-activated in accordance with the doc description.

Would it be clearer if the statement was reworded:

 

"... This then auromatically places thes plugins in deactivate mode, freeing up space in your load order. They can be re-activated to revert the changes just made in the BP."

If they were re-activated, does the BP need a rerun? This should be documented as well.

Re the second statement, I have never seen that de-activate dialogue, but great, we know it's there. Let's look at it again:

 

Once the Bashed Patch is built, these plugins can then be deactivated (Wrye Bash will ask to do this for you).

 

Wrye Bash will ask to do this for you after? building the BP- or before?

Would it be clearer if it were

"Once the Bashed Patch is built, all merged plugins will have deactivate status (Wrye Bash will ask to confirm de-activation of recently added mergeable plugins before building the patch).

Link to comment
Share on other sites

@Alt

Thanks for clearing it up.

The confusion arises with the statement "This then allows these plugins to be deactivated, freeing up space in your load order".

Suppose we have a plugin merged into the Bashed Patch. We click on it, and it becomes activated with a green tick. What happens then? Does the Bashed patch still merge it? On first impressions one clicks on it expecting it to be de-activated in accordance with the doc description.

 

If you activate the mod after you have merged it - What happens then is you have an activated mod that also is merged into the bashed patch, the bashed patch loading last will be used for this data.

When it comes to the next rebuild of the patch, you will be asked again if you want it deactivated as it did the previous time. The point is in between builds it is possible for it to be manually set different to what the automatic deactivation would set it at. The different states are more options for manual selection aswell as automatic

 

Would it be clearer if the statement was reworded:

 

"... This then auromatically places thes plugins in deactivate mode, freeing up space in your load order. They can be re-activated to revert the changes just made in the BP."

The wording as is seems to be clear enough to me as previously mentioned - Maybe you just need to experience what it is trying to describe ?, I mean how can you propose to change the wording when by your own admission you have not experienced what is being discussed ?.

 

 

If they were re-activated, does the BP need a rerun? This should be documented as well.

 

Why would it need a rerun ?. What you intended on the last run happened, it was merged into the bashed patch

If you then reactivated it with a tick, as mentioned above the bashed patch loading last will have its merged data used instead of the earlier loading plugin that has been reactivated, and you would be taking up a plugin slot unnecessarily

( unless of course you had a valid reason for needing it to be reactivated taking up that slot, for instance in case of a later loading mod having this mod as a dependancy as mentioned in the last post ) - Going round in circles here.

 

 

Re the second statement, I have never seen that de-activate dialogue, but great, we know it's there. Let's look at it again:

 

 

Wrye Bash will ask to do this for you after? building the BP- or before?

Would it be clearer if it were

"Once the Bashed Patch is built, all merged plugins will have deactivate status (Wrye Bash will ask to confirm de-activation of recently added mergeable plugins before building the patch).

No, all you are managing to describe there is the auto deactivation, what about the new possibilities of manually being able to set the different states by clicking the check box multiple times ?, the way you have described it skips that part .. again its already clear ..

 

 

Once the Bashed Patch is built, these plugins can then be deactivated (Wrye Bash will ask to do this for you).

Reference your question after or before building the bashed patch ..

 

"Once the bashed patch is built," <<-- This is past tense, it has happened already, therefore :

" these plugins can then be deactivated (Wrye Bash will ask to do this for you)." <<-- Then either of these apply after the bashed patch has been built ( as it says at the start of the sentence ) - Wrye Bash will deactivate automatically, but it is also now recognised by Wrye Bash as a merged plugin so manual deactivation / reactivation / setting any one of multiple states manually is also now possible for the user - The word Deactivate in that sentence to me describes the action of manually clicking the check box to put it into a different state - All just condensed into one sentence which no matter how I look at it still makes sense.

 

Built / Building / Build - Past / Present / Future

Why not try to find mods which do what is being described, and then you will understand it ?.

Maybe it is written in minimal programmer logical accurate dialogue and is confusing to someone not used to it.

Grab some mods and experience what it is trying to tell you .. Maybe you could refine the docs a little in a way I or the previous Wrye Bash team who understood it initimately do not see, but you need to convey all points of what is already being described adequately ( not just the parts of it you think you have a grip on, cutting out valuable parts of the description sentences, that would be a backward step for the documentation ) .. and imho I still cant see a need to change it at all.

Link to comment
Share on other sites

Why not try to find mods which do what is being described, and then you will understand it ?.

Maybe it is written in minimal programmer logical accurate dialogue and is confusing to someone not used to it.

Grab some mods and experience what it is trying to tell you .. Maybe you could refine the docs a little in a way I or the previous Wrye Bash team who understood it initimately do not see, but you need to convey all points of what is already being described adequately ( not just the parts of it you think you have a grip on, cutting out valuable parts of the description sentences, that would be a backward step for the documentation ) .. and imho I still cant see a need to change it at all.

Thanks Alt, I'm just putting myself in the shoes of someone reading it for the first time. :)

These days, no-one has the time to read anything of a technical nature, most of them I notice just say "f.. this" and run off to use MO or NMM or something. Well that's their prerogative really, but it's yet another customer walking out the door empty-handed. :P

I really like this readme, it's stood the test of time, albeit as the program evolves it probably could do with a bit of a touch up here and there, nothing more. Maybe all that's needed is a link to a merged/imported plugins tutorial that details all this stuff in a links section somewhere.

If anyone else is interested I can post a draft of an expanded version of the Merged Plugins section highlighting all points discussed so far.

Link to comment
Share on other sites

Weeeell :) - That was the objective of the Wrye Bash Pictorial Guide ( Basics guide ), for a quick intro to get people up and running, without much fuss they just follow 7 screens of info and they are away using it. Then they move on to Intro to Installers, and quite often the advanced guide aswell, whereas before WBPG they may have given up because the old wall of text ( before Wrinklyninja reformed it to the current split up htmls ) was even worse than it is now.

 

Usually people start to consult the wall of texts under the help icon in Wrye Bash as they start to get more used to it and curious about capabilities.

But then there are people who have used it for years and not realised there are hidden right click menus in some places for instance, the power of which only becoming apparent the more advanced the user is.

 

 

An overhaul of the UI and tooltips could still happen after all the refactoring, as could a Skyrim Wrye Bash Pictorial Guide which I am still wanting to do time permitting, maybe August / September ish ( there are RL events coming up which could change my participation with anything completely ) - Its nearly at the point where I wanted to start the new guide.

Link to comment
Share on other sites

I posted this on the NEXUS forum for Wrye Bash, and was linked to this topic where I presume it ties into the conversation, so I joined and have slightly modified my original post  to the following.

 

 

 

 

I am using the latest "Wrye bash" (except it is calling itself "Wrye smash"?) And everything is working as expected except for something to do with merging patches. When I rebuild the bashed patch it offers several mods for merging, and I am making sure they are all selected (checkmarked) including the merge section, and it seems to have no issues building the bashed/merged patch.

 

What happens then confuses me. The Wrye bash instructions say that after it is finished merging patches it is then safe to disable the merged mods. I quote from the help faq for clarity:

 

-----------------------------------------------------------------------------------------------

Merging Plugins

 

Plugins that contain only certain types of data records can be merged into the Bashed Patch. This then allows these plugins to be deactivated, freeing up space in your load order.

 

You should check the checkboxes of all the plugins listed in the Merge Patches section, and ensure the section is checked too. Once the Bashed Patch is built, these plugins can then be deactivated (Wrye Bash will ask to do this for you).

------------------------------------------------------------------------------------------------

 

Only Wrye bash/smash does NOT ask to do this for me, and if I select one of the green texted mods that was supposedly merged and uncheck it a plus sign shows up in the box rather than a checkmark. When I run the game at that point it tells me so and so mod is missing and things dependant on it may not work.

 

Is that normal? Is that what I am supposed to do? Uncheck the merged mods (since Wrye bash/smash isn't asking to do it for me) and ignore Skyrim saying so and so mod is missing?

 

 

 

 

Edit:  Ok, The problem is this instead:

 

If I add any further mergeable mods AFTER there is already an existing Bashed patch, Wrye Bash does NOT provide the deactivation popup again when I rebuild the patch.

 

I deleted my Bashed patch and then reran Wrye bash whereupon it built a new empty bashed patch which when I told it to rebuild it THEN asked me if I'd like to de-activate the mergeable mods BEFORE building the patch. I then clicked yes. It deactivated them (removed any checkbox + sign or . ) THEN built my bashed patch and changed the deselected mods to a green box with a +. 

 

However, If I add any further mergeable mods it will NOT then ask me if I'd like to disable those as well before updating my bashed patch.

 

In addition my skyrim still tells me that my save requires mods that are now missing when I run it after all this. None are missing, only unselected (the green + in wrye bash).

 

So I have now figured out what needs to be done before rebuilding your patch is to deselect the mergeable mods since Wrye bash does NOT ask you after the first merge.

 

And no, the phrasing in the faq:

 

-You should check the checkboxes of all the plugins listed in the Merge Patches section, and ensure the section is checked too. Once the Bashed Patch is built, these plugins can then be deactivated (Wrye Bash will ask to do this for you).-

 

is not at all clear, as it states specifically: "Once the Bashed Patch is built, these plugins can then be deactivated (Wrye Bash will ask to do this for you)."

 


The word Then has the following definition:

 

then
adverb \ˈthen\


: at that time : at the time mentioned


—used to indicate what happened or happens next


—used to indicate what should be done next




 


 

Once/after the Bashed Patch is built, these plugins can then/after be deactivated (Wrye Bash will ask to do this for you) afterwards.  Is how this sentence reads..

 

This phrasing indicates that you are to build the bashed patch first and THEN Wrye bash will ask you if you'd like to deactivate the merged mods.

 

It should read:

 

-You should make sure all the checkboxes of the mergeable mods are unchecked in the main list. Wrye bash should automatically ask to do this when beginning the rebuild bashed patch process, but cancel and do so manually if it does not.  Then in the rebuild bashed patch popup make sure the checkboxes of all the plugins listed in the Merge Patches section are checked, and ensure the section for merged patches is checked too.-

 

That is clear, tells you what order things should occur in, and what to do if they do not occur.

 

At the very least it should read:

 


-You should check the checkboxes of all the plugins listed in the Merge Patches section, and ensure the section is checked too. Once the Bashed Patch is built, these plugins can then be deactivated (Wrye Bash will ask to do this for you at the beginning of the process).-

 


 

 

 

And none of this answers my question regarding whether or not something is wrong with my skyrim saying mods are missing after creating a bashed/merged patch which I'd still very much like to know.

 

Please pardon my frustration, I've spent 3 days poring over the Wrye bash faqs, looking things up online, watching youtube tutorial videos, and pulling my hair out figuring this out.

Link to comment
Share on other sites

Sounds like you have a version of Wrye Bash which still has that bug ( ie the none-auto deselection of merged patches )

 

Its fixed in 306, which Utumno is currently trying to release ( See this closed issue #157 )

 

And once you are running the newer versions of Wrye Bash after release the documentation will make sense again for you.

 

I am using Utumno's development standalone version as posted at the end of the second post in the oblivion forum ..

http://forums.bethsoft.com/topic/1518379-wrye-bash-thread-103/#entry23976631

If you want to try it, just grab the standalone download, extract its zip, and in there you will find a Mopy\ folder, just copy that Mopy folder into your Skyrim\ folder ( so that it should ask you to overwrite your existing Mopy\ folder )

.. You now have the new Standalone installed, and bug fixed.

When the new release comes out, it will probably be newer than that version, but the new installer will just overwrite what you just manually installed so no worries about using it. Also the Uninstaller will not be broken should you wish to, it will uninstall the manually installed files just like it would the old files you just overwrote :)

 

Unless you are using a full Python installation instead of the standalone, in which case I think you could grab the other file and again extract / overwrite the mopy folder ( I havent tried it )

 

 

Also Wrye Bash for Skyrim has adopted a new name - Wrye Smash, which you can change in the settings ( gear icon in the tool bar )

Thats documented here http://wrye-bash.github.io/docs/Wrye%20Bash%20Advanced%20Readme.html#tools-settings

( In the screenshot "Use alternate Wrye Bash name" - Ticked by default )

 

 

Edit : Reference missing masters - Before your mod became deselected, did you have any other kinds of patches which prior to you deselecting the merged plugin ( from a tick to a + ) .. Then those patches need to be rebuilt without your previously active plugin which is now merged ( I'm talking about SkyProc or ReProccer or whatever other patching methods you may have used in addition to the bashed patch )

 

When you left click to highlight a plugin on the mods tab you notice you get Info in the panes on the right ..

http://wrye-bash.github.io/docs/Wrye%20Bash%20Advanced%20Readme.html#mods-details

 

If you left click some of your later loading mods ( loading later than the deselected mod ), you will notice in the Info panels there is a masters list, that is where you will find the plugin which has your deselected mod as a master ..

 

.. and if it is not some kind of patch, then you do need to reselect ( with a tick ) your deselected mod - As explained earlier in this topic, if this is the case, then that would be one of those rare hypothetical cases where a merged mod could still be a master and needs to be manually reselected after an auto-deselect ( which is not currently working correctly for you because you have a buggy Wrye Bash ).

 

I think that probably covers your problems.

Link to comment
Share on other sites

Thank you for replying so quickly :)

 

Yep, I'm using using V305 from Nexus (non python).  I'll try using V306 like suggested and see what happens.  

 

As far as other mergers though, no I don't use anything you mentioned.  The tools I am using are NMM, Loot, and Wrye Bash/Smash in that order.  I am also using FNIS, and SKSE, though I don't think either of those would have anything to do with it, and I installed all of these tools manually.

 

Anyways, I'll give V306 a try out.  :)

Link to comment
Share on other sites

  • 1 month later...

I tried out Wrye Bash 306.0.24-Experimental - Standalone Executable. I get this error whenever I deactive or move plugins down the list.

Traceback (most recent call last):
  File "bash\basher\__init__.pyo", line 1017, in OnLeftDown
  File "bash\basher\__init__.pyo", line 1069, in _checkUncheckMod
  File "bash\bosh.pyo", line 4219, in refresh
  File "bash\bosh.pyo", line 4394, in reloadBashTags
  File "bash\bosh.pyo", line 3575, in reloadBashTags
  File "bash\bosh.pyo", line 5275, in getBashTags
  File "bash\loot.pyo", line 364, in GetModBashTags
  File "bash\loot.pyo", line 231, in LootErrorCheck
bash.loot.LootError: LootError: loot_error_no_tag_map:No Bash Tag map has been previously generated.

Wrye Bash 306.201504212256 works fine.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...