Boop

It should work with the DLL I uploaded - just tested it myself. One thing you need to check, it seems that stock has the following line in settings.cfg: Editor_fineTweak { primary = LeftShift secondary = None group = 0 modeMask = -1 modeMaskSec = -1 } You need to edit that to read: Editor_fineTweak { primary = LeftShift secondary = RightShift group = 0 modeMask = -1 modeMaskSec = -1 } Try that and see. Maybe it used to be there and they god rid of it at some point. @PickledTripod I will add new methodology to the AngleSnap function, then write a post for @linuxgurugamer as I did before, detailing the changes (again, they're kinda small, all things considered). @Fwiffo can use the info to build one for 1.1.3 and make it available if he likes, but I'm going full-tilt towards 1.2 so I don't even have it installed to build against.

@Fwiffo right, try this on for size: https://drive.google.com/file/d/0B5NCh5cbU4lsY1hkTkRkV2VDZTg/view?usp=sharing Please note that I haven't done anything to Angle Snap yet, this is just to test hijacking the "X" key - try both "X" and "Shift-X".

Awesome! @Fwiffo the good news is that not only can the hotkeys can be 'zapped' so that the VAB/SPH don't respond to them, they are reset by KSP on the next launch, regardless of how the program was exited ('properly' or via sudden Alt-F4) which means that nobody will be left hanging if they uninstall the mod. This make me much more comfortable. Now to wire-in my earlier code...

@Fwiffo then it seems that, at this point, the best solution will be to rip-out the stock handling and wire-in what I wrote for the bracket keys. Hopefully @linuxgurugamer can throw me that updated source / tell me why this is a bad idea. I have a bit of experimentation to do in the meantime anyway. I can't believe we filled nearly 2 pages of forum talking about a hotkey that increments a number by 1

Sure, here you go: https://drive.google.com/file/d/0B5NCh5cbU4lsR0c1WEtHZWU5azA/view?usp=sharing Running on Windows.

@Z-Key Aerospace hope you get well soon! I had a poke at this in 1.2. Had to recompile it against the latest DLL references, but there were no errors after that. The good news is it seems to function as expected. The bad news is that the "Here and Now" window flickers madly when dragged, or when any of the mod's windows are interacted with. Not sure what's happening there. Stock toolbar by the way, in case that matters. I also took the liberty of following your settings model to add: if( (_filter.TotalCount - _filter.CompleteCount > 0) && _parent.Config.StopWarpOnAvailableExperiment) { GameHelper.StopTimeWarp( ); PlayNoise( ); } Works like a charm! Let me know if you want the code, although it was just a matter of adding a variable and a handler (copied-and-pasted from your other settings, then renamed) so I expect you'd recreate it in less than 5 minutes.

I had another go! I simply threw the following (somewhat inelegant) code into the Update() method of EditorExtensionsRedux.cs: if (Input.GetKeyDown(KeyCode.LeftBracket)) { if (editor.symmetryMethod == SymmetryMethod.Radial) { if (editor.symmetryMode > 0) { editor.symmetryMode--; } } else if (editor.symmetryMode == 1) { editor.symmetryMode = 0; } else { editor.symmetryMode = 1; } return; } if (Input.GetKeyDown(KeyCode.RightBracket)) { 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; } Using the "[" and "]" keys was then absolutely silky-smooth with no explosions of any kind. This suggests that whatever happened in 1.0.3 is no longer an issue, at least for symmetry. I'll have to dig into angle snapping to see if that works the same way - perhaps using "<" and ">". Then I can have a go at decoupling stock's handling of the default hotkeys and see how well that goes. @linuxgurugamer do you want me to continue taking a run at this part of the mod? If so, could I please get an updated copy of the source? The source code zip file download for "3.2.15 for 1.2 beta" doesn't have my changes or whatever you did to the GetComponent part in it.

I did make an attempt at that but only succeeded in setting-off a nullref nuke. I'm going to have another go, but my concern is that comment in the code I posted. It seems that it was deemed important at some point for KSP to handle some aspect of the event. Also, I'd really hope the game resets the hotkey at launch, because if you were to crash to desktop and uninstall the mod before relaunching then the VAB/SPH would be broken. I did this for a minute solid and couldn't reproduce it - at least not while using @linuxgurugamer's beta version in 1.2 pre.

Okay, so I had to go back to stock (*shudder*) to give myself some context. Vanilla KSP provides radial symmetry for 1x, 2x, 3x, 4x, 6x, 8x. This means that if we were going to see some potentially wacky behavior it would most likely manifest from 4-5 (as there is no 5x), 6-7 (as there is no 7x) and all the way from 8-20 (as 8x is the stock max). I tested this by pressing the relevant hotkey and not immediately releasing it. Lo and behold: 1-2 -- ✓ 2-3 -- ✓ 3-4 -- ✓ 4-5 -- X (springs to 6 until you release the key) 5-6 -- ✓ 6-7 -- X (springs to 8 until you release the key) 7-8 -- ✓ 8-20 -- X (springs to 1 until you release the key) Exactly as predicted. By the way, if you literally hold a part in the VAB and place it next to another one while doing this experiment, you get the same reflected visually as you see in the label (e.g. 4-5 will place 6 initially until you release the key). Now let's look at decrementing: 20-8 -- ✓ (What?!) 8-7 -- X (springs to 6 until you release the key) 7-6 -- ✓ 6-5 -- X (springs to 4 until you release the key) 5-4 -- ✓ 4-3 -- ✓ 3-2 -- ✓ 2-1 -- ✓ 20-8 not showing any flaky behavior might be a clue. I think this is the internal logic of KSP getting involved in all cases, before EER kicks in with its override. In fact, in the source, there is the following: //KSP v1.0.3: Change angle snap and symmetry mode actions to GetKeyUp() so that it fires after internal editor actions [...] // X, Shift+X : Increment/decrement symmetry mode if (GameSettings.Editor_toggleSymMode.GetKeyUp ()) { SymmetryModeCycle (modKeyDown, fineKeyDown); return; } So in 1.0.3, something happened that provoked a change to the logic whereby the hotkey needs to be released (GetKeyUp()) before the override happens. Until it does, in some cases you'll see this glitch. With variables flipping around like this and being changed by different pieces of logic, you get the added potential for desync. Unless the comment in that snippet is wrong, we need KSP to "do its thing", which would make any attempt at an alternative button combo cause even more issues. I might have time to look deeper tomorrow. Let's keep thinking!

Only one reason I can have known about it - I must have made the same mistake at some point! 3 would probably lead to a lot of "This mod is broken!" posts from the unaware. 1 is simple and kind of what I was expecting to be the case in the first place. 2 is smart, especially if you accidentally 'slip' on to a radial part when trying to add 20 landing legs to a fuselage, but as with anything clever it's bound to cause some confusion. Tricky one. Yep, I've seen this behavior, nice vid. I originally put it down to the slight jankiness of the game engine itself but your theory about the cause is pretty compelling. Of course, the fact I've now said that means it'll turn out to be something else entirely That temporary flip to 8 from 1 with Shift-x is bizarre!

@timmers_uk just wanted to let you know that I rebuilt the mod against the 1.2 prerelease (had to fix the DLL references, but that's all) and it seemed to work fine in the space center and flight scenes with the stock toolbar. I haven't installed blizzy's yet, but if I do I'll check that too.

Okay, this is based on that 3.2.15 version you linked. I may have a lead on one avenue for 'confusion' to arise. Start with this 'craft' (just a Mk1 Cockpit and Mk1 Liquid Fuel Fuselage, parts are relatively unimportant): Grab another fuselage and add two in radial symmetry: Grab another fuselage, pump the number up to something silly like 20, hover over the 'original' central fuselage, notice that all works as intended: Now hover over one of the radial parts you added in the last step - notice that the number auto-resets to 2x (which, again, is fine) Now hover over the 'original' fuselage again and press 'x' - notice that the number suddenly leaps back to 20, instead of (possibly more intuitively) rising to 3. If you try it with a lower number than 20 - say, 17 - it suddenly springs back and increments, so you get 18. Not saying this is a 'bug' per se, but I wonder if it might explain some confusion. On the other hand, the responsiveness does seem a bit more 'snappy', so I'd say you achieved something positive by addressing the GetComponent part. I smashed the hotkeys as fast as I could and it was very accurate - most of the 'errors' I encountered were almost certainly down to my brain's inability to command my fingers at such a speed.

No worries, it was exciting. Thanks for the kind offer of credit! The instructions were vital, at least for me, so that would be a fine idea. One thing I would point out - I don't have a lot of experience with Unity, but I took a look at the problem @Fwiffo mentioned and I saw this inside of the 'Update()' sub of 'EditorExtensionsRedux.cs': //check for the configured modifier key bool modKeyDown = GameSettings.MODIFIER_KEY.GetKey (); //check for configured editor fine key bool fineKeyDown = GameSettings.Editor_fineTweak.GetKey (); Camera cam = editor.editorCamera; // Fwiffo VABCamera vabCam = Camera.main.GetComponent<VABCamera> (); // or EditorDriver.fetch.vabCamera; // RK SPHCamera sphCam = Camera.main.GetComponent<SPHCamera> (); // or EditorDriver.fetch.sphCamera; It rang a bell, so I googled it and found this: Is Get Component bad within Update? If that thread is still relevant then assignments that can be done once, along with looping calls to GetComponent instead of caching them, might contribute to the 'jumpy' behavior. Maybe something I could look at when I get some more spare time?

@linuxgurugamer Done and done! I looked into the 'Pull Request', but I'm concerned that the changes I had to make to the structure to get it to build in VS might cause a problem and I'm not confident enough with the toolset yet, so I've compiled the 4 steps into a list. Turns out it's only actually about 2 minutes' work when you don't have to do the R&D! 1. Remove the following references from the project: - KSPCore - KSPUtil - Vectrosity 2. Re-add the latest version of the following references to the project: + UnityEngine + UnityEngine.UI + Assembly-CSharp + Assembly-CSharp-firstpass + KSPAssets 3. Change line 888 of 'EditorExtensionsRedux.cs' from: AttachNode an = p.parent.findAttachNodeByPart (p); to (note the capital 'F'): AttachNode an = p.parent.FindAttachNodeByPart (p); 4. Insert the following code before line 156 ("return false") of 'EditorExtensionsRedux.cs': if (Versioning.version_major == 1 && Versioning.version_minor == 2 && Versioning.Revision == 0) { // SelectRoot SELECTEDPART = 13; ST_ROOT_SELECT = 79; ST_ROOT_UNSELECTED = 78; MODEMSG = 62; ST_IDLE = 72; ST_PLACE = 73; ONMOUSEISOVER = 255; GET_STATEEVENTS = 0; // NoOffsetLimits ST_OFFSET_TWEAK = 75; SYMUPDATEATTACHNODE = 110; GIZMOOFFSET = 68; UPDATESYMMETRY = 61; ONOFFSETGIZMOUPDATED = 35; /* Gizmo offsets * 1 gridSnapInterval 2 gridSnapIntervalFine 3 useAngleSnap 4 refCamera 5 pivot 6 rot0 7 hostRot0 8 host 9 onGizmoRotate 10 onGizmoRotated 11 isDragging 12 ssScaling * */ GRIDSNAPINTERVAL = 1; GRIDSNAPINTERFALFINE = 2; return true; } After that, everything works, including NoOffsetLimits (which I forgot to mention that I'd successfully tested earlier). I also found that the Gizmo numbers in the 'Constant Constants' (e.g. GIZMOROTATE_ONHANDLEROTATESTART) didn't need changing, verified when I investigated in the log. Thanks for the adventure!

Cool, thanks. Awesome, a puzzle with a clue! You wrote that while I was doing a bit more detective work and preparing this post: Log.Warn("BRK 4"); Log.Warn("Type is " + Refl.GetValue(EditorLogic.fetch, EditorExtensions.c.ST_ROOT_SELECT).ToString()); KFSMState st_root_select = (KFSMState)Refl.GetValue(EditorLogic.fetch, EditorExtensions.c.ST_ROOT_SELECT); ...got me this in the log: [WRN 13:36:27.415] EditorExtensions: BRK 4 [WRN 13:36:27.415] EditorExtensions: Type is KFSMEvent [EXC 13:36:27.416] InvalidCastException: Cannot cast from source type to destination type. EditorExtensionsRedux.SelectRoot2.SelectRoot2Behaviour.Start () So "Refl.GetValue" is returning a "KFSMEvent", which you're trying to cast as a "KFSMState", therefore kaboom. I was trying to work out what the point of "c.ST_ROOT_UNSELECTED" was and what "EditorLogic.fetch" did, but I think you've just accelerated that process for me. Thanks for supporting me in having a go at this - I'm having fun!

Not so much with angle snap, but I do get some strange responses, much as you described, when 'quickly' using symmetry count hotkeys. Because it's a bit hit-and-miss to reproduce (and I don't know how reliable stock is in the first place, as I only ever play with this mod installed if I can help it) I don't know if I'll have much success in looking at it. Will try though.

No problem, happy to help. I don't know how to do a PR but I'll try to work it out. I may have tracked down at least the first problematic line - had to do a bit of 'manual breakpointing' by using the log file: Log.Warn("BRK 4"); //KFSMState st_root_select = (KFSMState)Refl.GetValue(EditorLogic.fetch, "st_root_select"); KFSMState st_root_select = (KFSMState)Refl.GetValue(EditorLogic.fetch, EditorExtensions.c.ST_ROOT_SELECT); Log.Warn("BRK 5"); The log then shows: [WRN 13:26:11.086] EditorExtensions: Starting SR [WRN 13:26:11.086] EditorExtensions: BRK 1 [WRN 13:26:11.087] EditorExtensions: BRK 2 [WRN 13:26:11.087] EditorExtensions: BRK 3 [WRN 13:26:11.087] EditorExtensions: BRK 4 [EXC 13:26:11.088] InvalidCastException: Cannot cast from source type to destination type. EditorExtensionsRedux.SelectRoot2.SelectRoot2Behaviour.Start () It doesn't hit "BRK 5", so you're right on the money with the reflection having issues. I haven't dabbled with this before but I'll see what I can do.

@linuxgurugamer I seem to have been mostly successful in getting this working in 1.2 prerelease by going through the following: Visual Studio Community 2015 obviously didn't like 'migrating' your 'BetaPackage' or 'ReleasePackage' .mdproj projects, so I just deleted them. Cleaned-up the DLL references (removed 'Vectrosity' completely). Removed your Post-build events and .bat files (not sure what purpose they serve). Duplicated your 'versioning' section for 1.1.3 - simply set it up it to check for 1.2, didn't make any other changes to it. Capitalised the 'f' in your use of 'FindAttachNodeByPart'. Built it and copied the resulting DLL file and Textures folder into my fresh 1.2 prerelease install. Went into the VAB and voila: http://imgur.com/sM6DGsP There were no obvious problems with the number of parts in 'R' placement; 'MM' worked great; 'fine adjust' (by holding down shift and using the move tool) was spot-on; and the angle snap behaved as expected on all settings. I did notice a bit of a gap in some radially-attached parts, but I uninstalled the mod and saw exactly the same problem with the same parts in stock, so I wouldn't worry about that - screenshot in case you're interested (note the gap between the central tank and the two attached to it - I put panels behind the 'ship' because it was a more contrasting background than the VAB wall): http://imgur.com/Dy4K3RQ Sadly, the log does complain about the following: [EXC 11:50:51.920] InvalidCastException: Cannot cast from source type to destination type. EditorExtensionsRedux.SelectRoot2.SelectRoot2Behaviour.Start () ...which explains why SelectRoot2 doesn't seem to be working (KSP reverts to the 'stock' way of doing things). I haven't tracked that down yet. Hope that helps!

I know the sinking effect you're talking about, but I've not seen an explosion. I only ever 'launched' craft in that fashion once and I used launch clamps. Although it definitely started to sag, it was away from the ground for plenty of time to jump and thus didn't get a chance to collide.

You'd probably find that very simple to achieve if you took a shot at it yourself - just take a look at a part with existing Tweakscale intergration and either edit it in or write an MM patch for it. I myself don't like putting the drive on everything that might need it, so I do the following: * Create a 'drive module' that consists of the drive, RCS, a variety of docking ports (I personally find one standard and one Jr at either end is fine for what I need), a drone control, power source obviously, engines (radial if needs be) and some fuel tanks (optional). * Optional: Create an Orbital Dock around Kerbin (or every destination, over time) and fit it with a beacon. Dock a drive module on to however many Orbital Docks you want them at (Jump Drives currently work from the surface, making this trivial). * Always put at least one matching docking port on any craft that wants to jump. * Get into orbit and either go to the dock / module or get the module to come to you. * Dock your ship to the module. * Jump out (tada - it works on 'both' craft!). * Undock and send the module back home (unless you want it hanging around for later). Voila, no need to put one on everything!

I rebuilt the source against the latest DLLs and it made DMagic experiments work happily without the MissingMethodException. Beware setting the science threshold too low or infinite loops ensue. I then put a Materials Bay and Mystery Goo on a rover with a Scientist inside. They only seem to fire and reset once, when the vessel first loads onto the runway. After that, nothing. I cruised around the KSC to test. There was definitely science to be had, as proven when I manually triggered either one, so something is still amiss.

The other day I used my heavily-modded install to build what was effectively a stationary 'office' platform. It used solar panels as 'blinds' for the glass panels mod and I put a little makeshift conference table in the middle. Unfortunately, it had no functional purpose in the game beyond that of an elaborate dollhouse. I've had an idea for something that starts by way of making the recruitment of Kerbals in Career Mode a bit more interactive (and thus save some cash, if you put the work in). It revolves around the placement of such structures (i.e. a collection of all your everyday / modded parts you put together in the SPH/VAB as normal, but that don't have wheels or engines and aren't moving) in each Biome (due to Kerbin et. al. not having actual 'countries' for them to be situated in). This will enable you, perhaps through the use of a few custom parts like a 'workstation' or somesuch, to build up some kind of reputation with the Biome that will make recruitment cheaper. Bigger (i.e. more parts, more costly) structures would enhance this effect. I'd also like to make Courage and Stupidity count in more ways. Perhaps by having easily-scared Kerbals temporarily revert to tourists when subjected to certain G-Forces, speeds or distance from home a-la the USI Life Support mod. Stupid ones could cause other Kerbals to quit by starting trouble, or harm your rep / finances for some reason. A another certain blend could make one ideal for running one of these 'offices'. Each game could randomize the likelehood of each Biome producing Kerbals with a particular stat balance. I could even look into the feasibility of making additional stats that aren't currently present. I haven't looked into it sufficiently, but I'd also like your efforts to affect things like the price of fuels. What I'm seeking is feedback on the current idea (would you play it? How would you tweak it to make it better?) and some inspiration for bringing something that will extend the fun into the infinite endgame. I'd like a reason for these structures to exist on other planets and moons. Bases are currently useful as staging areas / pit stops and need attention if you have a life support mod, but what other reason could they have for existing and requiring a visit every now and then - what consequences could not meeting that need have? I'd appreciate any input you might have. Thanks in advance!