Getting Started with SKSE Plugin Development

Legacy Article

SKSE supports loading mod dll plugins to extend its abilities. Making a DLL plugin mod is more complicated than a standard skyrim mod with the creation kit and papyrus however it allows much greater control of the game. Since 1.07.0 SKSE has had support for adding papyrus functions in a DLL which is what this page will focus on. It does not support dynamically adding additional functions to existing scripts so you need to make a new script type as a wrapper for the new functions and then call them through that. So instead of SomeObjectReference.newFunction(param1, param2) you do NewWrapperScript.newFunction(SomeObjectReference, param1, param2).

This is a quick placeholder to get things started, hopefully others will help format it and fill it out. Zartar wrote up a good guide in one of the SKSE threads that should be a base. http://forums.bethsoft.com/topic/1496168-wipz-skyrim-script-extender-skse/page-4#entry23595441 which should go here. There is more discussion before and after that post that would probably be helpful too.

A few other things that I think were talked about in a different version of the thread: SKSE only builds as is in vs2008 (the same version as skyrim was built in which helps compatibility) but plugins should be buildable in newer. Or at the least you can write in 2013+ and switch to compile them. I think you also need to modify the SKSE solution properties to suit your system for it to work but its been a long time. The function flag kFunctionFlag_NoWait in the example means the function is threadsafe so you probably don't want it. When built in debug mode SKSE has hooks to attach a debugger but it happens before the dll mods are loaded so you won't be able to break in your code that way. It is possible to attach the debugger and use breakpoints in your plugin's code but the only way I know of I don't think is appropriate to discuss as its grey area towards piracy stuff. For debugging I suggest you throw print statements in your plugin and then look at the log.

Update 10.05.2019

The CK Wiki is lacking of instructions on proper SKSE .dll plugin creation. Since I can't figure how to make a new article on this Wiki, I'm just trying my luck to edit this page. This Tutorial is based on a Reddit discussion over here. The first section will cover proper setup of the Visual Studio enviroment, and the corresponding toolset, as well as a FAQ. A big shoutout to user Ryan/SniffleMan/Fuggyduff. As far as I'm aware he's a long time member of the Nexus(not as long as me though...:D), and other Modding communitys, and seems to be specialized on the creation of SKSE .dll plugins, as well as modding neat gameplay functions for Skyrim. He created/updated famous mods such as Skysouls, and Quick Loot. So whenever you read this Fuggyduff, and you need help in updating your .dll plugins due to new Bethesda CCC updates, just poke me over on the Nexus or Reddit.

As such, all of the content of downloaded files, this Wiki page, and any information resources, will need to have credits dirrected towards Diens, Ryan/Fuggyduff, the SKSE-Team, and Bethesda. I'm merely creating a wall of text for you guys, so the hassle of setting up Visual Studio for proper SKSE .dll plugin creation, will once and for all be gone, and a proper info resource condensed on one website! Also, before I forget, my deepest respect to Xanderdunn, the original real deal, and initial source/tutorial provider. His page still gets frequented with new updates, and sometimes answering error reports. So let's begin:

Preamble

The following instructions assume you are modding on the most up to date versions of operating system, toolsets, and Skyrim Special Edition. The instructions may, or may not be backward/forward compatible. For the sake of sanity I'll only focus on present compatibility, since the chances for big new updates on SSE, W10, and VS may not be relevant to future .dll development.

Requirements:

Windows 10, Skyrim Special Edition, Visual Studio 2019, SKSE64 Source, Ryan's Plugin Example Source
If you had previously installed a Visual Studio SDK, make sure to deinstall first, then use the Visual Studio Uninstaller Tool to remove any traces left. Additionally you can manually browse your hard drive folders, to scan for any dead remnants of older VS versions, and delete them. You may also scan the registration for any remnants, and have them deleted

Installing Visual Studio 2019

