NavyFish

Excellent work, mic_e! Truth be told, this was what I had envisioned for the Docking Port Alignment Indicator mod when it was first conceived. I couldn't figure out how to draw on the Navball (Kitoban hadn't released his Enhanced Navball mod yet), so I went with a pop-up window instead. Alignment and orientation - that's all you need to dock with the navball! Great work

NEW VERSION Version 2.2 - Released 10/27/13 [update] Verified compatibility with KSP v0.22 [changed] Roll degrees now range from 0-359.9 (was -180 to +180) [fixed] Stock lateral docking ports (Inline Clampotron) now orient correctly! [fixed] Settings window toggle-buttons now much more visible

Indeed, this does work. It seems so horribly hackish, though (for example, the debug log becomes absolutely overwhelmed with spam), that I decided not to publish it in my latest release. Not that I'm opposed to hacks , but I am concerned with second- or third-order consequences of that particular approach.

For my Docking Port Alignment Indicator mod, I'm trying to allow a targeted docking port to remain targeted once it's more than 200m away from the active vessel. As far as I can tell, at 200m exactly, KSP switches the active target to the targeted vessel's root node. I can programmatically re-target the Docking Port, but an instant later KSP switches the target back to the root node. Quite simply - how and where is this retargeting occurring, and how can I override/intercept that behaviour?

Great work, gentlemen!

Version 1 of the mod is probably still installed. Remove all versions of this mod and reinstall. Note that version 1 was installed in a different directory than the current version - check the warning text file in the install package. Please report back if this does or doesn't fix the problem.

I've had success with multiple Clamp-o-tron Seniors. Check out the below pic - the orange tanks are connected to the rest of the ship using 3 Sr. docking ports abreast of each other. Probably the biggest key is to make sure the parts line up IN THE VAB 100%. I'm not sure that a 1.5m single to quad adapter actually lines up perfectly with a 2.5m quad to single, for example. I know with certainty that a 1.5 binary adapter DOES NOT line up with a 2.5 binary adapter It can be very hard to visually see the misalignment in VAB. The only way to really guaruntee you have a match is to clone the part and flip it upside down.

It's possible I'm mis-remembering how LDC worked but either way, I hope you weren't taking offense to the post. There has been enough confusion regarding the gauge that I felt some further explanation would be helpful. I don't forsee this mod implementing a camera similar to LDC for a number of reasons, but primarily due to the performance overhead it demands.

