Closed netkan-bot closed 8 years ago
Comment by mgsdk Friday Jan 30, 2015 at 11:44 GMT # Sample: Friday Sep 13, 2013 at 22:58 GMT
There are a few options for part selection already, though not all of them are equally user friendly. There is AutoPruner and then there is the plugin for the CKAN GUI.
I would love to have part management in the core of CKAN (as mentioned earlier)[https://github.com/KSP-CKAN/CKAN/issues/733]. I would extend the list to also include the core game as well (Squad and Nasamission), since I feel a lot of parts in those are superseded by parts in mod packs.
Comment by Ippo343 Friday Jan 30, 2015 at 17:01 GMT # Sample: Friday Sep 13, 2013 at 22:58 GMT
IMHO, part management doesn't really belong in the ckan core (remember that ckan also has some responsibilites towards modders: we want to guarantee them that their mod is installed as they instruct it to be installed).
I really like the idea of those "cutting sets" for the GUI part management plugin though, especially since it could open integration with KerbalX, which is the other big community repo and it's being completely ignored right now.
Comment by Sujimichi Saturday Jan 31, 2015 at 16:57 GMT # Sample: Friday Sep 13, 2013 at 22:58 GMT
I hadn't considered your point about responsibility toward the mod makers for correct installation, that's a good point. I thought you guys would already be considering part management, but I didn't know about the GUI part managment plugin. Yes that would be the more logical place for cutting sets. Do you think there could be a place for cutting-sets alongside your current plans for that?
I'm also very keen to get interaction between CKAN and KerbalX, so I'd put any action in that direction at the top of my to-dev list! (I'm pleased you'd call it "the other big community repo"! we are talking about the same KerbalX, right? ;) )
Comment by Ippo343 Thursday Feb 05, 2015 at 22:09 GMT # Sample: Friday Sep 13, 2013 at 22:58 GMT
Hey @Sujimichi , yes, KerbalX is the other big community repo :) I have a PR in place (#65) that implements pure metapackages with no files. It needs some more polish, but it already works.
A metapackage is just a normal ckan file with no download and a special flag - it will require a spec bump, but it can easily be generated procedurally by KerbalX already :)
As for cutting sets, as I said above, I think they are a neat idea, but I still think they don't belong in the core, only in the parts management plugin.
Comment by Sujimichi Thursday Feb 12, 2015 at 16:58 GMT # Sample: Friday Sep 13, 2013 at 22:58 GMT
Hi @Ippo343 sorry for slow reply.
If you can point me at a spec for a metapackage ckan file then I'll implement producing those on KerbalX.
I still need to have a look at the parts management plugin so I understand how it behavies (not had anytime for KSP things this last week), but it sounds like we're on a good path to making this work!
Comment by Ippo343 Thursday Feb 12, 2015 at 17:03 GMT # Sample: Friday Sep 13, 2013 at 22:58 GMT
I'll open a specific issue for that in a moment at KerbalX's repo, where it belongs :)
I just tried the part manager plugin, it doesn't seem to do anything. I see that it hasn't been updated since january, is it still compatible with the current CKAN?
TIL there's a part manager plug-in. :)
TJF, there actually is, it was created on Jan 9, but it doesn't seem to work. Here is what I just posted there: I installed the part manager using the "Add new" button on the CKAN Plugins page. Then I hit the Activate button.
Something happened, but I have no idea what. It starts showing a tab which says "Installed mods that contain parts", but nothing was listed.
I then tried to unload it, but the tab remained. It even remained after I restarted. I had to find where the dll was copied to (the Plugins directory) and delete it manually.
I'm not sure if this is a PartManager issue or a CKAN issue
I think most of nlights plugins lost compatibility somewhere around 1.6.5 or so, the way to uninstall them for sure is to remove the .dll from the plugins folder.
Something to consider (about the non-triviality aspect) is that it's not easy to determine what files are associated with each part. Sometimes parts have complex combinations of "MODEL { }" blocks in their configs, which may reference ".mu" models in multiple paths. Unless they also override the texture assignments in the config, the textures will be pulled based on what is specified in those ".mu" files. In turn, these textures and models may be shared amongst multiple parts. (SpaceY and FutelTanksPlus are great examples, since they share textures over multiple parts). What this means is that if you want to prune unused textures and .mu files to save memory, based on what parts the player doesn't want, then you have to consult both the ".mu" models and the part CFGs to see what's actually needed, not just one or the other.
Hi Paul,
I'm hoping you can answer a question or two about CKAN.
Specifically, I have a mod "CraftImport" which I'd like to integrate with Kerbalx. Kerbalx provides me with a list of mods that a craft file needs. I was going to have my mod call ckan to get a list of mods which are installed, and then to call ckan to install the missing mods.
Unfortunately, the System.Diagnostics.Process is blacklisted in KSP because it can be used for bad stuff.
So, I was wondering how difficult it would be (or maybe it's already doable) to create a class which I could include with my mod to do the checks and installs from inside KSP itself?
Since CKAN is written in Python, I'm thinking that I would need to use something like IronPython
or is this just too much to do? I don't want to bloat up KSP.
Alternatively, and maybe this would be a feature request, how about a way to have CKAN monitor a specified directory, and, if a .ckan file is dropped in there, to install it
Thanks in advance.
JBB
On 5/31/2015 9:36 AM, Paul Fenwick wrote:
TIL there's a part manager plug-in. :)
— Reply to this email directly or view it on GitHub https://github.com/KSP-CKAN/CKAN/issues/1035#issuecomment-107180978.
Since CKAN is written in Python
C#
So, I was wondering how difficult it would be (or maybe it's already doable) to create a class which I could include with my mod to do the checks and installs from inside KSP itself?
That's unrelated to CKAN managing parts. Create a new issue for that please.
Alternatively, and maybe this would be a feature request, how about a way to have CKAN monitor a specified directory, and, if a .ckan file is dropped in there, to install it
That's definitely a new feature and isn't related to CKAN managing parts. Create a new issue for that please.
I don't know anything about our plugin system, but maybe a plugin would give you the functionality you're looking for?
Managing parts installed by mods is beyond the scope of CKAN proper. Plugins can manage specific parts and there are tools completely independent of CKAN.
Issue by Sujimichi Thursday Jan 29, 2015 at 13:06 GMT # Sample: Friday Sep 13, 2013 at 22:58 GMT Originally opened as https://github.com/KSP-CKAN/CKAN-core/issues/62
Hi guys, I've recently started using CKAN and it's a great tool. I've also been talking to hakan on the ksp forums (I'm Katateochi btw) about displaying CKAN info on relevant pages on KerbalX and on a semi-related note, I have a suggestion. I appreciate it's not a trivial one and I hope you don't mind me posting this here, I thought it would be the best place for it.
Lots of mods users trim large mod packs to a few select parts to help with memory issues or just to de-clutter the editors. When it comes to re-installing or updating mods going through and re-doing your custom selections is a major pain. It would be extremely useful if CKAN could not only manage which mods where installed, but could also manage which parts where installed too.
That's the basic idea, but what I'm really thinking about is extending that idea to have config files (lets call them "cutting orders") that can define mods and parts to install. These config files can be exported and imported into the CKAN tool as both a way of transferring your mod setup to another install but also as a way of sharing mod setups between users. Lets say I've got a custom NovaPunch and KWRocketry setup, I can then ask CKAN to export a config for one or both of those mods and I can then share that config with someone else. They then put it into a folder in KSP (along side any existing cutting orders they have) and CKAN will then get them those mods and install the specified parts. So it makes it very easy for two people to set their games up in the same way (great for multi-player or forum challenges).
The cutting-order config files can contain info for 1 or more mods and are basically human editable text files that list parts in a simple format ie mod_name:part_name. The key thing about them is they are stackable. So you can put more than one cutting-order in and CKAN will get the full set of parts described by all the cutting orders combined. So for example I could have a cutting order that defined which parts from Nova and KW I have installed and I could give that to a friend who also has a cutting order that defines his pick of parts from B9 and KW. CKAN would look at both and install the parts that both cutting-orders combined describe.
Right, the final stage of the idea; Cutting orders for craft. As a cutting-order is just a list of parts (mod_name:part_name) then KerbalX could generate CKAN cutting orders for craft. When a user downloads a craft they can also download it's CKAN cutting-order and then CKAN will get them whatever additional parts they need for that craft.
With something along these lines we (CKAN and KerbalX) could really make it a total no-brainer for users to share modded craft. Users just share craft files and CKAN cutting orders and between CKAN and KerbalX we take care of sorting out which mods they need and setting it all up for them.
Let me know what you think!
Summary of main points
.ckan
text files to be placed in there..ckan
files in that folder will be used to instruct CKAN to install additional mods/parts to the ones the user has already selected..ckan
file is a list of parts (each part on a new line) in the formatmod_name:part_name
(it is therefore easily human editable) *1.ckan
file can also have an entry ofmod_name:all_parts
.ckan
file is not mod specific, it just deals with parts so it can define parts for several mods or just one.ckan
cutting order files are only inclusive not exclusive. They only list parts to add to an install, never specify parts to exclude. That way there are no conflcts, just some parts might be specified multiple times (which isn't a problem)..ckan
files from the interface and will promt the user to select which of their installed mods to include in the file.(The .ckan extension, the term cutting_orders etc are just place-holder terms, they could be called something else) *1 instead of having each part listed as
mod_name:part_name
it could have an indented syntax eg;I've not really considered mod versions in this so far. But I think that could be an optional specification to include in the cutting order file. something like this;
So mod1 has to be fetched at version 0.5.2, mod2 to can be any verion after or equal to 0.3.0 and mod3 is to be fetched at the latest version (and with all parts). There may be conficts if two cutting orders both specify the same mod but at different versions, but it could either ask the user for resolution or just use the most current.