blowfish

Yes. MM really doesn't have any knowledge of how any specific configs are used in KSP - KSP loads all configs in GameData (but not inside a folder called PluginData) into memory, then MM looks at which ones are patches and applies them. Then KSP actually does things with them, like creating parts etc. I took a quick peak at Texture Replacer's code and it is set up in a way that allows all of this to work. Actually looks like it might not work since TextureReplacer accesses that stuff before MM has a chance to process it.

You might have to set the scene on the UI_FloatEdit to UI_Scene.Flight

Yes and yes

I've been meaning to fully document it, but I did write up a post a while back: This was due to a change in SolverEngines: https://github.com/KSP-RO/SolverEngines/pull/26 (which I would consider a bugfix). As it was before the alternator would always output a minimum of 25%, which ends up being very wrong for some engines (mostly on the RF side). Jets and propellers probably should output some electricity at idle, but it'll take a bit more work to figure out how to make this work correctly for different engine types.

It's definitely something I've considered doing. It would be a bit more involved than the KW fairings, just because I would have to build the models and map them to the textures (which weren't really designed with this exact setup in mind), but definitely doable. I haven't written anything up yet, but that was mainly because I wanted to get it out and see if there were any major issues and gather feedback on how it was working for people. Now that it has been out for a bit and seems to be working well some documentation might be a good idea. I did put a fair bit of work into the KW fairings to improve the colliders (among other things) but that's not strictly necessary. What mods did you have in mind for this?

@Blackline one other thing to note is that the tanks typically have different dry masses, so you'd probably want a unique set of tank definitions just for this. Then there's the question of what to do if the user tries to switch off of a tank with fuel in it (probably allow them to dump the fuel after confirming, but that's another thing that would have to be implemented).

It's supposed to be disabled on IR parts. I guess that stopped working at some point.

Welcome to the forums! Unfortunately, just that info is nowhere near enough to figure out why it's happening. Please read the "how to get support" link in my signature which will point you toward debugging steps and when information you need to provide so that others might help diagnose your problem.

Could you be a bit more specific? What sort of thrust are you getting at what flight condition (altitude, mach)? Note that ramjets will have pretty low TWR to begin with.

It is currently disabled. Definitely possible to implement, but I'd like to know a bit more about it first. So what's your use case, or more broadly, what are you trying to accomplish by switching tanks in flight?

They actually both use the same texture, but are mapped to different areas of it. So changing the texture won't do anything. Hmm, looking at this, that's a texture designed for the stock procedural fairing module. There's no way to switch those textures on the same part, but you can duplicate the part and use it (the stock fairing module defines what texture it uses in the config)

Recoloring would require making a new set of textures.

I think this would be a lot less trivial than you think. MM doesn't keep track of what patches apply to what. So if you wanted to reload a particular e.g. PART, you'd basically have to go through every patch anyway to figure out which ones would apply to it. If you wanted to reload a particular patch, you'd have to start from scratch since everything currently in the database would already have the old patch applied. Plus, MM has no way of knowing exactly what nodes affect what in the game. Knowing that a PART node affects a part with that name is simple enough, but there's a lot of other stuff in the game database.

They're not in master, different branch (which you may not want to use right now because a lot of the stuff in it is highly experimental)

output_log.txt and KSP.log will always be current

@Gordon Dry The entire log might be more illuminating. Those few lines definitely say that something is wrong, but don't provide any clue as to what might be causing it. Maybe include ModuleManager.ConfigCache as well.

Is this for 1.2.2 or the prerelease? E: Answered the question myself. This is for KSP 1.2.2

Regarding cargo bays - The problem is that usually the models are hollow tubes, whereas when a cargo bay is closed you want it to have the same drag characteristics as a solid fuselage piece. So the usual process is this: Have two parts, one of which is a cargo bay and one of which is a solid part with the same shape Run KSP Open PartDatabase.cfg Copy the drag cubes from the cargo bay and put them in the part's CFG Copy the drag cube from the solid part and replace the cargo bay's closed drag cube with that in the CFG If the cargo bay doesn't have empty ends, none of this needs to happen. Regarding dragModelType, there are only a few significant values: "SPHERICAL", "CYLINDRICAL", "CONIC", "OVERRIDE", and "NONE" (override and none are the same). Everything else defaults to the default cube implementation.

Drag cubes are generated automatically and saved to PartDatabase.cfg (I am not entirely sure of when this cache is invalidated). The cases where drag cubes are specified on the part are those where the default procedural drag cubes don't work, mainly cargo bays.

It's a C#6 feature. I've managed to compile such code on all 3 platforms (Windows, OSX, Linux), so let me know if you need help.

Thanks for the log! I can't immediately tell what's causing the crash, but it doesn't seem to be B9. I see a couple of exceptions from KER, one from FAR, and a mod called SuperKerbal is definitely not working (because it is missing Kerbal Inventory System), but none of that should cause a crash. If you can isolate the problem with a much smaller mod list, I can look into it a bit more. Also, in general it isn't a great idea to mod your Steam install. Steam's auto-updates can cause incompatible versions, and I know for a fact that the next KSP update will break some mods. Best to start with a fresh Steam install, duplicate it somewhere else, and then mod there. No idea why there wouldn't be an output_log.txt ... you are looking in E:/Spiele/Steam/steamapps/common/Kerbal Space Program/KSP_x64_Data/ , right?

Had a chance to mess with the dev version a bit tonight and I can say that I'm still firmly for #2, maybe even moreso. With even a moderate number of recolorable parts on the vessel, the whole vessel list quickly becomes challenging to navigate, or to even remember where you are when you're trying to recolor just one part.

#2 makes the most sense to me. Key shortcuts can be handy but as you mention the chances of a conflict are high. They're also harder for new players to find.

I don't think this is any known issue. Try completely removing KW Rocketry and re-installing it. If that doesn't work, we might be able to diagnose the problem based on KSP's log. Instructions on how to find and upload that are in the first link in my signature.

A few of the stock effects are incompatible with RF. Solution is to install RealPlume.