Actually, no, this is incorrect. The orange Alignment Indicator has no analogue in Romfarer's, which is actually why I made this mod in the first place. The two gauges work quite differently, believe it or not. So while Romfarer's white lines are 'analogous' to my green lines and his red cross is similar to my yellow velocity vector, the actual behaviors are quite different, for reasons that are somewhat complex. Take a look at the source code if you'd like specifics, but in general it's because my gauge attempts to remain oriented relative to your own ship's heading (i.e. so "UP" on the gauge equals "UP" on your ship), while his (at least back when I used it), remained fixed relative to the target. I'll try to explain the significance of each indication, using an an analogy. Pretend the target docking port is another person. You are standing in front of them, but they are looking slightly above your head and over your left shoulder (and are frozen in place, heh). Let's say they have a pair of horse blinders on, too, so they can only see straight ahead (no peripheral vision). If you were to move your body so that you were standing directly in their line of sight, you would effectively be centering the green cross. From that centered green cross position, if you were to turn so that you're looking directly into their eyes, you would effectively be centering the orange circle. So let's say you've done both of these things, and are now standing directly in their line of sight while looking straight into their eyes. From here, note which compass direction you're facing (let's just deal with a 2-d plane in this example), let's say heading 085. Now, if you were to remain facing heading 085, but where to move somewhere else (i.e. step sideways and backwards a few times), you would effectively be un-centering the green cross on the gauge, but keeping the orange circle centered. On the other hand, lets say you were back to standing directly in their line of sight, but now turned so that you were no longer looking into their eyes. Here, you'd effectively be keeping the green cross centered, while un-centering the orange circle. Had you turned to your left, the orange circle would move to the right, indicating you need to turn back to the right in order to be aligned properly. The yellow velocity vector shows the components of your velocity that are perpendicular to the docking port's normal vector (which extends out from the port). These components are then PROJECTED onto the gauge so that they are displayed relative to your current orientation (this is an example of what differs between my mod and Romfarer's). So, let's say for example you are directly on the imaginary line extending out from the target ports (aka it's normal vector) (your green cross will be centered), and you are also facing in the exact reciprocal of this vector (your orange circle will be centered). Now you use RCS to thrust to your right *L key on your keyboard). The yellow Vel Vector will move to the right. You stop thrusting (but obviously continue translating right), and then YAW your ship 90 degrees to the right (using the D key on your keyboard). The yellow Vel Vector will now be centered. Let's say that instead of yawing to the right, you instead rolled 90 degrees clockwise, using the E key on your keyboard. Now, the yellow Vel Vector would be directly ABOVE the center of the gauge (i.e. 12 o'clock position), indicating that your translational velocity relative to the target is in the "UP" direction relative to your current orientation. I hope this makes sense.. I know visualizing it would help quite a bit, but I'm not really up for making a tutorial at the moment (real life Navy has me quite busy) -- If one or two of the Advanced users would like to step in here and help out I would be deeply appreciative.. Just always pretend that you are looking out of the port you have selected to control from - so the white crosshair is fixed to your ship. Turn so that your ship is oriented towards the orange circle: If it's up and to the left, pitch UP using S and yaw to the left using A. If the green cross is to the right, translate to the right using L. Well I do appreciate that. A future (and possibly the next) release will indeed have the ability to minimize the gauge.

Here's a bit of an extended example for a simple GUI element that displays in the KSC scene, to help others get started: Basically everything you need to know about making GUIs for KSP can be found here: Unity Scripting Reference [KSPAddon(KSPAddon.Startup.SpaceCentre, false)] public class YourPlugin: MonoBehaviour { private static Rect windowPosition = new Rect(0,0,320,240); private static GUIStyle windowStyle = null; private static boolean buttonState = false; public void Awake() { RenderingManager.AddToPostDrawQueue(0, OnDraw); } public void Start() { windowStyle = new GUIStyle(HighLogic.Skin.window) } private void OnDraw(){ windowPosition = GUI.Window(1234, windowPosition, OnWindow, "Your Plugin", windowStyle); { private void OnWindow(int windowID){ GUILayout.BeginHorizontal(); GUILayout.Label("ABC-"); GUILayout.Label("123"); GUILayout.EndHorizontal(); GUILayout.BeginHorizontal(); buttonState = GUILayout.Toggle(buttonState, "Button State: " + buttonState); GUILayout.EndHorizontal(); GUI.DragWindow(); } } Awake() is called when the plugin is loaded, and Start() is called once everything in the scene (including other plugins) have loaded, just before the first execution tick. Inside of Awake() we add the "OnDraw" method to Unity's PostDrawQueue (You could name it whatever you want), which will automatically call it every frame. Inside of OnDraw(), we create the window, which returns its size and position as a Rect, i.e. when the user drags the window. This 'windowPosition' Rect is fed back into the GUI.Window method so that it remains wherever the user dragged it to. GUI.Window points to another method, OnWindow (again, you can name it whatever you want), which contains the window drawing code. From within OnWindow(), we use GUILayout to automatically arrange the various elements (i.e. labels, buttons, sliders, etc). Finally GUI.DragWindow() allows the window to be dragged (and should always come at the end of this function). Again, check the Unity Scripting Reference linked above for all your GUI concerns!

If I understand you correctly, you want the "CVEL" value in the bottom-right of the gauge. This is short for "Closure Velocity". The Yellow Velocity Vector shows velocity perpendicular to the approach corridor, while CVEL shows velocity parallel to the approach corridor.

Thanks for the comments! In the absence of roll ticks around the entire gauge, make sure you're using "Show Roll Degrees" in the settings menu for a digital readout.

