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

[Fwiffo]

1 hour ago, Fwiffo said:

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...

Actually, I think I did find a bug, and it also explains the intermittent behavior I described above and my occasional frustrations when rapid sequences of hotkeys don't change the symmetry level to what I want.

@Boop Could you please try setting your symmetry count to 6R for me, then repeatedly hit X, Shift+X, X, Shift+X, etc. to cycle between 6R and 5R?  After a few keystrokes I find myself unexpectedly at 7R or 8R.  I think I can even get it to happen when I hit the keys slow enough to be sure I'm not accidentally hitting X before the Shift modifier^★.

I'm wondering if maybe a hotkey is getting captured during the "spring" phase of a transition, in which case the behavior might not be as cosmetic as I thought.

^★EDIT: Hey, you have the code in front of you. Assuming you can reproduce this, how hard would it be to temporarily hardcode independent, single-button hotkeys for "Cycle Forward" / "Cycle Back" to eliminate race conditions between "Shift" and "X" buttons as a factor here?  No pressure...

Edited September 16, 2016 by Fwiffo

[Boop]

11 hours ago, Fwiffo said:

Actually, I think I did find a bug, and it also explains the intermittent behavior I described above and my occasional frustrations when rapid sequences of hotkeys don't change the symmetry level to what I want.

@Boop Could you please try setting your symmetry count to 6R for me, then repeatedly hit X, Shift+X, X, Shift+X, etc. to cycle between 6R and 5R?  After a few keystrokes I find myself unexpectedly at 7R or 8R.  I think I can even get it to happen when I hit the keys slow enough to be sure I'm not accidentally hitting X before the Shift modifier^★.

I'm wondering if maybe a hotkey is getting captured during the "spring" phase of a transition, in which case the behavior might not be as cosmetic as I thought.

^★EDIT: Hey, you have the code in front of you. Assuming you can reproduce this, how hard would it be to temporarily hardcode independent, single-button hotkeys for "Cycle Forward" / "Cycle Back" to eliminate race conditions between "Shift" and "X" buttons as a factor here?  No pressure...

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!

[Fwiffo]

@Boop Is there any sort of flag we can pass back from a KeyDown event handler to indicate to KSP that we've handled the press and it should swallow the event and not invoke any further handlers?  Otherwise, could we unbind the Cycle Symmetry key ("X") to cut off the game's handlers, and handle it solely in the mod?

BTW did you get a chance to try this out?

19 hours ago, Fwiffo said:

 Could you please try setting your symmetry count to 6R for me, then repeatedly hit X, Shift+X, X, Shift+X, etc. to cycle between 6R and 5R?  After a few keystrokes I find myself unexpectedly at 7R or 8R.  I think I can even get it to happen when I hit the keys slow enough to be sure I'm not accidentally hitting X before the Shift modifier

 

Edited September 16, 2016 by Fwiffo

[Boop]

14 hours ago, Fwiffo said:

@Boop Is there any sort of flag we can pass back from a KeyDown event handler to indicate to KSP that we've handled the press and it should swallow the event and not invoke any further handlers?  Otherwise, could we unbind the Cycle Symmetry key ("X") to cut off the game's handlers, and handle it solely in the mod?

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.

Quote

Could you please try setting your symmetry count to 6R for me, then repeatedly hit X, Shift+X, X, Shift+X, etc. to cycle between 6R and 5R?  After a few keystrokes I find myself unexpectedly at 7R or 8R.  I think I can even get it to happen when I hit the keys slow enough to be sure I'm not accidentally hitting X before the Shift modifier

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.

[Boop]

Quote

I'm going to have another go

 

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.

[Fwiffo]

4 hours ago, Boop said:

did this for a minute solid and couldn't reproduce it - at least not while using @linuxgurugamer's beta version in 1.2 pre.

Interesting, I guess it's just me then!  if you want to sent me your beautifully kludged "[" & "]" build I'd be keen to retest under that one.

BTW, are you running under Windows or Linux (or other)? (sorry if I missed this before)

Edited September 17, 2016 by Fwiffo

[Boop]

37 minutes ago, Fwiffo said:

