blowfish

That sounds very reasonable to me.

Logging does tend to create a fair bit of gc alloc. If it's happening every frame it might be worth worrying about.

Unfortunately B9 Part Switch wasn't really designed to handle changing arbitrary info on any other PartModule. As it is, every thing that it touches I have had to add with code, and it does not interact with any other modules currently. I've been thinking about ways to add this in a consistent and reliable way, but it's not a trivial problem to solve.

Yes, it does appear that the VS solution for MFT is rather broken. I think taniwha uses some build script to compile that I don't really understand.

The repository does not contain any compiled DLL so you would have to compile it yourself.

It's all about the dependencies. Everything is updated, but RasterPropMonitor is still a prerelease, so I haven't repackaged everything into a new release. You can find links to all the dependencies in the OP where you will be able to download updated versions. Note: this info is available higher up the page on this thread. I would very much prefer that you read a page or two back to try and get it rather than me having to say the same thing to every person who comes here.

Given that FAR doesn't have a 1.3 release yet I haven't seen a huge demand yet. Are you using a dev version of FAR?

B9PartSwitch can change the model but not actually anything about the engine itself (thrust, Isp, ...) MM runs, then all the tank types are loaded (but not any parts that use them), then the parts are compiled including any part switch modules. Anything you do in MM will necessarily run before B9 Part Switch is even aware of anything. Hope that helps!

FYI, still waiting for my fix of CKAN's metadata for CryoTanks to get merged. It looks like a couple of the people on the CKAN team who usually handle this stuff might be away right now.

@Mystique Even if it is MM causing the crash (and I highly doubt that) no one will be able to help you without logs.

It really depends. I'd say only try it if you really know what you're doing and when things break assume it's the reason. KSP 1.3 included some changes that broke plugins badly, and in general plugins are very likely to break between versions (except maybe patch versions). You might have better luck with part-only mods, but then again there was 1.0.5

Has anyone been able to find the technical webcast? I haven't been able to find it this time around.

@fwdixon What do you mean "prevented the stack from launching" ? Could you describe what you saw exactly? Logs would be helpful as always of course.

You have a mix of mods for 1.2.2 and 1.3. You need to make sure all the versions are consistent. 1.2.2 mods will crash 1.3 and the reverse.

That, and license

Hmm, maybe you're right then. @Nertea, any thoughts?

Part of the problem might be that this isn't very much delta-v

But they do care that the launchpad is going to be ready for their launch when it happens, not damaged or destroyed due to a mishap with an earlier landing.

CKAN issue is with NearFutureProps, same issue that CryoTanks had. I've submitted PRs for both, hopefully they'll get merged in a few days (hard to say though) But yes, per OP CKAN issues should go to the CKAN thread

There were issues with the metadata for NearFutureProps and CryoTanks upon which those mods (respectively) depend. I have submitted fixes for both, but they may take some time to make it into CKAN.

You have a bunch of stuff in C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\Plugins\ . That should be empty. Also I highly recommend not modding you Steam install. Steam's auto-updates combined with mods can easily result in a broken install and unusable saves. Best to copy KSP outside of Steam and mod it there.

There seems to be an issue with the latest version of CryoTanks not being indexed, and I've submitted a PR to fix it (just have to wait for it to get merged and then NetKAN to run, could be a few days). But like Nertea said all future inquiries should go to the CKAN thread.

Probably because the B9 parts cause the code in one dependency to actually be used, causing it to crash. I'm assuming you're on KSP 1.3? Make sure all you dependencies are on the latest versions (note: all the dependencies included in the B9 download is out of date). If that doesn't work I'll need to see your log as usual.

B9PartSwitch v1.8.1 for KSP 1.3 is now available Fix drag cubes being overwritten with defaults on root part in flight scene Fix vessel disappearing from map view if root part has a switcher that affects drag cubes** ** I had to implement a bit of a hack to get around the issue @Nertea reported above. I have reported the underlying issue to the KSP team, and hopefully it will be fixed in KSP 1.3.1 so that I can remove this workaround

Nope. Original F-1 did not throttle. The Soviet N1 did something like that though.