Open manavortex opened 10 months ago
If the mod has a json manifest of some sort that is standardized, all of that is quite feasible in the vortex extension. Part of me feels like this sounds like FOMOD things, which might also be a solution? The only issue with the FOMOD is that it bypasses our extension, which is fine if the mod author puts things where they go.
A checkbox during Nexus file upload "allow REDMod conversion" and set it to true by default. This is probably not feasible because Nexus would have to store it in their database?
Ya, we don't really have any access to changes on the Nexus side of things, but we might be able to get something added if it were generic enough.
Don't think FOMOD integration is feasible, let's keep this simple - the plugin can probably parse these files? We'd have to come up with a shared structure :)
You could maybe talk to the Nexus guys and ask about it? Maybe it'd be possible to have a few optional fields per mod, which could then be configured for different games somehow? (Not sure about the standard value btw)
I like the idea the more I am turning it over in my head. A json manifest would be good since we already have json parsing in the extension. Given the examples in the OP, it'd be good to have a list of options and default values as needed. I haven't looked into the uninstaller on Vortex, so I am unsure if we can hook into it or not. Hopefully we can, because that'd be quite nice.
Motivation
Many mods have requirements that Vortex could easily handle if it only knew about them, such as:
This ticket should serve as a discussion thread to channel this process away from the Vortex dev team and manual support requests.
Solution: Manifest
The easiest way I can see is if mod users could provide a sort of manifest file in json or yaml. Vortex could parse that upon deployment and consider the information, such as (for example)
loadOrder: 1
=> will insert this mod in the load order before anything that doesn't have one specifiedloadOrder: 2
=> will insert this mod in the load order before anything that doesn't have one specifid, but after anything with loadOrder 1excludeFromRedmodConversion
=> will make sure that the mod will never be converted to REDModforceRedmodConversion
=> will force REDMod conversion, no matter what the user has specified. Or maybe ask the user if they're OK with that.skipVortexIntegrityCheck
=> Mod authors could disable any installation warning popupsoutdatedModFiles: { "bin/x64/plugins/cyber_engine_tweaks/mods/my_mod/init_old.lua" }
=> Vortex could delete these upon reinstall We could even integrate this into Wolvenkit, auto-generating a manifest file has been discussed before.Other solutions
Additional context
Every mod using this feature could be removed from Vortex's list of exceptions for REDMod conversion. Regardless, the usual checks and balances would have to apply.