Interesting, I guess it's just me then!  if you want to sent me your beautifully kludged "[" & "]" build I'd be keen to retest under that one.

BTW, are you running under Windows or Linux (or other)? (sorry if I missed this before)

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

Running on Windows.

[Fwiffo]

@Boop Thanks.  I can verify; the "[" and "]" independent hotkeys are completely smooth (no "spring").

I can still reproduce the "X" and "Shift+X" jump I described further up.  I've narrowed down steps to reproduce, and discovered it can occur while switching between "normal" symmetry counts as well as the non-stock ones.  Could you please try this:

1. Start at "2R"
2. Hold down Shift
3. Press down X (goes to "1R")
4. Release Shift, while still holding down X
5. Wait as long as you want, then release X.  At this point it jumps to 3R.

The jump does not occur in stock.

I'll bet this was a bug introduced during the 1.0.3-related change to GetKeyUp() you highlighted.  By the time GetKeyUp() is triggered, the Shift key has already been released, so the modifier is "lost".

I also noticed unlike stock, EER does not work with the right shift button.  So "weird-looking" behavior ensues as stock cycles downward and then EER jumps it back up to +1 from where you started.  Go ahead, try it out.

Finally, one other observation - unlike EER, stock does not allow changing symmetry count or angle snap if there are no parts yet placed in the Editor.  I don't think this one really matters, though.

Edited September 17, 2016 by Fwiffo

[Fobok]

24 minutes ago, Fwiffo said:

I also noticed unlike stock, EER does not work with the right shift button.  So "weird-looking" behavior ensues as stock cycles downward and then EER jumps it back up to +1 from where you started.  Go ahead, try it out.

 

Aha! That's been my problem. I thought it was a mod conflict (I didn't report as I couldn't find anything in the logs and I have so many mods) and resorted to mouse to change symmetry back down again. Due to disability, using left shift with x is awkward to the extreme for me, so I never even tried it.

[Boop]

@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 

[linuxgurugamer]

6 hours ago, Boop said:

@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 just pushed all the changes to Github, and yes, please do continue.

Edited September 17, 2016 by linuxgurugamer

[Boop]

21 minutes ago, linuxgurugamer said:

I just pushed all the changes to Github

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]

3 minutes ago, Boop said:

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

Sweet!

42 minutes ago, Boop said:

I can't believe we filled nearly 2 pages of forum talking about a hotkey that increments a number by 1

For sure.  But if it results in a version that quits tripping me up and really does inc/dec by exactly 1, it'll be well worth it (at least from my perspective)!

Edited September 17, 2016 by Fwiffo

[PickledTripod]

You know, I wish StripSymmetry and NoOffsetLimits were still standalone mods. I rarely if ever use the rest of EER's features and the buggy interactions between the stock system and this mod that were discussed above are extremely frustrating to me. I've been building stuff in KSP since long before my favorite editor mods were merged with EER and the keyboard shortcut are now muscle memory that's very difficult and annoying to fight against. I understand that most people like it this way and it's easier to distribute it all as one big mod, especially considering the sheer number of mods you're maintaining, but you know, if there were separate DLLs for StripSymmetry, NoOffsetLimits and EER and I could just delete the last one I'd be really happy.

EDIT: the tab I wrote my reply in had been sitting open for a few hours before I posted, I just saw that you are actually working on a solution for my main beef with this mod... If it works then I have on complaints anymore, sorry for bothering you.

Edited September 17, 2016 by PickledTripod

[Fwiffo]

Hey @PickledTripod, I can empathize with your frustration when your muscle-memorized reflexes don't quite achieve what you want.  Hopefully the upcoming build from Boop will nail down the issue.  We sure could use help testing it once it's ready :-).

[Boop]

@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".

[Fwiffo]

1 hour ago, Boop said:

@Fwiffo right, try this on for size

Best EER ever.  Works like a charm.  I see you also implemented the solution #1 to make the snap cycling behavior a little more intuitive when hovering on/off radially mounted parts.

Edit: Right-shift still doesn't function; @Fobok might appreciate getting that addressed if it's not too difficult.