Odd. The number of ports should have nothing to do with it. I don't use KW - is the multi-port thing you mentioned a single part? If so, that might be the issue, but I haven't encountered this before.

More than likely it is correctly controlling from the shielded docking port, but when you target the Inline port things get twisted. Does controlling from the shielded port while targeting a normal docking port (not inline) work fine? If so, that's definitely the problem.

Exactly what readouts would you like to see?

Indeed, that part's coordinate system is not aligned with its docking axis. I'll see what I can do to work around that. Thanks for the report.

Thank you, JDP. I'm still exploring a way to achieve this effect without tweaking other parts of the game, but this is great information to have - and if I can't get another approach working, then I'm likely to use your approach. NGTOne - I think JDP's answer would explain the problem you're having - the Docking Nodes are likely getting packed up at 200m, and thus the logic that controls their connection is disabled. I've made a simple partless plugin incorporating his code above. You can download it here and give it a shot. The source: using System; using UnityEngine; namespace PartPackExtender { [KSPAddon(KSPAddon.Startup.Flight, false)] public class PartPackExtender : MonoBehaviour { public void Start() { OrbitPhysicsManager Manager = (OrbitPhysicsManager)GameObject.FindObjectOfType(typeof(OrbitPhysicsManager)); Manager.distantLandedPartPackThreshold = Manager.distantPartPackThreshold = 2250; Manager.distantLandedPartUnpackThreshold = Manager.distantPartUnpackThreshold = 2000; } } } Please let us know if that fixes your problem. I can't test it out because I don't have any ships that are > 200m long! lol Also, worth noting - it seems that the OrbitPhysicsManager has been deprecated. The meta text reads: 'Manager.distantLandedPartUnpackThreshold is obsolete. Use Vessel.distanceUnpackThreshold instead' (and likewise for the pack threshold) I'm not sure if the correct 'Vessel' to use would be FlightGlobals.ActiveVessel, or the Vessel you're trying to dock to - but hopefully for now the OrbitPhysicsManager is still functional.

Awesome, thanks for the reply. I will try that - though I thought the "loaded" flag indicated vessels were within the 2.5 km scene? My current code does something very similar to the first block you posted, but I haven't worked with Proto stuff at all. I'll have to dig around the forums to get more detail on what they are, exactly. I've noticed that "FlightGlobals.fetch.VesselTarget" changes at 200m, if you had a docking node manually targeted - it shifts to the root part of the ship. So I think my way forward is going to be whenever the target changes, find out the vessel that belongs to the targeted part, then traverse through its list of parts and find the appropriate docking node.

Here's a starting point for the code itself: [KSPAddon(KSPAddon.Startup.MainMenu, false)] public class YourPlugin: MonoBehaviour { public void Awake() { } public void Start() { print("Holy Sh*t the plugin started correctly!!"); } } You create a class library (DLL) that includes subclass of MonoBehaviour, and put that in KSP's GameData directory (In this case, you'd call it "YourPlugin.dll", to match the name of the MonoBehaviour). From there, KSP automatically detects it, and will load it at the appropriate time based upon the settings you put in the attribute (KSPAddon.Startup.MainMenu, in this case. Other choices would include editor windows, in-flight, etc). Awake() is automatically called by KSP when the plugin is loaded, and Start() is called once the appropriate scene has been completely loaded, i.e. on the first execution tick. You can see the output from this plugin by hitting ALT+F2 at the main menu to bring up the debug console. Scroll up a bit, and you'll find the text it printed. Check out the source code in other mods to build a sense of how to work with Unity/KSP through scripts. You're welcome to browse through my code (included in the download: http://kerbalspaceprogram.com/dock-align-indicator/) -NavyFish

The title says it all, I'm wondering if anyone can help me with this. I've noticed that in ModuleDockingNode, the "UnsetTarget()" event has an "unfocusedRange = 200f" attribute - this might have something to do with it, but I'm not looking to modify KSP's default behavior, just disable it in particular cases. If I procedurally "FlightGlobals.fetch.SetVesselTarget(..)" when outside of 200m, the target node is set for a split second, perhaps a frame or two, and then becomes un-selected. Thus, there's probably an event system going on here. If that was the case, I might be able to override the "UnsetTarget()" method, but I'm trying to do this purely through a MonoBehaviour (plugin), and not through a PartModule. Any help would be greatly appreciated. -NavyFish

I'm trying to draw a 'ghosted' part in-flight - I don't want the drawn part to interact with physics in any way, nor be selectable etc as a normal part would be. My first attempt was to simply clone the desired part's GameObject, and disable physics on it as seen below: clone = (GameObject)GameObject.Instantiate(highlightedPart.gameObject); clone.rigidbody.isKinematic = false; clone.rigidbody.detectCollisions = false; clone.GetComponent<Part>().physicalSignificance = Part.PhysicalSignificance.NONE; clone.GetComponent<Part>().PhysicsSignificance = 0 The part draws correctly (I'm rescaling it and translating it slightly in a later chunk of code), but unfortunately it still interacts with physics. On top of that, you can select it, right-click it, etc. So, what I really want to do is to just grab the Mesh component of the part and work with that, throwing out all the logic and physical simulation. But I can't seem to find it! GameObject isn't listing MeshRenderer as one of its components. If anyone has experience with this situation or more familiarity with Unity, I'd greatly appreciate any help. -NavyFish

