Murdabenne

IIRC, CKAN bots index all of KerbalStuff - its set up wher that is actually the preferred source (it can also do github, and curseforge, although the latter is not all that automated for updates). But I think the initial metadata file needs to be set up by a person, which it was apparently, by one of the admins there - either because they use it themselves or someone requested it. But I would not be surprised if this was automated as well - if they are already indexing the site, automating the detection of new mods is probably a trivial item, and extracting the metadata and formatting in JSON would not be that hard for well designed and posted mods. - - - Updated - - - Go to their github site, look in the NETKAN section, and simply edit the file there to your liking and do a PR. I can do it for you if you like, Ive done that for a few mods to correct CKAN metadata problems on addons that I use. Nice thing is with the Netkan system they use, once its edited, it kicks in for all future versions and updates so you never need to bother it again, unless you change dependencies etc. - - - Updated - - - I made the change for you, here is my pull request to them https://github.com/KSP-CKAN/NetKAN/pull/2018

Have you considered taking the tanks out of the SpaceY and putting them here instead? This way SpaceY becomes engines, boosters and misc big hardware, and this becomes all the tanks. That way those that use something like ProceduralParts for tanks can get SpaceY for engines, drone cores, and so on without duplicating the tanks, and those who want the tanks only can do so without loading all the extra parts... Just wondering if a consolidation might make more sense (also add in the color coded tanks as an option to this mod as well, instead of a stand alone).

Actually CKAN can pull from github directly if you want it to - if there's a zip there they can get to it. I can look at this on Friday 31st if you like.

Is there a direct download link for this? Curse and curseforge are javascripts, and I like using my download manager, which javascript things like that circumvent.

hab136, I tried some of those configs last night, and the one that creates a new part from another one (fuel tank for instance), it doesn't do anything, there is no Davon menu at all on the part - I even put it into orbit, nothing there.

... and this, folks, is why you use a "libre" type license. It means your users dont get screwed when you decide to stop playing the game or developing the mod. Anyone here ever plans to do an app, please choose your license carefully, and consider the reality that eventually you will likely get tired of working on it long before your users get tired of using it, so if you use a tightly controlled license that isnt for adaptation or sharing, then be sure to re-license it accordingly once you stop.

Great post - this belongs on the front page in the second post if there were a way to do it. Here, have some rep. FYI - I didn't know you could add a part via ModuleManager! Amazing tool

Any update on the error where PR leaves unattachable nodes floating in mod air, even after the fairing is deleted?

hmm, could I stick the big bin to the side of a station module, in orbit, and send my magnet tug around to get parts from the debris in orbit (especially old rescue capsule hulks, booster tanks that are too small to bother reusing)? What about old smaller mostly complete ships I have parked because I didn't want waste the fuel to have my tug de orbit them?

I think I figured a lot of this out - except for: how can I use a different skin? I'd rather this look like a fuel tank (choose the skin, like one of the ones from Procedural Parts tanks) instead of the current appearance, or else gut a part already in use (MKS logistics part for instance) for just the model, and use this functionality instead - this way I keep the appearance of my station how I want it, but gain Davon to relieve me of the repeated resupply trips.

Do you guys mean How should CKAN handle forced install ? Thats the link to the discussion started a month ago on it on github. There has been a bit of talk on irc as well. Its a bit more complex than many may realize, because it affects authors a lot. Basically if someone gets bugs that exist because they installed an unverified version against a new KSP version, and it fails, and they go posting to the author's thread "installed via CKAN", then the fault is usually laid on CKAN for cluttering up the author's thread and taking their time chasing a bug in code that should not have been installed anyway (sometimes justified, sometimes not). This is what the CKAN crew is trying to balance, among many other things. And yes, some mod authors have snits about CKAN, but those are generally not done in public. What they run into is dependencies and/or interference between mods: this is an issue -and a complex one - of which part of it is handled by CKAN in their metadata to help keep the end users informed of such issues (and prevent them when practical). So yeah, they are hashing out a solution, but feel free to contribute.

Uninstalled and reinstalled all addond. That seems to have fixed the gap issue, but I still get the stray graphical nodes floating around.