Edit: This next bit occurs exactly the same way in stock, too, so clearly isn't induced by EER.  The mod could possibly take the opportunity to enhance the behavior (as mentioned below) but I understand if that's out of scope of this release.

Spoiler

I did notice one other thing (likely preexisting).

1. Drop an FL-T400 tank (specific parts don't matter).
2. Radial mount a pair of FL-T200 tanks on it.
3. Grab an FL-T100 and hover it over one of the FL-T200's from previous step.
4. You will see it prepares to mount it radially around the ship:
   
    
5. While still hovering there, press X.  You will see it now intends to mount it radially around the parent part:
   
    
6. Press Shift+X then X again (or briefly hover elsewhere and return).  Now it wants to mount around the ship, again.

Not sure if that's intended behavior.  As far as I can tell it's not causing any harm.  If intentional, it could actually be handy if you were allowed to press X a few more times after Step 5 to mount more of them (assuming the results are KSP-Kosher).

BTW, once all's said and done, could I get a build for 1.1.3, too?  (Or the source so I can build one myself?)

Edited September 18, 2016 by Fwiffo
Note right-shift still not captured

[PickledTripod]

A 1.1.3 build would really be appreciated, I won't start playing 1.2 until most of my essential mods are updated and I'm pretty sure that's the case for a lot of people. But I'm glad to hear that this issue is a thing of the past!

[Boop]

1 hour ago, Fwiffo said:

Edit: Right-shift still doesn't function; @Fobok might appreciate getting that addressed if it's not too difficult.

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.

 

1 hour ago, Fwiffo said:

BTW, once all's said and done, could I get a build for 1.1.3, too?  (Or the source so I can build one myself?)

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

35 minutes ago, Boop said:

settings.cfg:

Editor_fineTweak
{
    primary = LeftShift
    secondary = None RightShift

That explains it.  Sorry, I should have caught that.  Works perfectly.

35 minutes ago, Boop said:

@Fwiffo can use the info to build one for 1.1.3 and make it available if he likes

I'll be happy to.  Eager for some source!  I know you're going to awesomely outline the changes, but if you can send me a copy of your final code (even if it's messy) it would help me via compare tools on this end to verify I don't miss anything.

Edited September 18, 2016 by Fwiffo

[Boop]

39 minutes ago, Fwiffo said:

Eager for some source!

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.

[Fwiffo]

@Boop I almost never use the 1° setting.  It's very subtle, but as far as I can tell with your build it seems to (correctly) be slightly more coarse than the EER "no snap" setting.

In stock, "no snap" works fine (and the same as EER no-snap) when you use the rotation gizmo.  When you are hovering parts in stock, it kinda appears as if there is a ~5° snap, but I think that's just the result of less dense "normal" angles used for the attachment when no-snapping vs. snapping.  That make sense?

I can C/Shift+C fine.

Did you break something with the Alt modifier, or did my keybindings get mucked up?  It doesn't seem to reset to lowest anymore, for either angle or symmetry.

I'm planning on doing a fair bit of craft editing tonight (and maybe tomorrow), which is why I'm hoping to get a 1.1.3 build happening (even if it's just beta) to capitalize on the opportunity to kick the tires a bit.  I'm mostly holding off on 1.2 until more of my 60+ mods support it.

 

Edited September 18, 2016 by Fwiffo

[Boop]

5 minutes ago, Fwiffo said:

Did you break something with the Alt modifier, or did my keybindings get mucked up?  It doesn't seem to reset to lowest anymore, for either angle or symmetry.

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?

[Fwiffo]

2 minutes ago, Boop said:

Can you confirm whether that is in fact an EER thing, or also what stock does?

I tried before reporting, and Alt did nothing in Stock, so I assumed either stock lacks the Alt feature or I had a keybinding get screwed up.

Also note while you replied, I was editing my previous response with some more regarding the stock "5 degree" thing.

[Boop]

3 minutes ago, Fwiffo said:

I tried before reporting, and Alt did nothing in Stock, so I assumed either stock lacks the Alt feature or I had a keybinding get screwed up.

Also note while you replied, I was editing my previous response with some more regarding the stock "5 degree" thing.

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?