Indeed, that works nicely. I've tweaked the highlight to 'pulse' around a 1-second period, which helps bring the eye to the port. I'll put in a toggle to enable/disable highlighting. This works at close range, within 50 meters or so. Outside of that, it's pretty hard to see the highlight, but I think I have a solution that keeps with the simplicity/subtlety of this one. Stay tuned.

Quick update: Port cycling works! In my dev build, you can now press a button to cycle through all ports on the targeted ship. I still need to come up with a good UI to indicate which port is targeted. To test the "approach corridor" concept, I'm drawing a long orange line out from the targeted port (in 3-D space), but I'm not sure how I feel about the aesthetic of a 3-d overlay. It seems a bit too 'futuristic', as odd as that sounds. Another possible approach would be to draw a 2-D circle around the target port, in "GUI' space. Thoughts?

Yep, exactly. Hence why version 1.0 only displayed the alignment circle (and hence the name of the mod ) - this was the only information that could not be gleaned from the Nav Ball. I'm starting to build a feature/change list for 3.0, though there may be a point release before then. So far: Small stuff: -Changes to the roll degrees (0-359.0, vice -180 to 180). -Possibly reducing the range of the alignment and velocity vector, to improve resolution without having to resort to exponential (can't add much more before it becomes 'twitchy'). -A touch more expo on the CDI needles Bigger stuff: -Ability to resize gauge (it's already in there, I just need to convert to Bitmap fonts so that those will scale correctly, which is not trivial). -Ability to cycle between target ships and target docking ports through the gauge itself (and hopefully remove the 200m restriction) -This will necessitate have the gauge visible even when no target is selected, so I'll need to make a 'minimized' version that still allows you to cycle targets/ports. -Since the selected port itself isn't highlighted, I may need to draw some kind of overlay on-screen (i.e. in the 'world' itself) that highlights the selected port. This might be too intrusive, though. Thoughts? I'm also looking for inputs on the orange "fly-to" arrow for the alignment indicator. Should this be replaced with a 'retrograde' alignment indicator (might be confusing)? I think it's a bit ugly, frankly. Any ideas would be appreciated. Please post any other suggestions you'd like to see implemented. -Navy

Thanks for posting that guide, HeadHunter. I've been fairly busy with other commitments lately, and thus the plans to produce a new tutorial video that thoroughly explains how to use the gauge have been delayed. Your instructions should help new users until then! I'm linking your post on the OP. P.S. If anyone wants to make a tutorial video of their own, I'd be highly appreciative (I'd rather focus on coding anyhow ). All I ask is that you let me review it first before posting, just to double-check for accuracy.