Getting Started with SKSE Plugin Development

The Skyrim Script Extender (SKSE) is a tool that expands scriptings capabilities and adds additional functionality to the game, as well as allowing modders to create plugins to further extend Skyrim's scripting capacities. SKSE plugins take form as DLLs files that implement new functions into Papyrus, Creation Kit's scripting language. As you may guess, making an SKSE plugin is more difficult than a standard mod but the benefits of doing one are far greater. This guide focus on implementing new functions into Papyrus Scripting and debugging them.

This page is actually in progress and doesn't provide a complete tutorial on how to make an SKSE plugin project. With any progression on our side will come further upgrade. Until then, be assured that everything that has already been laid out is correct and up-to-date.

Sources

These are related sources that have inspired this guide. Please note that the instructions may differ from one source to another and that some might simply be completely wrong/outdated.

• Zartar's "noob tutorial" on Bethesda's old forum. The whole discussion may contain other helpful information too.
• Ryan-rsm-McKenzie's Tutorial on GitHub. However, his tutorial doesn't include a solution for the C2039 errors when compiling with modern SDK.
• This Reddit discussion
• Xanderdunn's GitHub, which includes material related to Skyrim32.

Credit goes to Bethesda, the SKSE Team, Ryan and every contributor of this page.

Requirements

• Skyrim Special Edition
• SKSE for Skyrim SE (Also referred as SKSE64), which you should already have installed.
• SKSE64 source code which is included in the SKSE64 distribution (In the src/ folder)
• A template SKSE Plugin. Ryan's Tutorial provide one.
• Visual Studio 2019, but you can use an earlier version if you wish.
• And most importantly, you need to know C/C++ programming and have a good understanding of memory management.

To eliminate any potential trouble, be sure to have Windows, SKSE and Skyrim Special Edition up-to-date. Please keep in mind that this guide does not guarantee backward/forward compatibility.

C++ Toolset compatibility

As you will notice in the following section, SKSE uses an earlier version of the 'Visual C++ platform toolset', the 2015 version. According to the SKSE team, using this version is safer because it's the same Bethesda used to build SSE, and compatibility cannot be ensured for every version. In other words, you can build SKSE with a later version of the toolset but the outcome might not work once loaded into SSE.

While testing for such incompatibility, SKSE 2.0.15 re-targeted and built with VS2019 (and it's toolkits) successfully ran on the corresponding SSE runtime, 1.5.73. That alone doesn't fully guarantee cross-version-compatibility and builds made with newer SDK might break as SKSE implements new features. Also, remember that running DOES NOT equal stable and retargeted SKSE builds can bear unseen and niche compatibility problems.

This guide will try to use the latest version of all the mentioned programs. If you don't feel comfortable using the latest versions or want to use a different one, don't worry; each step can be performed in any version of Visual Studio.

Without further ado, let's set up the environment.

Setups

Before making a plugin, you need to set up the environment.

Retargeting and building SKSE

To make a plugin we'll first need SKSE's source code. However, SKSE was made with an earlier version of Visual Studio and still use outdated toolsets that aren't available within VS2019. Therefore additional setups must be performed.

1. Within the SKSE zip files obtained from the official website locate and extract the src/ directory.
2. Open the SKSE64 solution src/skse64/skse64.sln with Visual Studio 2019. VS2019 should already be associated with the .sln file type.
3. Upon loading, you'll be prompted with the option to "Permanently remove source control association bindings". The SKSE team uses what is called "Source control", which is a way to share, update and checkout codes coming from multiple users. We won't (and can't) use their source control so we can permanently remove any source control association. (image)
4. Just after that, a new window will appear and suggest to Retarget the Projects. The default options should be good enough and you can press "Ok". (image)

   Why is that?

   The SKSE project is made with an earlier version of the Visual C++ platform toolset. It's good development practice to keep your project's component up-to-date and, hopefully, Visual Studio can take care of that itself. However, some more configuration will be needed to successfully build the solution.

5. Open the Property Pages for all projects.

   We're gonna tweak some options within the Configuration Properties.

   You can do so by selecting all projects within the solution explorer (Tip: select the first element and then the last one while holding SHIFT ) and press ALT+ENTER to open the Property Pages.

   Also make sure that the Configuration field is set to All Configuration, as we want them to apply for Debbuging as well as releasing.

   1. Disable post-build events

      The project files include post-build events that we don't want (Such as automatically moving files into Skyrim's directory).

      To disable post-build events, navigate to Build Events => Post-Build Event and change the Use in build field to No.

   2. Set the C++ Language Standard

      Navigate to C/C++ => Language and set C++ Language Standard to ISO C++17 Standard (/std:c++17).

   3. Force-include <string>

      At this point, any attempt to build the solution will fail and there will be many errors (image), with the most predominant one being C2039: 'string' is not a member of 'std'. In other words, many files are using the 'string' class without including the required header to do so.

      You can fix this without manually adding #include directives by instead navigating to C/C++ => Advanced and adding "string" (without quotation) in the Force Include File field. This will automatically include the string header whenever it's required.

   4. Click "Apply" and then "Ok". (Image)

SKSE should be ready to build. To test that, build the solution with the Release configuration. If no error occurs, congratulation! We can move on to the next section.

Testing the build

This section is optional and aims to further validate our home-built SKSE by testing it. Assuming you already have SKSE installed, go ahead and replace the original files from the Skyrim SE directory with the new ones located in src/skse64/x64/Release. The files to replace are:

• skse_(version).dll,
• skse_loader.exe and
• skse64_steam_loader.dll.

After replacing them, try to run skse_loader.exe. Skyrim should launch without any issues.

Note: Hypothetically, an SKSE built with updated configurations may give better performance than the default one provided by the SKSE team, but as explained in the "C++ Toolset compatibility" section, the opposite may also be true.

Making a plugin

Be aware: SKSE Plugin cannot override or extends already existing script. In other words, consider an "ObjectReference" object and a "newMethod(<parameters>)" function you want to implement as an interaction of ObjectReference. You won't be able to implement ObjectReference.newMethod(<parameters>). Instead, you can create a new "NewWrapperScript" object and implement NewWrapperScript.newMethod(ObjectReference, <parameters>).

At this point, we should start making the actual plugin. You can follow Ryan's Tutorial while this page is being written.