Wrye Bash - All Games

[Utumno]

Thanks @Dubious - fixed

[Dubious]

Sorry for the rambling nature of this report, but I wanted to accurately describe the sequence of events.

WB 307 for NV opened with the title bar "Wrye Flash NV 307: Default".  "Mods" tab was populated with the plugins in the game "Data" folder, but none were selected as "active".  (Which was not surprising, but suggests it did not pickup on the existing "tables.dat" from the WF install which is still present in the "Bash Mod Data" folder outside of the game folder.)  Chose to ignore this tab for the moment.

However, upon switching to the "Installers" tab, and choosing to "enable installers" it proceeded to work through (based upon the Advanced Readme: "BAIN Refresh" section, I presume) game "Data" folder for more than 10 minutes, only to display an "Installers" tab that was empty except for a newly created "==Last==" marker. Switched to the "Mods" tab and back to "Installers" but it was still empty of plugins.  By that Readme section, it should.

Checked the BashBugDump.Log:

Spoiler

Wrye Bash starting
Using Wrye Bash Version 307
OS info: Windows-7-6.1.7601-SP1
Python version: 2.7.12
wxPython version: 2.8.12.1 (msw-unicode)
input encoding: UTF8; output encoding: None; locale: ('en_US', 'cp1252')
filesystem encoding: mbcs
command line: ['Wrye Bash Launcher.pyw', '--debug']
bash.py  286 _main: Searching for game to manage:
bush.py   80 _supportedGames: Detected the following supported games via Windows Registry:
bush.py   82 _supportedGames:  Fallout New Vegas: E:\Games\SteamLibrary\steamapps\common\Fallout New Vegas
bush.py  140 _detectGames: Detecting games via the -o argument, bash.ini and relative path:
bush.py  150 _detectGames: No known game in parent directory of Mopy: E:\Games\Wrye Bash
bush.py  161 __setGame: Single game found [Fallout New Vegas]: E:\Games\SteamLibrary\steamapps\common\Fallout New Vegas
mods_metadata.py   39 <module>: Failed to import the loot_api module: (No module named loot_api)
testing UAC

Summary:
"mods_metadata.py   39 <module>: Failed to import the loot_api module: (No module named loot_api)"

It was at least implied that the LOOT API was included in the package but was not found to be present after installation.  Manually installed loot_api_python-1.2.0-0-g70371b7_master-win32, which was the last v1.2 version per the "Advanced Readme".  Noted that the latest version of the Python Module is v3.0.0, so decide to clear that up first.

LOOT v0.12.4 is installed separately, and does have a "setting,yaml" file under Users: "AppData\Local\LOOT".

Renamed the "Documents\My Games\FalloutNV" "BashSettings.dat" and ".dat.bak" files to not be recognized and re-tested hoping for a "clean slate".

Wrye Bash Error:

Spoiler

 

Wrye Bash starting
Using Wrye Bash Version 307
OS info: Windows-7-6.1.7601-SP1
Python version: 2.7.12
wxPython version: 2.8.12.1 (msw-unicode)
input encoding: UTF8; output encoding: None; locale: ('en_US', 'cp1252')
filesystem encoding: mbcs
command line: ['Wrye Bash Launcher.pyw', '--debug']
bash.py  286 _main: Searching for game to manage:
bush.py   80 _supportedGames: Detected the following supported games via Windows Registry:
bush.py   82 _supportedGames:  Fallout New Vegas: E:\Games\SteamLibrary\steamapps\common\Fallout New Vegas
bush.py  140 _detectGames: Detecting games via the -o argument, bash.ini and relative path:
bush.py  150 _detectGames: No known game in parent directory of Mopy: E:\Games\Wrye Bash
bush.py  161 __setGame: Single game found [Fallout New Vegas]: E:\Games\SteamLibrary\steamapps\common\Fallout New Vegas
testing UAC
mods_metadata.py  229 __init__: Using LOOT API version: 0.10.2
Error! Unable to start Wrye Bash.

Please ensure Wrye Bash is correctly installed.

Traceback (most recent call last):
  File "bash\bash.py", line 323, in _main
    bosh.initBosh(opts.personalPath, opts.localAppDataPath, bashIni)
  File "bash\bosh\__init__.py", line 3411, in initBosh
    initDirs(bashIni, personal, localAppData)
  File "bash\bosh\__init__.py", line 3221, in initDirs
    configHelpers = ConfigHelpers()
  File "bash\bosh\mods_metadata.py", line 258, in __init__
    self.refreshBashTags()
  File "bash\bosh\mods_metadata.py", line 289, in refreshBashTags
    u'\\taglist.yaml could not be found.  Please ensure Wrye '