I looked back several pages and didnt see this addressed (did i miss it?): is there a bug that causes the fairings to not cover properly? Basically, they leave gaps vertically between them , If I set it for 2 I get 2 gaps between my 2 fairing pars which are about 160 degrees wide, not 180 each, leabing a 40 degree gap on both sides. Similar when I do it for 4- the gaps narrow but are there vertiacally between the fairing parts. What causes that - do I have something set wrong? I've uninstalled and resinstalled the mod, doesnt seem to help. The stock fairings dont do this but they are butt ugly and hard to use, but they do work if I remove this. I tried reducing and increasing the number of nodes, no change in the behavioir, although when I reduced it to one node, that one node covered exactly HALF of what it was supposed to. Ive even tried making this as simple as possible: Mk1 capsule, fairing base ring, 2 nodes (visible onthe next to last screen shot). The sides still have a big gap between them on both edges. Its as if the fairings are only covering 60% of the space they should. "Parts Shielded" = 0 no matter how I change things. Tried changing symmetry, that didnt work. Are there any mods that may produce this kind of defect in procedural fairings? truncated logs for the problem [LOG 19:05:44.839] PilotRSASFix.Start(): v00.02 [LOG 19:05:44.840] [sCANsat] start: in editor [LOG 19:05:44.841] [sCANsat] sensorType: 0 fov: 0 min_alt: 0 max_alt: 0 best_alt: 0 power: 0.05 [LOG 19:06:03.600] HeatShield1 added to ship - part count: 2 [LOG 19:06:03.601] SAFix.onPartAttach(): Host = HeatShield1 | Target = mk1pod | Symmetry Count = 0 [LOG 19:06:22.932] stackDecoupler added to ship - part count: 3 [LOG 19:06:22.933] SAFix.onPartAttach(): Host = stackDecoupler | Target = HeatShield1 | Symmetry Count = 0 [LOG 19:06:48.111] KzResizableFairingBaseRing added to ship - part count: 4 [LOG 19:06:48.112] SAFix.onPartAttach(): Host = KzResizableFairingBaseRing | Target = stackDecoupler | Symmetry Count = 0 [LOG 19:06:48.112] SAFix.onPartAttach(): 1x symmetry in VAB detected. Radial symmetry set. [LOG 19:06:55.907] KzProcFairingSide2 added to ship - part count: 5 [LOG 19:06:55.908] SAFix.onPartAttach(): Host = KzProcFairingSide2 | Target = KzResizableFairingBaseRing | Symmetry Count = 0 [LOG 19:06:55.909] SAFix.onPartAttach(): 1x symmetry in VAB detected. Radial symmetry set. [LOG 19:07:03.117] KzProcFairingSide2 added to ship - part count: 6 PilotRSASFix.Start(): v00.02 (Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) [sCANsat] start: in editor (Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) [sCANsat] sensorType: 0 fov: 0 min_alt: 0 max_alt: 0 best_alt: 0 power: 0.05 (Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) HeatShield1 added to ship - part count: 2 (Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) SAFix.onPartAttach(): Host = HeatShield1 | Target = mk1pod | Symmetry Count = 0 (Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) stackDecoupler added to ship - part count: 3 (Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) SAFix.onPartAttach(): Host = stackDecoupler | Target = HeatShield1 | Symmetry Count = 0 (Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) KzResizableFairingBaseRing added to ship - part count: 4 (Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) SAFix.onPartAttach(): Host = KzResizableFairingBaseRing | Target = stackDecoupler | Symmetry Count = 0 (Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) SAFix.onPartAttach(): 1x symmetry in VAB detected. Radial symmetry set. (Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) KzProcFairingSide2 added to ship - part count: 5 (Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) SAFix.onPartAttach(): Host = KzProcFairingSide2 | Target = KzResizableFairingBaseRing | Symmetry Count = 0 (Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) SAFix.onPartAttach(): 1x symmetry in VAB detected. Radial symmetry set. (Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) KzProcFairingSide2 added to ship - part count: 6 (Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) SAFix.onPartAttach(): Host = KzProcFairingSide2 | Target = KzResizableFairingBaseRing | Symmetry Count = 0 (Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) SAFix.onPartAttach(): 1x symmetry in VAB detected. Radial symmetry set. (Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) Also here are screen shots - note that as soon as I add the base ring, I get a stray extra "node" hanging off to the side - the further I am zoomed out the further away the spurious fake node is. And it is not clickable, nor does it go away when I delete the part, as seen in the screen shots - as well as a 2 node fairing on both bases showing gaps.

