Jacke

Aviation Lights on both craft and Illuminators Mk 1 on the active craft help those darkness dockings. And then there's Ambient Light Adjustment as well.

Don't rant. Understand first. Aircraft and ships uses altitude in feet and ranges in nautical miles because that's the international convention that all nations, pilots, and traffic control work on. It will be the last use of non-metric units because it will be the hardest to change without mishap. Like what happened in World War 2 in the Pacific theatre when the United States Navy used nautical miles and the United States Army Air Force used statute miles. And U.S.A.A.F. aircraft were sent on a mission given data in nautical miles and compared that to their aircraft loaded radius of action in statute miles and thought it would work and it didn't and air crews died. Which lead to all air forces and then civilian pilots standardizing on nautical miles. Altitude in feet got included. All operating systems now can run in 64-bit mode. But a lot of the software is still 32-bit. Which is why all 64-bit operating systems have robust ways of running 32-bit code. I'm typing this post into the latest Firefox. Firefox on Windows is still 32-bit code, even though the OS is 64-bit, because that's the compiled versions supplied by Mozilla. Under Linux, Firefox can be 64-bit. And then I have other hoops to jump through because other stuff that runs in the browser is still 32-bit. My OS right now is Windows 8.1 64-bit. But I run the KSP 32-bit executable because under Windows Unity 64-bit and KSP 64-bit are full of bugs. Game-breaking bugs. Squad called Windows KSP 64-bit experimental and says it got worse in KSP 0.25. Just because you've run Windows KSP 64-bit without issue for a while doesn't change that. And doesn't change the fact that you will likely hit one of those bugs. And you add in the number of players who play any mod and they will have issues with KSP 64-bit. Which they demand the mod writer fix. Even though it's impossible. Because they don't know and don't care to figure out. And thus a lot of mod writers are sick of this crap and now have their mods refuse to run under Windows KSP 64-bit. Because it's experimental. That won't change until Windows KSP 64-bit improves.

Reentries with current DR are now more like real-life ones. A highly simplified calculation in an aerospace book I read showed that successful reentries start with an approach velocity less that 1 degree from horizontal. In KSP with DR 6.1+ I found reentries from both LKO and returning from Mun needed periapsis no lower than 30km or the craft burned up.

Squad says running KSP 64-bit on Windows is experimental and has more issues under 0.25 than it did under 0.24. There are a large number of bugs in Unity 64-bit and KSP 64-bit on Windows. Because of all the crap mod builders received about bugs beyond there control under KSP 0.24, many have decided to have their mods disable themselves under KSP 64-bit on Windows and say so.

Putting MM files under Squad's directories in GameData ("GameData/Squad/" , "GameData/NASAMission") is a bad idea, as those should just be Squad's files. I created a SPP directory under RPM's tree ("GameData/JSI/RPMPodPatches/SPP/") as they are just another RPM MM patch like the others there.

To continue your automobile example, it's Squad's problem, as Squad claims KSP has a multi-fueler engine as far as image formats are concerned, but actually has problems running with TGA format fuel. From NathanKell's article: TGA's have been used by Squad in the GameData/NASAMission/ tree and many mods, as a search for "*.tga" in GameData/ will find. To continue the car example, Squad's driving and they've pranged the front-right rocker panel--*again*! I don't think it was metl who said this, but someone else referred to KSP 64-bit. AFAIK, most mods now will only support KSP 64-bit on Linux, as Windows Unity 64-bit and Windows KSP 64-bit are full of bugs. Even Squad says KSP 64-bit on Windows is experimental and has gotten worse in KSP 0.25. I have Windows 64-bit but I run KSP 32-bit just to avoid that crap.

Sarbian, I have a few requests. Would it be possible to get entries in Custom Window Editor for these? 1. Target ASL, under Target, like the line displayed in Landing Guidance. 2. Target coordinate boxes, under Target, which show the Target coordinate in a series of boxes, allowing editing, like displayed in Landing Guidance. 3. Clear position target, a button under Target, which removes the position target. EDIT: Better, add it to "Pick position target" as a small button on the right end of that. And in Landing Guidance, could an entry for general Autostage be added, similar to the one in Ascent Guidance?

