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

[gilflo]

Maybe, in the preset, you could give the choice for the range at which the windows appears automatically when a ship is targeted? If you offer a preset from 0,2 to 2,3 kms that everybody can choose, may be it would be more comfortable

[taniwha]

My general rule of thumb is "when in doubt, make it a config option". Of course you then get the problem of choosing the default, but the one you expect to cause the least confusion is usually the best.

[RoboRay]

I don't think automatically selecting the nearest docking port and opening the UI would be a desirable feature, unless the target only has one docking port. And not always then, really.

I don't always approach a large ship or space station and just dock at the closest port... I'm usually intending to go to a specific port, which may be on the far side of the vessel.

[Commander Zoom]

Yeah, I gotta go with "let me pick for myself".

[BPI_Bel]

If the DPAI offered a list of docking ports in a collapse-able field to the side of the main DPAI interface, that would give us that long-range targeting that seems to be your intent with the auto-target feature, while allowing the user complete control over when the DPAI appears.

[dryer_lint]

This is a great mod, and it's helped with docking a lot... but mine is rather laggy for some reason. Is there any way to make it smoother?

[NavyFish]

Thank you all for the feedback. I'm mulling over this, but career commitments have had me pretty busy lately and so progress is slow.

@Nikola7007: It's more than likely not caused by DPAI. This plugin is very light-weight in terms of both memory requirements and processing. I recommend checking your debug log (hit alt+f2) for a bunch of null-reference errors, as perhaps another mod is breaking and causing your slowdown.

[Starwaster]

Hi NavyFish, I'd like to suggest a code change for calculateGaugeData()

The original code is commented out.

The main change is that instead of looking at the transform directly, it's calling GetTransform() on docking port module which returns the transform for the node. No more need for it to do a check for squad's lateral shielded port and it will work with any future docking port mods, even ones with multiple docking nodes per part. Specifically Porkjet's FLAT habitat which has three different docking ports on a single part pointing in three different directions.

I've tested this on that part and the stock ports to make sure that it works and it does.

One thing: I might have got the direction wrong... I thought it should be + for both but had to set it to -targetTransform.up.normalized for the roll, so I'm not sure the forward vector is actually correct. Still seems to work but... caveat.

