Trueborn

Warmadmax, I found the bug you reported. I was camping -30 to +30, which is why large draws looked like charges. I've fixed that, and I'm also reworking the gauge scaling so it will be easier to tell what the draw/charge is at lower values. Expect a beta 4 release later today.

warmadmax, I believe it should be working better in this new beta version. I'm not really happy with the way electrical draw is working, right now I'm having to just compare it to the previous value from 0.2 seconds ago because I can't seem to find the actual value that a part is either producing or using. There is a new beta version available! Version 1.3 Beta 3 includes several tweaks and bug fixes, and one new feature. - Scrolling digits should now scroll better - The vertical descent mode works, and orients correctly to compass headings - Mouse Input mode has a new icon to help identify the dead zone before input is accepted - The HUD now displays a warning when electrical charge, total fuel, or monopropellant falls below 5% remaining. Remember to deploy your solar panels, kids. This should be a fairly stable release, and assuming no major bugs are reported will probably get released as version 1.3. Currently my only plan for 1.4 is to double the width of the pitch ladder (should make finding nodes and vectors easier), unless I can come up with some useful air intake/engine readout stuff. Download link: https://skydrive.live.com/redir?resid=131B3D0DB2B5645E!118

Thanks for the support guys. There is a new beta version available! Version 1.3 Beta 3 includes several tweaks and bug fixes, and one new feature. - Scrolling digits should now scroll better - The vertical descent mode works, and orients correctly to compass headings - Mouse Input mode has a new icon to help identify the dead zone before input is accepted - The HUD now displays a warning when electrical charge, total fuel, or monopropellant falls below 5% remaining. Remember to deploy your solar panels, kids. This should be a fairly stable release, and assuming no major bugs are reported will probably get released as version 1.3. Currently my only plan for 1.4 is to double the width of the pitch ladder (should make finding nodes and vectors easier), but really good suggestions might still be accepted. Download link: https://skydrive.live.com/redir?resid=131B3D0DB2B5645E!118

A new beta release of SteamGauges is now available. Version 1.3 Beta 2 adds several improvements, most notably to the HUD. The pitch ladder now clamps to it's section of the HUD, and will not overwrite the speed/altitude tapes. The FPV and other markers also clamp to the pitch ladder much better. In the spirit of 0.22, the HUD is disabled until you research Electronics. The other gauges are available from the beginning. There is also a new "Vertical Ascent" mode that you should notice the next time you launch a rocket. This allows much better control at attitudes above 70 degrees. Additionally, Orbital mode is now available. When a vessel is in a stable orbit, the HUD changes to a relative indication of your velocity. In other words, the pitch ladder and compass now represent how far the ship's nose is from the FPV. To burn prograde, just set 0 pitch and heading 0. To burn retrograde set the heading to 180. This mode can be disabled through the advanced menu. And the final addition is mouse input for fine control. Also enabled through the advanced menu, you can click in the center of the HUD and drag to make fine attitude adjustments. Useful to get a burn just right, or if your vessel has a bit too much control authority. Download link: https://skydrive.live.com/redir?resid=131B3D0DB2B5645E!118

Actually, its based off of my personal favorite HUD, the C-17's. I don't know why its backwards, but since its the one I actually fly around with, I'm unlikely to change it any time soon.

Sorry for everyone who may have been waiting for updates, but I've recently had an attack of Real Life that has taken up a lot of my time. I do have some updates in the works, and I'll roll in 0.22 compliance with them. Most of the gauges should still be working, though.

