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

[Fwiffo]

Hey @Boop is it possible the tweaks you made cause KSP to loose the Editor_toggleSymMode and Editor_toggleAngleSnap bindings if the game is terminated ungracefully?

I've noticed if I kill KSP via task manager while in the Editor, the next time I load it up the X and C keys are no longer bound.  At first I thought it was my own fault due to other stuff I was messing with, but today I noticed settings.cfg is changed as soon as I enter the VAB.

I guess there's no way to intercept and override the game's internal handling of those hotkeys without tampering with the settings.cfg file?  A little quality-of-life option in EER to restore those keys next boot if missing would be great (or an option to simply have it handle those keystrokes and leave the ones in settings.cfg permenantly unbound).

I realize the simple workaround is to exit the VAB/SPH first, and that most people don't kill or crash the game while in the Editor.  I do all the time, due to the need to reload part weldments.

Edited October 14, 2016 by Fwiffo

[Boop]

21 minutes ago, Fwiffo said:

Hey @Boop is it possible the tweaks you made cause KSP to loose the Editor_toggleSymMode and Editor_toggleAngleSnap bindings if the game is terminated ungracefully?

I've noticed if I kill KSP via task manager while in the Editor, the next time I load it up the X and C keys are no longer bound.  At first I thought it was my own fault due to other stuff I was messing with, but today I noticed settings.cfg is changed as soon as I enter the VAB.

I guess there's no way to intercept and override the game's internal handling of those hotkeys without tampering with the settings.cfg file?  A little quality-of-life option in EER to restore those keys next boot if missing would be great (or to just have it handle the hotkeys and leave the ones in settings.cfg permenantly unbound).

I realize the simple workaround is to exit the VAB/SPH first, and that most people don't kill or crash the game while in the Editor.  I do all the time, due to the need to reload part weldments.

 

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?

[Fwiffo]

33 minutes ago, Boop said:

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.

I thought so, and furthermore thought I did the same!

I thought I was using a recent (as in downloaded yesterday) release linuxgurugamer posted (and had been under the impression it was annotated as compatible with 1.1.3) but now I'm thinking I must have been confused.

Now I'm trying to figure out which version I'm supposed to be using with KSP 1.1.3.  I just tried with a clean install of the most recent 3.3.2 mod and it doesn't work.

The 3.2.15.1 build I made on Sep 18 isn't still the most up-to-date 1.1.3-compatible edition of this mod, is it?  If so, let me know and I'll make a fresh build using latest source against the older KSP/Unity DLL's.

BTW @linuxgurugamer maybe next 'round a bit of minor cleanup/synchronization can be done re: version #'s.  Presently:

• There are GitHub tags and releases up to 3.3.2
• Changelog only covers to 3.2.14 (not the end of the world)
• The DLL in the 3.3.2 zip is versioned 3.2.13 (this one had me misled until I figured it out)

Edited October 14, 2016 by Fwiffo

[Fwiffo]

@Boop, @linuxgurugamer

Haven't found a recent KSP-1.1.3-compatible release so working on it now.  Tried a build with the following tweaks:

• Changed FindAttachNodeByPart back to findAttachNodeByPart
• Commented out "rotOffset," in call to GizmoOffset.Attach on line 46 of NoOffsetLimitsBehavior.cs (since that parameter doesn't exist for KSP 1.1.3)
• Commented out subsequently-unused "Quaternion rotOffset = p.attRotation;" two lines up
• Ammended Description field of DLL metadata to say "Kerbal Space Program Plugin : Editor Extensions (for KSP 1.1.x)" and File Description to "EditorExtensions (for KSP 1.1.x)"
• Numbered my version 3.3.2.1 (hope that's ok)

It seems to be at least somewhat working, but NoOffsetLimits is broken.  Trying to track that down... you guys are much more familiar with the codebase; I welcome any hints ;-)

Edited October 14, 2016 by Fwiffo

[Boop]

2 minutes ago, Fwiffo said:

I welcome any hints ;-)

 

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

[Fwiffo]

