Wrye Bash - All Games

[Sharlikran]

@Nayu37 That log isn't what I expected to see. I'm not so worried about the bush.pyo 172, where is says no preferred game specified because the previous line shows it sees oblivion found in the parent directory. What concerns me is the last line. Why on earth would it say that only one instance of Wrye Bash can run? I know why is says that, it says that when you have two copies open, but then you get a prompt about that, and you close them all and then open only one. So the log is just confusing.

One thing that I waned to see in that log was the mbcs for the filesystem encoding and the code page, so that's supported. However, that error about having only one instance open has me stumped. I'm gonna have to say it's a system related interference. Try to run as admin, disable all virus, firewall, and malware as they tend to provide protection against potential threats, however the threat is usually just an unsigned EXE that has no virus in it. For TES5Edit, FO4Edit, we have programs that just won't allow the EXE to run because it's not on the virus programs list, whatever it's called, a white list or whatever.  Kaspersky is the big trouble maker for xEdit, I don't know what programs cause Wrye Bash issues. I don't know of anyone that would use Mod Organizer with Oblivion, but just in case, Wrye Bash isn't supported with MO.

One way or another you have a supported environment, just something is preventing it from running, or something is making your system confused and think you have two copies running. I just don't see how it could think you have two copies open. That could be a false error, so that's why I'm also going with a system related issue. Also it's not Windows 10, lots of people have that. When I say system related issue I mean something you have installed that restricts access to programs, not your version of windows.

[alt3rn1ty]

From a post by CDCooley https://forums.nexusmods.com/index.php?/topic/6043958-unofficial-skyrim-creation-club-content-patches/page-15#entry54334023

Charlie breaks it down to 4 groups ..

Quote

There's absolutely nothing magical happening here, but people have gotten too comfortable with the idea that those first two digits of a formId you see in the game's console represent load order. They used to but now they don't thanks to ESL files. It's time to adapt folks. I'm seeing various people testing how things load by looking that the formID numbers in-game. 

Load order is controlled by the game's hard-coded list of official content and then things listed in the plugins.txt file. The numbers assigned as the first two digits of formID values in-game have nothing to do with load order when ESL files are involved. 

From my testing there appear to be only four groups of files that the game considers when loading files. 

First are the official files that are hard-coded into the game itself. Those used to be just Skyrim.esm, Update.esm, Dawnguard.esm, HearthFires.esm, and Dragonborn.esm but now include all of the new Creation Club ESL files too. That means the survival ESL will always load before any traditional mods including USSEP. If they exist in your Data folder they will be loaded and any entries in the plugins.txt file for them are ignored. 

Second are files listed in plugins.txt that are internally tagged as masters and marked as active. It doesn't matter what file extension they use (ESM, ESP, or ESL). They get loaded in the order they appear in the plugins.txt file (but only their order in relation to each other matters). 

Third are any other mods as listed in plugins.txt that are marked as active. The are the regular mods that we used to call ESPs but can technically include files with the extensions ESM and ESL too. 

And finally, the fourth group consists of only one file. It's the save file (ESS) being loaded (or a blank file if you're starting a new game).

Hopefully various mod managers (and LOOT) can be updated soon before too much chaos results from people thinking there's something more complicated and confusing happening. 

 

Edit : My bold in yellow

[Beermotor]

2 hours ago, DylanJames said:

Hey guys. I don't know if this issue has been addressed or brought up in this topic (I tried looking but couldn't find anything). On any of the Wyre Bash builds I've tried that support ESLs for SSE, none of them seem to understand that ESLs don't have the same load order prefixes as standard plugins (or, probably to be more accurate, it's counting ESLs towards your 255 plugin limit). Example, I've attached an error image I get when trying to activate a (blank) ESL in a full load order (with other ESL files).

Probably an oversight. Is there any way to bypass this restriction outside editing the code?

Thanks for the development you're putting into Wyre Bash.

Yes AFAIK this is still being worked on.  Quick question regarding the error message: was this generated with 255 mods total even counting mods merged into your bashed patch or was it 255 mods in addition to the mods merged into the patch? 

 

 

[DylanJames]

4 minutes ago, Beermotor said:

Yes AFAIK this is still being worked on.  Quick question regarding the error message: was this generated with 255 mods total even counting mods merged into your bashed patch or was it 255 mods in addition to the mods merged into the patch? 

 

 

Great to hear. This is not counting my mods merged into my bashed patch, they weren't contributing to the plugin count. Everything seemed to be fine there.

Just attached another picture just in case you were curious. xEdit shows the plugin is flagged as an ESL, ESLs are given an active load order index number, lower right hand corner shows the number of activated plugins, and the ESL error I showed before trying to activate it.

Thanks for the response, Beermotor.

[Beermotor]

14 minutes ago, DylanJames said:

Great to hear. This is not counting my mods merged into my bashed patch, they weren't contributing to the plugin count. Everything seemed to be fine there.

Just attached another picture just in case you were curious. xEdit shows the plugin is flagged as an ESL, ESLs are given an active load order index number, lower right hand corner shows the number of activated plugins, and the ESL error I showed before trying to activate it.

Thanks for the response, Beermotor.

Thank you. That's excellent information. I'm nowhere near 255 active plugins but then again I've merged a ton of plugins with with Mator's Merge Plugins tool. I also use AutoGhost which helps a bit.

I've actually been looking at converting a few plugins I have (specifically dummy plugins for loading texture BSAs) to ESL to save load order slots but I'm holding off until everything is sorted out.

[Nayu37]

3 hours ago, Sharlikran said:

@Nayu37 That log isn't what I expected to see. I'm not so worried about the bush.pyo 172, where is says no preferred game specified because the previous line shows it sees oblivion found in the parent directory. What concerns me is the last line. Why on earth would it say that only one instance of Wrye Bash can run? I know why is says that, it says that when you have two copies open, but then you get a prompt about that, and you close them all and then open only one. So the log is just confusing.

One thing that I waned to see in that log was the mbcs for the filesystem encoding and the code page, so that's supported. However, that error about having only one instance open has me stumped. I'm gonna have to say it's a system related interference. Try to run as admin, disable all virus, firewall, and malware as they tend to provide protection against potential threats, however the threat is usually just an unsigned EXE that has no virus in it. For TES5Edit, FO4Edit, we have programs that just won't allow the EXE to run because it's not on the virus programs list, whatever it's called, a white list or whatever.  Kaspersky is the big trouble maker for xEdit, I don't know what programs cause Wrye Bash issues. I don't know of anyone that would use Mod Organizer with Oblivion, but just in case, Wrye Bash isn't supported with MO.

One way or another you have a supported environment, just something is preventing it from running, or something is making your system confused and think you have two copies running. I just don't see how it could think you have two copies open. That could be a false error, so that's why I'm also going with a system related issue. Also it's not Windows 10, lots of people have that. When I say system related issue I mean something you have installed that restricts access to programs, not your version of windows.

Actually I know exactly why it displays that, I opened the Wrye Bash short cut while the program was already running just before (or just after, can't remember) creating the log. So I think there's nothing to worry about. I remember very well that I had a window poping up saying that only one instance can run. It's not a bug.

Doesn't look like it's related to my initial issue. Other than that, is there anything to worry about?

My modded game seems to run fine despite the weird error window after rebuilding the patch.

[Sharlikran]

38 minutes ago, Nayu37 said:

Actually I know exactly why it displays that, I opened the Wrye Bash short cut while the program was already running just before (or just after, can't remember) creating the log. So I think there's nothing to worry about. I remember very well that I had a window poping up saying that only one instance can run. It's not a bug.

Doesn't look like it's related to my initial issue. Other than that, is there anything to worry about?

My modded game seems to run fine despite the weird error window after rebuilding the patch.

Yeah you are correct, the part about there being two active has nothing to do with it. I still need to have a link to the file though because I can't answer your question looking at a screen shot I have to have the file.

[Utumno]

@Nayu37 please use the version from the second post here

@DylanJames  good catch - should be fixed in the python wip: https://github.com/wrye-bash/wrye-bash/archive/utumno-wip.zip

On 10/9/2017 at 8:56 PM, Arthmoor said:

My unsolicited interpretation here:

The code is under GPL so there's no legal issue with forking it and resuming development. That's the whole point of being GPL. Also one of the reasons the license is a lousy choice if there's any desire to restrict control in any way.

That does not extend to the naming and reuse of imagery though. GPL generally won't be sufficient to cover that so it would likely be up to Wrye if he's ok with the reuse of his monkey image. The naming is also suspect and IMO done in a way as to create confusion. I think if you had stuck to just working on Mash it wouldn't have raised anyone's hackles over it.

 

On 10/9/2017 at 9:04 PM, WrinklyNinja said:

Oh boy, drama. IANAL, but it looks like Sharlikran's got pretty clear-cut permission to use the "brand" - perhaps more than Utumno despite all his work, unless Utumno can also dig out a statement from Wrye.  So long as he abides by the terms of the license, he can also build off Utumno's work.

That said, it is a bit disingenuous not to have privately discussed this previously and to have chosen a name that's potentially confusing: the fork Utumno maintains has the most claim to being the "official" Wrye Bash, and I don't think Wrye-Bashers is sufficiently distinct not to confuse people looking for Utumno's fork (though the repositories are all marked as forks on GitHub). It looks like a hostile fork to me, and that kind of thing is generally looked down on for good reason.

I am covered by the posts above - plus @Sharlikran the straw that broke the camel's back, as I mentioned and you skipped, was that you went ahead and deleted your pull requests and branches from the main repo. Which, in open source, is a capital sin. And it is clearly a hostile action and a downright purposeful waste of my time - as I spent time reviewing, commenting and amending (see: https://github.com/wrye-bash/wrye-bash/pull/389 for just an example). Just let me remind you that you went ahead and deleted your uploaded files on nexus breaking links all over the internet and harming the reputation of the project - but deleting code you had me working on is just a little bit worse.

 

 

 

 

[RavenMind]

Thank you Utumno for 307.201710130216. I'm giving her a go now.

[DylanJames]

@Utumno

Appreciate the prompt response and fix. Not getting an error message anymore.

Been mostly running tests on SE the last few weeks so if I notice anything else I'll be sure to report.

[Sharlikran]

Spoiler

 

• Lojack taught me the basics about Wrye bash and I used that to enter all the Skyrim Records back when this was on Sourceforge. Later I did testing to enable patchers with the records I had entered. Skyrim would still be merging a mere 18 out of 120 records without what I contributed. There wouldn't be extra patchers without the testing everyone like Arthmoor and Alt3rn1ty did.
• Back in 2015 someone offered to help work on Wrye Bash but felt a Python 3 conversion might help. You considered it trolling. Could you have been refactoring code that works with Python 3 instead? We will never know what would have happened because you didn't give it a chance.
• Back on 2016 I posted a bug that was later resolved. You didn't understand what I was reporting, and unintentionally trying clarify the issue and offer test files, I upset Alt3rn1ty, and apologized.
• Yes I released Fallout 4 and Skyrim SE versions because I was able to get them working enough that people could use them. All they had to do was extract the strings until a more permanent solution was implemented. People that are very passionate about using Wrye just can't do much without it.
• When the Save games changed for Fallout 4 I came back to help with that and later for the CoSaves for the script extenders.
• The when it was mentioned that the Form Version was causing an issue and it wasn't something that I just wanted added, I wrote up some code to change the record header as a foundation for solving that.  Testing for personal use shows the code I made easily addresses the issue of adding the Form Version.  I didn't remove the import you mentioned yet but with what I have learned about importing recently, I see why that's a valid request.  The rest just needs adjusting but wasn't that bad.
• I didn't know why Wrye Bash couldn't handle duplicate signatures until recently when I learned more about python and learned the fields, or subrecords are stored in a dictionary. So MreLens isn't mergable and I have a fix for that.
• I always wanted a better solution for MelCoed and while trying to resolve that Lojack told me that sometimes integers or floats that aren't FormIDs are captured as a FormID anyway as a catch all.  I found a way to avoid that for CTDA but it needs to be applied to all the games since it's all handled the same way.
• I did my best to import Fallout 3 records into Fallout NV which eliminated over 2000 lines of code and I made installer changes for FO3/FNV.

You tell me that my coding doesn't meet your standards and that you have to take it upon yourself as usual to address issues.  You say I harm the reputation of the project. You tell me I am violating Intellectual Property and I'm not Wrye for a project that is under GNU, that he stated he didn't want to upgrade for Fallout and hopes someone will take on the project like Valda did. I ask Wrye for permission to upload a new version of Wrye Mash on his Nexus page but he declined my request. In his response, he mentions that Mash, Bash (not just Mash) and all his works are under some sort of GPL and that it's okay to continue work on them.  Even specifies I don't have to rename them but I can if I wish. For you to tell me the things you do and treat me the way you have for over two years, and still somehow feel it's justified... I don't understand.

I have released versions in the past for the following reasons: Added support for Fallout3 and Fallout NV and it needs tested, added updated records for already supported games like Oblivion, Skyrim, Skyrim SE or Fallout 4, and when I implement other fixes that are not part of the current version. Unless there is new or different code then there isn't any reason to have two versions.

I'm just responding to being publicly told I'm violating intellectual property of an open source project, abusing the name of an open source project, that I'm not part of an open source project, nor the original author Wrye who made Wrye Bash an open source project. I can't overreact to that because they are legal accusations.  As usual it's just ones personal opinion with complete disregard to me.  Everyone just treats me however they want and in the end if I respond, I'm considered to be exaggerating the situation or being inflammatory. I've shared my thoughts and I'll just discontinue sharing any more in the future.  Good luck with the project.

 

Records 'AMMO' and 'SPGD' have been updated with the release of the CC CK for Skyrim SE.

[alt3rn1ty]

@DylanJames Welcome to the forum, and so glad someone brought you back

@Utumno Will try the latest nightly build end of the second post when I get home later : Is there anything in particular needs proving / tested as fixed ?

[Arthmoor]

Guys, I think it's causing confusion by discussing the load order issue with ESL files in so many different places. Can we keep that to the thread dedicated to the issue?

[WrinklyNinja]

11 minutes ago, Arthmoor said:

Guys, I think it's causing confusion by discussing the load order issue with ESL files in so many different places. Can we keep that to the thread dedicated to the issue?

Yeah, sorry, I'll restrict myself to there in future.

[Utumno]

307.201710130216

Contains also

- work by @Daidalos for preventing crashes of Bash - it will crash alright but displaying a message - this is an eternal issue, people come with Bash won't start issues and no error message.

- work by @Beermotor on excluding the meta.ini and allowing dynlod

Thanks!

The BP crashes should be fixed - (technical: I mass renamed size variables but apparently PyCharm missed some)

What remains is

- deciding how we handle esl order - it's tougher than you might think internally because of saves

- addressing the SSE formVersion issue

 

 

[Leonardo]

1 hour ago, Utumno said:

- deciding how we handle esl order

I think that will be more or less solved by it self once we understand how the .ESL files is handle by the game.

[Nayu37]

15 hours ago, Sharlikran said:

Yeah you are correct, the part about there being two active has nothing to do with it. I still need to have a link to the file though because I can't answer your question looking at a screen shot I have to have the file.

I'm sorry I'm not sure which file you are reffering to. What is your file and where can I find it?

14 hours ago, Utumno said:

@Nayu37 please use the version from the second post here

Thanks, I will, but there are many links, which one is the right one?

[Leonardo]

13 minutes ago, Nayu37 said:

I will, but there are many links, which one is the right one?

Bleeding edge python code based on branch https://github.com/wrye-bash/wrye-bash/tree/utumno-wip (here is everything you need to know in order to use the Python version)

307 WB wip standalone (doesn't required to have Python installed)

[Sharlikran]

58 minutes ago, Nayu37 said:

I'm sorry I'm not sure which file you are reffering to. What is your file and where can I find it?

 

See if the improvements to the latest version resolve the issue.  If not then what I meant was that I would like to know which ESP or ESM file is causing the issue. To narrow down which file causes that, you can disable blocks of plugins for example 5 at a time and rebuild the Bash Patch. Once the error goes away then you know it's one of the last 5 plugins you disabled. Enable one of them, one at a time, rebuilding the Bash Patch each time you enable one, until the error happens again to narrow down which plugin causes the error.

[Nayu37]

Thank you Leonardo and Sharlikran.

So I uninstalled everything related to Oblivion and installed everything again from scratch using the Python version of Wrye Bash thanks to the links provided by Leonardo (I installed every module).

A very similar window pops ups as soon as I rebuild the Bash Patch: https://imgur.com/a/R80Kx

The only mods I installed so far are these : https://imgur.com/a/CXbOx (I'm following the guide by Bevilex: https://www.nexusmods.com/oblivion/mods/47591/?)

I doubt this issue comes from the mods themselves because, as I said earlier, I don't have this at all when I use the English version of the game. (Also, as you can see on my screenshot I translated the UOP but I also tried with the original English version and this happens too, so it doesn't come from the fact that I translated it.)

[Sharlikran]

Thanks that helps, and while I understand all you have said, your previous screen shot had Unicode characters it while the second screen shot does not. I was concerned with the Unicode characters as those should not appear in the error log. If there were Unicode values in the plugin I wanted to see them for myself because that would cause issues.  Thanks for your responses.

[Nayu37]

So can I safely ignore it or not?

The unicode characters probably disappeared since I installed wxPython 2.8.12.1 Unicode for Python 2.7.

(sorry I don't know why it's underlined)

[Sharlikran]

I was only concerned with the Unicode chars. If there is an issue with the patch routine that is something Utumno would need to address. If there was anything plugin specific I would have offered my evaluation of the plugin to help out.

[Nayu37]

I guess I'll go with it for now then! The game and the mods work as intended anyway, so I guess it's benign.

[alt3rn1ty]

3 hours ago, Utumno said:

307.201710130216

Contains also

- work by @Daidalos for preventing crashes of Bash - it will crash alright but displaying a message - this is an eternal issue, people come with Bash won't start issues and no error message.

- work by @Beermotor on excluding the meta.ini and allowing dynlod

Thanks!

The BP crashes should be fixed - (technical: I mass renamed size variables but apparently PyCharm missed some)

What remains is

- deciding how we handle esl order - it's tougher than you might think internally because of saves

- addressing the SSE formVersion issue

 

 

Well first thing I found which was damned good after seeing the previous version moaning about saves was ..

1. Skyrim Spedial Edition saves (after the CC update to SSE) are no longer popping up an error box every time Wrye Bash is started, and masters are listed fine. YESSS!

2. Something that has been a long term minor issue is resolved in this version (although it could have been solved earlier and I just keep forgetting to check) .. INI Tweaks on the INI Edits Tab - Previously the minor issue was : If you had an ini tweak that so far had not been applied (and, by default, the game did not put an entry for the tweak in the relevant ini), the INI Tweak would be greyed out among the other INI Tweaks for an INI not currently selected. For example say you have ini tweaks for Skyrim.ini, to set the grass distribution level (20, 40, 60), but you have never set it, then these tweaks would be greyed out among the Skyrimprefs.ini tweaks (which are also greyed out because you only currently have Skyrim.ini selected as the active ini to tweak) .. Then you right click and apply one of these relevant but greyed out tweaks. Previously you would have to reload Wrye Bash to see the now applied tweaks in the active (non greyed out) bunch of INI Tweaks .. The difference now is, as soon as you right click and apply a greyed out tweak, you do not have to reload Wrye Bash, it instantly becomes active, no longer greyed out, and applied, and jumps up into the active bunch of INI Tweaks correctly.

In short - Applying a greyed out tweak (which is relevant to the currently selected INI), now behaves how you would expect it to after applying it.

 

Otherwise you will be pleased to hear .. So far nothing new to bring to your attention, will keep testing over the coming days.