Jump to content

Wrye Bash - All Games


Utumno

Recommended Posts

It would appear some of this kind of parsing (or at least detection) is already happening. If you have an unconverted form v43 mod loaded you get this exception when building your Bashed Patch:

Spoiler

CreaNur.esp:
Wrye Bash SSE expects a newer format for STAT.DNAM than found.
Load and save CreaNur.esp with the Skyrim SE CK
STAT.DNAM: Expected size == 12, but got: 8
Error loading 'STAT' record and/or subrecord: 0417E50C
  eid = u'10_Slaughterfish'
  subrecord = 'DNAM'
  subrecord size = 8
  file pos = 252878
Error in CreaNur.esp

 

The mod used for testing was Creatures House.

 

Link to comment
Share on other sites

@Utumno I've been thinking of doing this for a while so this morning I experimented with sorting the options on the package installer right-click menu (in links.py). 

The goal was to group commonly used actions at the top, move "tricky" options out of the way so you have to explicitly click them, and to group similar functions.

Here's what it looks like. If you think I should add it as an enhancement/milestone I'll take ownership of it.

https://imgur.com/a/tsuNs

Link to comment
Share on other sites

After restarting wb with barely 100 mods installed it decided to calculate CRC for each and every file. Took over 8 minutes. When I used the standalone with over 400 installers it did calculate CRC, but only if I deactivated the "skip bethsoft content" option and never ever took as long with that many mods. This time I do have the skip beth content option active...

Another question: what should I do with the scripts folder that comes in the wrye-bash.dev.zip?

Edit: replaced the nightly build with the bleeding edge from 1st page and had no crc calculation problems. Lightning fast :) Previous question stands, though - don't know where to put the scripts folder that comes zipped with the mopy folder.

Link to comment
Share on other sites

Is there a way to do away with dummy esp's to load archives in wrye bash? If not, could it be a feature to implement in the future? Is there any other way to tell the game to load them in that particular instance in the load order (I think there's an ini line to load base game archives, maybe it could be used to load other archives, but what about load order)? I don't like having to unpack archives for any other reason, but dummy esp's are a reason.

Link to comment
Share on other sites

You can't implement such a feature because it would go against Bethesda's design.  BSA/BA2 files do not load unless the parent ESP/ESM file is active. For example the official Hi-Res packs.  This is why when merging mods with Wrye Bash, if they have an accompanying BSA/BA2 file you have to unpack the Bethesda archive and install the contents as loose files. For example Somemodname.esp qualifies to be merged and has an archive Somemodname.bsa (older games) Somemodname - Main.bsa (newer games). Once Somemodname.esp is merged into the Bash Patch and disabled, the BSA/BA2 will not load. All meshes, textures, scripts, or any other assets would not load because the parent ESP/ESM file is disabled.

Link to comment
Share on other sites

10 hours ago, Sharlikran said:

You can't implement such a feature because it would go against Bethesda's design.

But somehow I know of two instances where this was overcome. The Optimized Vanilla Textures (nexus 57353) implements its bsa packs by adding the archive names to the list in the ini - maybe that works because it sort of replaces the hi-res packs, with different filenames. You do have to run a .vbs script that basically adds the archive filenames to sResourceArchiveList2. In this instance, load order doesn't really matter because you want these textures to load first and be partially replaced by other textures. Then you got MO and its archive management feature, that I have no idea how it works, only that you can do without the dummy esps. There should be a way, then, to not only load the archives, but load them in the correct order.

Link to comment
Share on other sites

1 hour ago, godescalcus said:

But somehow I know of two instances where this was overcome. The Optimized Vanilla Textures (nexus 57353) implements its bsa packs by adding the archive names to the list in the ini - maybe that works because it sort of replaces the hi-res packs, with different filenames. You do have to run a .vbs script that basically adds the archive filenames to sResourceArchiveList2. In this instance, load order doesn't really matter because you want these textures to load first and be partially replaced by other textures. Then you got MO and its archive management feature, that I have no idea how it works, only that you can do without the dummy esps. There should be a way, then, to not only load the archives, but load them in the correct order.

The methods are detailed in the topics Lojack and Wrinklyninja found out on the old Bethesda forums, I duplicated it here ..

