Jump to content

Wrye Bash - All Games


Utumno

Recommended Posts

The bashdump is empty duh - he didn't run it with the -d switch

Working hard in my very limited time to smooth things out - ideally I want the beta up on Christmas - @Arthmoor or @alt3rn1ty prepare to do the honours of uploading it :P

One thing that's tough is the restore settings bug - https://github.com/wrye-bash/wrye-bash/issues/390 - won't make it, still it's an important issue to fix

It's broken to pieces but  the complication is that there are edge cases never thought of

For instance suppose that the user uses a bash.ini and the backup does not contain a bash.ini -> in this case the bash.ini of the user should be deleted to really restore settings. What should I do in this case ?

 

Reference uploading new version - Can do no problem, I dont have too much on with other projects at the moment, still doing shift work, but probably a lot less busy than Arthmoor just now.

Just point me at the finished files ( Installer / Source / Standalone loose ) when ready, and I will do my best to avoid the upload hoops Nexus sometimes gives (like the CDN Cache issues which occasionally throw up the old files hiccup, I have a couple of tricks to get around that if it happens now, aswell as hiding the mod pages while I do a few test downloads first before letting the public loose on them).

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

Hmm, well restore settings hasn't worked for ages so it will not hurt going another release down the road.

For the Bash.ini problem on restore .. Maybe a warning dialogue explaining the situation :

"To correctly restore your previous settings your custom Bash.ini file needs to be deleted (as it was not included in the previous settings backup and will conflict with the restoration). If you still need any custom settings you will need to recreate your bash.ini file" with buttons for "Ok dooo eeet!" or "Cancel" ?

 

Link to comment
Share on other sites

10 minutes ago, alt3rn1ty said:

 

Reference uploading new version - Can do no problem, I dont have too much on with other projects at the moment, still doing shift work, but probably a lot less busy than Arthmoor just now.

Just point me at the finished files ( Installer / Source / Standalone loose ) when ready, and I will do my best to avoid the upload hoops Nexus sometimes gives (like the CDN Cache issues which occasionally throw up the old files hiccup, I have a couple of tricks to get around that if it happens now, aswell as hiding the mod pages while I do a few test downloads first before letting the public loose on them).

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

Hmm, well restore settings hasn't worked for ages so it will not hurt going another release down the road.

For the Bash.ini problem on restore .. Maybe a warning dialogue explaining the situation :

"To correctly restore your previous settings your custom Bash.ini file needs to be deleted (as it was not included in the previous settings backup and will conflict with the restoration). If you still need any custom settings you will need to recreate your bash.ini file" with buttons for "Ok dooo eeet!" or "Cancel" ?

 

Parfait - thanks - will point you when I have those ready

---

Yep no time for that now - thanks for feedback - think that that's horribly complicated, imagine can fail at any step leaving settings half baked - lots of code to get this right

Another point I need feedback on - the recent discovery by @Ravenmind that the change game dialog is broken (related maybe to the weird issue you had with the Backup directories - seemed the same for all games IIRC).

I kind of think I will entirely drop this menu - it's just a left behind from pre alpha game handling. The idea of loading another Bash instance (another Bash launcher in the Mopy folder inside another game dir) is next to impossible to implement in any decent manner. Apps folder will remain the Apps folder of this instance (read Bash installation) of course, as will the bash.ini.
All this stems from the Oblivion time where Bash would sit in Mopy, which sat by Oblivion.exe. Since we support multiple games the problem of different installations was never really solved, albeit repeatedly tackled.

The careful reader will notice that those two bugs are really two sides of a multi-sided coin named settings handling (hint: "game" is a bunch of settings)

We need to switch to a profile based "one installation to rule them all" - but this has the obvious problem of not being able to run in parallel for different games (which is in beta I'd guess). Anyway, be aware that the "Switch game" menu just relaunches current Bash (with its App folder bash.ini and whatnot) - how about dropping it ? If no how should it be fixed ?

Link to comment
Share on other sites

For me the Game menu its a nice idea, I will probably never use. I always have an Icon on the desktop for each Wrye Bash - Game name, which launches one of the three installations of Wrye Bash which installed into each game folder.

I also have no need for different profile setups .. But then that along with associated different profile saves is something other mod managers do which is one of the main attractions to use other mod managers

All the above is just to explain basicly I recognise the need for it to be fixed if it is to be a feature .. But I have no opinion on how it should be fixed, or what needs to be done to make it do what anyone would want out of it. If it cant be fixed in the short term though, is it actually causing issues for people and they do not realise ?, and if so could it be easily and temporarily snipped from being an active feature to a dormant one until more of what needs to be in place is done ?

@Arthmoor may have better ideas along these lines, I think he has a Wrye Bash "one installation to rule them all" setup and is experienced in its day to day use.

Link to comment
Share on other sites

When did the "change game" thing break? I've been making regular use of it for ages and have never noticed any sort of problem with it. Occasionally the window pops behind other active windows, but I think that's just a Windows issue and not something Bash could fix.

I make pretty good use of that game selection menu and would hate to see it go. Managing individual installs of Bash in each and every folder I need it for is extremely unappealing.

Link to comment
Share on other sites

1 hour ago, Arthmoor said:

When did the "change game" thing break?

https://github.com/wrye-bash/wrye-bash/issues/399

I have never used the kind of setup you employ with Wrye Bash, so thought you might be the best and most experienced to weigh in on the issue.

Quote

.. But I have no opinion on how it should be fixed, or what needs to be done to make it do what anyone would want out of it. If it cant be fixed in the short term though, is it actually causing issues for people and they do not realise ?,

 

See also Utumno's post above, it seems this is not an easy thing to fix .. 

 

Link to comment
Share on other sites

Ok ok I'll try and fix :P - although if you have a Bash ini with settings for other game those settings are kept and no workaround for that (and other stuff reported in the issue)

Link to comment
Share on other sites

On 12/19/2017 at 7:08 AM, alt3rn1ty said:

@Utumno Venutius has responded to my questions on Skyrim SE Nexus ...

RenameOp: Warning - Unable to rename temporary file from "CMOvens.esp.new.2017_12_19_00_29_05" to "". Unknown details.
RenameOp: Warning - Unable to rename temporary file from "Soup01b.esp.new.2017_12_19_00_32_05" to "à#ªàÊQ

That error is almost certainly a permissions issue. I'll pop in and look at the thread when I get done with my to-do list. 

EDIT:  I was looking at \bash\basher\mod_link.py for something else (I'm helping @Ganda get up to speed about how CBash hooks into Bash) and found a comment in the 'Mod_CreateDummyMasters' class about some unicode issues.

Looking at the gibberish at the end of of that second filename and the fact it happened with Oblivion, it could possibly be a unicode issue. I see this frequently in logs because SMTP can't understand Unicode, and the subject lines are gibberish like that in the SMTP headers.

I'm tired as hell and sleep-deprived at the moment so if I'm logic is faulty my apologies. I'm just going with my gut here. :)

EDIT2: I must be too tired to summarize my thoughts: I think the user may be using a non-Western version of Windows.

Link to comment
Share on other sites

Bash debug start question?

 

I followed the instructions to start Wrye Bash in debug mode at command prompt but I think something went awry.

 

What I expected was Wrye Bash to start and then return focus to the command prompt window so that I could exit the command prompt window.

 

What happened was Wrye Bash started and seems to function however I cannot exit the command prompt window, and if I mouse click (X) exit the command prompt window Wrye Bash closes.

 

BashBugDump.log is created, I have included two, one for start from command prompt and one for start from elevated command prompt. I’ve also included a .txt file with the contents captured from the command prompt window after closing Wrye Bash and some system information.

ElevatedCommandPromptandSystemInfo.txt

CmdBashBugDump.log

AdminCmdBashBugDump.log

Link to comment
Share on other sites

That is the expected behavior. The command prompt window remains open, just ignore it. (Others, corrct me if I'm wrong), basically it's monitoring Wrye Bash and if an error is encountered it allows more info to be logged. Go ahead & use WB to do whatever you're doing, then when you close WB, it writes any pertinent information to the BashBugDump.log. I'll often run in debug mode when I'm not necessarily expecting a problem, just so if something happens I'll have the info in the log afterward. Be advised though, when running in debug mode, you'll not get the standard pop up notification that something errored. Often it will appear nothing went wrong and you won't know unless you check the log, so I don't really recommend running in debug as standard.

Are you concerned with the particular error evidenced in your logs, or were just asking about the debug mode?

It looks like you're missing "loot_api.dll", which should be located in your \Skyrim Special Edition\Mopy\ folder. You should be able to copy that file in from one of the non-installer versions of WB found in the link at the bottom of the second post of this thread.

Link to comment
Share on other sites

Thank you RavenMind,

I have just changed from the stand alone to the Utumno-wip python version.

I have only seen one GUI error that I did not cause. It is related to icons and I think it is a known issue.

The problem with Wrye Bash not returning focus to the command prompt window is that I can't do anything else at command prompt unless I close Wrye Bash.

I guess I will only be able to use debug mode during game play.

Edited by Joat_Mon
clarity
Link to comment
Share on other sites

Are you unable to open a second command prompt window? I haven't tried it myself with WB debug mode running, but I often have multiple command prompt windows open. Not sure what you mean by only being able to use debug *during* game play..? You're not expecting it to produce anything during game play are you? After game launch it doesn't do anything, (AFAIK), all its magic is done prior to launch.  There's even an option to have WB close itself upon game launch, which I like to use just to be certain any changes to .dat files are written before I play. :) 

Link to comment
Share on other sites

@Joat_Mon Ravenmind is correct in that you can open as many Windows Command lines as you want, each is a separate process, and has to remain open if you launch another process from the command line. But then you just use another one if needs be for anything else.

Also if you installed Standalone with the Wrye Bash Installer, you should have a bunch of Icons for Wrye Bash in your Start Menu (See spoiler below), if you use the Debug ones, no need to use a command window for this purpose, those icons launch Wrye Bash standalone in debug mode which also produces a BashBugDump.log in Mopy\. (It didn't used to, Sharlikran pointed it out to me and I was surprised to find they actually work these days, I must have missed when that got fixed somewhere along the way)

You do not need to launch any game. If you are using debug mode to try and find any game issues, this will not help you. The BashBugDump.log does what the name says, its a log of any errors produced by Wrye Bash while Wrye Bash was running. So when you launch Wrye Bash in debug mode, you then use Wrye Bash to try and recreate any issues you have with Wrye Bash, then close Wrye Bash, and the BashBugDump.log gets updated to include any errors during the last session. And then paste the content of the BashBugDump.log here in the forum if you do actually have any errors for Utumno's attention.

Those Icons I was talking about in the start menu ..

 

6837-0-1510310754.png

Link to comment
Share on other sites

Thank you alt3rn1ty & RavenMind,

I fully uninstalled Wrye Bash Standalone after using it for a year. I seldom use Win start menu, I'm sure the Icons where there but I don't remember them. I understood a mod manager's job was done when the game started, don't know why I said that, in fact I will prefer Wrye Bash to close for the SSE memory use testing I am trying to do now.

A couple days ago I installed Python, the Utumno-wip Wrye Bash, and all the dependencies. I encountered one problem and thought I should report this. After reading the bug reporting guidelines I realized that I need to reproduce the error while running in debug mode, but I also realized that I needed to read everything related to Wrye Bash @ github to determine if my error was a known issue and I now think that it is a known issue. Just to be sure I will state it (unofficially) here:

When I resized the icons at the bottom of the Wrye Bash window Wrye Bash closed/exited/crashed.

Otherwise Wrye Bash has preformed admirably so far. The python version seems faster than the stand alone executable but that may be due to scandir more than anything else. I have been in the habit of leaving the Wrye Bash window open when I run SSE as I will often drop out of game to make changes while testing. I will need to break that habit as I have decided to create a memory use baseline of the absolute minimum game install using VMMap and I will need as few things running in the background as possible. That is why the command prompt window caught my attention, I did not want to leave it running when the game started. For some reason my brain decided that I would always run in debug mode from now on, just being stupid.

Thanks again for the help and reminders. I have some questions (not problems) about Wyre Bash, if I can't figure them out from the documentation I hope I can ask the here without being too annoying.

Link to comment
Share on other sites

Dont know if we can answer any questions on Wyre Bash, but if you have any about Wrye Bash we will do our best to answer :)

Aswell as the official documentation ( General, Advanced, Technical ), linked in the first post, also try the ? question mark on the Wrye Bash tool bar, especially if you are using Dev builds, the documentation has been updated a few times in dev since the beta upload at nexus, so the dev build installation of the documentation is more up to date than the links in the first post or the docs that come with the Nexus version.

 

The Icon resize sometimes has been known to do that, although I thought it had been fixed in the more recent nightly builds - What version of Wrye Bash were you using when it crashed after using the icon size options ? - In 307.2711250133 nightly build ( link at the very end of the second post "307 WB WIP Standalone" ) of Standalone, I just tried changing from 32, down to 24, then down to 16, then back up to 32 again .. And no crashes, with no errors in the BashBugDump.log :

 

Wrye Bash starting
Using Wrye Bash Version 307.201711250133 (Standalone)
OS info: Windows-10-10.0.16299
Python version: 2.7.12
wxPython version: 2.8.12.1 (msw-unicode)
input encoding: None; output encoding: None; locale: ('en_GB', 'cp1252')
filesystem encoding: mbcs
Using scandir 1.5
bash.pyo  316 _main: Searching for game to manage:
bush.pyo   76 _supportedGames: Detected the following supported games via Windows Registry:
bush.pyo   78 _supportedGames:  Oblivion: e:\oblivion
bush.pyo   78 _supportedGames:  Skyrim Special Edition: D:\Steam\steamapps\common\Skyrim Special Edition
bush.pyo   78 _supportedGames:  Fallout4: D:\Steam\steamapps\common\Fallout 4
bush.pyo  136 _detectGames: Detecting games via the -o argument, bash.ini and relative path:
bush.pyo  142 _detectGames: Set game mode to Skyrim Special Edition found in parent directory of Mopy:  D:\Steam\steamapps\common\Skyrim Special Edition
bush.pyo  156 __setGame:  Using Skyrim Special Edition game: D:\Steam\steamapps\common\Skyrim Special Edition
testing UAC
mods_metadata.pyo  227 __init__: Using LOOT API version: 0.10.1

Link to comment
Share on other sites

1 hour ago, alt3rn1ty said:

What version of Wrye Bash were you using when it crashed after using the icon size options ?

Bleeding Edge Python Code 12/9/2017.

Let me know if you need me to pursue this further with debug active. So far I've observed:

Even with no apps added to the status bar changing the icon size can crash Wrye Bash. It is hard to prove a negative but it only seems to occurs at some point after changing the icon size at least 3 times.

When certain apps are added to the status bar Wrye Bash will crash first time, every time that the icon size is changed on the status bar.

Other apps when add to the status bar will exhibit the same failure as noted for no apps added to the status bar.

WYRE  I'm sorry, can I plead old age as a defense?

Thanks again for your help.

Edit: The apps that cause Wrye Bash to crash "first time, every time" when added to the status bar have something in common, they are installed in a folder on my f:\ drive. That means that this behavior is likely a windows path error and most likely can be ignored. I will test more later.

The apps that when added to the the status bar cause the same result as no apps added are all on my OS drive.

 

Edited by Joat_Mon
Add Info
Link to comment
Share on other sites

The resize icons crash has eluded me for too long - it's certainly a windows/wx hard crash - I was never able to replicate. The hint that it may be related to the Apps folder is the first shadow of a reproducer that I know of - would be nice to pin this down

@Joat_Mon welcome to the forums - nice reports there ! Yep, policy is that before filling an issue one should drop by here, cause 90% is a no issue or a known issue, or some regression of bleeding edge (which btw is the utumno-wip always, the second post (timestamp) version is usually left a bit behind the python one, it's just a snapshot of always evolving python branch)

 

Link to comment
Share on other sites

7 hours ago, Utumno said:

The resize icons crash has eluded me for too long - it's certainly a windows/wx hard crash - I was never able to replicate. The hint that it may be related to the Apps folder is the first shadow of a reproducer that I know of - would be nice to pin this down

 

Adding C:\Python27 to my system path statement seems to have solved the problem where Wrye Bash would crash on resize of icons in the status bar.

To Update: This is not a complete fix. It works in all tabs except the installers tab. Resizing status bar icons while in the installers tab still crashes Wrye Bash. Also if you switch to the installers tab (doing nothing else) then switch to any other tab, resizing icons in the status bar can still crash Wrye Bash.

Edited by Joat_Mon
Add Info
Link to comment
Share on other sites

11 hours ago, Utumno said:

Yep, policy is that before filling an issue one should drop by here, cause 90% is a no issue or a known issue, or some regression of bleeding edge

 

Keeping your statement above in mind.

While skimming the code to try to determine what was happening in the installers tab I ran across this:

github utumno-wip wrye-bash/Mopy/bash/basher/installer_links.py
Open parentheses which begins in line 979 appears to be missing close parentheses

I don't know enough about python to know if this is a problem that needs to be brought to your attention or not.

Link to comment
Share on other sites

9 hours ago, Joat_Mon said:

Keeping your statement above in mind.

While skimming the code to try to determine what was happening in the installers tab I ran across this:

github utumno-wip wrye-bash/Mopy/bash/basher/installer_links.py
Open parentheses which begins in line 979 appears to be missing close parentheses

I don't know enough about python to know if this is a problem that needs to be brought to your attention or not.

Admittedly the automated line breaking created a very complicated nesting of parantheses, but the expression is balanced. The open paranthesis on line 979 is closed by the second to last paranthesis on line 981. So nothing to worry about, but thanks for looking at the code. Help is always appreciated :)

Link to comment
Share on other sites

I had a personal need for profiles that easily allowed experimentation but both NMM and MO corrupted my profiles so I moved to WB. I also had problems with WB's profiles not refreshing correctly so I used WB's save and restore but that was cumbersome and not what I wanted. I looked at WB's issues list on github and noticed issue 250 - Profiles. I liked that approach so with much motivation I began exploring the code and implemented profiles as described in #250. I see @Utumno plans to work on this so I could be quiet and not share this code but that doesn't feel right. So hopefully this offer doesn't come across as stepping on anyone's toes. I assume he has a very particular vision for profiles so my implementation may not fit WB's long term vision.

I've been successfully using this alternate profile system for a few months now with Skyrim LE, SE and Oblivion. With work on release 308 about to begin, I thought this is a good moment to share.

The code is in my github repository,  warmfrost85-250-profiles branch, which is rebased on WB's current dev branch. Unfortunately I referenced that issue a few times and messed up its activity log. Sorry. Not sure if github allows that to be cleaned up.

The documentation for this solution is in the spoiler below and in the git commit comment.

Any feedback or comments are encouraged.

Spoiler

Implement the new profiling system as described in Issue #250

    -------------------------------
         S t a g e d     P r o f i l e s
   -------------------------------

Staged Profiles is a new profiling system for Wrye Bash. It does not
replace the original profile system which is now referred to as
Classic Profiles. This does not fix, enhance, or change the way Classic
Profiles work. As these approaches are not compatible with each other,
you must choose one or the other. Staged Profiles are an advanced
feature that has it's own copy of the game Data folder, game Installers
folder, and load order history (BashLoadOrder.dat). It is based on
the design described in Issue #250. This feature is disabled by
default. To enable staged profiles, set the Bash.ini
General Setting "useStagedProfiles=True".

Staged Profiles created from other profiles initially share all mods
and settings via hard linked files. Once created, installing or
deleting mods in any profile does not affect other profiles!
However, CHANGING a hard linked file WILL also change it in all
profiles in the staged set.

With Staged Profiles, there is no official game Data folder.
The Data folder in each profile is just as legitimate as any other Data folder.
You can now have a clean Data folder AND a Data folder filed with mods,
at the same time. Only one is active at any given moment.

Staged Profiles makes it easy and safe to create profiles that are as
separate and independent as you wish with minimal increase in disk
storage. Modding best practice is to either not modify your setup once
you start a playthrough or remember the save file so you can go back
if something goes wrong. With Staged Profiles rather than creating a
special save, just create a new experimental profile based on your
current profile and install mods into it. If something goes wrong,
delete the experimental profile and go back to the earlier profile and
try again. Since deleting a mod in a profile does not affect other
profiles, you can delete mods from your new profile that don't relate
to your current character build. This means you can have a
"vanilla" profile that has a clean Data folder; never touched,
always clean.

You can also simulate profiles for programs that don't natively
support them. For example, you can have a separately configured
Mator Smash for each profile. This works for all games that Bash
supports. This is discussed later.

A technical description of what happens under the hood when you create,
use, or delete a profile is detailed at the bottom of this file.

Tutorial to convert your classic profiles
==========================================
This is a tutorial on how to use Staged Profiles. It assumes you already know
how to use WB.

It's always a good idea to backup you Data, Mods and Saves directories
before you begin. If you have a second computer, you may want to do
these steps there just in case there are any surprises. Do not use
WB's builtin in save and restore settings for this purpose.

Do NOT enable Staged Profiles yet. The following are first use steps only.
First, switch to the classic profile that you want to use as the basis
for your first Staged Profile.
Now enable Staged Profiles via the Bash.ini file.

Depending on the number of mods installed, creating a new
Staged Profile may take a few minutes, just wait. If you have
more than just the Default profile, switch to each profile to convert
it to a Staged Profile. WB will restart every time you switch to a
Staged profile.

Create a new profile named "Vanilla" that we will configure to
contain NO mods. Now switch to the "Vanilla" profile. Bash will restart
and when it comes back you will be in the "Vanilla" profile. Now that
you're in the "Vanilla" profile, uninstall and delete ALL mods!
There should now be NO mods listed in the installer tab and only the
base game files in the mods tab. Open the game Data folder. If there
are any stray files, those are files that were not being tracked by WB.
Delete those untracked files to get a clean Data folder.
If you are a purist, you can delete and re-install the game,
then create your "Vanilla" profile. Now you can start the game and
enjoy a vanilla experience. This profile holds your clean game Data
folder. Notice the Staged profile looks no different than the
originating profile. Also notice you have not consumed any additional
disk space.

Switch back to the other profile. Notice, everything looks as it
did before. All your mods are present. Now switch to the "Vanilla"
profile. Notice, NO mods. You're back to a nice clean Data folder.

Whenever you create a new staged profile, it gets all the mods that
are currently active/installed. So if you want a copy of an
existing profile, switch to it, then go to Edit Profiles and create
the new profile.

What's next?
============
With the Vanilla profile active, I recommend you create a profile
named "Vanilla+Essentials" which will be the source for future profiles.
Add any mods you consider essential to your gameplay in general,
like weather and environment mods. Customize any ini settings that you
don't plan to change in other profiles. Why? This is explained later.
The more mods in this essential profile, the less disk space you will
use in future staged profiles. Create all new profiles from this
"Vanilla+Essentials" profile and customize them to fit your character.
When you want to create a new character, switch back to
"Vanilla+Essentials" to jump start the creation of a character's
profile. With this approach you have a common mod setup as a base for
your new profiles.

Are mods in Staged Profiles independent of each other?
======================================================
Yes, completely independent for any mod you ADD or DELETE to the profile.
No, not if you CHANGE mods/files that are shared (hard linked),
with other profiles, i.e. have a common ancestor profile.
It's VERY IMPORTANT to understand the affect of CHANGING a file that

Here's an example of this shared file effect. Let's say you have
two profiles that have a common ancestor profile that contains
the Skyrim Uncapper mod. If you change an uncapper ini settings in
either profile it is changed in both profiles. If that's not what
you want, you need to UNLINK (stop sharing) the Skyrim Uncapper ini
file in the profile you want to make independent.

To UNLINK a file and make changing it independent of ALL other profiles,
 you need to ADD/COPY it to your profile, not change it.  You can do
 one of the following.
   1. If the mod is a archive, change it to a project. This will ADD
      new files which will unlink them from other profiles.
      Remember to change the setting in the project and delete the archive.
   2. Duplicate the mod and uninstall the original mod.
   3. Uninstall, delete and re-install the mod.
   4. Don't include the mod in the "Vanilla+Essentials" profile.
       ADD it to any profiles created while "Vanilla+Essentials" is active.

Now that Uncapper is UNLINKED, you can change it and any changes will
only be reflected in that profile. Note: Each time you unlink a file,
it will consume disk space equivalent to the size of the file.

CHANGING a linked file in one profile and having it change in all other
linked profiles may be helpful. For example, if skyrim.esp is a
linked file in the Vanilla profile, when you clean and save it in xEdit,
 you just cleaned it in all profiles derived from Vanilla! Nice.

Icon overlay
=============
WB gives no visual feedback if a file is hard linked. To get a visual
indicator (and in my opinion this is imperative), you need to
install HardLinkShellExt. Once installed all hard linked files
displays a special icon. This is critical feedback when working with
your profile. If the file is shared it will have an upward slanting
red arrow in it's icon.
You can download HardLinkShellExt here:
http://schinagl.priv.at/nt/hardlinkshellext/linkshellextension.html

If the hard link overlay icon is not displaying, you have too many
icon overlays installed. Windows has a limit. See this link for more information.
https://www.ghacks.net/2016/07/24/fix-sync-icons-not-showing-explorer/

Simulating profiles in other applications
=========================================
If an application is self-contained, i.e. doesn't write to the Windows
registry and only uses files within it's folder, it can be independently
associated with a WB profile. This allows each profile to have a
separate configuration for a program that doesn't natively support them. Mator Smash is a good example.

COPY or install the Mator Smash folder into the games Mod folder. It is
now associated with the active profile. If you want another independent
copy of Mator Smash, switch to the profile you want to add it to.
There shouldn't be Smash there yet. COPY or install the Smash folder
into the games Mod folder. The disadvantage is any changes like new tags
you define are only associated with that profile. You'll need to
manually combine them by looking at the other profile in the Saves folder.

You can create a shortcut to this location and add it to WB's
status bar and it'll always point to the correct/isolated version as you switch profiles.

Switch back to classic profiles
===============================
You can switch back to classic profiles at anytime, however this
requires deleting all your enhanced profiles.

Steps to return to classic profiles.
  - Switch to the profile that contains the mods you want to use as the
    foundation of the classic profile.
  - Delete all other profiles except the Default profile. While not
    actually necessary, you may cause a mess if you re-enable Staged Profiles.
  - Turn off staged profiles in bash.ini with setting "bUseStagedProfiles=False"
  - Restart Wrye Bash

Future Staged Profile Enhancements
==================================
(1) Associate Bash settings (BashSettings.dat) with a profile so each
profile has its own settings. Today, Bash settings are common
to all Staged Profiles. Use the same technique as is used for BashLoadOrder.dat.
(2) Remove Backup Settings functionality.
Other than the bash.ini file, I think all data stored in the settings
backup archive are now associated with a Staged Profile. If you associate the
bash.ini file with the profile the the Backup Settings functionality is pointless.
If you want a backup of a profile, create a new Staged Profile with "(backup)"
appended to the profile name.
(3) Remove the Classic Profile system. Classic Profiles are only needed
to support games whose Saves and Game directories are on different drives.
Use junctioned point folders to cross the drives. This may not work as
mentioned in the "rejected approach" in the Technical Description below.
(4) The BashProfiles.dat file must remain common since it contains paths
to all profiles and is needed when switching profiles.


Technical Description
=====================
This design is slight of hand, a shuffling of the cards.
WB isn't aware of Staged Profiles. It continues to think it has
only one game Data folder, one Installers folder and one load order file.

WB creates hard linked files of every file in the game Data and
Installers folders and stores them in the profile's Saves folder.
Unlike NMM, which creates and deletes hard linked files in the
game Data folder when switching profiles, WB swaps the game Data folder
itself with a preconfigured/staged Data folder containing hard linked
and normal files.

The profile swapping process... When switching to a profile,
WB first DEACTIVATEs the existing profile by MOVING the Game/Data and
Game Mod folders to the active profile's Saves folder then ACTIVATEs
the requested profile by MOVING its folders from the Saves folder to
the Game/Data and Game Mod folders. It also swaps the BashLoadOrder.dat
files so each profile has its own load order history.
A new profiles starts with no load order history.
Installers.dat, Table.dat, and Converters.dat are unique to each profile.
BashConfig.dat is common to all Staged Profiles.

A design priority for this feature is to never break existing mod
configurations. Always preserve the integrity of the WB system,
i.e. it must always start up and work. If the swapping process fails,
even just occasionally, this will have a permanent negative impact
on WB's reputation and adoption. Therefore,

(1) Staged Profiles do NOT use BashInstallers.dat to determine which
files to be hard linked. It hard links ALL files in the game Data folder
without regard to what's in the BashInstallers.dat file.
Why? Potential untracked files must be preserved in the new profile
to preserve the integrity of the profile.

(2) No destructive actions, i.e. do not delete any files or folders.
When the user removes a staged profile its folder is moved to a
new folder, "Trash (deleted profiles)". A unique suffix is appended to
the profile's folder name to guarantee there are no collisions in this
Trash folder. Occasionally the user should "take out the trash".
Classic profiles continue to delete profiles from the Saves directory.

The final step in switching to a new profile is to restart WB.
Ideally, WB would call refresh methods to handle this but restarting
was the easiest way to guarantee that all caches, buffers, etc were
initialized with the new Data and Installer folders. Other games like
The Dark Mod (http://www.thedarkmod.com) uses this same approach when
switch from mission to mission.

Staged profiles use ln.exe (http://schinagl.priv.at/nt/ln/ln.html)
version 2.8.7.2 to hard link all files within a folder.
This "batch approach" is faster than having python walk through the
tree and hard linking files individually as NMM does. Hard linking only
works on Windows systems where the Game and Saves folders are on the
same drive. With this release, it does not work on Linux.

An alternate but rejected approach was to not move folders around
between Game and Saves. Instead create a junction in Game/Data that
points to the appropriate profile in Saves. When the user switches
profiles, delete the junctions and recreate them but now pointing to
the switched-to profile's Saves folder. This works fast and flawlessly.
If the user has a file or folder open in a moving folder, the user can
continue working undisturbed since he is actually working in the
original profiles Saves folder. This is ideal since no folders are
moved so less likely to encounter an error. However when you click on
the Installers tab, Bash blows. Obviously there is some code in the
refresh logic that doesn't like junctions. I was concerned this was
a can of worms so I didn't pursue it.

 

 

  • Like 2
Link to comment
Share on other sites

Very interesting @warmfrost85, python programmers are more than welcome. As a matter of fact I started working on https://github.com/wrye-bash/wrye-bash/issues/390 and naturally started thinking of #250 again, will reply to you there. No worries about github commit noise, rebasing on dev is a yes yes. Unfortunately my work on restore settings is pre alpha and on my local branches, will link to #250 asap. Be aware that Bash doesn't have Profiles, just SaveProfiles. There are several components to build the Bash settings (what would define a "profile"), including game selection, the Bash ini, cli options for user folders and game, and more. I am in the state of exploring those in relation with #390 (where I comment on profiles also, so have a look) and haven't quite wrapped my head around those. Adding different folders in there is a further step, plus hardlinking which adds further complications. In all I would suggest clarifying the booting process (have a look at initBosh() and initDirs()), then make restore/backup settings super robust, then investigating "true" profiles (with separate Data directories). The fact that nobody got it quite right is just an indication of how hard this problem really is.

 

Link to comment
Share on other sites

The long wait is over - 307 beta2:

307.201712232300

as usual in the dropbox: https://www.dropbox.com/sh/7b5ily482re0khs/AAD3vAWMVJNIpuS30tsdVte5a?dl=0

@alt3rn1ty all yours :D

Archives need to be renamed like the beta1 ones

I threw in a last minute warn for mods with TES4 header form version < 44 in SSE but I think it's ok

 

I would like to thank all people that contributed code, time and knowledge to make this possible: @alt3rn1ty, @saebel, @nycz, @iaz3, @Sharlikran, @fireundubh, @Daidalos, @Beermotor, @RavenMind, @Supierce, @zilav, @Arthmoor, @leandor, @valda just to name a few in random order and I am sure I forgot the half. Bear with me, releasing is stressful and stress makes one forget :P

Link to comment
Share on other sites

Whoops thats me .. Will do this tonight over the next 2-3 hours (bit of last minute Xmas preps going on)

Congratulations on getting this beta2 out Utumno, its certainly the most stable version we have ever had.

Utumno squashing bugs like a Jedi :starwars:

Fingers crossed Nexus behaves

Edit : That went quite smooth, all files uploaded for each Nexus page, and every uploaded file tested correctly for downloading. All version numbers updated, and each main page version updated. All sticky posts amended to chop out irrelevance and cut them back a bit. Old files have been shunted into the old files section.

All files with an exe in them are getting just one or two false positives on little known vendors on the VirusTotal result, but out of 60, the other 58 more reliable vendors are giving the files a clean bill of health :)

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