BoltError: Mopy\Bash Patches\Fallout New Vegas\taglist.yaml could not be found.  Please ensure Wrye Bash is installed correctly.

 

Summary:
"mods_metadata.py  229 __init__: Using LOOT API version: 0.10.2"
"BoltError: Mopy\Bash Patches\Fallout New Vegas\taglist.yaml could not be found.  Please ensure Wrye Bash is installed correctly."

Installed "loot_api_python-3.0.0-0-g1275a11_master-win32" instead.

Wrye Bash Error:

Spoiler

 

Wrye Bash starting
Using Wrye Bash Version 307
OS info: Windows-7-6.1.7601-SP1
Python version: 2.7.12
wxPython version: 2.8.12.1 (msw-unicode)
input encoding: UTF8; output encoding: None; locale: ('en_US', 'cp1252')
filesystem encoding: mbcs
command line: ['Wrye Bash Launcher.pyw', '--debug']
bash.py  286 _main: Searching for game to manage:
bush.py   80 _supportedGames: Detected the following supported games via Windows Registry:
bush.py   82 _supportedGames:  Fallout New Vegas: E:\Games\SteamLibrary\steamapps\common\Fallout New Vegas
bush.py  140 _detectGames: Detecting games via the -o argument, bash.ini and relative path:
bush.py  150 _detectGames: No known game in parent directory of Mopy: E:\Games\Wrye Bash
bush.py  161 __setGame: Single game found [Fallout New Vegas]: E:\Games\SteamLibrary\steamapps\common\Fallout New Vegas
testing UAC
mods_metadata.py  229 __init__: Using LOOT API version: 0.12.0

Traceback (most recent call last):
  File "bash\bash.py", line 227, in main
    _main(opts)
  File "bash\bash.py", line 323, in _main
    bosh.initBosh(opts.personalPath, opts.localAppDataPath, bashIni)
  File "bash\bosh\__init__.py", line 3411, in initBosh
    initDirs(bashIni, personal, localAppData)
  File "bash\bosh\__init__.py", line 3221, in initDirs
    configHelpers = ConfigHelpers()
  File "bash\bosh\mods_metadata.py", line 232, in __init__
    lootDb = loot_api.create_database(gameType, bass.dirs['app'].s)
AttributeError: 'module' object has no attribute 'create_database'

 

Summary:
"mods_metadata.py  229 __init__: Using LOOT API version: 0.12.0
Wrye Bash encountered an error."
"AttributeError: 'module' object has no attribute 'create_database'"

(Talk about confusing naming conventions.  Version v3.0.0 is actually v0.12.0?)

Restored the renamed the "Documents\My Games\FalloutNV" "BashSettings.dat" and ".dat.bak" files, and re-tested: with no change to the last error message.

-Dubious-

 

[Utumno]

Forget about loot, don't include any api in there @Dubious - there is some support for the newer version in my wip-branch but still beta - waiting on @Daidalos on that

5 hours ago, Dubious said:

Which was not surprising, but suggests it did not pickup on the existing "tables.dat" from the WF install which is still present in the "Bash Mod Data" folder outside of the game folder.

The info on active plugins should be read in the plugins.txt. Bash should pick that up - where is that located ?

Re: installers - try redirecting the installers dir to the actual Bash Installers folder for falloutNV? You can do that via the ini.

EDIT: most of this mess is because of renaming FalloutNV to Fallout New Vegas - I bet the plugins txt is in FalloutNV folder. Which means I will rename this back to FalloutNV and you will have to redirect the installers dir via the ini

 

 

[alt3rn1ty]

Devils advocate head on /

I can see this idea to include FO3 and FNV causing a lot of hassle and lots more delay to the main desired goal of getting a good bunch of patchers again one day, which is for many people the only reason they install Wrye Bash.

If the rename is reversed, and when this goes live, is that renaming going to negatively impact the many users of Wrye Flash out there ?, I mean if its so much of a problem with just one tester that the decision is to be reversed, what will it be like when it hits thousands of them with the already in place reverse naming convention ?.