2 minutes ago, Boop said:

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

DANG-it.  Yes, still messed up, i.e. the mod causes their bindings to be set to None when entering the Editor.  (Didn't even bother to check before; I just assumed you instituted the fix after I made my Sep 18 build and it would come with the new code along with all those other lovely new enhancements I'm hoping to backport).  Looks like this might be a little trickier than I thought.

[Boop]

1 minute ago, Fwiffo said:

DANG-it.  Yes, still messed up, i.e. the mod causes their bindings to be set to None when entering the Editor.  (Didn't even bother to check before; I just assumed you instituted the fix after I made my Sep 18 build and it would come with the new code along with all those other lovely new enhancements I'm hoping to backport).  Looks like this might be a little trickier than I thought.

 

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

[Fwiffo]

11 minutes ago, Boop said:

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.

I am 99% sure it does not.  I just did a quick test in my "cleanroom" 1.2 environment (virtually no other mods present) and it works fine.  I would need to do some more testing to completely rule out interaction from other mods causing my problems under 1.1.3 but given how specific a symptom this is I would be surprised if that's the case.

BTW while I'm here... an unrelated suggestion.  Next release we might consider making the NoOffsetLimits feature a user-toggleable option.  I remember some complaints about it being bundled, and sometimes I myself would love to turn that off to avoid "cheating", while still using the rest of EER.

Edited October 14, 2016 by Fwiffo

[Boop]

1 minute ago, Fwiffo said:

I am 99% sure it does not (i.e. works fine under 1.2).  I just did a quick test in my "cleanroom" 1.2 environment (virtually no other mods present).  I would need do some more testing to rule out interaction from other mods causing my problems under 1.1.3 but given how specific a symptom this is I would be surprised if that's the case.

BTW while I'm here... an unrelated suggestion.  Next release we might consider making the NoOffsetLimits feature a user-toggleable option.  I remember some complaints about it being bundled, and sometimes I myself would love to turn that off to avoid "cheating", while still using the rest of EER.

 

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

[Fwiffo]

3 minutes ago, Boop said:

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.

You're right.  For some reason I thought you must have fixed it after my build, but I guess not.

Will squirrel at it a little.  This build I'm making wants to succeed.  The new master snap stuff is working properly under 1.1.3.  I could work around the insta-quit stuff other ways if needed.  Still trying to hunt down why NoOffsetLimits broke.

[Fwiffo]

44 minutes ago, Fwiffo said:

I am 99% sure it does not.  I just did a quick test in my "cleanroom" 1.2 environment (virtually no other mods present) and it works fine.  I would need do some more testing to completely rule out interaction from other mods causing my problems under 1.1.3 but given how specific a symptom this is I would be surprised if that's the case.

