politas

Ok. I'll put it in CKAN as 3-Clause for now, and if you want to change to the 2-clause licence, can you ping me?

When you say BSD for the licence, do you mean the original 4 clause version, the new 3-clause version, or the FreeBSD 2 clause?

Does it definitely require both KAS and KIS? Can it not function purely via VAB assembly? Needs manual attention to get into CKAN, which hasn't happened yet.

Ah, ok, then the CKAN config is stored in the Mono registry instead (~/.mono/registry). What does the CKAN title bar say is the location of your KSP install? Is it the newly downloaded KSP install? You can also have CKAN installed mods that are unavailable if you installed them on your Steam KSP and then KSP upgraded. @Brigadier will need to take out the unavailable mods from the "depends" list in their exported .ckan Take out the version number, so it's just "CRP". I believe that'll work.

Something odd is going on there, since you shouldn't be installing Realism Overhaul v10.6.0. The current version is 10.8.0 if the XX.craft files are the names that match RealismOverhaul, then it sounds like you may not be accessing the newly downloaded KSP installation. Check your CKAN title bar to see what it says the current directory is. Maybe you need to add a new KSP installation. CKAN stores its configuration in the Windows Registry, not local files, so just putting a ckan.exe in the new install directory won't guarantee that's the KSP install you're working on.

Not really, no. If you're having troubles with downloads timing out when downloading a set of mods, you can use the contents tab download button to pre-cache the files. But CKAN always gets its mod files from the source, to ensure integrity.

CKAN automatically installs dependencies, such as BD Armory in the case of your mod, and makes updating easy. There is also a substantial group of KSP mod users who use CKAN as a way of finding out about new mods rather than the forums.

The KerbalStuff automatic submission is very unreliable. I'm looking into this mod now. EDIT: Should be showing up in CKAN within the next couple of hours.

The Comprehensive Kerbal Archive Network, a mod management solution. You ticked the box for CKAN submission when you set up your mod on KerbalStuff.

Making a complete mirror of mod downloads is in the works, though obviously, it can only be done for mods with free licences. I don't know any details, though.

Cool. KerbalStuff's having some issues at the moment, so I'm being held up, but I'll get your mod added to CKAN soon.

Did you change the part name(s)?

Hi There @Kalzuron, This is an intriguing mod, I'm looking forward to playing with it a bit. I'm trying to fix up the CKAN submission from Kerbalstuff, and I suspect there's going to be an issue down the track due to your current release's version number "Mk2" not fitting at all with your previous releases (and I can't see where you're going to go next with the numbering). Can I suggest making it version 3, instead? Also, you have Firespitter's github repository in your "Source Code" field.

Maybe have a look at that mod I linked to and see how they do the parts to see how to not put the parts under the BDArmory Parts folder? As far as getting the parts under the GameData folder, you can have basically the structure you have now (though maybe take out the superflous "AWP"), and change your install instructions to "unzip contents into the GameData directory". Easy as that.

Hi Patrick_the_Big, Just looking at the CKAN submission for this mod, and I can't figure out exactly what you mean with your installation instructions. You say: 3. Copy contents inside GAMEDATA folder to the original BD armory PARTS folder. -=DO NOT PUT IN GAMEDATA=- But your zip file contains no GAMEDATA folder (or even a GameData folder) I am not sure whether what is needed is for all folders below AWP/AWP/Parts to be installed to the Bahamuto Dynamics Parts folder, or whether the entire structure below the first AWP folder should go there. Are you planning on expanding the number of parts you are adding? It would make things much easier and cleaner for your users if your parts went in GameData/AWP/Parts/m230LaserGun, GameData/AWP/Parts/AWP/mk100Bomb, rather than getting mixed up with other parts, and I don't think you really need to bury your parts in the BDArmory directory. I also wonder whether people may be confused about the authorship of this mod due to the "BD" at the start of the name, but I have little experience with the group of KSP players who mess about with these weapons mods. None of the other BD Armory expansion mods seem to be doing that, though. (See http://forum.kerbalspaceprogram.com/index.php?/topic/118521-wip105-nas-naval-artillery-system-0351-bdarmory-addon-devastation-from-above-jan-2/&do=findComment&comment=2122808 for instance) EDIT: Oh, didn't notice before that these parts are generated by Bahamuto Dynamics That makes sense of the name. The folder structure is still going to cause some problems for CKAN if you intend to add more parts in the future.

I'd just like to thank @pjf for all the work he does on CKAN, and for adding me as a project contributor.

Righto - It's in the list of Pull Requests waiting for merging.

What if you delete the contents, rather than the actual folder? (Ideally, test by moving them somewhere else, of course)

Is there any problem with the game caused by not having the extra layer of directory? Fix submitted, anyway.

Other than doing a find for each mod name, I can't think of an easy way to delete old cached versions. You can force a download of a mod's latest version by going to the Contents tab and clicking on Download.

Would it be possible to have the RasterPropMonitor IVA be a ModuleManager config that :NEEDS[JSI] A file called something like RaptorAerospacial/Super100/S100_RPM.cfg containing this sort of thing: @PART[*]:HAS[@INTERNAL[IVA_S100]]:NEEDS[JSI]{ MODULE { name = RasterPropMonitorComputer } @INTERNAL { @name = IVA_S100RPM } } And then rename RaptorAerospacial/Spaces/IVA_S100 to RaptorAerospacial/Spaces/IVA_S100RPM (and match up the files under it, including changing the "name =" in the .cfg) and move RaptorAerospacial/StockIVA/Spaces/IVA_S100 to RaptorAerospacial/Spaces/IVA_S100

Mutually exclusive configs is exactly what a virtual config dependency lets you do. CKAN deleting things it didn't install is a hotly-debated topic. The current position is that CKAN will only delete files it installed, so that generated config files will be left untouched by an update. Mod authors can include an empty file in their download and then modify that if they want CKAN to delete it on upgrading.

Have a look at Distant Object Enhancement. There is the basic "Distant Object Enhancement" mod, there is a "Distant Object Enhancement default config" mod, which meets the virtual dependency "DistantObject-config" that can also be met by "Distant Object Enhancement Real Solar System". That's the system that's been developed to handle the situation you describe.

What's the actual name and/or identifier of that mod as shown in CKAN? I can't find anything with the name you mentioned.