Padishar

I asked around and the general opinion is that Vessel.CycleAllAutoStrut() needs to be called on both the resulting vessels when a vessel splits. I don't know why this isn't happening by some existing mechanism but it should be possible for KAS to call it itself...

@Auriga_Nexus, assuming that it doesn't happen with stock docking ports then it sounds like KAS isn't firing some required event either before or after disconnecting the parts. It may be that something new has been added in KSP 1.2 or the autostruts may just use a non-obvious mechanism to reset when stock undocking...

I didn't think that's what irony meant... https://youtu.be/awD1gtpdWIA?t=24s

See the signature in any of my posts (just edited it to make it clear that my dev version is for 1.2.x).

I'll take a look and see if there's a reliable method that will work for both your mod and the stock multi-mode. Do you have a test part for your mod (e.g. just an up-to-date config that reuses a stock part)?

KER only understands the stock engine modules. To handle multi-mode, it understands how to work out which of the ModuleEngines on the part is active (without using the "active" state as that isn't reliable during editing or before the engine is staged) . Here are the important bits of the code: https://github.com/CYBUTEK/KerbalEngineer/blob/master/KerbalEngineer/VesselSimulator/PartSim.cs#L201-L202 https://github.com/CYBUTEK/KerbalEngineer/blob/master/KerbalEngineer/VesselSimulator/PartSim.cs#L227-L289 So, KER is going to need custom code to handle your new module or it will just treat your part as an engine with multiple ModuleEngines and assume they all run at the same time...

Ideally I'd like to be able to detect any bit of stock UI rather than just the parts panel though I may resort to doing just that. However, it looks like that function just returns the local point of the intersection of the mouse ray and the plane of the rectangle and I would still need to know the size of the UI rectangle in that plane. I'll have a bit of a fiddle later...

Yes, it's a known problem. It would've been fixed by now except I've not yet managed to find a nice way to tell if the mouse is over stock UI. I'll probably resort to disabling on the left hand side of the screen but even that's awkward as the side panel isn't a fixed size. I'm also probably going to add a separate configuration for the tooltips so you can completely disable them but still keep the panels at the bottom. You're welcome. My branch is fast approaching the point where I'll be happy for it to be merged for an official release. I'd like to wait until RF is updated to 1.2 first, to test with that, but it looks like that still might take a while, so we may just have to fix any RF issues later...

I have now released version 0.3.2.3 which optimises the GUI code to create much less garbage when the window is open.

When this happens you should check the mode that the navball speed display is in. There is often a considerable difference in your speed in the Surface and Orbital modes and this may make a difference, e.g. the orbital speed could be reading 1600 m/s but your surface speed might only be 1500 m/s (or even less). You can just click on the readout to change the mode it is in (though note that this can also change the prograde direction of your vessel so be careful if you are using one of the advanced SAS modes as your ship might suddenly turn).

In the graphics section of the settings in the main menu .

Well, the tech support or general discussion areas would be more appropriate than here, but I'll suggest a couple of things. First, make sure it works in other programs, Alt and the first letter of a menu should open it, e.g. Alt-F should open the File menu in Notepad (and most other editor programs). Next, open the settings.cfg file in the KSP folder with notepad and search for MODIFIER_KEY. This should tell you what the modifier key is configured as in the game. You should also be able to see this in the in-game settings and change it back to the correct defaults if it is wrong. Alternatively, you can just correct it in notepad. This is the section from my settings.cfg: MODIFIER_KEY { primary = LeftAlt secondary = RightAlt group = 0 modeMask = -1 modeMaskSec = -1 }

Try turning off the part highlighter in the graphics section of the main game settings. If this doesn't stop the crashes then upload and link an output_log.txt file as described in the post that DrLicor linked above...

Can you describe the difference between a "non gravity turn" and a "true gravity turn"? Incidentally, @Lynch, you should update to the latest dev release of KER (see my sig) as the deltaV calculations have now been updated for the changes to fuel flow in KSP 1.2...

Since you have KER, check out the Slope readout in the Surface panel, it should tell you exactly what the slope is (and the heading of the downhill direction)...

The first thing I would suspect is the problem at the top of this post: I would suggest you disable the highlighter in the graphics settings and see if that stops the crashes... If it doesn't fix it then check out the "How to get support" sticky thread for tips on troubleshooting it yourself and to find out what info you need to provide for other people to help you...

No, the problem is just that KER 1.1.2.4p didn't fully support the changes to fuel flow in KSP 1.2. Update KER to 1.1.2.6p (see my sig) and you should get correct readings...

If that's the case (please let it be) then I'd expect a RealPeople mod to pop up in RO after not too long...

Great, thanks for the report. Hmmm, an especially thorny problem, especially if you don't have enough tankage to hold all the fuel created from the ore so need to do some of the burning before all the ore is converted. I won't say it'll never get done, but it's unlikely to be any time soon... Indeed, multiple converters is only one of many different factors that would (ideally) need to be accounted for...

Ahhh, yes, at 150+ fps it will generate a lot more as most of the garbage is generated per rendered frame. There isn't currently a way of capping the update speed in KER (this is one of the "fixes" that I've got planned that requires some substantial refactoring). The control you're thinking about in the VAB is probably the simulation timer but that only affects the simulation code which has already been pretty heavily optimised to generate less garbage. Your best bet is to either set the cap to 60 in the main settings or to turn vsync on, there really is no point having that many frames rendered per second, you're just making your CPU and GPU work harder for no real benefit...

I think the AFTER probably needs to be after the HAS...

This looks like a bug in KSP's code that loads saved games, presumably because your crash left the game in an odd state and the code doesn't handle the situation well. The problem is occurring when you click "Resume Saved" because KSP currently loads every save in your game when you open that dialog. Your best bet is to first try removing all of your saves from the saves folder (move everything out of the saves folder except for scenarios and training) and then copy just one save game back into the folder. If you still get the problem then rename the persistent.sfs file and copy one of the backups to replace it. If you still can't get it to work then zip up the save (right click on the folder and select "Send To/Compressed folder"), upload it to a file sharing site such as dropbox and post a link here. Chances are quite good that someone with technical knowledge of the save file format can locate the cause of the problem and provide a fix...

Yes, there are memory leaks (and other effects that are described by lay-people as memory leaks though they aren't actually leaks) but statements such as: ...imply to me that you don't have enough knowledge of the subject to be apportioning blame to anyone in particular. I have to assume that you have virtually no experience of software development as it is insulting to suggest that any developer would release a program that knowingly includes a memory leak because they "couldn't be bothered" to fix it. It's far more important to fix issues that cause the game to crash or cause other game-breaking issues than it is to fix a gradual rise in the memory usage of a program that will eventually cause a crash. Also: [citation needed] Where in the release notes for 1.2 or 1.2.1 does it mention memory leaks? Before you reply, bear in mind that excessive garbage creation is not a memory leak...

Yes, the excessive garbage creation due to the UI code is known about (though 6-7 MB/s sounds a bit high unless you have loads of readouts visible). I'll be making some improvements to it soon but it really needs considerable work to refactor the code to generate less string concatenation/conversion garbage and to switch away from the old GUILayout based code. The first part of this is something I can do but the second requires both knowledge of how the existing KER UI code works and knowledge of how the new UI API in Unity 5 works, neither of which I have a lot of. Yes, download version 1.1.2.6p from the post linked above (also linked in my sig). The version in the main GitHub repo was the initial fixes that Cybutek did to make it work at all in KSP 1.2 but my dev version has lots of other fixes and new features.

The first thing I would suspect is the problem at the top of this post: I would suggest you disable the highlighter in the graphics settings and see if that stops the crashes...