This will outline how to set up a development environment to allow attaching a debugger, proper stack-traces, break points, etc in VisualStudio.

The first step of setting up your development environment is getting the proper version of Unity for the game you are debugging. You'll most likely have to get these from the Unity archive. A google of the Unity version will take you there. During your install ensure the VisualStudio tools are installed as well.

• Kingmaker: 2018.4.10f1
• Wrath of the Righteous: 2020.3.48f1
• Rogue Trader: 2022.3.44f1

The second step is getting Unity2Debug. This tool will setup your development environment quickly and easily.

After you have both the tool and Unity installed open Unity2Debug. Note: Since Unity2Debug uses Symlinking it will require Admin access.

1. Select the game you wish to create dev env for. It has prepopulated assemblies that will be processed. WOTR has two options, for simple mods 'basic' will usually do, while 'full' will process all the assemblies.
2. Select a folder where the source code will be decompiled to. Anywhere outside of the game folder is suggested.
3. Ensure 'Create Debug Copy' is selected.
4. Hit 'Next' button.
5. A lot of the next screen should be prepopulated but ensure the following steps.
6. 'Retail Game Exe' is pointing at the game's exe. e.g. "C:\Program Files (x86)\Steam\steamapps\common\Pathfinder Second Adventure\Wrath.exe"
7. 'Steam App Id' has the correct app id for the game, the find button should automatically determine this if it isn't prepopulated.
8. 'Debug Output Path' is where you want you dev env of the game to be setup. This will be a whole different entity to the base game. This is convenient as debug features are unlocked at a cost of performance but will not affect if you want to play the game. You will basically have two copies of the game (with symlinks very little additional disk space is used.)
9. 'Unity Version' should be auto populated. An error will be shown if the proper Unity Version isn't found.
10. 'Symlinks' will be prepopulated with everything that is needed to work and keep your dev env a small as possible.
11. 'Exclude Filters' will exclude any files/folders from being copied from base game. It is ok if this is empty.
12. Hit 'Next' button and let it process.

After it is finished everything should be ready to go to begin debugging.

Debugging Mod Code

UnityModManager mods can be debugged from inside VisualStudio.

• Go to project properties, build, general, and ensure Debug symbols are set to PDB file, portable!
• Debugger only works on the first load of the mod. If you use UMM's hot reload debugging will be lost and game must be restarted!

1. Debugging is as simple as building your mod.
2. Set a break point where you want execution to stop.
3. Launch you dev env version of the game (location from step 8 in previous section).
4. A pop-up will show asking if you want to attach a debugger. If VS go to menu 'Debug' -> 'Attach to Unity Debugger' -> and select 'Debug' in the pop-up.
5. Hit Ok from the game's pop-up and the game will launch. Depending on where your break point was set execution will stop when it is hit!

Debugging OwlCat Code

It is much the same as above. If you are strictly stepping through Owlcat code then you can open the .sln file where ever you outputted the source code to in step 2 in the previous section. If you are debugging both your code and Owlcat code at the same time it is suggested that you open the individual .cs files inside you mod's instance of VS. Only 1 instance of the debugger can be attached at one time. You should be able to step into Owlcat code from your mod code if you need to.

If you prefer you can also use dnSpy to connect to Unity Debugger in much the same way. 'Debug' -> 'Attach to Process (Unity)' -> Game's name (should only be one)

Stack Traces

Another huge advantage is stack traces. Most of the time there is an exception thrown the log will contain the stack track. With the dev env it will output specific line numbers and files where these errors originated from. The is true for both Owlcat code and your own. This should narrow down where to set your break points to find that pesky NullReferenceException.