discussion Discussion - Community Category Kit

[RoverDude]

Ok, I will sort a repo today, and add @JPLRepo, @Nils277, and @IgorZ for starters.  We can start with Containers and Life Support for the first two categories, and add on as we get quorum.

[Nils277]

Sound like a plan!

[RoverDude]

I should be able to hunt down your github IDs

[steedcrugeon]

This may be a silly question but I'd though I'd ask; with things like DERP would that be more at home with Command, Life Support, or Utility (along with the safety apparatus like 'chutes and inflatables)? its a fairly unique part but it'd be nice to give it a home suited to it's function.

[RoverDude]

Depends - I try to use stock categories where possible (i.e. the DERP is a pod, etc.). as folks mix and match things a lot.

[Nils277]

I agree that most of the parts are best kept in existing categories where applicable and only parts that are designed to be used for a specific and unique function should have their own category.

[Kobymaru]

Just a side note:

If I understand correctly, some people *do* want the Mod-Basket approach. However, I think that it's much better to add the Manufacturer to the part, so that players can use the in-game filters to find the parts they need (I believe that that's how SQUAD intended it?).

For example, it seems that when I look through the Manufacturers option in the part filters, only the FTT parts show up under "Umbra Space Industries" manufacturer. Maybe the rest of the parts should end up there too?

Anyway, the point is that if people want "Mod-Basket" categories, they can use the manufacturer filter.

Edited October 13, 2016 by Kobymaru
There it is

[RoverDude]

@Kobymaru - no reason folks can't just use both.

@IgorZ , @JPLRepo, and @Nils277 - you all have collaborator access.

Most of the stuff is just convention based, the biggie is I decided to use tags (preceded by cck) to identify parts.  No need to waste the overhead of a part module for this, and we don't want to break saves by changing names, or force conventions in manufacturers.

I just have life support in there for now, and have to sort out some CKAN metadata (yay).  But by all means poke about, see what I missed, etc.

@IgorZ - feel free to add a 'Container' category for KIS containers

[IgorZ]

How do we decide if new category needs to be introduced in CCK? E.g. for KIS I'd add one extra category "Tools" to store wrenches and EVA canister. And I have in mind at least one more mod that may benefit of it - Surface Experiment Pack by @AlbertKermin.

 

[RoverDude]

IMO a good rule of thumb should be something that at least two modders want to share.  So I will still have some not here, as I expect a lot of others will, but it will cover the bits where we overlap.

[neamerjell]

Categories I want in addition to sort by individual mod, not just mod author / manufacturer

Engines with subcategories

• Jet / air breathing engines
• LFO engines
• SRB engines
• Karbonite Engines
• Ion Engines
• Nuclear engines

Fuel tanks with subcats

• just liquid fuel tanks (jet fuel)
• LFO tanks
• Monoprop tanks (RCS)
• Hydrogen (? what the ion engines use)
• Karbonite tanks

Command pods subcats

• manned (kerbaled?)
• unmanned / probe cores

electrical subcats

• batteries
• solar panels
• fuel cells
• generators / RTGs
• lights

Air plane parts subcats

• wings
• control surfaces
• nose cones
• intakes
• parachutes / airbrakes

wheels and landing gear subcats

• rover wheels
• air craft landing gear
• space craft landing legs

modular building subcats

• decouplers
• docking ports
• struts

Basically, Filter Extensions default categories with some tweaks because it doesn't catch and sort everything

[IgorZ]

I've figured out that better place for KIS containers would be stock category "payload". In fact, many KIS compatible containers are already there. That said, having another "Containers" in CCK may be more confusing for the players.

Though, a new "Tools" or "EVA tools" may be a good idea. What makes me concerned here is that people without CCK (those who didn't install it) won't see the category, and the items in it are not normally visible in the other categories. I have two ideas in my mind to solve it:

1. In CCK implement a verification logic when adding a category. If category with the exactly same name already exists then CCK will just re-use it. This way a mod (e.g. KIS) creates own category with the CCK compatible name, and it's got reused by CCK. Unfortunately, we cannot setup order of loading of the mods, so both the mod and CCK must implement verification logic.
2. Find a way to "pull out " parts from the other categories. I.e. when CCK loads it removes all CCK controlled parts forth the other categories. This way any mod that has own very specific items will put them in some more or less acceptable category. Once CCK is loaded the community category is created and the parts are moved there.

[DStaal]

8 hours ago, neamerjell said:

Basically, Filter Extensions default categories with some tweaks because it doesn't catch and sort everything

I was going to say, from that list you just want Filter Extensions and some personal configs.  I don't think that has much overlap with this discussion: This is about common categories that multiple mods would add to, not a complete re-do of the category collection.  If you want the later, there's already FE, and it's very configurable.

---

On the actual topic - Categories that I think would be useful are 'Rovers' - RoverDude's already got several that would go well, and if @Angel-125 and @MichaelV2.0  could be persuaded to add their rovers in too, you'd have a decent set.  Those are the most useful rovers I've seen, but there are several others as well.  Also in that category it'd be nice to have things like @theSpeare 's RoverScience parts.

The other two main ones I'd see as useful are 'Bases' and 'Stations', for stationary surface and space structures, respectively.  MKS and KPBS are the obvious contenders in that, with Pathfinder and MOLE having parts as well - and things like @Thrimm's Planetary Domes parts.

A question does become how many ways do you want to slice things though.  For instance, another good category would be EL launchpads - MKS and MOLE have their own, as well as EL itself, and @Eleusis La Arwall's Keridian Dynamics - but most of those would also go in 'Bases' or 'Stations'.  Would you want to duplicate them?  Or have them in only one?  (And some parts like MKS's new line are designed for either bases or stations.  Is it better to be combined?)

