plague006

Speedup sounds like a great option. Pitch speed sounds like a great tweakable setting as I've had rockets "fall over" during early-game launches. For locking and defaults I'd like to see the 2 separated. That is, if I want my default AP to be 75 but a particular launch is 120, I don't want the 120 carried to the next new craft. Similarly if for a given flight I had 6-7 parameters locked for any given reason, I don't want them locked on my next new craft. A "setup" specifically for defaults would be what I'd like to see where I can set whatever defaults I want *and* choose whether I want them locked or not. For example I might like a default start m/s of 50 but don't want it locked if "improve guess" has a better value. Similarly if I want everything in an 85km orbit I *do* want that locked on every new craft at launch. Just my 2 cents, love the mod. Way more efficient launches than I've ever been able to achieve.

I ran a couple more tests. The minimal mod combination with which I was able to generate the exception was: AmpYear+ContractConfigurator+ModuleManager+InterstellarFuelSwitch. THe lower mod count should make the log easier to parse. Log (exception on line 3721): https://gist.github.com/plague006/5667889c8d65a59460dd27e7c11ba1b7 So ultimately Toolbar is not a factor. I apologize for that confusion as I didn't anticipate multiple mods in my pack generating multiple exceptions with multiple reasons. (In hindsight something like this *should* be expected with a new version of KSP released). Edit: I should further clarify that the stock toolbar button functions. I'm not sure exactly what is broken (if anything) as I don't know AY well enough. Sorry overall for the subpar report, a lot of confusion was generated due to me "lumping in" AY with the other mod issues I was having. I got lazy after spending 3 days narrowing down the source of my issues (I really just want to play, I haven't played long enough to reach the Mun since KSP 0.90).

You're correct about MM that was totally my error. You're incorrect about the version of AY installed. I think you might have been looking at AVC's output (which reads the .version file which is in error). Line 230 of either log shows the version of AY. In the interest of thoroughness I downloaded a fresh copy of AY 1.4.1 and ran a checksum on both, only the config file and miniavc.xml were not identical (as one would expect). Further in the interest of thoroughness I removed the errant version of ModuleManager and re-installed CC. The issue persisted. Link to the full log: https://gist.github.com/plague006/a91ae4ce79e3944e0218d35b5331d2b2 and the excerpt relevant to AY (lines 19543-19551):

In the "with CC log file" log lines 19790-19809 are the error for TAC Fuel Balancer and 19998-20006 for AY. It looks like the error with AY is different from the error the other mods gave and is related to the KSPIEWrapper. I hadn't noticed that initially.

I'll happily provide relevant snippets I gave Nightingale in https://github.com/jrossignol/ContractConfigurator/issues/586: Contract Configurator seems to create issues for other mods and their interactions with toolbars. Namely several mods' buttons are absent from the toolbars (both stock and blizzy) and some mods' UIs are adversely affected. Image showing when CC is installed: http://puu.sh/rOoF5/b482f8e1ab.jpg Image showing when CC is not installed: http://puu.sh/rOp2A/860a50e79b.jpg Exceptions thrown when CC is installed seem to all be `NotSupportedException: The invoked member is not supported in a dynamic module.` and come from multiple mods including but not limited to: USITools, Kolonization, DockingPortAlignmentIndicator, Tac.FuelBalanceController, HotSpot, PartCommander, AmpYear. Full logs attached of both with and without CC installed. Log without CC: https://gist.github.com/plague006/9fa43d8ad759d11e0c8c2cda13a5a16b Log with CC installed: https://gist.github.com/plague006/7f7a637a82c6d65f36333171e6a0868b ---- I was under the impression you hadn't made the change yet as I saw the errant code in your GitHub repo's master (https://github.com/JPLRepo/AmpYear/blob/master/ToolBarManager.cs#L809) and dev branches both (https://github.com/JPLRepo/AmpYear/blob/Dev/ToolBarManager.cs#L809). But I don't know your workflow or much about modding so I must have been in error.

Ran into an issue between AY and Contract Configurator due to a bug in the toolbar reflection wrapper. Info on how to resolve the issue here: http://forum.kerbalspaceprogram.com/index.php?/topic/55420-120-toolbar-1713-common-api-for-draggableresizable-buttons-toolbar/&page=55#comment-2770188

Ran into an issue between your mod and Contract Configurator due to a bug in the toolbar reflection wrapper. Info on how to resolve the issue here: http://forum.kerbalspaceprogram.com/index.php?/topic/55420-120-toolbar-1713-common-api-for-draggableresizable-buttons-toolbar/&page=55#comment-2770188

