IgorZ

The latest version for now is alpha4. It has numerous improvements which you may find in the release description. As for the bouncing I think the only reason it was happening is false triggering of "release" event in which case part was aligned incorrectly (it's a corner case that happens intermittently). In normal case the part gets velocity and rotation of the object it's being attached/dropped to, i.e. the should be no bouncing. Another case is dropping a part so what it collides with some irregular parts of the other objects (extended panels, antennas, landing legs, etc.). Though, if you drop an object like this you should expect colliding effects I tried to find a solution to not allow dropping if there is a collision but everything I found was very expensive in terms of performance (it's basically going thru all the parts in the scene and checking them for mesh intersection, it's VERY expensive). Will get back to the task when have better ideas.

When KIS is attaching something it's considered docking ("coupling", to be more specific) from the game's perspective. In the game code I've found a script which controls "recover asset" missions, it may or may not require docking depending on the mission. Anyways, this script is explicitly checking for the part destruction, and if it's get destructed the mission fails. Since there is no way to change built-in scripts the only option is somehow workaround a situation when part is destroyed by the KIS script. Cargo bay works differently from KIS. In cargo (and service) bay parts are physically present, i.e. they don't get destroyed/recreated when you move move them in and out. In KIS what you see in the inventory is just a list of names, no physical parts are present unless you move one out. It's a principle solution in the add-on so, it cannot be changed without redoing the whole concept. The save file will be helpful to find a way of detecting quest parts. For now it's my own version (a GitHub fork, to be more exact). I tried to reach the original author to get my changes incorporated into the main branch but in the last 3 weeks there was no response (may be due to the holidays).

Hey! Could you please attach any savefile with this mission active? I've found the code that handles such contracts but according to what I see there mission completion is triggered on Docking with the part. It's not exactly what is stated in your contract, and I'd like to examine the save file to figure out how they do configure condition "recover it to Kerbin".

The largest container, ILC-18k, is 18,000 liters of volume which can only hold one quest module in your case (14.3l). How is it better than one AGU per mission?

This is helpful, thanks. I'll try to lookup which script is producing it, and figure out if its behavior can be intercepted. Out of curiosity, why do you prefer using KIS to finish the mission instead of a regular way - using Advanced Grabbing Unit? The part's size of 3.8x2.5x1.5 gives 14.25 cubic meters of volume or 14250 liters. I.e. to fit the part you need inventory container ILC-18k which is not cheap or lightweight. Yeah, I had this problem with the original KIS as well. Though, when I fixed false triggering of click events in the add-on the problem has gone for me. Could you please try the alpha3 version (only replace the .DLL in the KIS/Plugins folder) and let me know if bouncing problem still happens? If it does I'll be appreciated for a repro steps. And if you can make a short video to demonstrate the bouncing - it would be the best!

This is not true. When your rescuing vessel approaches the wreckage the crew onboard become "yours", i.e. you now can control them. Just switch to the wreckage using "[" / "]" keys, and use "EVA" button on the kerbal's icon: as long as exits are not blocked by the other parts it's possible to EVA (mk1crew cabin has two exits). After that you may use jetpack to approach the rescuing vessel. That's actually a normal way of doing these contracts but if you don't like easy ways you may, of course, try docking/attaching/etc

I don't remember this kind of contracts in the stock game. Rescuing a kerbal is a common contract but saving the cockpit is something new. Are you 100% sure this contract is not from an addon? How the cockpit is supposed to be "rescued" (I'm leaving aside question "why")? What is the criteria of accomplishing the task? This is perfectly understandable since when a part is moved into the inventory it's get destroyed. For the contract script destruction of the quest part appears as a failing condition. To be honest, I don't see a way to fix this behavior since the object must be removed from the scene somehow, and destroying it is an easy and reliable way. Hiding the object by other means (disabling renderer, removing meshes, moving to a distant location, etc.) is too hacky and will likely have a lot of side effects. A possible workaround could be completing contract right away once the part is moved into the inventory but feasibility of the solution depends on the contract script. The contract fails for the same reason as for the cockpit. Though, the whole behavior of putting kerbal into inventory is totally wrong. A kerbal being is not an object, and moving them into inventory must be restricted. In my development branch it is restricted - you cannot move/attach/detach/etc kerbals. If your mission is to save a kerbal then you need to bring a vessel with facilities to support a kerbonaut: a cockpit or an external command seat.

