[1.12.x] Editor Extensions Redux released (with SelectRoot merge. StripSymmetry & NoOffsetLimits)

[linuxgurugamer]

20 hours ago, steddyj said:

Very fair point, I just returned to KSP after a long sabbatical and I installed an insane amount of mods, I really need to trim that down.

So I made a clean copy of KSP from Steam - I always run KSP as a copy of the main clean install.  New clean install, new CKAN install, only this mod installed... still having the same issue.  Vert/Horiz snaps do not work, nor does the Strut/Fuel tool.

New log:

https://www.dropbox.com/s/0dqwvlnwf6zuxku/output_log2.txt?dl=0

 

I checked the debug console as I was testing, and I didn't see it generating any log entries, not sure what might be causing this.

Strange.  I assume you are on Windows?  While I can't see it being an issue, what version of windows, how much memory, etc?

I'll look at this later

[steddyj]

Yeah... so I'm an idiot.

Like I said, I've been away a while.  The functionality of the vertical snap used to be a toggle used when placing the part.  I seem to recall it changing right before I stopped really playing a few years ago. Anyway, I see how the tool works now and I'm all good.  Thanks for the help. 

[linuxgurugamer]

On 9/9/2016 at 10:02 PM, steddyj said:

Yeah... so I'm an idiot.

Like I said, I've been away a while.  The functionality of the vertical snap used to be a toggle used when placing the part.  I seem to recall it changing right before I stopped really playing a few years ago. Anyway, I see how the tool works now and I'm all good.  Thanks for the help. 

Not an idiot.  Thank you for getting back to me, so I don't have to worry about it.

 

[JCHR]

Hello, I am running 1.1.3 on KSP and for some reason this mod will not work. I'm not very computer savvy so any help from you guys would be appreciated. Thanks!

[linuxgurugamer]

4 hours ago, JCHR said:

Hello, I am running 1.1.3 on KSP and for some reason this mod will not work. I'm not very computer savvy so any help from you guys would be appreciated. Thanks!

Need a little information, please:

OS
System specs (ie: memory, cpu)
How did you install the mod (very important)?

and finally, a log file

[JCHR]

OS is windows 10, memory is 16 GB, CPU is 3.9 GHZ 8 CORE AMD, I installed the mod via the download link and it didn't work so i tried again using CKAN. and I'm not sure how to get a log file.. or what it is . sorry

[Boop]

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

[linuxgurugamer]

35 minutes ago, Boop said:

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

Thanks.

I haven't yet started on this yet, but, there are a number of reflection values which need to be updated which aren't that obvious.  Those batch files are used to install the compiled mod into my test install, and to build the release.

If you would put your changes in a PR, that would be great.  But only code changes, please do not put the deleted files into the commit.

 

[Boop]

Just now, linuxgurugamer said:

Thanks.

I haven't yet started on this yet, but, there are a number of reflection values which need to be updated which aren't that obvious.  Those batch files are used to install the compiled mod into my test install, and to build the release.

If you would put your changes in a PR, that would be great.  But only code changes, please do not put the deleted files into the commit.

 

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]

You just ran into the reflection problem

If you don't know how to do a PR, then send me a zip with everything and I'll figure it out.

since you got this far, I'll move it up the list of mods I'm working on, the reflection stuff will only take an hour when I able to get to it, probably this evening (US East coast)

Edited September 15, 2016 by linuxgurugamer

[Fwiffo]

Hey @Boop, while you're testing...

Do you ever run into strange behavior with the "Change angle snap" (C) and "Change symmetry count" (X) hotkeys?  I think I've seen times where I press them (or their Alt+ "Reset to default" / Shift+ "Cycle backwards" modifiers) too fast or something and they don't get registered correctly and I wind up at a snap setting I didn't expect.  Just wondering if I'm the only one...

[Boop]

Just now, Fwiffo said:

Hey @Boop, while you're testing...

Do you ever run into strange behavior with the "Change angle snap" (C) and "Change symmetry count" (X) hotkeys?  I think I've seen times where I press them (or their Alt+ "Reset to default" / Shift+ "Cycle backwards" modifiers) too fast or something and they don't get registered correctly and I wind up at a snap setting I didn't expect.  Just wondering if I'm the only one...

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.

[linuxgurugamer]

7 minutes ago, Boop said:

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.

If you REALLY want to, here is what you will need to do to fix the Reflection issues, and I suggest you do this BEFORE any more debugging:

Compile in debug mode

1. Install and start the game
2. Exit, and open up the output_log.txt file
3. Look in the file EditorExtensionsRedux.cs, near the top, in the Init function, you will see wher a number of constants have their values set depending on the version.
4. Create a new section for 1.2, copy them in from one of the other sections.
5. Look in the log file, for lines beginning with:

• EditorLogic Field name
• KFSMEvent KFSMEvent Field name
• MethodInfo  EditorLogic methods name
• MethodInfo  Part  name
• MethodInfo KFSMEvent  methods name
• MethodInfo KFSMState  methods name

