IgorZ

KAS v1.0 doesn't allow connecting two JS-1 ports by default, which was discussed a dozen of times on this forum. That functionality has been deprecated 3 years ago! I wonder why people keep referring to it. Is there "a respected source of truth" that says the old functionality still have to be existing in the current KAS? I'd love to get in touch with the maintainer. TL;DR; Either use the source connection parts like TJ/RTS, or find the "MM-LegacyKASPipesPart.txt" file in the installation and follow the instructions in it.

What does make you suggest that KAS may be the reason? I don't see any KAS interactions in this video. Try removing KAS and repeat the steps.

Thank you for your thoughts. So, it fits my vision too. The rule of thumb is: if a part can be carried/moved by the kerbal(s), it must be allowed for this regardless to the fact if the part's maker bothered to make an EVA config. And if the part can be moved and fits the inventory by the volume limit, it must be able to be placed into it. A side question is the mass limit. In the stock inventory it's an optional limit. And as far as I can tell it was mostly designed for the kerbal personal inventories. The question is: should a non-kerbal inventory have this limit? What is the use case? When we speak about a space craft, we all understand that the mass of a single part is not what defines the launch success. So, why limiting an inventory by mass?

A brainstorming is needed. GIVEN: The stock inventory system allows restricting parts from any EVA interaction. It also can enable a part for EVA movement, but not for the inventory storing. What are your thoughts? What real cases do you see where this behavior can be useful? When would you like to have a part that cannot be moved in EVA? Or can be moved, but not stored into an inventory? I'm asking because I need to understand if it's a user feature which needs to be preserved, or if it's a purely a technical limitation that should be worked around in KIS.

Hmm. If you're not using KIS, I wonder why do ask questions on this forum thread? Any stock inventory issue must be reported directly to the Squad team.

I guess it's a KIS thread question. Anyway, please, clarify which inventory are you referring? The KIS and stock inventories are completely independent of each other.

Done. Thanks for pointing this out. Great! Thanks a lot. This would be very helpful. In Alpha-2 I'm going to release a lot of code changes while the GUI stays the same. So, the same functionality would need to be verified. Good to know. I'll check it out to see if KIS conflicts with it or if it can use it.

I so got used to MM that it's like a stock game for me now. Indeed, you need this mod installed. I'll be adding this mod into the alpha releases going forward. Thanks. This and other mods are optional. FWIW, specifically Clickthroughblocker would not give any benefits with KISv2 since the dialogs are already working right. Given you have MM installed, a new part should appear: "KISv2 test inventory". This is the only part in Alpha-1 that supports KISv2. You should be able to open KISv2 dialog for it in the editor. If you don't see PAW option "KISv2: Inventory" for the aforementioned part, then it's indeed a bug. Please, share the logs (with the verbose option enabled). A small video would be also very useful.

Yes. KIS will prefer using the stock module to get the volume, but if there is no such module or the part is explicitly excluded ("stockVolumeExceptions" setting), then the model boundary will be used. In the full mode, KIS is not compatible with the stock GUI, so it'll be hidden altogether ("hideStockGui" setting). However, if the GUI is not hidden, then the fix won't get affected by KIS.

I'm doing my best, but I need a help of the community. Thank you for expressing a willing to participate in the test.

Wow! What a big project!

Eventually, yes. The idea is not yet finalized though. My rough idea was to stop applying the hards limits and, instead, adding a resource cost to the actions. E.g. if you're on orbit, then you spend EVA fuel to move the parts. And if you're on the surface, you'd need to spend electricity, assuming your character is using an exoskeleton to move the heavy parts. Again, it's a very rough idea at this moment. The main focus as of now is to give a new inventory access. You can disable the stock GUI via the settings. However, I'd not recommend it at this point. Eventually, KISv2 will replace the stock GUI completely. Note, that the main idea is not to disable the stock inventory, but replacing the GUI to it. Under the hood, if a stock inventory is being changed, the KIS inventory will obey. That being said, any mod that deals with the stock inventory, will be compatible with KISv2. And any mod that deals with the KISv2 API, will be compatible with the stock inventory at the extent of the compatibility settings.

Finally, the alpha testing of KISv2 has started!

Alpha-1 Installation: The mod should be located at: GameData/KIS2. The latest compatible ModuleManager is required. What this build MUST have: Only one part supports the new inventory: "KISv2 test inventory". It's a copy of the stock "SEQ-24 Cargo Storage Unit" part. Any item or a group of items can be moved between any KISv2 inventory windows. In editor, a part can be dragged from the editor's panel into a KISv2 dialog. In editor, a part can be dragged from the editor's working area into a KISv2 dialog. And vice versa. In editor, the parts can be moved between KISv2 and the stock inventory dialogs. In flight, any changes to the STOCK inventory dialogs should be reflected in the KISv2 dialogs. In flight, any changes to the KISv2 inventory dialogs should be reflected in the STOCK dialogs. In flight, KISv2 and STOCK inventory are not cooperating. If you pick a part from the STOCK dialog, it will ONLY be recognized by another STOCK dailog. This also applies to the KISv2 dialogs. Interaction via KISv2 respects the stock inventory settings in terms of stack sizes and the overall number of slots (in the stock module). How is this build INCOMPATIBLE: In flight, the drop part functionality is not tested or tuned. You can use it, but please don't file the bugs. It'll change in the following releases. In flight, you CANNOT pickup any dropped part. KISv2 dialog allows adding more parts than the STOCK GUI allows by volume. When it happens, using of the stock GUI will result in a lot of bad issues. Please, don't report them. You can adjust the compatibility settings as stated in the Wiki. However, it's a gray zone. Nothing was tested by me in there. Good luck!

