Mythos

Those docking problems tend to be not so quick to explain Maybe this post may help you to get your undock button. Even after fixing the structural problem, KSP often needs a little help about which context buttons to enable: About the question if this problem could be invoked by wrong building: If I look at your screenshots I would rather concentrate on part [7], a docking port that is node-attached to the root [0] and has another part [8] node-attached to it. So if both sides of the dock are occupied, where should you dock to it? Maybe you placed part [8] to it and used the move-tool so that is placed further away and it looks like the dock is now free to go. But KSP tricks you then, it really is a problem that the link goes to that node. I think I've seen such kind of problems multiple times. If you think [63] should not be radially attached to [9] this also sounds like a situation that I find KSP to have problems with: Usually we think of a vessel like a tree structure, anything new either node- or radial-attached to something existing. But then you dock things together where the ports were radially attached. And then the problem comes when we have a new tree where now the first thing to see is the dock and another tank or so links "radially attached BY" to existing parts, the other way round like the normal "radially attached TO" link. This is a type of connection that's rare for single vessels (can happen in VAB only with the change root tool) and I think causes problems with docking.

No, orientation of the vessel in flight has nothing to do with it. It's the way it is oriented in the VAB.

Oh well, now I see the dimension of this problem The connection that does the real dockee-docker thing and not the same-vessel-docking thing is also melt into the parent-child structure of your part tree. Sounds reasonable that this influences fuel flow. But because of the parent-part-tree it's not as easy as changing the same-vessel-dockings to be dockee-docker and vice versa. The structure drawing tries to keep up-down connections in the up-down manner with dark green lines, but left, right, front, back (wherever those are) in a X-shape with light green lines around some center part. And then the yellow lines stand for surface attachment, also arranged in X-shape with many legs. But then, when the space gets full, parts are just placed at free slots in the grid-structure and then it gets messy. I think it is not a good visualization for more than five things docked together, it gets really messy quite fast. In most cases once you have identified one part of a substructure the other parts of that substructure are the neighboring part numbers. You would like to have all parts of a substructure highlighted? At the moment I am spending not enough time in KML development. But maybe this idea sticks in my mind and I may try that out.

What is part #14 meant to do? In this case I would advise to delete part #14 and change #13 to "ready" so it looks like any of the functioning ports. To fix just the docking problem and keep the vessel at it is, have you tried the repair function in the right click menu of the parts? If repair is not available, it is a bit tedious to set this up manually. I may give some advise, only if really needed. As far as I remember, the "aquire" state happens during the docking process. So it looks like this mess happened while a docking attempt that somehow did not finish correctly in part structure concerns.

In my experience it remembers where you opened last time just by windows functionality, that was always convenient to me. And I rarely install games in program data which I still consider a good advice. Most users will need to find their steam library anyway (I bought KSP standalone). So the first time opening KML will always need hunting down your save dir in some fashion. Second time already does not.

Just uploaded release 0.8, see OP. Thanks alot to @pamidur for contribution.

I always wondered if that could happen during trans-wherever-injections or coming from far out for aerobraking. Only one day I've seen a marker rushing by and could catch a number about 1 km. I only ever crashed into something after undocking from my equatorial station and not looking for the station doing my burns I seldom use multiple version scanning the same topic. Usually I have 3 scanner vessels per body at 750, 250 and 150 km polar orbits, so they never come close. I like to launch them in a bundle so they even are in the same plane. As for the dozenS that include passive satellites, but about one dozen is active and really needs my attention from time to time. Like in between trans-minmus-injection and orbit-insertion around minmus there are many days to do multiple launches to LKO or hopping from anomaly to anomaly on mun or something like that. Of course you need Kerbal Alarm Clock for such managing. And it turns out if there is about an hour of time to the next alarm, I'm looking for such things to do next, not "wasting time just waiting". Sometimes it turns out having two maneuvers same time, then you need to decide wich one can just wait another orbit. And before doing a reentry burn I need to look if there are no maneuvers planned for the next 30min. I remember DMagic telling that disabling those scanning devices via right click menu is better than turning of "background" scanning for a whole body. I once wondered why BTDT does not give names to my anomalies I visited after having 100% of the map, it was because this also belongs to "background" scanning and was turned off.

