[1.8.1] Docking Port Alignment Indicator (Version 6.8.5 - Updated 12/14/19)

[nukeboyt]

Hi NavyFish:

I'm not able to rename the docking ports. I can cycle through them on RPM fine, but they only show the names that RPM calls each port. "DOCKINGPORT3 (front)": "DOCKINGPORT3 (left) and so on).

I'm running Linux. Tried renaming from IVA and from normal view.

I think that the feature that uses the RPM docking camera in conjunction with the target port HUD icon is great. Good idea! I was wondering if we were going to be able to see the HUD icon through the walls of the capsule (like you can see the target ship). I love being able to see which direction (on screen) the target port is.

Edited February 2, 2015 by nukeboyt

[NavyFish]

Oh, wow... You solved the IVA navball reference issue?

Looks like RPM is going on the download list, too.

This looks amazing, Navy. I may attempt my first IVA docking.

Somewhere between KSP 0.20 and .90, Squad exposed the ability to change the reference part through code. I noticed this when browsing RPM's code, and simply piggy-backed onto their implementation. Good luck with your first IVA attempt!

Hi NavyFish:

I'm not able to rename the docking ports. I can cycle through them on RPM fine, but they only show the names that RPM calls each port. "DOCKINGPORT3 (front)": "DOCKINGPORT3 (left) and so on).

I'm running Linux. Tried renaming from IVA and from normal view.

I think that the feature that uses the RPM docking camera in conjunction with the target port HUD icon is great. Good idea! I was wondering if we were going to be able to see the HUD icon through the walls of the capsule (like you can see the target ship). I love being able to see which direction (on screen) the target port is.

RPM will not pick-up on the name changes, as it does not recognize the "ModuleDockingNodeNamed" module I created for use with DPAI. The DPAI indicator should show the custom names for the target and reference port, however. Is that working for you?

[nukeboyt]

RPM will not pick-up on the name changes, as it does not recognize the "ModuleDockingNodeNamed" module I created for use with DPAI. The DPAI indicator should show the custom names for the target and reference port, however. Is that working for you?

I am not even able to rename the ports. When I right-click on a port, clicking the "Rename Port" button does nothing at all. Isn't a box supposed to open where a new name can be typed in?"

Edited February 2, 2015 by nukeboyt

[NavyFish]

I am not even able to rename the ports. When I right-click on a port, clicking the "Rename Port" button does nothing at all. Isn't a box supposed to open where a new name can be typed in?"

Yes, a separate box is supposed to open. When you installed the new version, did you delete the existing NavyFish directory, or just overwrite it? If you did not delete the existing directory, there will be bugs without a doubt.

[nukeboyt]

Yes, a separate box is supposed to open. When you installed the new version, did you delete the existing NavyFish directory, or just overwrite it? If you did not delete the existing directory, there will be bugs without a doubt.

No, I did a clean install. DPAI & RPM are the only mods. I was using Linux. I'll try Windows after work.

[MOARdV]

I haven't had a chance to dock using the 6.0 beta yet, but I have installed it and started a game. One thing I see in KSP.log is a lot of null reference exceptions during loading - one after each docking port is processed by the PartLoader, eg:

[LOG 08:40:08.806] PartLoader: Compiling Part 'Squad/Parts/Utility/dockingPortShielded/dockingPortShielded/dockingPort1'
[EXC 08:40:08.817] NullReferenceException: Object reference not set to an instance of an object
	RenderingManager.AddToPostDrawQueue (Int32 queueSpot, .Callback drawFunction)
	DockingPortAlignment.RenameWindow..ctor ()
	DockingPortAlignment.ModuleDockingNodeNamed.OnAwake ()
	PartModule.Awake ()
	UnityEngine.GameObject:AddComponent(Type)
	Part:AddModule(String)
	Part:AddModule(ConfigNode)
	PartLoader:ParsePart(UrlConfig, ConfigNode)
	:MoveNext()
