Jump to content

Recommended Posts

1 hour ago, Sharlikran said:

I would like to understand how ESL files work for my own personal knowledge.

Did you see the topic by Arthmoor which everyone chipped into 

 

Share this post


Link to post
Share on other sites

That topic may need to be updated slightly at some point with information people have uncovered since then, but it should provide most of what's needed.

Share this post


Link to post
Share on other sites

With the new WB build, when I try to rebuild my CBash patch (in Oblivion), I get a message saying it's a PBash patch and my settings will revert to CBash defaults, which they then do. Let me know what you need.

Share this post


Link to post
Share on other sites

I'm going to get around to doing this properly in preparation for merging into the main codebase, but here is a new Beermotor build if anyone would like to test Beta 3 with a few of my tweaks applied. This is mainly a SSE-oriented build.

Wrye Bash - Beermotor Beta 3  Experimental Build

Features:

  • New installer tab right-click menus (all games)
  • All Skyrim LE Bash tags enabled for SSE.
  • All Skyrim LE Patchers enabled for SSE. - thanks to @warmfrost85 for the final code revision that made this possible.
  • Additional GMST tweaks added to the Bashed Patcher for Oldrim/SSE.
  • Export to CSV has been re-enabled for SSE.

Consider this an ALPHA test of some future changes and proceed at your own risk! There may be issues with the resultant Bashed Patch but that's what this test build is here to confirm.  If you do encounter an issue, please reference this build in this forum thread and do not post to the main Wrye Bash bugtracker. This is to avoid any confusion and toe-stomping. 

Installation:

Back up your existing B3 Mopy folder and replace it with the one in this zip. 

Uninstall:

Put your backed-up B3 Mopy folder back, run WB and rebuild your Bashed Patch.

Enjoy and thanks for testing.

Share this post


Link to post
Share on other sites
11 minutes ago, Beermotor said:

I'm going to get around to doing this properly in preparation for merging into the main codebase, but here is a new Beermotor build if anyone would like to test Beta 3 with a few of my tweaks applied. This is mainly a SSE-oriented build.

Wrye Bash - Beermotor Beta 3  Experimental Build

Features:

  • New installer tab right-click menus (all games)
  • All Skyrim LE Bash tags enabled for SSE.
  • All Skyrim LE Patchers enabled for SSE. - thanks to @warmfrost85 for the final code revision that made this possible.
  • Additional GMST tweaks added to the Bashed Patcher for Oldrim/SSE.
  • Export to CSV has been re-enabled for SSE.

Consider this an ALPHA test of some future changes and proceed at your own risk! There may be issues with the resultant Bashed Patch but that's what this test build is here to confirm.  If you do encounter an issue, please reference this build in this forum thread and do not post to the main Wrye Bash bugtracker. This is to avoid any confusion and toe-stomping. 

Installation:

Back up your existing B3 Mopy folder and replace it with the one in this zip. 

Uninstall:

Put your backed-up B3 Mopy folder back, run WB and rebuild your Bashed Patch.

Enjoy and thanks for testing.

Gives the same error message, back trace as previously reported for Beta 3 when starting Oblivioin.

Share this post


Link to post
Share on other sites
6 hours ago, sombrero said:

Gives the same error message, back trace as previously reported for Beta 3 when starting Oblivioin.

@sombrero - Did you see Utumno's reply to your error issue ? - You need to provide a full bashbugdump.log not just a cut down error report, and Utumno also asked for a save game to have a look at to help him determine what is going on there for you.

Repeating your issue to someone else with an experimental branch is not going to help anyone help you.

-------------------------

@Beermotor - Is that experimental based on Beta 3, or the 150-fo3-fnv-support branch which I think is the bleeding edge currently

Edit: Ah doesn't matter, just realised its python dependant not standalone.

Share this post


Link to post
Share on other sites
4 hours ago, alt3rn1ty said:

 

@Beermotor - Is that experimental based on Beta 3, or the 150-fo3-fnv-support branch which I think is the bleeding edge currently

 

Edit: Ah doesn't matter, just realised its python dependant not standalone.

