Add/Restore support for '.' in bash.ini

[AndalayBay]

Can support for "." under sOblivionMods be restored or another option made available?

I have one installation of WB with multiple instances of Oblivion and one instance of Morrowind. I want to have the Bash Installers folder under the game folder so I can switch instances. I'm using the -o parameter to specify the game, but how do I configure the bash.ini to tell it to put Bash Installers under each game instance? If I use ".", it uses the default. It used to mean the current directory, which is what I want. Using an absolute path defeats the purpose of having one Bash installation - I'd have to edit the ini file every time. If I use "Bash Installers", it creates a second Bash Installers folder under Bash Installers.

Also, is there a way to backup your current installation order, including the markers? I can make copies of the .dat files, but I'm not sure which ones to backup and then replace when I mess things up.

Thanks. I did try asking on Discord.

[Infernio]

As far as I can tell, the special dot handling has been there since 2011, introduced in https://github.com/wrye-bash/wrye-bash/commit/a45f9b7fae1b0e141e977ce79732f5e89b053bf9#diff-4c047d32e328551940af4d89850e840c64f1f6ca9e8458e8ba418bdccb30c6e5R33646. Looking at that commit, it looks like it was introduced to skip the . that was chosen as a default for sSoundError. Considering that those settings have long since been commented out by default, we're probably good to drop that check - @Utumno?

As for the second part, you can export and import your package order via Edit > Export Order... and Edit > Import Order... on the Installers tab.

[Infernio]

@AndalayBay Try 313.202402022235

[Metallicow]

Can I play a dot. game with you... probably not 3 dots vs 1 dot is unfair, hmmmmph. [EDIT all the guts so I can play PACMAN or better]

[AndalayBay]

As far as I can tell, the special dot handling has been there since 2011, introduced in a45f9b7#diff-4c047d32e328551940af4d89850e840c64f1f6ca9e8458e8ba418bdccb30c6e5R33646. Looking at that commit, it looks like it was introduced to skip the . that was chosen as a default for sSoundError. Considering that those settings have long since been commented out by default, we're probably good to drop that check - @Utumno?

As for the second part, you can export and import your package order via Edit.. > Export Order... and Edit.. > Import Order... on the Installers tab.

Damn, I wish I knew about that! Ok, I know now.

So now I'm reinstalling everything, but it won't install the DLC's. I have an archive with the cleaned DLC's. I installed them before by deselecting Skip vanilla content. Now it's asking for permission to write to the Data folder and won't install the files. I don't have WB or my games installed in Program Files, so I don't understand the question or why it's not installing.

I'll grab the nightly - thanks. Please let me know how to install the DLC's.

[Infernio]

No idea why it's asking for admin permissions if it's not in Program Files. @wrye-bash/bashers any ideas?

[AndalayBay]

No idea why it's asking for admin permissions if it's not in Program Files. @wrye-bash/bashers any ideas?

Perhaps asking here fixed it! I closed WB and opened it again and now it works. The only thing I had done prior to that was to drag a new package to the installers tab. To verify that it was only the DLC's causing the issue, I installed another package just fine, but when I tried the DLC's again, I got the same prompt for permissions. I was going to grab a screenshot, but when I opened WB again, it worked. Very odd.

Now I'll try the new nightly - haven't installed it yet.

[AndalayBay]

Where do I find 313...? It has been a while since I've grabbed a nightly. Also happy to see support for the disk version of Oblivion and Morrowind restored.

[Infernio]