[EXC 08:40:08.826] NullReferenceException: Object reference not set to an instance of an object
	RenderingManager.AddToPostDrawQueue (Int32 queueSpot, .Callback drawFunction)
	DockingPortAlignment.RenameWindow..ctor ()
	DockingPortAlignment.ModuleDockingNodeNamed.OnAwake ()
	PartModule.Awake ()
	UnityEngine.Object:Instantiate(Object)
	PartLoader:CreatePartIcon(GameObject, Single&)
	PartLoader:ParsePart(UrlConfig, ConfigNode)
	:MoveNext()

It doesn't occur during flight, but I don't know if I've loaded any craft that have docking ports yet.

[NavyFish]

Awesome, thank you for the log. Nukeboyt, if you could also provide your log (from ksp start to scene load) that would be helpful.

I think I know what's causing that, though I won't be able to check until I return home from work. The partmodule isn't using a singleton "RenameWindow", and it's attempting to add to the render queue prior to that being set-up. Strange that I did not have the same issue, but its possible I did and just missed the logs.

Edited February 2, 2015 by NavyFish

[Dave7]

Other than the null reference exceptions noted above by MOARdV everything seems to be working fine for me. IVA has never been more fun. Now I need to get it working with the Alcore pod. Here's an idea I had by the way, instead of the black background have you thought about using the rasterprop docking port camera view?

[Redchrome]

One thing I've seen several times, and found quite frustrating, is that sometimes when switching ships while docking the DPAI will 'forget' which target it's supposed to be referencing. I'll be trying to approach the Recycle Bin for instance, but then I switch away to the space station the Recycle Bin is docked to in order to make sure the bin is activated, and when I switch back to the ship I'm trying to fly into the Recycle Bin I find that the DPAI is now targeting some other docking port.

If I don't notice this soon enough, I start wondering "why is my distance to the target different all of a sudden?" and start lining up again until I realize what's going on.

I haven't paid enough attention to notice whether it tends to take compatible docking ports or not. I'm typically doing this on my space station which probably has 20 ports or more, of all 3 sizes.

Also, there's no really clear documentation readily findable which explains all the symbols. I still don't know what the red crosshairs mean. I guess it means I'm on the 'back side' of the port I'm targeting.

