Jump to content

Recommended Posts

  • Replies 2.2k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

307.201711041935 Stablest WB ever - includes changes by @Sharlikran for skyrim records (all the best with health issues!) and some code by @Beermotor (thanks !). Fixes the stuck progress bar. All i

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 ne

Gonna throw this one out there as a feeler for now in a future version. How feasible would it be to interface Wrye Bash with the tracking list for a user on Nexus so that it can see when mods get upda

Posted Images

@RavenMind Until any changes are made, you can also utilise the apps folder of Wrye Bash ..

 

11289-0-1501865440.png

A different way of doing it .. Navigate to where the Boss_Gui.exe is with windows explorer, right click it, and choose "Send to .." "Desktop".

Now just copy / paste this temporary desktop icon into gamename \ mopy \ apps \

Right click and rename it BOSS (this is just a personal choice thing, and not functionally required)

And delete the temporary desktop icon copy.

Link to post
Share on other sites

Thanks for the tip! I currently use this for LOOT (ironically), 7-Zip, and NP++. Though when I opened up the bash.ini I noticed there was an entry for NP++.  Eminently useful, especially considering there are User Defined Languages for TES, BAIN, and OBMM scripts by the likes of untunmo, buddah, LHammonds, and raziel23x!

BTW, I picked up your latest version of the WBPG. Great work! :clap:

Link to post
Share on other sites

Update on my testing with the August 3 build:

BCFs are confirmed to be working.

Wizards are working without any issues.

I actually finally broke down and finished a BAIN wizard for SMIM after all this time. Check out the BAIN Wizards thread to snag it. Currently it is for SSE but I'm going to try to make a LE version later for folks that don't have SSE yet.

EDIT: update - I added a Skyrim LE version so all editions are covered now. :)

Link to post
Share on other sites
7 hours ago, RavenMind said:

Hey, is anybody aware of CBash incorrectly reverting NPC faction values back to default when building a bashed patch, even with the mod moved to just prior to the bashed patch & tagged with Factions? (v307.201708021813)

One way it might happen is if there's another faction mod higher in the load order. We've seen instances where CBash accepts the first mod and then ignores subsequent ones. I think it's being looked at. Try assigning a Factions tag to the mod in question.

Link to post
Share on other sites

Thanks Supierce. I do have several tagged with Factions that are higher up in the list: UOP, USIP, DLCFrostcrag, Knights, & Knights Unofficial Patch. I don't *think* any of their faction changes were reverted, but will have to double check in xEdit. What I'm fiddling with is Oblivion Character Overhaul v2. I've moved it both to slot 01, and to the bottom, just prior to the bashed patch & CBash has the same behavior in both instances. Strangely, I don't have this problem when I build the patch with the old Python method.

Edit: Hmmm.. Took OCO out of the equation. removed the Factions tag from the UOP, so that USIP (the esp I'm seeing the problems with) was the highest in the list with a Faction tag. Rebuilt with CBash & am still getting NPC Faction rank records in USIP that are reverting back to Oblivion ESM.  Strangely, DLCFrostcrag also modifies an NPC Faction record for Calindil. It is located below other ESPs with the Factions tag, and its changes are carried over into the bashed patch. The only difference I see between DLCFrostcrag & USIP, is that Oblivion.esm has no faction record assigned to the NPC whose faction is later added in DLCFrostcrag; whereas it DOES already have a faction & level assigned for the NPCs whose levesl are changed in USIP. So maybe CBash isn't altering Faction record changes that already exist, but is only adding in those which don't.

Link to post
Share on other sites

Bleeding edge python version refuses to start

Wrye Bash starting
Using Wrye Bash Version 307.201708021813
OS info: Windows-7-6.1.7601-SP1
Python version: 2.7.12
wxPython version: 3.0.2.0 msw (classic)
input encoding: UTF8; output encoding: None; locale: ('ru_RU', 'cp1251')
filesystem encoding: mbcs 
...
Traceback (most recent call last):
  File "Wrye Bash Launcher.pyw", line 89, in <module>
    bash.main(opts)
  File "bash\bash.py", line 430, in main
    app.Init() # Link.Frame is set here !
  File "bash\basher\__init__.py", line 4015, in Init
    frame = BashFrame() # Link.Frame global set here
  File "bash\basher\__init__.py", line 3646, in __init__
    self.SetStatusBar(BashStatusBar(self))
  File "bash\balt.py", line 2943, in __init__
    self.UpdateIconSizes()
  File "bash\basher\__init__.py", line 3531, in UpdateIconSizes
    self._addButton(link)
  File "bash\balt.py", line 2958, in _addButton
    gButton = link.GetBitmapButton(self, style=wx.NO_BORDER)
  File "bash\basher\app_buttons.py", line 201, in GetBitmapButton
    image=self.images[idex].GetBitmap())
  File "bash\balt.py", line 167, in GetBitmap
    self.bitmap = wx.Bitmap(self.file.s, self._img_type)
  File "C:\Python27\lib\site-packages\wx-3.0-msw\wx\_gdi.py", line 648, in __init__
    _gdi_.Bitmap_swiginit(self,_gdi_.new_Bitmap(*args, **kwargs))
