Testing behaviour of Wrye Bash via MO with bashed patch

[GrantSP]

I'm testing a peculiar behaviour with Wrye Bash via MO and I wonder if anyone else could verify this for me before I post a bug report.

 

After you run Wrye Bash you are given a browser window with a report of what was just accomplished.

However when run through MO there is an unexpected behaviour.

 

The Bashed patch, 0.html from the overwrite folder is NOT used.

 

If you have never bashed a patch before there will be no mod installed in the MO 'mods' folder so the browser window will show a generic:

 

This page can’t be displayed

• Make sure the web address is correct.
• Look for the page with your search engine.
• Refresh the page in a few minutes.

 

• Check that all network cables are plugged in.
• Verify that airplane mode is turned off.
• Make sure your wireless switch is turned on.
• See if you can connect to mobile broadband.
•  

If you create a mod from the overwrite that includes the patch and the Docs folder, only the bashed patch (the *.esp) is immediately updated. The 'Docs' folder from subsequent bashing stays in the overwrite and needs to be moved to the patch mod.

 

Now the 'Bashed patch' mod contains the plugin and a docs folder with the *.html & *.txt reports.

 

Running Wrye again and "rebuilding the patch proceeds and there is a report window but it contains the details from the previous patching, not that which has just finished.

This can be verified by editing the *.html in the 'mods' folder and replacing all the text with a sample message such as:

"This is not the bash message you are looking for."

 

 

So, to summarize.

 

1. First time the Wrye bash is run the report window shows as empty, ie. no Bashed patch, 0.html is found.
2. After these reports are made into a mod and the process is repeated, the report window shows the previous report, not that which was just run.

 

I'm also looking at why the two reports aren't automatically updated in the same manner as the esp, but that is secondary to this.

[hishutup]

I think it has to with that Wrye Bash writes the file and then at the same time, MO moves it to the Overwrite folder and Wrye Bash tries to open the file.

[GrantSP]

Can at least one other person see if these things happen when using Wrye Bash via MO?

 

If you are worried about messing up your existing bashed patch, just deactivate that mod and create a new patch in a new profile.

 

I'd rather not add to the existing Bug Reports if this can be shown to be peculiar to my system.

[GSDFan]

I have not seen this. A new profile with no mods activated other that the DLC results in the BP in the overwrite folder and a full report window. Editing the report and running WRYE results in the report updating with the current run instead of the edited one.

 

Edit: For what it is worth running Windows 8.1 x64

[GrantSP]

Thank you. Could you check the second part of my query? What happens when you redo your bashed patch, does the report reflect the new changes or the previous?

 

Also I've just noticed whenever I do this the Docs folder shows in the overwrite with a "locked" overlay icon, although the folder and files show no 'read only' properties when examined in explorer.

 

None of my software exist in any UAC folders and I have full administrator rights to my whole machine. Somehow there may be a conflict of permissions going on.

Edited December 13, 2014 by GrantSP

[GrantSP]

This is very perplexing. I just set up Wrye Bash in my MO managed Oblivion setup and tried the same steps.

Exactly the same results.

 

The browser error message I think I have narrowed down to IE. It matches the wording so all I can assume is Wrye Bash is trying to load IE as the default browser engine but I have Chrome as the default browser. Surely not though. I can't be the only person that has Chrome as the default browser on my system!

 

No matter what I do it is always the previous report that is displayed and the Docs folder is always shown with a 'padlock' overlay denoting it being locked, but it isn't.

 

Also I have no idea what the MO option to "Sync mod.." is supposed to do. In my Skyrim MO it only shows a 'Don't sync' option but in the Oblivion session I can choose Bashed Patch to sync to but it doesn't appear to do anything different to not using it.

[GSDFan]

The report is rebuilt and displayed with the new info.

 

I believe the sync to feature will only sync files that can be tracked by MO. I used to use it and was trying to document how it works, but I never finished it. I will have to look for my notes to go into more detail.

[GrantSP]

Thank you.

So there is something wrong with my Wrye Bash install then. I think another user reported something similar here, I'll look and see if the two setups are similar.

 

Just one more thing, the reports, do they automatically get placed into the Bashed Patch mod or do you still have to manually move them from overwrite?

[GSDFan]