Also aren't those communities still riddled with plugins corrupted by Snip and its record compression issues that it introduced on a wide scale?, I am just imagining Wrye Bash trying to make head or tales out of Snip corrupted plugins which will make the v43 / v44 issues pale in comparison, no Mod Authors supporting their old plugins anymore (though they would not help and most likely be adament there is nothing wrong to correct if they are still around anyway) .. And the expert on Snip issues Sharlikran, has left the building.

I maybe wrong and the impact of Snip is not so wide spread, but from what I recall there were a lot of authors using it for its convenience and made a complicated mess.

Am I just being a negative nanny, or is this going to be far more trouble than its worth for the project ?.

[Utumno]

We will put a big fat disclaimer up there that this is a beta and will remain a beta - I spelled it somewhere. We will have a guide with setting up the ini probably - apparently, it did not pick up the folder anyway. Or I could hack something just for the installers on fallout new vegas...

But having two branches and applying changes to two branches has been a tremendous loss of my time and energy. And since after all this is working code, I think it's high time we merged

[alt3rn1ty]

Sounds good 

Devils advocate mode off //

[Sharlikran]

For the Wrye/Bash/Flash folders, it will be Fallout3 and FalloutNV before Mods because of the short game name. Even valda's version uses that. If that was changed it would drive me crazy because then I'd have to make a Bash INI and add the path from Valda's versiosn.  Which was originally 295 with some updates from other versions here and there.  That path name has not changed ever as far as I know.

For Dubious, once Utumno has the NV/FO3 version fully integrated it will not support the same patchers as Valda's versions because most patchers are still Oblivion specific. So test it, and then you would have to wait for the patchers to be refactored so that multi game support is more fluid.

[Utumno]

