HUGE thanks for starting the work on this. It's a must have app IMO.

The game appears to be treating that one in some special manner and force loads it at the engine level. Which is why it would be HIGHLY inadvisable to touch the thing until more is known about how it works.

@Psymon
Python 3.2 is included. No need to install anything other than Bash3k-PreAlpha1.zip.

Mods tab is the only thing (partially) implemented. The rest of the tabs are simply placeholders so that the drag and drop reordering can be tested.

Current speculation is that Update.esm is hardcoded to load immediately after Skyrim.esm. It was probably done this way to minimize network traffic through Steam. Since it is hardcoded, the file is hidden by the official launcher (the reasoning being "the user can't do anything meaningful with it, so lets pretend it isn't there").

@Inverness Moon
We always welcome contributions. That said, Wrye Bash is fairly entrenched at its current svn. I'd say the odds of it being moved to a new repository are pretty low. The other team members may having differing opinions though

I don't want to discourage you, but I do want to warn you: Bash3k is a huge transition in the code base. You may want to wait until the dust settles a bit before you get started. It's up to you. Depends on whether you want to work on a relatively stable, relatively mature code base, or whether you want to get in while everything is still mercurial.

What I generally recommend for potential contributors is this:

• At first, email/PM/etc any patches to one of the team members so they can give it a glance over, and then they'll commit it for you. Most of our contributions are accepted in this manner. It works well enough for sporadic contributions.
  
• If the contributions are frequent enough (or large enough) that this becomes annoying, and the team members trust your code, you'll probably get named a team member and given full access to the svn / release page / etc.

@Lojack
I'd love the help. It may be a bit premature, but that's probably just be my pride talking. I was wanting to get all the frontend functionality in place so that ya'll wouldn't have to try and grok the gui factory.

Once the widgets finally behave themselves, basher.py should rarely need to be touched or even looked at.

What I'm working on:
I'm not happy with how some of the communication is handled between the gui and bashim. Specifically, I want to rework how data is pushed from the backend to the gui layer, and how refreshable data is pulled from the backend to the gui. There's also some issues still with binding keys. The existing interface for binding keys to arbitrary events isn't working properly for list items, so context menus can't be reliably set. I may have to switch out the ttk.Treeview widget for something a little more customizable...I don't see how I can add an image checkbox (which is why it currently uses a background color + status text instead).

Other areas that are open (just examples, plenty more to do than listed):

• Designing the other tab UIs within the new data-driven framework.
  
• Designing the new mod edit window. At a minimum it should allow the same editing as the previous mod detail pane.
  
• Designing the UI to control the profile system. Most of the profile stuff is roughed in, but there's no way to create/delete/switch/rename/reorder profiles outside of the ini files. This should probably be accessed via the toplevel menu rather than a new tab.
  
• Design/implement a UI to control the grouped app buttons. Should support creating lnks, grouping lnks, ungrouping lnks, deleting lnks, reordering groups, setting default lnk in a group, etc.
  
• Designing an extensible/reusable bashed patch window.
  
• Implementing the backend for each tab after its UI is in place. This will involve a lot of copy/pasting, but all the copied code should be reviewed as it is adapted to the new framework. Tedious.
  
• Add in string translation support. Difficulty: ensuring there are no unicode issues. Not too difficult with Python 3.2.
  
• Add in a help system. Difficulty: writing all new docs.
  
• Add in a "Tip of the Day" startup window.

In any event, please do look at the new code design and let me know what you think of it. If you want, I'll write up a quick and dirty doc going over the general organization and design decisions.

Once the Mods tab is fully fleshed out, the rest of the tabs should go a lot faster. All the major widgets will have been written, and all the communication protocols will have been decided. Fleshing out the UI of a tab or window is actually fairly straightforward now.

Gosh why would network traffic through steam matter at all when the game runs fine without steam even being active? Lost me on that one.

Well I'm here for the ride - will test features as you implement. Is this version an offshoot of another Skyrim bash program yet to appear or the main flagship?

Of course - very much looking forward to BAIN tab being active and working. I think that if BAIN (or BAIT even) is going to be the default mainstay mod installer then the sooner it is available the better.

good works

Sounds great, I'm going to follow this thread very closely

And +1 for Wrye Slash

Looks like Slash vs. Smash will have to be decided via a poll, if we get a say.

Wrye Slash is good IMO

Just have an edit added in Skyrim.ini about have the "Load Loose Files" box checked (Data Files option) when you launch the game from the Skyrim launcher.