Here is something you might be able to use. It is adapted from RemoteTech, which is probably a better source. Basically if you go past 200m, you can start using the protovessel to get parts, and then revert to the real target when the target gets closer again. Not sure if its really what you need, but it might help. private void buildFromVessel(Vessel v) { vessel = v; if (v.loaded) //Treat vessels differently if loaded, or not loaded { foreach (Part p in v.parts) { foreach (PartModule m in p.Modules) { if (m.name.Equals("ModuleDockingNode")) { //Do your stuff here } } } } else { //Use protovessel stuff foreach (ProtoPartSnapshot p in v.protoVessel.protoPartSnapshots) { foreach (ProtoPartModuleSnapshot s in p.modules) { if (s.moduleName.Equals("ModuleDockingNode")) { ConfigNode n = new ConfigNode(); s.Save(n); try { string t = n.GetValue("type", 0); type = getType(t); } catch { //Error handling } //Do your stuff here } } } } }

I haven't done any work, or even investigation on how to do 3D gauges in KSP. For now, I will keep working on the current design. I also don't want to build an entire 3D cockpit, which would probably be required to fit all these gauges into a ship.

You can change the burn window setting in the advanced settings window. This will give you an alert at a specific time until Ap/Pe (by illuminating the B next to the appropriate readout). For more precision, you can use the HUD (always displays time to Ap/Pe above 10km). I'll look at fitting two times in the gauge, or perhaps time to next node (Ap, Pe, An, Dn).

New beta release! As promised in the stable release thread, here is the beta with full FPV, target, and maneuver node indicators in the HUD. Again, thanks to a.g. for his invaluable assistance. The main additions for this version are the vectors, an the ability to lock window positions so you don't drag them around accidentally. The FPV currently mimics the behavior of the NavBall's, so it changes from surface velocity to orbital velocity and target relative velocity when the NavBall does. The target and node markers do not look the same, however. The target indicator is a square, and anti-target is a square with most of an X drawn through it. The maneuver node indicator is a diamond, and the anti-maneuver node marker is a diamond with an X through it. The main limitation of the indicators for now is the rather limited field of view of the HUD. It is harder to stumble upon them than with the NavBall for now. In the stable release, however, I will have them clamped to the edge of the HUD so you can steer towards them. As usual, just unzip into your GameData directory. The download is here, and the file is SteamgaugesV1.3b1 (I think I've settled into something of a numbering scheme now, so ignore the fact that the last beta was 1.4).

Thanks CoriW! Due to some excellent input from a.g. you can all expect a new beta release soon, now with vectors! That being said, the next full version will probably be a little while still, as there are some more things I want to do (like clamp the pitch ladder so it doesn't rotate over the altitude/speed tapes, and the orbital reference mode).

New source code is posted, and position lock looks pretty solid. Look for it in the next release.

@Kalista: I should be able to put a drag lock in, yes. @a.g.: I'll have it up this afternoon.

Sorry. I can put it back up, but its been supplanted by stable 1.2 Yeah, my numbering system sucks.

Which version are you using? The latest version should have improved HUD readability. What resolution are you running, and have you scaled the gauges up larger? Also, a screen shot might help. In the next version, the Maneuver Node, Rendezvous, an Radar Altimeter gauges will auto-hide when not valid. This should help a bit with clutter. Turning off the bezels helps as well. I've generally tried to incorporate warning lights in gauges, but I'll consider a master panel.

Version 1.2 is now available from the spaceport. It has fixes for the radar altimeter, should run under Linux, and also the HUD! Although currently tailored towards spaceplane operations, it should also be useful for conventional rockets. More vectors and a vertical ascent mode are still in the pipes, but I thought you all would appreciate the various bug fixes as well.

I want you to be able to move part (most) of the window off screen if you want, but not all of it. So I'll probably use a buffer of like, 10 pixels so the left edge of the window can't go past width-10, and the left edge can't go past 10, etc. Thanks for the link a.g. and I'll see what I can do with those textures, now that I'm off for the day.

Right now I think I'll stick to a straight plugin, but thanks for the offer. I'll take a look at only enabling it in IVA, and add the option if it isn't that hard.

@SpaceK531: Absolutely. In your GameData\SteamGauges\Plugins\PluginData\SteamGauges folder there is a file called "config". You can either open it and manually put the gauges where you want (with xmin and ymin), or just delete the file and the plugin will rebuild it the next time you start KSP. Everything should be pretty safely in the upper left hand corner. I'll look into a screen size safety though, so people can't completely loose gauges off the screen. @a.g.: I was trying it from my original texture files, I'll try just editing the .png's after I get off work. I'll try that alpha8 conversion as well.

Pesky capitalized file changed. It does look like I can assign arbitrary colors to the texture elements using GUI.color. So eventually, expect fully customizable HUD colors (it'll be global to the whole HUD though, because anything else you might as well just repaint the darn textures yourselves). Unfortunately, I've only gotten it to work on textures that are a single layer of text. If I create a new layer from visible and run through the steps above, I end up with a pure green (or white) texture. Same with merging them all into a single texture first. Use of the Alpha8 format doesn't seem to be affecting it (visually) one way or another. Any thoughts on that?

Here is how I'm loading all my textures. I'm sure there's a better way. I'll try doing that in GIMP. Byte[] arrBytes; public static Texture2D Node_no_node = new Texture2D(width, height); arrBytes = KSP.IO.File.ReadAllBytes<SteamGauges>("Node_no_node.png"); Node_no_node.LoadImage(arrBytes); Thanks for all your help, I'm not too familiar with textures, or Unity for that matter.

Beta 1.4 is now available in the development thread, here. In addition to many HUD improvements, the radar altimeter now works over the ocean, it should run under LINUX, and there is an option to use KSP's calculated burn times for maneuver nodes.

Hmm, I'll play around in GIMP and see what I can do. Alternately, this is how I'm doing the Alpha blending currently: //Alpha blending Color tmpColor = GUI.color; GUI.color = new Color(1, 1, 1, SteamGauges.Alpha); //Alpha is the global alpha scale between 1 and 0.10 ... GUI.color = tmpColor; //reset Alpha blend Is there a better way to do this that would eliminate the issue?

New beta release! Lots of HUD improvements, as well as a few other fixes. The target relative velocity vector is in place, but no other vectors yet. Future improvements include orbital mode (forward velocity is North, and 0 degrees), vertical ascent mode (replaces pitch ladder at high attitudes). Also, the advanced settings window has been expanded because it was getting too big. As usual, feedback is appreciated.

I believe System.IO is now unlocked, so you can just go find it yourself if you want.