The first method you mention is called Registered BSAs (I helped Tony with the methods he uses, mostly with Wrye Bash help via PM on Nexus, which as you say needed a script to do a few manual tasks which Wrye Bash cannot perform, on behalf of the average user to ensure they all got the setup right).

MO can get around it by feeding any loose files or files within archives to the game on the fly by intercepting the games calls for files all the time with its VFS (thats why MO has to be running in the background so that this all works) .. Wrye Bash cant do that. Utumno would have to programme Wrye Bash from the ground up to use its own Virtual File System, heavens forbid that ever happens :P

The better method these days though is to use the dummy plugin method, so that you can load order your mass texture replacers, and have those overridden with other texture BSAs loading later, or loose files when necessary.

You have had all of this explained before though, in response to this post you made.

Link to comment
Share on other sites

2 hours ago, alt3rn1ty said:

he better method these days though is to use the dummy plugin method, so that you can load order your mass texture replacers, and have those overridden with other texture BSAs loading later, or loose files when necessary.

You have had all of this explained before though, in response to this post you made.

Sorry for insisting... It's cumulative learning ;P The news this time was the method you mentioned that mo uses to feed files into the game when requested. I too have become less fond of the vfs, even though my lay knowledge of things doesn't let me pass an informed judgement. Maybe my system is just not strong enough, but it's no potato and wrye bash does the trick just fine where mo would lag as far as npc's "laying around like lemons", as soon as the first visit to riverwood. I'm sure I must have screwed up somehow because so many others are using the same mod list as I am, with mo, and don't report the same problems. But since wb works for me, it's fine. Shame about relinker (but not being able to use it makes me think before merging mods, and, in general, merge less).

Edit_ I give it to you that reading all of the documentation linked to your link finally yielded Tannin's own view on archive management within mo. I hesitate whether to like or dislike the fact that load order in mo is yielded by an algorithm instead of simple last-one-wins.

Link to comment
Share on other sites

Maybe other people using the guide you are using also use MO's more advanced (but ill advised if you are not an expert user) features of extracting BSAs and completely undermining the Load Order system that is best left in place, with MOs priorities.

 

I recall a long argument on the S.T.E.P forum where the resident experts on the subject were eventually pulled up short by Tannin for getting it all wrong for a few years (and influencing thousands of misguided people, who form the basis of the majority of MO users today, and their guides .. The damned thing caused a plague of misadventure imho).

Eventually the advise on S.T.E.P was amended, MO had its more advanced and potentially damaging features hidden and turned off by default. So maybe the guide you are using needs more advanced understanding ? (not only of the tools being used, but also your machines capabilities and what you are feeding it to handle which it is maybe not quite capable of - NPCs laying around like lemons sounds like either a bad ini edit to memory allocations, or you are overloading the game with heavy scripts your CPU cant keep up with juggling .. Or another possibility on that could be an old Combat / Anim mod which has been removed at some point which your game save was dependant upon, and you continued playing onwards, though I dont think you would make such a mistake so not sure on suggesting that one - Any significant Load Order change can also result in such problems, surprisingly, especially if you play on afterwards with a save which was dependant upon the previous load order, Crushboss (Animal Tweaks and Combat Evolved) gets a few reports of such issues periodically which are due to those mistakes being made, typically the old Oblivion NPCs going into crucifix pose but still moving towards you like a Monty Python animation can be a result of Load order changes involving Combat mods, and that problem can still happen in Skyrim)

Link to comment
Share on other sites

16 hours ago, Sharlikran said:

You can't implement such a feature because it would go against Bethesda's design.  BSA/BA2 files do not load unless the parent ESP/ESM file is active. For example the official Hi-Res packs.  This is why when merging mods with Wrye Bash, if they have an accompanying BSA/BA2 file you have to unpack the Bethesda archive and install the contents as loose files. For example Somemodname.esp qualifies to be merged and has an archive Somemodname.bsa (older games) Somemodname - Main.bsa (newer games). Once Somemodname.esp is merged into the Bash Patch and disabled, the BSA/BA2 will not load. All meshes, textures, scripts, or any other assets would not load because the parent ESP/ESM file is disabled.