Attention! This is not a real mod. It's a concept of the mod, and here I'm trying to attract a broad audience to test it. All the builds are debug and it should be expected that they lack of the functionality and have bugs, including the severe ones. You should absolutely not be considering these releases for your carrier games. READ CAREFULLY what's stated below BEFORE getting yourself involved into this test. Backwards compatibility For the alpha test a dedicated part is created ("KISv2 test inventory"), and only this part is subject to the new KISv2 logic. I.e. the other parts in the game will not be affected. However, the inventory carried by the kerbals can potentially get affected since KISv2 module will be added to all the kerbals. It should not have any consequences, but it can! I did my best to not allow the ALPHA logic to affect the stock game logic, but (bad) things happen. The goals of the alpha testing Play with some of the solutions that are already implemented to see if they fit the gamestyle of the community. Find the edge cases when the new functionality fails. In my manual tests I can only cover the cases that I can predict. Let people trying the approach and suggest their own ideas. How to install the release and what to expect For every release there will be a separate post in this thread. There will be a description of what is being tested and what are the limitations in the release. Scroll the thread down to the latest release post and follow the instructions in it. Keep in mind that the backwards compatibility between the releases will not be purposely maintained. For the sake of saving the eng efforts, I won't be spending any extra time to make the older saves compatible. If the new release is incompatible, it will be stated in the release notes. If it's not stated, then the release is compatible. How to participate Please, give your thoughts in this forum thread. If you've found a bug, please consider to file a bug in GitHub rather than explaining it here, in the thread. A lot of bugs are expected to be discovered, and we don't want them to spam the thread. And, in the end, any bug report will have to be transformed into a GitHub issue anyway, so you may save a bit of my time. Make sure you've enabled the "Verbose logging" setting in your game. A detailed log is the key to the issues troubleshooting. Please, always add the logs to any issue report.

Can't tell. I didn't investigate this feature deep. In fact, the absolutely rigid link is not possible in PhysX. The objects need to shift beyond the joint's threshold for the engine to start applying forces. Thus, there always be some error in positioning.

All joints between the parts in KSP are actually "rubber". There were times when KIS/KAS were creating truly rigid links, but they were easily breaking during the loading. So, I decided to not be a smart a$$ and simply copied the joints settings from the stock game. After all, the Squad team had a reason to choose such settings. That being said, all the KAS links are "rigid" only to some extent. The JS part provides a tiny docking port capabilities. You cannot go over it without changing the parts configs. Just and FYI. The size of the attachment node is not simply a visual thing. It also defines how many actual PhysX joints will be created. The larger the node size, the more joints you get. And guess what, it affects the performance! With all nodes being LARGE you'll get a really rigid vessel, but the FPS price will be severe. And speaking about the reaction wheels. This issue dates back to ancient versions of KSP. The rule of thumb: don't have more than one reaction wheel active on your station. If your wheel is not powerful enough, bring a bigger wheel. You may use KIS for that Sometimes, even with one powerful reaction wheel, a big station still starts wobbling. The workaround that always worked for me was quick save/quick load. Sometimes you may need to repeat it couple of times though

In the "UNDOCKED" mode its already working this way: the vessels are loaded as detached, and then the connection is restored. It's different in the "DOCKED" mode. There, there is just one big vessel even though you see it as a set of vessels connected via RTS. In this mode detaching before loading and attaching afterwards will kill the ISRU functionality, since it distributes the accumulated resources on vessel load. It happens due to shifting of the CoM. In the docked mode CoM is roughly located in the middle part. When you undock, the side tanks become separate vessels and each gets its own CoM while the middle vessel gets its mass significantly reduced. Nothing can be done here. I can only suggest making more strong foundations under the big tanks to make the rapid mass change less disturbing.

If you're wondering how KISv2 is progressing, you can checkout the first public release (debug).

In KPS all parts are attached via "nodes". KIS uses the opposing orientation of two nodes as the base configuration. From there, you may adjust the offset and rotation to some extent. What you see in VAB is a stock editor aligning functionality. They connect the parts via the nodes too, but in this case editor offers a convince of an automatic alignment. That beings said, until this functionality is explicitly implemented in KIS, making big flat surfaces will be a problem. In fact, I've just tried to play with it and found that you still may find a good pair of nodes to align the parts. I used SP-S12 as an example. This part has 9 attach nodes, so there are "only" 81 unique combinations I was able to find a right pair in less than a minute.

Could you please make a short video and provide logs captured during this session?

The stock system is very picky about what can be stored in the inventory and operated in the flight. If you cannot use the stock inventory, just store the item into the KIS inventory. You won't get the benefits of the stock inflight editor, but you'll still be able to attach the parts.

https://github.com/ihsoft/KAS/wiki/Legacy-parts-destiny TL;DR; There are no electromagnet parts as of now.

You've brought up a very interesting issue. I never thought about it before. I've created a feature request in KIS. No chances it will be implemented in the legacy KIS, but this is something to address in KIS v2.

Wow! Are you playing a fuel dealer role in the game?