Ok reverted the change of game fsName to Fallout New Vegas - should pick up active mods correctly and probably the installers dir - should also work with loot (although not the newer one, the one we bundle with Bash 307 - however I don't think the internal taglists are correctly updated)

[Dubious]

Wrye Flash 17.7 installed to FNV game folder on Win7SP1.
Removed all previously added LOOT API files.
Installed "wrye-bash-150-fo3-fnv-support_20180226_1325.zip" over existing prior versions of the same release in "E:\Game\Wrye Bash".
Renamed initial "BashSettings.dat" and ".bak" to get a "clean slate".  (This worked as expected.)
Launched 'C:\Python27\pythonw.exe "<install path>\Mopy\Wrye Bash Launcher.pyw"'.
"Mods" Tab was populated with current selected "Data" files.  (Previously they weren't selected.)
Switched to "Installers" Tab and chose NOT to enable "Installers" this time.
On empty "Installers" tab, <right-click> on header field and selected "Enabled".  Spent 14:30 minutes processing some 600+ files.
Only the "==Last== marker was displayed.
Closed WB.
Copied the "E:\Game\Wrye Bash\Mopy\bash_default.ini" file to the same location, as "bash.ini"; and editted according to the "Advanced Readme" guide under "Alternative Install Locations".

Bash.ini edits:

sOblivionMods=E:\Games\Fallout New Vegas Mods\Bash Installers
sBashModData=E:\Games\Fallout New Vegas Mods\Bash Mod Data
sInstallersData=E:\Games\Fallout New Vegas Mods\Bash Installers\Bash
sOblivionPath=E:\Games\SteamLibrary\steamapps\common\Fallout New Vegas
sUserPath=C:\Users\Dubious
sPersonalPath=C:\Users\Dubious\Documents
sLocalAppDataPath=C:\Users\Dubious\AppData\Local
bSteamInstall=True
iKeepLog=1
sLogFile=Mopy\bash.log

Launched again in "debug" mode.  No errors in log.  "Installers" Tab now populated with my previous WF "markers" (yea!), but not any mod packages.  No change after switching to "Mods" tab and back to "Installers".  Then ran "Full Refresh", but that did not populate the packages either.  

No change upon closing WB and then re-running and switching to "Installers" tab.   No "bash.log" file found.  "BashBugDump.log" only has failure to import "loot_api module" error.

* It is not clear in the Readme if the edits to the "bash.ini" file are supposed to leave the setting variable names (such as "sOblivionPath") the same regardless of game, or if they are supposed to be changed to reflect the game (e.g. "sFalloutNVPath") if there are multiple games installed.  If the latter case, a list of the valid "game" names for such variables to be used should be provided.  I choose to leave the variable names unchanged based upon the examples in the actual INI file and only one game being recognized.

The difference in the nature of the "data" between "sOblivionMods" and "sInstallersData" is not clear.  An example of a file to be expected in the latter instance (e.g. "Installers.dat") would be helpful; both for editing and for identifying what needs to be backed up if using multiple "profiles".  (This was a "new" WB related file to me.)

The "Advanced Readme" needs a section listing the files and locations that need to be preserved between multiple instances of the same game (e.g. a "current game" and a "test game" instance of WB files).  It's difficult to find them scattered across the various files and sections if you aren't ware of them in the first place.

@Sharlikran:  Thanks for the advice.  Noted and added to the migration guide I'm working on.

Speaking of which, what type of programmer is needed for the FO3 & FNV patcher code? There is no "CBash" option in WF, so I am assuming it is currently Python code.  But going forward, will it need to be some version of "C"?  I plan to add that information to the "Disclaimer" statement.

@Utumno: FNV does not have a "plugins.txt" file.  (Older Gamebryo engine.)  Checked both the "game install" and the "Data" folders.

-Dubious-

 

[Utumno]

6 hours ago, Dubious said:

* It is not clear in the Readme if the edits to the "bash.ini" file are supposed to leave the setting variable names (such as "sOblivionPath") the same regardless of game, or if they are supposed to be changed to reflect the game

same regardless of game

7 hours ago, Dubious said:

"Installers" Tab now populated with my previous WF "markers" (yea!), but not any mod packages. 

It read Installers.dat that's where the markers are stored - when you select Open.. in the installers columns menu which folder does it open? I do hope you baked up the Installers dat original cause Bash overwrites it on shutdown

7 hours ago, Dubious said:

sOblivionMods=E:\Games\Fallout New Vegas Mods\Bash Installers

This means that Valda's version does indeed use the "Fallout New Vegas" name internally - too bad

7 hours ago, Dubious said:

The difference in the nature of the "data" between "sOblivionMods" and "sInstallersData" is not clear.  An example of a file to be expected in the latter instance (e.g. "Installers.dat") would be helpful; both for editing and for identifying what needs to be backed up if using multiple "profiles".  (This was a "new" WB related file to me.)

The "Advanced Readme" needs a section listing the files and locations that need to be preserved between multiple instances of the same game (e.g. a "current game" and a "test game" instance of WB files).  It's difficult to find them scattered across the various files and sections if you aren't ware of them in the first place.

Feel free to add examples to the default_ini and advanced readme - just please do this in as a final (and minimal) way as possible - turns out editing and reviewing other people's stuff is as time-consuming as doing it from scratch. The multitude of Bash settings and locations is an inevitable product of the game itself modular setting locations plus the need to support different games and installs. It's one of the things I am working on and good docs are badly needed. Please, when editing the readme wrap your lines at 140 chars or so - do not do any formatting or other non-essential differences makes super hard for me to review. Just copy the readme from the python code and add what you think it's needed then link me to it. Please diff it before and verify only needed changes are in

7 hours ago, Dubious said:

Speaking of which, what type of programmer is needed for the FO3 & FNV patcher code?

Python - FNV may support CBash too (!)

7 hours ago, Dubious said:

FNV does not have a "plugins.txt" file.  (Older Gamebryo engine.)  Checked both the "game install" and the "Data" folders.

C:\Users\MrD\AppData\Local\FalloutNV ?

7 hours ago, Dubious said:

"BashBugDump.log" only has failure to import "loot_api module" error.

And lots of other info - please post me that one

7 hours ago, Dubious said:

Noted and added to the migration guide I'm working on.

Great!

[Utumno]

9 hours ago, Dubious said:

sOblivionMods=E:\Games\Fallout New Vegas Mods\Bash Installers

Should be 

sOblivionMods=E:\Games\Fallout New Vegas Mods

- please correct the advanced readme. Now it will find your installers

[Dubious]

Quick reply as you wanted the "BashBugDump.log" from the last test session:
 

Spoiler

 

Wrye Bash starting
Using Wrye Bash Version 307
OS info: Windows-7-6.1.7601-SP1
Python version: 2.7.12
wxPython version: 2.8.12.1 (msw-unicode)
input encoding: UTF8; output encoding: None; locale: ('en_US', 'cp1252')
filesystem encoding: mbcs
command line: ['Wrye Bash Launcher.pyw', '--debug']
bash.py  286 _main: Searching for game to manage:
bush.py   80 _supportedGames: Detected the following supported games via Windows Registry:
bush.py   82 _supportedGames:  FalloutNV: E:\Games\SteamLibrary\steamapps\common\Fallout New Vegas
bush.py  140 _detectGames: Detecting games via the -o argument, bash.ini and relative path:
bush.py  146 _detectGames: Set game mode to FalloutNV based on sOblivionPath setting in bash.ini:  E:\Games\SteamLibrary\steamapps\common\Fallout New Vegas
bush.py  161 __setGame:  Using FalloutNV game: E:\Games\SteamLibrary\steamapps\common\Fallout New Vegas
mods_metadata.py   39 <module>: Failed to import the loot_api module: (No module named loot_api)
testing UAC

 

"sOblivionMods=E:\Games\Fallout New Vegas Mods\Bash Installers" was created by me and added to the "Bash.ini" for WF; not by Valda.

and:

"plugin.txt" is indeed under "AppData\Local\FalloutNV".  (Another location I had not been aware of needing to check.)

Selecting "Open" from "Installers" tab context menu opens "E:\Games\Fallout New Vegas Mods\Bash Installers\Bash Installers".  Which is one level too deep.  Next test I will try shortening up that path in the "bash.ini: sOblivionMods=" line.

Other points noted.  Time to get some sleep.  Later.

-Dubious-

[Arthmoor]

I take it there's confusion as to which file path everything is using? IMO we should make transitioning from Wrye Flash as easy as possible on people who have installers already set up. So I guess getting this right is important.

[Dubious]

Correcting bash.ini to use:

sOblivionMods=E:\Games\Fallout New Vegas Mods

resolves the issue of packages loading in the BAIN tab.  The current problem to be resolved is that packages are loaded without regard for the markers.  This is a major pain with 600 packages and needs to be properly documented by me in the migration guide to prevent it from affecting others.  Expect this was my error as while I had backed up the "table.dat" file, I hadn't known about the "installers.dat" and thought I had (but hadn't) used the "Backup & Restore Settings" function which apparently only works with ".7z" files.  At least, I can't get "Restore Settings" to display any files without that extension.

A quick flip through the various tabs suggest they are all functional, but until I get the BAIN tab sorted out they won't get  a real workout.  But the major hurdles seem to be overcome.

I won't be making any direct edits to the Readme files for the moment.  Need to collect some information and work out my suggestions more fully, and then I would like to run them by @alt3rn1ty first to keep things consistent with the existing framework.  I can do that privately to avoid cluttering up this thread.

-Dubious-

[Utumno]

6 hours ago, Dubious said:

Expect this was my error as while I had backed up the "table.dat" file, I hadn't known about the "installers.dat" and thought I had (but hadn't) used the "Backup & Restore Settings" function which apparently only works with ".7z" files.  At least, I can't get "Restore Settings" to display any files without that extension