It is based off of the build that's on @Utumno's dropbox and has support for the older FO games, so I'm guessing it's the 150-fo3-fnv branch. I'm about to head out to Estes Park and the mountains, but when I get back I'll check the thread again to see if I based it on the wrong version. 

Share this post


Link to post
Share on other sites

So now that Utumno has closed the FO3/NV support branch and declared it merged, which download are we using to test things on now?

Share this post


Link to post
Share on other sites
15 hours ago, Beermotor said:

It is based off of the build that's on @Utumno's dropbox and has support for the older FO games, so I'm guessing it's the 150-fo3-fnv branch. I'm about to head out to Estes Park and the mountains, but when I get back I'll check the thread again to see if I based it on the wrong version. 

[off topic] So now we know where to go for a greyscale wedding:

34335285_1339_40c8_bc61_42b0a8b48e75_3af

And a lot of places to go hiking besides! :)

Share this post


Link to post
Share on other sites

Yep everybody we are finally back to normal - use utumno-wip https://github.com/wrye-bash/wrye-bash/tree/utumno-wip. @sombrero I still need a full bugdump, but I added debug prints in utumno-wip - please use that one.

It also contains a fix (?) for cp65001

There are some bugs that remain - I would appreciate your adding them to https://github.com/wrye-bash/wrye-bash/issues/400 and the patcher ones to https://github.com/wrye-bash/wrye-bash/issues/314

 

Share this post


Link to post
Share on other sites
On 7/13/2018 at 9:08 PM, sombrero said:

Gives the same error message, back trace as previously reported for Beta 3 when starting Oblivioin.

Aside from what jonwd7 did initially, I did the save game decoding. Please provide the save game file as requested and I'll take a look at the header with 010. With the bash log (wryebash.exe -d) and the save game there should be a better way to resolve that issue.

Share this post


Link to post
Share on other sites
On 7/13/2018 at 8:55 PM, Beermotor said:

Features:

  • New installer tab right-click menus (all games)
  • All Skyrim LE Bash tags enabled for SSE.
  • All Skyrim LE Patchers enabled for SSE. - thanks to @warmfrost85 for the final code revision that made this possible.
  • Additional GMST tweaks added to the Bashed Patcher for Oldrim/SSE.
  • Export to CSV has been re-enabled for SSE.

 

I'm kind of a stickler to things like credit for work done on Wyre Bash. Do you have a fork that you and warmfrost85 used, or is this the only commit for that?  So that you and warmfrost85 get credit?

Share this post


Link to post
Share on other sites

 

16 hours ago, lmstearn said:

[off topic] So now we know where to go for a greyscale wedding:

And a lot of places to go hiking besides! :)

After yesterday's trip we're going to avoid Estes Park - since its a tourist town the traffic is terrible.

But the hiking is indeed fantastic. I live in the Province of Skyrim now. 

IMG_4170.thumb.JPG.5ad7840177fa7aa4db9ee376ade7a115.JPG

 

10 hours ago, Utumno said:

Yep everybody we are finally back to normal - use utumno-wip https://github.com/wrye-bash/wrye-bash/tree/utumno-wip. @sombrero I still need a full bugdump, but I added debug prints in utumno-wip - please use that one.

 

Roger. I'll fork utumno-wip and redo my build based on that branch, or if you'd prefer I can make a beermotor-342-experimental branch.

6 hours ago, Sharlikran said:

I'm kind of a stickler to things like credit for work done on Wyre Bash. Do you have a fork that you and warmfrost85 used, or is this the only commit for that?  So that you and warmfrost85 get credit?

Yes, that commit overlayed those changes  on top of the WIP branch as it existed in January.  This time around I basically applied those diffs to (what I thought was) the most recent build and then added the code chunks that @warmfrost85 provided.  I'm hoping I didn't miss anyone else because we've all had our fingers in the pie at different points. 

TODO: We just got back from the mountains again, so once I hear back from @Utumno I'll redo my build. 

Share this post


Link to post
Share on other sites

