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?

Thank you for your hard work @TriggerAu

I see. Is the recommendation to just use AJE and not Firespitter or KAX? With Firespitter, KAX and AJE I have so many engines and AJE gives many of them the same name but the FS ones behave differently - It's all a bit of a mess. For any given use case I would love to be able to compare the stats of the engines and make a decision about which is most appropriate. Currently I need a bit of trial and error in sandbox to find a suitable engine.

Thanks for maintaining this mod guys. AJE/FS.cfg tries to edit @MODULE[ModuleEngines*] in Firespitter parts, but the Firespitter engine module is FSengine so the replacement obviously doesn't occur. Shouldn't @MODULE[ModuleEngines*] be replaced with @MODULE[FSengine] in the FS.cfg?

Maybe just LANDED then? I might have a play around this evening.

Might an alternative to the exclude option be to have some sequential objectives requiring that before you start moving, you have a pilot and engineer aboard and not the passenger? This is entirely untested and off the back of zero experience with contract configurator:

I just took the KerbalSpaceCentreOldKSCBusinessFlightContract contract and was confused when sitting on the runway with a pilot and an engineer, the "Has a flight engineer aboard" objective was not met. I looked in the config file and saw that the requirement is actually for 2 Engineers. Looking at the code that generates the contracts, I see that this line takes the requirement for 1 engineer and adds the number of engineer passengers to the minCrew requirement. I can understand that the "Has engineer" requirement should not be met by the passenger, but there must be better ways to achieve this that do not result in this unintuitive user experience.

I didn't know about CC's Alt+F10. It says the PartModuleUnlock requirement is not met. I'll investigate. Edit: I investigated.. The problem is FAR removing the ModuleControlSurface module and replacing it with FARControllableSurface. Solved with a MM patch: @CONTRACT_TYPE:HAS[@REQUIREMENT[PartModuleUnlocked]]:AFTER[ContractConfigurator] { @REQUIREMENT[PartModuleUnlocked]:HAS[#partModule[ModuleControlSurface]] { @partModule = FARControllableSurface } } Maybe change it to require either ModuleControlSurface or FARControllableSurface?

Does anyone know if Squad are continuing to work on wheels or are they satisfied with their current ridiculousness?

I'm not being offered the Glider contract. I have unlocked the seatExternalCmd and the R8winglet which has a ModuleControlSurface. I have no other contracts pending. I have completed: Join SSI Aerospace! Purchase command seat tech. Purchase electric vehicle tech. Purchase flight control tech. Purchase structural tech. I have CommunityTechTree and UnmannedBeforeManned which rearrange parts but looking at the contract cfg I can't see how that would matter so long as the required parts are unlocked. I have KerbinSide GAP but that just adds more contracts so I dont see a conflict there. Using ContractConfigurator I have all contract types turned off except for GAP. Any help would be appreciated.

Literally 4 posts up: The latest off github seems to be working fine for me.