Looks that way to me. No more "When will this be on CKAN" for your regular updates.

I dont think this has the maths in this for FAR just yet, only stock?

1.5.1 was automatically picked up by CKAN when you updated. It worked!

Increasing line count for one liners does increase readability - please stay on your original context and topic - raising things not asked or in context does not help your case. One liners that are dense need to be cleaned up for readability if you want to have maintainability. Sufficiently spreading out the density of the symbols can ease reading for comprehension in something as potentially cryptic as heavily punctuated (symbols) code. Prime example of this is lisp and its parentheses. Or APL (a solid language for parallelism ahead of its time) whose primary issue was density and readability. Or, less computer related, mathematics proofs (especially modern algebra if you've had a course in that). Experience, and basic software engineering competency both reinforce this concept. So, if you intend anyone other than yourself to see it, make a concession for legibility for others who may not see it the way you do. And if you believe even remotely that you might have to come back to it, cold, in 6 months or 2 years, make a concession to maintainability for yourself - or better yet, for others. Expand the one-liners out to acceptable format you see in most places for that code - common courtesy goes a long way. And with that, Im done responding to the "retract" demand. Sorry for the diversion.

Ah. Well they are just ribbons to me, not flags. Some of them resemble actual military decorations

Thank you - perfect answer.

This is as close to perfect as I and many others need. This is the right size, early enough in the tech tree, the parts all work together well (capsule, nose, heat shield, seperator, monoprop tank, and the engine). it fills a niche perfectly - and its useful all the way through the end of the tech tree. This is my go-to for "evac pods", a spare command spot to build my tugs with, rescues (of course), and its light enough to be a return stage for landers. And it simply looks good - it looks right. This is my most used component of any parts mod I have downloaded. For the base parts (above) you dont need to change a thing! Add other parts as you see fit, but please leave the core as it is - no need to change anything about it other than updating it for game engine changes, and possibly altering the tank to be a true service module - mabye with monoprop core, and a couple hatches that would take advantage of KIS/KAS style crates - like Universal Storage does. But keep the look and the monoprop - and the attachable monoprop engine. Having several hundred delta-v attached and looking integrated comes in handy.

Try to use a shallower descent profile. start further out, use (-120, 0, 0) node if you are in a ~71km circular orbit (which is a darned fast orbit). Start the burn (~12 seconds retrograde with the monoprop engine) about 75-80 degrees clockwise from KSC to end up pretty close - jettison back end after the burn and enter with just the capsule, nose, and heat-shield. Go hands off after you set the capsuel to hold retrograde the whole way with torque and SCS (use RCs once you're in the flames if necessary and if you have much). The rest is just watching until parachute time. You should hit 60k altitude going about 2200 m/s. You'll see red (dynamic pressure 500pa) as you cross 50K at about 2250m/s. It will get a bit toasty at 45-35k but the speed bleeds off starting at 35K, and and the heat and speed drop rapidly between 30K (2000m/s) and 10K (700 m/s). By 1500-1200m altitude your speed should be about 225m/s, and you can pop the chute. Landing is a nice thump at 6-7 m/s.

What national flags? The only graphics this provides are the ribbons, or at least so I thought. The "flags" provided by the game are mission flags, which are space agencies and things like that. Some come from plugins. And those go on the spacecraft, not the kerbals. Is this perhaps in the wrong forum?

Thanks so much for this - the maths for the aero vs dragcubes vs unity vs KSP are not simple items - I am thankful for you folks who do handle this!

Readability enhances maintainability. Cryptiuc and dense one liners are part of the things that made perl known as a "write only" language.

I see this and CapCom mentioned a lot - what is the difference between the two? And why 2 mods instead of 1 with options? (just asking the latter out of curiosity)