Bash will not mark as mergeable the files if it detects that they have an associated BSA/BA2 (or voices dir). This was buggy I fixed it recently (well not so recently)

5 hours ago, godescalcus said:

But somehow I know of two instances where this was overcome. The Optimized Vanilla Textures (nexus 57353) implements its bsa packs by adding the archive names to the list in the ini - maybe that works because it sort of replaces the hi-res packs, with different filenames. You do have to run a .vbs script that basically adds the archive filenames to sResourceArchiveList2. In this instance, load order doesn't really matter because you want these textures to load first and be partially replaced by other textures. Then you got MO and its archive management feature, that I have no idea how it works, only that you can do without the dummy esps. There should be a way, then, to not only load the archives, but load them in the correct order.

Bash will read the ini files and be aware of the extra bsas - this is largely untested as mods that use inis are very rare but the functionality is there

Link to comment
Share on other sites

3 minutes ago, Utumno said:

Bash will not mark as mergeable the files if it detects that they have an associated BSA/BA2 (or voices dir). This was buggy I fixed it recently (well not so recently)

 

I remember you mentioning that was something you wanted to look into. Thanks for adding that.

Link to comment
Share on other sites

Hey guys, just noticed that when I install a mod containing DynDOLOD information (usually a DynDOLOD folder along with the normal bain folders, files and archives) Wrye Bash doesn't install that directory by default. I think the workaround for this is currently the "has extra directories" option, which I couldn't test thoroughly because I had already copied the folder manually to Data. But after using that option, uninstalling and reinstalling the mod, it's no longer showing grey background and the needed directories are installed. This just seem a bit "advanced", if you know what I mean. May give a bit of trouble to the average user or the user will have incompletely installed mods. Since DynDOLOD is pretty popular, maybe wrye bash could be made to work with its configuration files out of the box?

Link to comment
Share on other sites

1 hour ago, godescalcus said:

Hey guys, just noticed that when I install a mod containing DynDOLOD information (usually a DynDOLOD folder along with the normal bain folders, files and archives) Wrye Bash doesn't install that directory by default. ~snip~

 

It does install very easily out of the box - You can install DynDOLOD anywhere (When you launch its exe it detects where your game is installed), its only the resources BAIN you need to install in Data, and I helped Sheson to make the BAIN for those files :

 

 

That guide is for Skyrim LE, but even if you are using the DynDOLOD beta for Skyrim SE its very much the same (minus we dont have PapyrusUtil yet until that has been republished for SSE and SKSE64) .. The setup just doesnt have the Dynamic part of DynDOLOD for SSE .. otherwise it works great.

If mod authors are including a DynDOLOD folder as part of a BAIN for install into Data, I think they are doing that just to include the files, they have certainly not been advised by Sheson that the DynDOLOD folder should be in data, because Sheson went out of her way to make the Utility Standalone and Installable anywhere just like any other tool. For example we would not expect LOOT to be installed in Data.

I have mine in the root of my second hard drive partition

6ANwn70.png

Link to comment
Share on other sites

2 hours ago, alt3rn1ty said:

It does install very easily out of the box - You can install DynDOLOD anywhere (When you launch its exe it detects where your game is installed), its only the resources BAIN you need to install in Data, and I helped Sheson to make the BAIN for those files :

Hi alt3rn1ty, I'm running DynDOLOD without a problem, also thanks to your literature ;) It's the other mod that concerns me, the old Spice of Life Forts. It contains a DynDOLOD folder with scripts that are important for the mod to be correctly assimilated by DynDOLOD. Sheson confirmed me that it should go into the Data folder, or alternatively into the edit scripts folder within DynDOLOD. Pretty easy, but non-standard and the mod's description doesn't say anything about the folder, nor do any documents contained in within the mod. On one hand it's understandable since the mod is no longer supported by its author and its page is maintained by The Caretaker at nexus. The motive of my post was to suggest that WB might have the ability to automatically copy a "DynDOLOD" folder to the data folder, as other mods use the same procedure. How about FNIS and its "tools" folder? I'm ready to agree that the list of exceptions can grow indefinitely and as it stands, you can manage it with the "has extra directories" option but, again, it's less than standard and perhaps makes for a little bit of wb's reputation of being difficult to use. How about a feature similar to the BAIN sub-packages? Not directly applicable, it seems to me, because this "DynDOLOD" is not a directory containing BAIN standard folders and files, it needs to go into Data itself. I mean, there has to be a "DynDOLOD" folder inside the data folder for DynDOLOD to read its contents and use them. But maybe this is not a good practice, since these folders are not read by the game at all. The problem is, when using a mod manager, you're usually only managing the data folder (whether real or virtual). So, either these mods have to include a manual installation instruction for the extra files, or the mod managers have to widen their scope. Thinking about it like this, it doesn't sound very promising (although mo handles it because it copies everything into its virtual data folder and feeds it to applications running insider it). But on a wrye bash installation a lot of these "extra folders" just clutter up the data folder. I don't think it'll impact the game (which should simply ignore these folders) but still...

