[WIN] KML - Persistence file editor

[diomedea]

Can't find what follows reported yet (if I missed it, sorry!).

Parts with multiple docking ports, when at least 2 ports are docked, can bring to errors in KML. 

While such parts are not existing in stock KSP, they do in add-ons, I did test with the Command Module Hub from Tokamak Industries (Note: I have a recollection from times old multiple docking ports with a part were an issue in KSP, therefore highly discouraged; however the vessel I used in my tests doesn't raise any trouble (no errors, exceptions, warning in the log and debug console) and works finely in KSP).

What I am seeing from examination of the savegame, a part with multiple ports has multiple "ModuleDockingNode" modules; each will have the dockUId field set to uid of the docked part; from the docked parts side, each has the "ModuleDockingNode" module with dockUId set to the corresponding part with multiple ports (so, dockUId can be identical for multiple modules in the save), however the "dockNodeIdx" field is set to a different index for each part.

From what little I can get about how KML works, it reports an error due to checking correspondence of the uid, parsing data from only one "ModuleDockingNode" module with each part so failing to find the correct correspondence in case of multiple docking ports with a part.

I'm attaching savegame and pictures of KML showing vessel structure (with docked parts) and data of the Hub.

[Mythos]

On ‎22‎.‎02‎.‎2017 at 11:49 AM, diomedea said:

Parts with multiple docking ports

 

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.

[Teslamax]

Would it be at all possible to allow re-defining the root part on a craft in flight? I've heard its difficult and might require alteration of the .craft file as well.

It sounds too complicated but if you could implement it, I would be appreciative.

(RoverDude's Construction ports won't compress if one of them is the root part.)

Sorry, this issue was covered previously. Just noticed the KAS/KIS solution myself. "Nothing to see here."

Edited March 19, 2017 by Teslamax

[Mythos]

1 hour ago, Teslamax said:

Would it be at all possible to allow re-defining the root part on a craft in flight? I've heard its difficult

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

 

1 hour ago, Teslamax said:

might require alteration of the .craft file as well.

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.

[includao]

I freaking love your program. Thanks, very useful

[Starslinger999]

Does this work in-game? Does it have compatibility with the "K-PAD" From 

[Ruedii]

OK, I tried running it with Mono on Linux and it won't run due to "entry point method cannot be loaded."

I'll take a look at the code later to see if anything stands out but you probably need someone with more experience getting .Net programs working on Mono under OSX and Linux.

[Mythos]

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

Edited August 13, 2017 by Mythos
Info about false positive virus warning

[rich216]

is there anyway you can make a macOS version?

 

[captinjoehenry]

Thank god for this!  I encounter the docking port bug again in 1.3.1 and this fixed it perfectly!  Thanks a ton!

[Mythos]

Just uploaded release 0.8, see OP.

Thanks alot to @pamidur for contribution.

Edited May 5, 2018 by Mythos

[JAFO]

15 minutes ago, Mythos said:

Just uploaded release 0.8, see OP.

WooHoo!

Many thanks! 

[Apaseall]

This also looks interesting.

[Gordon Dry]

How about defaulting to look into the application's folder instead of user documents when opening the first time?

Or even a small settings tab to define the game path?

[Mythos]

54 minutes ago, Gordon Dry said:

How about defaulting to look into the application's folder instead of user documents when opening the first time?

Or even a small settings tab to define the game path?

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.

Edited July 21, 2018 by Mythos

[Rakaydos]

So I'm attempting to figure out how to use this to fix broken docking ports, and looking for help.

The problem docking ports, if I'm reading the schematic right, are #13 and #14. The schematic says that #14 is associated with the ship, but not connected to the ship? How can I change that?

The folder view thingy says 13 and 14 are in "aquire." Do I need to change that to docked, dockee?

Edited September 1, 2018 by Rakaydos

[Mythos]

2 hours ago, Rakaydos said:

The problem docking ports, if I'm reading the schematic right, are #13 and #14. The schematic says that #14 is associated with the ship, but not connected to the ship? How can I change that?

The folder view thingy says 13 and 14 are in "aquire." Do I need to change that to docked, dockee?

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.

[Rakaydos]

4 minutes ago, Mythos said:

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.

I grabbed an old Debris with the same problem to learn the program before I tried messing with the main ship. Part 14 was attached to a decoupler (for fuel flow planning).

I think I figured out manual repairs, but I notice a fuel flow irregularity in my main ship that I'd love to fix in the editor instead of in flight, but is likely to be a pain in the ass to locate.

There were 5 pages of docking errors I went through and fixed in the editer. The fuel flow irreglarity is an artifact of the multidocking- the "part tree" connects one of the edge docking ports first, when I want the center port of each layer to carry fuel flow. Is there a reasonable way to identify which part# relates to a part of a structure? temporary Color edit, perhaps?

[Mythos]

Oh well, now I see the dimension of this problem 

25 minutes ago, Rakaydos said:

I think I figured out manual repairs, but I notice a fuel flow irregularity in my main ship that I'd love to fix in the editor instead of in flight, but is likely to be a pain in the ass to locate.

There were 5 pages of docking errors I went through and fixed in the editer. The fuel flow irreglarity is an artifact of the multidocking- the "part tree" connects one of the edge docking ports first, when I want the center port of each layer to carry fuel flow.

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.

Is there a reasonable way to identify which part# relates to a part of a structure? temporary Color edit, perhaps?

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.

[Rakaydos]

10 minutes ago, Mythos said:

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.

In most cases once you have identified one part of a substructure the other parts of that substructure are the neighboring part numbers.

So in orbit, "up/down" is normal/antinormal or radial/antiradial?

Quote

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 I think would be amazing , though probably not related to your skillset, is to have a visualizer that uses the part data to recreate your ship in an window, with whatever part you have selected in the editor highlighted. As a stop gap, I was wondering about being able to visually change a part, load it into KSP, and figure out where it was in the ship that way. We'll see how well orienting the ship works to make it more clear.

[Mythos]

2 hours ago, Rakaydos said:

So in orbit, "up/down" is normal/antinormal or radial/antiradial?

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

[Nicky21]

I managed to fix my 2 stuck docking ports with this tool. Thank you for this !!!

[pseudamin]

Hi.

I have a quick question. I had some problems undocking a station part that I was ferrying in a shuttle to a station. The station part in question built (in VAB) into a cargo bay of an SSTO Shuttle, connected via docking ports. When I docked the shuttle to the station, there turned out to be no "undock" options in the context menu for the docking ports holding the station part in place in the cargo bay. So, looking for a solution I came across this program.

The question: the docking parts on the station part show up in KML as "disabled" and I'm not entirely sure what this means, in terms of docking status, nor how I can change the status? Additionally, I do not know if this will solve the lack of an undock-option in the parts in-game context menu. 

It looks like the docking port in question is not connected to the shuttle part as I built it in the VAB. The ferried station parts docking port [87] should have been connected below [7], rather than the main control module of the station part [63] being radially connected to [9]. I don't know if changing this structure will solve the abovementioned problem or not. But is possible to edit hierarchy in KML?

 '

 

Edited March 17, 2019 by pseudamin

[Mythos]

On 3/17/2019 at 9:29 PM, pseudamin said:

I have a quick question.

Those docking problems tend to be not so quick to explain  

On 3/17/2019 at 9:29 PM, pseudamin said:

The question: the docking parts on the station part show up in KML as "disabled" and I'm not entirely sure what this means, in terms of docking status, nor how I can change the status? Additionally, I do not know if this will solve the lack of an undock-option in the parts in-game context menu. 

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: 

On 3/17/2019 at 9:29 PM, pseudamin said:

It looks like the docking port in question is not connected to the shuttle part as I built it in the VAB. The ferried station parts docking port [87] should have been connected below [7], rather than the main control module of the station part [63] being radially connected to [9]. I don't know if changing this structure will solve the abovementioned problem or not. But is possible to edit hierarchy in KML?

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.

[pseudamin]

19 hours ago, Mythos said:

Those docking problems tend to be not so quick to explain

Too true. 

19 hours ago, Mythos said:

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?

I took a few screenshots that might put more context into the KML schematic of the vessel. These also highlight the two docking ports that I had trouble with.

First, highlighting the docking port [87] on the transported station part:

And this, highlighting the docking port that connects (edit: should connect) the transported station part to the cargo shuttle. Note that this is node attached to the first 2m section of the cargo bay. I initially thought it better to design the cargo bay with radial separators on the inside of the cargo bay, but that did not quite work for me in the VAB. 

So, as the pictures show, the shuttle's docking port (that connects it to the station) is an Mk2 type with attachment nodes at either end and a radially orientated docking port. This is [7] in the schematic view. The regular Clamp-O-Tron that I attached to the cargo bay, as the link between whatever was supposed to be transported and the shuttle itself, does not appear in the schematic. So perhaps that docking port is the root of the problem (or why KSP marked the two docking ports, [87] and [65], on the station part as "disabled"). 

In any case, the problem is a bit moot as the edits I made turned the savefile incompatible with KSP, so I had to restart my career ambitions. However, it might be nice to discuss the issue further in order to prevent these issues from arising in the future using better construction designs or construction hierarchies.