Mythos

I haven't, wanted to do some more testing or maybe someone else just knows a fix within the savefile? Doesn't seem to happen this way round on my side. So it's really not urgent. Just started a new career, just standard nomal difficulty. And then I realized it is also the level 0 Kerbal pilot, that has all SAS modes. Scienced me up to the Stayputnik, and again it also has all the SAS modes. Now downloaded the full 1.11.1 package. Merged no settings and no save. Started new career, Jeb again has all SAS modes. So it's not just the patch. Tried to disable "part upgrades" in difficulty, but same behaviour.

That's also the only odd thing I noticed so far. All probe cores have all the SAS modes, even the Stayputnik. Hail the almighty probe! For me they are fully functioning, always. On 1.11.0 vessels and on built in 1.11.1 vessels. I just used the patch from 1.11.0 to 1.11.1 . The save was a complete vanilla, no DLC, no mods, fresh 1.11.0 start.

As the issue doesn't appear on launch but only later mid-flight, you probably need to check that your center of lift is slightly behind the center of mass, ALWAYS. So please check if that is the case for fully fueled, half-full and even empty. Because while you burn through your fuel, the center of mass usually changes.

I always support that.... I don't get any of the rest of the conversation, though. What the hell is WOLF? Is there some link to a description? Is it only hidden woven into 400 pages of MKS thread (search results say so)? That would mean I may never lern about it, because I will not go through the whole thread I have a rough idea what MKS is about, but never used it. Is it not continued anymore and WOLF is a successor?

Have a look at the part description you get by right-click on a part in the VAB/SPH. The first sentence in the first textbox tells you what you can do: "This is a Cargo Part that can be placed inside inventories": The usually smaller parts can be carried around inside the inventories and be assembled during a mission by an engineer. You have to consider the volume of the part and the volume of the inventory, it does not always fit in there. "This part cannot be placed in a Storage container but can be manipulated in EVA construction": Other slightly too large parts can be detached and reattached by engineers but not stored in inventories. No text about reassembly: The large parts can't be handled at all.

Thanks for bringing this up. I was also used to backspace and wondering why that doesn't work, since 1.11 is the first version I gave a real go, having my main career still in 1.3.1. I also learned that tab cycles focus through celestial bodies and even maneuver nodes now. Shift-tab cylces backwards, but also throttles up thrusters... After all those years that's still a questionable keyboard layout And while we're at it.. I'm currently stuck to play on my notebook and didn't bother to plug in my mouse, so using touchpad. If I'm doing a zoom-gesture, it messes up the throttle as well, this time only ever throttling down, so it is safe to zoom when cut off

Ah ok. I usually try to clean up and rescue the pod as well (weld a docking port to it), regardless whether it's in the contract or not. Then I often don't EVA the rescuee at all. So maybe that's my fault then and I should just EVA. Thanks to 1.11 the task can be solved differently, and that's why I probably have never skipped the EVA part before and everything feels different

Well, yes eventually. But since I'm early in my new career I prefer that the just rescued pilot already can follow the prograde marker

It's been some years that I hardly ever continued my 1.3 career (didn't want to start over and 1.4 changed too many parts). So I am a bit unaware when changes did happen. But the new changes in 1.11 convinced me to play around in a new career (and maybe the fact that KSP runs on my notebook while my desktop graphics card broke and delivery of a new one is already a month late, damn crypto miners). So the question is: When I rescue a Kerbal from LKO that state doesn't appear in his "logbook", so he will get only 1 XP for the next state that is Kerbin sub-orbit, thus he remains lvl 0. Rescue from Mun orbit will give him Mun fly-by but not orbin and so on. I did not expect this. My personal feeling is that this was different in older versions, although I'm not 100% certain. My solution is, for e.g. LKO: Reduce periapsis to 69km, new state sub-orbit is reached, push it back to 70km, another state change to LKO, then continue with standard deorbit. When I do this, the rescued Kerbal will have orbit around Kerbin, 2 XP and be on lvl 1. Seems a bit cumbersome to me to apply such tricks on every rescue (which appear more often than I'm used to).

Hello and welcome to the forums. Sadly (that those bugs still exist) it's often problems like yours, that motivate people to join in Concentrate on the first entry in the response. The others just repeat, what else has been there before. There is a bit of an oddity going on with claws, try to avoid such solutions if possible. Also bad or even worse is this "same vessel docking", having more than one port from the same ship to the same station (or other ship) connected. And maybe you have simultaneous claw attachment going on? Or being clawed and also docked? Both might even be the worst. Well, if you look in the tree there is a child node to the part, that is called "MODULE". Or maybe there isn't, that might be the problem causing such a message. But have a look at a functioning claw or docking port. If you don't have one, build one, put it one the launch pad, save, and then load that state into KML. And then the idea of repair is to copy that "MODULE" node only, not the part. After having a module node under the broken claw/port, you should probably save and reload in KML, and then fix again. Those module nodes contain the information what the docked/grappled ship is called, what its root node is, what part it is attached to and so on. If that somehow got lost, you might end up with a generic name and root part being reassigned, when it finally does undock in-game. Just upload your savefile somewhere and drop a link here. I might have a look tomorrow.

This is the link to the GitHub releases: https://github.com/my-th-os/KML/releases This is directly to the latest one: https://github.com/my-th-os/KML/releases/download/v0.8.2/KML_v0.8.2.zip Maybe you clicked on the "preview build" link in the OP? There is currently no one, so this should lead to a 404 page. I hope its not false positive from some virus scanner again? Actually the KML.exe is the only file in that zip. So is a zip without any file a thing? If you have other files, you probably downloaded the source code.

I would not say it's outdated. KSP just did not change much since the last KML version, especially about the structure of a savefile. Of course it still works!

The guide states, that it would be good to port to .NET Core first. I have no personal experience with wine, but I thought it is used to run any Windows app in Linux. So what exactly happens if you run KML in wine? Does it just work or does it need some adjustments?

Nice commitment, but the problem is not C# running with mono under Linux. The problem is the GUI using WPF, that is not accessible in Linux. See https://github.com/my-th-os/KML/issues/2. You could write a completely new GUI, though Could try this Avalonia thing, if that still exists, or some more old-school wxWidgets. I still lack the time to do larger changes on KML. Well, it's working. Although I'm sorry for my bad decision excluding Linux users. If I could, before just rebuilding the GUI, I would rather rebuild anything. Time will show, whether some tool like this could be used for KSP and KSP 2 in parallel, having a more modular thing would help with that.

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.

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.

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)

No, KML can't re-root.

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:

@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.

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.

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?!

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.

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.

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.