Boop

Members
  • Content Count

    47
  • Joined

  • Last visited

Everything posted by Boop

  1. 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.
  2. 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.
  3. 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!
  4. @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.
  5. @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"
  6. @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).
  7. @linuxgurugamer has given me permission to hint that there is another surprise incoming. OMG! SURPRISE! INCOMING! P.S. Does anyone know what 'hint' means?
  8. @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!
  9. 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
  10. Yikes - lemme know if that turns out to be the case, could be an important warning for the OP.
  11. 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
  12. 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...
  13. For starters, is insta-quit still messing up your VAB controls in this 'new' version?
  14. 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?
  15. 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.
  16. It was a pleasure, and that's the icing on the cake, so thanks for the opportunity to contribute. Give me a holler if you need anything else, with this or the rest of your ever-expanding portfolio!
  17. No problem - here it is with all the changes, plus the updated 'OnMouseIsOver' value: https://drive.google.com/file/d/0B5NCh5cbU4lsM2w2enR6SmxPSFk/view?usp=sharing
  18. Turns out that was the only one, no other offsets are off. If you've already made that alteration to the source then we're good to go
  19. Darnit. I see KSP has patched at least twice since I set that up - maybe that's it? I'll have another look after dinner. You're welcome!
  20. I think I have enough for a serious final test Here's what I did to fix the SymMode and AngleSnap responsiveness - note that all changes are made solely in EditorExtensionsRedux.cs, which I've uploaded to Google Drive in case you prefer getting it that way without integrating it all manually: https://drive.google.com/file/d/0B5NCh5cbU4lsNDhTal9kbmN2dnM/view?usp=sharing 1. We need these class-level variables - I personally put them just before "Start()" as that made them handy to see for the next step: //Boop: Cache the editor hotkeys so we can keep consistency with whatever is in the settings.cfg file. KeyCode HotkeyEditor_toggleSymModePrimary = GameSettings.Editor_toggleSymMode.primary; KeyCode HotkeyEditor_toggleSymModeSecondary = GameSettings.Editor_toggleSymMode.secondary; KeyCode HotkeyEditor_toggleAngleSnapPrimary = GameSettings.Editor_toggleAngleSnap.primary; KeyCode HotkeyEditor_toggleAngleSnapSecondary = GameSettings.Editor_toggleAngleSnap.secondary; I did that specifically so that if the User (or a future KSP version, or maybe another Mod) ever changes those buttons then we still know what we're looking for. Then it turned out to be vital later (step 3). 2. This then needs to go into "Start()", suggest straight after your "Log.Debug ("Start()");" line: //Boop: Nuke the editor hotkeys so we can hijack them. GameSettings.Editor_toggleSymMode.primary = KeyCode.None; GameSettings.Editor_toggleSymMode.secondary = KeyCode.None; GameSettings.Editor_toggleAngleSnap.primary = KeyCode.None; GameSettings.Editor_toggleAngleSnap.secondary = KeyCode.None; This is how we ambush the (by default) "X" and "C" keys. 3. Now put this in "OnDestroy()": //Boop - restore the hotkeys - without this, the hotkeys fail to work on each subsequent visit to the VAB/SPH after the first. GameSettings.Editor_toggleSymMode.primary = HotkeyEditor_toggleSymModePrimary; GameSettings.Editor_toggleSymMode.secondary = HotkeyEditor_toggleSymModeSecondary; GameSettings.Editor_toggleAngleSnap.primary = HotkeyEditor_toggleAngleSnapPrimary; GameSettings.Editor_toggleAngleSnap.secondary = HotkeyEditor_toggleAngleSnapSecondary; That fixed the nastiest bug I managed to introduce (and lost nearly 2 hours to) 4. Last but not least, the new SymMode and AngleSnap code needs to go into the "Update()", suggest directly after your "if (!validVersion) return;" statement: //Boop: Override stock Angle Snap manipulation if ((Input.GetKeyDown(HotkeyEditor_toggleAngleSnapPrimary) || Input.GetKeyDown(HotkeyEditor_toggleAngleSnapSecondary))) { int currentAngleIndex = cfg.AngleSnapValues.IndexOf(editor.srfAttachAngleSnap); float newAngle; if (Input.GetKey(GameSettings.Editor_fineTweak.primary) || Input.GetKey(GameSettings.Editor_fineTweak.secondary)) { // Decrease snap newAngle = cfg.AngleSnapValues[currentAngleIndex == 0 ? cfg.AngleSnapValues.Count - 1 : currentAngleIndex - 1]; } else if (Input.GetKey(GameSettings.MODIFIER_KEY.primary) || Input.GetKey(GameSettings.MODIFIER_KEY.secondary)) { // Reset snap newAngle = 0; } else { // Increase snap newAngle = cfg.AngleSnapValues[currentAngleIndex == cfg.AngleSnapValues.Count - 1 ? 0 : currentAngleIndex + 1]; } currentAngleIndex = cfg.AngleSnapValues.IndexOf(editor.srfAttachAngleSnap); editor.srfAttachAngleSnap = newAngle; if (editor.srfAttachAngleSnap == 0) { GameSettings.VAB_USE_ANGLE_SNAP = false; } else { GameSettings.VAB_USE_ANGLE_SNAP = true; } lastSrfAttachAngleSnap = editor.srfAttachAngleSnap; last_VAB_USE_ANGLE_SNAP = GameSettings.VAB_USE_ANGLE_SNAP; updateGizmoSnaps(); var gizmos = HighLogic.FindObjectsOfType<EditorGizmos.GizmoOffset>(); if (gizmos.Length > 0) { var gizmo = gizmos[0]; if (editor.srfAttachAngleSnap == 0 && gizmo.useGrid) gizmo.useGrid = false; else if (editor.srfAttachAngleSnap != 0 && !gizmo.useGrid) gizmo.useGrid = true; } return; } //Boop: Override stock Symmetry manipulation. if ((Input.GetKeyDown(HotkeyEditor_toggleSymModePrimary) || Input.GetKeyDown(HotkeyEditor_toggleSymModeSecondary))) { if (Input.GetKey(GameSettings.Editor_fineTweak.primary) || Input.GetKey(GameSettings.Editor_fineTweak.secondary)) { if (editor.symmetryMethod == SymmetryMethod.Radial) { if (editor.symmetryMode > 0) { editor.symmetryMode--; } } else if (editor.symmetryMode == 1) { editor.symmetryMode = 0; } else { editor.symmetryMode = 1; } return; } else if (Input.GetKey(GameSettings.MODIFIER_KEY.primary) || Input.GetKey(GameSettings.MODIFIER_KEY.secondary)) { editor.symmetryMode = 0; } else { if (editor.symmetryMethod == SymmetryMethod.Radial) { if (editor.symmetryMode < cfg.MaxSymmetry - 1) { editor.symmetryMode++; } } else if (editor.symmetryMode == 1) { editor.symmetryMode = 0; } else { editor.symmetryMode = 1; } return; } } Unfortunately I ran out of brain before I could look at the now redundant code that got left behind. As far as I can tell, it's no longer necessary to hook-in to event handlers etc. Much of your old code just gets ignored at the moment because of the 'unwiring' of the hotkeys, but the fact that much of it is in the "Update()" loop means we should probably tidy that up. Props to @Fwiffo for testing and explaining what was supposed to be happening. Also a lot of encouragement
  21. I noticed a massive bug whereby each subsequent visit to the VAB/SPH after the very first would be utterly broken and took the opportunity to go to bed Looking at it fresh today helped a lot. Here is the latest version, with the added benefit of having been built against the latest source for the first time: https://drive.google.com/file/d/0B5NCh5cbU4lsaGxLVWtRbm9LV0E/view?usp=sharing Some notes: * I couldn't actually reproduce your Fuel Tank symmetry behavior, so I've either accidentally 'fixed' it or I'm doing something wrong. * There will still probably be a slight 'bounce' when pressing 'R' to change symmetry mode as I haven't hijacked that key with the new method yet. * The mouse-click on Symmetry Mode and Angle Snap gizmos works for me, although it doesn't work on Symmetry Mode in the 'EER way' - it cycles through stock settings of 1x/2x/3x/4x/6x/8x - not sure if I've missed something there or if that was never addressed by EER.
  22. Right, hopefully last time round the block: https://drive.google.com/file/d/0B5NCh5cbU4lsNjVvZlRveFJ4Yms/view?usp=sharing
  23. Gotcha, so with EER, the behavior you expect is: 1. Press and release 'Alt', and only 'Alt'. 2. Both angle and symmetry instantly decrease to the lowest value and stay there until you begin changing them again. Is that accurate?
  24. Darn. I saw something in the code, but I disregarded it. I was working from the Wiki Key Bindings to establish how stock worked and holding down 'Alt' wasn't listed as having that effect. Can you confirm whether that is in fact an EER thing, or also what stock does?
  25. Last test before I start writing the how-to. Angle Snap now uses the same sort of mechanism. https://drive.google.com/file/d/0B5NCh5cbU4lsZExaQnF5MFdUWjQ/view?usp=sharing Note that the EER setting of 1° seems to be finer than the default stock "No snapping" setting (the one with the concentric circles). Unless I've screwed something up. Stock seems closer to the 5° setting. Let me know if it works properly and we can get this ticked off the list.