Aelfhe1m

It's difficult to tell from just a screenshot of part of the folder, but you appear to have multiple install problems. A lot of KSP configuration files are very sensitive to being installed in the correct folder paths: there is an extra GameData folder inside your GameData folder : move all the contents of that folder up into the main folder. Bluedog_DB AND Bluedog_DB - Copy : there shouldn't be duplicate folders, KSP can get confused and behave oddly. Chatterer+0.4 : that's the name of the zip download. It should contain a GameData>Chatterer folder. Merge that folder with your main Chatterer folder Crafts / Craft files : these folders shouldn't be inside GameData - merge them with either <KSP>/ships or <KSP>/saves/<your save name>/ships It's likely that there are other similar issues that are not immediately visible in the supplied screenshot.

Took a quick look at the Commonwealth Aeronautics "Blue Steel" mod on GitHub and the engines all seem to be named "blue_steel_engine_<whatever>" so the edit to the patch should be:

It is always possible to override one mods patches with another patch. In each patching phase, MM applies all the patches of equal priority in order of their filename (including directory path). Therefore to ensure that my personal custom patches are guaranteed to override any mod created patches I store them in a folder called ZZZ_Custom. By doing that any :FINAL patches I put in that folder are currently guaranteed to be run last and override anything in any mod I install. I feel this trick should be reserved used for personal override patches. Mod authors should ideally keep their patches within their mod's install folder and use the pre-FINAL phases for their patching.

I don't think it's still being updated, although since it's just contracts it should still be compatible with latest KSP. The author hasn't been active on this site for 6 months+. As for the Skylark-1 contract, that does appear to be a mistake. While later iterations of the Skylark carried sizeable payloads to 800km+ in a three stage design, the first generation sounding rockets were single stage with performances much more similar to the early Aerobees. The first flight (SL01) on 13 Feb 57 (the one referenced in the contract) was a test flight carrying telemetry instrumentation with a max altitude of only 12km . The fourth flight SL04, 13 Nov 1957, was the first to reach space with a max apogee of just over 120km. For more information about Skylark series of rockets see this pdf hosted on the University College London website.

@emble12 They should show up under (non-searchable) custom part categories at the bottom of the parts menu. Make sure you have all the dependencies installed correctly, I think one of them adds the custom categories support if I remember correctly.

To get them working for my latest career, I opened the craft files in a text editor and ran search and replaces to change "Direct.KJ10" to "benjee10.AJ10.v2" and "B10.APAS" to "B10.APASv2" that allowed me to open them in a sandbox KSP. I then detached and reattached the AJ10s to make sure they were sitting on the correct nodes. I haven't reached the point in the career where I unlock all the tech needed so I haven't flight tested them yet, but they do open and are editable.

