Support depends on any_of lists #2660
Merged
+533
−247
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.
Background
Sometimes a mod needs some functionality to be provided by a third party dependency, and there are several choices available, but they have different APIs, so the dependent mod has to implement support for each one separately.
For example, TextureReplacer, TextureReplacerReplaced, SigmaReplacements-SkyBox, and DiRT can all be used to replace the stock SkyBox with a custom one, but they're all mutually incompatible and so a dependent mod has to implement support for them separately one by one.
The
provides
property can't handle this (well), since there is no baseline abstract concept that they could sensiblyprovide
. Consider if we had all four of the above mentioned modsprovide
something like SkyBoxReplacer; then we would not have a solution for a dependent mod that only implemented compatibility with 2 or 3 of them. We would need oneprovides
tag for each possible permutation of supports that a mod could implement, which would be unworkable.Changes
NOTE: This is a high risk change. Core pieces of
RelationshipResolver
are modified, which risks breaking common tasks. Please review with care!Now a new
any_of
format for relationships is allowed:This creates a requirement that can be satisfied by any of the specified modules. If the user installs a module with the above syntax, they are prompted to choose which dependency to use:
(It works in GUI too.)
The schema and spec are updated to incorporate this syntax.
RelationshipDescriptor
is now an abstract base class (let me know if an interface would be better somehow) with two child classes,ModuleRelationshipDescriptor
(formerly known asRelationshipDescriptor
) andAnyOfRelationshipDescriptor
which models the new syntax and mainly holds aList<RelationshipDescriptor>
and multiplexes access to it.Various tests are updated to instantiate
ModuleRelationshipDescriptor
now thatRelationshipDescriptor
is abstract.A new
JsonRelationshipConverter
class handles parsing .ckan files, populating lists ofRelationshipDescriptor
with instances of the appropriate child classes based on the contained properties.Parts of
RelationshipResolver
are refactored to handle the new syntax, mainly by calling virtual members ofRelationshipDescriptor
.Fixes #2522.
Reverse dependencies fix
Previously if you installed a mod that depended on another mod, but the latest of version of the dependency conflicts with or depends on a different version of the original mod, then you'd get an error.
Now older versions of the dependency will be checked to see whether they're compatible.
Includes tests to make sure this works.
Fixes #1693.
Tests fix
I was still getting the error from #2628, I think because the cache objects in KSPManager weren't being disposed. Now this is added to the affected tests.