Murph

There's a bug at the moment, where the brake torque isn't being set correctly. It's ok for a newly installed wheel, but as soon as you open the right-click menu it's getting set to a fraction of what it should be, in some cases to 10% or less than what it should be by default. If you know what you are doing, edit your save file and you'll find that you have cases of "brakeTorque = 30" on some rover wheels. Set that to a more appropriate value, e.g. "brakeTorque = 300". You can check the default values in the cfg files in GameData/Squad/Parts/Wheel, it's different for each wheel: $ grep brakeTorque GameData/Squad/Parts/Wheel/*/*.cfg GameData/Squad/Parts/Wheel/roverWheelM1/roverWheelM1.cfg: brakeTorque = 300 GameData/Squad/Parts/Wheel/roverWheelS2/roverWheelS2.cfg: brakeTorque = 180 GameData/Squad/Parts/Wheel/roverWheelTR-2L/roverWheelTR-2L.cfg: brakeTorque = 500 GameData/Squad/Parts/Wheel/roverWheelXL3/roverWheelXL3.cfg: brakeTorque = 200 $ It will break again as soon as you right-click the wheel, but should stay at the correct value if you don't touch them. The culprit seems to be brakeTorque_UIFlight's maxValue, so you can also set that much higher, which I believe should prevent the value getting clobbered (untested, not sure if setting a higher value there actually sticks). Each new craft will launch broken, these things only fix it for craft already in flight. I've not tried actually fixing the part cfgs themselves. If the above made about as much sense as a novel written in a random mixture of Dutch and Chinese combined, you probably shouldn't be messing with your save file (or at least don't complain to me if it all goes horribly wrong for you).

One thing I'd would strongly like to avoid is it switching to a mode that blocks cmd+tab, as some full screen apps are prone to doing (quite why the OS even allows that without the user granting permission or enabling it is beyond me). I too am annoyed by the current mode where the menu bar and dock can make an intrusive and unwanted appearance if your mouse strays a pixel or 2 too far. Given the choice, however, of cmd+tab being broken, or having to live with the current behaviour, I'd choose the current behaviour. I.e. correct function of cmd+tab is orders of magnitude more important to me than the irritation here. Ideally, I'd do away with the irritation while keeping cmd+tab functionality.

It's not a total waste, every scientist on board contributes to the daily rate. So, 2 labs with 4 scientists should be double the daily rate of 1 lab with 2 scientists. It's just the 500 cap and the hidden internal no-repeats log that is per-craft and not per-lab. As for preventing it, it should only be a warning, as some may wish double rate, or have aesthetic reasons for choosing to have multiple labs. Completing the tree without leaving Kerbin SoI is nothing new, and that's something that is actually a good thing. While it's possible to do interplanetary without completing the tree, plenty of people have absolutely no interest in doing so. I'm not interested in exploring the solar system with one hand tied behind my back. The career game is absolutely not about ongoing unlocking of the tech tree, that would be a terrible game. That has never been what the game is about, and I sincerely hope it never will be. It is about unlocking the tech tree as a start of game activity only, with mid to late and end game being all about exploration and managing funds. I always get the tech tree out of the way as first priority, before any interplanetary missions. The game is an open ended exploration and building sandbox, with the tech tree strictly as an early game "getting started" activity only. You can choose to venture out of the Kerbin SoI early if you prefer to do that, but you should never be forced into that just to get the full set of parts. The science system absolutely should not be changed in the way you suggest, it is absolutely not broken like that. Yes, the labs need some polish, and a proper UI in particular. No, they do not need "to be better integrated", they need to continue as a stand alone and optional science source which you can choose to use or ignore. There is nothing wrong with career mode "pacing", it's working the way that it's supposed to work.

The current heat is basically about right for the speeds involved. You are calling for heat that vastly exceeds realism for the speeds. Remember that it's m*v*v, so half the starting velocity is actually a quarter of the energy to dissipate, i.e. it's perfectly correct and appropriate for heat to be less of a problem. I don't need to cite a reference, but I can: The 1.0.2 release is a fairly clear statement of Squad's intent. I really do think that what we have today is very likely at least a close approximation to Squad's intended level of heat. Can you cite anything at all, anywhere, even the slightest hint, that they intend for re-entry heat to be a major problem for re-entry from Mun & Minimus? I don't believe that any such statement exists from them. There are circumstances in today's 1.0.2 game which will cause you severe problems with heat, namely coming in from certain solar orbits. Also, re-entry in space planes without actively taking steps to increase drag dramatically and scrub speed off. Also, spaceplane ascent if your vertical rate is too slow once you've got mach 3+ speeds going on. Also, losing attitude control of a capsule with other parts below it and ending up facing prograde. I think that we have got exactly what they intended to deliver, that it should not be changed significantly; and that it would be a huge game-breaking mistake to change it to be significantly harder, very likely causing significant harm to KSP's long term success. I do not believe that they ever intended the consequences to be a severe problem for re-entry from Kerbin orbit. - - - Updated - - - Up to about 45° AoA, it's not so ridiculous. That's how NASA's Shuttle did it, combined with long high AoA S-turns.

To be honest, unless it's extremely marginal on chutes, set the pressure to 0.5 (max), to minimise the time to landing/splash (and set the full opening altitude to 50m if you can get away with it, or 300m if you can't, those are always altitude above terrain, so safe anywhere).

Well, if I was building it, I'd adjust the position of the rover if its mass was low enough to allow that. I'd then flare the fairing outwards below it to clear the widest parts of the rover, while keeping the fairing perfectly centred. You shouldn't really need the next size up of fairing for that (which I guess is what you're meaning by needing more tech), rather just expand the existing fairing outwards, unless the rover is really huge and hits the max expansion width of the fairing. If need be, move the fairing base down the rocket, or place spacers on it to give sufficient vertical distance between the fairing base and rover, so that it can expand sufficiently to clear. I'm just thinking "gee, I really don't fancy Tim's job flying a banana shaped rocket into space…" ;-)

If you're low on fuel, and fast/high, and screw up the approach to KSC 09, it does give a possibly useful alternate landing strip, but not if you're low & slow with no fuel (if low & slow already, just use the vast plains of grass instead of KSC 09). Similarly, if low on fuel approaching KSC 27, it will be slightly closer to you until finals. Mostly it's just a curiosity, and somewhere that's convenient to fly to from KSC when training yourself to fly, or experimenting with aircraft designs.

Hmm, "off centre" sounds a little concerning, to be honest, but it depends just what you mean. Off centre mass or drag is a terrible thing in rocketry, it's a major cause of control issues and failure. A wider and heavier faring would almost certainly be a much better idea than an off centre fairing, or significant off centre payload, if either of those are what you did to fix it.

As others have already said, you're completely wrong about that, and the reasons you think were behind it. There are a great many things in the game which would be far worse with real scale: ascent to orbit, descent from orbit (just the time needed, nothing to do with heat), rovers, terrestrial flight to places elsewhere on Kerbin, etc; pretty much every single thing involving distance and real time control. It has absolutely nothing to do with texture size or quality, you could do real scale without any difference in texture size (but low-isn quality), or just a modest increase in texture size for ok-ish quality. The mods which are giving problems with texture memory have chosen to go with heavy texture load, but they didn't really have to in terms of gameplay, only an arbitrary decision by the author to make it look as pretty and detailed as possible. Scale and detail are two completely separate things. Squad could very easily have done real scale while still having all textures loaded all of the time, and without severe memory bloat. It's not like there is much surface detail to see anyway, to justify high res textures for planets. I strongly believe that they chose not to do real scale because it would be extremely crap for gameplay for the average person just wanting to have some fun. The current scale provides a game which can deliver satisfaction from as little as 5–10 minutes of play, or feel like you achieved quite a lot in an hour of play. It lets you complete a flying mission on the other side of Kerbin in less than an hour. Launches take long enough to be interesting, can be hand flown without much issue, but not so long that you're dreading the time they take. It's absolutely standard in game simulators which are on the (more fun, less serious) end of the spectrum to make exactly that type of choice, as you get a better game out of it, with a far wider audience. It's all a bunch of compromises necessary to produce a "light" and fun game. It has never been supposed to be an ultra-realistic simulator, just something which doesn't deviate too horribly from real physics in general, and adheres to normal orbital mechanics. KSP does not need ultra-real re-entry heat, it would be a vastly worse product with that. All we need is acknowledgement that re-entry heat exists combined with limited consequences from it as long as providing those consequences doesn't cause serious problems for average players. Today's heat system is perfectly acceptable as a whole, maybe it could use some minor tuning, but that's all; it should absolutely not try to get even close to real re-entry heat problems.

It's not really a proper solution, but you'll know if an experiment has already been processed by the lab in question. The process button only appears if the lab hasn't seen that particular experiment before. You can also keep the previous experiment results in the lab after processing, but the current UI is dreadful for actually seeing what's there once there's more than about 10 experiment results. Beyond that, absolutely nothing in the stock game really helps you with that at present. Hopefully the replacement UI in 1.1 (all UIs have to be redone from scratch for Unity 5) might be better. On the flip side, there's no requirement or benefit in-game for hitting 100% completion on experiments processed in a lab. You don't really even get the personal achievement type thing from looking at them in the science archives, as with traditional experiment results. I suggest forgetting about anything like completion and just moving on to a new location once you get bored with the current one. Just let that lab slowly run dry, but any exploration missions to the body it's orbiting can always stop there and process whatever experiments they gathered, on their way back home.

Turbojet + Aerospike combinations seem to work mostly as pre-1.0 if, like me, you never believed in "air hogging" (due to it being a blatant and obvious cheat). Personally, I quite like them. Historically, I found they were often superior to the RAPIER (it was never clearly better than them pre-1.0, and I always felt it was a bit mediocre, falling quite short of what it should be). 1.0 has changed the ascent profile needed, and altered the fuel usage a bit, but they are quite usable for a spaceplane. N.B. I'm talking about larger spaceplanes, which can deliver useful payload, there was an edge case for micro spaceplanes (with basically zero payload) pre-1.0 which the RAPIER seemed to win. Because I was always unimpressed with the RAPIER historically, I've yet to really properly evaluate it in 1.0, so not sure just how it measures up now. I just know that with a little adjustment to designs, I can produce reasonably viable low orbit spaceplanes using traditional non-air-hog turbojet + Aerospike. If anything, the turbojet is now superior to the old one (with no air hogging), due to the big burst of power before it falls off due to lack of air. The pre-1.0 RAPIER always felt to me like I'd been promised a Ferrari, but a Fiat painted Ferrari Flame Red was delivered, and the salesman thought that was ok.

Yeah, I'll basically agree with that. NASA have entire buildings full of incredibly smart people to figure out the long range mission profiles. It could be a quite positive thing to add some tools which kinda represent that a little, but without doing all of the work for the player (we don't want it to be click "go to Duna", then "EXECUTE!"). Just something to help find the transfer windows, efficient profiles, dV budgets, etc; but with the player basically still putting it all together (with some opportunity to screw it up and fail), and hopefully getting educated in how it works and some of the issues of real long range space travel.

It's not at all clear that Squad intends there to be "meaningful" re-entry heat under all circumstances, only that they intend to represent that the heating exists (which is an entirely different thing to representing the consequences), and provide consequences in extreme circumstances. Can you cite a single reference which says that Squad's intention is to have highly realistic consequences of re-entry heat under all circumstances? The scale of the star system is a necessary and useful compromise in a number of ways. Squad got that bit right, for the "more fun, a little less serious" approach of the game. Re-entry heat is meaningfully represented; but the no-fun, bad for gameplay, bad for KSP's overall success consequences are greatly softened. The scale compromise results in other necessary compromises. The game is far better having more forgiving re-entry heat, than pushing hard towards realistic consequences, as too much realism there would make it completely impossible to re-enter in anything other than a very narrow range of craft designs. This is an area where maintaining the possibility of fun for the majority completely negates the justification for providing realism for the minority. Is the current tuning and balance perfect? Probably not. Will it improve? Almost certainly. Should it be pushed hard towards realistic consequenves? No, absolutely not. Is it actually much closer to being "ok" than the critics here are willing to admit (mostly due to being too narrow minded, failing to see the big picture, etc)? Absolutely, yes. I'll say it again, the worst critics of the current heat implementation need to tune/configure their game to give the result they would prefer, and/or mod it if Squad's provided controls are insufficient for them. You are in the minority here, you are arguing for changes which would likely be overall significantly harmful to KSP. - - - Updated - - - The mach 3.0 plane at 20,000m is just an example that most should understand. High altitude, very fast aviation is very much a good thing to include in the game. Just look at NASA, they have a long and broad history in more extreme aspects of terrestrial aviation as well as space. Tweak the game too far in the way that you are advocating (and my sense is that you want it tweaked much too far in that direction), and rockets will likely have unreasonable (possibly even unrealistic) heat problems on ascent as well. Space planes are here to stay and a popular feature of the game. Get over it.

You'll pretty much need to take that complaint up with your preferred deity in the real world, or some international union of physicists if you are not into the deity thing. "Ya cannae change the laws of physics!"  Scotty, Star Trek. Interplanetary transfers are extremely hard, with narrow error margins. Two things you need to look into, and try to understand, if you've not already done so: transfer windows (the dV for interplanetary transfer varies HUGELY based on the alignment of the planets before you start), and mid-course correction burns (it takes a tiny amount of dV mid-course to make a huge change at the far end, as it basically gets multiplied by the remaining travel distance). Once you're familiar with both of those, one of the other details is being very precise with your burn vectors, due the the mentioned feature that a tiny variation in dV makes a huge difference over interplanetary distance (at origin, just 1° off on the direction, or 0.1m/s off on the size of the burn can be enough to make the difference between intercept or no intercept of the destination, hence the need for mid-course correction burns, just don't waste all your fuel chasing that last impossible 0.1m/s, rather wait for it to grow a bit before correcting).

Heating from convection (which is most of your incoming heat during re-entry) only hits the shock intakes half as hard.

I second that. It is totally irrelevant how quickly or easily other games managed to port from U4 to U5. KSP is a unique and highly complex game that will require a vast amount of custom code on top of Unity, and code to forcefully shape Unity into what is required for KSP.

I've thought about this quite a few times as career mode has progressed since first introduced. On balance, I have to say an emphatic "NO!!!" to this. It makes a little sense in the earlier stages of career mode, but becomes nonsense in the later stages, once you've fully unlocked the tech tree and naturally your focus has shifted towards long range missions (having likely got to the stage where the local system is no longer that much of an appeal). It would have to be set at such a low level of funds needed, that it would be basically irrelevant and pointless. If it wasn't set at that low level, people would just abandon career mode in favour of science or sandbox mode, or just hack the funds. Personally, I'd probably just hack the funds for it. I quite like playing career mode "end game", where the focus is on interplanetary, and this suggestion would be pure annoyance, taking away from the fun of the game.

You could also possibly take some of Ike's free supply of dV to reduce the cost of braking to 0 before accelerating in the opposite direction. http://wiki.kerbalspaceprogram.com/wiki/Tutorial:_Gravity_Assist Not sure that would really be worth it; raising Ap to quite high and reversing orbit there is simpler, and you can actually use the high Ap as part of your orbit phase matching for the rendezvous.

I'm aware of the bug, but can't say that it bothered me much, or that I see it as a priority to fix it. It's not really game breaking, and you can't freely hire until you raise the cap. If there is to be a fix, I suggest what may be a simpler alternative, that you can't launch kerbals past the cap. Honestly though, if I were one of Squad's devs, I'd probably push this bug close to the very bottom of the pile.

Probably not all that much, although every little bit does help. KSP isn't actually all that graphically intensive (other than the ridiculous oceans on default configs), so if you have the graphics options tuned downwards appropriately for your system, and have fixed the ocean performance by editing settings.cfg, then you're likely already mostly bottlenecked on physics and orbital maths. Hopefully Squad will fix the long standing ocean performance bug as part of the porting to U5. If DX12 is a standard part of Unity 5, and doesn't require special support on the application end, it seems highly likely that it will be used if available. If it requires special support on the application end, then it's less likely in the short term, as 2/3s of KSP's platforms (OS X and Linux) use OpenGL, not DirectX.

No "zooming past" for me, either completely stock or with Kerbal Alarm Clock. You might want to check if one of your mods is creating a failure case for them, or file a detailed bug report if you've got a reliable way to make them "zoom past".

You're ok, I wouldn't call that cheating, as you're not abusing the high impact tolerance of the wheels, your landing is at a realistic speed, and within normal physical stress margins for the way those wheels would be used in their normal application. You are just using a more unusual part for your surface interface, so it's reasonable creativity, rather than cheating.

See also the "Go Advanced" button, if the "Quick Reply" box is insufficiently buttony for your tastes.

I use them quite a lot, and I'm very pleased that they were added. The problem fixed by them was accidental warping past the desired point, something which was common due to the way that warp ramps up and down, particularly for longer warps or highly eccentric orbits where there is a rapid increase in speed approaching periapsis. They also improved the user interaction by changing the method from an imprecise stream of carefully timed keypresses, to just a simple click. Are they perfect? Probably not. Could further improvements be made? Undoubtably.

Size, function, and mass are not necessarily related (although each can influence the others). An argument could possibly be made that decouplers need to be larger to physically separate the fixed attachment point from the explosive decoupling (I admit I made that up, but it is a possible justification). That said, I'm not convinced by the difference in weight, as separating both sides can still be as simple as blowing a single set of bolts (i.e. I'm not convinced there is a good case for separators to be larger or heavier).