[WIPz] Skyrim Script Extender (SKSE64)

[aleksi134]

I wouldnt particularily see any problem with donations to them so they can finnish it faster of course its optional same as modders ask for donations on nexus but if people donate to them to finnish the project faster.

[VulcanTR]

I was checking this topic and new files and skse website everytime. I am doing this first time in my lifetime. 70+ mods ready to installed but still i can't started lol.

[ttabakova]

I wouldnt particularily see any problem with donations to them so they can finnish it faster of course its optional same as modders ask for donations on nexus but if people donate to them to finnish the project faster.

They don't accept donations. As far as I remember, some of them work for the gaming industry, and monetizing this project may result in a huge headache. I'm pretty sure this info is buried somewhere in this topic.

[1Singh]

I think they have forgotten about SKSE64 because of their work.

[barcharcraz]

 

The other thing I think is important to remember is they probably don't want to release a version of SKSE64 that only has a few functions decoded/added. Like people are expecting mods to just start being ported immediately and may be frustrated if that does not happen. With fallout4 they can incrementally release features and mods will start to use them over time. They ALSO probably don't want to get in a situation where some features of SKSE64 are unstable and it creates a cargo cult of thinking SKSE is unstable for years to come.

Yeah you're right. But as many of us said before, its very likely that the more time passes, the less mods will get ported by their creators.

 

 

That's not really what I meant.

 

If they release it without all functions and data structures decoded many mods won't be able to be ported. Actually why don't I explain how SKSE works very briefly.

 

SKSE's main components are skse_loader and the skse dll. The loader simply takes care of injecting the dll into the game's process and is actually really simple. All it does is create a new process with the executable of the game (which starts paused). It then finds the address of the LoadLibraryA function. Then it allocates some memory in the games address space (which it can do since it launched the process!) and manually writes a function call to LoadLibraryA("skse.dll") into that memory. Then it creates a thread (again in the games process) that starts in the memory it just allocated. Thus the thread runs and loads skse.dll and everything is good to go before the actual game thread starts up.

 

The dll hooks into the game and does a bunch of stuff, the main thing modders notice are the new papyrus functions. These are exposed by hooking the function in the engine that registers all the normal papyrus functions and simply also registering the skse functions.

 

This core functionality is probably done for skse64, after all it's only really a few functions that they need to find, and barring any really strange circumstances their hooking process will work fine for any function. The trouble is that in order to actually *implement* any new functionality SKSE needs to know the exact layout of the game's data in memory. If it gets this wrong then SKSE will end up reading and writing to random unrelated places in the game engine and anything could happen, including save corruption, erasing your disk, or causing nasal demons to erupt from your graphics card. There's a good chance that skyrim64 has added some functionality to the games internal objects, thus changing the order of any function pointers in them. Thus the SKSE team needs to run skyrim under a debugger, break on their hooked functions, and manually examine the game's objects to make sure SKSE's versions of those objects are correct. This involves creative debugging (adding breakpoints and making sure they get hit when expected) as well as actually looking at the code to make sure it more-or-less does what they expect.

 

Now SKSE has MANY more thing exposed than F4SE does, so it's A LOT of work to update everything. Also as they are updating things they may find that an object is the same between both games, in which case they may decide to add that object to F4SE. So I don't think work on F4SE is mutually exclusive with work on SKSE64, but we have to recognize that the functionality we have in SKSE today is the result of years of reverse engineering work, and unless you want a version of SKSE64 that crashes all the time and corrupts your save in extremely "interesting" ways you need to be patient.

 

Again I would love a little bounty board for verifying the layout of skyrim's objects!

[Panda492]

 

 

The other thing I think is important to remember is they probably don't want to release a version of SKSE64 that only has a few functions decoded/added. Like people are expecting mods to just start being ported immediately and may be frustrated if that does not happen. With fallout4 they can incrementally release features and mods will start to use them over time. They ALSO probably don't want to get in a situation where some features of SKSE64 are unstable and it creates a cargo cult of thinking SKSE is unstable for years to come.

Yeah you're right. But as many of us said before, its very likely that the more time passes, the less mods will get ported by their creators.

 

 

That's not really what I meant.

 