1. Look in the log for the corresponding value for each line in the Init function, you should find the corresponding number.  
2. Update the Init section
3. Now, recompile in Debug mode, restart the game and go into the Editor
4. Place a part, then activate one of the gizmos on it (rotation, etc).
5. Exit the game, and again, open the output_log.txt file
6. This time, look for lines which match:

• EditorLogic Gizmo Rotate Field name

1. You need to look for the two items in the Init function which relate to the Grid, update the values as required

Compile and test.

[Boop]

17 minutes ago, linuxgurugamer said:

You just ran into the reflection problem

If you don't know how to do a PR, then send me a zip with everything and I'll figure it out.

since you got this far, I'll move it up the list of mods I'm working on, the reflection stuff will only take an hour when I able to get to it.

Cool, thanks.

Quote

If you REALLY want to, here is what you will need to do to fix the Reflection issues, and I suggest you do this BEFORE any more debugging:

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!

[linuxgurugamer]

Just now, Boop said:

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!

If you get it finished, I'll be happy to release it as the Boop release

[Boop]

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

[linuxgurugamer]

3 minutes ago, Boop said:

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

Great, about what I expected, but thank you for doing the work.

I'll get a new release out this evening and give you the credit for it.

I think I'm also going to add those instructions I wrote for you in the file, so that it is available for anyone in the future.

[Boop]

2 minutes ago, linuxgurugamer said:

Great, about what I expected, but thank you for doing the work.

I'll get a new release out this evening and give you the credit for it.

I think I'm also going to add those instructions I wrote for you in the file, so that it is available for anyone in the future.

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]

1 hour ago, Boop said:

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?

Thanks, I'll take care of it this evening.

 

[linuxgurugamer]

I got the changes in, and also fixed the GetComponent problem.

Beta release here:  https://github.com/linuxgurugamer/EditorExtensionsRedux/releases/tag/3.2.15

I need some feedback, please, @Fwiffo especially, since you seem to be aware of the issue.

Thanks

[Boop]

9 minutes ago, linuxgurugamer said:

I need some feedback, please, @Fwiffo especially, since you seem to be aware of the issue.

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):

Spoiler

Grab another fuselage and add two in radial symmetry:

Spoiler

Grab another fuselage, pump the number up to something silly like 20, hover over the 'original' central fuselage, notice that all works as intended:

Spoiler

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)

Spoiler

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.

 

[linuxgurugamer]

3 minutes ago, Boop said:

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):

  Reveal hidden contents

Grab another fuselage and add two in radial symmetry:

  Reveal hidden contents

Grab another fuselage, pump the number up to something silly like 20, hover over the 'original' central fuselage, notice that all works as intended:

  Reveal hidden contents

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)

  Reveal hidden contents

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.

 

That is expected behaviour.

Thanks, I'm at work and wasn't able to do more than make sure it worked.

Let's see what @Fwiffo says

Beta release here:  https://github.com/linuxgurugamer/EditorExtensionsRedux/releases/tag/3.2.15

I need some feedback, please, @Fwiffo especially, since you seem to be aware of the issue.

Thanks

[Fwiffo]