Link to comment
Share on other sites

19 hours ago, godescalcus said:

Hey guys, just noticed that when I install a mod containing DynDOLOD information (usually a DynDOLOD folder along with the normal bain folders, files and archives) Wrye Bash doesn't install that directory by default. I think the workaround for this is currently the "has extra directories" option, which I couldn't test thoroughly because I had already copied the folder manually to Data. But after using that option, uninstalling and reinstalling the mod, it's no longer showing grey background and the needed directories are installed. This just seem a bit "advanced", if you know what I mean. May give a bit of trouble to the average user or the user will have incompletely installed mods. Since DynDOLOD is pretty popular, maybe wrye bash could be made to work with its configuration files out of the box?

In the meantime until a decision is made by the maintainer, if you need to install that change this. Unless you aren't using a Python install.

Mopy\bash\game\skyrim\__init__.py

dataDirsPlus = {
    u'skse',
    u'ini',
    u'asi',
    u'skyproc patchers',
    u'calientetools', # bodyslide
    u'dyndolod',
}

 

Link to comment
Share on other sites

38 minutes ago, godescalcus said:

LOL I can see that there was already an exception for caliente's, that's good! How about adding one more:


dataDirsPlus = {
    u'skse',
    u'ini',
    u'asi',
    u'skyproc patchers',
    u'calientetools', # bodyslide
    u'dyndolod',
    u'tools', # FNIS
}

 

Yes I agree the tools recognition needs to be updated to include the newer tools like DynDOLOD (which isn't really new at all) and FNIS. You will still need to install the executables outside of the data dir and use a trick to keep them safe from the "Clean Data" action.

I posted an example of how to do this at the bottom of this guide for BodySlide, and the same could be done for the FNIS executables.   https://github.com/wrye-bash/wrye-bash/wiki/[guide]-installing-bodyslide-with-wrye-bash

Link to comment
Share on other sites

Great guide. Are the executables the only files that get skipped by wrye bash? And the following section on how to avoid clean data deletion, I presume it implies that those executables don't need to be in their original folder to work as intended.

I've always managed bodyslide manually from a folder located outside Data. But FINS I've always placed inside the Data folder and never had any executabe deleted. Actually, I'm not acquainted with the clean data action. So if I never used it, is it safe to assume that if I never have to use it, those executables will just stay where they are inside the Data folder?

Link to comment
Share on other sites

Odd behavior with latest WIP and Fallout 4: I packed cleaned versions of the 6 DLC ESMs into a .7z installer, then installed them with the Override Skips option. The installer icon turned green as expected. When I then closed WB and reopened it, the icon was red and all 6 ESMs showed as uninstalled and missing, even though they are all in the game's Data folder where they belong.

I've repeated this several times, always with the same successful install, followed by the same failure to recognize they're there when WB restarts.

Let me know what you need. :)

Link to comment
Share on other sites

Supierce, I'm guessing here, cuz I haven't had a chance to open and test it, but check the options on the installer tab. There is an option that's something like Bethesda, official, beth content, something that would imply it's from Bethesda. If I remember correctly even Lojack uses something like you have, but once you make the installer or package then you have to check or uncheck an option and I don't think it's Override Skips.  Once you do that then the installer or package will then behave correctly because Wrye Bash is no longer ignoring files that are in the settings as official content.  Sorry I can't remember the exact name I'm working on something at the moment and can't really get to a working version of WB.

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...