behippo

But there isn't any official papyrus support in F4SE at the moment, which is likely what is being requested. We'll have papyrus support enabled in F4SE soon, but it will most likely be after SKSE64 gets into beta in March. Unless one of the other team members gets around to it before then.

Sorry - I forgot to come back here and post. I did create a new thread two days ago. It has a bunch of information including a video update and a target beta release date: https://forums.nexusmods.com/index.php?/topic/5206865-wipz-skyrim-script-extender-skse64/ Also it is a pinned thread now so you shouldn't have trouble finding it.

Mid-march we should have an open beta of SKSE64 available for anyone comfortable using beta software to try. Hopefully soon after we'll have an official non-beta release. There may be some closed alpha/beta tests before hand, but those will be done with a very small hand-picked group of modders to help with regression testing and ensuring the new versions of the functions work properly with their mods.

There are only three of us currently: Ian, Brendan and I. Brendan has mostly been investigation F4SE in the very recent past, but he's did the lion's share of getting the papyrus internals back online for SKSE64. Ian did all of the initial, basic set up for the engine but has been really busy in real life.

New thread opened up, includes a video update and a beta release timeline: https://forums.nexusmods.com/index.php?/topic/5206865-wipz-skyrim-script-extender-skse64/

This is the official thread for the Skyrim Script Extender for Skyrim Special Edition (SKSE64). Previously discussion was carried on in this thread over in the general discussion area. Here is the current state of SKSE64 (28-Dec-2016): Greetings everyone. Let's start with a link to a new video I have uploaded which demonstrates SKSE64 in action. SKSE64 Update - 28 Dec 2016 Here are the big takeaways before diving into details: Excellent progress continues to be madeTentatively expect a beta in mid-March 2017 (unless I can make it earlier)Input event support is working (and demonstrated)Menu support needed for SkyUI is not done but is the next major deep but narrow diveSo now down to the details. Work is progressing well. We've been focusing on deep but narrow dives into the code to prove out all of the major systems. That will be followed by a wider path that will bring along all of the supporting papyrus classes. The hard part of the work is the major systems - it is comparatively easier to bring along a new object class and corresponding papyrus functions (Armor, Potions, Shouts etc.) I'll put together a more comprehensive list of what is up and working a bit later tonight. In general I've decoded and hooked up the papyrus functions for Weapons, Spells, ObjectReferences, Forms and the Event systems (specifically Button and Control input events, and Crosshair Ref events.) The next big task is to implement the Menu and UI Hooks and Events to see where SkyUI stands. When I get that up and running I'll post another video. Thanks for your patience and support. Staff edit (Zaldiir): Update from ianpatt:

Yes. Instead of this thread in the Skyrim SE General Discussion subforum, the official thread will live in the ModTalk subforum for Skyrim SE.

I'll be opening up that thread in ModTalk before the new year. Just a couple things to finish up first.

I will have an update and a new thread here in this forum before the new year - just need to finish up a few things first.

I should clarify. The first and foremost goal is to ship SKSE64 with full parity to SKSE. Whether that is in the initial release or soon after remains to be seen. It is certainly possible that we'll extend capabilities further. It depends on what we find and what requests we get (or what mods we want to write ourselves) It is likely that before too much of that goes on we'll head back to F4SE to get more robust scripting functionality implemented there.

From just the SKSE64 perspective there won't initially be any more functionality than available in SKSE. In fact there is a distinct possibility that the initial version of SKSE64 will have less functionality than SKSE-proper. It depends on how much time it takes for us to get things together. As for Special Edition being 64-bit and perhaps having more performance and memory headroom - that is not specifically tied to SKSE64 and I am not an expert to speak on that. I'm not going to try and estimate percentages right now. I haven't done a proper accounting of what number of addresses have been found and what number of functions have been completed. That is for a little later in the process. Right now I am just focusing on the work itself. We haven't opened up any sort of issue tracker in the past. We've used the forums and email to collect issue information. Perhaps it is time to change that? We'll see. All of the script extenders provide source so that folks can investigate the code. Unless you are experienced with reverse engineering there is not a ton that can be done to help right at the moment. Having a completely open repository for the code isn't the best plan for the script extenders, given the fairly specialized nature of the work. SO we're going to keep our repository internal and just share the output when we release each build.

