blowfish

Revisiting the SC-E reminds me ... I believe there actually is a way to combine multiple wings/control surfaces on the same part. I haven't tried it myself (I seem to say that a lot, don't I), but I suggested it in this thread and it sounded like it worked. Didn't even need much code. This does have some drawbacks ... (1) The UI would be pretty messy with all those control surfaces on the same part (though with reasonable defaults for the control toggles, most probably wouldn't need to touch them), (2) It only removes 3 parts at the expense of some configuration complexity and (3) I'm pretty sure it would break any hope of FAR compatibility, at least as it currently stands (no idea when the wing overhaul is actually going to happen)

That's for duplicating an existing node. If you're creating it from scratch you wouldn't use the operator.

This should work, to my knowledge. You should be able to tell what's going on based on the log and config cache. Any clues in there?

ModuleManager would be the way. Nothing specific to B9PartSwitch there. I can provide an example when I get home if you want. Have you taken a look at some of the existing tank definitions? There's not really a concept of a fixed amount of a resource in B9PartSwitch - the amount that you end up with is essentially ( (base volume on the module) + (added volume on the subtype) ) * (units per volume on the tank) . So what I'm trying to figure out is how to defined how much should be filled in relation to the units per volume.

There's no way to do this currently. I don't think it would be hard to implement, but it would require new code. I think there are really two features here: Ability to only partially fill tanks. You are not the first person to request this, so I'm somewhat more inclined to look into this now. Ability to override the resource's tweakable option In both cases I think it would be defined on the tank type. Something like this (note for anyone reading this in the future, this is a prototype and not necessarily how the feature would look) I'd definitely like to hear some feedback on how you would expect this to work, also from @komodo who also requested the ability to partially fill tanks (and anyone else who is interested in these features, of course). Specifically, a couple of questions still remain in my mind: In both cases, would you prefer the setting to be per resource or per tank type? For partially filled/empty tanks, how would you like it to be defined. It could be a proportion (0-1), a percentage (0-100), or the number of "units per volume" that would be filled (so if unitsPerVolume = 0.45, the range would be 0.0-0.45)?

From the main menu or space center, Alt+F11 and click "Quick reload database" (the only thing that the normal "reload database" gives you in addition is re-rendering drag cubes, which you probably don't need)

I see the issue. @Nertea In this patch, it should be checking for Procedural Parts and NOT Modular Fuel tanks: https://github.com/ChrisAdderley/CryoTanks/blob/master/GameData/CryoTanks/Patches/CryoTanksProceduralFuelTanks.cfg#L4 So it should be @PART[procedural*Liquid]:NEEDS[ProceduralParts&!ModularFuelTanks&!RealFuels]:FOR[CryoTanks] Although the ProceduralParts part isn't strictly necessary because procedural*Liquid should really only match procedural tanks anyway

@Angel-125 I think what you have will do exactly what you want

Yes, they are. This thread is from before they did however.

B9PartSwitch v1.5.2 Recompile against KSP 1.2.1

There's nothing new in this regard in 1.2, but since 1.0? We have IPartMassModifier (and IPartCostModifier for cost), which, if implemented on a PartModule, will tell KSP to add some mass to the part (or subtract even).

I have clarified my original post, however I maintain that putting any settings in a cfg outside of PluginData is a bad idea, because it causes the cache to be invalidated when it shouldn't be. In effect, it breaks a convenient, but not strictly necessary feature.

If it's in a .cfg file, and the contents change, then ModuleManager will re-apply every patch rather than using the cache. If you're saving settings to a config file, it should be in a PluginData folder (and thus will be ignored by the game database and MM's caching)

As Sigma88 said, anything in a PluginData folder will be ignored. If there are mods that store settings in a cfg outside of a PluginData folder you should tell the author that this will break MM's caching clarification: writing to a .cfg file outside of a PluginData folder will cause ModuleManager's cache to be invalidated, causing it to re-apply all patches rather than simply reading from the cache. This is undesirable because it makes the user wait significantly longer than necessary for KSP to load.

Re: solar panel colliders: it might be possible to do with just a box collider that scales along its axes during the deploy animation (well, really the transform scales). There might be some edge cases like the T shaped panels though, though I think there you have few enough panels that a single box collider for each might be acceptable. Definitely a fair bit of work to add colliders on all the panels and re-export them though. E: Just saw your last post though - applying force to the craft while deploying might be a problem. It might be possible to just break based on the sum of forces (or torque) on the part, but I'm not sure how reliable that would be.

Stock deployable solar panels (and all deployable parts) actually have custom handling for collisions.

There is a patch which should allow cryogenic tanks on procedural tanks. If it's not working, then it's a bug. Could you please do the following? In your GameData folder, delete ModuleManager.ConfigCache Start KSP and wait for it to get to the menu screen Find KSP.log (in your KSP root folder) and GameData/ModuleManager.ConfigCache and upload them somewhere we can see. If you can provide that information, we should be able to debug the issue.

I'm confused. The Procedural Parts mod comes with procedural tank parts, and is probably the most known mod that includes them. Are you referring to a different mod?

No, it's in the save file, and the default value is hard-coded. I don't think there's an easy way to override it.

The cost of the part does in fact include resources. It has always been this way.

I wouldn't expect any information to be logged when you click the event. Most of the useful information in the log comes from when KSP is loading.

Here's the config for the dome engine mount I mentioned in the SSTU thread.

@SciMan I can't speak for other mods, but B9 uses prefixed part names which make them easier to identify. Splitting out the HX parts complicated things somewhat, but you can still identify the correct parts relatively easily. Example: B9 MFT/RF patch

The landing legs still use Firespitter animation modules. Make sure Firespitter is up to date and if that doesn't work provide logs as usual.

The master branch at the RealFuels repository should be updated with any SolverEngines changes (which are still in the KSP_1.2 branch). Make sure you have those two branches checked out and see if you still get errors.