IgorZ

In KSP it's common that a rocket gets destroyed at the first launch. And at the second. And at the third. And many times more until it finally succeeded The winch to port connection is not a magic. It's a regular part-to-part joint. In the docked state, it's a strong as a regular tiny joint would be. If it breaks, it only means your design is not as good as you think. Obviously, you need more struts. And, to be honest, there is a game limitation to the physics. Some things just cannot be done

Some of you might think this mod is stale. Nope! I'm still working polishing the behavior. It will go live at most on the coming weekends.

I see a lot of errors like this: [ERR 23:35:20.044] MechJeb module MechJebModuleMenu threw an exception in OnLoad: System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown. at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 at AssemblyLoader+LoadedAssembly.TypeOperation (System.Action`1[T] action) [0x00006] in <55ba45dc3a43403382024deac8dcd0be>:0 at AssemblyLoader+LoadedAssembyList.TypeOperation (System.Action`1[T] action) [0x0001c] in <55ba45dc3a43403382024deac8dcd0be>:0 at MuMech.ToolbarTypes.getType (System.String name) [0x00014] in <4cdbe337c6aa43d0bc3552436a95c969>:0 at MuMech.ToolbarManager.get_Instance () [0x00023] in <4cdbe337c6aa43d0bc3552436a95c969>:0 at MuMech.ToolbarManager.get_ToolbarAvailable () [0x0000c] in <4cdbe337c6aa43d0bc3552436a95c969>:0 at MuMech.MechJebModuleMenu.ClearButtons () [0x00034] in <4cdbe337c6aa43d0bc3552436a95c969>:0 at MuMech.MechJebModuleMenu.OnLoad (ConfigNode local, ConfigNode type, ConfigNode global) [0x00000] in <4cdbe337c6aa43d0bc3552436a95c969>:0 at MuMech.MechJebCore.OnLoad (ConfigNode sfsNode) [0x002fc] in <4cdbe337c6aa43d0bc3552436a95c969>:0 Not to mention this one: [ERR 23:32:09.205] ADDON BINDER: Cannot resolve assembly: KerbalEngineer.Unity, Culture=neutral, PublicKeyToken=null [ERR 23:32:09.206] ADDON BINDER: Cannot resolve assembly: KerbalEngineer.Unity, Culture=neutral, PublicKeyToken=null I'd say you have real troubles with KerbalEngineer. Try either updating it or removing altogether.

<<CONTENT DELETED>> Apologies, this was a wrong thread. Snap!

LogConsole v2.1 2.1 (April 27th, 2020): [Change] Stop complaining about KSP minor version change.

1.6 (April 26th, 2020): [Fix #289] RTS-1 docking mode is not reset on decoupling. [Change] Stop complaining about KSP minor version change. [Enhancement] Add two new localization strings for the custom corridors: Corridor-1000 and Corridor-1500. [Enhancement] Add an optional patch MM-LegacyKASPipesPart.txt to simulate the old KAS pipes. Use at your own risk!

LocalizationTool v1.9 1.9 (April 26h, 2020): [Change] KSP 1.8 compatibility. WARNING: the mod won't work with version lower than KSP 1.8!

Could you please repeat the steps and share the logs? When something like this happens there are usually errors in the log. Detaching a part from a live vessel is done by KIS via a stock function. I don't see how it can get broken.

Well, it's not like a real known bug, but in general it's known that KIS creates and initializes parts differently from the stock game. This was the reason why KIS was never compatible with IR. If the part doesn't have advanced dynamic behavior, it's usually OK (and it's 99% of all KSP parts). The dynamic behavior, which some advanced parts implement (like wheels or IR), in many cases doesn't work as expected. I'm pretty sure this is the case here. And ahead of your next question: no, it won't be fixed in KIS v1. However, this will likely be resolved "naturally" in KIS v2 which creates new parts in the game world in a completely different way (inspired by the stock inventory system). It's really hard to say. Most of the KIS issues with the newly created parts can be resolved by simply reloading the savegame file. If it doesn't help in your case, then I have no idea. I may suggest a workaround that sometimes helps: Pull out the wheel out of inventory and drop it on the surface. Given it didn't explode or flew into the sky, try attaching it to your vessel.

1.25 (April 25th, 2020): [Change] Stop complaining about KSP minor version change. [Change] Update ES-ES localization. Important note: Going forward the mod will not be checking KSP version unless it's proven the release was incompatible. If that's the case, then the next mod's version will have the minimum compatible version adjusted, but the maximum version will never be verified.

I'd like to confirm what @Tonka Crash has said. Indeed, the old pipes were too buggy. No to mention they were physically impossible. Due to how the game is designed, it was simply not possible to make them stable. RTS-1, on the other hand, gives most of the stuff that people would like to get from the old pipes. And RTS-1 links never get destroyed due to they are flexible! If you're looking for a rigid connection, take a look at the TJ parts family. It's not as good as the old pipes (due to the short distance limit), but there is a reason why they are not: they are physically realistic.

KSPDev Utils v2.2 2.2 (April 22nd, 2020): [Change] Better default behavior in EventChecker.CheckClickEvent.

Hmm. This case I didn't check. But as long as it works fine, I'm OK

tag: fun If you plan to visit Kerbal Space Center, make sure you've made an appointment. The office hours may be reduced due to CORVID-19.

In KIS2 the whole pickup/move concept will be revised. Like, completely. I don't want to give details and set false expectations until at least Beta is released. Yes, it will be possible to construct such parts. In the old KIS it's not possible due to the module constraints. Btw, if you need to extend the mass/distance limits in the old KIS, you can simply change the settings file. E.g. if you are not an arcade type of player, and think as an architect in the game, simply set the limits to reasonably big values and you'll be unlimited in the game. In all my latest games I played with limits 10t/30m - it covers all my needs. Be careful with the distance limit, though. It affects the performance in the carry mode, and you won't snipe the right place for part at the bigger distances anyway.

Alas, this module doesn't work the way it should. It's supposed to be a pickup point, but with time too much code have accumulated that doesn't respect the concept. This will be fixed in KIS2. I've gave up trying to implement it in the old KIS. Today only a real kerbal works good as a KIS Pickup point. Non-kerbal parts may or may not work as expected (and they usually don't).

In case of you've guessed what do I do during my coronavirus quarantine weeks. This can be one answer: Or it could be the other one:

As answered by @DStaal, there was one and it was deprecated. There is a plan to implement a counterpart. Eventually. At this moment I'm focused on the new version of KIS. And, honestly, my usual schedule is severely impacted by the recent quarantine lockdown due to the coronavirus. Who may have guessed that this human specific disease may affect Kerbal? But it did.

KAS doesn't deal with the tanks capacity. It's defined in the part config. I may only guess that your game has some other mod that modifies tanks, and it worked bad. Please, share the save file and the logs.

Indeed, it's not an intended behavior. Could you please share the logs? In general, when you disconnect a winch, the owner vessel is expected to get some momentum due to the connector object is now on it's own. However, getting that much momentum cannot be explained by this. If you can prepare a simple save file for me to test, it would be awesome! I'm not a "plane person" (never flew a single plane in KSP, but destroyed a brazillion of rockets), so I never tested how does winch behave in planes connection.

I perfectly understand why refill doesn't work - it tries to work with "EVA propellant". It's actually a good idea to use the whatever fuel is actually used. Open question is how to deal with the fuel reserve. I've created a feature request.

I'm glad to hear you like the mod This is why I'm spending my time to it. About the log. Does this one relates to your initial "it doesn't work" problem? I don't see any KIS related issues there, but I do see exceptions thrown from the MechJeb: [EXC 16:29:21.948] NullReferenceException: Object reference not set to an instance of an object MuMech.MechJebModuleInfoItems.MaxThrust () (at <3ddb09b54c5e42379c1671957c9d0f6f>:0) MuMech.MechJebModuleInfoItems.MaxAcceleration () (at <3ddb09b54c5e42379c1671957c9d0f6f>:0) (wrapper dynamic-method) System.Object.lambda_method(System.Runtime.CompilerServices.Closure,object) MuMech.ValueInfoItem+<>c__DisplayClass13_1.<.ctor>b__0 () (at <3ddb09b54c5e42379c1671957c9d0f6f>:0) MuMech.ValueInfoItem.DrawItem () (at <3ddb09b54c5e42379c1671957c9d0f6f>:0) MuMech.MechJebModuleCustomInfoWindow.WindowGUI (System.Int32 windowID) (at <3ddb09b54c5e42379c1671957c9d0f6f>:0) MuMech.DisplayModule.ProfiledWindowGUI (System.Int32 windowID) (at <3ddb09b54c5e42379c1671957c9d0f6f>:0) UnityEngine.GUILayout+LayoutedWindow.DoWindow (System.Int32 windowID) (at <fa6f9762ac624af092525d37c9d516c4>:0) UnityEngine.GUI.CallWindowDelegate (UnityEngine.GUI+WindowFunction func, System.Int32 id, System.Int32 instanceID, UnityEngine.GUISkin _skin, System.Int32 forceRect, System.Single width, System.Single height, UnityEngine.GUIStyle style) (at <fa6f9762ac624af092525d37c9d516c4>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) [EXC 16:29:21.954] NullReferenceException: Object reference not set to an instance of an object MuMech.MechJebModuleInfoItems.MaxThrust () (at <3ddb09b54c5e42379c1671957c9d0f6f>:0) MuMech.MechJebModuleInfoItems.MaxAcceleration () (at <3ddb09b54c5e42379c1671957c9d0f6f>:0) (wrapper dynamic-method) System.Object.lambda_method(System.Runtime.CompilerServices.Closure,object) MuMech.ValueInfoItem+<>c__DisplayClass13_1.<.ctor>b__0 () (at <3ddb09b54c5e42379c1671957c9d0f6f>:0) MuMech.ValueInfoItem.DrawItem () (at <3ddb09b54c5e42379c1671957c9d0f6f>:0) MuMech.MechJebModuleCustomInfoWindow.WindowGUI (System.Int32 windowID) (at <3ddb09b54c5e42379c1671957c9d0f6f>:0) MuMech.DisplayModule.ProfiledWindowGUI (System.Int32 windowID) (at <3ddb09b54c5e42379c1671957c9d0f6f>:0) UnityEngine.GUILayout+LayoutedWindow.DoWindow (System.Int32 windowID) (at <fa6f9762ac624af092525d37c9d516c4>:0) UnityEngine.GUI.CallWindowDelegate (UnityEngine.GUI+WindowFunction func, System.Int32 id, System.Int32 instanceID, UnityEngine.GUISkin _skin, System.Int32 forceRect, System.Single width, System.Single height, UnityEngine.GUIStyle style) (at <fa6f9762ac624af092525d37c9d516c4>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) In my game installation MechJeb warns about incompatibility, so it's not a surprise to see errors in 1.9.1. It is surprise to hear KIS is affected though. What exactly do you do to have the problem showing up?

2.1 (March, 3rd, 2020) [Change] Switch to C# compiler v6.0. [Change] Set maximum KSP version to 1.99 due to now Squad team increases the minor part on any release, except a bugfix one (and it's the right way to treat versions!). [Enhancement] Fixing typos in the default localization strings descriptions. P.S. Not yet available on CurseForge. They are historically behind the KSP release schedule

Without details we may only guess what was wrong. A good start for the troubleshooting is providing logs. 70% of all the troubles can be resolved this way. Providing a short video of the problem adds 29% more to the success ratio.

To the best of my knowledge both KIS and KAS work just fine in the latest 1.9.1. You may use them with no troubles. Very soon I'll release a cosmetic update, but the only thing it "fixes" is the version check.