Murph

As said above, it depends on your experience. Top 10 easily, if you restrict it to current games. If, like me, you remember a time when processors were 1–2MHz, RAM was in low kB, disk was in kB, colour displays were a premium upgrade, and some upgrades involved a soldering iron, then it's much harder to quantify. Edit: It's not a perfect or best metric, but factually it's currently ranked #7 of all games on Steam, sorted by user reviews. 98% positive reviews. That's a HUGE achievement for a relatively tiny developer on their first big project.

Is part of the same craft as the lab, or docked with it? If neither, you'll need to transfer the experiment result over to the lab craft by EVA. Since you're describing a lab in orbit of Kerbin, but a report from Minimus, it sounds almost like you're expecting it to receive reports remotely. It doesn't work like that, you'll need to do an orbital rendezvous and dock or EVA to get the report to the lab.

Soonâ„¢

Read the contract again, and triple-check all the parameters. You shouldn't even need fuel for an engine test on the pad. A simple 2 part craft of the Stayputnik or starter pod on top of the engine should be sufficient. Once on the pad, check the contracts mini panel thing, to see what is ticked and what is not ticked. And, make sure you've not run out of battery for probe cores. The island is irrelevant. Other than that, you'll need to give us the exact criteria from the contract. Do you have any mods installed? Which ones, and their versions?

The part count limit really doesn't bother me. It makes sense in as much as a practical mechanic to limit you to low complexity craft until you upgrade, which absolutely is a valid thing to tie into the upgrade system. Pushing you towards doing a lot with a little is a very good thing for learning the game. The one that doesn't make any sense to me is the action groups not being available until level 3. That just feels very forced and fake, adding something to the system because they felt they had to add something and not because it made good sense to do so. Level 2's part limit should be much lower, as it's effectively unlimited at 255, at least for early contract missions, and action groups should be completely removed from the upgrade system (and not replaced with anything unless something can be found which actually does make sense).

It's not impossible to do something else, like establish on a higher orbit first, but alternatives may well take even longer in game days. Just wait on the Mun getting out of the way, it's far easier to do that, and shouldn't take that long.

In a word, no. Also, don't try to be clever and try to clip a normal port into the middle of a large port, it doesn't work. You just need to design docking nodes that have both sizes.

That sounds like an excellent suggestion. The processing time shouldn't really be a huge concern, as it's not something that needs to be constantly recalculated. It gets updated when we scan a new biome, but is static apart from that. Right now, even if the system is definitely using the same data for the 3 presentations, and technically operating correctly, the visual result has a significant problem. There is a large significant difference between the styles which gives the appearance of working from a significantly different data set. The difference is visible over the entire sphere, not just the poles  I've seen big changes in the 0–30°.latitude band as well. Small variations, not a problem, that just serves to emphasise that it's not high precision data, particularly if the variation is mostly around the edges of hot spots, not entire hot spots moving significantly. Big variations, that leads to confusion and people thinking it's useless or broken, not knowing which version to trust. Right now, it's big variations.

It's really not a big problem, I wouldn't care if it never got fixed. On normal difficulty, I really don't need the cash from recovering spent stages, and I don't want complexity added around them to generate lag for the active vessel. I'm also against having lots of spent stages laying around on Kerbin splashed/landed, as I think it would add nothing of value to the game to have to clean up more trash after launches. If anything is to change, it should be limited to an extremely simple and quick recovery mechanic, without any full physics simulation. Just a trivial yes/no for sufficient parachutes based on mass alone, then immediately recover, no complex physics.

The game already does that to an extent, but it requires the user to take the prudent step of manually saving every once in a while (e.g. after every significant change). Right now, you have persistent.sfs automatically managed, quicksave.sfs manually (but extremely easy and conveniently) managed, and unlimited named saves (default "quicksave #number.sfs") manually managed from the Esc menu at the KSC screen. I do not agree with having many levels of automatic backup for persistent.sfs, but do agree that it would be a simple enhancement to preserve the immediately previous version. It doesn't need to be as complex as your suggestion, as a move/rename is a safe "atomic" (100% success, or 100% fail, no halfway points leaving inconsistency) operation on all 3 operating systems supported by KSP. Just rename the current persistent.sfs to persistent.sfs.bak, the OS semantics are that any failure there will leave the file untouched as its previous name (unless your filesystem is broken, in which case nothing an application does can guarantee or improve safety). I'm strongly against any unnecessary complexity related to persistent.sfs, as it is automatically saved frequently during game play. For example, copying it to a backup is orders of magnitude slower than renaming it; copying would double to triple the most time intensive part of saving. Additionally, if something with game or system state has created a situation which would be likely to corrupt the save, copying would make it very likely that you would also have a corrupted backup, where renaming does not touch the actual data blocks and is very unlikely to corrupt the file unless the filesystem is broken. If you're not frequently hitting F5 to quick save after significant operations in the game, you should be, and you really need to get into the habit of doing that, even if you don't believe in undoing player mistakes via quick load. Then, at the end of each session, or other points where you've made significant progress that you don't want to lose, you should be using the named save feature.