You can either grab the latest WIP build from the Dropbox (see the Discord'a #wip-builds channel or the second post in the AFKMods thread for the link), or you can grab an automated, bleeding edge build via the CI here on Github.

[AndalayBay]

Bookmarked the Discord channel - thank you. I'll bookmark the CI too.

Also in terms of my original question, it looks like it's a full backup I need. I think backups should have their own menu or section under the File menu. Settings would be to configure them, but creating and restoring backups should be under File or their own section. Really happy to see these options.

[AndalayBay]

Ok, good news and bad news. Good news is that "." is back and is working fine. Bad news is: why are you deleting backups as soon as I close WB? There's no way I could use a backup to restore my settings if you delete it as soon as I close the app! Should I open a new ticket?

[Infernio]

We're definitely not (purposefully) deleting backups when WB is closed. I still have my backups from back when I started using WB back in 2018 sitting in my WB folder. Could be a regression, please post a BashBugDump from when it happens.

[AndalayBay]

It does it every time. I opened 313 in a new game session, so it prompted me to backup, which I did. Then I manually did a backup. It deleted the one it has just created. Then it deleted the new one when I closed WB. Here's the log: BashBugDump.log

[Infernio]

I'll have to see if I can reproduce it once I find soms time (unless someone beats me to it).

[AndalayBay]

The only thing I can add is that I set the backups directory to "Backups" under Bash Mod Data. I had that folder in one of my game instances and propagated it to the rest.

[Infernio]

Okay, I can reproduce. This is almost certainly caused by using the "Backups" folder under Bash Mod Data, I think that one is used for backups of plugins (i.e. the right click > File.. > Backup ones), but any cleanup we might be doing on that shouldn't nuke non-ESP files.

[Infernio]

Yup, it's indeed because that directory gets cleaned of old backups of no-longer-existing plugins:

https://github.com/wrye-bash/wrye-bash/blob/49ca6ebcde4ea19fefa857dae341137391c1d939/Mopy/bash/basher/__init__.py#L4203-L4211

That cleanup just shouldn't touch any files with a non-.espf/.esp extension, since those were most likely put there by the user, not by us.

[Infernio]

Newest nightly (313.202402091838) should fix it.

[AndalayBay]

Oh, that's what that folder is for. I've never used WB to backup my plugins. Which folder should I be using then?

[Utumno]

From next nightly whichever one you wish :)

[Infernio]

It's a very random, ad-hoc function that needs to be redone from the ground up. I've never used it either :P

[AndalayBay]

From next nightly whichever one you wish :)

Yeah I believe the default is to just put the backups in Bash Mod Data and I didn't like them being loose in that folder. I guess if you wind up rewriting the plugin backups, perhaps the folder could be named Plugin Backups. By the same token, I guess the settings backups could be put in Bash Backups or Settings Backups...

Thanks for the fix guys. I'll grab the latest nightly.

[AndalayBay]

Grabbed the latest nightly and the backups are not being deleted. The "." in bash.ini is fine too. I also tested the game detection for non-Steam games and that seems to be working too.

However now it's wiping the trusted binaries list. It seems to wipe it when the WB version changes so I saved my list. However when I import my list, it's not saving the import. Since I tell it not to merge, it wipes the whole list and now there are no trusted binaries at all. Is this a regression or a known issue? I can't search. The entire menu bar in github is busted for me. Nothing happens when I click in the search box or when I click on my avatar. It was fine until a few days ago.

Anyway I guess I can close this issue. Let me know if you want me to open a new issue regarding the trusted binaries.

[Infernio]

I'll take a look (and close this issue for good once I merge the fix).

[AndalayBay]

A bit more info on the trusted binaries: it's deleting the list when WB is closed, no matter how it was populated. I installed some packages with DLL's and it added them to the trusted list, but the list was blank again when I re-opened WB. This is the same 313 nightly that I grabbed previously (313.202402091838). And yes, having an About dialogue where I can copy the version number would be super helpful! :)

[Infernio]

Thanks. About dialogue is planned: #666

[AndalayBay]

Yep, saw it. That's why I said "And yes..."

[Infernio]

Mine aren't being wiped. Can you link some of the binaries you tried to install?

[AndalayBay]

All the usual ones, plus a couple of shadeMe's helpers:

# Exported by Wrye Bash v313.202402022235
goodDlls # Binaries whose installation you have allowed
dll: obse\plugins\obse_jail_fix.dll:
version 00: ['Unofficial Oblivion Patch-5296-3-5-8-1704317485', 53248, 343420351]
dll: obse\plugins\obse_training_fix.dll:
version 00: ['Unofficial Oblivion Patch-5296-3-5-8-1704317485', 75264, 2117086202]
dll: obse\plugins\ba_enginefixes.dll:
version 00: ['BA_EngineFixes.zip-52700-v1-0-0-1675045693', 15360, 44057632]
dll: obse\plugins\conscribe.dll:
version 00: ['ConScribe 100-26510-10-0', 317440, 1518327448]
dll: obse\plugins\switchnighteyeshaders.dll:
version 00: ['Detect Life and Night Eye Shader Complete', 118784, 3433025069]
dll: obse\plugins\obse_elys_uncapper.dll:
version 00: ['Elys-_Uncapper_v098-31464', 46080, 2713521129]
dll: obse\plugins\elys_usv.dll:
version 00: ['Elys-_Universal_Silent_Voice_v93-16622', 24064, 1615380825]
dll: obse\plugins\enginebugfixes.dll:
version 00: ['EngineBugFixes v2.22-47085-2-22-1569169531', 434176, 3916751456]
dll: obse\plugins\menuque.dll:
version 00: ['MenuQue v16b-32200-v16b', 192512, 1803890346]
dll: obse\plugins\obse_kyoma_menuque.dll:
version 00: ['MenuQue v16b-32200-v16b', 72704, 3578912587]
dll: obse\plugins\menuque\submodule.cs.dll:
version 00: ['MenuQue v16b-32200-v16b', 1721856, 533044125]
dll: obse\plugins\menuque\submodule.game.dll:
version 00: ['MenuQue v16b-32200-v16b', 360448, 3179625815]
dll: obse\plugins\sr_oblivion_stutter_remover.dll:
version 00: ['OSR_4-1-37', 399360, 1318545640]
dll: obse\plugins\componentdlls\borlndmm.dll:
version 00: ['OSR_4-1-37', 34816, 2651765292]
dll: obse\plugins\componentdlls\debugmm.dll:
version 00: ['OSR_4-1-37', 41984, 2025514455]
dll: obse\plugins\componentdlls\libtcmalloc_minimal.dll:
version 00: ['OSR_4-1-37', 182272, 118921120]
dll: obse\plugins\componentdlls\tbbmalloc.dll:
version 00: ['OSR_4-1-37', 74416, 915833282]
dll: obse\plugins\runtimeeditorids.dll:
version 00: ['REID 50-40132-5-0', 103936, 95632087]
dll: obse\plugins\runtimedebugger.dll:
version 00: ['RuDE 10-37105-1-0', 168960, 463683208]
dll: obse\plugins\componentdlls\rude\debugger.dll:
version 00: ['RuDE 10-37105-1-0', 96768, 3620275687]

badDlls # Binaries whose installation you have forbidden
# None

https://www.nexusmods.com/oblivion/mods/5296 https://www.nexusmods.com/oblivion/mods/47085 https://www.nexusmods.com/oblivion/mods/32200 https://www.nexusmods.com/oblivion/mods/37105 https://www.nexusmods.com/oblivion/mods/52700 https://www.nexusmods.com/oblivion/mods/36407

[Metallicow]

Keep up the bad work

... is what is said sometimes...

LOL

On Sun, Feb 11, 2024, 7:34 AM Infernio @.***> wrote:

Mine aren't being wiped. Can you link some of the binaries you tried to install?

— Reply to this email directly, view it on GitHub https://github.com/wrye-bash/wrye-bash/issues/676#issuecomment-1937756355, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDTXRFZELVQV4XYZDFD243YTDCEVAVCNFSM6AAAAABCXLXQTGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZXG42TMMZVGU . You are receiving this because you commented.Message ID: @.***>

[AndalayBay]

Have you guys changed how Anneal works? I'm not sure if 312 did this or not, but I've noticed that the last two nightlies aren't installing missing files when you anneal a package. I have to keep selecting advanced installation - install missing files.

We have a resource package for a project I'm working on and I'm continuing adding and removing files. Anneal isn't installing the new files - I have to select install missing.

[Utumno]

There were some discussions of this in discord - there might something that broke recently, and I was thinking of opening an issue for this one. The problem is we have no specification on how anneal should work in all cases - can you give me a specification of what anneal should be doing, including how it behaves on higher/lower order conflicts?

[Infernio]

It should probably be doing what the docs say it does:

Install missing files and correct install order errors according to the package configuration.

From https://wrye-bash.github.io/docs/Wrye%20Bash%20General%20Readme.html#bainAnneal

That is:

1. Install missing files (that's how it differs from Install... and Install Configured, those overwrite existing files)
2. Correct the Data folder to match changes in your package configuration, e.g. if you change package order and now some of the files that were originally installed from that package should come from a different package instead (at that point, the package gets an orange background and you have to anneal it). Or if you pick another sub-package, etc. (that's how it differs from Install Missing Files, that one only does Point 1).

If it doesn't do this anymore (which is what it's done for as long as I remember), something broke. Granted, I rarely use it for point 1, so I probably wouldn't have noticed if it did break.

[Infernio]

There's some more details in the advanced readme too, corroborating what I said: https://wrye-bash.github.io/docs/Wrye%20Bash%20Advanced%20Readme.html#bainAnneal

[AndalayBay]

In addition to that, it will also remove files that have been deleted from the archive. That is still working.

So yeah, new files are not being installed. In my case, these are only resource files, so meshes and textures, no plugins. These files are only for this project, so there's no conflicts, so it shouldn't be skipping any files.

Sometimes I delete the package to make sure everything gets refreshed properly. That's when I discovered the issue with the trusted binaries because it reinstalls the UOP when I do that. We have some LOD that conflicts with the UOP and Bash correctly refreshes the UOP when I remove our package.

Lastly, us engineers have an issue with the term "anneal" for this process, but that's a separate discussion. :D

[Infernio]

Maybe an example is best. Say I have two packages, A.7z and B.7z in the order A, then B. Both provide two files, test.esp and test.bsa, and both are different in each package (different CRC).

First I install both of them, e.g. using Install... (or Install Missing Files, etc.). Now the winning files are test.esp from B and test.bsa from B. B's checkbox is green, A's checkbox is orange.

Next, I clean test.esp in xEdit. This modifies it and changes its CRC to a third one, that doesn't match either A's or B's. B's checkbox is red now, A's is still orange (IIRC).

Now I reorder A to come after B. This means that test.esp and test.bsa from A should now win over B. However, BAIN does not commit this change to the Data folder immediately (because that would be terrible UX, especially for huge packages with tons of files to extract). That's why the checkbox colors remain unchanged. B's background is orange now.

At this point, let's see what various actions would (or rather, should) do:

• Install Configured/Install.../Install Last on A: Overwrite the user-modified test.esp and test.bsa in the Data folder with A's versions.
• Install Configured/Install... on B: Nothing.
• Install Last on B: Overwrite the user-modified test.esp and test.bsa in the Data folder with B's versions.
• Anneal on A: Nothing, you need to run anneal on the orange-colored one.
• Anneal on B: Install A's version of test.bsa, leave the user-modified test.esp in the Data folder.
• Uninstall on A: Install B's version of test.bsa, leave the user-modified test.esp in the Data folder.
• Uninstall on B: Install A's version of test.bsa, leave the user-modified test.esp in the Data folder.

The "which one to anneal" thing might be the other way around and I'm not 100% sure on the uninstalls, it's late and I need to get some sleep :P

Edit: what AndalayBay said above me is indeed correct, it'll uninstall files that are no longer configured for uninstallation (e.g. if you uncheck a subpackage or plugin).

[Infernio]

Oh, and it's important to note that all of this can of course only work with changes to the package done in Wrye Bash or while Wrye Bash is running - if you change the package outside Wrye Bash while it's not running, you won't get an orange highlight and Anneal won't be able to tell what exactly has changed. You'll have to Install Configured/Install Missing Files in that case.

[Utumno]

Need to get some sleep too - it would be helpful if you could check that the example by Inf works @AndalayBay - maybe it's a user modified package that prevents anneal?

[AndalayBay]

Sorry guys, I'm finding that really hard to follow. Perhaps my case is simpler. I have an archive called resources.7z. The archive has meshes, textures, distantLOD, sound and trees. I am modifying files, adding files and deleting files from the directories. I then recreate or rebuild the archive. Then I drag the new version of the archive into Bash's Installers tab. It prompts me to replace the file, and I confirm the action. The package, or archive in the Installers turns orange, as it should. However, it only replaces and deletes files. It does not install the new files unless I select Advanced Installation - Install Missing. This is NEW behaviour. I have been doing this for years and this is the first time that I've had to select install missing.

When Bash lost my installation data due to the "." bug that was the start of this ticket, I had to reinstall everything. I used Install Configured so that I didn't have to run the wizard scripts again - that was fine.

Oh, and it's important to note that all of this can of course only work with changes to the package done in Wrye Bash or while Wrye Bash is running - if you change the package outside Wrye Bash while it's not running, you won't get an orange highlight and Anneal won't be able to tell what exactly has changed. You'll have to Install Configured/Install Missing Files in that case.

I'm not changing the package that's in Bash Installers. I'm changing the package in my projects folder. Then I start WB and drag the new package to the Installers tab. As I said, it's detecting the change as it should. It's just not doing all the actions I expect when I Anneal the package.

I can also confirm that WB leaves a modified esm or esp alone, as it should. I have a separate package for the plugins and I install that when we release a new version. I will copy in the new archive and WB sees that the plugins are different so it won't overwrite them unless I force it to. Usually I delete everything manually and just install the new release (which is in a new archive).

Installation order is honoured, so it's the last package that gets annealed if it has changes from what is currently installed. If that's what you were saying @Infernio then you are correct. I think that's what you were saying. :)

So when I uninstall our resources archive, which is last in the installation order, WB fixes the UOP installation as it should, which is much higher in the installation order. Is that what auto-anneal does? If so, I need to re-enable that because that's what I want it to do. I turned off auto-anneal as I was trying to figure out what was going on. I just realized what it meant, so I need to re-enable it.

[Infernio]

Ah right, that's what I forgot about uninstall: if you have auto-anneal off, you have to manually anneal packages afterwards to have BAIN install the right files.

And I think we're in agreement of how it should work. If no one gets to this first, I'll have a look at it this weekend.

[AndalayBay]

Yeah, once I realized what it meant, I went back in and made sure it was on. Also concur about the expected behaviour/functionality.

[Infernio]

I can reproduce and I bisected it to af11b461ee0b5d4ace54acef8822ca1841762490. It's somewhere in the changes to __restore in there, will have a closer look.

[Infernio]

I pushed a fix for the anneal issue. I can sometimes reproduce the trusted binaries thing, but it's extremely inconsistent and random. I don't have the first idea why it's happening.

Edit: I officially have no idea what's going on there. I smell a race condition, but where on earth would it be and why only with those two dicts?

[Infernio]

The new 313.202402171641 has the Anneal fix. Still no clue what's up with the Trusted Binaries thing, I'm giving up on that for today.

[AndalayBay]

First, why is bash wiping the trusted binaries list at all? Second, I just discovered another issue. Now it has the UOP OBSE DLL in the list, as it should. However when I import my saved list, I tell it not to merge because I have the UOP DLL's in my list, so I thought that if I merged, there would be duplicates. It's wiping the UOP DLL's from my list as well! It should import my complete list, but it's not.

Even if I tell it to merge, it's removing the UOP DLL's from the list. It shouldn't be removing anything. It should have at least one set of the UOP DLL's. Really it should have two.

I'll grab the new nightly.

[Infernio]

It isn't. There is no code to wipe the binaries list. Which is why I'm so confused.

Sometimes I launch WB, it has fine data in the Trusted Binaries list, I install a new binary, it adds it, the Trusted Binaries tab shows it fine, I relaunch WB -> empty list.

[Infernio]

My best guess is a regression stemming from 5eecd360f407452cd0cba914766f87dc78933861 (@Utumno), since that one touched everything, including converting the paths in the trusted binaries to FNames. But I placed a metric ton of deprints and breakpoints, and never once was able to catch it during debugging. Only during non-debug runs. Which is just making me suspect race conditions more and more.

[AndalayBay]

Yeah I would have suggested looking at the initialization code, but it sounds like it's processing it fine when you're debugging. You might want to take a look at the import code. Is it going through the same process to save the list as it does when you install a mod with DLL's?

Also new problem: the nightly wiped my installation! IT REPLACED MY bash.ini - the real one!! I'll put my bash.ini back and hopefully that sorts it. I guess I'd better back up my ini.

[AndalayBay]

I let it backup my settings when I installed the nightly, but it backed up the new ini, not my copy. So it's not really a backup...

[Infernio]

I can't replicate that, my INI is entirely intact. Wrye Bash also has no code to write bash.ini that I'm aware of.

[AndalayBay]

Well it did. The timestamp for bash.ini is the same as the rest of the files like bash_default.ini. I just ran Wrye Bash 313.202402171641 - Installer.exe I don't mess around with the Python versions or any kind of manual install. I've also discovered that it modified my ini previously. Here's my ini from the previous set up. I left all the paths intact and just changed the sOblivionMods to "." when that was restored. ABbash.zip

Here's the bash.ini from the backup I took once you got that fixed: bash.zip

See what happened? It replaced my ini, but retained the "." However all the extra settings are gone. It didn't hurt anything because I guess I was actually using the defaults, but it replaced the ini. So it did it on one of the previous nightlies, not the latest. The latest removed the "." and that's when I noticed.

When I install a new version, I don't touch the ini. I haven't made a new copy from bash_default.ini since playing with these nightlies. Even on old versions of WB, I don't change the ini unless something significant has changed, then I use Winmerge to transfer my changes to a new ini. That's why the first ini I attached is actually from WB 3.11.