On an /r/skyrimmods thread today I provided a simplified explanation of what SKSE does to help explain what my latest update meant. For everyone's edification I'll reproduce the content here. [/line]I can try to simplify some. The Creation/Gamebryo engine is built in C++ as a collection of classes which represent the game world, the things in it, and the framework needed to organize it. What SKSE does is essentially document and expose that internal game engine so that we can extend the scripting capabilities. Think of it as translating a novel. We have to figure out the table of contents, the chapter boundaries, and understand the concept of pages, paragraphs, sentences and words. But to do a good job we also need to identify the setting, the characters, what happens to them, and where in the book that happens. So in SKSE for Skyrim classic we identified and documented 897 classes in our translation. Some of those classes represent the framework in the game. The DataHandler, for example, is like a glossary or index at the end of the book, and lets us find almost any object in the game (each weapon, spell, NPC, piece of furntiture, Perk what have you.) There are also classes which represent these objects in the game - you can think of them as chapters or paragraphs depending on how important they are. In addition to translating the novel, we also found interesting tidbits of information. So we highlighted specific words and phrases so we can get back to them (3rd sentence of the 4th chapter of the book - which is found on page 54.) These are the 221 addresses in memory that we have to update. These are basically bookmarks to help us find the important or interesting objects in the game. They include things like the player character object, the object under the crosshair, where the glossary is. Finally we also decided to make it easy to access these individual pages, sentences and words. So we shoved the translation online and set up a webpage to lookup and even change the words in the book. These are the 769 functions we provide in our papyrus extensions. Some of them let you just ask for pieces of data (what is the name of this object) and others let you modify that data (change the damage of this weapon, set the name, create a new object entirely.) Note that we never had a full translation of the novel. There are some chapters or paragraphs where we only have a little idea about what is going on. But it is enough to carry on the gist of the story, and our search and modification functions are useful so we published anyway. So that is SKSE as it relates to Skyrim. Each time a new edition of the book comes out it is printed a little differently. The general structure of the novel is the same, but what is found on each page is slightly off. So our bookmark for the third sentence of the fourth chapter is no longer found on page 54, it may be on page 53 or page 55 now. This change can happen for each of our bookmarks. That is why with each new build of the game we have to re-find our bookmarks and there is a delay getting SKSE out the door. But usually nothing else has to change - just our bookmarks. So that brings us to Skyrim Special Edition and SKSE64. What happened is that BGS chose to put out a new edition of the Skyrim Novel. They choose to revise the novel with some new chapters, and they also decided to use a larger font for a lot of key words of the novel. So to get SKSE64 out the door we have to do a complete re-translation of the novel. Much of our translated framework is still useful in general, we just need to update it. In particular where we didn't have a complete translation of the novel before, we're not sure where the new font might have made things much bigger. So we have to look over those unknown areas and discern how much bigger they are and re-find all of our bookmarks. So that is what we are doing. Retranslating the new edition, documenting important changes, and re-finding our bookmarks. As we cover a new area we can build the new functionality in our web page about the book. Once enough useful information has been verified, we'll publish our page and continue working. Hopefully that gives a more understandable context for those who are not as versed in the programming details?

Not sure if this helps or not, but I wrote a unit / integration test framework for the Papyrus side. If it might help, please feel free to use it! And thank you for all your work! Thanks Chesko, I will take a look. If I remember correctly back in Oblivion days I had a special room that I had activators on that would trigger a bunch of things and dump info out to the SKSE console output. But that was so long ago at this point. Lilac looks promising.

Time for another update. I know at this point that I am unlikely to put together a video this week, with some substantial real-life deadlines. Progress is continuing at a good pace, but I am finding that to finish up pieces I am interested in I have to bring in other pieces. Everything is interconnected and sometimes you can't simply disconnect them. So where am I? Well I solved the issue with Actor.SheatheWeapon() - there was an extra virtual function in the vftable. But mainly I have been diving into the Scaleform code that we'll need to support SkyUI. Not far enough along there to test anything - but finding most of the addresses and things are compiling - at least until I try to put the hooks in place to activate things. Those require another two sets of hooks (UI and Gameplay) to be pulled in. Which is the next step. I also spent a little time getting a sense of exactly how much work there is to get a full port of SKSE over to SKSE64. For Skyrim there are 897 game classes we need to decode and verify. Some of these are small and straight-forward classes with only one or two data points. Others are gargantuan. We have 221 addresses we need to find and keep up-to-date with every new build. A large number of those addresses are RTTI values we need for casting, which is more or less completely automated. Other key addresses are for global objects (like the player, the DataHandler, the console) and functions we need to call or hook (print to console, heap allocation and free, LookupFormByID).Finally we currently provide 769 new papyrus functions that will all need to be validated. So I guess I will be writing some form of regression/unit test plugin again so that we have something to test against each build to be sure we haven't broken anything. I had one of those for OBSE back when we only had a hundred or two functions. It took forever to write and keep up to date.So I haven't taken the time yet to determine exactly how much progress we have made so far. I'll need to set up something to keep track. I know the number of papyrus functions brought over and validated is quite low. I haven't been bringing papyrus functions in until I was ready to test them or use them for a demo. More of them may work - I just don't know. In any case - we'll be working on this for some time yet. I just wanted to give folks an idea of the scope of the work. As more of the functionality comes together we'll start figuring out a release plan. Still no timeline at this point.

Not with full SKSE64 support, no. But in theory a reduced set (like the 2.2 patches folks are using) without SKSE could be done. Getting on the console may require loading onto Beth.net which the original developers would have to do. So it is unlikely to happen.

