Mattasmack

I guess I'm not up-to-date either! I've played KSP stock or minimally-modded for years; I just grabbed CKAN recently to try a more heavily modded game for a change. CKAN is working for me; but if it used to work better or if it was down for a while, I wouldn't know. According to a post on the KIS thread, you can narrow it down further to just KKS and KIS (KAS is not needed to make the bug happen). The bug is very consistent; I got a cloned kerbal every single time I had one re-enter a pod after EVA-ing.

Same here, and I just finished narrowing it down to this mod vs KIS & KAS as well. I'm on KSP version 1.0.5 (build 1028), with KAS version 0.5.5, KIS version 1.2.6, and Kerbal Krash System version 0.3. Module manager version doesn't make a difference, at least between 2.6.18 (packaged with KKS 0.3) and 2.6.20 (current version according to CKAN). Edit: I should mention that although I first ran into the problem while using CKAN, I duplicated it with a completely fresh install and the mods installed manually. (It's not CKAN's fault.)

Mea culpa, it's been a heck of a month. I had read those Dev Notes and I missed the bit about the tutorials. I had to ctrl+f 'tutorial' to find what you were referring to. The dev notes seem to say that you're fixing 'bugs' in the tutorials -- that sounds like things like updating craft for the new physics, fixing older design errors in ships, etc. I hope you're doing more than that. There are good comments in this thread and elsewhere about the sort of basic information that's missing. Similar to many of the comments in the reddit topic that Maxmap made almost a year ago about a tutorial revamp, which are probably still worth reading even though they were about version 0.90. (If you were already aware of the reddit thread, never mind.)

Psst, Derfel, And to get on-topic: I don't expect Squad to do anything with the training missions in the next version. Their general pattern, as I've seen it, is to first introduce features in the game in a bare minimum, just-get-it-working way, and then leave them alone until they're ready to come back and completely rework the feature to be just the way they want. They tend to not make half-way changes. If the pattern holds, they'll eventually come back and completely redo the tutorials, possibly to some whole new system. But that will be a major effort, so we'll hear about it in the dev notes when it happens, and if they haven't said anything yet it's not going to be in version 1.1. In my ideal KSP, the training scenarios would include video content to illustrate some concepts as well as building and flying activities. (For example, you can't adequately explain how to use a maneuver node to a new player using only a few words in a text box.) More attention would be paid to basic how-to's, like how to interpret the symbols on the screen in flight, or how to navigate the scenes in the space center. And the scenarios wouldn't be flat-out broken, of course. They would also be accessed from within a save game rather than main menu and would unlock progressively, at least in career and science mode games. You don't need to see the tutorial on docking until you've unlocked docking ports, or anything about asteroid intercept until you've upgraded the tracking station enough to see them, etc.

Hi Derfel, You are right. The tutorials are borked. They've been borked for at least a few versions now, and I'm not surprised to hear they're borked worse now. And yes, it's very frustrating. My Dad has tried to get into this game a couple of times; it's just the sort of thing he should like. But he did the same thing as you -- he tried to work through the tutorials and training missions first to understand how to play, and of course got increasingly confused and eventually got frustrated enough to give up. (It didn't help either that on his first attempt he used the 64-bit version from Steam -- because that's the logical version to choose for a 64-bit computer with a 64-bit OS -- which crashed constantly for him.) In my opinion, currently the best way to get started in KSP is to watch Scott Manley's tutorial video on getting started in career mode. Unfortunately the video is out of date in many ways, having been made for version 0.90 about a year ago, but they key things to learn from it are about science points and how to collect them in flight and that's still mostly current. Then, start a new career or science mode game on an easy difficulty level and start flying rockets and experimenting. Starting with only a few parts available keeps things from being overwhelming at first. (No need to know how to capture an asteroid or make a rendezvous in orbit; you can't even get to orbit at first!) Unlocking parts gradually takes away the training wheels gradually. There's no need to complete this initial career or science mode game either; it's just a way to get started without dealing with the flawed scenarios and vehicles in the training missions or getting thrown into the big and confusing parts list of sandbox mode.

Unless something has changed recently, I don't think there's an official definition of the volume units anywhere but if you assume a unit is five or six liters, it makes things work out reasonably. (Reasonably means that the rocket fuel tanks actually have most of their volume taken up by fuel and oxidizer, and the densities of fuel and oxidizer come out close to real-life equivalents.) The fact that there isn't an official definition means you can get a really good argument going about it though (e.g. the original thread you apparently posted this question in).

