Categories

[netkan-bot]

Issue by Andy81le
Monday May 04, 2015 at 08:21 GMT # Sample: Friday Sep 13, 2013 at 22:58 GMT
Originally opened as https://github.com/KSP-CKAN/CKAN-GUI/issues/93

---

It would be practical to have categories in order to be able to choose mods and plugins more easily. A good starting point for categories would be that of the 'Community Mods and Plugins Library' (http://forum.kerbalspaceprogram.com/threads/55401-Community-Mods-and-Plugins-Library). This would also give the modding community a bit more consistency.

[netkan-bot]

Comment by politas
Monday May 04, 2015 at 08:23 GMT # Sample: Friday Sep 13, 2013 at 22:58 GMT

---

This would be good.

[netkan-bot]

Comment by Shaggygoblin
Sunday May 24, 2015 at 09:23 GMT # Sample: Friday Sep 13, 2013 at 22:58 GMT

---

+1, similar to how parts are 'catagorized' in KSP, a 'tag(s)' can be utilized to denote parts only, visual/audio, modules (adds/changes functionality). RemoteTech would be a Part and Module, RasterPropMonitorCore would be a Module only, KW Rocketry would be Parts only. If a Parts Only pack had a dependency which contained a Module tag, then possibly append the Module tag to the parent, thus B9 would inherit it's Module tag from it's dependent, FirespitterCore.
Just thinking out loud, sorry.
But still +1 on the Categories/Tabs in CKAN.

[netkan-bot]

Comment by dewiniaid
Monday May 25, 2015 at 19:47 GMT # Sample: Friday Sep 13, 2013 at 22:58 GMT

---

+1 for tags/categories, but please allow metadata to support multiple categories -- and have a built in "uncategorized" category for mods lacking categories.

It'd also be neat if the tags included what -kinds- of parts are involved, e.g. things like "ISRU", "Unmanned", "Manned", "Station", "Science", etc -- in addition to generic things like "Tech Tree", 'Career", "Physics"

[netkan-bot]

Comment by damerell
Wednesday May 27, 2015 at 00:46 GMT # Sample: Friday Sep 13, 2013 at 22:58 GMT

---

An obvious characterisation would be "library" mods which are only installed as dependencies - which add nothing to the game in and of themselves.

[netkan-bot]

Comment by Dazpoet
Friday May 29, 2015 at 12:43 GMT # Sample: Friday Sep 13, 2013 at 22:58 GMT

---

How would people feel about a "hidden" category filled with mods like the "library" mods mentioned above that was hidden from the user from the start? There has been some discussion like that over in #803 and now that KSP-CKAN/CKAN-GUI#137 is in the works it might be more feasible than before to consider such a thing.

I will assume that a great part of this request is based on the aspect of wanting to shop for mods more easily, but also to some degree to resolve some of the clutter that is the CKAN modlist? I think a hidden category (which could easily be shown if a user wanted it) could be a good solution to the latter and it would perhaps also make shopping for mods easier?

As for the implementation I would assume this would require us to update a lot of metadata making #947 extremely relevant.

[netkan-bot]

Comment by plague006
Friday May 29, 2015 at 12:46 GMT # Sample: Friday Sep 13, 2013 at 22:58 GMT

---

Would hiding library mods cause an issue where users uninstall the mod relying on the library but can't find the actual library to uninstall it?

[netkan-bot]

Comment by politas
Friday May 29, 2015 at 13:41 GMT # Sample: Friday Sep 13, 2013 at 22:58 GMT

---

If the "Hidden" category was implemented with a change to the default filter, that could work. Perhaps then there could be an "Unused Libraries" filter that lists all such "hidden" mods that nothing currently depends on, to cover @plague006's case.

[pjf]

Bot got rate-limited, but we also had from @Dazpoet :

We solve it with #978 :)
Or the current Installed category.

and from @dewiniaid :

I think that categories/tags should be descriptive, rather than being used directly to trigger any sort of behavior. "Hidden" tells me as a user nothing about a particular mod. So, from a metadata/spec perspective, it seems wrong.

Now, if a compatible client (e.g. this one) wants to attach a default behavior to -- say -- hide uninstalled mods that ONLY have the "library" tag, that seems more appropriate. Of course, if we have an aptitude/synaptic-like tree view of mods by category, this is a non-issue because all the libraries will be segregated into their own category anyways.

[damerell]

I think one has to be careful of overly-complex category schemes for two reasons. One is that someone's got to maintain them, either adding load on the mod maintainer or the CKAN contributors.

The other is, I fear, that what one really want to be told is which mods in the list are actually any good - harshly, to distinguish FAR from some guy's personal suit retextures. However, CKAN can hardly get into value judgements.

That said, I think it's clear that hiding library mods (leaving aside the division between tagging and client behaviour) is desirable.

A second improvement might be a mechanism for designating packages as "submods", only to be displayed when their parent mod (without which they are useless, and which might itself be a metapackage) is selected for installation. The ream of Astronomer's Pack mods would be an obvious example here. (It's not just another word for "dependency", but implies a relationship where you would only possibly want the submod after considering the parent mod. Another example would be that ATM Basic/Aggressive could be submods of an ATM metapackage).

