Thanny

Calling 0.90 a Beta release is definitely pushing the bounds of the term past the breaking point. It's still an Alpha game.

I loaded up your save. You are 100% not in the zone. Fly a little further NE and you're in, where the temp scan completes the contract normally. There's a message on the screen that tells you when you're entering and leaving a scan zone. And you can click on the marker (on the map screen) to activate navigation towards it, so you're sure which direction to move. When zones do actually overlap, which seems to be rare, being in the overlap will complete both zones with a single scan. I had exactly one case where that was possible, and that's what happened. And for future reference, use four lander legs. I couldn't get that thing to stand up straight at all.

That card is slow enough to be put under heavy load during planetary scenes. While 80C sounds high, it's actually well within normal for a GPU under load with typical air cooling. It's also entirely safe for extended periods of time. With that card, you needn't start worrying until it's past 90 and on its way to the 100C max of the chip. That quote is perhaps my favorite from HGTTG.

It's a problem with the Unity engine scripting language and it's garbage collection (i.e. freeing up unused resources). Until they update to a version of Unity where this is fixed (assuming such a thing ever exists), this will be be a problem. Saving and returning from the main menu can often make it go away for a while. It tends to be the worst when working with very large craft, especially in the VAB/SPH. But simply playing for a while can also bring it on.

It's the Unity scripting language doing garbage collection, in an exceptionally poor manner. When it gets especially bad in the VAB, I save the ship, start a new ship, then reload, and it will go for a while without much skipping. It's really bad when it happens in flight, as events in the game continue during the pause, so you can be throttled up for a burn, have the screen freeze for a second, and suddenly be well past the point where you wanted to kill the throttle. So if it's happening before a burn, leave the game and come back, and it might be mitigated.

Something that's made this mod less easy to use since 0.90 is the fact that the context menus disappear after a click (or, when things are running slow due to high part counts, even before a click is made), which makes it difficult to start and stop a transfer in quick succession (such as when fine-tuning a transfer). It's also less convenient when trying to find the right tank. Previously, you could highlight to find the right tank, then start transferring. Now you lose the menu, so have to click the tank again to remove the highlight and then again to start the transfer. It's easy to lose that specific tank in the list when there are many present, too.

Previous versions of KSP supported Crossfire, but the current one does not, for whatever reason. In most situations, you will be CPU bound. At least until they update to a later version of Unity and physics goes multi-threaded.

It cannot be overstated how much faster the leak is with terrain scatter and low flying. Turn scatter off completely (requires restarting the game), and the leak will be slow enough that you can fly around the world several times before having to restart.

FYI, I've done a ladder like that and had it work. The trick is to rotate it away from the plane more, so that the ladder is closer to the same angle as the built-in steps, but still reaches the ground. The right angle is just enough to keep the body of the ladder assembly inside the fuselage (i.e. you can just barely not see it sticking out below).

