-
-
Notifications
You must be signed in to change notification settings - Fork 346
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Let's clarify what the supports
relationship means.
#1104
Comments
For the record, I would also like to say that I think being able to show inverse relationships is a great idea, and may make some uses of |
My main concern with To me that's not a metadata problem, since the relationship is already expressed, just in the opposite direction. Then it just becomes a UI problem about presenting it to the user, from which #1100 arises. As for a non-informational (aka semantic) version of Quite a few mods will {
"spec_version": "v1.x",
"identifier": "AwesomeMod",
"supports": [
{
"name": "AmazingLifeSupport",
"depends": [
{ "name": "ModuleManager" }
]
}
]
} That way, |
Throwing my two cents in, since it's kind of my 'fault' that this got started :P I've described my interpretation of things in a bit more detail here, for documentation's sake: http://forum.kerbalspaceprogram.com/threads/52042-1-02-Near-Future-Technologies-%28All-packs-updated-to-1-02-Finally!%29?p=1998489&viewfull=1#post1998489 Note that while I'd like to have a field in which to do this, it doesn't absolutely have to be the 'supports' field if there's a good reason to do something else with it. It's just that, as I explained in the above link, the user cannot really collect the information 'what mods work well with this tech tree' by examining an arbitrary number of mods individually. By all logic and usability considerations, the tech tree itself should be able to provide that sort of information somewhere, and the 'supports' field as a purely informational field currently fills that role the best. Community Tech Tree is actually a very special case in that it expects other mods to set up support, but all other tech tree mods that exist or have existed actually do the part assignment themselves. For them, providing this information is even more important. Of course, this can be done by pointing the user towards the forum thread, which the CKAN client already does. But if there was a way to display it directly in the client, why not do that? Plus, CTT has another very special idiosyncracy in that regard... namely, I cannot use the forum thread to provide this information. The first post is Nertea's, I cannot edit it, and he's a super busy guy between all of his mods and RL. Maintaining the CKAN metadata, however, is something that I can do for him. Regarding the 'makes relationships harder to maintain' part, that's kind of a non-argument from my point of view. It implies that relationships are perfectly tracked right now, which is not the case. A lot of mods are added by CKAN team members or bulk contributors, not the original mod authors, and while the contributors can make educated guesses about what the relationships should look like, they obviously cannot read the mod author's mind. Case in point, the metadata for Nertea's mods, which I set out to update, only had a small fraction of the relationships that Nertea and I thought they should have. Not something you can fault the contributor for, but it's incomplete nontheless. And then there are mods added to CKAN by the original mod authors that don't make use of any of the relationship fields at all, even though they easily could. Additionally, new mods get added to CAN all the time, and occasionally one will show up that makes sense to include in a relationship after the initial posting. For example, just today I came across a new contract pack that adds its own tech tree, thereby conflicting with CTT. This pack isn't on CKAN yet, but as there's a huge number of other ContractConfigurator packs already present, it's highly likely that it'll eventually make its way into the repository. If I notice, then I can update the relationship; if I don't notice, then I won't. All of this implies that you cannot have the expectation that all relationships are ever fully complete or fully reliable. The only relationship field that is always guaranteed to be complete is the 'depends' relationship. For all others, you should in fact make the assumption that they are always incomplete, and the only way to move them towards a state of quasi-completeness is by actively maintaining the relationships (ideally done by the mod authors themselves). Therefore, having an information field where tech trees reference other mods does not intrinsically make the relationship metadata less reliable. It'll be just another optional field like all the others - probably includes some useful information, but also probably incomplete. If a tech tree does not properly fill out the information field, then that's not a problem of the CKAN specification... it's an optional field, after all! Like all the other relationships except 'depends'. As a purely informational field, it even does less damage (namely none) than when certain other fields (namely 'conflicts') are incomplete. |
My day is crazy, so apologies for my very brief response. Semantic Supports / Conditional relationships This is a hard problem. We had something like it back in October 2014, but we removed in #209 because it's very hard to have "dependent installs" to act consistently, and we no longer had a guarantee that the same mods would install the same way every time. That was back in the days when a mod could contain optional components within itself, and luckily we're not doing that any more. :) @dbent's suggestion here is different to and better than our old dependent installs, but it's still a tricky problem. If X recommends Z if Y is installed, then we can absolutely do the right thing if the user is installing both X and Y, or if the user is installing X and Y is already installed. The question is what we should do if the user has X installed, and later installs Y? In this case I think the answer is clear: we should recommend the user installs Z. In other words, if the user installs any mod we scan through all the existing relationships and see if any conditional relationships are now satisfied. In this case, I'd suggest we'd expand the relationship syntax itself in general:
By having a That's pretty darn powerful. We'd need to hash out the syntax and details, but having dependencies on any relationship is going to give us a lot more power going forward than only having them available on the supports field, and potentially gives us extra goodness if and when we implement warnings (#211) and other relationship types. Relationships and accuracy
I'm totally out of time, but @lOmicronl pretty much hit my thoughts on the head here. Our metadata is always going to be in a state of flux, and we should be very generous in what we accept for informational and human-oriented fields such as Suggestions:
Further discussion and telling me that I'm wrong absolutely encouraged. :) |
Aye, I like the To me, a bidirectional i++; // increment index by one That is, redundant and extremely prone to decay once the actual behavior changes: i+=2; // increment index by one It's not that I'm unaware that metadata requires constant updates to keep accurate, it's that bidirectional To be clear: I don't think bidirectional |
I think Any stronger relationship (i.e., install-by-default) belongs in the depending mod, but in the case where I do some dev in my mod to support RasterPropMonitor, it would be nice if my mod came up as a suggestion when RPM is installed. I'd say it makes sense for that relationship to live in my mod's metadata, since my mod is where the relevant code change happened; and RPM shouldn't have to know every single mod out there that works with it. For a tech tree, same deal. ModX supports Tech Tree Y, so when you install TTY, you get the option to install ModX. |
10 cents from a non-technical, common-user, logophile view ...
To me, I think The I'll leave y'all to herding the cats into using these they way you intend. |
It sounds like it might be good to have a "supporting mods" selection screen, similar to the "recommends" screen, but based on a reverse relationship lookup. |
I was thinking we could mix them into the existing suggestions/recommendations screens, defaulting to not install. Those lists are usually short enough, a few more unchecked checkboxes won't hurt anyone, and fewer steps/screens is generally better. |
Sure, with suitable descriptions of the relationships. We'd have to replace the "Recommended by" column with a "Why" column and prepend "recommended by/suggested by/supports" to the related mod name. |
After #2744, these are two distinct sections of one screen. We could easily add "Supports" or "Supported By" as a new section on the same screen, with no wasted UI space or confusion. 👍 |
The spec has a pretty short explanation for the
supports
relationship, which came out of #11.It looks like we need this to be clarified, as KSP-CKAN/NetKAN#1565 shows there's at least two interpretations.
So, I'd like to clarify just what we mean when we use the supports relationship. To me, it's always meant "X works with Y" and in particular "X gives consideration to Y". Using the example which has just come up a mod might "support" the Community Tech Tree, meaning the author has specifically coded their mod to use the extra nodes if it's found to be installed.
At the same time, I think it's reasonable to say that the "Community Tech Supports X". Even though all the effort may have been done in X to ensure compatibility, if it was done in consultation with with the Community Tech Tree, then we'd expect the CTT not to change in a way that causes X to break.
Finally, I'd like to express a very strong preference for
supports
to remain an information-only relationship. Indeed, I can't imagine how it would work as anything else, since all our other bases are already covered in our relationship model (depends
- you must install this mod;recommends
- you should install this mod;suggests
- you might consider installing this mod,supports
- hey look, a mod!).Discussion very much welcome. Tagging @dbent in particular, who's very much been in the front-line here.
The text was updated successfully, but these errors were encountered: