Mythos

Released 0.9.4, see OP CLI selected warning "-ws=0" shows source node - for @darthgently CLI shows all sources nodes for each warning with multiselect "-wm=*" GUI and CLI always name 2 nodes in warning message, even if it is about an attribute

KML should never just close. It should show a message about the exception that happened, but turns out stack overflow exceptions are not handled this way. And a stack overflow happened because your vessel has cyclic attachments. Fixed the problem and released 0.9.3, see OP. About the problem with your vessel: There clearly is a problem with how the parts are attached to each other. The warning about part [61] not being attached to its parent [50] already indicates this. But separate from that, the problem that caused KML to give up was that there is a cycle in the attachment structure. The 'part graph' algorithm to project the 3D structure onto a 2D diagram could benefit from some improvements But I managed to analyze it anyway, here is the cycle: From all what I've learnt about part attachments so far, your vessel should not exist There are two docking connections involved [71]-[72] and [55]-[78], both are of the type docker-dockee. But one of them should actually be of the 'same vessel' type. This kind of structure has always confused KSP and you should try to avoid it. Does it still load in KSP or was crashing the game the reason you consulted KML? Edit: I just saw this bug made you join the forums and make your first post. Welcome! And what is wrong with the forums these days? Half the time it doesn't load stylesheets or is totally unavailable. Is it too many KSP2 users looking for help? I didn't have a look, I'm not participating in this over-priced, over-demanding, under-delivering hype yet.

I can reproduce the problem and will have a look soon,. Thanks for reporting.

I'm sorry to say, that KML can't help you with that. You can open .craft files with KML, but not much more than that. I don't know why Squad had chosen to write .craft files differently from the FLIGHTSTATE section of the .sfs file, but it is complicated to translate from one to the other. Why does the Craft Extractor not work? Is is due to dependency hell not even starting anymore? Or does it run but can't deal with latest version save files (no real radical changes there)?

Released 0.9.2, see OP. Sorry, I expected you wouldn't love it, but I didn't want any GUI clutter for a feature hardly anyone cares about. So it now it just displays line count in the context menu of each node.

Yeah, it's in general a pretty wasteful format. Never thought about something like that. All the lines are read anyway, shouldn't impact the performance. But right now I wouldn't know where to display that, don't want to overload the GUI. I will think about that. Edit: Did a quick test and have it displayed in the context menu. It's updated each time the context menu opens, so it is up to date and still pretty fine performance wise. You probably don't want to click on each node for your task, but that is was you would have to do in Windows File Explorer as well. And there it doesn't annoy all the others who never cared about line count

Not mentioned so far, you can also use EVA construction to attach a docking port and use that to deal with the vertical alignment problem.

I agree with what @Curveball Anders said. Some more details how to try: Locate a funtioning non-occupied Clamp-O-Tron on some vessel and select "copy node" on the part. Then find the Construction Port (what part is that exactly?) within the non-functioning vessel. Select that and click "paste inserting node before". Then you need to copy a bunch of attributes directly within the original part to the inserted one, overwriting the copied entries: cid, uid, mid, persistendId, launchID, parent, position, rotation, srfN, attN (and maybe more). This should make the copied part to be attached in the same way the original part is. Finally delete the original part. It might look odd when you look in KSP. You then have to tweak the "position" and "rotation" attributes with some maths and a lot of trial and error.

From my experience, this usually happens when you undock in different order than dock. If you dock A to B and later dock AB to C, the game sometimes gets confused when you undock B. This also happens when you just think you undock the same vessel, but you don't. Let's say you deliver a tank T to your station S with your rocket R. You then dock S with TR and later undock R from STR. This is a different link. And if TR came straight out of the VAB, then this link doesn't know anything about names.

The only reason I can think of, why this might not work, is crew. But I think you excluded that by using probes only. And then no reason comes to my mind, why this shouldn't work.

I think you are talking about save / persistence files here, not about craft files. If you talk about making a split, you probably just did an exact copy of your save? And then maybe deleted some vessels in one or the other version?

I don't run all of your mods, so I probably don't fully understand your problems and their need for solutions It's open source. Feel free to use it. You're probably right about me not wanting too mod-specific stuff in a general KSP save editor. If you have certain aspects that the general audience might benefit from, and you manage to break down your work into smaller pieces, pull requests are welcome. Well, that sounds annoying. The save file structure clearly wants any additional data to a vessel to reside as a subnode (some MODULE) within the VESSEL. As such it should be deleted with it. If there is a "Vessel_data" next to the VESSELs, or somewhere completely different, that's really bad design. I have seen at least "uid", "vesselID", "partID", "pid", "persistentID", "launchID", and no idea what those could be "cid" and "mid". From looking at those you get the idea that different features have been implemented by different teams, not talking to each other. One feature (e.g. type of contract) uses that naming sceme to refer to each other, the other one, by no reason, invented a new name for the same idea, using different numbers of course. So, good luck with that But yes, messed up IDs is a thing. And when I personally got annoyed by non-functioning contracts, I implemented a check in KML for at least that small part of the mess, that I could make sense of. I also remember someone mentioning messed up IDs in craft files. But since craft file support is a rather neglected feature in KML, I never got deeper into that

When you change the kerbals to "Assigned" in the roster, you also have to go to the flightstate, your vessel, and then the part where they should be in. You need to have one enty "crew = Jebediah Kerman" and a separate additional "crew = Bill Kerman" for each one.

I submitted the KML_Windows_v0.9.1.zip to the Defender support. They updated the signatures and when you do this, it should work now: Submission details (9fa2c800-9d1d-44d7-b04e-a07d33290f48) - Microsoft Security Intelligence

In some of the posts I read that you can observe this strange behaviour: Download the release zip to your standard download folder, see false positive warning, file gets deleted Create a new folder and set up Defender to exclude that Download the release zip to new excluded folder, obviously no warning and it remains. But now the fun part: Copy the zip from excluded folder to standard download folder, call a Defender check there, also no warning, file remains