Restore is broken but you only see 7z cause Backup creates a 7z backup. All the info on installers order is In Installers.dat. So if you made a backup of your Valda Flash Installers .dat (I hope you did!) this will be inside the 7z file - so manually restore that and you have your install order back.

What happened is you loaded installers pointing to the correct location of installers.dat but wrong Bash Installers (one level too deep) - so Bash only found the markers. On closing Bash Installers dat was overwritten to only contain the markers - when then you pointed Bash to the correct Bash Instalelrs dir Bash naturally detected all installers and dumped them to its list before ==Last==

6 hours ago, Dubious said:

I won't be making any direct edits to the Readme files for the moment.

At least please keep some notes of what needs to be edited - the section on advanced installation for instrance should be crystal clear otherwise bad things may happen - see above

[Utumno]

307.201803041642

Fallout 3/nv support - based not on utumno wip but on https://github.com/wrye-bash/wrye-bash/tree/150-fo3-fnv-support

Bad news - can't make loot api to work on Standalone - if it crashes for you please delete Mopy/loot_api.dll - Bash will start but with no loot support

Waiting on @Daidalos for this one

[alt3rn1ty]

ehm, if this replaces the standalone we linked on nexus comments which we called pre-beta3 for everyone to test .. and LOOT API is not working .. I think I will steer clear of nexus Wrye Bash comments for a while, until the fan has stopped dripping brown stuff  quite a lot of people had good success with Pre-beta3 having had issues with beta2

This is what we have linked on Skyrim LE nexus sticky post ..

Quote