Or not. I've yet to see a single sign of any problem with them. No obvious unreasonable memory growth, no crashes whatsoever, despite long periods of flying mach 2–3 at 20km with plenty of heating and a number of the bars showing for long periods. That doesn't mean that the problem doesn't exist for some people, only that it doesn't seem to hit everyone. I have no idea what makes the difference â€â€.it might be Windows only (I'm on OS X), it might have something to do with mods, it could have something to do with graphics settings, it could be something else, it's impossible for me to say since there seems to be no bug to observe for me.

Yeah, seems like a bit of an oversight, since the scientists modify the rate of science collection. As a workaround, I suggest just using full career mode, giving yourself as much funds as you want, and then ignoring the bits of career mode that don't interest you.

Ok, sure, I'd go for improving the characteristics to be less severe for cases where the vertical component of the velocity is very small. Water is much softer in that situation, or to be more accurate the surface tension causes it to act like a lubricated solid surface with a little give, and you hydroplane over the surface until the speed drops low enough to fully penetrate the surface. I've personally landed on water with about 15–20m/s horizontal speed and negligible vertical, after parting company with a boat at speed, without much protection, and it was very wet but not otherwise unpleasant, but I did skip over the surface for quite a distance before going under. In those types of cases, the surface tension actually helps you, as it delays the point where you decelerate rapidly due to breaking the surface and having to push the water aside. Vertical speed is the main problem for landing on water. Horizontal speed has the problem of abrasiveness, and can be catastrophic if you get something like a wing digging in and causing the craft to cartwheel, but it is quite survivable if those problems don't lead to consequences. I'm not sure I'd call it "relative safety", as there's really a fairly big element of luck involved (and pilot skill), but it's certainly not guaranteed death and destruction. In many cases, ditching has been catastrophic, as there's very little error margin.

Landing on water at significant speed is just about the same as landing on solid concrete. The surface tension created by the water molecules mean that it behaves far more like a solid in high speed impact, than as a liquid. It is only "soft" at very slow speed. A 50m fall onto salt water results in catastrophic damage to the human body, breaking pretty much every bone, in some cases causing near decapitation (in the real example I'm thinking of, complete separation of the skull from the spine is quite common). I'm not saying that the current ocean physics are good or perfect, just that it's highly realistic that a high speed impact with water is catastrophically destructive. Fast water landing should never be significantly safer than fast ground landing.

That sounds fairly normal, it takes many times the fuel delivered to deliver fuel to space, both in reality and KSP. If you're in career mode, you are paying for it, it's included in the cost of the tanks, empty the tank out and the cost drops dramatically, as fuel is the majority of the normal cost of a full tank. Unless you have any expensive modules, you'll find that the majority of your launch cost is often fuel.

Yeah, I think it was a mistake to make them non-retractable. It just doesn't make any sense to me, and feels very like an arbitrary "we need to do something, let's invent something without any real basis". It would have been quite sufficient to just make the shielded ones more resilient to heat when closed, maybe a little less draggy, and more protected from impact damage. Those things would make some sense, lack of ability to retract does not.

No they don't dwarf everything else unreasonably. They have a very specific area where they deliver the high power output, and it's not unreasonable. Needing to throttle back once established into supersonic cruise is a very realistic behaviour. Or, if space is the destination, you make use of the power peak to get as much speed as possible before losing combustion air. You just need to use the throttle to control them, if the peak power is causing a problem, or adjust the ascent profile to reap the benefits of the performance characteristics. The power peak is normally quite narrow and short lived, and for me it gives a very welcome, but brief boost to help me through the 20–25km climb where the power is dropping off almost entirely. More commonly for me, the problem isn't the size of the power peak, but actually holding onto the peak for long enough to get max possible speed above 25km.

That still offers no real improvement over just launching a new purpose built lab station. It doesn't save you anything of real consequence. You would need to launch a crew ship and stock the lab with science after ramming it with a klaw. Remember, that to be useful, those support modules will need to have about 5–10k of battery and a couple of the Gigantor XL solar arrays, as a minimum. Sorry, but I just think it's a really crappy idea to try to re-use scrap lab modules, and nothing that has been said so far comes close to convincing me otherwise. If anything, what's been said has convinced me even more that it's a crappy idea. Just blow them up and be done with it. It saves you nothing of any importance, neither time nor effort nor a significant amount of funds.

I concur, the dotted view is showing a significantly different data set to the other 2 views. The difference is far more than the distance between a pair of dots, it can have nothing to do with the way the dot represents a larger square around it. Entire areas (containing many rows and columns of dots) light up that were entirely unlit in the other 2 views, and vice-versa with entire areas of dots going dark when you switch away from dot view. Nothing to do with eyesight, nothing to do small error rates, nothing to do with sampling/averaging/precision/etc. It is either showing a significantly different data set, or has a significant error in the way that it is mapping the same data set onto the surface (an entirely different projection). One of the cases is showing highly incorrect data, but I have no idea if it's the dots that are wrong, or the other 2 that are wrong.

Just remove the klaw from that launch and replace it with a lab. ;-) The lab isn't expensive in terms of part cost, and it's only 3.5t. You save yourself the hassle of needing to do an orbital rendezvous. The launch effort is just the same as launching a klaw with a support section for a lab, and the cost is inconsequentially higher. I could be wrong, but I don't believe you get a higher science rate. You get a higher conversion factor processing experiments from the same surface into research data, but that's all, I think. The research rate is entirely determined by the number of scientists and their skill levels, I believe. The generated science will still be 5x data. So, over infinite time, it does give more science, but over a fixed shorter period there's minimal advantage to landing it. Am I wrong in that belief?

Yeah, that's a hell of a lot of rocket for the M700, but might make sense if it's destined for somewhere a very long way away. I use something near identical to the stock Z-MAP satellite launcher, a simple small 1.25m stack, with the M700 on top. I use a 1.25m fairing for it and the probe it sits on. All you need is for the fairing base to be a bit lower than immediately below the M700, and expand outwards as the first/lower part of the fairing until it's wide enough for the widest part of the M700. Once it's wide enough, next segment is vertically up until the M700 starts to taper in. Next segment is a long taper inwards roughly following the shape of the folded M700 scanner dish thing. Finally, taper in and close on top of that.

It's just junk in the stock game, if it's just the lab part on its own (which it will be). You could ram it with a klaw, but that's really not worth the effort, in my opinion. If you're talking about trying to use junk, I'd guess you probably don't have the klaw unlocked anyway. Terminate it from the tracking station and launch a proper station built with all the correct stuff from the start. You would be saving very little by salvaging floating junk, for a whole load of hassle to try to use it. Docking ports and crew hatches are two completely separate things. There are 2 crew hatches on the sides.

If the main issue for you is just finding the runway, plant a flag on the grass directly off the 09 end of the KSC runway (make sure it's actually off the runway object, including the grass slope, and onto the flat grass plain beyond, not far, just enough to stop the game being stupid and forcing you to recover it before you can use the runway again). I prefer to have flags at both ends myself, but the stock game has an odd bug that keeps eating my 27 end flag right now, unless I do a bit of a hack to make it stay put. You can set the flag as a target, and the end result is very nearly as good as MechJeb's pseudo-ILS guidance. If the issue is landing, it really is worth spending a bit of time learning how to pull off a textbook landing by hand. It's not easy, I know, but worth it in the long run. Low, slow, and very flat, no violent control inputs on final approach, that's the key to learning successful landing; once you have calm gentle landings sorted, you can move to more advanced stuff like a mad supersonic power dive from 20,000 directly towards the threshold, pulling up hard at the last moment. If the issue is "altitude hold", that doesn't really seem to work terribly well, to be honest, at least for me. It always seems to over-compensate and constantly hunt for the set altitude, without really stabilising there, even if I start out straight and level at the altitude before engaging it.

Not the most delicate way of phrasing it, but I respect your bluntness and strongly agree with you. It would add nothing of value to the game to force the player to sit watching it for a while. The current mechanic is basically just fine, and it is absolutely not overpowered or broken. That said, "just fine" isn't the same as impossible to make it better. "Just fine" means that there's no burning issue with it that needs any urgent changes. I certainly wouldn't have a problem if the results were not available until it had been sitting up there for a while, as long as there was no pointless forced interaction with it. One thing though, if there's to be any change, don't make the classic noob-navigator mistake that SCANsat historically made (not sure if it still has the flaw or not, have not used it in a long time). Do not ever treat longitude as being of constant physical distance, it's not. Latitude is constant physical distance, longitude varies according to latitude. Using longitude for distance is only valid at the equator, it's not even close once you're out of the equatorial region. That flaw made using SCANsat slower and more annoying than it needed to be. The longitudinal width of scan lines should grow with latitude on Mercator projection maps (or equivalent), tending towards 360° from a single pass over or near each pole, assuming a constant altitude circular orbit. The maths to calculate the correct longitudinal width are not difficult. I'm also not convinced that ore scanning would really benefit from a model which required an actual complete scan based on the satellite physically passing over the entire surface through many orbits. Simply having the results available an hour or a day later would be fine, if there was to be any change at all, the precise detail of the scanning doesn't need to be implemented.

Yeah, I can't even see a minor downside anywhere here. It's good for stock KSP to simulate debris to the extent it already does, but I have pretty much zero desire for any more debris handling to be added to the game. On normal difficulty, I absolutely don't care about debris recovery in financial terms, and just don't really care about it at all, I mostly just want it gone without a fuss. Multiple craft too difficult? Don't do multiple craft on a single launch then, although I seriously can't see how it's too difficult if we're talking about detaching them in orbit. Detach, then use '[' and ']' as required, pause to go through each craft and the launcher to rename and set class as necessary, then it's all right there in the tracking station, or the in-flight map. I see a little learning required, but no difficulty. Multiple craft in atmosphere, ok that's not really supported, but it's also really not necessary and a limitation that does no serious harm to the game. Again, on normal difficulty, there's not really a huge financial concern that makes multiple craft for a single launch something that you absolutely must do. Nothing is forcing, or requiring, or even encouraging you to do multiple craft per launch, it's just an option if you find that fun (and if you don't, then don't do it).