[FONT=Menlo][COLOR=#3363a4]Transform[/COLOR][COLOR=#444444]selfTransform[/COLOR][COLOR=#444444] = [/COLOR][COLOR=#444444]FlightGlobals[/COLOR][COLOR=#444444].[/COLOR][COLOR=#444444]ActiveVessel[/COLOR][COLOR=#444444].[/COLOR][COLOR=#444444]ReferenceTransform[/COLOR][COLOR=#444444];[/COLOR]
[COLOR=#444444]ModuleDockingNode[/COLOR][COLOR=#444444]targetPort[/COLOR][COLOR=#444444] = [/COLOR][COLOR=#444444]FlightGlobals[/COLOR][COLOR=#444444].[/COLOR][COLOR=#444444]fetch[/COLOR][COLOR=#444444].[/COLOR][COLOR=#444444]VesselTarget[/COLOR][COLOR=#009695]as[/COLOR][COLOR=#444444]ModuleDockingNode[/COLOR][COLOR=#444444];[/COLOR]
[COLOR=#999988][I]//[/I][/COLOR][COLOR=#999988][I]Transform[/I][/COLOR][COLOR=#999988][I]targetTransform[/I][/COLOR][COLOR=#999988][I] = [/I][/COLOR][COLOR=#999988][I]targetPort[/I][/COLOR][COLOR=#999988][I].[/I][/COLOR][COLOR=#999988][I]transform[/I][/COLOR][COLOR=#999988][I];[/I][/COLOR]
[COLOR=#3363a4]Transform[/COLOR][COLOR=#444444]targetTransform[/COLOR][COLOR=#444444] = [/COLOR][COLOR=#444444]targetPort[/COLOR][COLOR=#444444].[/COLOR][COLOR=#444444]GetTransform[/COLOR][COLOR=#444444] ();[/COLOR]
[COLOR=#3363a4]Vector3[/COLOR][COLOR=#444444]targetPortOutVector[/COLOR][COLOR=#444444];[/COLOR]
[COLOR=#3363a4]Vector3[/COLOR][COLOR=#444444]targetPortRollReferenceVector[/COLOR][COLOR=#444444];[/COLOR]

[COLOR=#444444]targetPortOutVector[/COLOR][COLOR=#444444] = [/COLOR][COLOR=#444444]targetTransform[/COLOR][COLOR=#444444].[/COLOR][COLOR=#444444]forward[/COLOR][COLOR=#444444].[/COLOR][COLOR=#444444]normalized[/COLOR][COLOR=#444444];[/COLOR]
[COLOR=#444444]targetPortRollReferenceVector[/COLOR][COLOR=#444444] = -[/COLOR][COLOR=#444444]targetTransform[/COLOR][COLOR=#444444].[/COLOR][COLOR=#444444]up[/COLOR][COLOR=#444444].[/COLOR][COLOR=#444444]normalized[/COLOR][COLOR=#444444];[/COLOR]

[COLOR=#999988][I]/*[/I][/COLOR]
[COLOR=#009695]if[/COLOR][COLOR=#444444] ([/COLOR][COLOR=#444444]targetPort[/COLOR][COLOR=#444444].[/COLOR][COLOR=#444444]part[/COLOR][COLOR=#444444].[/COLOR][COLOR=#444444]name[/COLOR][COLOR=#444444] == [/COLOR][COLOR=#f57c00]"[/COLOR][COLOR=#f57c00]dockingPortLateral[/COLOR][COLOR=#f57c00]"[/COLOR][COLOR=#444444])[/COLOR]
[COLOR=#444444]            {[/COLOR]
[COLOR=#444444]targetPortOutVector[/COLOR][COLOR=#444444] = -[/COLOR][COLOR=#444444]targetTransform[/COLOR][COLOR=#444444].[/COLOR][COLOR=#444444]forward[/COLOR][COLOR=#444444].[/COLOR][COLOR=#444444]normalized[/COLOR][COLOR=#444444];[/COLOR]
[COLOR=#444444]targetPortRollReferenceVector[/COLOR][COLOR=#444444] = -[/COLOR][COLOR=#444444]targetTransform[/COLOR][COLOR=#444444].[/COLOR][COLOR=#444444]up[/COLOR][COLOR=#444444];[/COLOR]
[COLOR=#444444]            }[/COLOR]
[COLOR=#009695]else[/COLOR]
[COLOR=#444444]            {[/COLOR]
[COLOR=#444444]targetPortOutVector[/COLOR][COLOR=#444444] = [/COLOR][COLOR=#444444]targetTransform[/COLOR][COLOR=#444444].[/COLOR][COLOR=#444444]up[/COLOR][COLOR=#444444].[/COLOR][COLOR=#444444]normalized[/COLOR][COLOR=#444444];[/COLOR]
[COLOR=#444444]targetPortRollReferenceVector[/COLOR][COLOR=#444444] = [/COLOR][COLOR=#444444]targetTransform[/COLOR][COLOR=#444444].[/COLOR][COLOR=#444444]forward[/COLOR][COLOR=#444444];[/COLOR]
[COLOR=#444444]            }[/COLOR]
[COLOR=#444444]            */[/COLOR]
[/FONT]

[Addle]

Hi NavyFish, I'd like to suggest a code change for calculateGaugeData()

The forum seems to have mangled your code a bit. But since I had this issue with the Habitat Pack docking ring yesterday, I figured I'd try and compile myself a new DockingPortAlignmentIndicator.dll with your changes. I haven't really tested it beyond undocking a ship, and redocking it, but once I found the correct docking port button of the three, it did in fact work properly. So, thanks for that, Starwaster!

NavyFish, I hope you'll look into it. I had to dock without DPAI, yesterday! The horror! Also, a .csproj file in the source would have saved me some time.

[taniwha]

StarWaster, Addle: I've already sent NavyFish patches that use GetTransform() and make DPAI a little more general (eg, support for EL's bins). He's said he'll incorporate them, but he seems rather busy with RL at the moment, so we'll just have to wait.

[Starwaster]

StarWaster, Addle: I've already sent NavyFish patches that use GetTransform() and make DPAI a little more general (eg, support for EL's bins). He's said he'll incorporate them, but he seems rather busy with RL at the moment, so we'll just have to wait.

The license seems fairly permissive... I could put my build up for those in need...

[NavyFish]

Thanks both of you for the code inputs! As taniwha mentioned, he proposed a nearly identical change back in May. I'm glad to report it does indeed generalize the port orientation logic.

RL has been quite busy for me lately, but I believe I will have an opportunity this weekend to release version 4.0 of the mod. There are a LOT of changes coming, and so bug-hunting and QA have required a lot of effort this time around. I have one last little bug I'm facing, and unfortunately I can't reproduce it reliably enough to determine its source - I don't even know if it's being caused by DPAI. It's been reported by others as well, even folks not using DPAI, so it's likely a bug in Squad's code - but it's quite possible that DPAI is doing something to triggering it. Unfortunately the bug requires you to force-quit KSP (it prevents you from being able to save, load, or go back to the space center), so the impact is not insignificant.

With the upcoming release imminent, I'd ask that you hold-off on releasing your own version of the code at the present. If there's sufficient interest (and there seems to be), I may go ahead and host the project on github, thus allowing folks to propose and test changes with more frequency and ease.

I think you're going to like the added features in 4.0. Thank you for your patience!

Navy

[NavyFish]

Yep, looks like everyone can expect a release this weekend!

Taniwha's code helped in more than one way - it seems to have removed the nasty null ref! I can never be 100% sure, but the bugger hasn't surfaced in a while. Looks like calling partModule.transform could sometimes return a null reference, whereas ITargetable.GetTransform() always returns something. I'm not sure how one would safely get the transform for a PartModule that doesn't implement the ITargetable interface... perhaps partModule.part.transform is safe? Anyway, not my problem

Doing a few last minute tweaks... made it so that "occupied" docking ports aren't selected when cycling (though you can still manually target them w/ a right-click). There are several more features I want to implement, but I'm forcing myself to stop here and get this thing out into the wild. There will inevitably be a version 4.1, and I even have some ideas for a version 5 (whereas by my ad-hoc versioning convention, whole numbered releases indicate large chunks of added functionality while 'point releases' contain smaller tweaks and fixes).

Huzzah! I may even have time to make a short release vide (though those things always take longer than expected..)

Navy

Also,

a .csproj file in the source would have saved me some time.

This release will have all the source files included, my apologies. Edited June 28, 2014 by NavyFish

[DeepOdyssey]

Is there any way to invert the dpai settings. The up and down are ok, but the left and right are switched. And, please, don't suggest changing controls ingame. I don't use docking staging.

[NavyFish]

There seems to be enough people requesting this that I will consider putting in an option to change the control scheme. But I need to get a consensus on what folks would like to see for an alternate scheme.

To me, the controls are all oriented correctly. I imagine people think that when they use WASD (staging controls), they're moving the orange circle - but, you're not. You're changing your ship's orientation, i.e. the white center crosshair, to line it up with the orange circle. Thus if the orange circle is up and right, you pull up (S) and turn right (D). Likewise, if the green CDI crosshair is up and right, you translate your ship up (K) and right (L) to get on centerline.

Feel free to post your requests, be specific with respect to what control input (using staging mode) should have what effect on the gauge. If there's a consensus, I'll include it (probably for v4.1 as I'm trying to release this weekend).

[diomedea]

Is there any way to invert the dpai settings. The up and down are ok, but the left and right are switched. And, please, don't suggest changing controls ingame. I don't use docking staging.

There seems to be enough people requesting this that I will consider putting in an option to change the control scheme. But I need to get a consensus on what folks would like to see for an alternate scheme.

...

Consensus! I would like to show I agree on the above. But, for me it just works in reverse. I am absolutely fine with WASD(QE) and (HN)JL, but IK (up and down translation controls) seem reversed and always (each time I start a docking) have to try them a couple times blank to get used at them.

Sure, DPAI may show reverted indications about the up/down axis, and that would help me set my bearings correctly. But other tools use the same as DPAI currently (tried with Docking Navball and the Docking Camera from Lazor systems, all tools seem to match) so it shows it is my handling that needs some upgrade, not the tools. After all, real pilots undergo extensive training before they are allowed in a real cockpit.

[NavyFish]

So perhaps two options would be useful: "Invert Translation Y-Axis" and "Invert Orientation Y-Axis" ?

Correction: that wouldn't address DeepOddessy's concern. I suppose I could provide toggles for inverting all four axis.

Edited June 28, 2014 by NavyFish

[taniwha]

Just so long as everything defaults to the "correct" (current) behavior, I have no problems with inversion options (though making them well hidden might be good). I went through my own "intensive training session" until I clicked that I was moving the white cross-hair and not the moving markers. I'm not keen on the idea of that hard work being undone

[diomedea]

I am considering if those axis inversions with DPAI are really needed. If only DPAI had axes inverted out of all the tools that show docking helpers, that would make things more confusing. In my case, getting set with up and down just requires to try the RCS - something I like to consider akin to test the RCS system works, before using it for real. Taniwha is also right, we actually move the ship (the cross-hair), not the target (moving markers). But if anybody really has issues figuring directions with IK and JL command pairs, I guess those commands may be easily switched in the game settings.

[NavyFish]

It's finally here

Version 4.0 - Released 6/29/2014

• [added] Ability to cycle through all unoccupied ports on your target. No more need to right-click a port!
  
• [added] Ports can now be targeted up to 2.25 Km away!
  
• [added] When a vessel is first targeted, the nearest port is automatically targeted.
  
• [added] Magenta HUD indicator floats on top of currently targeted port to allow for easy identification.
  
• [added] Ability to rename all docking ports using the right-click GUI (in both VAB/SPH and flight).
  
• [added] Text readout on indicator which displays the name of the targeted port.
  
• [added] Closure Distance (CDST) readout, displays range to target port along the approach axis only.
  
• [added] Prograde icon on velocity vector changes to Retrograde icon when CVEL is negative.
  
• [added] Support for parts with multiple docking ports (Thanks taniwha!)
  
• [added] Support for Extraplanetary Launchpads' recycle bins (Thanks taniwha!)
  
• [changed] New toolbar button icon, easier to identify. Clicking toolbar button will show/hide indicator.
  
• [changed] Removed hard-dependency on Blizzy's Toolbar.
  
• [changed] Added custom 'toolbar' button if Blizzy's toolbar is not present.
  
• [changed] Text now drawn using Bitmap Fonts, allowing for higher resolution text rendering particularly when increasing gauge scale.
  
• [fixed] Indicator no longer displayed in Map View or while on EVA
  
• [fixed] Generalized port orientation logic - all non-stock lateral ports should now work (Thanks taniwha!)
  

See first post for download link. Also, note - for those of you who are really quick to the draw, Curseforge is still listing the file as "Under Review", so you may need to wait a moment.

[Deadweasel]

Link still leads to 3.1.

*shakes fist in impotent rage at Curse*

*ahem*

Nevermind, it seems we're both re-editing posts on-the-fly simultaneously, which is a recipe for confusion and disaster. Just saw the addendum to your latest post, so I'ma just gonna slink over to the corner and pout until Curse recognizes the genius and approves your latest version.

Edited June 29, 2014 by Deadweasel

[Alewx]

First question:

what is exactly meant with [added] Support for parts with multiple docking ports (Thanks taniwha!)?

[Deadweasel]

First question:

what is exactly meant with [added] Support for parts with multiple docking ports (Thanks taniwha!)?

Some mod parts have multiple docking nodes on them. He's fixed it to recognize multiple docking nodes on a single part, not only whole parts that act as a docking node.

[Alewx]

Some mod parts have multiple docking nodes on them. He's fixed it to recognize multiple docking nodes on a single part, not only whole parts that act as a docking node.

Thanks, I was sooooo close to hope for multiport Docking

[taniwha]

Some mod parts have multiple docking nodes on them. He's fixed it to recognize multiple docking nodes on a single part, not only whole parts that act as a docking node.

I imagine that's true, but it's actually an accidental feature (ie, wasn't in my goals). My one goal was to get DPAI working with EL's bins (for which I still have to release an update to correct the target orientation), the rest of my "enhancements" came along for the ride.