blowfish

Should have actually read @tater's original post @Shadowmage There seems to be something weird about the way the latest release is packaged. The paths all seem to have backslashes rather than forward slashes, and this seems to mess up unzipping in OSX. The previous release does not seem to have this issue. Was the most recent one packaged differently?

You should really download from releases rather than downloading the whole repo unless you have a specific reason not to.

If it's not disabling transforms, that points to something being wrong. If you watch the debug output when placing that part in the editor, are there any errors or warnings?

You don't need it, and I don't think this behavior is guaranteed. ModuleB9PartSwitch will disable any transforms it sees as inactive, so you shouldn't have the same transforms in a subtype and ModuleB9DisableTransform

Should look something like this

I think this is more of a ModuleManager question than a B9PartSwitch question, but I'll try to answer it anyway. To my knowledge, only one index is supported by ModuleManager (though I'm not sure why it would be removing more than one), so you should probably split that up. I would also highly recommend referencing things by name instead of by index. It's much easier to keep track of and less prone to breaking, so I'd recommend something like this: Also what's the purpose of the ModuleB9DisableTransform ? It seems to be referencing the same transforms as the switcher.

You do have access to the keys Dictionary<string, string> dict = new Dictionary<string, string>(); for (int i = 0; i < node.values.Count; i++) { ConfigNode.Value value = node.values[i]; dict[value.name] = value.value; }

A steeper re-entry will reduce overall ablator use. Peak heating will be higher, yes, as will peak g loading, but the total heat load over the entire re-entry will be less. So if a gentler re-entry causes you to run out of ablator, that kind of makes sense. Not saying the balance is correct at the moment, but the overall trend of the results seems to make sense to me.

Nope, those are still a separate mod. No procedural wings here.

@whale_2 thanks for the info, I'll see if anything can be done about it without completely redoing the models. But not voxelizing the struts seems like a reasonable workaround in the mean time.

It needs configs for every engine mod, and I guess no one has made them yet in this case. Are you volunteering?

@Stratickus it should be tankType = Karbonite

Months are hard...

They will behave more accurately. Be aware though that accurate aerodynamics may often be unintuitive.

Well something is probably still installed wrong. Honestly the easiest way to see exactly what's in GameData is if you upload KSP's log, instructions on how to find that are in the support link in my signature.

There was code to make the work together. I haven't tried both mods together very recently though.

Yes, extract the zip file and move the contents of its GameData folder into KSP's GameData folder.

I haven't heard of such a problem and I don't think any recent changes in RF would affect it. Might want to ask in the SSTU thread (be sure to provide logs of course) E: saw that you did, might want to include logs though because those are an important debugging tool. Visit the support link in my signature if you're not sure how to get them

Your existing GameData folder is the one that Squad is currently in. It should have contents looking something like this: Squad/ B9_Aerospace/ B9PartSwitch/ ModuleManager-x.x.x.dll ... Also it is not recommended to mod your Steam install (KSP can update automatically and badly break mods). Best to copy it somewhere else (it'll work fine) and mod there.

Well you definitely have stuff installed wrong. I'm guessing you copied the contents of the download directly here? That's not correct. You need to copy the contents of GameData in the download into your own GameData folder. It might be worth starting from scratch at this point (delete everything but Squad and reinstall) E: And welcome to the forums!

Answered @miromed's question via PM. TextureReplacer does not support mesh names with spaces in them.

I can look into it, but fundamentally I'm just working with the assets that were there to begin with - any modification I could do would probably not look as good (texture stretching issues, etc) And I've found that a fairing that's slightly longer than necessary isn't the end of the world

It's now disabled by default, you can enable it in the part action menu. Note though I think there's a bug where it won't appear immediately when you toggle it, have to force it to update by e.g. changing the diameter.

Advanced Jet Engine v2.9.0 for KSP 1.3 Recompile for KSP 1.3 @Duck1998 I haven't forgotten about localization, just been busy with other stuff and still working to understand KSP's localization system. I wanted to get something minimal out now that FAR is 1.3 compatible

@HebaruSan I'd say it's different if you actually identify the issue (which you did). But in general it's better if any CKAN related support requests go in that thread and someone who knows more about FAR/CKAN can look at the issue and determine where the problem is happening.