Jump to content

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


NavyFish
 Share

Recommended Posts

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 by nukeboyt
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 by nukeboyt
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by NavyFish
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by NavyFish
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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 by nukeboyt
Link to comment
Share on other sites

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.

dpai-thrusters-180.jpg

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

dpai-thrusters-parallel.jpg

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.

dpai-thrusters-45.jpg

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.

dpai-thrusters-lotlitttle.jpg

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

I originally had that problem back when i started using DPAI! I solved it this way :D 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.

crude_but_effective_solution.png

Link to comment
Share on other sites

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.

dpai-movement-indicator.jpg

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.

Link to comment
Share on other sites

I originally had that problem back when i started using DPAI! I solved it this way :D 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).

Link to comment
Share on other sites

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.

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.

 Share

×
×
  • Create New...