I would guess that the green crosshairs are like some kind of virtual 'rays' emanating from the targeted port (i.e. when you're in line with the port, the green lines are centered), but when I'm way off to one side of the port (CDST low, DST high) I would expect at least one of the crosshairs to be up against the side of the indicator window, but I don't think that always happens.

The tool seems to be really good when one is within a certain angle relative to the axis of the targeted docking port, but I'm still confused about what it's telling me when I'm way off to one side of the port.

If possible it would be really cool if there were some kind of indicator showing which way your thrusters are pointing. This really affects thrusting efficiency, and some (crappy) designs of ships don't even have RCS ports for all directions. If you're flying 5-ton capsules around this isn't so noticeable, but when trying to dock 80-ton tankers you need all the help you can get.

It would be nice if there was a readout for velocity relative to the DST indicator. Comparing that to the CDST value would give some idea how fast one is moving laterally.

Thanks for your patience, for reading this, and for a great tool. I put some money in your tip account.

[WuphonsReach]

One thing I've seen several times, and found quite frustrating, is that sometimes when switching ships while docking the DPAI will 'forget' which target it's supposed to be referencing. I'll be trying to approach the Recycle Bin for instance, but then I switch away to the space station the Recycle Bin is docked to in order to make sure the bin is activated, and when I switch back to the ship I'm trying to fly into the Recycle Bin I find that the DPAI is now targeting some other docking port.

How fast are you switching back and forth? I find that things get wonky unless I rest for 5-10 seconds before switching away from the new vessel.

[NavyFish]

Other than the null reference exceptions noted above by MOARdV everything seems to be working fine for me. IVA has never been more fun. Now I need to get it working with the Alcore pod. Here's an idea I had by the way, instead of the black background have you thought about using the rasterprop docking port camera view?

I'll end up making some more config files for MFDs other than the one that comes with RPM, but want to get this release patched up and out the door before doing so. If you end up writing a config file for Alcore, please let me know

One thing I've seen several times, and found quite frustrating, is that sometimes when switching ships while docking the DPAI will 'forget' which target it's supposed to be referencing. I'll be trying to approach the Recycle Bin for instance, but then I switch away to the space station the Recycle Bin is docked to in order to make sure the bin is activated, and when I switch back to the ship I'm trying to fly into the Recycle Bin I find that the DPAI is now targeting some other docking port.

Interesting, I hadn't considered this. There is no functionality for DPAI to 'remember' what it was targeting. And, there is only ever one instance of the DPAI, not actually one per ship. I'll consider storing this info per-ship, although the less I have to touch the persistence file, the better.

I haven't paid enough attention to notice whether it tends to take compatible docking ports or not. I'm typically doing this on my space station which probably has 20 ports or more, of all 3 sizes.

It does not, although this is a planned feature.

It would be nice if there was a readout for velocity relative to the DST indicator. Comparing that to the CDST value would give some idea how fast one is moving laterally.

Another planned feature, coming soon actually. Translational distance (and possibly velocity) readouts.

If possible it would be really cool if there were some kind of indicator showing which way your thrusters are pointing. This really affects thrusting efficiency, and some (crappy) designs of ships don't even have RCS ports for all directions. If you're flying 5-ton capsules around this isn't so noticeable, but when trying to dock 80-ton tankers you need all the help you can get.

Not sure what you're trying to describe there. Are you talking about which RCS thrusters will fire when you press 'forward', for example (as this would change based upon your "Control From Here" selection)? How would you display this?

Also, there's no really clear documentation readily findable which explains all the symbols. I still don't know what the red crosshairs mean. I guess it means I'm on the 'back side' of the port I'm targeting.

You are correct (on both points ). Red means you're on the back side of the target port.

I would guess that the green crosshairs are like some kind of virtual 'rays' emanating from the targeted port (i.e. when you're in line with the port, the green lines are centered), but when I'm way off to one side of the port (CDST low, DST high) I would expect at least one of the crosshairs to be up against the side of the indicator window, but I don't think that always happens. The tool seems to be really good when one is within a certain angle relative to the axis of the targeted docking port, but I'm still confused about what it's telling me when I'm way off to one side of the port.

Correct, the green lines are CDIs (Course Deviation Indicators) which indicate angular deviation off of centerline (defined as an imaginary line pointing outward from the center of the target docking port). So a centered vertical line means you're neither left or right of centerline. A half-window deflection to the left means you're at 45 degrees 'right' of centerline. So if you were to maintain your translational error but decrease CDST, the line would deflect further away from centerline (as your angle from centerline would increase). Full deflection (green line pegged all the way to one side) indicates you're at 90 degrees off centerline, and will only happen just before you enter the red crosshair (back hemisphere) region. I think this will all become a little clearer when I add translational distance readouts.

Thanks for your patience, for reading this, and for a great tool. I put some money in your tip account.

Thank you for your generosity, and for taking the time to write up your thoughts. I hope my response has been helpful.

-------------------------------

RC3 (RC2 went to a couple of folks, but didn't warrant 'public testing') will be out shortly. Nukeboyt and MOARdv in particular have been very helpful tracking down a couple of bugs. Thanks Dave7, WuphonsReach, and everyone else for helping me test this.

Edited February 3, 2015 by NavyFish

[NavyFish]

RC3 is out: git 'er dun

[diomedea]

Testing DPAI 6 RC3. Have a number of DivideByZeroExceptions raised in the log, e.g.

DivideByZeroException: Division by zero

at DockingPortAlignment.DockingPortAlignment.cyclePortRight () [0x00000] in <filename unknown>:0

at DockingPortAlignment.DockingPortAlignment.drawIndicatorContents (Int32 windowID) [0x00000] in <filename unknown>:0

at UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) [0x00000] in <filename unknown>:0

However, not found (yet) any missing or misbehaving functionality with DPAI.

Doing dockings while in IVA (with RPM + DPAI) is very immersive .

[Redchrome]

Interesting, I hadn't considered this. There is no functionality for DPAI to 'remember' what it was targeting. And, there is only ever one instance of the DPAI, not actually one per ship. I'll consider storing this info per-ship, although the less I have to touch the persistence file, the better.

When docking two craft in orbit, I will often switch between them and target them at each others' docking ports. With a space station this isn't really meaningful, but with smaller craft it can help.

I don't know how you store information, but couldn't you have a file (separate from the persistence.sfs) that says "this section is for this ship, which is using this object as the control reference point and is targeted at that reference point or object"? I.e. just use tags in your separate data file which reference objects in persistence.sfs?

It does not, although this is a planned feature.

That would be sensible and cool. Your logic could go something like "the object used as the control reference point is a Clamp-O-Tron Sr. port, so we should first look for other Clamp-O-Tron Sr. ports to dock to; then Recycle Bins; then other varieties of ports". I can conceive of wanting to target an incompatible docking port, just to use it as a reference point. (I doubt this will happen often, but one should account for this corner case).

Another planned feature, coming soon actually. Translational distance (and possibly velocity) readouts.

Yay!

Not sure what you're trying to describe there. Are you talking about which RCS thrusters will fire when you press 'forward', for example (as this would change based upon your "Control From Here" selection)? How would you display this?

I'll have to mock something up to be clear, but what I mean is that the display could show which direction (up, down, left, right) RCS thrusters are actually firing.

Say for instance you have a ship which only has thrusters pointing 'up'. One could conceivably still dock such a ship by rotating it around its axis so the thrusters point in whichever direction one wished to translate away from. However, without knowing exactly which way the thrusters are pointing, it's difficult to judge exactly how far to rotate the ship.

The more common use case of this is when you have a relatively heavy ship with relatively weak thrusters. You push the keys to fire the translation thrusters, but there's no apparent movement, possibly not for some time. Why not? Did you forget to turn on RCS? Did you forget to take yourself all the way out of timewarp? Do you have a pair of thrusters firing 45-degrees away from the direction you wish they were instead of one thruster firing exactly the direction you want, such that the efficiency is reduced? Are you pushing the wrong button? Do you just not have working thrusters in that direction? Or is your ship just so heavy it takes a long time to get any indication of response, especially if you're very far off the axis of the port? Some sort of immediate visual feedback saying that 'yes, the thrusters are firing and in the direction I want' would be really helpful at times.

Correct, the green lines are CDIs (Course Deviation Indicators)

This sounds familiar from my student pilot days, but I never got far enough to have to worry about doodads like that.

which indicate angular deviation off of centerline (defined as an imaginary line pointing outward from the center of the target docking port). So a centered vertical line means you're neither left or right of centerline. A half-window deflection to the left means you're at 45 degrees 'right' of centerline. So if you were to maintain your translational error but decrease CDST, the line would deflect further away from centerline (as your angle from centerline would increase). Full deflection (green line pegged all the way to one side) indicates you're at 90 degrees off centerline, and will only happen just before you enter the red crosshair (back hemisphere) region. I think this will all become a little clearer when I add translational distance readouts.

Ah! Thank you! That all makes much more sense now.

Thank you for your generosity, and for taking the time to write up your thoughts. I hope my response has been helpful.

Your response has been very helpful! Thank you again!

[NavyFish]

RC4 is out

(Fixes divide by zero bug found by diomedea)

Thank you everyone for the continued testing! 3 bugs down, and we're that much closer to release.

[nukeboyt]

Here's a sneak peak for what's coming in Version 6.0. This is RPM & DPAI integration! Notice how in the 2nd picture, the Target Port HUD is on the left side of the camera screen. If the target port is off-screen, the HUD shows you which direction it is. This is very useful. The problems I was having earlier with not being able to rename docking ports has been fixed in RC4

I absolutely LOVE THIS MOD

Javascript is disabled. View full album

Edited February 4, 2015 by nukeboyt

[Redchrome]

Here's some mockups of an idea I had about indicating the direction of translation thrust. The line of dots is sort of reminiscent of rocket exhaust. My idea is that the dots would appear when the thruster was activated, but otherwise be absent.

Suggestions, and correction of any misunderstandings or misstatements is welcome.

Here's the simple case. One thruster pushing the velocity vector roughly in the direction of where the CDI lines cross.

Here's two thrusters in parallel doing the same thing.

The following image indicates that there are two thrusters at a 90 degree angle to each other, but the sum of their vectors points roughly towards where the CDI lines cross.

I don't know how the RCS thrusters work internally to the game engine, but here would be a way to represent one thruster applying a lot of force, and one thruster applying a little.

[NavyFish]

Great pictures, nukeboyt. And thank you again for your generosity.

@RedChrome - I think I see what you're talking about. It could be a neat feature, although the code to make it work seems daunting. I'll put it on the list of things to explore, though, as some things are easier than they first appear. Thanks for the mock-ups!

[Alshain]

You should be able to tell what direction your thrust is going by the way the prograde moves. Not to mention the keys you are pressing. DPAI's screen orientation is static (regardless of craft rotation) so if you press J on the keyboard, thrust will always be right (opposite the direction you want to go). I hate to squash ideas but I feel like the thrust indicators would be redundant clutter.

[taniwha]

Alshain: It's not so easy to tell when you need to lean on the thruster to make the indicator move even a little (big ship, small thrusters).

[ap0r]

I originally had that problem back when i started using DPAI! I solved it this way very crude but it worked! Once i got used to it, it became instinctive and i returned to using the normal background texture.

In fact, an alternative "tutorial mode" texture would probably be helpful for those who don't like to read manuals and want to figure out things on their own.

[Redchrome]

Alshain: It's not so easy to tell when you need to lean on the thruster to make the indicator move even a little (big ship, small thrusters).

Exactly.

Or if you're way off-axis and the indicator doesn't appear to move when you push the keys.

Or you screwed up and you're not actually thrusting in the direction you mean to, but you don't have an indicator of this.

I know the code may not be trivial, but it's just a suggestion. Even a limited implementation indicating "yes, the velocity vector is moving, and in this direction" would be helpful at times.

Here's a mockup of an indicator showing the velocity vector moving downward.

Of course the problem is that as one gets closer to the target and (hopefully) the CDI lines are near the center, things get increasingly crowded there and the movement indicator isn't as helpful because movement will be much more apparent than it would be when one is way off-centerline. Some suggestions I have would be to make the movement indicator larger/brighter when:

* thrusting longer

* farther off-centerline

* there is less apparent movement

I do not know which of these would be the best tho. It would probably be confusing to implement more than one, but I could be wrong. Some play testing would be necessary.

[Alshain]

Alshain: It's not so easy to tell when you need to lean on the thruster to make the indicator move even a little (big ship, small thrusters).

Hmm, fair enough. I retract my earlier objection.

[Redchrome]

I originally had that problem back when i started using DPAI! I solved it this way very crude but it worked! Once i got used to it, it became instinctive and i returned to using the normal background texture.

In fact, an alternative "tutorial mode" texture would probably be helpful for those who don't like to read manuals and want to figure out things on their own.

http://s14.postimg.org/ju9zo35wx/crude_but_effective_solution.png

That's a great idea!

Just as long as the keys indicated actually reflect the keybindings (I've remapped several of my keys for rotation and translation to something that makes more sense to me), and the direction things will move in (when dealing with the negative velocity vector indicator it sometimes moves opposite of the way the positive velocity vector indicator would move).

[HeadHunter67]

Remember that WASD only control yaw and pitch, not translation - so that texture could mislead new pilots into thinking that D would move the ship (rather than the nose) to the right.

When I was starting out, I actually drew a little six-axis on a post-it with the HIJKLN directions, until it became second nature.