As for 1.4 we need to wait for 1.4.1 and all the wanted mods I think. Maybe 1.4 changed too much to merge an old career from 1.0 that survived up to 1.3.1 now? Got it downloaded but didn't look into yet. Every time I got stuck into micromanaging my space agency having dozens of flights running... And every time I'm almost going to finally visit another planet for my very first time, a new version forces me to start from scratch and doing mun and minmus over and over... :-( I had that 0.23 to 0.23.5 career, started scansating moho, no kerbals yet. Then a 0.90 career, no interplanetary at all. And now that 1.0 to 1.3.1 career in the very ends of year 1, Jeb and his team half way to duna now... Concerning my problem I found the conflicting mod: AutoLoadGame! If I have this xor ScanSat it works, but together ScanSat looses :-(

Anyone else solved a problem with toolbar button not showing up? I just commented on github issues. As now 1.4 is out it is time that I merge from 1.2.2 to 1.3.1 :-)

Oh well, I may never notice such kind of problems, as by design I always install games to something like c:\games, just a normal folder that behaves normally instead of having complicated things going on with c:\program files I added a warning message to KML for such cases, will be included in next release.

@EwingKang I could not see where the problem is. I loaded your save with KML, fixed all problems, then reloaded the save in KSP 1.3.1 and then I could undock. Here is the save after the fix before undocking: EwingKang_fixed.sfs

I made some progress and implemented part deletion for any part that's not parent to other parts. This would usually mean any outermost parts. I didn't like the idea to click delete on one part and causing some chain reaction to delete all dependent parts, worst case all parts but root. Of course you can delete your way forward step by step (easiest done in the graph view in vessels tab). This would fit my needs... Would it fit yours? Not released yet, but it's in the preview build (the ZIP mentioned on bottom of OP). KML.zip in this version has some issues with false positive virus warning with Windows Defender. Didn't find a solution, maybe solved after more code changes, see https://github.com/my-th-os/KML/issues/3#issuecomment-322055507

I also think this would be handy, but as you said it is difficult. As KML is still pre-release I might add more standard features first. Like copy & paste of anything or deletion of parts (this is related to the root part problem and might get difficult also and would lead to having the root change just a little more work). I personally changed root part in my own save recently like that (KIS/KAS connection linking and unlinking caused root to be the KAS-port pointing sideways): dock your problematic vessel to a station (watch out for the problem vessel being docker and the station or whatever other ship being dockee). save and open with KML navigate to that docking connection, identify all related parts (both docking ports and the part you want to be root, and maybe the part that is current root) by part number and UID on the docker side the part will contain a MODULE (ModuleDockingNode) and a DOCKEDVESSEL node therein There you should check the "vesselName" to be your problematic docker vessel and then just change the "rootUId" to your liked part UID save in KML and reload in KSP undock and KSP will reorder the parts for you to have the given part the new root This does not sound correct. The save .sfs file is independent from any .craft file, because it already contains all vessel connection information. This is why some people have the need for a tool to get .craft files out of vessels within a .sfs file. Maybe they launched unsaved vessels and later want to reload them to the VAB.

Thank you for teaching me something new about docking. I understand the problem and got your savefile to reproduce it. For the moment it seems complicated to rework the docking test for multiple docks per part. I could just not check such ports and so skip that warning. But that is not my intention, KML should rather do more checks if it would understand multiple docking ports. But I can assure that you can ignore that warning and use KML for editing such a savefile. The docking information will stay as it is. You just should not try to use the repair-feature on any docking warning with such a multiple dock involved on one side. As I said about warnings on KAS ports... Not all mod parts are supported and you should read warnings about mod parts like "there is something about that part KML does not understand". And if you know it's due to a mod, than ignore those warnings. I intended to support KAS ports, but also did not found the time to do so far.

For the moment KML can load craft-files because it was no big deal. But any check for problems does only work for savegames so far. Now I know about this possible bug, I may add a check for this.

I'm currently in test stage to migrate my savefile from 1.1.3 to 1.2.2 so I have both versions running. Today I started KSP 1.1 and was quite irritated that it refused to start as usual but on my second monitor instead. Playing around with some windows settings (that I did not touch beforehand) did not change that behavior. Testing other games told me its a KSP issue only. Starting KSP 1.2 again I was quite surprised that it started on the primary monitor. Finally I searched the registry, having some hidden windows settings in mind, but instead I found "HKCU\Software\Squad\Kerbal Space Program\UnitySelectMonitor_somenumber = 0" I then changed the value from 0 to 1. And that did the trick and switched KSP 1.1 back to primary monitor. But then I noticed KSP 1.2 is now running on second monitor... How funny, both have exact opposite monitor preferences To clean things up I just renamed that registry key and tested again. Conclusion is KSP 1.1 did not have that registry property at all, it appears when KSP 1.2 is started first time. But when it is there also KSP 1.1 does his thing with it, which is just the opposite thing you'd expect. Just telling you in case someone else encounters this problem as well...

For some errors I noticed you need to fix in KML, open the new save in KSP (maybe do something like try to undock), save again and then fix with KML a second time. Maybe it was one of those.

I started to migrate my own save from 1.1.3 to 1.2.2. Still not done with that but managed to have 1.2.2 working with all the mods I use. First tests are looking good for continuing the save. I realized the new vessel types plane and relay, at least this has to be represented in KML. So I made this little change, not touching all those more important points from the TODO. Time for that will come one day... Pre-Release 0.7.2 is now on GitHub and OP updated.

I've read many rumors about the rules for this, but the mass theory is new to me. I can't explain exactly what is happening, but my experience tells it has to do with which ship was build latest (the older ship likes to be dockee) and the type of the ships (stations tend to be dockee and such). Confirmed. If you know what you're doing, deletion of broken content is often the fix.

Can you explain what KML has identified but could not repair?

3 of 5 commits have only been tests to prepare coming changes... That will take longer than expected, I'm sorry. 2 commits about minor issues where I would not expect them to happen very often. You can have a look at the preview changelog and download the zip with the preview built I linked in bottom of first post (updated right now).

As I said to the one asking for Linux: It's very unlikely. KML is a WPF application and WPF does not run on Linux or macOS even with mono. So the whole GUI needs to be rewritten. I'm curious to do so, but I don't have the time. Maybe anyone want's to fork the project? Mentioning time... I really misjudged my current situation when I said I will have time to work on KML soon... I don't! :-(

I didn't notice any changes in savegame syntax for any version update lately. So I would say its compatible with at least any version from 1.0 to 1.1.3.

You could go to the part and change its name. I can't tell anything about placement of different sized parts, but replacing a LFO-Tank by LiquidOnly-Tank of same size does work this way. Maybe any surface attached part work as well. Because of this positioning problems and unpredicted behavior in general, it may never be automated,. I had a look, and this is seems to be a good tool for part removal. But he does interpret the game file in his way and I do it differently. Its not only about deleting in the resulting game file. I need to manipulate my own representation of parts to remove them. What to do about deletion is almost straight forward, but its more than a few lines. Its on the TODO list, but not on top I didn't manage to code KML for quite a while, but I will do soon.

I'm sorry, it's not likely that KML will be running on Mac or Linux some day, since it's made on WPF. If you upload your savefile I may try to repair it.