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

[linuxgurugamer]

2 hours ago, Doghead13 said:

It is an on/off switch for the stock thing that doesn't involve going into the cheat menu. That's all.

I think what he wants to know (and so do I), is what is that cheat option for?  As he said, you can already clip parts without it.

[Apollo13]

14 minutes ago, linuxgurugamer said:

I think what he wants to know (and so do I), is what is that cheat option for?  As he said, you can already clip parts without it.

Exactly correct, sir.  Using the stock function, I place parts (batteries, MechJeb) inside other parts using the translation gizmo.  I also use that gizmo to "slide" a nosecone and other parts down onto parts that would be exposed to the airstream.

Edited May 22, 2016 by Apollo13

[swjr-swis]

1 hour ago, Apollo13 said:

Exactly correct, sir.  Using the stock function, I place parts (batteries, MechJeb) inside other parts using the translation gizmo.  I also use that gizmo to "slide" a nosecone and other parts down onto parts that would be exposed to the airstream.

The name (and description) is a bit misleading: it's nothing to do with clipping parts into others, it just allows to use the same stack attachment nodes multiple times.

Eg.: Place an Mk1 Pod, then a tank below that on the node, then add a second tank at exactly the same node, so both are attached to the Mk1 bottom node. In the editor, you can notice this because a 'used' node will continue to show as available, and will accept anything attached to it.

And the reasons why this is risky: fuel routing can sometimes get very screwy, and some parts do end up very clipped into each other and cannot handle that without exploding.

[linuxgurugamer]

2 hours ago, swjr-swis said:

The name (and description) is a bit misleading: it's nothing to do with clipping parts into others, it just allows to use the same stack attachment nodes multiple times.

Eg.: Place an Mk1 Pod, then a tank below that on the node, then add a second tank at exactly the same node, so both are attached to the Mk1 bottom node. In the editor, you can notice this because a 'used' node will continue to show as available, and will accept anything attached to it.

And the reasons why this is risky: fuel routing can sometimes get very screwy, and some parts do end up very clipped into each other and cannot handle that without exploding.

Thank you for that concise explanation.

[OliverPA]

@linuxgurugamer I'm new to the Github stuff so I'm not sure if my pull request worked as expected.

Basically I found myself wishing for a possibility to use the H hotkey to horizontally align along the other horizontal axis (z-axis).

Only a very minor change was needed to extend EditorExtensionsRedux.cs to use the H hotkey (or whatever the user has set) for x and Shift+H for z axis.
I would have preferred to use the mod-key but mod+H is already taken by HyperEdit

[linuxgurugamer]

2 hours ago, OliverPA said:

@linuxgurugamer I'm new to the Github stuff so I'm not sure if my pull request worked as expected.

Basically I found myself wishing for a possibility to use the H hotkey to horizontally align along the other horizontal axis (z-axis).

Only a very minor change was needed to extend EditorExtensionsRedux.cs to use the H hotkey (or whatever the user has set) for x and Shift+H for z axis.
I would have preferred to use the mod-key but mod+H is already taken by HyperEdit

That would be a nice addition, but I don't see it on Github yet.

If it's a simple change send me the file and I'll add it manually.

 

Thanks

[OliverPA]

15 minutes ago, linuxgurugamer said:

That would be a nice addition, but I don't see it on Github yet.

If it's a simple change send me the file and I'll add it manually.

 

Thanks

It's this one: https://github.com/OliverPA77/EditorExtensionsRedux/pull/1/files

I created a fork, then a branch and a pull request but apparently the PR is now within my fork and not visible to you?
Before this I tried to create the PR in your project site but it didn't let me.

Btw. I've also implemented a shortcut to open the fine adjust window (including setting in settings window) and am now going to have another new setting that opens and closes it automatically whenever the translate/rotate gizmos are activated. The shortcut is definitely convenient but I'm not sure yet how the auto-thing is going to be like...

Edited May 29, 2016 by OliverPA

[linuxgurugamer]

9 minutes ago, OliverPA said:

It's this one: https://github.com/OliverPA77/EditorExtensionsRedux/pull/1/files

I created a fork, then a branch and a pull request but apparently the PR is now within my fork and not visible to you?
Before this I tried to create the PR in your project site but it didn't let me.

Btw. I've also implemented a shortcut to open the fine adjust window (including setting in settings window) and am now going to have another new setting that opens and closes it automatically whenever the translate/rotate gizmos are activated. The shortcut is definitely convenient but I'm not sure yet how the auto-thing is going to be like...

Try creating the pull request again, it looks like it should work.

you might need to merge the branch into the head before doing the pull request

Re. the shortcut, I'll think about it, but am concerned about too many keyboard shortcuts.  But you can't have it close automatically, because someone might be doing a number of adjustments, flipping between the two gizmos