If they release it without all functions and data structures decoded many mods won't be able to be ported. Actually why don't I explain how SKSE works very briefly.

 

SKSE's main components are skse_loader and the skse dll. The loader simply takes care of injecting the dll into the game's process and is actually really simple. All it does is create a new process with the executable of the game (which starts paused). It then finds the address of the LoadLibraryA function. Then it allocates some memory in the games address space (which it can do since it launched the process!) and manually writes a function call to LoadLibraryA("skse.dll") into that memory. Then it creates a thread (again in the games process) that starts in the memory it just allocated. Thus the thread runs and loads skse.dll and everything is good to go before the actual game thread starts up.

 

The dll hooks into the game and does a bunch of stuff, the main thing modders notice are the new papyrus functions. These are exposed by hooking the function in the engine that registers all the normal papyrus functions and simply also registering the skse functions.

 

This core functionality is probably done for skse64, after all it's only really a few functions that they need to find, and barring any really strange circumstances their hooking process will work fine for any function. The trouble is that in order to actually *implement* any new functionality SKSE needs to know the exact layout of the game's data in memory. If it gets this wrong then SKSE will end up reading and writing to random unrelated places in the game engine and anything could happen, including save corruption, erasing your disk, or causing nasal demons to erupt from your graphics card. There's a good chance that skyrim64 has added some functionality to the games internal objects, thus changing the order of any function pointers in them. Thus the SKSE team needs to run skyrim under a debugger, break on their hooked functions, and manually examine the game's objects to make sure SKSE's versions of those objects are correct. This involves creative debugging (adding breakpoints and making sure they get hit when expected) as well as actually looking at the code to make sure it more-or-less does what they expect.

 

Now SKSE has MANY more thing exposed than F4SE does, so it's A LOT of work to update everything. Also as they are updating things they may find that an object is the same between both games, in which case they may decide to add that object to F4SE. So I don't think work on F4SE is mutually exclusive with work on SKSE64, but we have to recognize that the functionality we have in SKSE today is the result of years of reverse engineering work, and unless you want a version of SKSE64 that crashes all the time and corrupts your save in extremely "interesting" ways you need to be patient.

 

Again I would love a little bounty board for verifying the layout of skyrim's objects!

 

He never said, that is what he meant, what he said is, either way it sucks for us, because if more time passes less people will be play and less mods will come, your explanation is great but not really needed.

[barcharcraz]

I'll admit that I kinda just wanted to read the code and dive into their hooking mechanisms. But my point was mods won't get ported over if SKSE64 is released without all the features of the original SKSE, and also that F4SE work is not necessarily taking away from SKSE64 work

[FilthyCasual523]

 

Have any of you ever considered the possibility that tone of your words and the general attitude of posts in this thread might also deter them in someway? They are human too.

Unlikely, as bla08 posted on May 11/17 that the last time behippo was on the forum was February 8, 2017. More likely that he has lost interest.

 

 

At this point I'd wager that it's 100% guaranteed. Personally I'd advise the Silverlock team to give SKSE64 to someone who's actually active but I doubt they'd pay any attention to a guy named "Filthy Casual." So, as far as I'm concerned it's most likely dead until proven otherwise.

[Genj0]

I'll admit that I kinda just wanted to read the code and dive into their hooking mechanisms. But my point was mods won't get ported over if SKSE64 is released without all the features of the original SKSE, and also that F4SE work is not necessarily taking away from SKSE64 work

Oh, I get it better now. Thanks for the explanations =).

[jmike00]

 

 

Have any of you ever considered the possibility that tone of your words and the general attitude of posts in this thread might also deter them in someway? They are human too.

Unlikely, as bla08 posted on May 11/17 that the last time behippo was on the forum was February 8, 2017. More likely that he has lost interest.

At this point I'd wager that it's 100% guaranteed. Personally I'd advise the Silverlock team to give SKSE64 to someone who's actually active but I doubt they'd pay any attention to a guy named "Filthy Casual." So, as far as I'm concerned it's most likely dead until proven otherwise.

This was my fear once it was revealed that SKSE64 was going to be a far more daunting task than creating F4SE. Mod burnout is very real.

Edited May 17, 2017 by jmike00