HansAcker

I don't really know much about it, myself. I only ever changed the size value :) The easiest way is to wait for the Kopernicus mod to support comets, so you can control their orbits and frequency. Other than that, you could probably just convert undiscovered asteroids to comets by changing their part to "PotataComet" and increasing the size in DISCOVERY.

This mod is the closest to that goal, I think: I don't know if it gives you all the information about a planet at once when discovered or if more scanning is required.

That's what Kerbalism's science does. It does a lot more, though, not everyone's choice

I use these mods in 1.10.1 (in their latest CKAN versions, can't check at the moment) and have not noticed any problems. A log file of a session where a craft goes missing might be useful.

PotatoComet is the KSP "part" that constitutes a comet. Asteroids use PotatoRoid. You'll find the size class in a DISCOVERY node in the comet "vessel".

On the far end is Red Onion. You can program your own UI and functions with access to most module functions:

LGG maintains some more mods with that theme:

KerbalEngineer continously scans the ground to display the slope directly under the craft. I don't know how expensive these tests are but that could be an option for the target picker (where to display the value, though?) I wonder if the surface slope returned by a scan from orbit accurately reflects the high-resolution surface on landing or if it's just a rough "scaled-space surface" value. TCA's autolander does it a bit different and scans the ground for a flat surface after the landing site has been selected. Then again, do you really want to target a flat landing site automatically? Let Jeb stake out good sites and note the coordinates plant flags

I don't think it's mod-related and as VoidSquid said, it's been a "feature" for quite a long time. I'd say the Kerbals can't decide whether to walk or float, so they get stuck between animations. Why walk if you could take a rocket-powered rover instead?

Maybe the blast marks could be made a special case for Kopernicus Expansion's Footprints feature. I never used it and have no clue how hard it would be to implement it there, so this is just another irrelevant post

This patch would only work with processes already defined in the Profile node - as that's not patchable with MM because it needs to be parsed before MM runs, so the loader can set the feature flags seen by later patches. At least that's how I interpret the loader source. I'm not sure how that maps to converter modules and if custom converters can be supported. But, if you only want to add (not change) processes, couldn't that be done with a .cfg file just containing the new process in a Profile node and Unity would merge it even before Kerbalism runs? Edit: I did give it a try later, it won't work (yet). Kerbalism loads the first Profile with the name it's looking for. Additional nodes won't be merged and if the patch is loaded first, NullRefs ensue because all the rest is missing. I guess the profile loader could be changed to merge all config nodes with the same name. That would make extending Kerbalism much easier. Edit again: I didn't know that Kerbalism already includes some mechanism for that, the "KerbalismSupport" profile. At least it allows adding content to the profile, not changing it (duplicates ignored). Third edit's the charm: a resource definition for the _ProcessName pseudo-resource was missing. So that's a way to add custom converter recipes without editing the profile cfg.

I think that's only true for the "Profile" node because Kerbalism reads that before MM can patch it. Part modules can be modified with MM if the patch order is right. I succeeded by adding ":AFTER[KerbalismDefault]" to my patch (not exactly the same thing but similar - add electrolysis to the US II fuel cells)

I just had the same effect. Disabling "Personalise suits" in the TextureReplacer menu helped. I haven't looked at it further, spending too much time on a suit texture

TacLS does not reference "DS_WasteWater" itself. My guess is that some other mod (possibly one that could be abbreviated as "DS") includes compatibility patches depending on TacLS and those patches either do something weird or you're missing additional dependencies. I'd search for "DS_WasteWater" in GameData and take it from there. Or maybe post a link to a log file. (copied from another thread ;)

TacLS does not reference "DS_WasteWater" itself. My guess is that some other mod (possibly one that could be abbreviated as "DS") includes compatibility patches depending on TacLS and those patches either do something weird or you're missing additional dependencies. I'd search for "DS_WasteWater" in GameData and take it from there. Or maybe post a link to a log file.

"They're flying through dangerous territory—and one wrong move could make them crash and burn..." That does sound very Kerbal, indeed. ( scnr https://www.goodreads.com/book/show/23562877-eyes-turned-skyward ) ( I guess you're talking about this one: https://www.alternatehistory.com/wiki/doku.php?id=timelines:eyes_turned_skyward but I don't have an answer for that, sorry. nice vehicles

That's MiniAVC-V2, not MiniAVC. ZeroMiniAVC does not (yet) remove the v2. As far as I know, only KIS/KAS includes it. MiniAVC-V2 should not have the problems MiniAVC had with threading. In this case, it seems to choke on a MiniAVC-Settings file. "C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\000_ClickThroughBlocker\MiniAVC.xml". tbh, I'd just try removing that file. I don't know enough to even guess at the cause of a "sharing violation". Insufficient access rights or is the file locked by another process? There are more exception about someting called "Ookii.Dialogs", too. Edit: I'll read that again. There's a "MiniAVC" (not -V2) in the ClickThroughBlocker directory (and elsewhere) which might cause this problem when both versions try accessing the same file, I guess. So you're right, installing ZeroMiniAVC would probably fix it

Yeah, that's what I meant with "not all of them work" and you'd need to test it in the settings. It probably depends very much on the keyboard layout because you can only configure (physical) keys, not characters. On my keyboard "<" and ">" are on the same key (which KSP reports as being "^", incidentally), so they wouldn't work, either.

I'd say: Yes. Unless you use a special framework like ReloadableMonoBehaviour. In my experience, replacing a plugin DLL in a running game will lead to all sorts of weird crashes.

In the settings.cfg, you need to use the codes described here: https://docs.unity3d.com/ScriptReference/KeyCode.html Not all of them can be used in KSP and some keys may have unexpected assignments. What works for me is to go into KSP's input settings, chose any control and look at the output when pressing keys. I just tried this config with HullCam and it places the next/reset/prev buttons on otherwise unused keys on my keyboard:

Well, since you bumped it, I had to test a patch It probably depends on what you want to change but you can target the engines by their "engineID"

The SAS _mode_ (prograde/radial/etc.) is not saved unless helped by a mod.. The on/off state is saved in the ActionGroups section and can be accessed in-game via Vessel.ActionGroups[KSPActionGroup.SAS];

I'm going to give @Lisias' Driftless a try. It doesn't really do much, "just" zeroing out the torque: https://github.com/net-lisias-ksp/KSP-Recall/blob/master/Source/Driftless/PartModule.cs#L106

It was easy enough with ImageMagick to convert all files into a big map. Converting to .dds is not necessary. The .png works, too, and is a much smaller file. montage Red/Flags/*.png -geometry +0+0 -background transparent red.png convert red.png -flip red.dds A bit of shell script produces a suitable config file from a template: https://pastebin.com/BDaHN1aw. The images are licensed CC-ND, so I can't share the resulting .dds files but it really isn't difficult to convert them yourself. I see some artifcats in the airlock decals but the numbers work very well.

If your cargo bay doesn' do anything special and has the animation defined within the model, no programming is required. For stock cargo bay behaviour, you'd need to add "ModuleAnimateGeneric" and "ModuleCargoBay" to the part config. I'd look at the config for the stock cargo bays or examples in other mods. Apparently, multiple cargo bay modules can reference the same animation and the Mk2 lander can doesn't even use the cargo bay module for its storage space. The module options are listed in the API (ModuleAnimateGeneric and ModuleCargoBay) but there's little documentation in it.