Edited May 29, 2016 by linuxgurugamer

[swjr-swis]

On 12/8/2015 at 3:09 PM, linuxgurugamer said:

Only one click needed. Just click on the part you want to be the new root.

I noticed that the one-click functionality interferes with the recent stock ability to also reroot floating subassemblies (transparent sets of parts disconnected from the main craft and set aside while editing). It simply refuses to do anything with floating sections.

Would it be very difficult to add that ability to SelectRoot? If not, at least make it not interfere or revert to stock behaviour when I try reroot a floating subassembly. I would prefer the awkward stock two clicks than it not working at all, I encounter this issue surprisingly often.

[OliverPA]

2 hours ago, linuxgurugamer said:

you might need to merge the branch into the head before doing the pull request

Yes I think hat did the trick, thanks for the tip!

[linuxgurugamer]

3 hours ago, linuxgurugamer said:

Try creating the pull request again, it looks like it should work.

you might need to merge the branch into the head before doing the pull request

Re. the shortcut, I'll think about it, but am concerned about too many keyboard shortcuts.  But you can't have it close automatically, because someone might be doing a number of adjustments, flipping between the two gizmos

Pull request came through, thanks

[OliverPA]

If you want to have a look at the hotkey for the fine adjust window: https://github.com/linuxgurugamer/EditorExtensionsRedux/compare/master...OliverPA77:hotkeyFAW?expand=1
There's also a binary as draft release to try it out real quick.

I put "None" as default for the new hotkey so if a user wanted to assign it they'd have to do it consciously without the mod spamming the keyboard with unwanted shortcuts. It's a good compromise, no? Have a look, if you like it I'd create a PR...

The auto opening/closing of the window actually works quite nicely regarding the key-controlled adjustments. You open translate/rotate gizmo and the window opens. You switch to another gizmo and it closes:

// automatically show fine adjust window when offset or rotate gizmo are active
if ((GizmoEvents.offsetGizmoActive || GizmoEvents.rotateGizmoActive) && cfg.AutoFineAdjustWindow && !_fineAdjustWindow.isEnabled()) {
  _fineAdjustWindow.Show();
}
// automatically hide fine adjust window when offset or rotate gizmo are inactive
if (!GizmoEvents.offsetGizmoActive && !GizmoEvents.rotateGizmoActive && cfg.AutoFineAdjustWindow && _fineAdjustWindow.isEnabled()) {
  _fineAdjustWindow.CloseWindow();
}

But currently the fine adjust window also removes the snapping feature when using the mouse and this would need to go to be useful altogether.

Btw. any particular reason why the fine adjustments are triggered by GetKey and not GetKeyDown? It happens quite regularly that the part is moved too far...
 

[linuxgurugamer]

On 5/29/2016 at 1:35 PM, swjr-swis said:

I noticed that the one-click functionality interferes with the recent stock ability to also reroot floating subassemblies (transparent sets of parts disconnected from the main craft and set aside while editing). It simply refuses to do anything with floating sections.

Would it be very difficult to add that ability to SelectRoot? If not, at least make it not interfere or revert to stock behaviour when I try reroot a floating subassembly. I would prefer the awkward stock two clicks than it not working at all, I encounter this issue surprisingly often.

I've created this as an issue on Github so I don't lose track of it

[awang]

On 5/19/2016 at 8:16 AM, linuxgurugamer said:

Just released 3.2.12:

Fixed rotation gizmo to not angle snap when anglesnap is off
Replaced code which did FindObjectsOftype with GizmoEvents class for performance improvement
Updated FineAdjustments window to detect which gizmo is active
 

@awang I just released 3.2.12, should fix your issue.  Please let me know

Sorry, I somehow managed to miss this back then. Performance is indeed much better. Thank you!

[swjr-swis]

@linuxgurugamer Another pesky request for EEX to revert to stock behaviour in a specific circumstance: can EEX please, please obey me when I tell it to switch symmetry modes, or get a setting to stop it from forcing symmetry modes the way it does?

Alternatively, if that is not possible somehow, is it possible to get some kind of master on/off switch to completely disable EEX and revert to full stock behaviour just for those moments when I need to do something that the stock editor is perfectly ok with me doing?

 

Context and some frustration venting:

Spoiler

 

Yes, I am one of those people that sometimes purposely uses mirror symmetry in the VAB and radial symmetry in the SPH, and sometimes, yes, gasp, I even do mix both symmetries in the same craft. In some designs it is the only way to get parts placed in the correct manner. I have already grudgingly accepted the kraken-enforced limitation that I cannot mix symmetries on the same single part, but at least stock will accept without question when I tell it to use mirror for another set of parts when the rest of the craft so far has used radial... or the other way around.

