Bombaatu

@Angel-125 - I just had a idea you might be interested in: a Ponderosa or Casa configuration called "Veranda" that could function as a Cupola with regards to habitation multiplier, as well as fulfill the Bases contracts "have a cupola" requirement. The model might have transparent or reflective panels whereas the Ponderosa Habitat configuration has opaque panels. Thoughts?

I really haven't had a chance to play with this mod yet (been having too much fun with MOLE! :D) but was wondering: If you have "require resources to reconfigure" check, then you have to have Equipment to inflate these modules. Is any Equipment reclaimed when you deflate them? If the Equipment represents furniture, storage and other things you'd need, I would think they could be broken back down. There would be a loss involved - maybe you'd only get back 50 to 75%. Is this currently in the mod, or has it been considered?

Don't know if this is a known issue or not, but the DMagic contracts (magnetic field survey, etc) do not recognize the Coatl parts as their DMagic counterpart. For example, if the ship needs to have a magnetometer boom or RPS antenna, the Coatl version of these instruments will not fulfill the requirement; only the DMagic part will. However, the contract does recognize the experiments being run (RPS antenna reading from Low Orbit, etc)

Is there a fix, perchance?

I have an odd problem with city lights on the Mun. Is this a known issue? If not, I'll add screen shots, logs, etc.

This one:

Capcom doesn't appear to work; there's no button in any toolbar.

KAC has been fixed.

I grabbed the latest version of this but KSP-AVC still reports it is for version 1.1.2. This was a manual install with no other mods but KSP-AVC.

I started this thread to get information because I am a new-comer to this community and genuinely did not know. However, this 'discussion' has become way too acrimonious and I'm out. If any moderator is reading this, please feel free to lock the thread. The original question has been answered & the thread's purpose has been served.

I have seen this claimed a number of times in this thread, but my understanding is that it's not true. Certainly the metadata can specify versions with dependencies - see https://github.com/KSP-CKAN/CKAN/blob/master/Spec.md#relationships - and I'm fairly sure the client respects them. Ah. My bad from making the assumption - that was the gist I was getting and have just recently ran into this very thing with version 0.7.4 of MOLE. Turns out CKAN did not update a dependency as it was supposed to.

One of the reasons I like CKAN as a user is that I can see newly-added mods that I might have otherwise missed. Threads move so rapidly on the forums that it is easy to miss something. However, I fully understand the mod-makers' frustration with it; the tool is incomplete in that it does not do dependency version checking, and allows anyone to edit the metadata files which results in a support nightmare. I see a solution along these lines: A stand-alone product, in that you do not have to run KSP to get a report of updates Well-documented metadata requirements (I have not viewed CKAN's so this is not a condemnation) Opt-in only - of course, this would require the mod makers' support Only the mod-maker OR THEIR DESIGNATED AGENT(S) can edit the meta-data. This could help with the point above, allowing the mod maker's work to be on the new platform but freeing them of much of the onus of maintaining metadata. This would also eliminate the 'random-person-on-internet' issue. The metadata should track dependency versioning. In the case of a version conflict, notify the user

FYI, with the release of KSP 1.1.3, KAC now spams the log with errors: Please let me know if you need further information.

Thank you all; the question has been answered.

No, I can get around it; was just curious.

I have heard 'CKAN is the best thing since sliced bread' and 'CKAN is bad-wrong! Do-not-use!' (these are paraphrases, of course). I have used it and have not personally run into any issues. For those who believe it is bad - why? I have yet to see a coherent explanation of this.

I *LOVE* this pod but have one usage issue. I cannot for the life of me locate maneuver planning in the MFDs - circularize, Hohmann trasfer to target, etc. I have MechJeb installed & MOARdV has said that RPM does support it. Have these features been enabled in this pod?

It was the Mk1-2 Pod replacement by alexustas: I'll post over there; thanks.

I was playing around withe autopilot panel (which I assume required mechjeb?) and could see things like setting prograde, target relative velocity +, etc. but could not access a "maneuver planning" portion - circularize, hohmann transfer to target, change apoapsis, etc. Are there any plans to allow access to these in RPM if MechJeb is installed?

Yes. The same thing occurs with the Mk1-2 iva replacement

Just out of curiosity, have you ever considered releasing the science experiments and antennas as a stand-alone mod? I love the extra science but the tanks and engines leave me a bit confused and clutter up their respective categories. Yes, I know, I can delete the part files - was just wondering if you had ever thought of this.

Sorry - don't know if this is a known issue or not. I installed this mod & tried to attach a Terrier engine to a 1.25 meter fuel tank. The tankbutt was 2.5 meter. Is there a setting that makes the tankbutt automatically conform to the size of the part it is attached to? If so, will it conform to non-standard sizes (like the 1.875 meter size used by Mark One Laboratory Extensions)?

Ummm.... how does one actually *use* the JetWing? I can't equip it or attach it to a Kerbal.

And There Was Much Rejoicing! (yaaay!)

I know it's not yet "officially" updated for 1.1.2, but does it function with that version?