I think a MM config to change defaults would be a good idea. I used to use pressure 0.2 for semi-deploy, about 8000m, as I didn't realise parachutes would full-deploy straight from armed. On some reentries that lead to parachute loss due to speed still being too high. Thus the shift to using 0.5. Here's what pressures would have to be set for every body with an atmosphere (Kerbin, Eve, Duna, Laythe, and Jool) to get 7000m and 3000m semi-deployment. They are very different for the 5 bodies. For Eve and Jool, they can't be set in the VAB and I suspect they aren't the best ones for them. Body Scale Ht (m) 0m Pres (atm) 3000m Pres (atm) 7000m Pres (atm) Kerbin 5000 1 0.55 0.25 Eve 7000 5 3.26 1.84 Duna 3000 0.2 0.07 0.02 Laythe 4000 0.8 0.38 0.14 Jool 10000 15 11.11 7.45 With stock parachutes, they have an altitude setting for full deployment which can be set in the VAB to 50m, 300-4750m in steps of 50m, and 5000m. But a pressure setting for semi deployment which can be set in the VAB to 0.01-0.47atm in steps of 0.01atm, and 0.50atm. Defaults are 500m and 0.01atm, except for Mk25 drogue parachutes which have 2500m and 0.007atm set (which isn't available in the VAB).

Ever since I upgraded to DR 6.2+, to avoid supersonic deployment on Kerbin landings I've learned to set my stock parachutes to pressure setting 0.5 atmosphere (the maximum) which means they semi-deploy about 3500m (formula '-5000m * ln pressure in atmosphere' from reversing the pressure formula in the wiki). If the spacecraft comes down on higher altitude land, at the full-deploy altitude (set to default 500m) they full-deploy straight from armed. Haven't lost a spacecraft yet from the opening shock but you can't have everything. Multiple parachutes with slightly different full-deploy altitudes could deal with that.

Here's my current RPM install procedure. Just added the SPP patches by nli2work and have yet to check them out:

It's code this and a few other mods included to warn about a version change in KSP. For a number of them, they still work and you can just close that window at the start. From the mods I have, there's just this one and Notepad that still haven't been updated. And both are working okay.

It won't fly because you let out the magic smoke? Can't fly without the magic smoke inside.

Well, the current version 7-4 with Astronomer's Visual Pack is working under KSP 0.25 for me (Windows x64 running 32-bit KSP). Maybe missing some elements but most of its there.

I don't think something like that is in MechJeb (although I'm not fully versed on all the many extra functions in MechJeb). However, sarbian has another mod, Gimble Auto Trim, that might work for you.

I've been playing with Deadly Reentry 6.1 for a while with Kerbin reentries. It's working for me, but it's much deadlier than in version 5.2 and wonderfully so. You have to reenter much more shallowly, with a higher periapsis--or pack a whole lot of delta-V to slow down to well under orbital speeds before getting too deep, or your spacecraft will be destroyed by reentry heating. And you can't deploy your parachutes when the airstream is too hot or they will be destroyed, which will show up as them being cut (parachute icon in staging goes red). With a bit of testing I figured it out.

Starwaster, don't you think you should have changed the version number? Anyhoo, finally getting the hang of Kerbin reentry with DR 6.1. Had to change the pressure my parachutes semi-deploy at so it's a lower altitude and thus airspeed else they get burned away. Cool!

Sorry about not getting the output_log.txt. I usually provide it but forgot to save it after this one. I don't think I was dragging the TAC Fuel Balancer window at the time I hit ESC. Looking back at screenshots I took during the flight, I see that little 16x16 pixel element show up in the upper left; on one screenshot, it's not there, then on the next and subsequent ones, it is. Looks like the window resizing element. If it happens again, I'll grab the output_log.txt.

