NavyFish

So there I am, in Minimus orbit, with a Mobile Processing Lab and a small lander. I mean SMALL, this thing had to fit inside a 1.25 meter fairing. It's freakishly tall, but it works. I've crammed a materials bay, 2 goo canisters, and 6 thermometers on it. My first four biomes went great: I'd drop off the lander, perform a materials study, get 2 goo looks, an EVA report, crew report, take a couple temperature readings, grab a surface sample, and plant a flag to mark the biome. Wait for my MPL/mothership to complete it's orbit, launch and rendezvous, dock, and refuel for the next go. Upon docking, I would use the lab to improve the transmission value of the goo and materials lab, then transmit those along with the crew/eva reports and thermometer readings. I'd then go on EVA, and take the surface sample over to my hitchhiker storage unit, which would ultimately be the return vehicle for my 3 crew (1 lander pilot (Jeb, of course), and the 2 scientists in the lab (Bill and Bob)). Suddenly, a thought, both monstrous and wonderful dawned upon me: what if I could remove the materials and goo samples from their equipment, and store them in the hitchiker for the return trip as well? I tried it, and, sure enough, it works! This can also be done with the thermometer readings, though on my vessel they're a bit tricky to reach on EVA (this will surely inform my lander designs in the future..). I'm at once delighted, as instead of losing over 65% of the data value on material lab transmissions, I can return 100% of the data to Kerbin, but also a touch , as I technically 'wasted' several hours conducting landings, only to burn away most of that precious potential science by transmitting the data, thinking I had no way to return the sample home. So that brings me here, to post my findings, with the hopes that another brave explorer may avoid making this same mistake! I'm willing to believe that most folks know this tip already, but if this post saves just one person their time and data, then it will have been worth it. Thanks for reading, and, if you have them, please feel free to share any other less-obvious science tips that you may have discovered! "Dock safe" -Navy

