behippo

There is a new beta build of SkyrimSE (1.1.51). There are minor modifications to the exe and a bunch of changes to audio files. As far as SKSE64 is concerned the biggest thing is that the beta still has the Edit and Continue jump tables which make our job a bit harder. This redirects every function through an extra indirection. This means code is not as obvious as we investigate, and hurts performance generally. It also means we have to manually update anything we find, rather than being able to use some of our tools to help do the updating. In theory you are correct. If we implement the same APIs (which is our intention) then any SKSE Papyrus users should not need to change their scripts. SkyUI will hopefully just work as well if we make the same changes to the Scaleform APIs it is expecting. But we will not know for certain until we get a little further along.

My expectation is that the Papyrus API that SKSE64 provides will be identical to SKSE. I haven't seen any need for changes yet (though it is very early.) However if a mod depends upon plugins - those plugins will still need to be updated. I would hope that plugin authors keep the same Papyrus API - but there are obviously no guarantees.

http://skse.silverlock.org/SKSE64FirstRun.jpg Progress is being made and we traditionally show an image the first time we get the game hooked and the GetXXXVersion function working properly. I reached that stage last night. There is obviously still a ton of work to do - but this proves that our basic techniques will be able to accomplish the task.

We appreciate all of your support and desire to contribute. However, the Script Extender team cannot accept donations. We work in the software and game industries and accepting payment could compromise our ability to continue working on the project. Plus when we started this whole thing (back with OBSE in 2006) it was not permissible for any modders to accept any money (via donations, patreons, gofundmes or what have you). So the spirit in which we started these projects continues - we make the script extenders to enable better mods to make a better game experience. If you want to give back to the community - go write a mod or support the mod developers directly.

Thanks for the support everyone. I have updated the website with a statement about SKSE64. We use our own private source control repository, as it is very important not to have the sources forked. We have discussed the github site mentioned earlier with the creator and it has been taken down now that we are officially working on the port ourselves. In general there aren't a lot of folks who have the skills to help out on the project. Over the last 10 years there have only been four or five of us who have been truly active (Ian (ianpatt), myself (behippo), Brendan (purple lunchbox/expired), Paul (scruggsywuggsy the ferret)). Not every programmer can really help out. Especially in the earliest stages of a port where it is more reverse engineering and understanding the game engine than writing new code. Once we have more of a base there will be need for testers and perhaps folks willing to help update the wiki with SKSE64 functions as they come online. We'll let folks know when we reach that stage.

Hey, since you probably have it disassembled already, would you mind telling us if SSE is really FO4 engine with Skyrim assets or its just 64 bit compilation of old Skyrim with some modifications like some people say? It would clear a lot of misunderstandings we see these days. The truth is that this is somewhere in between Skyrim and Fallout 4. Parts of the engine have been updated to match Fallout 4 (graphics engine, 64-bit, etc.) Basically all of their games are the same core engine which gets improved/modified with each release. But where Fallout 4 used ActionScript 3 and an updated Papyrus scripting engine, Skyrim SE uses the old UI and Papyrus engine from Skyrim (to do otherwise would require rewriting all the scripts and the UI.) In either case there is a lot of work to do for us. Even within a single game there are lots of things to update with each new build. Memory addresses and offsets change, functions can behave differently, classes can get data added or removed, classes and form types can appear or disappear. Between games you don't even have the basics you can depend upon. With each new game we have to find all of the relevant and important bits and update our internal code to match the new realties. The jump to the F4 64-bit engine was really big. We haven't really got real script extending working for F4SE yet (in part due to real life concerns). We are expecting there to be a similar big jump for the Special Edition. While in general we have a sense for the large subsystems are which ought to be closer to Skyrim and F4, until we look at the nitty gritty details we simply won't know. Add to this the fact that Bethesda again released the game in a psuedo-debug mode with a big extra jump table in between all of the functions, and anything we do right this moment will have to be redone as soon as they release a fix. They know about this - but who knows when they will have an update. Next week? Next month? We'll start investigating, but this is going to take some serious effort and time to get done. There is a ton of functionality in SKSE. We won't get it all implemented at once for the Special Edition. Expect early versions for the Special Edition to have a lot less functionality. And no ETA at all for when we'll have anything to show.

To be clear - I am one of the main developers behind the script extenders. But we are few in number, and have a lot to investigate with the Special Edition (and Fallout 4). No ETA at all on when we might have something. Just that we are looking at it.

And by they, of course you mean me. (See sigs below.) :)

So what exactly is your '64-bit version of SKSE'? Is it just building the original SKSE code for 64-bit? If so - that really isn't going to work. At all. SKSE depends upon hundreds of addresses inside the Skyrim binary. It depends upon knowing the internal class layout of the engine code and leveraging functions from Bethesda that we have uncovered. It also needs to patch the binary and functions so that our code is invoked properly- and this is a massively different process on 64-bit. Simply taking a look at the differences in what our code looks like between SKSE and F4SE will tell you that there is a huge amount of work to do.

