Feature request: SKSE dependency tracking

[HomerSlated]

I just spent the entire day updating SkyrimSE, courtesy of Bethesda/Steam. From what I can tell, there is almost nothing in this 2GB+ update that is of any relevance to PC users, at least not those who use The Nexus in preference to Creation Club. This process is much complicated by the fact that my (and I suspect most Nexus users') install of Skyrim is heavily modded, and as such updates often break a very large number of dependencies.

 

This is especially true for SKSE.

 

While SKSE itself is usually updated in a timely fashion, its many third party plugins are not, and tracking them all, on a heavily modded system, is an absolute nightmare.

 

Before committing myself to the update, I did attempt some research, to verify that everything would still work afterwards, but with so many mods I was bound to miss something. I then forged ahead, but it wasn't until I'd wasted most of the day on this that I discovered that one rather essential SKSE plugin had not been updated, namely RaceMenu. Results vary, from CTD to non-functional sliders. In my case it's unable to load presets, which ironically means I can no longer use or work on my own RaceMenu preset mod.

 

Of course, none of this is the fault of Vortex or The Nexus, but before wasting yet another day completely reversing this process, which involves downgrading SkyrimSE, SKSE and dozens of other mods, assuming I can still obtain older versions, I wish to suggest a new feature for Vortex that would have saved at least an entire day of my life.

 

Would it be possible for Vortex to display, in both the list and the info box, whether a mod requires SKSE, and if so which version?

 

Additionally, when using the "Check for Mod Updates" feature, would it be possible to display not only the mod's newer available version in the Version column, as it does now, but also the version of SKSE this update requires, if applicable.

 

Or better yet, can we please have a dedicated SKSE column, which can then be sorted and filtered to produce an easily discernable list of mods that need SKSE, and which version they need respectively.

 

That would then make it clear to the user if and when all installed mods that need SKSE have updates compatible with the newer version, allowing them to opt out of any update until everything is in sync.

 

You could even implement a system that locks all SKSE dependent mods to whatever version of SKSE is installed, refusing to upgrade them until all versions are in sync, or allowing certain mods to be ignored by disabling them.

 

I feel that SKSE is a special case that warrants this additional effort, because so many other mods are not only dependent on it, but are hard dependencies on specific versions.

 

Thank you.

[HadToRegister]

Not sure what the effort would be behind that?

SKSE always is always the "newest version" to match the newest Skyrim EXE, and if a mod doesn't update to the newest version of SKSE it becomes unusable

 

The best way to "opt out" is to download and install "SkyrimSE.exe Auto Backup" mod.

It automatically backs up your current SkyrimSE.exe in a folder in your Game Directory, so if there's a Creation Club update, it's just a matter of copying that backed up exe to your game folder (after RENAMING your UPDATED SkyrimSE.exe) so you can keep playing the game while waiting for SKSE64 and the mods that require it to update.

If you TRACK those mods in the tracking center, you can easily follow which mods have been updated

Maybe in the future this could be incorporated into Vortex? Not sure, but since the Script Extenders are 'off site' I'm not sure how Vortex could track them

[HomerSlated]

Thank you, I wasn't aware of SkyrimSE.exe Auto Backup.

 

However, surely restoring the previous version of Skyrim entails more than just a single executable. Don't the ESMs contain assets that would break if used with the wrong version of the EXE? Then there's USSEP, which again has a hard dependency on not only a specific version of the EXE, but also the ESMs and presumably other assets, since it fixes scripts amongst many other things. Worse still, the USSEP devs have a policy of making older versions unavailable, which means that unless I had the foresight to back up my local copy, I'm now incapable of downgrading.

 

Anyway, my point is that having to manually track 500 mods is a logistical nightmare. As far as I can tell, the Tracking Centre doesn't tell me that XYZ mod has been updated to support ABC version of SKSE, I still need to visit each actual mod page and read the changelog. Or in the case of RaceMenu, the description field of the main file in the files section.

 

Being able to tell at a glance, just looking at Vortex, which mods will break if I update SKSE, would save me a lot of wasted time.

 

Although SKSE itself is off site, the SKSE plugin mods on The Nexus do declare their dependency on SKSE, including the version they currently support. Unfortunately there isn't a dedicated field for this info, so parsing it programmatically from the mod page (or SQL backend) currently isn't possible, at least not reliably, so my humble request extends to asking for this feature to be implemented on the backend too.

 

Thanks again.

[AugustaCalidia]

 

However, surely restoring the previous version of Skyrim entails more than just a single executable.

 

No, it does not require more. Bethesda is not updating the core game files. Current updates are nothing more than Creation Club updates which do not touch the core files. Use Auto Backup to revert to the previous .exe and then play your game. I know it sounds too simple, but it works. I've done it many times.

[HomerSlated]

OK thanks. I must admit this surprised me.

[HadToRegister]

Thank you, I wasn't aware of SkyrimSE.exe Auto Backup.

 

However, surely restoring the previous version of Skyrim entails more than just a single executable. Don't the ESMs contain assets that would break if used with the wrong version of the EXE? Then there's USSEP, which again has a hard dependency on not only a specific version of the EXE, but also the ESMs and presumably other assets, since it fixes scripts amongst many other things. Worse still, the USSEP devs have a policy of making older versions unavailable, which means that unless I had the foresight to back up my local copy, I'm now incapable of downgrading.

 

Anyway, my point is that having to manually track 500 mods is a logistical nightmare. As far as I can tell, the Tracking Centre doesn't tell me that XYZ mod has been updated to support ABC version of SKSE, I still need to visit each actual mod page and read the changelog. Or in the case of RaceMenu, the description field of the main file in the files section.

 

Being able to tell at a glance, just looking at Vortex, which mods will break if I update SKSE, would save me a lot of wasted time.

 

Although SKSE itself is off site, the SKSE plugin mods on The Nexus do declare their dependency on SKSE, including the version they currently support. Unfortunately there isn't a dedicated field for this info, so parsing it programmatically from the mod page (or SQL backend) currently isn't possible, at least not reliably, so my humble request extends to asking for this feature to be implemented on the backend too.

 

Thanks again.

 

 

I made a text file called Mods that Require SKSE64, and I put the names of all the mods I use that use it, that way, I have a quick reference list of the mods to go and check for an update.

 

I use the tracking centre and sort it by LAST UPLOAD, that way I can quickly check the list for the last upload date, which lets me know if the mod has been recently updated, because if it has a "Last Upload" date a few days after the game, and SKSE64 updated, then it's probably been updated for the news SKSE64.

 

It's not a perfect method, but it does help.

[HomerSlated]

Yes that's a good plan. It's a lot of work the first time around, with a large number of mods, but it's a usable solution.

 

Also, am I right in thinking that every mod that in any way utilises SKSE must have a DLL in Data\skse\plugins?

 

Or are there mods that can merely use SKSE without providing any sort of plugin?

 

Oh wait, no, I see that Campfire, Frostfall and Wearable Lanterns all have folders in there, but no corresponding DLL. I take it the plugin they're all using is PapyrusUtil.dll? So as long as Papyrus works with SKSE then those three mods will continue to function correctly?

 

Can I literally just count DLLs and call that my SKSE modlist?

[HadToRegister]

Yes that's a good plan. It's a lot of work the first time around, with a large number of mods, but it's a usable solution.

 

Also, am I right in thinking that every mod that in any way utilises SKSE must have a DLL in Data\skse\plugins?

 

Or are there mods that can merely use SKSE without providing any sort of plugin?

 

Oh wait, no, I see that Campfire, Frostfall and Wearable Lanterns all have folders in there, but no corresponding DLL. I take it the plugin they're all using is PapyrusUtil.dll? So as long as Papyrus works with SKSE then those three mods will continue to function correctly?

 

Can I literally just count DLLs and call that my SKSE modlist?

 

 

I "THINK" they all have dlls, hence the need to upgrade the mods along with SKSE64

 

My plugins folder has about 13 dlls and their corresponding ini files

 

No, PapyrusUtil.dll is not a common dll for each SKSKE64 mod, each skske64 mod should have it's own dll.

some also have folder for where the mod SETTINGS are saved

 

I have

 

AchievementsModEnabler.dll

AddItemMenu.dll

AHZmoreHUDinventory.dll

auto_backup_executable.dll

AutoHarvest.dll

EngineFixes64.dll

fiss.dll

JaxonsConsolePlugin.dll

MoreInformativeConsole.dll

PassiveWeaponRecharging.dll

skee64.dll

SkyrimUncapper.dll

 

 

If all of the SKSE64 mods relied on one dll, that'd be easy, but they all use their own.

[HomerSlated]

Hmm, OK so this is going to be harder than I thought.

 

For example, the mod page for Campfire does not list SKSE as a requirement, or even an option, anywhere at all, and yet there it is clearly using SKSE via Papyrus. I had to go offsite to GitHub to find SKSE even mentioned as a requirement.

 

It seems there really is no way to implement this programmatically, unless a NEEDS_SKSE={0/$VERSION} flag is implemented on the backend (and actually used by mod authors).

 

If I have to go on a wild goose chase to manually determine SKSE dependency for 500+ mods, I might literally die of old age before I'm finished (and at my age that's an actual possibility).

[HadToRegister]

It looks like Campfire, Frostfall, Wearable Lanterns all rely on PapyrusUtil.dll

 

YEa, I agree, I looked at the Campfire mod and it seems it's just assumed people will know what to do with it, but I saw another say PapyrusUtil isn't even needed fro Campfire.

The mods that use PapyrusUtil need to make it clear what it's there for, I'm finding it confusing at best.

You won't have that problem with Other mods,
This is the first I've heard of PapyrusUtil.dll