Boop

I'm also away now until Friday night, but I'll do it as soon as I can. I'll grab logs, screenies and mod lists.

Hi @linuxgurugamer! Tried this for the first time today. In my relatively-modded install (~60 mods) it triggered a bizarre issue that made me chuckle: Kerbals are not visually occluded in the Flight Scene by some (all?) parts (things such as Pods that they literally enter are unaffected). Steps to reproduce: 1. Create a hollow cube out of Structural Panels. 2. Place a Command Seat inside the hollow space. 3. Assign a Kerbal to the seat and launch the Vessel. Expected Result: Kerbal cannot be seen. Actual Result: Kerbal is visible 'through' the solid panel walls. Spooky! To be clear, I've verified that this only happens with the mod installed and goes away as soon as it's uninstalled. I assume that this isn't something I'm missing in the settings, as the mod's UI doesn't appear to have anything interactive I can fiddle with when this happens. Let me know if you feel the need for screenshots, list of other mods etc. and I'll see what I can do after work.

I'm a devoted fan of this mod - it makes just about everything fly 10x better. But if I take-off, land and then take-off again, as soon as I reactivate AA my aircraft always always goes absolutely bananas and crashes violently. I read this post while I was flying about and I noticed that KER was showing what seemed to be a perfectly accurate 'Vessel Situation' at all times. I had a poke around that mod's Github and noticed that they're using the ScienceUtil 'ExperimentSituations' rather than vessel.LandedOrSplashed. I changed the code in your source to use that approach instead, so for example: ScienceUtil.GetExperimentSituation(FlightGlobals.ActiveVessel) == ExperimentSituations.SrfLanded || ScienceUtil.GetExperimentSituation(FlightGlobals.ActiveVessel) == ExperimentSituations.SrfSplashed I threw the new DLL into KSP and tried it out a couple of times. Now, instead of essentially completely losing control, I get several seconds of slight 'jiggling' before it settles down completely. Anyway, maybe think about trying it out. It's solved it for me so far. Thanks for the awesome mod!

@Daishi this is just... absolutely sensational work. Oh boy was it worth the wait. The way the resource containers resize with completely different looks took me by surprise. So good. The only thing I'd like to see added would be some kind of Greenhouse wedge for life support. Other than that, you seem to have all the bases pretty much covered for me. Many thanks and congratulations to you and the rest of the team.

@AndyMt I'm seeing this behaviour on one particular vessel (I think, could have sworn it was working before) with 1.7.7 via CKAN on KSP 1.4.3 (have checked the DLL itself, shows 1.7.7). Reason for the lag is this being spammed to the log: [LOG 09:53:04.628] GravityTurn : minorbit 670000, 70000 [LOG 09:53:04.629] GravityTurn : Saving launchDB [LOG 09:53:04.632] GravityTurn : Exception: System.ArgumentException: Illegal characters in path. at System.IO.Path.GetFileName (System.String path) [0x00000] in <filename unknown>:0 at KSP.IO.IOUtils.GetFilePathFor (System.Type T, System.String file, .Vessel flight) [0x00000] in <filename unknown>:0 at GravityTurn.LaunchDB.GetBaseFilePath (System.Type t, System.String sub) [0x00000] in <filename unknown>:0 [EXC 09:53:04.632] ArgumentException: Illegal characters in path. System.IO.Path.IsPathRooted (System.String path) System.IO.Path.GetPathRoot (System.String path) System.IO.Path.GetDirectoryName (System.String path) GravityTurn.LaunchDB.Save () GravityTurn.GravityTurner.fly (.FlightCtrlState s) Vessel.FeedInputFeed () FlightInputHandler.FixedUpdate () As this seems to be string-related, the only thing I can currently think could affect it is the vessel name: CUS-2 "Pioneer"

@Katten you just saved what little remained of my sanity. Reloading my heavily-modded install was killing my motivation, now I'm free! One thing I did notice - the 'Rescale' value in my edited CFG still wouldn't visually update without a restart. Don't know if that's something you're already aware of, or if I was missing something (I was switching a Micronode from 1 to 0.5 and back).

@linuxgurugamer has given me permission to hint that there is another surprise incoming. OMG! SURPRISE! INCOMING! P.S. Does anyone know what 'hint' means?

@Fwiffo, you've once again gone above and beyond, so megaprops. I don't know how to physically screen another mod from conflicting with us like this. There's an 'OnGameSettingsApplied' event that might be worth investigating. I tried to avoid any contact with the settings on a 'permanent' basis, for reasons I mentioned, so hopefully we can all just get along!

Unfortunately, it's not a true 'fix' that can happen here. There was a potential drawback to the way I did what I did, but 1.2 stepped in and took away the risk. 1.1.3 doesn't seem to behave similarly, according to @Fwiffo, so all I can suggest is that he sets the hotkeys back to the default ('x' and 'c') on startup if they're null / set to Keycode.None, which is risky in the event that the mod is uninstalled before it gets to implement the change

Yikes - lemme know if that turns out to be the case, could be an important warning for the OP.

My theory on why you 'remember' this bug not happening when testing is that you were testing against 1.2, like I was - you didn't make a 1.1.3 version until after we were done and you probably didn't regression test that one case. As a result, I wouldn't dig too deep, it's most likely that this just doesn't go down well in 1.1.3. The whole reason I was desperate to avoid permanently overwriting the settings was that, in the case that we had a crash etc, I would be unable to restore them even if I'd persisted them to disk if the user uninstalled the mod before restarting. It was a one in a million edge case, but it gave me indigestion. Thankfully, KSP seems to deal with it for us in 1.2, so I was able to unclench

I think the only sensible next step would be for you to backup your game folder, grab 1.2, install the legit 1.2 EEX and see if it still happens. If you confirm that then I'll have to roll my sleeves up, but from current evidence at least, it's limited to 1.1.3. I will just go back and have a look at that fix code, though...

For starters, is insta-quit still messing up your VAB controls in this 'new' version?

This is surprising for a couple of reasons. Firstly, I tested Alt-F4'ing when I developed the new handler, because I feared exactly this. In that test the functionality was intact after restart, so I assumed it was handled by KSP and I moved on. Secondly, fearing that an end-task in TaskManager might be a case I overlooked that does something 'worse', I just tried it. Once again, my tools were fine after restart. Now, I do remember putting a bit of code in which specifically aimed at this problem, which is mentioned in my writeup of my fixes earlier in the thread. I'm using a (slightly modified) version of EEX in 1.2, based on the latest Github source, the only changes being something new I'm working on. What are you using?

Sort of - I downloaded the source from Github, then fixed it up in Visual Studio for 1.2. I expect @timmers_uk will publish an updated release. Many modders prefer to wait until the new version officially launches before uploading it.