TheDrukenMagi - have you been using the CustomControlMap to change keymappings? There was an update to the control mapping between 1.3.47 and 1.4.132. If you have any modifications there you will need to grab the CustomControlMap.txt from F4SE 0.1.8 and re-apply your changes.

Also note that I have upated F4SE as of this afternoon to work with the new official 1.4.132 release.

There was a change to the CustomControlMap.txt with the Fallout 4 1.4 beta (starting with build 1.4.125). If you used the 1.4 betas then you should have already updated the CustomControlMap.txt. If you were still on the stable 1.3.47 release then you will see an update in the CustomControlMap.txt.

F4SE 0.1.8 is now available for the new Fallout 4 1.4.132 runtime. For those updating from F4SE 0.1.5 and the previous 1.3.47 build of Fallout there has been an update to the CustomControlMap.txt. New RotateRight and RotateLeft entries have been added to the end. We've included the CustomControlMap.txt in the archive as always. Please re-apply your changes as appropriate. Let us know if you run into any trouble.

Update -it looks like the 1.4 patch may now be live for all users. I am working on updating as quick as I can. It should be tonight as mentioned.

Yep - another day another update. I am working on updating things. Hopefully available sometime this evening US Pacific time. @cattywampus4 - there is absolutely no way to do what you ask. F4SE has to know the exact addresses in memory of the various things we touch. Every time BGS compiles the application from source code these addresses change. We have to simply rebuild ourselves when the application updates. If you need to have a more stable environment to work then you should probably not participate in the betas as there will always be a lag in the betas between release and update of F4SE. The fact that BGS releases betas means that folks who don't participate in the betas can get immediate access to F4SE when the beta becomes public. Participating in the beta requires enduring a little hardship.

F4SE 0.1.7 is available for Fallout 4 runtime 1.4.131. No updates to the CustomControlMap.txt. I've done my basic testing and things seem alright. As always let us know if there are problems. The new automated update toolset worked well - life has just been incredibly busy. Sorry for the delay getting things put together.

And they've gone ahead and pushed out another update: 1.4.125. Only the executable changed. But it is enough that I have to start the port over again. Stay tuned. @pipdude111 - I am not sure how easy it will be to provide an overlay for specular maps. I will have to talk to the other engineers who may have a better clue about that. I've not been involved in that part of the engine yet.

There is a new Fallout 4 beta: 1.4.124. We're grabbing the beta now and will start to work on a new F4SE build. Until then if you need to use F4SE, don't update to the beta.

Not in the current build. I am actively investigating/implementing input support. It will definitely be available for our first official release after the GECK comes out. I hope it will be available earlier for plugins - but I don't know exactly when that will be. Just hooked on their GetRawInpuData processing routines for now. Works ok for my Place everywhere plugin. Excellent. Between Skyrim and Fallout 4 they switched away from DirectInput to a combination of GetRawInputData and XInput for controllers. I hadn't pinned things down completely.

Try running f4se_loader.exe as an administrator. If that doesn't work, please send along the contents of your f4se_loader.log and f4se.log. They may include information we can use to diagnose the problem.

jsemtvujkral Take a look at the f4se_loader.log and see what it reports. You'll find it in your My Games\Fallout4\F4SE folder. It should report what version of everything you are trying to use. Assuming you are on the latest release (1.3.47) you should be using F4SE 0.1.5. You'll need to update each of the components of f4se (f4se_loader.exe, f4se_1_3_47.dll, f4se_steam_loader.dll). You can get Properties on each of these components (Right-click>Properties) and go to the Details Tab. It should properly list version 0.1.5 of F4SE. Report back on that info and see what happens. You may also want to try launching f4se_loader.exe as an administrator and see if that makes a difference.

Not in the current build. I am actively investigating/implementing input support. It will definitely be available for our first official release after the GECK comes out. I hope it will be available earlier for plugins - but I don't know exactly when that will be.

Fallout 4 1.3.47 has been moved from Beta to Release and is the new stable build. F4SE 0.1.5 is the appropriate version to use with that build.

I would tend to imagine that normal scripting (when available) isn't going to provide any sort of input control to either trigger scripts or allow UI changes. So probably you would need support from F4SE to do your work. That doesn't mean that we'll have the ability to do what you want either - we haven't investigated this yet. It was probably a momentary glitch. The website seems to be working fine right now.

I'll note that we're not actually doing any scripting at this point. F4SE is simply replacing the in-memory string that is the CustomControlMap with the data in your customized CustomControlMap.txt in your f4se directory. We don't change any behavior at all - only what keys trigger that behavior. So it is very possible what you want to do it's feasible without additional changes to Fallout 4 behavior that we simply do not do yet.