blowfish

Oh, you're right. I thought that was a patch for the MFT tanks, but it's not. Context might have helped.

I don't think this would work. Procedural Parts uses a completely different mechanism for switching fuels when MFT isn't present (additionally, you would break the patch for people who have MFT but not PP).

For what it's worth, I think it would be pretty easy to modify the existing shaders to do this. The shader source is already available through PartTools, and while I don't entirely understand the shading language, it looks straightforward enough to modify it to subtract another texture from the diffuse texture. I think the bulk of the work would be in reconfiguring the models to use this. But its probably worth waiting to see if 1.2 has a built-in solution for this.

I was interested in this too, and I looked into it, but it turns out to be not trivial. Ambient occlusion (basically, soft shadowing) from the pipes is baked into the texture, so you'd basically need a duplicate set of textures for this (or custom shaders so that the AO maps could be separated).

It has been on CKAN for a while. But there hasn't been a release marked as compatible with 1.1.3 so it won't show up for that version of KSP

There's a full stack trace on the exception that only shows in the log. The first link in my signature has instructions on how to find and upload KSP's log

.NET has its own serialization system, and under that Material isn't serializable (since it doesn't have the [Serializable] attribute). Unity's serialization system is completely separate, and I would be surprised if VS knew anything about it.

Material derives from UnityEngine.Object, meaning that it's serializable. There are weird cases like Vector3 where Unity's documentation doesn't necessarily say explicitly that it's serializable but it is. I think as a general rule most built-in Unity types are serializable, however.

@DMagic Correct, any public field of a type that Unity can serialize will be copied from the prefab to the instantiated part/module. This actually has nothing to do with KSPField, it's all Unity's serialization. If you don't want it serialized, you can mark the field [NonSerialized] ... similarly, if you want it to serialize a private field you can mark it [SerializeField]

That's not supported. You can only have one aero surface per wing part.

It seems to be called any time a part is created in the editor or in flight (but only after the entire vessel is loaded if loading a vessel). I haven't tested extensively though, so I could be wrong about this.

@pellinor Yep, sounds like you mostly figured it out. Load/OnLoad may not be called in the editor at all, depending on whether the part is freshly created or from a craft/subassembly. In flight, it will be called to load data from the saved craft. For code I want to run on the prefab (e.g. icon setup), I usually use OnLoad, but have some code to detect whether it's being run on the prefab or not. At that point in the part's life, part.partInfo will be null (though that's not the only way to check).

The SABRE does not liquefy the incoming air, so I don't think this quite makes sense.

Precoolers don't do anything at the moment. I've wrestled with this a bit - really, an engine like the SABRE wouldn't even function without a precooler, so it should be included in the engine.

Welcome to the forums! Please read "How to get support" in my signature - it will tell you how to find and upload KSP's log. Whatever this error is will probably show itself in the log.

Place it at the beginning of that particular patch, should look something like this (near line 98):

@Pointblank66 Ok I see the problem now. This patch is assuming that anything with command and monopropellant will also have electric charge, but that assumption is being violated in BDB. @Raptor831 I think I know of a quick fix. Checking for the resource and having separate handling for when it does/doesn't exist is difficult, but forcing it to exist is easy. Just add this at the beginning of the patch: &RESOURCE[ElectricCharge] { maxAmount = 0 }

@Pointblank66 Error can be found in KSP's log. For instructions on where to find and how to upload it, you can read the first link in my signature.

With RF installed, RF handles boiloff, not CryoTanks. I don't think RF supports any sort of active cooling.

I think the simplest thing to try is re-installing Kerbinside.

@Verran Not sure what you're trying to accomplish (context!), but you might want to read the first section of this: https://github.com/ferram4/Ferram-Aerospace-Research/wiki/Deriving-FAR-values-for-a-wing-using-Blender-2.7

The DEL part doesn't actually matter. You can put anything there, it just has to be something. But DEL or DELETE makes the intention of the patch clear.

This has been pretty consistent with PartModules in my experience. If Load is called at all, it is before Start. Load isn't called in the case when you're creating a new part in the editor from the part catalog.

Don't focus on the size of the tanks. Liquid hydrogen isn't nearly as dense as LiquidFuel or Oxidizer. Focus on total mass, delta-v, and cost. Maybe there is a problem with the procedural parts patches though ... you could verify by comparing to stock tanks.

@Flow There's definitely a delta-v threshold for which higher TWR chemical rockets are going to require smaller overall vessel mass. The LH2 tanks do mass a bit more per ton of fuel than the LFO tanks, but not by that much. They're big but they're not particularly heavy. Nuclear engines are only going to make sense for very large delta-v requirements.