Mythos

Members
  • Content Count

    97
  • Joined

  • Last visited

Community Reputation

95 Excellent

About Mythos

  • Rank
    Rocketeer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Is the question about how to use KML? When you found such a problem, right click the warning ad select "repair this connection...". Then save the file and reload it in KSP. If still problems exist, save again and repair once more (sometimes double-repair is necessary). If then problems aren't fixed, please report some more details here, how the state was initially, what you fixed and how exactly the final state looks like, e.g. with an uploaded savefile.
  2. I'm glad KML helped again… and again and again. Yes, this bug is quite old and still not fixed. KSP2 will be rebuild from scratch, so it will hopefully not appear there again. But having KSP2 coming, I think the motivation to fix KSP1 decreases?! Well, no, I did not know that. Probably I never had kerbals in external seats in any test save. Still new things to learn about part connections And yes, it's fine to ignore any warnings like that.
  3. Welcome to the forum! That's how I like to play as well… But this is also why this… wait.. LAST year I have been to Duna the first time, after many years of playing KSP About KML: It's absolutely fine to delete asteroids either in the tree or the vessels view. I don't think there are contracts for specific asteroids, but if you accepted a class-X related contract, you probably don't want to delete all class-X asteroids. If there is a mod for hibernating your historical vessels that's perfect. You could do this with KML as well, copy & paste them to a separate save file and delete from your active one. I'm thinking about crew now, they should appear as available then… But a problem may arise if they are reused and later the vessel is copied back in, so someone is on two vessels simultaneously... Most safe way to do it for empty vessels only. And contracts again.. Probably you shouldn't delete vessel-X from your "rescue vessel-X" contact, although it might take years to get there (I have one of those active. To his luck I don't run life support mods)
  4. Just uploaded release 0.8.2, see OP. This is now implemented: Still not 100% clear when this is needed and if it should extended to other cases as well. Feel free to contribute your knowledge to https://github.com/my-th-os/KML/issues/5 Just 3 years later and I found time to implement this request as well:
  5. @Bruce the Loon notified me about an issue since 1.7.3 where the surface attachment node can have a third parameter. Example: srfN = srfAttach, 80,COLLIDERADAPT He provided a save where this occurs for some "nfs-panel-deploying-concentrator-1x4-juno-1" parts. Can anyone help to clarify what this is, when this occurs and if this is DLC or a mod? More info in GitHub issue https://github.com/my-th-os/KML/issues/5 I'm very thankful he not only pointed out this problem but came up with a solution as well. Until this is fixed in the next release, be aware that KML will have problems if your save has such a part attachment.
  6. About GitHub I found out, that I could use a link to ../releases/latest if and only if there were full (non-pre-release) releases. And then the assets would start expanded again. I will think about dropping the pre-release tag as it feels close to 1.0 anyways. Playing around with this I built in a online check for updates (which of course is of no use yet, so not worth a preview build). For the paranoid among you: Yes KML will soon call home, but it will only get a JSON from GitHub and not put anything.
  7. Just uploaded release 0.8.1, see OP. GitHub now thinks it's a good idea that you need an additional click to expand "Assets" And it seems like something on the forum prevents me from specifying new keyboard command as "Left" in square brackets in OP?!
  8. First, thanks to all for the encouraging replies every now and then The suggested in-game solution should have done the trick for your task. Having multi-select seems pretty straight-forward for deletion, but causes issues with other actions from context menu. The whole menu and details view would have to adapt and in most cases somehow come up with some interpretation of what you mean by that for multiple entries… and would probably be often wrong in this guess. So I'd rather not go with multi-select. But you definitely made a point on that. I've just put a bunch of new keyboard shortcuts in together with the copy & paste for attributes and a total rework of the kerbals details view to have the attribute editing equal to the one on the tree tab. I'll think over and then make a new release soon.
  9. Having another look now I also wonder why you have [63] surface-attached to [9]. Did you build [7] first and then start your payload from there, so put [87] to [7], then [86] to [87] and so on? The numbering tells you didn't. But this would be the way that works. It rather looks you have picked a tank [63] and just tried to place it somewhere in the cargo bay [9], finally having it surface-attached to it. And then build the payload from there on in two directions. Finally managing to have the front dock optically aligned with the bay-dock. But that is not how it works. Dealing with payload you also like to have built it separately (to see only its stats) and then save it as subassembly. In such a case you have to make sure that so dock where you want it do dock with the bay must be the root part. When loading sub to your shuttle you will have the whole thing sticking to your mouse and should connect it to the dock, probably by forcing node-attachment with the alt-key. You can see what parts are connected by the parts that are highlighted during placement. Those are some hints I have for building payload. I hope it helps.
  10. If you edit with KML it asks if you really want to overwrite an existing file creates a backup file named zKMLBACKUP<timestamp>-<original filename>.sfs But of course managing your copies by yourself and having names like "docking_broken", "partially_fixed" and whatnot is easier to handle and restore from If you only fumbled around a single vessel you also could just delete tho whole vessel and the incompatibility should be gone, not necessary to start a new game.
  11. 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.
  12. No, orientation of the vessel in flight has nothing to do with it. It's the way it is oriented in the VAB.
  13. 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.
  14. 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.