You can just chain the conditions to get a range. @PART[*]:HAS[@MODULE:HAS[#experimentID[*]&#xmitDataScalar[>0]&#xmitDataScalar[<1]]] { @MODULE:HAS[#experimentID[*]&#xmitDataScalar[>0]&#xmitDataScalar[<1]] { // For each Module with an experimentID and a transmit penalty, adjust xmitDataScalar to eliminate the penalty. @xmitDataScalar = 1.0 } } Edit: NB Surface samples have a default xmitDataScalar value of 0.25 and so would still be affected by this patch. If you have another mod/patch that changes their xds to 0 then you may need to check the patch ordering to make sure that it is not overridden.

The changes to the docking ports are in the file GameData/Restock/Patches/Coupling/restock-docking.cfg If you delete that file or change its file extension to something other than .cfg (e.g. .disabled or .off or .txt) then the docking ports should all revert to the stock style. If you only want to revert some of the docking ports and keep others then you can open the file in a text editor and delete out the sections for the parts you don't want to keep.

Yes, I kept running into issues with simulations and eventually gave up on trying to get them to work reliably. Instead, I now run two save games in parallel - one for my full career with part purchases enabled, KCT for building and research delays etc. And a second testing save without part purchases and with KCT disabled in which I design and test my craft before adding them to the build queue in the main save. It's more of a hassle having to switch between the saves each time I want to design a new vehicle, but that also incentivises me to reuse existing vehicles more heavily, both within a given career and across multiple careers. Importing tried and tested designs from other past saves into my current game. As for resetting the contract, I think you might want to start by looking at SCENARIO[ContractSystem] in the persistent file (after backing it up of course) that has sub nodes for all the active (and completed) contracts. Setting some of the parameters' states back to "Incomplete" might be a good place to start. (Never tried it myself, so I'm just guessing). I find KML editor is good for messing around with save files in a slightly more structured manner than a plain text editor.

To start that mission you normally just need to launch a plane with a pilot and enough empty seats to the runway. Load the inspector from the popup message then set the brakes and wait a few seconds for the take-off clearance message to be displayed. Then fly out to the target location al little bit above 2500m (not too high or it won't register) and then back to the KSC. Land at the runway and taxi to the terminal location near the billboard. Stop and wait a few more seconds for the final confirmation message, after which you can recover the aircraft. Most of the other contracts follow a similar pattern with you having to pause stationary at various points until you get clearance to continue.

Thinking about the subject of cargo missions a little further, I came up with the following concept: create a custom "cargo payload" resource create some "cargo pallet" parts of various sizes and capacities add "cargo payload" as a purchasable resource through the Kerbal Konstructs merchants system, either by adding it to existing fuel merchants or placing custom "warehouse" statics at some locations. The contract advance could include the cost of purchasing the payload from the merchants. missions would be written to require flying to a given airport, loading up with a specified amount of cargo payload and then flying to Jeb's Junkyard (or another destination) to offload the cargo I'd also like to have missions flying between different airstrips rather than the current pattern of KSC -> somewhere -> Jeb's Junkyard -> KSC Possibly a final step of "selling" the cargo to a merchant after landing at the final destination. Compared to the existing contracts, I think this would introduce some interesting design constraints for the transport planes. Needing them to be able to be built to accommodate the volume and mass of the cargo rather than just an arbitrary number of "payload" parts - after all a 1.25m service bay and a Mk3 cargo bay both count as 1 part and some mod parts are even smaller or larger. It would also allow some flexibility in choosing whether to use several small pallets or one large pallet to satisfy a given capacity requirement and need some thought put into distributing them within your vessel to maintain its balance in flight both empty and loaded. Different tiers of contracts could be created for small, medium, large and bulk cargo missions and for short, medium or long haul flights. After I've finished my current helicopter project, I might take a crack at implementing this but if anyone wants to use this idea before that, then feel free.

Interesting idea, but a lot more complex than you probably suspect. In order to work correctly someone would need to code a new custom facility type for Kerbal Konstructs to handle the user interaction and a new plug-in for Contract Configurator to implement new behaviours and parameters for the contracts to use. The existing system on the other hand is a clever workaround utilising features that already existed within the mods. Why it may be "failing" sometimes is that the location of the waypoint that you must get within 50m of is offset slightly from the billboards location (usually positioned in the centre of a taxiway junction). If you install the Waypoint Manager mod then you will be able to see the actual location of the waypoints. The contract will measure the distance between the root part of your craft's origin and the waypoint location (not the billboard). This could mean for example that a large plane could have a wing touching the billboard, but the cockpit (root part) could be more than 50m from the waypoint on the other side of the billboard. Waypoint Manager gives you a clear readout of location and distance to the terminal waypoint and removes any guess work. Example: KSC Terminal location in relation to billboard: That would be much more doable. "Just" involving writing and testing a new contract for the extra mission types. Perhaps a minimum mass for the vehicle to count as "large"? Of course that would depend on how much spare time Caerfinon has to spend on the mod. Or whether someone else would write the contracts and contribute them. (I'm currently writing and testing some patches to expand the role play aspect of helicopters within the contracts, with adding terminals to helipads where available as an alternative to landing at the billboards. I'll offer them up here once they're in a more complete state.

The gear icon opens a little pop-up window to allow you to change the displayed name and icon of the current reactor - useful for large bases/stations/ships with multiple reactors to help keep track of which one you're currently looking at or what it's designated purpose is. The two options in the advanced section let you set the automatic "temperature shutoff" and "warp shutoff" thresholds. There's a little more info on the GitHub wiki, but it's incomplete (missing images) and rather terse.

Jeb persuaded a reluctant Bob to join him in test flying his new Zelicopter (The Belafonte mod by @ColdJ). At first things went well, including a quick trip to visit the Cove launch site and a high altitude trip across the peninsula, but Bob was rather disgusted to find out that Jeb hadn't been paying attention to the fuel gauge and they were forced to make an emergency landing near the edge of the desert on their way back. While Jeb stayed with the his new toy, Bob hiked to the nearest main road and hitched his way back to the KSC. It took a little while for the people at the KSC to prep another chopper (a Huey also by ColdJ) to take a couple of jerry cans of fuel to the stranded Jeb (Wehrner felt it would do him some good to have to wait a bit), but eventually Sammy and John made the trip and then followed him back after refuelling the Zelicopter (squadron mode in TCA). All's well that ends well and both craft landed neatly on the runway.

Newly added contract packs should be enabled by default, but yes you can access the customisation screens within a loaded save game. In a loaded save, bring up the pause menu and click on the settings button. At the top of the settings screen is a button to access the mod configuration settings that were available during your new game setup, including picking which packs contract configurator will use.

That looks like the wrong zip. It look like you cloned the repository (which does not include a compiled copy of the mod) instead of downloading the release version. You want to download MagiCore-1.12.0-1.3.2.5.zip from the release page on GitHub. Then copy the whole MagiCore folder (3 files plus a subfolder with the compiled dll) from the zips GameData folder into your GameData. NOTE: MagiCore is a dependency needed by other mods but does nothing by itself alone.

I looked at the camera part config file to find a module that ran the science experiment and didn't find any of the usual suspects, with the only likely one being the moduleSpyExperiment. To verify I then did a search for the code implementing the moduleSpyExperiment and confirmed it was based on the stock ModuleScienceExperiment. As a final check to make sure removing it wouldn't have any unintended side-effects, I also searched for other references to it in the source code and confirmed that the only other code referring to it was in the camera part code and it did a proper check to make sure that the module was actually present before trying to access it. (You can usually skip this last step if you aren't a coder, I was just being extra careful)

Add a ModuleManager patch file (create a new text file, copy in the below text and save it with the filename of your choice and a .cfg extension anywhere in your KSP GameData folder) : !EXPERIMENT_DEFINITION:HAS[#id[TargetScanning]] {} @PART:HAS[@MODULE[ModuleSpyExperiment]] { !MODULE[ModuleSpyExperiment] {} } DISCLAIMER: Untested but it's a very simple patch, so I can't see any reason it won't work.

It's working fine for me in my current heavily modded 1.12.5 career, no patch needed. Just click the little options icon next to the ship's name in the build queue and then the "Select LaunchSite" button to see a list of currently available launch sites. Depending on your KK settings you may have to pay to open bases (possibly by visiting them first). I have found that the feature can be a little buggy though and sometimes KCT will just offer the stock launch sites. When that happens the only way I've found to restore the list is to restart KSP. Screenshots:

You can just change the value in the UI (right click the KCT toolbar button to open settings dialog) and then save it as a new preset. Or if you prefer to use a text editor: Go to GameData/KerbalConstructionTime/KCT_Presets folder Copy one of the existing config files and give it a new name Open file in text editor Find the StartingPoints line in the KCT_Preset_General section Edit the three numbers after the equals sign (first is career, then science, then sandbox)

The mod includes a surface mounted avionics package that goes on the rack for the smallest size to act as its control probe and a 0.625m inline probe ("M-315 Probe Core") for larger sounding rockets.

Yes it does. It's not designed to allow launch from other planets (you need Extraplanetary Launchpads for that). Because not everyone wants it? (I don't) Because core KSP isn't designed to allow those features to be extended (or at least not without a lot of kludgy hacking) so mod writers had to come up with various work-arounds. The drop down on the launch button inside the SPH and VAB are extensible and are utilized by this mod. That one I can sort of agree with, since the wiki is more functional documentation than user guide, but KK was designed more as a tool for other mods to use to implement planet side infrastructure than with end users in mind.

KSP 1.12.5, KK 1.8.6, Kerbin Side Remastered 1.0.1

@Exp0Ten It sounds like there's something wrong with your install. I'm not seeing that problem on my current heavily modded install which includes KK and Kerbin Side Remastered. Although I'm using the full Kerbin Side Remastered not the Airports sub-install.

Sorry, the KK-Distance tag has been broken for a long time now. I keep meaning to rewrite it to work with the current version of KK but I've never gotten around to it. By "distance to Kerbin", do you mean distance to KSC?