• Content count

  • Joined

  • Last visited

Community Reputation

64 Excellent

About Mythos

  • Rank
  1. 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). 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
  2. 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.
  3. 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.
  4. 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.
  5. 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...
  6. 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.
  7. 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.
  8. 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.
  9. Can you explain what KML has identified but could not repair?
  10. 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).
  11. 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! :-(
  12. 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.
  13. 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.
  14. 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.
  15. @Sulaiman Did you read previous posts? Your problem sounds like the common one.