Ran into an issue between DPAI and Contract Configurator due to a bug in the toolbar reflection wrapper. Info on how to resolve the issue here: http://forum.kerbalspaceprogram.com/index.php?/topic/55420-120-toolbar-1713-common-api-for-draggableresizable-buttons-toolbar/&page=55#comment-2770188

Ran into an issue between your mod and Contract Configurator due to a bug in the toolbar reflection wrapper. Info on how to resolve the issue here: http://forum.kerbalspaceprogram.com/index.php?/topic/55420-120-toolbar-1713-common-api-for-draggableresizable-buttons-toolbar/&page=55#comment-2770188

I submitted a PR to CKAN that, once merged, will ease reports of this issue from CKAN users. Specifically, versions 4.1 of LTech and 1.4.3 of MC2 will be marked as conflicts with KEI. My hope is the issues are resolved in their next releases. If the issues persists with the next release of either mod I would suggest opening an issue with CKAN so they can be marked as conflicts until the issue is properly resolved.

Due to the empty .zip you've uploaded CKAN has to temporarily disable automatic indexing of new releases of your mod. Whenever you release a new version of the mod please open an issue on our github or post in our thread so we can resume. This will have no effect on existing versions of the mod being indexed in CKAN.

Currently your .cfg is named CTTPatch.cfg. Since it installs to CTT it might be best to name it something like VSPRPatch.cfg so that it's more clear which mod this patch is for.

As a heads up, the "Mod website" link on spacedock is broken. You just need to add a character after the dash to make it valid. Ex. http://forum.kerbalspaceprogram.com/index.php?/topic/108797-A

Not sure why I was mentioned..

I'm looking for clarification on the mod's license. In the OP it's listed as ARR but the spacedock page and the file inside the .zip indicate CC-BY-NC-SA-4.0.

I can probably clear some things up. Before anything else I'm sorry our users are bugging you directly. CKAN users should be bugging CKAN for all CKAN-related issues. It's a message we've wholly failed to get across. Modders determine their own level of involvement in how CKAN manages their metadata. Some write their own metadata and CKAN only references it, some simply ping us when something is wrong and some don't even know CKAN indexes their mod. @Tekener is half-correct: CKAN does indeed read the .version file in a given mod's zip. In the case of your mod you use a remote .version file so CKAN will prioritize that info over the local file (but only if the version of the mod in the remote version file matches the mod version). The issue arose because the spacedock release was delayed. Within seconds of 2.1.1 hitting the spacedock server it was on CKAN. Would it be best for us to target your github releases? Just read a quote from you " Github is the master, spacedock the mirror." So we'll be changing where we pull releases to GitHub. As for documentation for CKAN a decent primer might be https://github.com/KSP-CKAN/CKAN/wiki/Adding-a-mod-to-the-CKAN

Thanks for the quick reply.

In the course of indexing this to CKAN I ran into a few question marks: The readme indicates that this mod redistributes Klockheed_Martian_Gimbal but I didn't notice it in the .zip. The spacedock page indicates the license for this mod is GPL-3 but the OP in this thread and the readme indicate that it's CC-BY-NC-SA-4.0. We currently index Mk2Expansion and it suggests users install FAR alongside it. Should we do the same for Mk3?

I scaled the image to match the height of KSPedia entries because I'm not a fan of scrolling images. Alternatively you could scale it to the width and scroll. The dimensions of a KSPedia page are 2048(W) x 1536(H) (scaled down in-game of course).

Amazing and easy-to-follow tutorial even for someone like me who's never touched unity. Thanks.

@Kowgan This might save you a bit of work <link removed> If you're ok with its simplicity I'll whip up one up for the OPM map as well. Edit: Since @Kowgan will be making their own version I'd rather not leave a link up to an 'off-brand' version in the official thread.

Looks good, thanks for the quick response.

Version 0.2a of your mod on SpaceDock doesn't contain the Apex folder, only the files from ASET.

Just as a heads up, that version of Expedition Ribbons is marked as `5.1.1` on spacedock (and subsequently CKAN). If your next release isn't a higher version than 5.1.1 the release will be "hidden" in CKAN unless we manually intervene. It's a trivial fix, but because it'll need to be performed manually we'll need to be poked when it happens. The simplest/fastest fix IMO would be to release version 0.5.1.1 on spacedock and then we can fix it at that point.

I'm not intimately knowledged enough to know what the drawbacks or alternatives are. Good to know it's a sticking point with some people though, thanks.