@Boop Actually, come to think of it it might be possible another mod (that isn't installed in my 1.2) is triggering a save of the game settings after EER changes the hotkeys.

Edited October 15, 2016 by Fwiffo

[Boop]

2 minutes ago, Fwiffo said:

@Boop Actually, come to think of it it might be possible another mod (that isn't installed in my 1.2) is triggering a save of the game settings after EER changes the hotkeys.

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

[linuxgurugamer]

1 hour ago, Fwiffo said:

I thought so, and furthermore thought I did the same!

I thought I was using a recent (as in downloaded yesterday) release linuxgurugamer posted (and had been under the impression it was annotated as compatible with 1.1.3) but now I'm thinking I must have been confused.

Now I'm trying to figure out which version I'm supposed to be using with KSP 1.1.3.  I just tried with a clean install of the most recent 3.3.2 mod and it doesn't work.

The 3.2.15.1 build I made on Sep 18 isn't still the most up-to-date 1.1.3-compatible edition of this mod, is it?  If so, let me know and I'll make a fresh build using latest source against the older KSP/Unity DLL's.

BTW @linuxgurugamer maybe next 'round a bit of minor cleanup/synchronization can be done re: version #'s.  Presently:

• There are GitHub tags and releases up to 3.3.2
• Changelog only covers to 3.2.14 (not the end of the world)
• The DLL in the 3.3.2 zip is versioned 3.2.13 (this one had me misled until I figured it out)

I'll work on that later, but for now, the current release of EEX is NOT compatible with 1.1.3, and the .version file says that.

I don't have time right now to go regress stuff for 1.1.3, I still have a number of mods to update for 1.2  That being said, if @Boop gets it fixed, I won't mind having a seperate 1.1.3 branch

[Boop]

19 minutes ago, linuxgurugamer said:

I'll work on that later, but for now, the current release of EEX is NOT compatible with 1.1.3, and the .version file says that.

I don't have time right now to go regress stuff for 1.1.3, I still have a number of mods to update for 1.2  That being said, if @Boop gets it fixed, I won't mind having a seperate 1.1.3 branch

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 

Edited October 15, 2016 by Boop
typo

[Tarheel1999]

@linuxgurugamer The Master Snap and the part sliding are very cool.  When you get a chance maybe you could update the OP so this functionality won't be hidden.  I figured it out by looking at the config file for the keybind and trial and error.  For everyone else here is how I think it works:

1) Hold down "left control" and select the "master" part;

2) Hover the cursor over the child part and press "v" for vertical snap or "h" for a horizontal snap. This will snap the child part to the master part's vertical or horizontal position;

3) Click on an empty space to turn off Master Snap.

This should prove to be very useful for VTOLs where you can't apply engines in symmetry.

Thanks for being awesome LGG

[Fwiffo]

1 hour ago, Boop said:

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

Theory confirmed.  It's not a KSP 1.1.3 vs 1.2 thing.  It's mod interaction.  In my case, having TimeControl by @westamastaflash installed is triggering the GameSettings to save when entering the Editor.

Looking at his code I think the problem is in here:

Spoiler

private void Update()
{
    if (!IsReady)
        return;

    if (needsSaved && (Time.realtimeSinceStartup - lastSave > saveInterval))
    {
        string logCaller = "Settings.Update()";
        Log.Trace( "Saving Settings & Time Control Config Starting", logCaller );

        lastSave = Time.realtimeSinceStartup;

        GameSettings.PHYSICS_FRAME_DT_LIMIT = MaxDeltaTimeSlider;
        GameSettings.SaveSettings();

        buildAndSaveConfig( false );

        Log.Trace( "Saving Settings & Time Control Config Complete", logCaller );
    }
}

 

I let him know.  Since the time delta can't be changed by a user while in the VAB/SPH hopefully he can throw us a bone by avoiding the call to GameSettings.SaveSettings while in the Editor scene.

The good news is I've confirmed about 60 other mods do not cause this problem.

However there's no guarantee some other mod-maker might have a good reason to trigger a save while in the Editor, so I agree it would be good to add a warning about the potential for lost keybindings to the documentation.  That "auto-heal" feature you suggested would be a great perk, too - although could annoy someone who intentionally wants their binding for those hotkeys to be None.  I suppose you could create a little breadcrumb file on entering the Editor and clean it up on leaving in order to distinguish an unclean shutdown from a bonafide lack of binding, although that might be taking this a little too far.

1 hour ago, linuxgurugamer said:

I don't have time right now to go regress stuff for 1.1.3, I still have a number of mods to update for 1.2

Totally understand.  Have I mentioned how grateful we all are for all your hard work?

In the meantime... if you have any ideas off the top of your head at where I might dig to root out why NoOffsetLimits isn't working feel free to let me know!  I've already got NoOffsetsLimitsBehavior.cs looking identical to what it was in the old (working) version, so I know the problem's not there.  Presently comparing the many diffs in EditorExtensionsRedux.cs in search of illumination.

33 minutes ago, Tarheel1999 said:

When you get a chance maybe you could update the OP so this functionality won't be hidden.  I figured it out by looking at the config file for the keybind and trial and error.  For everyone else here is how I think it works

Thanks for that; I had a little trouble figuring it out too (but had a little help since the source code happened to be in front of me).  Once you do figure it out, the feature is awesome (and I love the way the part "slides" into place).

