Trueborn

I'm wondering if anyone has a better way to check and see if RCS and SAS are active on the current vessel? I'm using this for now: //SAS flag if (FlightInputHandler.state.killRot) GUI.DrawTextureWithTexCoords(new Rect(720 * Scale, 11 * Scale, 88 * Scale, 31 * Scale), Resources.HUD_singles, new Rect(0.3464f, 0.5833f, 0.2162f, 0.3229f)); //RCS flag if (!FlightInputHandler.RCSLock) GUI.DrawTextureWithTexCoords(new Rect(255 * Scale, 11 * Scale, 86 * Scale, 31 * Scale), Resources.HUD_singles, new Rect(0.1220f, 0.5833f, 0.2113f, 0.3229f)); And it works great, except that if the vessel loads with SAS or RCS on, then I get true when toggled off instead of on. In effect, they are reversed. Nothing else that I've looked at seems to be any more reliable (and most are worse). Thanks.

Great stuff! Keep up the good work NavyFish.

Good point numerobis.

This is how I do it. Like Faark said, just iterating through all the parts and looking at the electrical charge in it. double electricCharge = 0; double electricMax = 0; Vessel active = FlightGlobals.ActiveVessel; foreach (Part p in active.parts) { if (p.Resources.Contains("ElectricCharge")) { foreach (PartResource pr in p.Resources) { if (pr.resourceName.Equals("ElectricCharge")) { electricCharge += pr.amount; electricMax += pr.maxAmount; break; } } } }

Yeah, I'll take a look at some other fonts, I'm not entirely pleased with this one either. And yes, vectors are coming soon

The markers will come first, but that sounds very interesting. From some brief research, that mode would essentially display (0, 0, 0) (pitch, yaw, roll) as the prograde vector? Thus, to burn prograde you just burn at (0, 0, 0), and retrograde would be (0, 180, 0). To increase inclination (0, 90, 0), etch. That sound about right?

Its inaccurate when flying over the ocean. Or rather, its too accurate. It reads the distance to the terrain, which is the bottom of the sea. It should be fixed in the next release.

You could always do it the old fashioned way and build a font texture and use DrawTextureWithCoords... Other than that I'm not sure. Maybe look at some Unity stuff to see if it supports ttf

Licensed under Attribution-NonCommercial-ShareAlike 3.0 Unported, and updated on the first page. Also for you m4v, the latest beta should load under Linux now. If I don't get the final version nailed down in the next few days, I'll release an update to the stable version with that fix (as well as a couple others).

Watch this video, and the 6 after it. They are a great start on getting a working mod up and running in visual studio. Should be transferable to another IDE as well.

There is a new beta release available in the beta thread. Version 1.3b features much improved HUD functionality, as well as bug fixes for a couple things mentioned above. Enjoy!

New beta version is available! Much improved HUD functionality, as well as a couple of bug fixes. The biggest improvements are airspeed and altitude tapes, and additional information positioned around the HUD. There are three new options in the advanced menu. You can disable pitch ladder rotation (good for some external views), turn off the smaller, interior airspeed/altitude readouts, and disable the external information. Downloads are on the first page. Next up should be the various markers like prograde, target, etc.

My first guess would be either when reaching orbital velocity, or outside the atmosphere. Either of those is easily done in code. Vector3 FlightUIController.fetch.GetComponentInChildren<NavBall>().displayVelocity will probably get you the currently displayed velocity off the NavBall, so you could check against that. Hope some of this gets you in the right direction.

@ymir9: Not an analog one, no. I think the built in version is sufficient. The next version will have a G meter integrated in one gauge though. @m4v: Thanks. I've been trying to keep things consistent, but I guess I missed those. Fixed for the next version. Also, I'm looking at another method of getting burn times. I'm also expecting another beta release in the next day or two, which I think you guys will enjoy.

@Raelsmar: There is a throttle indicator on the Maneuver Node gauge (blue arrow along the left).

@SDIR: I know about that issue, and it should be fixed in the next release. @dlrk: See the beta thread.