@Beermotor I want to have the refactoring of the installers menu - here is your branch over dev: https://github.com/wrye-bash/wrye-bash/tree/beermotorwb-tweaktest

You need to edit the advanced readme section to rearrange the items - note I just added an export Achlist menu - feel free to move that around.

So you should split the commit - keep working over dev, not over utumno-wip (except if you really need something that's in there) - dev is the stable branch that's bound not to change, so branches should be over that one

Re: the rest apart from testing I need to look into the code, IIRC this was kind of monkey patch - but let's test first patchers and tags

Thanks!

Share this post


Link to post
Share on other sites
On 7/16/2018 at 5:58 AM, Utumno said:

IIRC this was kind of monkey patch

Agreed. In the code I called it a "hack". The right way would seem to let the patcher's record definitions have optional subrecords (or fields, not sure what they're called). Optional subrecords is a change which I don't have the knowledge to implement.

My monkey patch involves just a few lines of code. Something easy to remove when a proper fix is added. Also since LE and SE are so related I think this "hack" is only relevant to Skyrim and will not spread. IMO, enabling these additional Skyrim SE Bash tags was well worth that small technical debt. In my personal repository, I've been using these additional SE Bash tags for months now without issue. Of course that doesn't mean there are no issues, just none that I've noticed.  If I didn't have these available I'd have to use Mator Smash which I assume others are using in the mean time.

As always it's your call. Personally it doesn't matter to me since I'll continue to use them privately but would prefer them incorporated into the main repository so others can benefit.

Share this post


Link to post
Share on other sites

@warmfrost85 Unfortunately the entire codebase has everything as required by default. There are routines for optional records in the record definition, but you can't just add that when it's not really optional.  When something is optional usually what people have done is modify dumpData(). What you do to the patchers is fine as long as it doesn't break Oblivion. I am very particular about the actual record definitions in records.py though.

Share this post


Link to post
Share on other sites

Note sure whether to post this here or as an issue at github. I'll start here.

WB reads the bash tags from a plugin header record expecting this format: {{BASH:tag,tag}}  WB is looking for "BASH" uppercase, a case sensitive search. The mod Another Sorting Mod has mixed case so the tags are not recognized in the header, e.g. {{Bash:Names,Stats}}. I assume there are other mods like this. Is this behavior intentional? If so, why? I noticed this when using Beermotor's branch with the additional Bash tags enabled.

It's an easy to make it case insensitive by adding 're.I' which I have done in my personal WB repository and now works as I expect.

maBashKeys = re.search(u'{{ *BASH *:([^}]+)}}',description,flags=re.U|re.I)

@UtumnoShould this have been posted as an issue in github instead? Or maybe it's not considered an issue. :cool:

Share this post


Link to post
Share on other sites

One of the things I love about WB over other mod managers is the amount of information I can get at a glance without having to go through a bunch of mouse clicks. A thought occurred to me the other day while I was popping back and forth between the installers tab and mods tab to make sure some ESPs were in the right order: would it be possible/feasible to integrate a plugin list in the same tab as the installers? Even if it isn't as fully featured as the mods tab and only allows reordering of plugins I can see it being a huge convenience when negotiating load/install order- especially in cases where you are using a lot of loose files.

Here is a quick MSPaint mock up of what I'm talking about:

 

Spoiler

2027212058_WBMockup.thumb.png.192826048f58cfbd4bad0ba12d0ece1a.png

 

I'm sure I'm not the first person to come up with this idea, so if it has already been discussed and rejected for whatever reason, I'm sorry.

If it hasn't been discussed before though, I think it would be a really neat addition.

Best regards,

Langeston

Share this post


Link to post
Share on other sites
3 hours ago, warmfrost85 said:

Is this behavior intentional?

I dont recall anything specifically, but the only thing I can think of is that it was done that way to distinguish it as the start of the Bash Tags list from anything else in the description that may include the word Bash, or just make it stand out.