Anyway, just a user's perspective.  I like the idea, and look forward to where you're going with it.  I run FE, and still make heavy use of the different manufacturer tabs - or using FE's ability to show parts grouped by 'manufacturer' (folder in GameData).

[RoverDude]

Thanks for the discussions

To be honest, I don't see this adding very many categories at all - we all have our unique ones in our mods (or prefer the category-per-mod approach).  It's specific sweet spot is handling those few cases where there's a direct conflict (i.e. 'Life Support' - which started the conversation).

@neamerjell - I would agree you probably want something other than CCK for that kind of list, like FE, etc.

@IgorZ - IMO if you feel the stock payload category makes sense, stick with that - tho I saw that more as 'parts that contain other parts' like cargo bays, cargo trusses, etc. - I already have a Logistics category for the USI stuff... which is where I stick my KIS bits.  I am wondering if Containers makes sense as a catch-all for 'boxes for stuff that doesn't make things fly' - so leave fuel tanks, Karbonite tanks, etc. in the 'Fuel Tanks' bucket, with your KIS containers and other misc. resource containers in a new 'Containers' bucket.  

I also think implementing fallback would be a little tricky, and in a way breaks the concept a bit - i.e. I could already code to avoid KPBS life support from @Nils277 or vice versa - much easier to just either use a different category (if I felt that made sense), or take advantage of a new one with no code required.  i.e. similar to CRP, where once you opt in it's bundled, you're not restricted to only what it provides, but you don't stomp over what it does.  One of the reasons I wanted to make sure folks who participate have collaborator access is to cover the odd case where CCK not being updated is impacting their ability to release a mod (i.e. I get hit by a bus on release day...)

@DStaal - I could see Rovers, Construction (which could cover EL parts as well as mods that support them), Bases, etc. as good candidates, but I think sticking to the concept that we add nothing till two modders determine there is need or value will go a very long way towards preventing bloat and clutter.

Oh.. and version 0.1.0 is up on GitHub and (assuming the metadata is good and CKAN reindexes) CKAN.

 

 

 

[Farix]

Beyond the addition of a life support category, other categories that I would find useful would be parachutes/airbreaks, lights, and crew cabins. Probably separate categories for solar panels and batteries outside the rest of the electrical parts for things like Near Future. I would also like to see probe cores separated form command pods.

[Eklykti]

Just saw it on CKAN, but it's listed there as 'Community Resource Pack'.

[RoverDude]

Already fixed - was a metadata typo

2 hours ago, Farix said:

Beyond the addition of a life support category, other categories that I would find useful would be parachutes/airbreaks, lights, and crew cabins. Probably separate categories for solar panels and batteries outside the rest of the electrical parts for things like Near Future. I would also like to see probe cores separated form command pods.

As soon as a couple of modders want to do this to resolve a conflict, we can do it   But remember the point is not to just add a bunch of categories, the point is to add the ones we need to avoid conflict.

[DStaal]

Understood.  Why I was trying to summon relevant modders to decide they needed to be a part of this. 

[Jiraiyah]

hmm i have a mixture of grouping system, some of the groups are for specific type of job to be done, for example, one group for satellite one for stations, sub groups for these are most likely stock like meaning i would have pods, antena, electrics etc.

the other section of grouping is related for developers with more than one mod, USI for example has it's own group, in these, each sub group is one mod, for example life support, Konstruction etc

the last one is a single group with many subgroups, this group is called mods, each sub group is one mod all by itself, and it has one subgroup names MISC for those mods with 1-3 parts (like mechjeb)

obviously, right now, i am using filter extensions for all of this

Edited October 16, 2016 by Jiraiyah

[Bombaatu]

@RoverDude - I'm assuming you're maintaining the CKAN file for this mod as you are doing for your others? FYI, this is showing up in CKAN as 'Community Resource Pack' instead of 'Community Category Kit'. Thought you should know.

[RoverDude]

I pushed a fix already

[Nils277]

Thanks for the work in this @RoverDude already added the tags to the KPBS parts and will include support in the next update.

Btw. using the tags for the categories is a nice idea and makes it even easier to implement. 

The only thing i'm not sure about is adding a version of CCK in the zip-file. Always tried to avoid adding additional mods in the download. How does Ckan handle this scenario when multiple mods ship the same additional mod? (May sound like a noob question I know ) 

 

[RoverDude]

CKAN handles it pretty reliably, tbh

[Alshain]

I don't have any part mods but I think this is a great idea.  Mods that just add a category for their mod kind of annoy me, it's filter by function, not by mod.  Unless the mod adds a new function of course.

 

Edited October 17, 2016 by Alshain

[Kobymaru]

 

26 minutes ago, Nils277 said:

How does Ckan handle this scenario when multiple mods ship the same additional mod? (May sound like a noob question I know ) 

You have to specify exactly which directories in your ZIP file should be installed to the users GameData. If you don't include CCK in that, but instead add it as a dependency then it should be fine.