It looked like the rocket developed a coning motion, based on the animation they showed after launch. Once it got severe enough, that would be enough to cause the rocket to break up either from the motion itself or due to aerodynamic forces (since the rocket would certainly have still been in the atmosphere at that time). The later animation of the rocket spinning end-over-end could have been after it broke apart. Whatever fragment that held the telemetry could have ended up spinning like that, though the animation showing the whole rocket doing so must be incorrect. Edit to add: It's really too bad they cut away from the initial four views they showed right at launch. The video from the tracking camera would show for sure whether the rocket broke up, so we wouldn't be left guessing if their animation just went screwy or if the rocket was really lost. Edited again: Here's a recording of the launch footage that someone uploaded to Youtube: Right before it cuts from the four views at 1:28, I think all the views support the conclusion that the rocket tumbled for real: in the lower-left tracking view, the exhaust trail is becoming corkscrew-shaped. In the upper-right onboard view, the exhaust grows more and less visible with each rotation of the rocket, indicating that the rocket isn't facing the same direction it is going. And the animation based on telemetry, in lower-right, shows a tumbling motion rapidly growing larger.

I don't think a stock hard mode career will give you the experience you're looking for. The relatively low funds you get from contracts in hard mode really punish failure; instead, I found that hard mode pushed me to be more conservative in my rocket designs, to make sure each launch was successful and completed the contract(s) it was designed for. A slightly too large, more expensive rocket is much cheaper than a slightly too small rocket that has to be launched twice because it didn't work the first time. I don't know what would be better. In terms of stock KSP, maybe a normal or moderate difficulty career with quicksave turned off would do it. (And I generally play stock, so I don't have any mods to suggest.) That would mean you have to put up with the random failures that come from game or game engine bugs, though. It is possible to rationalize them as the sort of random failures that occur in real life, but they can be very frustrating. But if you expect to sometimes fail missions or have failed launches, don't play stock hard mode!

If you do add this image to such a section, it would be good form to credit the author. (Stephan Biesty and/or Richard Platt; I'm not sure which book this illustration came from. And I doubt either of them has released it under CC or to the public domain.) How much do you trust it? At a quick glance, I see that it claims the Saturn V first stage ran on paraffin (rather than kerosene) and oxygen. The paragraph labelled 1 for the first stage is a rather mangled description of the separation of the interstage on the bottom of the second stage (not usually considered part of the first stage at all). Seeing those right off the bat makes me think it's not useful except for very general illustrative purposes.

Sure, mirrors are cheaper than PV cells. But the slumped glass mirrors typically used in parabolic trough receivers are not so cheap. Neither are the structure holding the mirrors, the drive turning the structure, the foundations, the receivers, or the labor required to align all of these components precisely. And all of this typically accounts for half (or less) of the total plant cost. Let's look at some recent numbers: The most recent parabolic trough plant completed in the U.S. that I could find is the Mojave Solar Project, completed at the end of 2014: 250 MW net power output for $1.6B in construction costs, or $6.40 per installed Watt. The plant's capacity factor is 28%, suggesting that it has little or no thermal storage. Perhaps it uses natural gas cofiring like earlier parabolic trough plants in California did. (See its Wikipedia article, and this letter citing capacity factor.) In contrast, as of 2013 the average cost of utility-scale PV projects was $3.7 per installed Watt, with an average capacity factor of 27.5%. (report here) This comparison suggests that parabolic trough plants are about 70% more expensive than PV ones. Which is consistent with PV being installed at a much faster rate than solar thermal.

It depends on what kind of solar panels you are comparing to. Typical panels used on homes or in slightly larger-scale installations (e.g. over parking lots or solar gardens) have efficiency in the 10-20% range, depending on whether the panels are thin-film, polycrystalline silicon or monocrystalline silicon. Concentrating photovoltaics (CPV) can have higher efficiency, around ~30%. These use high-efficiency multijunction solar cells (efficiency 40%+), but lose some energy in the concentrating optics. I don't know what the state-of-the-art of solar Stirling systems is, but my understanding is that their actual demonstrated efficiency are right in that same range of ~30%. So a solar Stirling system can be more efficient than run-of-the-mill solar panels, but if you compare like-for-like concentrating systems, it's about a wash between Stirling and CPV. Better to look at cost as a figure of merit rather than efficiency. The plain old solar panels have lower cost and are therefore more practical -- assuming you have the space for them. The problem with highly concentrating systems (Stirling or CPV) is that concentration requires mirrors or other optics. These must be aimed precisely towards the sun and must be very rigid structures so that they aren't deflected or deformed by wind. The structure, the pointing mechanism, and the mirror surface or lenses add cost. (Solar Stirling systems that I've seen are pretty big, because there's a minimum practical size for the Stirling engine. That means the parabolic mirror structure is large and tall, which puts it further off the ground and exposed to stronger winds, so it has to be built stronger. CPV systems can be made smaller to avoid some of this problem.) The simple PV panels can just be plunked down on a fairly low, fixed structure so that they're tilted a bit to the south (or to the north, if you're in the southern hemisphere). If they get deflected a bit by the wind, or if the installation isn't precise, it doesn't really matter. If you have limited space, then a higher-efficiency concentrating system might make sense. No solar system will do much when it's cloudy. But, solar panels accept diffuse light and will produce a little power as long as there's some light. Concentrating systems use only direct sunlight, so in cloudy weather I wouldn't expect them to produce any power at all.

I agree with your impression that this feels like a larger-than-normal release but not a special "1.0" release. I suppose it's just a result of different perspectives -- the developers have known all along what they wanted the game to look like in a 'finished' state and what elements needed to be present, and we haven't. It is a big update though, and some of the new features should be pretty great when they're polished a little more. I'm pretty excited about the new aerodynamics; up until now I've flown only rockets because the old placeholder soupodynamics were just no fun at all to me. I'm looking forward to giving spaceplanes another try. I'm also excited about resources; I'm looking forward to making missions that can go around to multiple locations and come home again, rather than one-way flights that eventually run out of fuel and are abandoned. That said, I'm playing in career mode and it will be a while before I'm able to do any of those things. They finally fixed the radial decoupler bug, thank goodness. I'm rather disappointed at what seems to be the unfinished state of the new aerodynamics. I like that I have to be much more careful about what I re-enter and how. But putting a heat shield on a capsule destabilizes it; how did nobody notice that in testing?! It's a problem that re-entry heating can destroy my craft, but I don't have any way to check the temperature of parts without using options hidden in a debug menu. It's also a problem that I can't see how far I can angle the capsule on re-entry to produce body lift before the heating starts hitting parts other than the heat shield. I like the changes they've made to the contracts in this version, at least so far. The problem I had with them in 0.90 was that the main new contract type that appears late-game (doing things with asteroids) didn't appeal to me, so doing the other contract types got repetitive. More contract types should help. I don't think I agree regarding excessive funds. In version 0.90 I played career on hard mode and building up funds to pay for space center upgrades and unlock parts was the main limiting factor. This time I'm playing on moderate and the upgrades are coming more quickly, but so far at least funds are still the limiting factor. In version 1.0 I just got my first ever Danny-style game bug -- when landing a capsule at the end of a flight, I noticed that the upper stage that crashed nearby had thrown some parts back up into the air. I switched to them and discovered a pair of goo containers, and they suddenly took off out of the atmosphere! By the time I switched back to the tracking station they were out around the orbit of Mun. I tried switching back to them again and the game froze. So it's still buggy! Edit: Aaaand, I just killed a tourist on re-entry. I was at something like 35km, coming in tail-first, not even seeing re-entry effects yet, and the capsule blew up. The probe core on top of it was fine, the heat shield and still-attached upper stage below it were fine, just the capsule blew. Wish there was some way to tell if that was a bug or bad re entry or what!

The game is about to change next week, but I think much of the following will still hold afterwards. (This is all based on my playing stock; mods likely will change the picture as well.) Khazar already said it, but I want to emphasize: your first building upgrade should be to mission control, so you can take on more contracts at once. It's a cheap upgrade, and it gives you much more scope to find combinations of contracts to fulfill with a single launch (which is more profitable, and makes the mission more interesting too). It also lets you take on the first few 'explore x' contracts and get their up-front payments, even before you're ready to start tackling them. Select contracts carefully; they need to both be profitable (total funds payout should be several times the cost of the rocket you build to fulfill the contract) and worth your time as a player. For example, testing parts landed or splashed down on Kerbin is almost pure profit, but the contracts are so small that they usually fail the second measure: not worth your time. Very early on, I liked the 'science from space around Kerbin' contracts a lot -- they could be fulfilled with a very cheap rocket (a capsule and two stages of small SRBs) and a quick straight-up, straight-down flight was quick to fly. For me, the contracts for readings (or crew reports or whatever) from specific locations on Kerbin fail on both counts; but that type of contract on other bodies is often worthwhile. Interplanetary contracts and rescue contracts are time-consuming; the interplanetary ones can have payouts to match though. Build your final stage / payload as small as possible; build your first stage as cheap as possible. Once you have access to decent probe cores, every rocket that can be made unmanned should be. My first stage is almost always SRBs, or for rockets too big to be lifted with 4-6 SRBs I add four or so to burn in parallel with the first stage. Reusability isn't worth your time, in almost all circumstances. Build cheap rockets to fulfill contracts that pay decently, and the few percent that you could improve your profit margin through reusability just won't matter. (OTOH, if SSTO spaceplanes are your idea of fun, then go for it! But don't feel that you have to.) You'll probably make your first missions beyond LKO before upgrading your facilities to the point of having patched conics or maneuver nodes. Remember that the Mun's SOI is larger and easier to hit, but landing on and returning from Minmus is cheaper in terms of delta-V. Minmus contracts usually pay slightly better. You can get to either moon, at least to high orbit around either, with tier-0 facilities. Career mode, especially at higher difficulty levels, really pushes you to go out as far as possible and do as much as you can with limited parts, limited launch weight and part counts, limited assistants. It also pushes efficient rocket-building and -flying. (Or, you could say it heavily punishes inefficient rockets and inefficient flying.) That won't appeal to everyone; if you don't want to play on those terms you'll likely find other game modes more fun. The worst part about KSP career mode is that it usually can't tell you when you've lost! If you find that, for whatever reason, you're stuck flying the same old missions over and over, and it's become tedious -- then you have lost. Technically you can keep playing and it's possible that you'll improve and eventually progress in the game, but if you're not enjoying it then what's the point? Better to just give up that save (or 'put it on hiatus' if that's easier to swallow) and start a new game at a lower difficulty level or in a different mode and get back to doing things that are fun.

Yeah, that solar panel doc was a bit sparse. I had started writing it up before I realized how little was there, but decided to leave it in and let someone else make an editorial decision on it. Cool, I'm glad you found the others worthwhile! That series of NASA docs is pretty dated by now, but I had them on-hand so I started there. I know they made a series of documents that gave nice descriptions of STS components (good for dimensions, RCS placement, etc.); if I can remember what they were called and find them again I'll post them as well. I'm sure they're in NTRS somewhere, but that's such a huge database that it can be hard to find anything specific.

In response to a list of ideas Cpt. Kipard posted a few pages ago, here are a few resources from older NASA docs that might be useful: Rocket engines and tankbutt: NASA SP-125, Design of Liquid Propellant Rocket Engines, is an early edition of Huzel and Huang's text on liquid rocket engine design. There are newer editions that are probably more relevant to modern engines, but this one is a NASA publication and is freely available. It can be found here: http://ntrs.larc.nasa.gov/search.jsp?R=19710019929&qs=N%3D4294129240%2B4294965930. It's a long document; some items of interest include Figs 3-2, 3-4, 3-7, 3-10, 10-10 to 12: biprop liquid engine layouts (both pump and pressure-fed); Figs 4-20 to 23: thrust chamber layouts; Figs 8-1 to 3: tank and engine configurations; Figures 9-1 to 5: engine mounting and interconnecting components; Figure 9-19: possible propellant duct routing for a gimballing engine; Figures 9-23 to 25: gimbals; Figures 10-26 and 27: photos of engine clusters. Most of the information in this book is probably too fine-grained detail to be of interest to most, but if you want to make sure your engine is realistic by actually doing the engineering design ... RCS placement: NASA SP-8028, Entry Vehicle Control, located here: http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19700019228.pdf. The figures in this monograph show the locations of RCS jets for control during re-entry for Mercury, Gemini, Apollo, and X-15 vehicles. SEDR 300, Project Gemini Familiarization Manual, ought to be a good resource for this as well, but what I think is the relevant chapter (8, Guidance and Control Systems) is omitted from my copy as it was confidential at the time. I believe the whole thing is in the public domain now, but I can't find a version on any NASA servers. Perhaps someone else knows where to find a complete version. Solar panels: NASA SP-8074, Spacecraft Solar Cell Arrays, can be found here: http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19710028154.pdf. This one is mostly about the electrical and thermal design of solar cell arrays, but some Figures 14-16 show some mechanical layouts. --- NASA released a whole series of monographs on subjects related to space vehicle design in the late 1960's through 1970's, numbered SP-8xxx, which you can find listed in this catalog: http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19810013465.pdf. Generally each is focused on a particular design area (e.g. wind loads during ascent or solid rocket motor igniters), and so does not contain much big-picture information that a modder might be looking for to just determine how something should look. But they're worth knowing about.

This is an interesting idea. Please update this thread when you do create the thread in Add-on Development, so those of us who don't normally look at that board know about it. I have a background in mechanical engineering and it's conceivable I could provide useful input to someone. To me at least, the format of an add-on author asking specific questions or asking for advice on a specific design makes more sense. I'm aware of lots of types of mechanisms, machine components, connectors, etc. but I have no idea what modders are working on. I'm not inclined to just start writing up things I know about, because most of it would likely be wasted time.

PakledHostage, you are correct. The Falcon 9's second stage put DSCOVR into the 187x1.37m km orbit. (See SpaceX's press kit here, where you can see that they were targeting a very slightly lower apogee. The webcast on NasaTV also made it clear, that orbit was achieved after the second burn of the second stage, before the spacecraft separated from the stage.) According to spaceflight101.com, DSCOVR carries enough fuel for about 600 m/s total delta-V. That's to last over its entire lifetime, so is mostly meant for stationkeeping; it's certainly not enough to get the spacecraft to L1 from anything but an orbit that already gets it very close. Also, the second stage does achieve escape velocity, and in fact will be disposed of in solar orbit. (See SpaceX's filing with the FCC for the launch here, where they state "... launch vehicle Earth-escape second stage to be disposed of in Sun." "in Sun" is believed to be an error, where what they meant was solar orbit. The delta-V required to drop the stage's solar orbit's periapsis into the sun would be enormous.)

Thanks! I'll look for a local copy (of that or any edition). If you have a tight-fitting duct arranged so that you can be sure all the air going to/from the fan must pass through the heat sink, you shouldn't see any dramatic difference in heat transfer from the heat sink between sucking the air through or blowing it through. But there are other considerations: The air that my ~4 year old laptop exhausts can get pretty hot. If the fan were arranged so that it was pulling the air through the heat sink, the fan itself would be in that hot airstream. The fan bearings and motor would then operate in a higher-temperature environment and might fail sooner. The fan would also be dealing with slightly lower-density, higher-kinematic-viscosity air, so it would probably move a slightly lower mass of air through the heatsink. Also in this laptop scenario, the duct itself would become hot and would heat up all the laptop components around it. Blowing the air through the heatsink makes it possible to put the heatsink right at the edge of the laptop so that the hot air is immediately exhausted to the surroundings and doesn't heat anything else up. If you hold a running computer fan in the open air, on the intake side it pulls in air from all directions. That means the air velocity on the intake side stays pretty low right up until you get to the intake of the fan itself. If you place an obstruction such as a heat sink near the intake, the air would also come to the fan by the path of least resistance -- the air would preferentially flow around the heatsink through the largest gaps it could find and a significant amount of air would go through the passages of the heatsink itself only if all other larger gaps were blocked. On the other hand, on the exhaust side of the fan the air exits with the momentum imparted by the fan, which will carry it some distance as a jet. The effect isn't so strong for computer fans, I think, because the air exits with significant radial and/or angular velocity so it forms a weak cone-shaped jet. But if you put a heat sink in front of the exhaust side of the fan, you can count on that momentum of the flow to at least carry some air into the heatsink and do some good, even if there are gaps around it. Anyway, those are my thoughts!

Ah, perhaps we were talking past each other a bit. My background is mostly in incompressible flow and the OP posted those diagrams of subsonic flow around airfoils, so, yes, I defaulted to talking about low Mach number, incompressible flow. Could you recommend a reference that expands on / explains "...at high mach numbers, pressure gradient across boundary layer is very high"? That's outside of my experience, and outside most of my references which deal with incompressible flow, and I'd like to learn more.

Sure, viscosity is necessary, no disagreement here. In the context of ideal flow, the way I usually see it argued is that viscosity is what explains / enforces the Kutta condition, which can't really be proved or explained purely within the ideal flow model. But it seems to me that if you're concerned about the Bernoulli principle being invoked as the fundamental cause of lift, the problem isn't that it neglects viscosity, the main problem is that the principle, by itself, doesn't explain anything! The lift force is a result of the flow field around the airfoil and the Bernoulli principle can't explain what that field should be. You need the full Navier-Stokes equations. But, if you've already determined the velocity field by other means (e.g. a wind tunnel), you can invoke the Bernoulli principle to explain the regions of high and low pressure that add up to the lift force. (And that works! Though you could also use the pressure gradient normal to curved streamlines and avoid talking about Bernoulli at all.) -- edit -- Whoops, ninja'd several times over. That deserves repeating, especially since I think I've seen it said otherwise in this thread.

But once you go through the boundary layer to the surface of the airfoil the Bernoulli equation becomes irrelevant, because it applies only as long as viscous forces are negligible. In conversations at this level, it is usually taken for granted that we are talking about a high-Reynolds-number flow (and flow that isn't separated from the surface) so that the boundary layer is thin compared to the airfoil and there isn't a significant pressure difference across the boundary layer. Then one needs to deal only with the irrotational flow outside the boundary layer (where the Bernoulli equation does hold) to get a reasonable approximation of the lift an airfoil produces. Though I agree with the larger point, that simply naming an effect is not an explanation. There's no law that says the behavior of a reasonably complicated system must be able to be accurately explained in a few words of english.

I'm playing a hard mode career, no mods. I really liked how constrained this made the beginning of the game. Since I couldn't afford to upgrade my facilities for a while, I really had to think about which contracts I took and how I fulfilled them, and there wasn't lots of margin for error. The only part that's felt grindy so far was when launchpad weight constraints meant I had to launch my Munbase with barely enough fuel to reach orbit, then fly three refuelling missions before I could send it to Mun. That said, I haven't fully upgraded my R&D center yet and that might become a grind.

Glad to hear things are picking up! Hope it stays fun!

If you can afford to drift for a few seconds during your launch, you can activate the engine by right-clicking on it when it comes up next in the staging sequence. Then, when you get to the point where you want to test it, shut it down by right-clicking again, then stage it. I've used this technique a couple of times in just the situation you describe (have tier-1 buildings, need to test a relatively heavy engine). And yes, that 'run tests' option definitely was there in 0.25. I run completely stock and remember seeing it.

I second this -- be judicious in the contracts you take. 'Science from space around Kerbin' was a good very early contract for me -- just two small SRBs will take a capsule into space where you can get a crew report, so it's very cheap and low-risk to fly. The parts and mass limits make it hard to do multiple testing contracts at the same time, so I've mostly avoided them. Forget reusability; with the parts available early-on in stock it would be hard to recover very many parts, and at their prices it's not worth worrying about. Make your vessels as simple and small as possible, which will also make them cheap and allow you to do more before upgrading the launchpad or VAB. Use SRBs for your first stage (and second stage when the thrust levels make sense). They'll give you lower part count than a stack of tanks on a liquid-fueled engine and they're cheap. My first building upgrade was the mission control. There may be better approaches to upgrades, but that worked well for me (so far). With the upgraded mission control I could take on all the early exploration contracts (Mun, Minmus, Ike, and Duna) and get their advances, and since those contracts don't have deadlines I don't have to scramble to fulfill them and can do other contracts while I work up to them. I was able to get a craft to go around Mun before upgrading the launchpad. I just used a 30-part vessel (made in the tier 1 VAB) to land on Minmus and fulfill that exploration contract; with the funds from that I can upgrade the astronaut complex. Now I can EVA and do the rescue contracts, and future missions will start bringing in better science returns (EVA reports). Edited to add: OP, you mentioned grinding a lot. I haven't had to grind much at all so far. I took a 'science from space around Kerbin' contract maybe thrice; nothing else has repeated yet. Take only the contracts that are worthwhile, and practice making the minimum rocket that will fulfill it.