Use internal ckan and version file to install unrecognized ZIPs#4327
Merged
HebaruSan merged 6 commits intoMar 16, 2025
Merged
Conversation
Member
Author
|
@JonnyOThan, this feature is ready for alpha testing with paid mods if you have time: |
35fefd9 to
cff0c3b
Compare
cff0c3b to
cc35312
Compare
Merged
This was referenced May 14, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
To install a module, you need metadata for it, which currently comes from either a metadata repository (e.g., CKAN-meta) or a standalone
.ckanfile. It would be nice if a mod could be more self-contained, so the ZIP itself could provide all the info needed to install.Internal .ckan files potentially could provide a mechanism for this, but they're currently only checked by NetKAN. Additionally, this usage would clash somewhat with the existing usage:
CkanModule.versionis required, and while it technically could be added to an internal.ckanfile, that would require additional manual maintenance for every release of a mod and would be redundant with the more reliable host APIs that usually provide this data. So we need another way of setting the mod version, preferably one that would work for at least some existing mods.CkanModule.downloadisn't needed for downloading when you already have the ZIP, but it is required for cache management and also a bad idea to set in your internal.ckanfile for the same reasons asversion.Changes
Now if you try to import a ZIP that isn't found in any of your configured metadata repositories, CKAN will scan it for internal .ckan files and "inflate" them if found, using a simplified version of what NetKAN does:
$vrefproperty exists, we scan the ZIP for either a*.versionfile or aswinfo.jsonfile (depending on the value of$vref), parse it, and import its version and compatibility properties into the module.downloadproperty isn't set, we assign it a default value that contains both the mod'sidentifierand the name of the ZIP file, which should hopefully prevent two different mods accidentally sharing the same URL (and therefore cache hash).If the inflated metadata satisfies all of
CkanModule's required fields, then the file will be imported to the cache and can be installed during the importing process. (If you import without installing, you won't be able to install it later, because the inflated metadata is discarded after the importing is complete.)To make this work, several things needed to be moved from NetKAN to Core:
YamlExtensionsso we can parse the internal .ckan file in the clientAvcVersionso we can parse .version filesSpaceWarpInfoso we can parseswinfo.jsonfilesModuleService.ApplyVersions, which is nowGameVersion.SetJsonCompatibilityso we can set the game version compatibility properties correctlyIdeally, all of the inflation logic would be shared with NetKAN, but that has not been done at this point due to limitations of NetKAN's code structure and some subtle differences in how the inflation needs to be done in the two contexts.
Known limitations
.versionfile may have some quirks. Suppose there's a mod that has a partially non-numeric version string on GitHub/SpaceDock, likev1.2.3; thevcan't be represented in a.versionfile, so the above described importing logic would setversionto1.2.3. But now suppose the mod in question is in the metadata repo but you are importing a release of it that isn't indexed (yet?). The value ofversionthen would not reflect the "correct" value that will eventually be generated by NetKAN (with thevprefix) for that release when it is indexed. The same goes for any mods usingx_netkan_version_editorx_netkan_epochto massage version strings into consistency. This may even result in out-of-order version strings.For this reason, it's probably best to limit usage of this feature to mods that are not and never will be indexed.