Beyond that I'd suggest a mechanism for categorisation lists themselves to be third-party extras; a way for (for example) the user of a particular client to say "Community Mods and Plugins Library categories, please", and for the compilers of that list to make it available to CKAN clients. If some of the compilers of those lists happen to do value judgements, well - that wasn't CKAN's fault.

The final thing that suggests itself to me is a way for CKAN contributors to add text to a mod name or description which is unhelpful - eg "its a texture replacer add on", or ISTR one or two mods in 0.90 land where homepage and github were N/A and the description told me nothing, which is not conducive to installing the mod.

[Dazpoet]

As for the third party suggestion CKAN does have some rudimentary plugin support which might be helpful in such an endevour.

Metadata maintainers aswell as anyone else who knows how to open an issue or, preferably, a PR can propose additions to both names and abstracts aswell as inject homepages and other resources into our metadata. Just head over to CKAN-meta and NetKAN repositories :)

[dewiniaid]

I think that some sort of category/tagging behavior should be standard, rather than third party -- but it should launch with a well-defined list of accepted categories. Said categories should never be mod-specific (there shouldn't be a FAR category for mods that 'support FAR', for instance), but should rather be broader categories that can give a very general overview about what a mod contains and adds to the game.

Here's what I think might be a comprehensive list (remembering that a mod can have multiple categories) -- note that my examples are not endorsements of any particular mods.

Mod type -- Each mod should ideally have at least one of these:

• plugin - Mods that directly add a plugin (any .DLL really), regardless of purpose.
• library - Mods that have no direct use to a player, but support other mods. See Firespitter, KSPAPIExtensions, KerboKatzUtilities, etc.
• physics - Mods that have a significant affect on the physics engine. FAR and DRE are the obvious mods here, but also things like KerbalJointReinforcement.
• part - Anything that has parts, really.
• config - For mods that don't add anything besides .cfg file(s) (e.g. for ModuleManager or tech trees). "Mechjeb And Engineer For All" and "StockPlugins" come to mind as likely candidates -- things like default and alternative configuration files for other mods may also apply (RSS's config patches for other mods, for instance).
• program - Anything executable that runs outside of KSP, if we decided to index these in CKAN.

Mod descriptors -- Each mod may have zero or more of these:

