alt3rn1ty Posted December 19, 2017 Share Posted December 19, 2017 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 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" ? Utumno 1 Link to comment Share on other sites More sharing options...
Utumno Posted December 19, 2017 Author Share Posted December 19, 2017 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 ? alt3rn1ty 1 Link to comment Share on other sites More sharing options...
alt3rn1ty Posted December 19, 2017 Share Posted December 19, 2017 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. Utumno 1 Link to comment Share on other sites More sharing options...
Arthmoor Posted December 19, 2017 Share Posted December 19, 2017 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. alt3rn1ty 1 Link to comment Share on other sites More sharing options...
alt3rn1ty Posted December 19, 2017 Share Posted December 19, 2017 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 More sharing options...
Utumno Posted December 19, 2017 Author Share Posted December 19, 2017 Ok ok I'll try and fix - 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) alt3rn1ty 1 Link to comment Share on other sites More sharing options...
Beermotor Posted December 20, 2017 Share Posted December 20, 2017 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. Utumno 1 Link to comment Share on other sites More sharing options...
Joat_Mon Posted December 21, 2017 Share Posted December 21, 2017 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 More sharing options...
RavenMind Posted December 21, 2017 Share Posted December 21, 2017 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 More sharing options...
Joat_Mon Posted December 21, 2017 Share Posted December 21, 2017 (edited) 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 December 21, 2017 by Joat_Mon clarity Link to comment Share on other sites More sharing options...
RavenMind Posted December 21, 2017 Share Posted December 21, 2017 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 More sharing options...
alt3rn1ty Posted December 21, 2017 Share Posted December 21, 2017 @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 .. Link to comment Share on other sites More sharing options...
Joat_Mon Posted December 21, 2017 Share Posted December 21, 2017 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 More sharing options...
alt3rn1ty Posted December 21, 2017 Share Posted December 21, 2017 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 More sharing options...
Joat_Mon Posted December 21, 2017 Share Posted December 21, 2017 (edited) 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 December 21, 2017 by Joat_Mon Add Info Utumno 1 Link to comment Share on other sites More sharing options...
alt3rn1ty Posted December 21, 2017 Share Posted December 21, 2017 Ah, Bleeding edge is quite a bit behind the times now. Link to comment Share on other sites More sharing options...
Utumno Posted December 22, 2017 Author Share Posted December 22, 2017 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 More sharing options...
Joat_Mon Posted December 22, 2017 Share Posted December 22, 2017 (edited) 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 December 22, 2017 by Joat_Mon Add Info Link to comment Share on other sites More sharing options...
Joat_Mon Posted December 23, 2017 Share Posted December 23, 2017 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. Beermotor 1 Link to comment Share on other sites More sharing options...
Daidalos Posted December 23, 2017 Share Posted December 23, 2017 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 Beermotor 1 Link to comment Share on other sites More sharing options...
Joat_Mon Posted December 23, 2017 Share Posted December 23, 2017 I see it now, thanks. Link to comment Share on other sites More sharing options...
warmfrost85 Posted December 23, 2017 Share Posted December 23, 2017 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. Beermotor and Utumno 2 Link to comment Share on other sites More sharing options...
Utumno Posted December 23, 2017 Author Share Posted December 23, 2017 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 More sharing options...
Utumno Posted December 23, 2017 Author Share Posted December 23, 2017 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 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 Beermotor, Daidalos, Arthmoor and 1 other 4 Link to comment Share on other sites More sharing options...
alt3rn1ty Posted December 23, 2017 Share Posted December 23, 2017 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 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 Beermotor and Utumno 1 1 Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now