Load Loose files I think is nothing to do with Update.esm, I believe Load Loose Files is supposed to invalidate BSA's so that replacer files (loose files like textures / meshes etc etc) actually work without needing any form of archive invalidation (BSA Redirection for example) - Currently there are posts out there by early modders suggesting it does not work though ... Time will tell if we need another archive invalidation method but it may just be a game patch away to fix it.

I disagree because I didn't have the Load Loose Files enable when I first start my game and after a while the intro just stopped, but when I enable the Load Loose Files I could continue with my game so I think it matters.

Possibly just a complicated game engine bug enabling it has sorted out for you, in our experience I havent had to enable it yet and my eldest had a good 6 hour session playing yesterday with no problems. Between three of us here, we have had five different gaming sessions with different users since we installed it.

ESM (Elder Scrolls Master) and ESP (Elder Scrolls Plugin) are not traditionally referred to as "Loose Files", whereas all the files you add as replacers filling up your data folder from mods with loads of sub-folders and files which replicate the folder/file/name structure within the BSA's - Those are loose files.

That was my first thought too, but now I don't know what's exclusive for Skyrim or not.

Lot's of nice things in the forge. Starting fresh with Python 3 hopefully fixes UTF for good and we can now install weird named files with no trouble.

Awesome work

If I remember right, Oblivion also had a Load Loose Files option in the Data Files menu. Though, we needed Archive Invalidation so it may be for something else.

I was kinda hoping a return of Wrye..

Should be called Wrye Sky...

+1

But the devs are still doing a nice job keeping the Bash up to date

Having a way to cleanup duplicates automatically would be very welcome this time arround.
Leave the complicated esp editing to TES5Edit (?) but allow Wrye Bash to clean plugins via CBash automatically.

Steam network traffic matters because the game gets updated through steam. It's a lot easier on Steam's servers to deliver a small update vs. a big update.

I plan on Bash3k becoming the main flagship for TES3/4/5/FO3/FNV, and end up replacing the current Bash program. This would allow us to keep all the games up-to-date relatively easily.

For now, Bash3k will likely focus on TES5, and later add in support for earlier games.

I agree on the BAIN tab. It's my next priority after the mods tab gets fleshed out. I have some ideas on how to avoid all the refresh delays associated with Wrye Bash's implementation of BAIN.

With Bash3k being a single program, my preference is simply "Wrye Bash for Skyrim", "Wrye Bash for Oblivion", 'Wrye Bash for Fallout 3", etc. It identifies the program and which game mode it is currently using. I don't really care though. I'll leave it up to the other devs and ya'll to sort it out. A poll might be the answer.

We all would, but I rather doubt it will happen. He was pretty burnt out on supporting Wrye Bash towards the end.

If that is indeed the route to be taken, I support the usage of one name with qualifiers appended. That way I can simply reference Wrye Bash rather than having to write Wrye *ash and then explain what that means. It also makes sense with the program being the same - Wrye *ash sounds like a family of programs which all differ slightly and users are likely to make the assumption that they don't share development. I think having users understand that everything across all supported games comes from the same place is a good thing.

It also makes documenting things a lot easier for you guys. I for one applaud the effort to move to a unified Wrye Bash rather than the messy ecosystem of code that is present ATM.

Great props to Waruddar for working so quickly!

So, +1 to "Wrye Bash for [game]", and to the adoption of Bash3k as Wrye *ash's future path.

Bash3k -is another team making this?

Bash3k, like CBash, is one of Warrudar's pet projects. Like how myk002 is working on BAIT. They're not part of the main Bash code, as they replace far too much of it and are at an early stage, but the intention (AFAIK) is that they will become the future of Bash.

Eg.

All current versions of Wrye *ash -> Bash3k.
Python Bashed Patch builder -> CBash
BAIN -> BAIT

I believe Bash3k and BAIT are just project 'codenames', not 'official' release names, to distinguish them from the main code. Cbash too perhaps, once the Python patchers have been removed and there is no longer any reason to distinguish it.

I believe that means unifying programming effort into one place. That's great planning.

On the naming part, if there was a poll I'd vote your idea. Wrye Bash is like a brand name, in honor of the creator of the tool. The rest is a direct, no nonsense, naming defining the game it is operating with.

Yacoby wanted to work on a unified code and program for all versions. He put forth the idea earlier this year.

Well this is all good news. Will be checking back daily.

Awesome news. Wrye Slash does have a certain ring to it.

And showing my ignorance here, but I've never known what BAIN actually stands for... anyone enlighten me?

BAsh INstallers.