@Boop Yes, I am the culprit who broke the rule against calling GetComponent() in Update().  I was new to KSP coding (still am, really) and was not aware.  Thanks for catching that.  As far as I know it was only used for the rapid zoom feature, so changing that code shouldn't break anything related to the snap behaviors you're currently diagnosing.  (In fact I've often considered the rapid zoom function would make sense as its own mod that works in all scenes of the game... maybe one day).

10 hours ago, Boop said:

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.

Thanks a TON for isolating those steps.  Although apparently by design, that's definitely not intuitive and likely contributed to my impression of "strange behavior".

Maybe @linuxgurugamer can comment on the motivation behind it.  Perhaps it was an ill-implemented attempt to restore the user's intended symmetry count in cases where they happened to brush their mouse past a different set of parts while moving something from the toolbox onto the spacecraft.  In any case, I think it would be more intuitive to do one of:

1. Always increment / decrement starting from the current symmetry setting.
2. Make the number leap back up to 20 immediately when you hover over the 'original' fuselage in Boop's final step above, to accurately reflect where we are in the count sequence.  Or better yet, do it right after hovering out of the lower-symmetry component.  This way the game only automatically overrides your desired setting as long as needed.  Either way, EER should only restore the memorized snap count if the user hasn't manually changed it in the interim (because a user's explicit instruction should always trump the software's attempt to infer what they want).
3. Simply avoid trying to dynamically change the symmetry count without user input.  If the user tries to hover over something with different symmetry, somehow indicate the selected part can't be mounted at this time (e.g. shade it red).

While it deserves more thought, on first impression I think I personally prefer #2b.  For clarity, what I'm proposing would work something like:

1. When user hovers over part with conflicting symmetry:
   a. If there isn't already a memorized setting, then memorize current symmetry level (i.e. what it was before we hovered in).
   b. If there is already a memorized setting, we must have missed a "hover out" event (i.e. we're in a "recursive hover") and should leave the memorized setting intact to avoid overwriting the user's actual desired value.
2. Automatically change symmetry level to match hovered part.
3. If user manually adjust symmetry level (e.g. X, Shift+X, Alt+X, somehow managed to click the "R" circle, etc), then discard memorized setting and clear flag.
4. When mouse hovers out of the part, restore and discard the memorized setting, if one exists.

I think that logic would cover off edge cases where you brush over several different-symmetried parts in sequence or hover-out logic doesn't fire in between hover-in events.  Would love to hear your thoughts or alternative ideas.

10 hours ago, linuxgurugamer said:

it suddenly springs back and increments

I've noticed "springy" behavior as well, when changing snap count.  I think it might be a separate issue, though it contributes an impression of "flakiness" to the mod.

e.g. See the following test which I recorded at 15fps and annotated to show keypresses.  During the video, I only hit a key once every 1 second or so.  My mouse was not hovering over any parts (it was resting in the area on the right side of the video where the word "START" is), and was not moved at all during this time.  Pay close attention to what happens inside the symmetry count circle.

First I take the snap count up to 12.  The first three taps of X move from 1R to 4R just fine.  Notice what happens on the fourth tap - the count briefly goes up to 6R, before settling where it should be on 5R.  To reiterate, that jump-return resulted from only a single tap of the X key.
The subsequent tap from 5R to 6R works fine.  The "jumpy" behavior recurs on the transition from 6R-->7R.  7R-->8R is fine.  All of 8R-->9R, 9R-->10R, 10R-->11R and 11R-->12R exhibit springiness, but the sequence is current level --> 1 --> desired level.
You see similar behavior on some of the steps as I take the levels back down to 1R.
Once at 1R, I hit Shift+X a couple times.  Each time, you can see it jump briefly to 8R before settling at 1R.
Finally, while at 1R, I hit Alt+X which causes it to jump briefly to 2R then back to 1R.

The behavior is not intermittent - i.e. the sequence of events is reproducible the same way every time.  The Angle setting does something similar, although is less distracting since the behavior is more uniform.  Is this caused by the game responding to hotkeys before EER gets a chance to override the behavior?  Can the hotkeys for snap level be disabled or unmapped to give a more robust experience?

Although the springiness is a cosmetic distraction, I'm not sure it actually causes any problems.  I didn't test enough to discover if it ever doesn't land where expected (beyond the scenario Boop outlined above), or if you could be really quick and drop a part in between frames.  I did notice a case or two where if I used a modifier (e.g. Alt+X) it didn't seem to end up where I wanted, but suspect this is due to something low-level in how Unity queues keyboard input (game registers a frame with just X in it before Alt) or maybe timing the part of my human-limited fingers.  I probably won't be doing a lot of Editor work in the next few days, and

I also confirmed the bugs I originally reported here have not regressed.

Although I didn't play with it very much yet, I concur with Bloop that this build feels tighter than any that have come before.  I want to emphasize my tremendously appreciation for the efforts of Bloop, linuxgurugamer, and anyone else who's contributed to this mod.  It would be totally awesome if the fixes (e.g. GetComponent) were backported to the KSP 1.1.3 compatible version.

ps. Also I did notice tapping Spacebar in the part search dialog resets the VAB camera position.  Guessing this is a bug in stock KSP 1.2, not EER.  Not sure if it's been reported yet.

Edited September 16, 2016 by Fwiffo
Clarifications to 2b

[Boop]

22 minutes ago, Fwiffo said:

@Boop Yes, I am the culprit who broke the rule against calling GetComponent() in Update().  I was new to KSP coding (still am, really) and was not aware.  Thanks for catching that.

 

Only one reason I can have known about it - I must have made the same mistake at some point!

 

25 minutes ago, Fwiffo said:

1. Always increment / decrement starting from the current symmetry setting
2. Make the number leap back up to 20 immediately when you hover over the 'original' fuselage in Boop's final step above (or better yet, right after hovering away from the lower-symmetry component) - provided the user hasn't manually changed the count since then (since a user's explicit instruction should always trump a software's attempt to infer what they want), or
3. Simply avoid trying to dynamically change the symmetry count without user input.  If the user tries to hover over something with different symmetry, somehow indicate the selected part can't be mounted at this time.

 

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.

 

31 minutes ago, Fwiffo said:

 

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!

[Fwiffo]

11 minutes ago, Boop said:

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.

I agree.  I've made edits to my post since you read it, to more formally outline what I'm proposing, but it's still tricky and I'm not sure how straightforward to accomplish in KSP.

11 minutes ago, Boop said:

That temporary flip to 8 from 1 with Shift-x is bizarre!

Maybe you avoided playing without EER for so long that you forgot 8 is the stock game's maximum symmetry, and Shift+X-ing from 1R causes the stock game to wrap around backwards to 8R. EER (thankfully) does not wrap.  ;-)

Edited September 16, 2016 by Fwiffo