Jump to content

behippo

Members
  • Posts

    77
  • Joined

  • Last visited

Nexus Mods Profile

About behippo

Profile Fields

  • Website URL
    http://f4se.silverlock.org
  • Country
    United States

Recent Profile Visitors

4764 profile views

behippo's Achievements

Enthusiast

Enthusiast (6/14)

  • First Post
  • Collaborator
  • Conversation Starter
  • Week One Done
  • One Month Later

Recent Badges

0

Reputation

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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/
  6. 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:
  7. Yes. Instead of this thread in the Skyrim SE General Discussion subforum, the official thread will live in the ModTalk subforum for Skyrim SE.
  8. I'll be opening up that thread in ModTalk before the new year. Just a couple things to finish up first.
  9. 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.
  10. 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.
  11. 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.
  12. 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?
  13. 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.
  14. 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.
  15. 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.
×
×
  • Create New...