mic_e

Just a matter of changing one number in the source code. I'll see if I maybe can put that into a config file. In the meanwhile, use this dll file: http://pub.sft.mx/NavBallDockingAlignmentIndicator1black.dll (delete the old one)

Sorry, I, too, like numbers a lot, but most posters here seem to be quite happy with the stock feeling, so I don't want to change that. Also, I have no idea how to draw numbers there It might be a better solution to draw an additional target velocity indicator, one that ignores forward-/backward motion, or just assumes a forward motion of 1. However, to keep in line with harv, I think additional markers/information might just confuse a lot of people and in the end make the mod a lot less useful. Anyways, if someone would send a working pull-request for a feature like that, I'd gladly accept it and add it as a (non-default) config option.

I've just released a new version of the mod, compiled for 0.23. There were no actual source code changes neccesary, the old DLL might even continue working. Anyways, the ZIP folder structure has been slightly changed, to be more like all the other mods. Also, the readme file now has a .txt extension Make sure that you overwrite or manually remove the old version of the mod when installing the new one, or else, there might be Unforeseen Consequences.

Enhanced Navball by default does not display Normal/Radial indicators when in target mode. Note that in target mode, it does not display your orbital velocity, but the difference of your and your target's velocities. If you stand almost still relative to your target, the (pro-/retro)grade indicators will start to shake, or even disappear.I don't believe the Navball docking alignment indicator has anything to do with this.

yay waiting is fun!

Seing how the scale height on eve is greater, and orbital speeds are not that much higher, using a bigger heat shield should definitely suffice. The important thing about reentry is to bleed off as much speed as possible before entering the denser atmosphere, so aim for a ~50km periapsis, and use a high-drag design (if you're using FAR, just use a BIG heatshield or otherwise big surface area (high ratio between mass and drag per dynamic pressure) and, as a bonus, design your ship so that it creates a little lift during entry. If you're in the stock game, you'll just have to hope for the best (but at least your ship won't suddendly turn and explode violently if you designed it aerodynamically unstable). I have survived 6km/s entries at Kerbin with DRE, by attaching a 2.5m heatshield to a 600kg lander can.

So, world space is the camera coordinate system, right? I failed to mention in my original post that I already DO have code to determine longitude, latitude and altitude for a specific timepoint, which might simplify the problem a lot. So a way to convert from long/lat/alt to a PQS vector would be OK, too... Currently, I'm having the impression that the PQS system (= world system?) does not rotate with the result of the Ray casting method would vary with the time when it is called...

Thank you for your reply! I'm talking about the future where the vessel simply follows its normal orbit (no atmospheric or engine acceleration). One of the main problems I'm seeing here is that the body will of course rotate, so I assume I'd require additional transformations...

Hi, what methods and transformations are required to calculate the vessel position in PQS coordinates (those that are accepted by the pqsController.RayIntersection method)? What if I am looking for the position at some point (in seconds) in the future? Unfortunately, the best 'documentation' I seem to find on this topic are the method names in the Vessel/CelestialBody/PQS APIs...

Awesome mod. Has anybody tried this with FAR/Ferram Aerospace?

Nice series; you are an awesome writer.

NathanKell: I didn't think i'd reach _You_ with this post, but thanks for replying. I wasn't actually awaere of the new DREC version; I just downloaded what google suggested. Unfortunately, the new version does not seem to fix the stability problem. IMHO, this is a pretty massive gameplay issue; the only designs where the 6.25m shield is currently any use are extremely unrealistic ones (shields on both ends of the craft, delta-wings 20 meters behind the craft, ...) Most ships (such as the normal command pods) have two stable orientations, prograde and retrograde, with at least a 5 degree AOA stability range (i.e., as long as I keep the AOA lower than 5 degrees, it automatically rotates back to the stable position). None of my realistic 6.25m ships had _any_ stability range whatsoever. IMHO, the slightly conic shape of the 6.25m shield should cause a certain pitch and yaw stability, just as it works with all the command pods and other shields. Is there any difference in the implementation?

Limiting entry velocity sounds great, but there is only so much you can do when attempting to aerocapture at Kerbin or Jool... For realism reasons, I don't wann deploy my Drouge chutes above Mach 2, even though I know that they won't burn up below ~2km/s.

Going in nose-first is pretty much a no-go with DRE, as is changing drag values with FAR. Drogue chutes will burn up at hypersonic speeds, so I'm pretty much out of options... except positioning the COM as close as possible to the COD. The main problem appears to be that FAR does not notice the growth rate of the heat shield on inflation.

Eve. Aimed for a periapse of 30km. Poor Bob was stranded there for 11 years. After that I wrote my atmospheric entry simulation code

Hi, so I recently decided to go all the way for realism, with Ferram and Deadly Reentry (this one). I've tried to design a (complex) lander capable of landing on Kerbin from orbit, using the 6.25m Inflatable Heatshield. However, the design becomes violently unstable at any significant dynamic pressure levels, as high as 50km, and will always turn in the wrong direction (the heatshield will act as a parachute, not a shield...). Only the most unrealistic, extreme modifications to the craft were capable of stabilizing it in its retrograde orientation (e.g.: A set of four delta-wings mounted tens of meters above the craft). Are there any general guidelines on how to design a stable atmospheric entry vehicle in FAR, especially with the inflatable heat shield?

Thanks! Yeah, I really owe him. I guess he spent a weekend of blood, sweat and tears brute-forcing the transformations and layer till he had the first correct marker on his navball...

But... that makes the game easier! Nooooooooooooooooo!

Thanks, I'll include it in the main post. What's the facial hair mod?

That's what I am experiencing. I'm getting a typeloadexception when trying to create the scripting engine object, and that's it...

I just find python to be a whole lot more sexy.

Those mountains on Earthbin must surely be awesome... highest point would be 71869m by my calculations

Has anybody ever successfuly started a IronPython interpreter from inside a mod? Or anything that comes with its own DLL file?

Would any of you guys be interested in making a short youtube video on how to use the mod, which I could feature in my post?

It's here: http://forum.kerbalspaceprogram.com/threads/54303-0-22-Navball-docking-alignment-indicator Actually, you don't need to place the DLL in any kind of subfolder, just put it into Plugins or GameData.