Both very soon after release by an update which was specifically designed to break the mod.
I’m now curious about this from a technical perspective - how did the update specifically break their mod in particular? Were they doing a bunch of custom DLL hooks or something?
I know with Skyrim SE modding it’s usually that any update breaks SKSE and a tiny handful of other mods that directly hook DLLs or the executable (these mods are usually scripting engine extensions and are a dependency for a variety of other mods), and depending on the update sometimes it takes longer than average to get a new version of those running (the AE update was one of those because they switched compiler version and that broke the method SKSE was using to find hooks). But in general that only breaks 1) mods using those (think SkyUI) until a new version comes out, after which most of those mods start working again without the individual mods needing an update and 2) mods that include their own plugin DLL, (think SkyClimb) which have to wait on an update and then compile a new version of the DLL for the new version of both the game and the other mod, because addresses and functions they are hooking may have changed. Mods not using SKSE or similar generally run just fine between versions of SSE (including AE).
So basically what happened with the AE release for Skyrim SE where Bethesda switched to a new compiler version and the tool the script extender team was using to find the correct offsets couldn’t handle it so they had to track down the offsets manually like before they’d written the tool, leading to a longer than usual time for the script extender to update than usual?
Which if it’s anything like SSE means that mods that didn’t use F4SE were basically unaffected, mods that use F4SE had to wait for it to update which took longer than usual after which they would mostly work unmodified, and mods that involved a plugin DLL for F4SE had to at the very least be recompiled against the new versions of the game and F4SE. Nothing about that specifically targets Fallout: London though from what it sounds like.
I mean, it would suck for any mod using F4SE. The answer for what to do is the same as every other update - recommend people not update until F4SE is updated.
Did they have their own plugin DLL or were they just using F4SE as is? If the former that would make it suck for them even worse since they’d potentially need to find some new hook addresses of their own and wait for the new F4SE and then reconcile their DLL.against that and then test it all again to make sure nothing broke.
I’m now curious about this from a technical perspective - how did the update specifically break their mod in particular? Were they doing a bunch of custom DLL hooks or something?
I know with Skyrim SE modding it’s usually that any update breaks SKSE and a tiny handful of other mods that directly hook DLLs or the executable (these mods are usually scripting engine extensions and are a dependency for a variety of other mods), and depending on the update sometimes it takes longer than average to get a new version of those running (the AE update was one of those because they switched compiler version and that broke the method SKSE was using to find hooks). But in general that only breaks 1) mods using those (think SkyUI) until a new version comes out, after which most of those mods start working again without the individual mods needing an update and 2) mods that include their own plugin DLL, (think SkyClimb) which have to wait on an update and then compile a new version of the DLL for the new version of both the game and the other mod, because addresses and functions they are hooking may have changed. Mods not using SKSE or similar generally run just fine between versions of SSE (including AE).
Full recompilation of exec from scratch - memory positions changed and basically f4se became extremely borked.
So basically what happened with the AE release for Skyrim SE where Bethesda switched to a new compiler version and the tool the script extender team was using to find the correct offsets couldn’t handle it so they had to track down the offsets manually like before they’d written the tool, leading to a longer than usual time for the script extender to update than usual?
Which if it’s anything like SSE means that mods that didn’t use F4SE were basically unaffected, mods that use F4SE had to wait for it to update which took longer than usual after which they would mostly work unmodified, and mods that involved a plugin DLL for F4SE had to at the very least be recompiled against the new versions of the game and F4SE. Nothing about that specifically targets Fallout: London though from what it sounds like.
Exactly, nothing target mod specifically, it’s just dramatic people being dramatic. It DOES suck for Fallout London creators, but whatchu gonna do.
I mean, it would suck for any mod using F4SE. The answer for what to do is the same as every other update - recommend people not update until F4SE is updated.
Did they have their own plugin DLL or were they just using F4SE as is? If the former that would make it suck for them even worse since they’d potentially need to find some new hook addresses of their own and wait for the new F4SE and then reconcile their DLL.against that and then test it all again to make sure nothing broke.