OminousPenguin

Hi all, I like playing with Planetshine and no ambient light, but this does make the dark side of planets and moons entirely dark. I can't remember what they look like stock but I assume they're still pretty dark. Some modern flight HUDs have synthetic terrain overlay enabling the pilot to see where the ground is, I assume using radar but conceivably using a hightmap and the fact the plane knows it's exact position. Here's an example: So here's what I'd love to see in KSP: An 80's retro/Kerbal style wireframe view of the terrain of whatever planet/moon I'm on/orbiting, entirely independent of local lighting conditions. Ideally automatically enabled where the terrain illumination is bellow a certain threshold, but a simple toggle on and off would suffice. If SCANsat is installed, have the wireframe based on altimetry data from SCANsat Wireframe only available for areas of the terrain where you have scanned altimetry data Low resolution altimetry means your wireframe terrain won't show small lumps/bumps/boulders = plenty of opportunity for disaster fun and not just a 'god mode night vision' So what do you think? Is this feasible? Is it something you'd be interested in? Perhaps a terrain shader would be a reasonable way to implement this? Looking forward to reading your thoughts.

Thanks @Nertea! Any chance of backporting the latest updates for 1.7.3? I'm holding off updating to 1.8 because a few of my must-have mods are yet to be updated.

Love the mod @Gotmachine! Thanks for your hard work. On smaller vessels I find myself missing a four-way micro RCS block, i.e. a micro equivalent of the RV-105, or following the naming of your other parts, a part that would be named 025T_2xlateral_1xup_1xdown. Is there a reason this part was omitted? On some craft it makes sense to have one set of RM-025-IL at one end of the vessel, and another set rotated 180° at the other end. However for smaller probes I'd prefer to just have a set of four-way RM-025 around the COM. Hope this makes sense. Thanks!

Just installed this as I've been using external tools for this sort of thing, but I feel like I must be missing something - The slider for Body Orbital Height does not allow for accurate input: Far left is 1km, next value is 80km, next is 619Mm... A box into which a number could be typed would be great!

Hi all. I'm wanting to set an exact orientation and rotation so that it doesn't drift over time. I had a look at the save files but after a bit of futile experimentation with the rotation quaternion and direction vector I gave up. Anyone got any suggestions for this sort of thing? Thanks

@Phineas Freak recompiled for 1.6.1 on March 25th (thanks). If you could tag it and create a release that'd be great as I think CKAN would pick up on that automatically. https://github.com/KSP-RO/RealHeat/commits/master Hopefully just a recompile is needed for 1.7.1 as well.

I've been searching around and looking at the krpc source and I can't work out how to get the result of an expression: dynamic_pressure = conn.get_call(getattr, vessel.flight(), 'dynamic_pressure') velocity = conn.get_call(getattr, vessel.flight(), 'true_air_speed') heatflux = conn.krpc.Expression.multiply( conn.krpc.Expression.call(dynamic_pressure), conn.krpc.Expression.call(velocity) ) If someone can tell me how to get the result of the heatflux expression that'd be great. Thanks.

Just a note for those looking for a build of this for 1.3.1: https://github.com/Ni2Be/ImprovedChaseCamera-by-BahamutoD/releases/tag/Chase_Cam_v1_3

Found this mod last night and wow. Thank you @The White Guardian!

Yes. As @linuxgurugamer said, his build is specifically for 1.2.2.

Working perfectly for me. Thank you!

I've been checking this thread occasionally to see if anyone had been kind enough to recompile & fix for 1.2.2. Thank you @linuxgurugamer - I'll try it out tonight.

I think the cleanest solution to this problem is to have a short (configurable) delay (about 1 second) after changing the value before it takes effect. eg. The course reads 195. You want to change it to 210. 1. You clear the 195 and press the '2' key. 2. Internally, the mod starts a 1 second countdown. The mod still behaves as though the course is still 195. 3. Less than 1 second later you hit the '1' key. 4. The mod restarts the 1.5 second countdown. The mod still behaves as though the course is still 195. 5. Less than 1 second later you hit the '0' key. 6. The mod restarts the 1 second countdown. The mod still behaves as though the course is still 195. 7. After 1 second, you haven't changed the value any more and new value of 210 takes effect. This solution means no change to the GUI and no change to how users interact with the mod, it just means the mod doesn't try changing course to '2' and then '21' before you finish typing '210'.

If FuelWings is compatible with RealFuels, then in CKAN FuelWings should require ModularFuelTanks OR RealFuels. This would involve asking both @taniwha and @NathanKell to both add something like "provides" : [ "ModularFuelSystem" ] to their netkan files and then having FuelWings require "ModularFuelSystem". The user would then be asked to choose to install either ModularFuelTanks OR RealFuels. (Currently RealFuels conflicts with "ModularFuelSystem" although I can't see any mod that actually has that name. (Doesn't look like the old Modular Fuel System is in CKAN)) Unrelated, @Tortoise. Is there a reason you didn't add tanks to airplaneTail and airplaneTailB?