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 following instructions are 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. 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 trying to condense information in one place. Also, pay attention to legacy information in regard to SKSE plugin creationXanderdunn. This page still gets frequented with new updates, and sometimes answering error reports.
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
- Optional: If you had previously installed a Visual Studio SDK, you can deinstall it with using the Visual Studio Uninstaller Tool. 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. It has come to my attention, that there might be problems with remnants of older VS SDK's
Installing Visual Studio 2019
Official Microsoft Install Instructions
- Installing on system drive C: is personal preference, and primarly done for convenience during install procedure
- Depending on your choice of install range, 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 personal preference
- If you are not on a native English OS, make sure to additionally select and install the English language pack for VS2019, if you want to stay consistent with general coding language
- 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
- 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
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, after upgrading 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.
- 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)
- Optional: 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 trouble fixing part: this information depends on if you either have VS2017, or VS2019 installed. In the Configuration Properties->General section make sure to not use the latest Windows SDK Verion, which is clearly labeled with "latest/updated". You want to use the SDK with version ID: 10.0.18362.0 for VS2017. This might not be true when using VS2019.
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 were using VS2015 for the latest SKSE64 update.
FAQ
Why should I use VS2019/2017?
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. On the topic of SKSE64 potentially created with VS2015: 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. 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
- Platform Toolset Visual Studio 2019(v142)
- Windows SDK 10.0(most up to date)
- Visual Studio 2017
- Windows SDK 10.0(10.0.18362.0)
- Platform Toolset Visual Studio 2017(v141)
- C/C++ ISO standard v17
- Platform Toolset Visual Studio 2017(v141)
- Windows SDK 10.0(10.0.18362.0)
- Visual Studio 2015
- Windows SDK 8.1(???)
- Platform Toolset Visual Studio 2015(v140)
- C/C++ ISO standard v14
- Platform Toolset Visual Studio 2015(v140)
- Windows SDK 8.1(???)
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. Also, the create article button simply doesn't show up on any of the Wiki's pages, for me.
Any more relevant discussions happening?
Yes: here, here, and on the Discord
I still get various error reports, even after successful compiling the SKSE64 source!!!
Refer to Ryan's instructions to solve or ignore.
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. 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.
Addendum
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. Pay special attention to the Debugger section. Without this, you will never be successful.