ianpatt

I'm not sure about the issue you're running in to, but I can confirm that Starfield does not use DirectStorage. It would need to ship with two DLLs (dstorage.dll and dstoragecore.dll) that are not included with any DirectX installation.

No, it doesn't. You think that it does because people have made kludges that let the plugin manager sort of work. Currently there are no mods using Papyrus or most of SFSE's features (or the current feature set of SKSE) because there's no editor. All of those would be broken if you tried using them with the hacks to make it launch on the GP build. People who enable a partially-working version of SFSE on GP now are selling you a false promise that it will continue to work. Guess who the users would complain to when that hack stopped working?

This is not a donation issue. Before anything else, it's a workload issue for the mod developer community. The executables for Game Pass and Steam are different, and SFSE/plugins work by directly manipulating the internals of the executables. Any difference in the executable is an incompatibility. Supporting two different executables is a lot of work, especially this early in the life cycle of native code modding. We don't even have a way to support using the same plugins across different patches of the game, or a solid well-tested library for building plugins. For that matter, we don't even have an official editor. I also would never ship a destructive method of installation, like what you need to do to take control of the file permissions of Starfield.exe on Game Pass. Please read the comment carefully. Since these issues are purely technical, there isn't anything useful that the non-technical community can contribute to solve them. All of the removed posts have just been complaining that Game Pass isn't supported. I know that people want support for Game Pass, there's nothing constructive to add. Hence discussion of Game Pass is not allowed in the mod thread. Do you genuinely think that I don't want to make as many people happy as possible?

The address library is not part of SKSE, so it wouldn't have updates posted on that website.

It did. The plugin manager (also preliminary) is enabled, and version checking has been rewritten. Using an alchemy bench will also not crash with SkyUI installed now.

Here's SKSE64 2.0.7 for runtime 1.5.39: 7z archive. whatsnew: - support for runtime 1.5.39 - fixed SimpleLock/BSReadWriteLock implementation - fixed Ammo functions edit: The version check in PapyrusUtil SE is broken, and would crash the game if loaded. I've added this version of that plugin to an internal compatibility table to stop it from crashing, and contacted the author with details of how to fix the problem.

SKSE64 2.0.5: 7z archive Here's an update for runtime 1.5.16. If you are running in to crashes on startup, please check your /Data/SKSE/Plugins folder for outdated plugins that don't perform a proper version check. Once you've identified a plugin that is crashing on startup, please contact the author (not me) for an update, and ask them to add a proper version check. whatsnew: - support for runtime 1.5.16 - fix crash in GetLeftHandSlot (could show up in Actor.EquipItemById, GetEquipSlotById, EquipItemEx, UnequipItemEx) - fix GetFormWeight return type - many internal definition fixes/additions - hooks for tint texture size - unified internal tasks - handle lookup for 'light' mods, serialized in cosave

SKSE64 2.0.4 alpha for 1.5.3 beta runtime: 7z archive This fixes a crash on save that I missed in testing. A value that used to store the number of loaded mods changed format with the Creation Club update, and I didn't notice because of the likelihood of the new value being stored there being zero. Oh well. 2.0.4: - fix DataHandler layout changes from Creation Club - fix occasional crash on save - proper reporting of current beta/release runtime version You only need this version if you've opted in to the 1.5.3 beta runtime. Otherwise, continue with 2.0.2.

SKSE64 2.0.3 alpha for 1.5.3 beta runtime: 7z archive 2.0.3: - support for runtime 1.5.3 - update Armor and Actor scripts for new functions added in 1.5.3 - FastTravelEnd event sink (internal) You only need this version if you've opted in to the 1.5.3 beta runtime. Otherwise, continue with 2.0.2.

SKSE64 2.0.2 alpha: 7z archive 2.0.2: - fixed scaleform ShowOnMap

SKSE64 2.0.1 alpha: 7z archive 2.0.1: - fixed missing save hook (skse cosave wasn't being written when triggered from papyrus)

Here is an alpha version of SKSE64. It is currently not intended for use by most users. It will be primarily interesting for mod authors and people who want to test things. Reporting that mod X doesn't work is probably not very helpful, but reporting that ActorBase.GetCombatStyle() always returns an empty form would be helpful. I would like to thank eternity for his recent help and going above and beyond to get this closer to the finish line. This would be going up much, much later without his help. SKSE64 2.0.7 beta: 7z archive 2.0.1: - fixed missing save hook (skse cosave wasn't being written when triggered from papyrus) 2.0.2: - fixed scaleform ShowOnMap 2.0.3: - support for runtime 1.5.3 - update Armor and Actor scripts for new functions added in 1.5.3 - FastTravelEnd event sink (internal) 2.0.4: - fix DataHandler layout changes from Creation Club - fix occasional crash on save - proper reporting of current beta/release runtime version 2.0.5: - support for runtime 1.5.16 - fix crash in GetLeftHandSlot (could show up in Actor.EquipItemById, GetEquipSlotById, EquipItemEx, UnequipItemEx) - fix GetFormWeight return type - many internal definition fixes/additions - hooks for tint texture size - unified internal tasks - handle lookup for 'light' mods, serialized in cosave 2.0.6: - support for runtime 1.5.23 2.0.7: - support for runtime 1.5.39 - fixed SimpleLock/BSReadWriteLock implementation - fixed Ammo functions

Sorry, this isn't intended to be an April Fools joke or something like that. I don't really have any good news. A large amount of the core code (papyrus support, scaleform support, etc) is ready, but the layout of most of the game data classes still needs to be verified as unchanged from the 32-bit version. I haven't had any time to work on this for the past few months due to work, and I assume the same is true for Stephen. Making time estimates for full-time professional engineering projects is very hard, and this is far from that. Again, sorry for getting people's hopes up.

Here's F4SE 0.3.0 with support for runtime 1.9.4 as well as some other new stuff: http://f4se.silverlock.org/beta/f4se_0_03_00.7z. whatsnew: - support for runtime 1.9.4 - input event hook - event sending - ScriptObject.Register/UnregisterForKey/Control - enabled papyrus API for plugins It was never an option. Trying to run a mismatched F4SE/runtime pair will crash on startup. The message is to provide a more useful explanation than just crashing. If you want to play in the meantime, just run the game by launching Fallout4.exe directly.

Yes, it does. This makes the code easier to read (for us) and faster to run (for the computer), so it's good for everyone. The tools used to help automate updating for different versions of the executable also break when compiler options are changed, so it's good that this is being done before we have hundreds of addresses to update.