• information - Mods that provide extended information. Mechjeb, KER, VOID, Protractor, Thermal Monitor, Trajectories, etc., including editor-only information mods like RCS Balancer.
• control - Mods that add alternative methods of controlling crafts -- Mechjeb, Pilot Assistant, kOS, Telemachus, and PID Tuner all fall under this, as do the various mods that assist in docking (DPAI, Navball Docking Alignment, etc.)
• utility - General utility/quality-of-life mods: Editor Extensions, Filter Extensions, QuickGoto, KSP AVC, KAC
• graphics - Mods like ATM, EVE, Distant Object, Planetshine, Astronomer's Pack, TextureReplacer and its texture packs.
• sound - Mods like Chatterer, Atmospheric Sound Enhancement, QuickMute, MusicMute, and Water Sounds.
• unmanned - Mods that focus on unmanned gameplay. kOS, RemoteTech, BoxSat, and just about anything that adds probe cores.
• manned - Mods that focus on manned gameplay. The various colony- and station-building mods are all likely relevant here, as well as the various life support mods, as are things like RasterPropMonitor (probes don't have IVAs!) Note that simply happening to have a pod in a parts pack isn't necessarily "focused on manned gameplay", though mods that focus on replica or stock-alike parts for manned spacecraft probably are (any spaceshuttle mod, K2 Command Pod).
• science - Mods that add new ways to collect or use science. In general, science mods aren't very useful in a sandbox game (save for cosmetic value), though things like Scansat may be exceptions here. Scansat, Banana For Scale, ScienceAlert, Station Science are all candidates here.
• technology - Mods that extend or overhaul the tech tree in a significant way. I'm not entirely certain if this should be combined with the 'science' category; I mention it separately for purposes of the discussion
• career - Mods primarily of interest in a career save that aren't particularly relevant to a science or sandbox player. The various Contract Packs and mods that filter contracts all apply here, as do mods that add new strategies.
• resources - Mods focused on ISRU and resource management.

Part descriptions: A bit more specific

Loose indications of what kinds of parts a particular part mod adds. wings, wheels, engines, fuel tanks, power, structural, etc. Actually, this can almost mirror the default VAB categories. Or we can ditch it and rely on people to actually write coherent descriptions.

[khr15714n]

Please add the closed "Hide" mods from the list.
Right now I see 849 compatible mods. Guess what, I won't add all but I'll frequently check the list again. I check the forum, read the description by the author aso and I may decide, that I don't want to use this mod within the foreseeable future. And I would really like to mark it as "not interested in" to prevent it from showing up. You won't remember 800+ mod names each time and thus you'll waste your time checking the same mod again and again. All shows 1671, just to say.

Another approach, also mentioned before in another thread, let the user mark each mod with stars for instance from +3 to -3. Save his preferences in the local CKAN-folder. A list containing just a string (name of mod) and an integer (stars). Simple but very helpful for users and the column (in CKAN) would be narrow. Plus a few lines for the filter (stars).

[mheguy]

Simple but very helpful for users.

Pull requests are always welcome. Especially for simple issues.

[politas]

A "Hide" or personal "rating" feature is a purely client-based thing, unlike the Categories mentioned above, so it can be implemented in the client as additional data without worrying about spec/schema changes.

[khr15714n]

I should add that I've taken a break on KSP for a good while, just as I do with other great games I love.
While I respect those who manage to create all those weapons aso for their creativity (in creating the mods, not for their usage ;)) I simply have no interest in these kind of mods at all. Without any categorizing by any contributor - tags would be a nice thing but someone would have to invest continuously time and effort to keep them up to date - no one, not even the mod authors, would be affected by the individual filtering by users for their own convenience.

CKAN, as far as I know, doesn't judge any mod. It offers both sides, authors and users, a simple way to get "customers" aka users respectively the mods user want without time consuming efforts. Add-on Releases list nearly 2700 threads ... 50% are a year old, 25% less than 90 days. You can't read everything, no way. I'm pretty sure I miss some really good stuff because someone doesn't want to be listed on CKAN - for whatever reason. They probably lost a whole bunch of thankful users. So thanks to all who keep CKAN alive and make it a really good place to get what I want. Thank you.

[smattiso]

"Tags" will be added to the CKAN spec and schema as per v1.24, pursuant to pull request 2034.
At the time of this writing, discussion and development is underway in issue 2155.