So, I think I found a solution for the problem. You may try uploading a fixed DLL from https://github.com/ihsoft/KIS/releases/tag/v1.2.3-alpha2-experimental. Though, keep in mind that this is a development binary which is not officailly merged into the main branch. It's basically my development branch which is very far from the original trunk on GitHub. If it does fix the problem I'll make a pull request to KospY. Btw, you also may spend some time testing moving/attaching groups (hierarchies) of parts - that's another feature that is pending in this binary. I'll be very appreciated to hear the feedback.

Consider creating a bug report on GitHub. This way it's easier to track and, eventually, fix the problem. Can you give an example of a failed contract? What was the objective, and what was the quest item? Was it a "stock" contract (carrier mode) or from an addon (name)? From the implementation point of view when an item is placed into inventory it's actually get destroyed, and then re-created when pulled out. I'd say it's not surpising the contarct has failed.

Nevermind. I've added some traces to the code and now see the problem. How to fix it is a question, though.

Did you actually launched the vessel or just switched to the launch table and then back? I tried to switch back and forth 5-6 times and haven't noticed the problem. Though, I had it once so, I agree the problem does show up in some cases.

From technical perspective it's kind of challenging. Every part in the game has at least one attachment node but kerbonaut has none. In the latest official KIS version (1.2.3) you can grab a kerbal but dropping him will likely result in a disaster (depends on either you're on orbit or on surface). In version which I'm being developing (1.2.3-alpha) grabbing of the kerbonauts is explicitly restricted. And, to be honest, I don't think KIS/KAS should implement this feature. If you're an engineer capable to attach a thermometer on surface of anorbital station it doesn't mean you can play a rescuer role "Martian"-style

Situations on the surface and on the orbit are very different. In your case there were wheels on the cart but a regular 1t object in KSP doesn't have wheels attached. When you are on surface first thing to fight with is gravity - you need to lift the part off to be able moving it (i.e. weight is your main enemy). So, I'd say realistic limit should be ~70kg at 1g. Once the objetc is lifted off moving in the horizontal plane is only a question of the kerbals stamina. You can use jetpack to increase the weight limit, though. On the orbit situation changes. There is no weight over there so, you don't need to lift off the object. Though, you need to apply a force to accelerate the object in the right direction, and then apply the same force in the opposite direction to stop it. When distance is only 1m it can be done from a fixed mount point (like a ladder) and use muscular power, but if you move an object at, say, 5m distance you just cannot do it the same way as on the surface. More logic approach would be using jetpack to accelerate/decelerate the parts. And with this approach the distance and number of kerbals doesn't really matter, only the mass does - there should be enough impulse in the jetpack top start/stop the movement. My rough idea for the physics in the addon is the following: On surface: Distance limit: None. Weight per kerbal limit: 70kg at 1g. Jetpack can be used to increase the weight limit at a cost of RCS fuel. Atmosphere does affect jetpack's ISP. Exact cost for 1kg of the mass is yet to be determined (it should be reasonable). On orbit: When on ladder: Distance limit: 2m (radius from the kerbal). Mass limit: 300kg per kerbal in range. RCS cost: None. When EVA: Distance limit: None. Mass limit: None. RCS cost: proportional to DeltaV=1m/s. Multiple kerbals can be used to increase the fuel reserve (thus, increasing mass limit).

Do you know what was FPS when the problem happen? I've noticed strange behavior of the interface when FPS drops below 10 (a usual situation on my PC for a big station).

Attach external command seats in range of the operation, and assign the required number of kerbals. Though, I'd not say it's perfect. From physics point of view in order to move a heavy object on orbit you need spending RCS fuel and not bringing more kerbals. Btw, that's one of the improvement ideas I'm working on.