Alright - here is a smaller update than I was planning. A good deal more progress has been made. Since my last update I have done a first pass decoding of Spells, Magic Effects, References (TESObjectREFR, Actor, PlayerCharacter), ExtraData and the Inventory. I have successfully tested functions walking over the player's spells and printing out information about them. I have tested getting and setting various values on the Weapon class. I have decoded new information about Light objects (found while investigating magic effects.) Some of the corresponding papyrus functions do not work right out of the box and will need investigating. Some examples: Spell.GetMagickaCost() doesn't seem to be returning the expected value; Actor.SheatheWeapon() doesn't seem to be working. The first is likely a decoding error or scripting error on my part (or the costs really are that low). The second error calls directly into a virtual function on the Actor class which may mean the virtual table layout changed which will take more investigation. None of the Inventory code has been tested yet. So I didn't make enough progress to have a good enough set of interesting functions to do a demo video. I will work on that and hopefully will be at a point sometime next week. Brendan has been making progress on our plugin code and we may be able to show off a plugin in the video if the timing works out. No matter where things stand I'll do another update early next week.

Awesome! Thanks!

Please don't, actually. In a few days I will open an official [WIPz] SKSE64 thread which should be the main place to discuss things on the forums. The plan is to open that when my demo video is ready. Unfortunately that will still be a few days away.

I'll be opening up a new official thread in this section early next week whenI give our status update. I think this is the proper forum to have a WIPz thread. I'll post a link here, and in the Skyrim General Discussion thread you mentioned earlier. From then on that thread will be the best place to ask about SKSE64 on the Nexus forums. I also have been updating the official thread at BGS linked above, and answering questions in /r/skyrimmods/ on reddit as well.

That seems very familiar. Probably because I wrote it. :D There is more up-to-date information in this thread. Including an expected update on where we are early next week.

Okay - here is an update for you all. I posted this info on the old BGS forums yesterday as well. As of last night we have the general Papyrus script extending working. I have a test spell that collects info off of a Weapon form (damage, stagger, weight, value from Weapon.psc, Name from Form.psc, Keyword info from Keyword.psc) and displays it. The TESObjectWEAP class is fully decoded, and with the exception of the SoundDescriptor class, all of the component forms that are used by weapons are also decoded. I expect most of the Weapon.psc functions to just work at this point, but I haven't verified them. The weapon itself is found by looking it up internally by ID, and the dynamic casting code to get it to the correct form is also being used. These are important, foundational pieces of SKSE64. Additionally, many classes leverage the form components used by Weapons, so they will be decoded faster. This early work is like an accelerator for later work. That being said, there is a ton of work left. We have many, many classes left to decode and verify. As each one is done I'll bring over the corresponding papyrus functions. We haven't looked at Inventory code yet (always tricky.) We haven't looked at Magic and Active Effects (big). We haven't looked at Input code (changed for x64). We haven't looked at Events. We haven't looked at Scaleform yet for SkyUI/MCM. The long Thanksgiving weekend is approaching in the US, and I will be spending a lot of time deep in the porting process. I'll have some form of semi-official statement on where things stand (with perhaps a demo video) early next week (Monday or Tuesday I expect.)

Once we get the appropriate hooks done in SKSE64 we'll make sure that SkyUI and MCM get completed. We are in regular contact with the SkyUI developers. Between the two teams we'll get it done.

Previous builds of SkyrimSE for PC were built with a setting that lets developers make changes while running the game, and continue from the same spot with that code change. This is known as Edit and Continue. It works by creating a large jump table at the top of the executable and routing all function calls through it. Then you can change a function and only have to update the one jump table entry rather than rebuild everything. Usually this setting would be removed before the game is released to customers. But Skyrim, Fallout 4 and SkyrimSE were shipped for PC with the setting still on. Each time the script extender team has informed them of the setting and they have released an update without it. This time they released they update quite quickly. The jump tables slow down the game some and make the script extender work harder to do. With the new build there is a possibility of better performance in cpu-heavy areas of the game. And our work will be easier - meaning SKSE64 may be out a little sooner than if the fix was not released.

The 1.2.39 build of SkyrimSE has the optimization fix that SKSE was looking for. We hadn't waited to start development, but it will be easier with a cleaner executable. There may also be a performance improvement in CPU-heavy areas of the game. It is a win-win for everyone.

My understanding is that HDT was a SKSE plugin, and not part of the core functionality of SKSE. (A quick lookup showed that as I was unfamiliar with the functionality.) Right now I am focused on the base functionality of SKSE64 - in particular on the hooks needed for SkyUI (by far and away the most popular SKSE-based mod.) Havok changes may also be difficult to implement in the SKSE64 core, as Ian works for a game company and likely has access to the Havok code. I know in the past he has said he cannot participate in any Havok-related porting. That is not to say that SKSE64 couldn't have that functionality - just that Ian can't work on it. Here are the unknowns in my mind: Who owns the HDT plugin, and are they planning on porting it? Is the plugin truly open source so that others can work on it and/or integrate/replicate the functionality Has the Havok code perhaps changed with the update? Could the functionality be added to the SKSE64 core?Getting answers to these questions, with the additional caveat that there isn't a SKSE64 for plugins to use, will give us an idea about when we might see this functionality. I will admit that having capes with havok physics would probably be pretty cool.