Once you've downloaded the Visual Studio 2019 Installer, make sure you are perfectly aware where to install it. I'd recommend installing it on your system drive(C:), where you have Windows 10 installed, but you can also install it on any other drive. Just be aware this is going to make the installation process a bit more complicated
Also, while you'll usually get adviced to install Skyrim, and with it any corresponding Tools/Mods/Whatever, explicitly not inside C:\...Programs(x86), or similar, this is not the case for Visual Studio. Correct me in the page's discussion if that statement is wrong
Also, be aware, depending on your install, Visual Studio 2019 may need disk space ranging from anything of 600MB to 25GB, depending on the components you want to install. Installing on a SSD, or any faster equivalent, is recommended
Refer to this image, for an example on how I forwarded the install procedure
Very important!: If you are not on a native English OS, make sure to additionally select and install the English language pack for VS2019. If you're ok with a localized VS2019 only, happily ignore this advice, but be aware you always have to cross language barriers this way
Important as well. Make sure to install/run VS2019 as administrator

Setting up SKSE64 Source

Most, if not all the instructions on this article, is based on the users's Ryan instructions, which I advice to keep as secondary resource opened in a browser tab, so you have something to backup for, whenever I'm starting to talk nonsense, due to lack of better information

Download SKSE64 Source, and unpack the .zip to a folder of your choice. Make sure to backup/seperate, if you also utilize SKSE64 for your game
Open up the file src\skse64\skse64.sln, by double clicking, then permanently removing source control
You may now upgrade the SDK/toolset. I encourage you to do so, because this tutorial is based on upgraded toolset files. According to Ryan you do not necessarily need to do this
Ensure you're building in Debug mode
Direct quote of Ryan: "Disable SKSE's post-build events by selecting all projects, right click -> Properties -> Configuration Properties -> Build Events -> Post-Build Event -> Use In Build -> No. SKSE's build events are configured for their environment, however ours is different, so we won't be using them"...you can select all by using CTRL+left click
Make sure these changes apply to all configurations
So far so good. From here the original instructions of Ryans tutorial differed for me. That may not be the case for you. I encountered a problem, when trying to build the SKSE64 .dll, that resultet in 3275 error messages. A trace to why this is happening can be found here. Basically this happens, because the latest SKSE source did not include a particular string library, which you will have to add manually, when trying to update the SKSE64 to VS2019. So this means from here I assume you will stay with VS2017. Don't be worried, since the following instructions will apply to both VS versions
Again, multi select all projects with CTRL+ left click, then right click->Properties->Configuration Properties->C/C++->Language and make sure to select the correct C++ ISO standard(v17)
After confirmation open properties again for all projects, and make sure to->Configuration Properties->General->Platform Toolset->set to Visual Studio 2017(v141)...set to Visual Studio 2019(v142), if you've already gone ahead, upgraded to VS2019, and fixed the previously mentioned SKSE64 string problem
Now the essential and tricky part, that took me ages to figure, on how to resolve my compiling problems. This information depends on if you either have VS2017, or VS2019 installed. If you're on VS2019, you may or may not ignore this. I'm not 100% sure yet, but will update once I did the full upgrade to VS2019 myself. In the Configuration Properties->General section make sure to not use the latest Windows SDK Verion, which is clearly labeled with "latest/updated" or something like that. You want to use the SDK with version ID: 10.0.18362.0. Again, this might not be true when using VS2019. But I'm sure it complies as well. If you deliberately want to use the most up to date SDK, there's traces either on any of the Nexus pages, or Github pages for SKSE64 .dll content creators, that have gone through upgrading SKSE64 for VS2019. You might want to contact Aers, or Ryan in order to get closer information on this, and maybe even obtain a SKSE64 source for VS2019? I'm also uncertain if the SKSE team did already update the latest SKSE64 source to use the latest SDK update, or plan to do so for the next SKSE64 update. As it stands now, due to my findings, it's entirely possible SKSE team did not even upgrade to VS2017 yet, and are still using VS2015. This is verified by the fact, VS2019 wants you to upgrade, once you double click the SKSE64 solution. If you don't upgrade, you will figure SKSE64's VS2015 fallback via name labeling. This is also a reason why I urge you to upgrade, since VS2015 does not utilize the W10.0 SDK, but 8.1 SDK, which you do not even have access to inside the VS2019 installer. You would need to make a complete new install of the actual Visual Studio 2015 to work with SKSE64 in its original form