The easiest solution is to edit the save file (it's all text) and change the altitude for that part of the contract. I found out the bit posted by Spheniscine the hard way - after putting up an orbiter below 6km to do temperature scans, it disappeared after colliding with invisible terrain.

I know on Gilly, the visible terrain doesn't match properly. If you set an orbit below 6km (the low orbit limit for doing temperature scans), you will visibly be well above all terrain, but it's only a matter of time before you find a note about colliding with terrain in the game log, and the ship goes away. I'd bet something similar is happening here on Pol. Probably any small world with very irregular terrain needs attention to make what's visible match with the collision geometry.

Probably the same bug that Jool has, where the atmosphere height variable has the wrong value in the place it looks to determine whether or not it's orbital or sub-orbital. Check the bug system to see that it's registered.

You have no mods installed?

Turn off terrain scatter if you're flying low for extended periods of time. There's a memory leak which is exacerbated by that, making the 32-bit version run out of RAM pretty fast, with or without any mods. Or, use Linux, as apparently the 64-bit version there works fine.

That mod uses very little memory. It just shows you information available with a program like Process Explorer on a HUD. The only benefit to the mod is if you have only one monitor, and can't watch process stats real time on a second screen. - - - Updated - - - It does seem to be related to terrain scatter. After disabling it and restarting, I no longer see uncontrolled memory usage when flying low.

Just got bit by this one doing a long recon mission, but only after going halfway around the world then turning north for a bit. With a mid-flight save, I can see the memory usage going from ~2GB on game load to ~2.5GB on save load, then steadily increasing during flight until the game crashes at ~3.5GB. With the 64-bit executable, memory usage follows the same pattern, and has so far increased to ~5GB. I'll have to finish these contracts in 64-bit, hoping it doesn't crash too often. There was no real difference between stock and modded (<10 mods), either.

Unity has a command line option for that, but it doesn't seem to work in KSP. It's "-adapter N", where N is the screen number starting with 0. It always goes to the primary monitor when I try it, whether set for fullscreen or borderless window ("-popupwindow" on the command line, which does work).

Is there a way to disable the free-floating text readouts on the flight screen?

Figured out why one of the ships was disappearing. There must be a huge disconnect between the visual model of Gilly in the game and it's dimensions used for calculating collisions. Despite being well above any of the apparent terrain, the log shows it colliding with the planet when switching ships. So you can't actually achieve stable low orbit of Gilly, since that figure (6km) is below the highest invisible terrain (apparently around 8km). Not sure why the Bop orbiter disappeared, since it was already above the highest recorded terrain, but I moved that to a higher orbit as well. I also found my Gilly base deleted, and can only assume the game though it collided, despite being landed. I'll just have to keep an eye on that one. There seems to be no way to land stably, as the planet keeps torquing underneath the lander.

When looking to complete a contract to return science data from orbit around Bop, I found that my Bop science orbiter had disappeared. It was in a stable orbit just below the low orbit limit (so temperature scans would work). I was able to restore it from an older save file by copying and pasting the vessel definition. I then checked to make sure no other ships had disappeared, and found that one had from around Gilly. Also a science orbiter (exact same ship design, in fact - ion drive probe weighing less than a tonne), also just below the low orbit limit. I had to go further back to find that one in a previous save, so that one disappeared first. Mods I have installed: Toolbar EditorExtensions EnhancedNavBall KerbalEngineer PreciseNode TacFuelBalancer KerbalAlarmClock TransferWindowPlanner Is this a known intermittent bug? Is there something in particular that would lead to the game removing a ship?

Gravity in KSP is 9.82m/s^2. You will get inaccurate results using 9.81 or (worse) 9.8066.

Just to add quickly, it's thrust / (Isp * 9.82) for fuel consumption. Got stuck in RPN-think, where the stack determines operator precedence.

Thought I already posted about this, but the forum ate it instead of posting (paid attention this time, and what looks like a confirmation page actually says it can't be posted due to some issue with a mysterious token - apparently I waited too long between typing and hitting the button). The burn time feature has the potential to be very useful, but unfortunately it's not accurate. I took a look at the source, and if I'm reading correctly, it's dividing the total delta V (of the total burn or the max the current stage allows - which is a very cool feature) by the average acceleration based on start and end masses. While that would be a better approximation than what the game does (which is equivalent to delta V divided by current acceleration), it's still the wrong answer. But I'm not even seeing those results in the game. For example, if I set up a node for a 2000m/s burn with a 284.395t ship using 20 nuke engines, KE shows a total burn time of 7m 54.0s, with a half burn time of 3m 57.0s. Applying the Tsiolkovsky rocket equation shows that the burn would actually result in a final mass of 220.474t. That makes the starting acceleration 1200 / 284.395 = 4.219m/s^2, and the ending acceleration 1200 / 220.474 = 5.443m/s^2, for an average of 4.831m/s^2. Using the logic I'm seeing in the source, that means it should be showing a total burn time of 2000 / 4.831 = 413.98s = 6m 53.98s. That's more than a minute off from what's showing in KE. The correct burn time, calculated from the rocket equation, is 418.47s, with half the delta V accomplished in 222.53s. I don't know where the source of the error is, but I do have a suggestion for improving the result regardless. Assuming a correct mass delta figure can be retrieved from the vessel simulation (i.e. end mass minus start mass, the difference being fuel burned), that can be divided by the fuel consumption rate of the engines to calculate the correct time. The consumption rate (by mass) is simply thrust / Isp * 9.82. It doesn't matter what fuel type it is, either, as specific impulse is related to the mass of the fuel. So in my example, 20 nuke engines have a thrust of 1200kN and a specific impulse of 800s, which means the consumption rate is 1200 / 800 * 9.82 = .15275t/sec. The mass delta for the example burn is 63.921t, which can be determined with a direct calculation (mass - mass * exp(-dV / (Isp * 9.82))) or a simulation (I wrote one into my burn time calculator, as a sanity check, that updates every millisecond and gets the same answer), so presumably the vessel simulator in KE will expose that information somewhere. Total time is then 63.921 / .15275 = 418.47s.

I had that happen to me recently, after I tried to do a temp measurement while being too high. The option just disappeared until I reloaded the ship. It seems to be a known bug, so will presumably be fixed at some point.

It's all about mass and speed. See my last post here. So assuming the drop of a space plane at launch is consistent, it reduces to mass, since the speed would be the same. By my estimate, it would take a drop speed of about 1.5m/s to make that 375t plane blow up the runway.