EEX, as much as I love the utility of it otherwise, will simply and unbudgingly REFUSE sometimes to change symmetry modes, and at hitting 'R' automatically and immediately changes my chosen symmetry mode back to what it feels it should be. I'm sure it's trying to tell me something with that, but I simply do. not. care, I hit 'R' on purpose, and it just makes me quit the game and uninstall EEX, because in stock, I CAN use the symmetry mode I want, and it works, and the craft works. So whatever handholding EEX is trying to do with this symmetry-enforcing behaviour is completely lost on me, and after two or three times of encountering this, EEX just ends up permanently uninstalled again despite its other useful functions.

So please, allow me some way of stopping EEX interfering with my chosen symmetry mode.

 

 

[linuxgurugamer]

2 hours ago, swjr-swis said:

@linuxgurugamer Another pesky request for EEX to revert to stock behaviour in a specific circumstance: can EEX please, please obey me when I tell it to switch symmetry modes, or get a setting to stop it from forcing symmetry modes the way it does?

Alternatively, if that is not possible somehow, is it possible to get some kind of master on/off switch to completely disable EEX and revert to full stock behaviour just for those moments when I need to do something that the stock editor is perfectly ok with me doing?

 

Context and some frustration venting:

  Hide contents

 

Yes, I am one of those people that sometimes purposely uses mirror symmetry in the VAB and radial symmetry in the SPH, and sometimes, yes, gasp, I even do mix both symmetries in the same craft. In some designs it is the only way to get parts placed in the correct manner. I have already grudgingly accepted the kraken-enforced limitation that I cannot mix symmetries on the same single part, but at least stock will accept without question when I tell it to use mirror for another set of parts when the rest of the craft so far has used radial... or the other way around.

EEX, as much as I love the utility of it otherwise, will simply and unbudgingly REFUSE sometimes to change symmetry modes, and at hitting 'R' automatically and immediately changes my chosen symmetry mode back to what it feels it should be. I'm sure it's trying to tell me something with that, but I simply do. not. care, I hit 'R' on purpose, and it just makes me quit the game and uninstall EEX, because in stock, I CAN use the symmetry mode I want, and it works, and the craft works. So whatever handholding EEX is trying to do with this symmetry-enforcing behaviour is completely lost on me, and after two or three times of encountering this, EEX just ends up permanently uninstalled again despite its other useful functions.

So please, allow me some way of stopping EEX interfering with my chosen symmetry mode.

 

 

Could you raise this in aGithib issue, please. I'm in the middle of finishing up another mod, am also away for avfew days, and don't wan v o lose this.

Thanks

[Majorjim!]

This seems to work fine in 1.1.3.

[selfish_meme]

6 hours ago, Majorjim said:

This seems to work fine in 1.1.3.

Really I am pretty sure it disabled itself for me because its an incompatible version?

Though if you edit the .version to add 1.1.3 as the max version it should load, but it does not for me.

Edited June 23, 2016 by selfish_meme

[G'th]

PRobably beating Linux to the punch here but he did update for 1.1.3. IS on Spacedock.

[Majorjim!]

6 hours ago, selfish_meme said:

Really I am pretty sure it disabled itself for me because its an incompatible version?

Though if you edit the .version to add 1.1.3 as the max version it should load, but it does not for me.

Well I updated the game, loaded it and I am in the editor using all the tools. No offset limit, surface attach, symmetry. They all work and those are the only parts I use.

[linuxgurugamer]

8 hours ago, selfish_meme said:

Really I am pretty sure it disabled itself for me because its an incompatible version?

Though if you edit the .version to add 1.1.3 as the max version it should load, but it does not for me.

You know, there IS a reason I put in code to prevent it from running on incompatible versions.  The .version file is used by AVC, but the code in the mod uses the compiled-in version.

And yes, I did get it updated for 1.1.3.  Nothing new, just updated fro compatibility.

Edited June 23, 2016 by linuxgurugamer

[Majorjim!]

23 minutes ago, linuxgurugamer said:

You know, there IS a reason I put in code to prevent it from running on incompatible versions.  The .version file is used by AVC, but the code in the mod uses the compiled-in version.

And yes, I did get it updated for 1.1.3.  Nothing new, just updated fro compatibility.

It works for me out of the box for 1.1.3. What gives?

[linuxgurugamer]

Just now, Majorjim said:

It works for me out of the box for 1.1.3. What gives?

Probably you installed/updated it after I got it updated on Spacedock/github

 

[Majorjim!]

Just now, linuxgurugamer said:

Probably you installed/updated it after I got it updated on Spacedock/github

 

I have been using it for at least three months. When did you update it on spacedock/github?

[linuxgurugamer]

either yesterday or the day before.  Are you using CKAN?