All good ideas. For a first pass, I'll generate a HUD reticule over the selected part, akin to the normal target diamond but probably a different color (orange?). It may be easy in code to distinguish between ports of different size. If so, I'll filter (with the settings option to not filter) the list of available ports to those matching in size. I'll take a look at shielded and docked ports - not sure how those are represented in code, but if I can parse them I'll include them as a filter option as well (with shielded ports likely defaulted to not filter, as it's more of an advanced usage case). Part naming, as far as I can tell, is a whole other monster. Module Manager may allow for it, but I won't have the time to research that before my desired release date - I'll be getting underway again for some time and would like to push these new features prior to that time. Targeting asteroids and other types of objects falls under this category as well, but I admit would be a very cool feature, so I'll look into it for the future.

Gentlemen, GREAT SUCCESS: If I may, please draw your attention to the distance readout to the targeted docking port. I have discovered how to interact with docking ports beyond the 'default' 200m radius. Ports can now be targeted up to ~2.25 km (or whatever your vessel load/unload distance is set to, via other mods). Of course, you can't right-click a port at that distance. Heck, I find it hard to right-click a port at anything more than 100m, particularly if there's relative motion involved. Thus, the next update will include the ability to cycle-through the list of docking ports on your target. Finally, there will be a reason for the toolbar integration (although I will be making it optional, and provide a standalone button if blizzy's toolbar isn't present). Here's how I picture it all working... (Note that I'm sharing this with you for feedback purposes. If you think there's a better way to do this, then speak up!) This DPAI 'reticule' window will always be available, and its visibility can be toggled with the toolbar button. When visible, if the target is not loaded (beyond ~2.2 km), it will simply display a message in the window indicating that the target is too far away. Once you've closed within the loading distance, the nearest port will automatically be targeted (A settings option will allow the DPAI to automatically pop-up whenever you're in docking range, if desired). Somewhere on the gauge will be a left and right arrow, which will allow you to cycle through the available docking ports. It will also likely display the human-readable name of the type of port that's selected. Finally, and this may not make it into the next version unless I can figure out how to do it soon, there may be a little 'diamond' reticle overlaid in world-space over the selected port, for quick visual identification of your selection. I've experimented with part highlighting as an alternative, but I think it's just ugly. As always, interested to hear your feedback. Free-time is very limited for me at the moment, so I can't give you a reliable estimate as to when the next update will come out, but stay tuned, I think sometime within the next 2 weeks will be reasonable.

Congrats! Always nice to hear! I believe that was the current version of blizzy's toolbar when I last updated the plugin. The coming update will likely not even include the toolbar folder, as integration will be optional.

Thanks jmanidb! If anyone could tell me how to get an individual part's transform when it's greater than 200m away from the active vessel, that'd be great! Time permitting, I'll be taking another whack at this, and if we can figure it out, I'll add a couple "Target Port Cycle" buttons to the mod (including a HUD-style selection diamond over the selected port in-game), so that we no longer have to right-click the target docking port. Also.. I've added a donation button to the first post. I'm not looking to quit my day job (yet.. ), but after making a few contributions myself to other modders, I figured why not. I'm not going to put up an AdFly link because advertisements are so very annoying. If you're feeling generous, a small contribution would be incredibly appreciated! -Navy

This plugin currently requires blizzy's toolbar to be installed. In the next version, I will be removing this dependency (keeping integration optional). I apologize for the inconvenience.

Hey, sorry about that. I should have updated the release notes / title. Doing so now may cause more confusion, though, so hopefully folks will find the forum thread if they face the same issue. My apologies!

Sure, I could make the roll degrees toggle between modes in the next version. Enough people have asked for this to warrant the addition. Long-term, yes, I'd like to incorporate the approach corridor, but there are a couple other large features I'd like to build first: a target port cycler, likely with an indicator on the main game screen depicting which port is selected. This is to alleviate the annoying hunt-and-right-click exercise you have to do every time you want to bring up the indicator, which can be near-impossible when there's relative motion involved. After that, I want to re-attack the 200m range issue. Only then will I look seriously into making an approach corridor. In other news, I'll be away from the forums for the next month, off doing Navy stuff. Might have an opportunity to work on the mod while I'm away, but will not be checking the forums. Don't break anything while I'm gone! (Or, do, and then PM me about it ) See you folks in a month! -NavyFish

I'm glad you're finding it useful! I can provide colorblind support in a future patch - can you suggest an alternative color palette that would be easier to pick out for color Regarding the use of a part for the mod - if I were to do this, it would be done in a separate "realism" mod, because I wouldn't want to force it upon anyone. I don't see this happening in the near future, however, due to the time commitment it would require. Finally, the text of the link deadweasel mentioned is pasted below. It's basic, but should get anyone to the point of consistently docking, where they can then begin to discover the actual function of each needle through experimentation. I'll point out that "Chase mode" actually isn't essential, as the orange crosshair is always aligned to your ship's pitch/yaw axis - i.e. regardless of your camera's orientation, or your orientation with respect to your target, pressing W will still move the nose of your ship down with respect to the target port alignment indicator (orange crosshair), thus causing the crosshair to appear to move 'up'.

You're welcome! And thank you for the comments!

You should have extracted the 'NavyFish' and '000_Toolbar' folders into Gamedata.

Thanks, both of you. I've removed the extra dll from my plugin's directory, and re-uploaded the fixed archive to the Spaceport. I think Visual Studio copied Toolbar.dll into my bin directory, and I copied it into the archive without checking. Bilzzy - you might want to follow a singleton pattern with your toolbar in case someone else makes the same mistake! -Navy

Sorry, that kind of code is non-trivial and not really worth the effort in my opinion. Thanks for the suggestion though, and I'm glad the mod works well for you! You're welcome! Damn you and your awesomely huge screens! lol Actually this feature has been on my to-do list since version 1, I just hadn't found an easy way to draw bitmap fonts (and still haven't, really... What text rendering I've written in there is a hard-coded kludge, but it does the trick). Next up: a bit of texture cleanup and sharpening, some more data readouts, and perhaps an orbiter-store precision zone on the gauge.

As you have probably noticed, the toolbar icon is somewhat redundant at the moment - settings can still be accessed using the "settings" button on the indicator itself. In the future, however, this icon will be used to interact with the indicator when no target is selected, allowing for fancy-schmancy stuff like target port cycling, etc.

Docking Port Alignment Indicator v3.0 now uses the Toolbar Plugin. Thanks, blizzy!

Oh by the way.. Version 3.0 - Released 12/18/2013 [update] Verified compatibility with KSP v0.23 [added] Indicator's size can now be scaled freely (from settings window) [added] Toolbar-Plugin miniature icon for toggling the settings window [added] Glyph Font rendering to support indicator scaling [fixed] Indicator will now display at full resolution regardless of KSP's Texture Settings

Are your texture settings at "One-Eighth", and if so, does it look correct if you turn them up to full? EDIT: This issue has been resolved in v3.0! Please test and let me know if it works on your machine.

It wouldn't be hard to calculate, but displaying those numbers might require a small redesign of the gauge to accommodate them. Frankly I've been opposed to overloading the indicator with numeric displays in the past. But now that other modders have come out with on-nav-ball instrumentation, I can see this plugin filling the niche for people who want all the details and extreme precision. This would include X and Y (planar) translation offset and relative velocity. I'll make this information toggleable. Still, I'd like to integrate it with the gauge as opposed to just throwing text on there haphazardly, so will need to make a few design choices. Feel free to post your ideas. In all, this constitutes a good a weekend or two of effort, which unfortunately I do not have at this time due to military commitments. I might find some time during the upcoming holidays, however, so stay tuned!

Check the debug log by pressing F2 in-game. Scroll up a bit, you're probably getting a null exception error (it will display in red). When a script fails, it gets left in an awkward, half-finished state, which sounds like your description. The other likely problem is that your OnWindow function does not have the exact same name as the 3rd parameter in GUI.Window. Have you imported the unity DLLs and KSP DLL into your project? (ithout those I imagine the C# project wouldn't even compile, so I assume so, but you never know)

Ah, great, that's what I suspected. The CDI lines and digits are dynamic graphics, while everything else are textured sprites. I'll have to see if KSP/Unity have some kind of flag indicating the game is using low-res textures. If so I could package a lower res version of my textures and switch to them when appropriate. The blurriness you're seeing is because of downsampling (and subsequent filtering).

I'll look into it, it's probably something to do with the texture size/resolution. Are the CDI (green) lines blurry? Is text blurry?

That's confounding. Try reading through your ksp.log file. If you post it I'll be happy to take a look myself. It's possible something's throwing a null reference error, which tends to cause a lot of down-stream silent script failures.

The structure you listed is absolutely correct. Are you running many other mods? I'm not aware of any incompatibilities, but I suppose that would be possible. If you had version 1.0 installed, it used a totally different structure - I believe "DockingPortAlignment" was the top-level folder under GameData. If so, definitely remove that. Anyone else have any ideas?

I'd probably take a look at this: http://forum.kerbalspaceprogram.com/threads/48720-TT-NeverUnload-Vessel-Unloading-Preventer

That's a nice idea. I'm currently trying to crack the code to enable targeting at distances > 200m. If/when that happens, I'll look into making an ILS plugin! Thanks