wx._core.PyAssertionError: C++ assertion "strcmp(setlocale(LC_ALL, NULL), "C") == 0" failed at ..\..\src\common\intl.cpp(1449) in wxLocale::GetInfo(): You probably called setlocale() directly instead of using wxLocale and now there is a mismatch between C/C++ and Windows locale.
Things are going to break, please only change locale by creating wxLocale objects to avoid this!

 

Link to post
Share on other sites
21 hours ago, zilav said:

Bleeding edge python version refuses to start


Wrye Bash starting
Using Wrye Bash Version 307.201708021813
OS info: Windows-7-6.1.7601-SP1
Python version: 2.7.12
wxPython version: 3.0.2.0 msw (classic)
input encoding: UTF8; output encoding: None; locale: ('ru_RU', 'cp1251')
filesystem encoding: mbcs 
...
Traceback (most recent call last):
  File "Wrye Bash Launcher.pyw", line 89, in <module>
    bash.main(opts)
  File "bash\bash.py", line 430, in main
    app.Init() # Link.Frame is set here !
  File "bash\basher\__init__.py", line 4015, in Init
    frame = BashFrame() # Link.Frame global set here
  File "bash\basher\__init__.py", line 3646, in __init__
    self.SetStatusBar(BashStatusBar(self))
  File "bash\balt.py", line 2943, in __init__
    self.UpdateIconSizes()
  File "bash\basher\__init__.py", line 3531, in UpdateIconSizes
    self._addButton(link)
  File "bash\balt.py", line 2958, in _addButton
    gButton = link.GetBitmapButton(self, style=wx.NO_BORDER)
  File "bash\basher\app_buttons.py", line 201, in GetBitmapButton
    image=self.images[idex].GetBitmap())
  File "bash\balt.py", line 167, in GetBitmap
    self.bitmap = wx.Bitmap(self.file.s, self._img_type)
  File "C:\Python27\lib\site-packages\wx-3.0-msw\wx\_gdi.py", line 648, in __init__
    _gdi_.Bitmap_swiginit(self,_gdi_.new_Bitmap(*args, **kwargs))
wx._core.PyAssertionError: C++ assertion "strcmp(setlocale(LC_ALL, NULL), "C") == 0" failed at ..\..\src\common\intl.cpp(1449) in wxLocale::GetInfo(): You probably called setlocale() directly instead of using wxLocale and now there is a mismatch between C/C++ and Windows locale.
Things are going to break, please only change locale by creating wxLocale objects to avoid this!

 

That's when wx 3.02 is used and windows has default locale - or so I thought, cause it used to work in your case - apparently it broke for you too. I haven't looked into this - as a workaround comment out the locale.setlocale calls - see for instance: https://github.com/wrye-bash/wrye-bash/commit/ab9c4a99070a2959f3b209ed16604911b4f895d6

Link to post
Share on other sites

Yeah I played around with the new GECK last night to create an .esl.  I made a few observations about them.

First I created what I call a "donor" or "parent" plugin. I made one that was just a bunch of Image Space records tweaked a bit to change the bloom levels during various times of day.  I don't think there's engine support for the .esl files yet so I can't really test them, but just in case I set them to some crazy values so I'd recognize them immediately.

Then I loaded it up in the v.1.10 GECK and converted it to an esl. That was fairly painless. If I did the above wrong, the CK GECK didn't complain about it.  Once it was done the original esp was still there and was the same size. Nothing terribly unusual. I made sure to rename the parent ESP and loaded up the game. Nothing happened as expected.  Still, I may have done it wrong. 

So I got a crazy idea to load up the .esl into FO4Edit to see if there were any version changes or other things afoot. I also loaded the donor plugin up with it.  Everything was identical. Everything. Versions, the records, everything.  So far the only difference appears to be the extension. Then again, like I said before, I could have done it all wrong.  

It is entirely possible that I did everything above incorrectly (info is still spotty on the ground) but I thought I'd report that back.  

Link to post
Share on other sites

A bit more information today. Apparently this is more or less intended for the Creation Club, so we may see something similar on the SSE side.  I found this today on the Reddit FO4 Mods sub:

 

Copypasta from Flenarn's post:

  • The reason for them being read only is most likely (this is not 100% confirmed, but our research is pointing towards it) that they're flagged as read only so the game can merge them at runtime and thus bypass the 32-bit plugin ID limit (255 plugins). This is most likely the reason for the 4,000 forms limit.

  • Now, as far as them being "read-only", this is correct as well but this is most likely for the game to be able to merge them at runtime.

  • When creating a .esl file, just save it as a .esl rather than a .esp, the only difference found in the file is an edit to the HEX, that can be swapped back to 00 from 02, then rename the extension from .esl to .esp and it will work 100% in the Creation Kit.

  • You can also choose to "compress" your file before saving as a .esl, all this does is, if you have 4,000 records it'll just make your highest formID in your plugin to 1F39. After that, you can do the same HEX procedure and flag it back to 00 rather than 02, swap the extension from .esl to .esp and the plugin will load fine in the Creation Kit.

Link to post
Share on other sites

Sounds similar to swapping the ESM / ESP flag, with the added complication that the content needs to be checked for = or less than the formid limit (per game? - I guess at this stage we need to be psychic as to what the need is, and extrapolating how it could affect current / future games)

Link to post
Share on other sites

Well of course the save won't consider them the same thing. Saves go by filenames and we've already shown that changing .esm to .esp will cause the same thing to happen so it should not have come as a surprise to anyone that .esp to .esl will have the same effect.

Link to post
Share on other sites
On 7/26/2017 at 7:08 PM, Utumno said:

- is anyone using exclusion groups ? I am tempted to bin them - will simplify some core methods, plus not a good idea. User can always define groups and manually check if more plugins than one are activated. We could add an enhancement in 308

We have had a sticky note on all Wrye Bash pages comments since you posted that .. Not one response thus far.

Link to post
Share on other sites
On 8/17/2017 at 4:32 AM, Utumno said:

Oooops that's far from trivial - is it only for fallout 4 ?

I made an ESL file from an ESP file I have for Fallout 4, Settlement Keywords Expanded.  First I compacted the ESP file FormIDs.  After converting to ESL, at least for my file, all that happened was the flag was set to 0x00000200 and other then that the file was a binary equal of the ESP with the compacted FormIDs. I won't release it because it changes things that can't be changed for that mod, but still that was my observation.

They should probably be treated as ESM files. I don't see a Steam Beta sign up, so I asked about it.

EDIT: I don't expect much info until next week on Tuesday (because of the Eclipse) about the Creation Club, but before I end up under NDA, the community manager verified that this will be for both SSE and Fallout 4.

Link to post
Share on other sites

So to put my PM hat on and make a suggestion: This new file format isn't going to be a thing for the general public for at least a month at the time of this writing.

It may be prudent to proceed with Beta 2 as-is and target this as a Beta 3 feature. I'm not concerned about feature creep as much as I am the fact that the Windows 10 Creators Update is going to effectively kill MO, so there may be an increase in WB adoption. 

Link to post
Share on other sites

It's got something to do with the virtual file system no longer working once that update goes live. People on Reddit have been up in arms about it because Microsoft has no intention of reversing whatever did it. So they got their VRAM "bug" fixed and traded it for killing MO instead. Tannin has already said he has no plans to try and work around it somehow for Vortex either.

Link to post
Share on other sites

Well that is disappointing. I don't like to use NMM, MO/MO2, and probably wouldn't have used Vortex.  However, I would never want to see them fail as there are many people who do prefer them. I would never want to see users options limited no matter what my personal preferences are.

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...