Something on your system is amiss. My report is in the D:\Steam\SteamApps\common\Skyrim\Data\Docs folder. It never goes to the overwrite folder.

 

On my system without a BP, when Wrye is run it copies the BP to the overwrite folder. When the BP is rebuilt the patch is updated. There is only the patch in the overwrite folder. When I make a mod from it, the next time I run Wrye the patch in the mod gets updated and the overwrite is empty.

[GrantSP]

Yeah agreed, but I can't figure out what it is.

 

I've just removed the current Standalone install and tried the installer version, same result.

Both Oblivion and Skyrim installs produce the same thing and I can not for the life of me figure out why that locked overlay icon appears for the Docs folder.

 

Oh hang on, just re-read your post. The Wrye Bash report gets placed directly in the Skyrim Data folder? Not into a mod folder under the ModOrganizer folder?

 

That is really strange. Why would it do that? MO doesn't allow anything like that to happen.

 

This is the setting in ModOrganizer.ini that handles the custom executable for Wrye on my system.

9\binary=C:/Games/Utils/Mopy/Wrye Bash.exe
9\title=Wrye Bash
9\arguments=-g Skyrim
9\workingDirectory=
9\closeOnStart=false
9\steamAppID=
9\custom=true
9\toolbar=false

Wrye Bash runs just fine from outside MO and generates reports and makes bashed patches just fine, so the install location shouldn't have any bearing.

All I've done is placed 1 installation in that folder and used the switch -g Skyrim or -g Oblivion to tell it to work for whatever game MO is currently on.

Is that similar to yours?

[pistolouco]

Hey GrantSP, for me its look like all this is working exactly like u said. I follow your steps and:

 

1) got the message:

 

 

2) and the error in M.O.:

 

 

now i changed the wrye report and did a second run with wrye bash :

 

 

  

 

After that, I also tried another time with all mods in MO enable and i got the RIGHT report  :O_o: in Overwrite but no Bashed Patch, 0.esp   !!!

 

What foul sorcery is this ????

 

OBS: My MO and Mopy are in Skyrim folder ; and My Skyrim isn't in defaut directory to not allow steam mess up with.

 

 

Edited December 17, 2014 by pistolouco

[z929669]

Just wild guessing, but I would double check folder permissions for MO_Mods and all of the WB folders listed in the bash.ini. Then I would configure those paths in both apps (and be sure you are running latest version of both apps).

 

I get standard 'good' behavior, but my WB/MO folder locations are custom and not on same drive as Skyrim. My MO download directory is same as my WB package directory.

[GrantSP]

@pistolouco

 

Actually what you did wasn't exactly the same as me but it does show the principle. In your test the Bashed Patch wasn't active when you ran WB for the second time. At least that is what I am surmising based on the first screenshot.

But, MO should have allowed WB to display the report from that current running instead of the error message, so the end result is the same.

 

Regarding permission issues, that isn't possible in my instance. I have checked and triple checked and there are no permission issues with any of my programs.

 

Although this isn't the expected behaviour for MO to show, I'm loathe to make a bug report for what is a very minor issue. The patch itself works just fine and is updated properly, it's just the reports.

 

I think I will just let this rest and this thread can serve as a documented history that might be useful later on.

[pistolouco]

            GrantSP dude, now i'm worried   and  u aren't . Take back your worries! i'm giving it back ::P:  ! By the way, in the fist run, the bashed patch was inactive, like displayed in the first image; and in the second run, it was active like in the 3 image.

             z929669 thanks! I did a fresh install of MO and Wrye. Also, i have full control and permissions for MO and Mopy folders and all these EXEs are run as administrators.

Edited December 18, 2014 by pistolouco

[GrantSP]

Yeah, don't sweat it, it's just the reports that are bugging out, and apparently only on a few systems; yours, mine and I think one other.

The bashed patches are created perfectly and that's all we need worry about.

 

Having said that feel free to further investigate this phenomenon, whatever the outcome it all goes towards forming a knowledge base that everyone can learn from.

 

 

EDIT:

May I ask you, in the overwrite folder, when you open it and examine the contents does the 'Docs' folder have that padlock icon I mentioned?

Edited December 18, 2014 by GrantSP

[pistolouco]

Yep! The Docs folder always have it! Hummm......

Edited December 18, 2014 by pistolouco