FAQ

Why should I use VS2019/2017, if SKSE64 is build in VS2015?

Because, according to Ryan, the intern versioning does not really matter. What matters, is the amount of bugs you'll have to fix when upgrading to any new VS version, if you haven't previously updated. Also, any new VS version will be more powerful and user friendly to utilize. So it's basically just a question of convenience, to improve workflow. Also, I don't even know if my statement about SKSE64 being build on VS2015 is true. It's just what I assume, since that's what the files tell me. If you know it better, let me know, so I stand corrected.

You're constantly hopping in between the different VS versions, in your instructions. You are confusing me!?

Guess what. That's because the whole setup of VS was nothing but a giant and thoroughly confusing pita on my end. I mean, I had previous experiences with setting up Eclipse for Java coding. But getting the SKSE64 source to run and compile with VS2019 made me tear out my hair. However, for you the following things are important:

Visual Studio 2019
- Windows SDK 10.0(most up to date)
  - Platform Toolset Visual Studio 2019(v142)
    - C/C++ ISO standard v17

Visual Studio 2017
- Windows SDK 10.0(10.0.18362.0)
  - Platform Toolset Visual Studio 2017(v141)
    - C/C++ ISO standard v17/v14

Visual Studio 2015
- Windows SDK 8.1(???)
  - Platform Toolset Visual Studio 2015(v140)
    - C/C++ ISO standard v14/v10

Why do you keep mentioning different versions of Visual Studio? I do have VS2019 installed, right?

That's correct. But you can freely switch between VS2017/VS2019 in the latest VS2019 install. You can also switch even further back to VS2015, but you will need to figure a way to get access to the Windows 8.1 SDK for this. And as far as I'm aware, the only direct access is either by installing Visual Studio 2015, or Windows 8.1. None of those cases are true for the instructions provided in this article.

What's with the initial article made by Dienes, and why don't you make your own article?

The original info is outdated, but links back to the very beginnings in 2012. So you might still want to follow the provided link to learn something additional. The reason why I did not make my own article, is because I'm either to stupid to figure out how to actually make an article on this Wiki, or I'm disallowed to do so, since I haven't figured for the heck of me where there is a "create article" button. It simply doesn't show up on any of this Wiki's pages.

Is there even more walled of text information on this?

Oh yeah, there actually is, with even more detail...:)

I still get various error reports, even after successful compiling the SKSE64 source!!!

Refer to Ryan's instructions to solve or ignore. Let me know if you've found a better way than just ignoring.

Can I find any trace inside source files, on which version was used to compile?

Nope, haven't found any. However, Github actually provides this information inside the .gitignore file, and most of the sources are actually provided on Github, so for you that means = win! However, there's usually info provided inside the .vcxproj files, which toolset has been used, which in return might provide the info which version of Visual Studio was used.

Why do Bananas grow curved?

Because they start upside down, and want to bend their heads towards sunlight...;)

Addendum

So, that's about it. For now. Section two will cover on working with a plugin example based on the install posted upside. Until I'm going to update this article, you should use Ryan's tutorial over on Github as resource. It's probably best practice anyways, since he's not as much a chatterbox, than I am. However, I do believe there's something relevant in any single snippet of information, be it still so trivial. A lot of detail informations often get shoved under the carpet, or are not made available at all. However, I figured Ryan might be an exception to this rule, as he really does deliver quality, as well as quantity information in regard to SKSE .dll creation. And yes, it is also planned to add a full fledged scripting tutorial in section 3, as well as a self-condensed instruction on updating .dll plugins, or even going as far as to reverse engineer .dll plugins, that do no longer get any support from the original creators, so that other coders might take up the glove.