I may release a standalone HUD if it gets complex enough, but you can just turn off all the gauges you don't want. And while auto-centering is nice in theory, I would like it to work in a wide variety of IVAs as well, so it needs to be freely movable and scalable to fit in whatever space people have. The HUD is actually quite a bit wider than the outputs you're seeing now, so if I don't use all that extra horizontal space the window will get a bit smaller, so you shouldn't be dragging it around as much on accident.

I've finally started work on a HUD, and I've got everything I need except for one thing. I can't for the life of me get any useful information about where the prograde vector (or any other navball marker) is. I've been using the FlightUIController's NavBall as the source for pitch and roll, which come out of a Quaternion called relativeGymbal. I can just extract the Euler angles to get pitch, roll, and yaw. Works great. Then there are Transforms for progradeVector, progradeWaypoint, and target. Unfortunately I can't seem to do anything with them. I would think I would do progradeTransform.rotation and be able to use that directly, or use something like Quaternion.Angle(vesselRot, ball.progradeVector.rotation) to get at least an angle between them, but I can't seem to work out a combination that provides useful data. Ideally, I want to get the pitch and yaw (x and y Euler angles) for the progradeVector. Does anyone have any recommendations? Thanks for your help.

New beta version 1.2b available! There is a new beta, and really preview, version of SteamGauges available now. As usual, it can be downloaded at http://sdrv.ms/12Bv7AN So, the new gauge is...a HUD! I know this totally goes against the theme of rest of the mod, but I think its pretty slick none the less. This is a work in progress just demonstrating the proof of concept so far. I'll be adding airspeed and altitude tapes, fixing the compass and more before release. I was hoping to get a little feedback on how people might like to use this. It is based off my experience with aircraft HUDs, and makes the most sense from a horizontal frame of reference. Besides simply replicating the NAVBALL (which isn't so simple without a 3d model, which I'm not currently doing), what do you think would be useful for vertical flight?

The are just windows that you can drag around the screen. They work just find in any flight mode, including IVA. @Creideiki: I've recently been playing around with some NavBall stuff, but can't promise anything yet.

Sorry for the delay, but I was out of continent the last few days. The 0.21 compatible version of SteamGauges is now available from http://kerbalspaceprogram.com/steamgauges/. No real changes, just recompiled with the new DLLs. Please let me know if you experience any other 0.21 related issues so I can track them down.

This series of tutorials got me started. After you get through those, just go pick a mod that seems fairly simple and look at some of the source code to see how it does different things. Just remember to credit those whose shoulders you are standing on!

Version 1.1 is now available! Up on spaceport and the alternate download link in the first post. Version 1.1 Highlights: New Gauge! The Maneuver Node Gauge is now here, so you can make all your burns in style. It features at Delta V readout, time to burn, burn time, %dV remaining, and %Throttle as well. The GUI windows should resize a bit better, as well as look just a touch nicer. The larger, square bezels can now be toggled from the main window for a more compact look.

Thanks, the physicalSignificance got me the right mass. That certainly helps some. Playing around with 9.816 vs 9.82 vs 9.81 I can get kind of close, but nothing there seems to be spot on. I'll try rounding some values I guess...

I've been working on my Maneuver Node gauge for SteamGauges, and I'm having some trouble calculating how much time the burn will take. If anyone has any insights why neither the full Rocket Equation version or a simple f=m*a calculation aren't giving me good results, I would appreciate it. deltaV = myNode.DeltaV.magnitude; //The burn's ÃŽâ€V deltaVRem = myNode.GetBurnVector(FlightGlobals.ActiveVessel.orbit).magnitude; //Remaining ÃŽâ€V in the burn res r = calculateThrust(FlightGlobals.ActiveVessel); //Actually calculates thrust, mass, and Isp double mass = r.mass / Math.Pow(Math.E, (deltaVRem / r.isp)); //Mass after burn double rate = r.thrust / (r.isp*9.81); //Mass flow rate double burnTime = (r.mass - mass)/rate; //Mass to burn over rate should give time, but doesn't //Try the f = m*a method for time computation... double t2 = deltaVRem / (r.thrust / ((r.mass+mass)/2)); //Use average mass to get closer? I'm using a custom function that just runs through each part and get's its .mass and .GetResourceMass(), and then thrust and Isp for active engines. The latter two are spot on, but my mass is always slightly off from, say, Kerbal Engineer. Thanks for the help guys!