Does this work under KSP 0.24.2 (32-bit of course)? Understandable if you haven't tested that. I'm not moving to 0.25 until most of the important mods (including BTSM) have all successfully upgraded.

Do you think these still work with KSP v0.24.2? Understandable if you haven't tested that. I'm not moving to 0.25 until most of the important mods (including BTSM) have all successfully upgraded.

I don't have the USI Survivability Pack. But otherwise AGExt appears to be working okay. Thanks, Diazo!

I ran into a simple bug that prevented me from using TAC Fuel Balancer until I could get at its config file, "GameData/ThunderAerospace/TacFuelBalancer/PluginData/TacFuelBalancer/FuelBalancer.cfg". During a flight where I had the window open to balance, instead of clicking on its x upper right or the icon on Blizzy's toolbar, I hit the key ESC. TAC Fuel Balancer Window went away. And I couldn't get it back, during that flight or another, or when I exited and restarted KSP. During that flight where I hit ESC, the Fuel Balancer continued to operate. So I pulled out the files for the mod and found its config file. Removed that, reinstalled the mod, and started KSP again. Went to a flight and now I had the TAC Fuel Balancer window again. Couldn't recreate the problem, as now when I hit ESC, the Game Paused menu comes up. Now I'm doubting what happened to make it go away in the first place. Here's what my FuelBalancer.cfg file had: MaxFuelFlow = 10 RateMultiplier = 1 FuelWarningLevel = 25 FuelCriticalLevel = 5 ShowStageNumber = True ShowMaxAmount = True ShowCurrentAmount = True ShowPercentFull = True ShowDump = True BalanceIn = False BalanceOut = False Debug = False TACFuelBalancer { visible = True x = -572 y = -729 width = 588 height = 745 } TACFuelBalancerSettings { visible = False x = 840 y = 360 width = 240 height = 360 } TACFuelBalancerHelp { visible = False x = 710 y = 135 width = 500 height = 810 }

I've had a similar case of a mission miscount, but I was fortunate it happened early, so I can give details (and provide savegame backups with the FF files if requested) I also play with a lot of mods, including MechJeb2. And I play BTSM career. Jebediah Kerman had flown 3 missions, but it was reporting it as 2. I looked back over the screenshots I had. 1: In atmosphere rocket flight. Landed by parachute on top of the VAB. Jeb went EVA and couldn't reach the hatch. First the rocket and the Jeb were recovered at the Tracking Centre. FF log shows a complete mission. 2: Another in atmosphere rocket flight. Landed by parachute near KSC. Jeb went EVA and couldn't reach the hatch again. First the rocket and the Jeb were recovered at the Tracking Centre. FF log shows a complete mission. 3. A suborbital flight. Landed by parachute up in the highlands west of KSC. Jeb went EVA but this time could get back into the Mk1. Spacecraft was recovered at the Tracking Centre. FF log shows a complete mission. This is when I noticed that Jeb's mission count was 2 instead of the 3 it should be. Looking at the log now, it's missiong the entry "Jebediah Kerman has returned from a mission" for the 1st mission. Looking at the screenshots for that mission, I see that entry which is now missing. Unfortunately, the screenshots for the 2nd mission don't show the log entries for the 1st mission, so I don't know if that missing entry was there or not at that time.

When you are in an IVA scene and you type F1 to get a screenshot, not only do you get the screenshotN.png of the whole view, each RPM monitor display is saved as a separate file. View your screenshots sorted by date to see the whole screenshotN.png files next to the related monitor*.png files.

This improves the calculation of the transfer orbit injection maneuver node, but you will still likely need a course correction. I imagine MechJeb2 still isn't doing a power-track calculation, that is calculating the accelerated track under thrust on your spacecraft flying the node. It's still likely assuming the maneuver is a point impulse to change the orbit. So, as usual, check to see if you need a course correction after every long burn and SoI change.