IgorZ

To start with, KAS doesn't deal with attaching parts. It's KIS that does. And you say you haven't used KIS to attach the panel. So, what part of KIS or KAS have you used? Why do you believe any of these mods are related to the issue you observe?

Could you please try reproducing the error and attaching the logs? There is no any dependency on KSPDev in CKAN config. I wonder how CKAN could even match KAS and KSPDev.

How exactly did the KAS failed and how you knew it was indeed KAS? Was it a record in the logs? Just to clarify, the following record from the game's log doesn't indicate a real error. [ERR 14:57:18.948] ADDON BINDER: Cannot resolve assembly: KSPDev_Utils.2.6-KAS, Culture=neutral, PublicKeyToken=null

The magnet can be used on the unmanned crafts. All the other parts require a kerbal EVA.

Okay, it seems the "harpoon" topic gets the audience. So, let me share some insights. Here is the plan that I've made when working on the KAS v1 design (and this plan didn't become live): "HP-01 Harpoon" only attaches to asteroids and celestial bodies surface. You cannot hook a kerbal (it's a live being) or a part (it's metal and sturdy). Attaches at impact. EVA is required to detach the harpoon from the asteroid/surface. "HG-02 Grappling Hook" only attaches to the solid parts (no kerbals allowed). Attaches at impact. EVA is required to detach the hook from the part. "HE-03 Electro-Magnet" only attaches to the solid parts (no kerbals allowed). Attaches to the nearest part in range (limited) once the electricity supply is provided. No EVA required, it can detach from the winch action by just deactivating the electricity supply. #1 and #2 don't require significant mod changes. I think I can make it pretty quick (given KISv2 is in beta). #3 is a different story - it will require the core changes. You're free to throw your ideas and suggestions before the actual work has started.

No, KIS calculates volume based on the meshes. The stock implementation is based on the renderer and collider boundaries. In the normal case the boundary of a renderer should match the boundary of its mesh, but I've seen edge cases when it was not the case. Here is the code: https://github.com/ihsoft/KIS2/blob/4e718797258f581080df1f966c486f0e987bb315/Source/api/Utils/PartModelUtilsImpl.cs#L176

To be more precise, KIS will be incompatible with the stock inventory GUI. The code that properly deals with the stock inventory API should not be affected. The only open question here is what is "properly"? FWIW, the stock inventory API is not existent. So, in the end, it will depend on the implementation of a specific mod.

And now we have +4 "chime ins". Which totals to 6 per a year, which is an absolute record this far! I heard you ladies and gentlemen. Once KISv2 is in beta, I'll get back to the "ejecting things" in KAS.

The KIS and stock inventory systems are not working together. They are two different systems. If you put stuff into the stock inventory, you have to use the stock functionality to use it. If you put stuff into KIS, you can only use KIS functionality. The only way of moving stuff between the inventories is dropping the parts on the ground and then picking them up in the right inventory mode. However, there will be a lot of edge cases. You may want to join the KISv2 alpha testing which addresses it, but it's only an ALPHA. Such versions don't have enough stability to be used in the carrier games.

TWO in a year - checked.

There was no intent to remove them altogether. About that time Squad started adopting the newer Unity versions that changed physics a lot, and made many of the KAS harpoon parts not working properly. The idea was to get back to it when KAS 1.0 is fully done and re-design the parts on the new codebase. However, I didn't find time for that. If there will be enough people who chime in for this feature, I may reconsider the priority. So far there were may be 4-5 inquires with regard to these parts in a timespan of about 3 years.

Because this is how it would happen IRL. In the old approach you were putting two 8kg connectors, and then pulling 30m of pipes out of nowhere. If you still like this approach, it can be activated. Read some pages back, this question has been discussed here multiple times.

It's impossible to help without extra information. Can you capture the logs from the game and share them (read here to learn how)? A short video would be helpful too.

Could you please record a short video and provide the logs?

Have you checked the videos in OP? They cover pretty much all the functionality. Yes, it does.

1.10 (October 20th, 2021): [Fix #326] Error in the logs when an inactive vessel gets in range.

Great! Thanks for this samples. During the KISv2 work I've almost decided to stop using "a ghost" and start using the real part appearance (and as of Apha2 this is the case - no ghost). However, after that I've discovered that it sometimes introduces confusing due to the part being moved and the "ghost part" look too similar. Options (Kowalski)? As of now the "ghost part" is colored with green/red to indicate the state of the attachment/drop action, but it may not be enough. Plus, such coloring may interfere with the part natural appearance. Out of the scope of this topic. It seems you're a kOS fan. I never used it, so some people who worked with it are very welcome in the KISv2 alpha testing. If I can make the new mod more friendly to kOS, I will. They have an excuse that KIS also allows "attachments". Not to mention, KIS and KAS were once the same mod. KAS should probably be named differently to indicate that it doesn't deal with parts attachments, but instead deals with the vessels connections. Kerbal Vessel Connection System, maybe?

By a chance, can you draw a mockup? I'm not sure if I fully understand how it should look like and what's the benefit.

Given the context, it's a KIS (Kerbal Inventory System) issue. Please, capture a short video and the logs, and report it to the right forum thread.

Alpha-2 New features to this build All operations with the inventory are now made using the stock methods ONLY. This deprecates the respectStockStackingLogic compatibility setting. The stock GUI should be able to handle the overflowed stacks. I.e. the stacks that are bigger than configured in the cargo module must be handled just fine by the stock. KIS now uses the STOCK inventory volume. There must be a full sync between the two GUIs. The parts with negative volume can now be added into the stock inventory via the KIS GUI. The volume should be accounted correctly, using the KIS geometry estimation algo in BOTH of the GUIs. The non-cargo parts should be successfully added and processed via KIS GUI, and be moved/removed in the stock GUI as well. The stock GUI is not expected to ADD such parts. All actions are now checking the volume restriction. The spawn new part dialog included. New parts can now be spawned in the KIS inventory if BuilderMode.enabled is set to true. A hint should be showing up when hovering over an empty slot. Clicking the suggested sequence will produce a spawn new part dialog similar to the old debug KIS dialog. The stack sizes are now limited in both KIS and STOCK. The KIS limit is 500, and the STOCK limit is 99. It can be overridden via the part settings: maxStockSlotSize/maxKisSlotSize. New test parts added: "KISv2 test inventory SMALL" and "KISv2 test inventory VERY SMALL". The offer lower space for the items. Testing features The hotkeys to produce various "sample" parts in the inventory if AlphaFlags.enableInventorySamples is set to true: ALT+1 - adds three random fuel parts that are loaded with resources at 100% of their capacity. ALT+2 - adds a random fuel part that is loaded with resources at the 10%-50% range level (randomly). ALT+3 - adds a random fuel part that is loaded with resources at exactly the 50% level. ALT+4 - adds a random fuel part that is loaded with resources at exactly the 100% level. ALT+5 - adds three instances of the same random fuel part that is loaded with resources at the 10%-50% range level (randomly). Only the inventories with an open GUI will get updated. Not all parts will get added due to the compatibility constraints. Verify the logs. The main focus of testing of this build Add things to the inventory and ensure they can be managed in both KIS and STOCK GUI with no issues. Try to break the logic. Try various save/load approaches to break the KIS/STOCK sync. Hints: Quick save/load at the arbitrary moment. Switching scenes. Launch rollback. Try to break the spawn part dialog approach. And give your thoughts on it's usability. This dialog will become an essential part of KISv2 "builder mode" concept. We want making building in EVA comfortable. Check how stable and useful is the stacking approach of the parts with different resources (see FR#2 to learn how to generate sample parts).

Which part(s) have you tried? How exactly they didn't work? Do you have logs? Also, I strongly recommend you to check the OP videos and images to verify if you're using KAS the way it's intendent to be used.

Yes, it's the only way. KISv1 lives completely separate from the stock inventories. It's going to change with KISv2 release, but it's in an early development yet.

It won't be exactly same. For the resources consumption you can simply set a timer, which is cheap performance wise. It's trivial to calculate for the how long the selected resource will last, given the known consumption. Things change when you have ISRU and one of the ends is inactive. Now you need to handle the inactive end on every fixed frame (regardless to if it's a source or a target), which is a lot more expensive than a simple timer. Not to mention you would need to implement a whole new bulk of code to process the unloaded vessels. It is much more complicated then you may assume before looking into the real code. I'm not saying it's impossible at all, but it will require substantial development and testing efforts, and would roughly double the amount of the code to maintain. To start with, the resource flow graph is a thing that is built on vessel load and gets updated during the vessel life cycle. This thing cannot be fully simulated without wakening up all the modules on the vessel. Any approximation algorithm will likely break the mods that deal with the dynamic resources. Given the use case, I'm really not sure if it ever become a stock feature in either KSP or KSP2. One possible workaround could be making a code that would prevent vessel unloading if it's attached to an active vessel. There will be edge cases, and it may be not feasible at all, but it's the best bet.

They don't. The amount of the produced resources is calculated on the vessel load.

No, the parts in the the both ends of the KAS link must be active parts. Working with the unloaded vessels would be so much burden that I'd not even try to do it.