It wasn't a thing for Wrye Mash Mod Details .. So must have been introduced for Oblivion, and I think it was around version 0.86 of Wrye Bash - But Bethesda did not allow their site to be searched by google bots etc so its still not searchable, and a lot of the older Wrye Bash topics will have fallen off the edge of the old forum well before the time it became locked.

I have never seen a mod plugin that did not use Caps for it before. But then the Skyrim community is not as close knit and well informed as the Oblivion community used to be on the old official bethesda forums.

Share this post


Link to post
Share on other sites
2 hours ago, Langeston said:

If it hasn't been discussed before though, I think it would be a really neat addition.

It was discussed with the old Wrye Bash team a fair few years ago. At the time Monitors / Screens were not capable of showing so much detail on a huge res screen with extremely small fonts you need a magnifying glass for, so just presenting it like that was not doable at the time. Myk002 wanted to include more info in an overhaul of the Installers Tab (which was provisionally named BAIT on the old SVN - Here's a Mockup of what it would have looked like), but decided from a good design perspective not to include more information. Even Metallicow had ideas on expanding the Comment box into something far more capable than just a comment box, it had its own Tabs just like the info boxes above it .. But eventually that idea was taken back out of the code, because it made you want to expand it more to get more of the detail, but that then crunched up all the info above it which became annoying especially on lower screen resolution.

But even given your screen capabilities and not restricted on a laptop, even your mock screen is constricting the main Installers display of all the BAIN information boxes, which are imho already too constricted without your addition of a cut down mods column. Personally I would say not a good idea, and not necessary for the Installers Tab.

Personally I still hold hopes one day someone will be able to make BAIT become a thing that takes over the Installers Tab

Share this post


Link to post
Share on other sites

I kind of figured something similar had been already brought up, but I figured I would throw it out there anyway.

1 hour ago, alt3rn1ty said:

even your mock screen is constricting the main Installers display of all the BAIN information boxes, which are imho already too constricted without your addition of a cut down mods column.

Yeah, that was just something I threw together in a couple of minutes to illustrate what I was talking about, it wasn't meant to represent a finished product. I didn't give any thoughts to actual layout and even if I did, I'm sure it could be improved upon greatly by someone much more knowledgeable about UX/UI than I. 

I just thought it would be nice to have the ability to look at load order and install order on the same screen.

Thank you for taking the time to respond.

edit: You know, I didn't even think about laptops. I've had a dual monitor setup for so long, (and my smaller monitor is still 24") that I take it for granted. In my setup, WB wastes a lot of space because it's usually maximized (or close to it) on my secondary monitor. If I only had one monitor, and a small one at that, maybe my idea wouldn't seem so rosy.

edit 2: That BAIT mock up looks pretty interesting. It looks like it adds some functionality that MO2 and Vortex have.

Share this post


Link to post
Share on other sites
2 hours ago, alt3rn1ty said:

only thing I can think of is that it was done that way to distinguish it as the start of the Bash Tags list from anything else in the description

Since a regex pattern parses the description starting with '{{', it's unlikely a valid description begins with '{{bash:' and ends with '}}'. It's possible but there's at least one SSE mod that I use routinely that has it mixed case. Of course I can just change it to uppercase myself but that fix breaks as soon as I download an updated version. That mod updates a lot, in fact it was updated just two days ago.

Maybe this is a one-off mod and shouldn't be accommodated. How is something like this decided? Either I contact the mod author and say it must be uppercase or WB becomes more forgiving. I'm in favor of being more forgiving with this issue. The downside to accepting mixed case seems very remote.

Share this post


Link to post
Share on other sites
On 7/18/2018 at 3:02 AM, Sharlikran said:

When something is optional usually what people have done is modify dumpData().

@SharlikranIt looks like dumpData() just tosses the 'optional' field. Is that the preferred way to handle 'optional' fields? I was not aware of dataDump() before this.

 

On 7/18/2018 at 3:02 AM, Sharlikran said:

I am very particular about the actual record definitions in records.py though.

Since I did touch skyrimse/records.py to fix, does that mean Beermotor's experimental branch that enables more Bash tags is not acceptable?

Share this post


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

Support us on Patreon!

×
×
  • Create New...