Wabbajack 2.0 in the works (Patreon)

In the aftermath of the Wabbajack 1.0 launch I took some time off for a bit of a rest. Coming back to the project a week or so later, I realized there was a lot of cruft in the project I would like to fix. Issues that didn't impact the user experience, but resulted in confusing code. So I'm about two weeks into a major refactoring of the Wabbajack code. This rewrite accomplishes a few things:

Firstly, the code currently in use abuses strings quite a bit, we'll have code that looks like this: `Dictionary<string, string> Archives`. What does that mean? What is that a mapping to or from? Instead, the new code removes this overloading of strings and replaces it with strong types for Hashes, RelativePath, AbsolutePath and Game types. So now we can have `Dictionary<Hash, AbsolutePath> Archive` which makes it quite clear that this is a mapping of hashed archives to paths on disk. This ripples through the code so that at any moment it's clear exactly what's going on.

Secondly we're looking into serialization of modlists. We currently use Ceras which hasn't ended up being as easy to use of a format as we had hoped, it's hard to improve on the format without breaking older modlists. I'm currently using MessagePack as the serialization format, but I might replace this with JSON if the performance isn't too bad.

Thirdly the backend server uses a horrible mixture of SQL and MongoDB. I started with Mongo because a lot of the data we store is blobs of JSON, but as it turns out we also want some amount of ACID support, so SQL was added. As part of this rewrite I'm switching completely over to SQL.

Fourthly I'm taking the time to test the server code. I have a test harness setup in a branch where the integration tests can setup a dummy build server and then call Wabbajack routines and make sure the desired changes are made on the server. This already has uncovered a few bugs, and I'm sure we'll find more as we write tests for all the endpoints.

Sadly all these code changes are made without any regard for backwards compatability. This means existing installers can't be used with this new version of Wabbajack, and will have to be recompiled. This isn't a hard process as we recompile lists all the time, but it will cause some confusion at rollout, so I'm planning on releasing this as "Wabbajack 2.0" as it's completely incompatible with previous versions.

As far as user facing features for this major release, I'd like to look into expanding our command line tools. Right now it's a rather involved process to setup MO2, setup the MO2 download in the folder, setup metas, and the like. In addition there's a lot of mods that are installed the same way, so I'm considering adding a sort of `apt-get` feature to the Wabbajack CLI. Imagine if creating a new list was as simple as going to a console and typing:

```
wj new MyList
wj add skse engine-fixes SRO Noble
```

This feature I'm planning on calling "recipes" . They're not modlists, and they're more than a single file being installed (SRO contains 4 files that have to be downloaded and extracted). But the're somewhere in the middle, a set of downloads and configuration changes to apply to a single MO2 mod. It's a fool's errand to try to make this system install whole sets of mods, but it's simple enough to enable it as a way to give names to single sets of mods.

I imagine users will want to submit their own recipes, so how we manage the moderation of these submissions is still something I'm thinking about.

To sum up, things are still happening, we seen hundreds of new downloads every day, and we're sitting at just shy of 10,000 unique users of Wabbajack since the start of this year. So thanks again, and expect to hear more about these features in the next month as they get implemented.