More doc work

docs/Blacklisting.md

@@ -0,0 +1,17 @@
+# Blacklisting Mods
+
+## By Group
+Synthesis Groups can blacklist mods.  To do so, click on the Group of interest, and a UI should show that lets you pick the mods to not include during patching of that group.
+
+![](https://i.imgur.com/iyf4rPO.png)
+
+## By Patcher
+### Patcher Settings
+Individual patcher developers can decide to offer patcher settings that expose a mod blacklist as they see fit.
+
+If a patcher does not offer the setting, it is something they can decide to add.  Perhaps add a request on the patcher's Github page.
+
+### Synthesis Provided Per-Patcher Blacklist
+Synthesis itself does not provide functionality to blacklist a mod for a specific patcher.  There's an [issue for it in the works](https://github.com/Mutagen-Modding/Synthesis/issues/285).
+
+In the meantime, if a patcher does not offer a mod blacklist within its own settings, your best option is to put the patcher by itself in a Group and use the blacklist it offers, as described above.

docs/DataFolder.md

@@ -0,0 +1,9 @@
+# Data Folder
+
+Synthesis by default looks at the typical game registry areas to automatically locate the installation folder for the targeted game.   However, if you have multiple installations, you may want to override and have Synthesis target a different location. 
+
+This can be done by editing the profile settings:
+
+![Screenshot 2022-08-24 213522](https://user-images.githubusercontent.com/24981326/186561179-5fd169f6-dcd9-4171-8c22-ad266179a07c.png)
+
+It should then look to the new location when reading/writing mods.   You can leave it blank to go back to automatic location logic.

docs/Language-Settings.md

@@ -0,0 +1,29 @@
+# Language Settings
+Synthesis comes with a few profile settings to help users that are targeting a language besides English.  The typical settings you should pick depend on your situation and the patterns that your language translation mods have used.
+
+## Overview
+### Localize
+This setting controls whether to use `.STRINGS` file system when exporting your synthesis patches.  This will allow for a synthesis patch to export with multiple languages at once and with their associated preferred encoding, as each language is stored in their own files.
+
+### Language Dropdown
+This determines what language a mod which is not localized (does not have .strings files) should be considered to have.  This is important for different reasons depending on if you have the above Localized setting turned on:
+- If you have the above Localization setting turned on, when patchers have records from mods that were originally not localized, their string will be placed into the language strings file specified in this dropdown.
+- If you have the above Localization setting turned off, then when patchers have records from mods that were originally localized, it will take the language data from the strings file associated with the language from this dropdown and put that into the outgoing non-localized patch files.
+
+### Use UTF8 for Embedded Strings
+By default, if Localization is turned off for a mod and .strings files are not used, the embedded strings are encoded with a non-UTF8 encoding.  But, some language modding setups have mods with non-localized strings that are stored as UTF8 (often Japanese, Chinese, etc).  This setting controls whether Synthesis should use UTF8 when reading embedded strings or not.   For default English users, this is usually good to keep off.
+
+## Typical Recommended Settings
+### For English Users
+Default settings is good:
+
+- `Localization` -> Off
+- `Language Dropdown` -> English
+- `Use UTF8 for Embedded Strings` -> Off
+
+### For Non-English Users
+A current best practice is not yet ironed out (please feel free to swing by the discord and offer your experience and suggestions!). 
+
+The desired settings depend on the ecosystem your language community has adopted.  For example, Japanese/Chinese translation mods have seemingly opted to not use `.strings` files, and instead embed their strings into non-localized files that store with the UTF8 encoding.  Thus, for those setups, you would want to turn off `Localization`, and turn on `Use UTF8`.  
+
+But that might not be consistent with other language ecosystems or your specific setup.  The best recommendation is to read the available settings and try to navigate what combination will work for your setup.  If you find what works for you, please give some feedback so that this documentation can be better filled out!

docs/LoadOrder.md

@@ -0,0 +1,73 @@
+# Load Order
+Load Order can affect the results of Synthesis patches in a few ways
+
+## Patches Only Consider Mods Earlier in the Load Order
+A patch being run will only consider the mods that come before it in the load order.  Any mods that come after it are ignored and not seen or considered by the patchers when they are running.
+
+For example:
+```
+ModA.esp
+Synthesis.esp
+ModB.esp
+```
+
+If a patch pipeline for `Synthesis.esp` was run, `ModA.esp`'s contents would be considered while `ModB.esp` would be ignored.
+
+## Patch Not On Load Order
+If Group being run is not on the load order, then it is considered to be last and will consider everything on the load order.
+
+## Building On Previous Patches
+Do patchers consider any other patcher's results when running?  
+### Within a Group
+Patchers within a group build on each other's contents.  An earlier patcher's changes will affect a later patcher's results.
+
+![](https://i.imgur.com/KMIAVeI.png)
+
+In this scenario, `Speed and Reach Fixes` will run first.  Any changes it makes will be seen and considered as `Facefixer` and `AmmoTweaks` run right after.
+
+Similarly, `FaceFixer`'s adjustments will be seen by `AmmoTweaks` which will make the final adjustments before exporting to `Synthesis.esp`
+
+Occasionally, ordering will matter, as some patcher might want to act on the content that another creates. 
+
+### Between Groups
+Group interaction works slightly differently.  Groups see previous Groups' results as if they were a normal mod on the load order.  So the initial Load Order example takes effect.
+
+For example:
+```
+ModA.esp
+Patch1.esp
+Patch2.esp
+ModB.esp
+```
+
+`Patch1`'s run will consider `ModA.esp` when running, and nothing else.
+
+`Patch2`'s run will see `ModA.esp` and also the results of `Patch1`, as it is a "mod" before it in the load order.
+
+`ModB.esp` will not be considered by either, as it is later in the load order.
+
+### Group Order Should Match Load Order
+It is important to note that generally Groups should be run in the same order they appear on the load order. 
+
+!!! bug "Mismatched Order Leads to Bugs"
+    Running patcher groups in a different order than they appear on the load order can result in inconsistent output
+
+For example, if the Synthesis groups are listed:
+```
+GroupA
+GroupB
+```
+But are listed in your load order as:
+```
+GroupB.esp
+GroupA.esp
+```
+Then the following will occur:
+
+- GroupA will run first
+- GroupA will see GroupB's contents, but stale from the previous run
+- GroupB will run second, and perhaps change its contents
+
+The result is that A has now built itself on an outdated understanding of B.  This may or may not mean the results will not be as expected, and a 2nd run will suddenly "fix" the issue as now A will see B's new results.
+
+Instead, it is recommended to keep the ordering in sync, unless you plan to run the groups independently in some special custom setup.

docs/Multiple-Output-Targets.md

@@ -0,0 +1,34 @@
+# Multiple Output Targets
+By default, Synthesis comes with one large group, named Synthesis.  Putting patchers inside and running them results in all of their content being added to one single mod named `Synthesis.esp`.
+
+## Synthesis Groups
+Synthesis can also be set up to export different patcher results into different mods.  
+Synthesis groups is a feature that helps organize what patchers will go into what mod files.
+
+Each group will export its contained patchers into a mod with the name of the group.
+A group named `MyPatch` will be exported to a mod called `MyPatch.esp`
+
+### Adding a Group
+Clicking the new group button will add a fresh group to your pipeline
+
+![](https://i.imgur.com/99v7YqM.png)
+
+### Renaming a Group
+After creating a new Group, you will want to give it a name before it is usable.  This can only be done by focusing the group and renaming it in the right side panel
+![](https://i.imgur.com/cWTEkXz.gif)
+
+### Adding Patchers to Group
+With the group selected, you can then add patchers to the new group as normal.  Just make sure to click on the group you want to add the patcher to before adding the patcher.
+
+### Moving Patchers between Groups
+You can also drag drop patchers between groups, and reorder them if the patchers you're choosing care about order.
+
+## Running With Multiple Groups
+### Run Whole Pipeline
+You can run the whole pipeline by clicking the run button at the bottom left of the UI.  This will run all of your groups in order one after another.
+
+!!! bug "Keep Groups In Sync With Load Order"
+    Group order must match load order [Read More](LoadOrder.md#group-order-should-match-load-order)
+
+## Running a Single Group
+You can also run a single group in isolation, rather than generating all groups at once.  This is sometimes useful, but generally is less safe than running the whole pipeline.  

docs/Other-Dynamic-Mod-Generators.md

@@ -0,0 +1,26 @@
+# Other Dynamic Mod Generators
+When running with other programs that generate content, there are two styles:
+
+## Ones that respect load order
+If the program only considers content before it in the load order (Synthesis itself is in this category), then the only thing that matters is that the order you run the programs should match the order they appear in the load order
+
+If this is your load order:
+```
+OtherProgramThatRespectsLoadOrder.esp
+Synthesis.esp
+```
+Then run the other program first, followed by Synthesis.  If they're reversed, then you'd run them reversed.
+
+## Ones that run on the entire load order
+If the other program runs on the entire load order no matter what, then it is recommended to place Synthesis before that other program in the load order
+
+```
+Synthesis.esp
+OtherProgramThatRunsOnEntireLoadOrder.esp
+```
+
+You would then run Synthesis first, and then the other program.   Synthesis would regenerate without considering the other program's content, and then the other program would build on top.
+
+## Specific Recommendations
+### Bashed Patch
+Probably good to run before Synthesis in the load order.  It processes leveled lists and might undesirably revert changes made by Synthesis patchers depending on the contexts.

docs/Synth-File.md

@@ -1,6 +1,4 @@
-Synthesis associates `*.synth` files with itself
-
-# Installer Files
+# .synth Files are Installer Files
 `.synth` files can be made to be "installer" files for patchers.  Users can double click a `.synth` file to have a patcher added to the currently selected group in the Synth UI.
 
 ## Using a .synth File to Install a Patcher
@@ -11,5 +9,16 @@ Synthesis associates `*.synth` files with itself
 ![](https://i.imgur.com/1bQ23Zu.gif)
 
 ## Creating an Installer .synth File
-Please refer to the [Nexus Integration](https://github.com/Mutagen-Modding/Synthesis/wiki/Nexus-Integration) page for more details
+To create a .synth file, create a text file with the repository url and project location that normally shows up. Then make sure to save your file as `[patcher_name].synth`.
+
+```
+{
+  "AddGitPatcher": 
+  {
+    "Url": "https://github.com/[Project-Path]",
+    "SelectedProject": "[Directory]\\[Project].csproj"
+  }
+}
+```
 
+Users should then be able to use this shortcut that to add your patcher to Synthesis.

docs/Synthesis-vs-Mutagen.md

@@ -0,0 +1,29 @@
+# Synthesis vs Mutagen
+
+Often newcomers are first introduced to Synthesis.  They install a patcher or want to make their own.
+But what is the term Mutagen, and why is it mentioned often alongside Synthesis?
+
+Both of these terms are used in conjunction with each other often, and so they can get confusing.
+
+## Mutagen
+Mutagen is the library that allows for reading and manipulating Bethesda plugin files.  
+
+Sorts of things that Mutagen is in charge of:
+
+- Reading what an Npc's Health is
+- Making 10 new Weapons with various stats
+- Finding/reading a texture asset from a BSA
+- Resolving and finding the Race that an Npc is
+- Other jobs that require interacting with mods and analyzing/manipulating their data
+
+## Synthesis
+Synthesis is a system that is built on top of Mutagen to provide an easy patcher pipeline ecosystem.  
+
+Things that Synthesis is in charge of:
+
+- A UI for users to control what patchers they want to install, in what groups, in what order.
+- Running dozens of patcher code snippets (patchers) from many mod authors easily in one place with one click
+- Creating an easy bootstrap project template to start coding your own patcher that hooks into the system
+
+## Summary
+Synthesis is the patcher pipeline ecosystem that helps create an accessible environment for developers to create and for users to run Mutagen code snippets.   You do not need to find/install Mutagen yourself as an installation step for Synthesis, it will be pulled in automatically.

docs/Typical-Usage.md

@@ -70,7 +70,7 @@ Running the pipeline will export a file [per patcher group](Multiple-Output-Targ
     Some mod managers like Mo2 "intercept" new files.  If there are no errors in Synthesis, but you're not seeing its output in the Data folder, then your mod manager might be intercepting.
 
 ## Enable in your Load Order
-Once a patch is created, you'll want to use your favorite tool and make sure the results look good and then add the patch to your load order!
+Once a patch is created, you'll want to use your favorite tool to view the results (like xEdit) and then add the patch to your load order!
 
 ## Read The Rest of the Wiki
 This page is just a brief overview of how to get started.  Be sure to read the rest of the wiki!