ANYONE WITH GAME FREEZING ISSUES WILLING TO TEST A PRE-BETA3 NIGHTLY BUILD
>>GRAB THE INSTALLER HERE<<

.. Now they are going to have gone from game freezing, to good beta3, to a new beta3 with LOOT issues which is not based on Utumno WIP (and probably puts them back with game freezing issues again) ?.

 

@Utumno @Daidalos do you all know about the GitHub issue changing over to TLS 1.2 now ?, and if you have an older windows than Win 10 you may have issues with windows not correctly updating you to support it and drop older insecure encryption ?

If you were not aware of this see pStyl3's second sticky post in LOOTs comments here. He posted a link for everyone to follow, there is a MS manual update to apply, and some registry settings to be made.

After WrinklyNinja released LOOT v0.12.4 a few days ago that note was made to ensure everyone updates their windows manually where necessary. There are still a lot of users posting the same problem that LOOT will not update its masterlist due to errors with GitHub, but there isn't a lot Wrinkly can do about the situation apart from advise them of the windows fixes to be done by everyone concerned.

See also LOOT download page .. 

Quote

Windows 7 users must also ensure that they have enabled TLS 1.2 support to support updating the masterlists from LOOT's official repositories on GitHub.

There have also been reports from Win 8 users who needed to do the same.

[Utumno]

13 hours ago, alt3rn1ty said:

Now they are going to have gone from game freezing, to good beta3, to a new beta3 with LOOT issues which is not based on Utumno WIP (and probably puts them back with game freezing issues again)

I need this tested - does indeed loot not work for everyone else? This is basically the previous packaged build (contains utumno-wip) with the fallout3/nv support in, it won't freeze the game anymore than the previous one

[alt3rn1ty]

I just started night shifts again so it will be a week before I can get round to testing, but good to hear keeping the link up will not break anyones setup participating in Pre-beta3

[Sharlikran]

On 2/26/2018 at 8:02 PM, Dubious said:

 

Bash.ini edits:

sOblivionMods=E:\Games\Fallout New Vegas Mods\Bash Installers
sBashModData=E:\Games\Fallout New Vegas Mods\Bash Mod Data
sInstallersData=E:\Games\Fallout New Vegas Mods\Bash Installers\Bash
sOblivionPath=E:\Games\SteamLibrary\steamapps\common\Fallout New Vegas
sUserPath=C:\Users\Dubious
sPersonalPath=C:\Users\Dubious\Documents
sLocalAppDataPath=C:\Users\Dubious\AppData\Local

 

Thanks for the advice.  Noted and added to the migration guide I'm working on.

 

Speaking of which, what type of programmer is needed for the FO3 & FNV patcher code? There is no "CBash" option in WF, so I am assuming it is currently Python code.  But going forward, will it need to be some version of "C"?  I plan to add that information to the "Disclaimer" statement.

The Bash INI is there to customize your setup but I never use it. Once the official Bethesda launcher runs it will automatically set the paths, although I have not reinstalled anything since my HD crash. I don't remember all the paths. I could swear though that the users path is FalloutNV and the installers path is as you have it as Fallout New Vegas.  If I am ever able to install things again I can use Valda's old versions and test to be sure.

As far as programming it's just python code. Updating CBash to work with all five games would be a greater undertaking then altering the patchers.  Once patchers allow for adding the variables to a dictionary, set, or whatever makes sense all that has to happen is to use them and account for the differences between each game as the currently active patchers allow. When I started tinkering with the patchers I just changed the ones that were easy enough for me to change with my limited knowledge.

[alt3rn1ty]

@Utumno The new nightly build installer has gone a bit backwards instead of forwards

It no longer recognises it needs to install for Fallout 4 (previous nightly build installer does), aswell as not offering to install for FNV / FO3

Screenshots in spoiler ..

.. Hope this is not the old installer prior to Fireundubh's work which solved the messed up installations ?

Going back to the previous one for now.

 

 

[Utumno]

Hmmm I just took some changes by @Sharlikran - we probably need to summon @fireundubh again - are you here ?

[Sharlikran]

You can't fit all the games on one screen and the installer can't be resized. The previous code was pushing other installers off the screen. In you screen shot it tells you that Fallout installations will be next.

[fireundubh]

8 hours ago, Utumno said:

Hmmm I just took some changes by @Sharlikran - we probably need to summon @fireundubh again - are you here ?

What do you want from me now? 

[Sharlikran]

@fireundubh You don't want to wait until they look more and see what they missed?