Jump to content

[1.2.x] Part Angle Display - including seamless, highly accurate rotation v0.3.2.4


Padishar

Recommended Posts

Part Angle Display 0.3.2.4

This is a simple KSP plugin that allows you to surface attach parts at accurate angles. The latest version is built against the 1.2.2 release assemblies and should work with any 1.2.x version but is unlikely to work in any older version. For compatibility with older versions of KSP, please see the older versions available on the Curse download page or from DropBox below.

Simply put, the plugin allows you to display a small window in the VAB/SPH that displays the orientation of the currently selected part as pitch, roll and yaw angles and it also allows you to enter increment values for the pitch, roll and yaw and to apply these to the selected part.

9ylEWvW.jpg

It originally used a single hotkey of Mod-P (Mod being KSP's configured "modifier" key which defaults to Alt on Windows and RightShift on Linux) as it doesn't clash with any of the mods I use. If you don't have a part selected then it will show or hide the window. If you do have a part selected then it will apply the angle increments to the part by simply adding the increment values to the displayed Euler angles and re-setting the rotation of the selected part. This has strange effects caused by the way that Euler angles work.

Version 0.2 introduced a new way use the plugin. The original Alt-P hotkey still works the same way but it also now overrides the handling of Mod-WASDQE in the stock game (the standard part rotation controls with the configured modifier key held down do the same as the unmodified key, rotate by 90 degrees) to instead rotate by whatever angle increment is entered into the respective field in the dialog. This allows you to set increment values to 1 (or 0.1 or even 0.01) and then have seamless, accurate rotation of parts.

Version 0.2.1 fixed the handling of the standard pitch keys and makes the angle increments they use configurable. W/S and Shift-W/S no longer go in opposite directions. The < and > buttons can be used to cycle the angle setting through 120, 90, 72, 60, 45, 30, 15, 10, 5, 1, 0.1 and 0.01 degrees. The F key also adjusts the "Fine" angle control (F to cycle down, Shift-F to cycle up and Mod-F to reset to 5).

Version 0.2.2 introduced "Part-relative" mode. This changes the rotation keys to act around the axes of the currently selected part rather than the usual fixed axes. E.g. if you rotate a Mk 1 plane cockpit to an odd angle and then switch to "Part-relative" and roll using Q and E the part will roll around its own axis.

Version 0.2.4.2 added the saving and loading of settings (window position, visibility and all the control settings).

Version 0.2.4.3 made the keyboard shortcuts configurable in the settings file. To change the shortcuts you will need to run the game and enter and exit the VAB/SPH once for the default settings file to be written out (in GameData\PartAngleDisplay\PluginData\PartAngleDisplay\settings.cfg). Then simply edit this file (you shouldn't even need to quit KSP) and change the three lines starting "key" to be the keycodes you desire. Note that the "toggle window" and "apply Euler" operations always use the configured modifier key and the "cycle fine" operation uses plain, shifted and modified keypresses.

Version 0.2.4.4 added support for both the stock and Blizzy's toolbars. The use of the stock toolbar can be disabled in the settings file (useAppLaunch).

Version 0.3.0.0 for KSP 0.90 has had to change quite a few things. The key to cycle the fine angle increment now defaults to G because the stock editor uses F. The normal angle increment can be cycled using B. The modifier key for the WASDQE keys to use the separate axis increment values now defaults to Ctrl as Mod is used to disable surface attachment which would make it impossible to adjust surface attached parts in place.

Version 0.3.0.1 for KSP 1.0.2 is simply a recompile for the new version and a minor bug fix.

Version 0.3.1.0 for KSP 1.1 has been significantly refactored to simplify it and fix the part relative rotation that has been broken since the editor changes in KSP 0.90.

Version 0.3.1.1 for KSP 1.1 enables the part rotation keys when the dialog is closed making it usable without ever opening the UI.

Version 0.3.2.0 for KSP 1.2 is a straight recompile.

Version 0.3.2.1 for KSP 1.2 now stores the key bindings as strings rather than integer values.

Version 0.3.2.2 for KSP 1.2 fixes the loss of the toolbar button with Contract Configurator.

Version 0.3.2.3 for KSP 1.2.x optimises the GUI code to reduce garbage creation.

Version 0.3.2.4 for KSP 1.2.x is built against KSP 1.2.2 and fixes the .version file.

Download from CurseForge

Download from DropBox

Older versions from DropBox:

The source is available on GitHub and is released under the MIT license (see main source file).

13/12/2016 07:16 GMT   Fixed .version file.
Built against KSP 1.2.2.1622
Updated to version 0.3.2.4

25/11/2016 23:58 GMT   Optimised GUI code to reduce garbage creation
Updated to version 0.3.2.3

25/10/2016 17:14 GMT   Updated to latest version of ToolbarWrapper.cs
Updated to version 0.3.2.2

30/09/2016 09:41 GMT   Changed key binding settings to use textual KeyCode names
Updated to version 0.3.2.1

15/09/2016 12:33 GMT   Rebuilt for KSP 1.2
Updated to version 0.3.2.0

30/03/2016 19:08 GMT   Enabled rotation controls when dialog is closed
More garbage reduction
Updated to version 0.3.1.1

09/03/2016 16:32 GMT   Updated for KSP 1.1
Refactored rotation application to fix part relative rotation
Updated to version 0.3.1.0

16/12/2014 14:38 GMT Updated for KSP 0.90
Changed fine increment cycling key to G (configurable)
Added normal increment cycling key of B (configurable)
Changed Mod-WASDQE to Ctrl-WASDQE (configurable)

12/08/2014 19:50 GMT Fixed yaw and roll controls when editor mode is changed using Editor Extensions
Updated to version 0.2.4.5

04/08/2014 19:50 GMT Now supports both the stock and Blizzy's toolbars
Use of stock toolbar can be disabled in settings (useAppLaunch)
Updated to version 0.2.4.4

01/08/2014 11:57 GMT Now allows the keyboard shortcuts to be configured in the settings file
Updated to version 0.2.4.3

26/07/2014 17:33 GMT Compiled against KSP 0.24.2
Added loading and saving of settings (window position, visibility and all the control settings)
Updated to version 0.2.4.2

25/07/2014 08:43 GMT Compiled against KSP 0.24.1
Updated version to 0.2.4.1

23/07/2014 22:50 GMT Fixed build to target correct .NET runtime
Updated to version 0.2.4.0

17/07/2014 22:27 GMT Swapped roll and yaw displays in SPH
Compiled against KSP 0.24
Updated version to 0.2.3.0

13/07/2014 16:37 GMT Implemented "Part-relative" mode that changes all part rotation axes to be relative to the selected part
Updated version to 0.2.2.0

13/07/2014 12:29 GMT Now totally overrides part rotation hotkeys
Allows changing of the default and fine rotation increments
Updated version to 0.2.1.0

10/07/2014 21:52 GMT Now uses configured key bindings for part rotation rather than hardwired WASDQE
Updated version to 0.2.0.2

10/07/2014 20:53 GMT Fixed roll and yaw rotation axes in SPH
Updated version to 0.2.0.1
Fixed version in title bar

10/07/2014 12:12 GMT Added handling of Mod-WASDQE to rotate by the entered amounts in the respective axes
Updated version to 0.2.0.0

28/05/2014 09:48 GMT Added buttons to zero the increment fields
Rearranged window to avoid things moving when entering values
First release version 0.1.0.1

23/05/2014 14:06 GMT Fixed editable fields to work better

20/05/2014 23:17 GMT Removed some unused code and logging

20/05/2014 15:52 GMT First release

 

 

Edited by Padishar
Link to comment
Share on other sites

Great, but why not use the toolbar API?

Well, a key shortcut is required to apply the angle increments while a part is selected and also, I couldn't be bothered to create two icons and write the necessary code for something that was originally just for my use. I may get around to it at some point, or anyone else is free to submit a pull request on GitHub (or, given the license, to fork it, implement anything they like and release it themselves).

Link to comment
Share on other sites

  • 1 month later...

I have tried it and i may have misunderstood how to use it properly : i have a part that i attached at angled surface. As expected, attaching it caused part to change to new angle. Then i wanted it to re-align it again in relation to editor space (and cockpit/root part) to make it "straight". When i activated GUI to display angle, it showed the angle relative to attachment point, but i was hoping it would show absolute angle (relative to editor orientation).

If this is not yet implemented, i ask if it can be added (editor or "absolute" angles with usual relative-to-attachment node ones). I don't know how ships structures in editor look from programmer's point of view, it may be needed to "trace" through several parent parts to calculate "absolute" angle.

Also a GUI improvement suggestions.

Workflow type 1 (numerical feeback) :

1. activate plugin GUI via Toolbar

2. click "target part" button (maybe use same alt-p to both open GUI and activate part selection mode)

3. select target part

4. use commands and watch for angle changes

Workflow type 2 (numberless visual feedback):

1. activate plugin GUI vi Toolbar

2. click "target part" button (maybe use same alt-p to both open GUI and activate part selection mode)

3. click on desired part

4. targeted part now shows alignement vectors in editor

5. click angle buttons to change angles

6. each angle change is followed by new vector guides being moved, when an angle vector guide is aligned to some predefined angles (like 30, 45 or 60 degrees) it turns brighter

Both workflows assume part can be optionally manipulated while still attached to ship.

Also, it would be nice to have "zero" buttons for both relative and absolute angles. I admit, this would make more sense for absolute angles as it would align part to nominal orientations instantly. Absolute angles do assume target part is manipulated while still attached to ship, otherwise they are meaningless.

NOTE : Look for vector guides examples at landing gears in firespitter pack.

Edited by fatcargo
typos
Link to comment
Share on other sites

I agree that an absolute angle display could be useful in various situations but it involves considerably more code to work them out. I may get around to looking at this at some point but it isn't high on my list of priorities as I'm currently busy planning another mod and I expect that 0.24 will require some fairly urgent fixes to the simulation code in KER so it probably wont be for a while.

As for the other suggestions of changes to the workflow, any changes to how the part selection works is likely to be too complex and it isn't very clear what you mean. For example, what does "use commands and watch for angle changes" mean? The RealFuels mod requires part selection for configuring tanks and engines and that uses the action groups editor to handle the part selection side. The partRotation member of the EditorLogic code only works when in "Parts" mode and a part is picked up so that all the usual handling of part placement is still done by the core game code. Affecting the parts directly while still attached is probably possible but it is certainly significantly more complex and may require all sorts of checking to prevent the user making changes that the game would usually prevent.

Link to comment
Share on other sites

I agree that an absolute angle display could be useful in various situations but it involves considerably more code to work them out. I may get around to looking at this at some point but it isn't high on my list of priorities as I'm currently busy planning another mod and I expect that 0.24 will require some fairly urgent fixes to the simulation code in KER so it probably wont be for a while.

Understood.

As for the other suggestions of changes to the workflow, any changes to how the part selection works is likely to be too complex and it isn't very clear what you mean. For example, what does "use commands and watch for angle changes" mean? The RealFuels mod requires part selection for configuring tanks and engines and that uses the action groups editor to handle the part selection side. The partRotation member of the EditorLogic code only works when in "Parts" mode and a part is picked up so that all the usual handling of part placement is still done by the core game code. Affecting the parts directly while still attached is probably possible but it is certainly significantly more complex and may require all sorts of checking to prevent the user making changes that the game would usually prevent.

Well, you pretty much described the core of the problem. To try reiterating : the suggested workflow is that user activates plugin GUI (the window with numbers and few buttons), then clicks the target part, now plugin is in "target" mode, and all operations from there on are applied to target part. Any click on next part, any selections in part tabs, action groups, pretty anything other than going straight to editing angles CANCELS target mode.

This will most likely be frustrating, but it ensures that plugin does not further block any user input. Or it could be (via GUI) set to some kind of "lock" mode (to keep plugin in "target" mode) but that is a risk that user should be warned about a taking it on their own responsibility.

Yes, the action group mode does just the above, but i somehow do not see it used for part geometry editing. When i first used Modular Fuel Tanks i was a bit uneasy going to action group editor. Now it has it's own resource editing GUI accessible via right-click menu. HEEEYYY !!! What if you can use same right click menu item to show GUI, or have all buttons and angle numerical feedback labels right there INSIDE menu ! That way you maintain "targeted" mode of part. Now that i remember, Modular Fuel Tanks, Tweak Scale, Tweakable Everything and others do just that !

Also, Procedural Parts (previously StretchySRB) uses multiple keyboard shortcuts to handle it's own commands while mouse is hovered over a stretch-enabled part (but that will use up available keyboard shortcuts, read below for more).

[Oh boy there is more ... :confused: ] Plugin authors should really try to work out some common mouse/keyboard input capturing API (can KSPAPIExtensions.dll do this ? Or at least can it be updated to cover this ?), unused keys will be quickly exhausted with ever growing number of "must have" partless plugins / plugin-driven part packs. Maybe each plugin could "take turns" in capturing mouse/keyboard input if exclusive access is needed, also common API should register all capture keys, report any overlaps and offer user with choice to remap keys. Those remapped keys are then returned to all plugins to "listen". Maybe plugins could register in that API keyboard hook functions formatted as "PluginName.UserFunction" strings that are then mapped to keys requested by plugin(but possibly remapped). Also API should have a Blizzy Toolbar integration for mouse-controlled layout switching that could group keys, avoiding input collisions when two plugins need same shortcut keys in same conditions (those shortcuts would reside in different layouts).

Link to comment
Share on other sites

I'm not certain (not having done very much with UI stuff) but I believe that to put something on the right-click tweakable requires a PartModule to be added to all the relevant parts. If this is the case then I suspect that doing so for this mod would be undesirable as adding an additional PartModule to every part even though it will not be used for most parts will use more memory and cause more processing overhead for no good reason.

At the moment, this plugin is incredibly simple, mainly because of the way it uses the "selected part" facilities provided by the core editor API. There are only 2 really significant lines of code and it allowed me to do everything I originally wanted it to (and quite a few other things since) so I have no real desire to do anything that will basically change it beyond all recognition.

Some of this post (and the discussion it is likely to generate) should probably go in the Add-on Requests and Support forum rather than this thread as it is likely to be seen by more interested people. Personally, I would rather see an "operation registration" API in the core game code so that it could easily integrate with the existing keyboard configuration.

Link to comment
Share on other sites

Agreed. I believe you that making any of the suggested workflow changes will need complex code. Simplicity is often best, i just hope this may not be too troublesome some day in future to include it.

As for keyboard stuff, i'll post in relevant topic (thanks for the posting suggestion).

Link to comment
Share on other sites

While we're spitballing UI: have you considered applying the appropiate YPR field whenever ALT+(direction key) is pressed? That way you could leave PAD always set for 0.1 degree in each field, and then seamlessly 5-degree-rotate a part with Shift+WASDQE and then 0.1-degree-rotate a part with ALT+WASDQE?

Link to comment
Share on other sites

While we're spitballing UI: have you considered applying the appropiate YPR field whenever ALT+(direction key) is pressed? That way you could leave PAD always set for 0.1 degree in each field, and then seamlessly 5-degree-rotate a part with Shift+WASDQE and then 0.1-degree-rotate a part with ALT+WASDQE?

I did think about that but, while testing, I noticed the general problem with how Euler angles wrap around (just keep hitting W with the PAD window open and see what happens to the numbers, or better, set the pitch to something odd like 21deg and hit alt-p a few times). Basically, when you go past various 90 degree multiples the way the heading is represented suddenly changes from using 0 deg roll to using 180 deg roll and the pitch goes down again. This could be handled "correctly" by changing how the angle increments are applied (currently, it simply adds the angle increments to the Euler angle version of the current part rotation and it would need to do something more involved, building a new quaternion to describe the desired incremental rotation and combining it more sensibly with the current rotation) but I was happy with how well it was working for such simple code. I may revisit it once I'm a bit less busy...

Link to comment
Share on other sites

Um, couldn't you just, on each press, apply an AngleAxis quaternion around the part's local (X/Y/Z) axis in the specified amount?

Obviously that will not change the Y/P/R values consistently, but it would allow simple per-keypress rotation without gimbal locking.

Link to comment
Share on other sites

Um, couldn't you just, on each press, apply an AngleAxis quaternion around the part's local (X/Y/Z) axis in the specified amount?

Obviously that will not change the Y/P/R values consistently, but it would allow simple per-keypress rotation without gimbal locking.

Link to comment
Share on other sites

I did think about that but, while testing, I noticed the general problem with how Euler angles wrap around (just keep hitting W with the PAD window open and see what happens to the numbers, or better, set the pitch to something odd like 21deg and hit alt-p a few times). Basically, when you go past various 90 degree multiples the way the heading is represented suddenly changes from using 0 deg roll to using 180 deg roll and the pitch goes down again. This could be handled "correctly" by changing how the angle increments are applied (currently, it simply adds the angle increments to the Euler angle version of the current part rotation and it would need to do something more involved, building a new quaternion to describe the desired incremental rotation and combining it more sensibly with the current rotation) but I was happy with how well it was working for such simple code. I may revisit it once I'm a bit less busy...

It turned out to be a bit easier than I expected except for the fact that the core game already rotates the part by 90 degrees when using Alt-WASDQE so I have to undo that first. This will not (currently) work properly if you have changed the keyboard mapping for the part rotation (if this is possible). If it is possible then I'll look at reading the actual key bindings so it always uses the same ones as the 5 and 90 degree rotations. I have also not tested it in the SPH so the axes for the rotations might need switching around. I'll test this later and fix it if necessary.

Edited by Padishar
Typo, VAB is tested, SPH is not
Link to comment
Share on other sites

You definitely can query bindings rather than keys. I forget offhand how (via GameSettings IIRC?) though.

And yeah what I wrote was because I *didn't* see it as involved: you just do orientation *= Quaternion.AngleAxis(part.transform.(appropriateVector), degrees). Bang.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...