sarbian

The newest dev will fix your problem. Your vessel has an Intake module with a wrong named transform. I guess a part config is wrong somewhere but given how long it took to start your modded install I did not want to spend more time on it.

The content of MM thread since 1.6 begs to differ

Could you share your save and mod list?

Hopefully this should do. Version 3.1.3 Add a workaround for the 1.6.0 PartDatabase / Editor bug Downloads : ModuleManager-3.1.3.zip ModuleManager.3.1.3.dll

I doubt your commit is the culprit. That dictionary has all the vessel part so if something is not found then a decoupler or a part reference a part outside of the vessel... So my money is on the broken mod I guess we could handle the error more gracefully with a bunch of TryGetValue but meh...

v1.1.19 orbitDisplayMode is now an array and you can start without the ability to see any orbits. See the default file comments Downloads : CustomBarnKit-1.1.19.0.zip It seems it was fixed.

It's the stock bug mentioned in the post before yours and is not related to MJ. Late relative to what ?

Nope. Each Unity version seems to bring new bugs related to multiple displays. The current one crashes if the display resolution are different which is the case for me...

KSP includes the KSPAddon annotation to do that and it provides far better control over the object life than this.

The current version works on 1.5.x and most likely on 1.6.x

I have not tested it in a long time but that one used to not properly work on Roslyn generated dlls.

It is the same code but built for 1.5

Ok, we are back online with the old server while I get the new one ready (new provider and I have a few quirk to fix). For those interested by the nerdy part: Old server now has a faulty RAM stick (and ECC does its best to deal with it) I won't get it fixed because I planned to ditch the old provider after their last "hey, here is a +26% on your server bill" a few weeks ago The server runs proxmox with a ZFS pool for storage. Bad RAM + ZFS => bad stuff The ZFS log got corrupted bad enough that the poor linux kernel actually segfaulted... from there it was impossible to mount the ZFS without crashing the kernel I tried a bunch of rescue CD (booting an ISO thru the network... glad I have fiber) without much luck. A FreeBSD even rebooted when mounting the ZFS. I finally found a Linux ZFS rescue ISO with a release candidate of the next ZFS on Linux release and that worked. Scrubbed the ZFS volume. Exported the KSP/Jenkins VM image to have a backup and rebooted to a ItDidNotCrashYet™ state. I am getting the new server ready and will do my best to get it ready ASAP

I won't be able to fix it today. The data seems do be fine but I ll have to move to the new server to have it working and it will take time...

The server is reminding me that I need to move to a new host by crashing badly. I am working on it and hopefully it won't be too long.

I love it when people dismiss an issue like this. There have been multiple patch to the controller and you can even choose one of the 3 available controller to find what suits your rocket best. If you can do better then write a freaking patch. I would love a amazing controller that can handle whatever freak build you throw at it. But I get more amateur hours analysis (FPS dependant, lol) than contributions.

As I explained in my other post that it is not the case.

You need to use the callbacks to control the vessel or you will fight with the stock code (and other mods). Somewhere in your OnStart public override void OnStart(PartModule.StartState state) { if (vessel != null) { vessel.OnFlyByWire += MyControlMethod; // or OnPreAutopilotUpdate / OnAutopilotUpdate / OnPostAutopilotUpdate depending on how soon/late you want to do it in the controls orders } } Make sure you have a OnDestroy void OnDestroy() { if (vessel != null) { vessel.OnFlyByWire -= MyControlMethod; } } And somewhere else private void MyControlMethod(FlightCtrlState s) { s.wheelSteer = 0.5 }

Version 3.1.1 more Internal code improvement by @blowfish Downloads : ModuleManager-3.1.1.zip ModuleManager.3.1.1.dll

The smartA.S.S does exactly that in one of its tabs. Edit: err no, the plane AP

It took some time (mostly because I did not have any...) but the last dev finally work properly with your Service Module (and most likely other parts with similar problems). Hopefully I did not break anything else.

@value != 0.5

Try deleting the cfg in C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\MechJeb2\Plugins\PluginData\MechJeb2 But you have a lot of exception from EVE, Scatterer and Kopernicus...

Not really easy but it seems to run on a FixedUpdate so you "just" have to disable the object.

Dev is the development version and those version can break at any time Release is the "official" version and should be somewhat stable.