Edited October 15, 2016 by Fwiffo

[linuxgurugamer]

51 minutes ago, Tarheel1999 said:

@linuxgurugamer The Master Snap and the part sliding are very cool.  When you get a chance maybe you could update the OP so this functionality won't be hidden.  I figured it out by looking at the config file for the keybind and trial and error.  For everyone else here is how I think it works:

1) Hold down "left control" and select the "master" part;

2) Hover the cursor over the child part and press "v" for vertical snap or "h" for a horizontal snap. This will snap the child part to the master part's vertical or horizontal position;

3) Click on an empty space to turn off Master Snap.

This should prove to be very useful for VTOLs where you can't apply engines in symmetry.

Thanks for being awesome LGG

Thanks, as you can guess, I've been rather busy with updates.

I'll add your comments, they do a nice job of describing it.

[Boop]

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

Edited October 15, 2016 by Boop
reasons

[linuxgurugamer]

I took a look at TimeControl, found and fixed the problem.  I submitted a PR to the author.

In the meantime, here is a DLL with the fix, compiled for 1.2:

https://www.dropbox.com/s/99o6gqqp9j98buj/TimeControl.zip?dl=0

17 minutes ago, Boop said:

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

There isn't any reason for a mod to force the game to save settings while in the Editor.  Hopefully no one will do this, although I kind of understand his reasons in general, I think it wasn't the best decision

Edited October 15, 2016 by linuxgurugamer

[Fwiffo]

@linuxgurugamer Once again, you are a hero!

[linuxgurugamer]

@Boop

About the autostruts:

I think this will do it for you:  

     void Part.DrawAutoStrutLine()

It's a private function, but maybe with Reflection?

Edited October 15, 2016 by linuxgurugamer

[Fwiffo]

3 hours ago, Fwiffo said:

If you have any ideas off the top of your head at where I might dig to root out why NoOffsetLimits isn't working feel free to let me know!  I've already got NoOffsetsLimitsBehavior.cs looking identical to what it was in the old (working) version, so I know the problem's not there.  Presently comparing the many diffs in EditorExtensionsRedux.cs in search of illumination.

I must be doing something stupid wrong.  I went back to what I believe is the code I used to compile my original 3.2.15.1 DLL.  The original DLL works, but when I recompile it using what I think is exactly the same code, it doesn't.  Either I contaminated my old code, or my build environment, or I'm just loosing it.

Dumb question - does it make a difference if I reference the x86 vs x64 KSP dll's in my project?  (I've always been referencing the x86 ones, since I don't know of a way to reference different DLL's for different "bitnesses" when compiling for a single AnyCpu target)

Edited October 15, 2016 by Fwiffo

[Fwiffo]

1 hour ago, Fwiffo said:

Either I contaminated my old code, or my build environment

Oh for pete's sake.  <Takes a giant hammer and smacks it over my head repeatedly while reciting "USE. VISUAL. STUDIO. 2015. NOT. 2010!">

All my problems suddenly evaporated.  The world is right again.

I present you with: Editor Extensions Redux 3.3.2[.1] for KSP 1.1.x

(At least until linuxgurugamer gets around to releasing an official KSP 1.1.3-compatible package).

@linuxgurugamer I did some work in the enclosed readme.md which you might want to grab for your main branch (and sent you a PR).  The only code changes are the ones I listed a few posts up.

Edited October 15, 2016 by Fwiffo

[Vitaspy]

Hey, I love everything in this mod except the snap angles and symmetry (pressing X and C for surface mounted parts), and I wonder if it is possible to disable it and have it the stock way?

[Fwiffo]

4 hours ago, Vitaspy said:

Hey, I love everything in this mod except the snap angles and symmetry (pressing X and C for surface mounted parts), and I wonder if it is possible to disable it and have it the stock way?

Crazy, 'cause that's the thing I love most about this mod ;-).  You could try deleting the unwanted angle snap degree stops in the mod's settings.