Dave Kerbin

Don't feel bad about it. I think when we are talking about breezing through the tech tree we really mean that about 80-90% of the useful parts (things like the nuclear engine) can be obtained in only a handful of normal but well planned missions. Until you visit another planet or two, or you start covering the entire Mun in flags you won't have actually maxed out the tech tree. If you are having trouble my first suggestion would be to try and focus on the science items near the bottom - unlocking these lets you get even more science. Once you reach the last science item, the GravMax, you can build a probe that just orbits around Kerbin, the Mun and Minmus collecting massive amounts of science.

Ironically I'm pretty sure all the units of measurement where shown in the old tooltips (before they made the right click for more info in .23) with the exception of the crash tolerance which was just a mysterious number to most people. Now the crash tolerance is the only figure that actually states the unit of measurement and everything else is a mysterious number.

Correct.

Liquid fuel+oxidizer has the same mass regardless of the container. First there is the ratio of Liquid Fuel to Oxidizer, which is 9 parts liquid fuel to 11 parts oxidizer. Since you usually carry both (unless you are building a jet engine) I ignore this value. Fuel:Oxidizer = 9:11 The next important value is mass. 200 L of combined fuel/oxidizer is equal to 1 ton, however we usually don't work with a combined figure. Looking at it from a Liquid Fuel perspective you have 90 L of liquid fuel (plus the required oxidizer) is 1 ton. 90 L Liquid Fuel = 1 ton (assuming matching oxidizer is included) Finally you have the tank weight. With the exception of the two tiny tanks (the Round8 inner tube and the tiny Oscar) all the stock tanks have the same ratio of fuel to container mass, which is for every 8 tons of fuel there is 1 ton of metal container. Fuel:Container mass = 8:1 I use these regularly since I've got Excel instead of Engineer redux, though I remember the ratios using slightly different numbers: A 9 ton tank Contains 8 tons of fuel Which includes 720 L of liquid fuel From those numbers it is easy to determine wet/dry values. For example if I write that I need 180 L of fuel, then I get a wet mass of 180/720*9 (2.25), and a dry mass of 180/720 (0.25). For the Oscar and Round8 you just need to get the values from the VAB or Wiki. Both of them have worse fuel:tank ratios (about 5:1) and use very small non-rounded numbers for the fuel so they can be a pain to work with.

While I do share your opinion that budgets/reputation will help career mode and will add more balance I think that my current .23 career file (warning, bandwidth heavy) shows that even budget missions with simple goals (no grand tours or 500 ton ships), when planned by experienced players, result in a ton of science that is not entirely in proportion to the tech tree. I planned out my program requirements thinking I'd be challenged in my early planetary missions. Instead I had to constantly find other things to spend science to avoid having nuclear engines and mainsails on my first trip. I actually considered the idea that I might not have probe cores or seismic sensors when the relevent missions came up...how wrong I was.

I know that things like difficulty levels are very far in the future in terms of being properly implimented in the game, but for now there are already several 'hidden' options included in the save file which can be used by players to change the difficulty. What I'm asking for is a tech cost multiplier to be added to the save file, default being 1. This would only be used in one place, the science building when viewing the tech tree. The costs shown would be multiplied by that amount and when the button was pressed the value subtracted would be the same. So for example if you changed the value to 2.5 then the most expensive items in the tech tree would now cost 1375 instead of 550. This wouldn't affect items already unlocked, it would just be a few lines of logic added to the tech buy button and the display label.

I guess I'm alone in finding career mode almost too easy. I find everything up to the 45 cost tier is roughly balanced for new and experienced players, but after that it seems really easy for a more experienced player to blast through the tech tree just by visiting the Mun or Minmus. I should make a suggestion about that.

I am close to flying phase 3. As I said before it will all sort of be one mission since I'll need to switch between them to handle burns and captures at the right time, though I'll try to break it up into 3 distinct reports. In game the whole phase will take about a year from the launch of Martian to the return of Tyson. I was asked about the design process so I'll try and share a bit of that. Design for a mission starts with requirements gathering. First I need to know where I am going which is usually a single planet though I have figured out multiple planet missions for non-career challenges. For career the next step is figuring out what science I should be trying to collect. For a manned mission I usually aim to collect 'everything'. For the one use experiments (goo, science jr) this tells me how many I will need to carry. With the way science works in .23 (data can be moved to the command pod) I can also determine how long into the flight an experiment needs to be carried. For the reusable experiments it is usually safe to carry just one, but time/safety restraints (like descending through an atmosphere or braking) can raise the requirements since I'll need to plan on storing the results until they can be transmitted/collected. The next step is creating my own delta-v map. I don't get fancy with graphics, it's usually just a few columns in Excel or even just scratched down on a small notepad. To create the map I use a few sources. For landing I use the common cheat sheet with some safety factor thrown in. Unfortunately I find this map loses accuracy the farther you go out - flying to Duna or Eve is fairly safe, but the inclined planets start to get really far off. In fact the values for Dres look like they would fit exactly if Dres where on a circular, non-inclined orbit. For a better idea of burns I look at the alexmoon's Launch Window Planner, which is a handy bit of javascript that calculates raw delta-v values fairly accurately. Since I fly manually a lot of the values it gives are more of a guide. Without an in game aid like Mechjeb or protractor the easiest way to use the values is to calculate a mid-course plane change maneuver (rather then the more direct ballistic). The values calculated can be used to device a stop watch flight plan. The first burn can be checked for accuracy by comparing the resulting AP/PE, while the second burn has a more obvious intercept. Once I have some idea of the requirements (I add a safety to the delta-v) I begin building a ship. To do this I don't start up KSP, I start up Excel along with a copy of the parts list (of which I've now made several corrections since my delta-v numbers depend on it being accurate). I do know the mass and where applicable isp and thrust of several parts by memory, and importantly I know the fuel mass to container mass for fuel tanks (8:1, and also that 8 tons of fuel = 720L of liquid fuel). The ship is then built in reverse - I start from the very last stage of the mission and work backwards from there. Because it is done in Excel using some basic forumulas and I can make cascading changes - I can add or remove components and immediately see the effect on the mission. It's not the prettiest looking but it's not intended as a strict formal blueprint, rather I treat it more like design notes and frequently have comments written in the margin. Once I've proceeded far enough that a design seems viable I'll build it in the VAB. Not all designs can be built (this is especially an issue with micro probes) though over time it becomes more intuitive as to what parts you can pick in what combination (for example ensuring enough space is available for mounting radial parts) and I can usually picture what it should roughly look like while picking the components. Once a design is finished I'll come back and review it after spending some time away. For the review I usually start from the beginning, figuring out the requirements and then walking through the ship design. This helps find oversights (does the ship have landing gear? Did I make a typo when recording the delta-v requirement?) and can suggest design changes. One thing that generally comes last is the design of a launcher - in fact I'll usually design, iterate and build the ship in VAB several times before I get to a launcher. With the aid of copy and paste I may test multiple designs, either partial changes (keeping the upper stages but changing lower ones) or completely new designs. For example for Martian and Tyson I went through at least 6 more formal designs and probably another 6 improvement designs that where discarded when it became obvious they wouldn't be superior to the original. One of my requirements for Martian and Tyson was that they properly reflect a budget mission. That didn't just mean that they should be light and that only one would get a nuclear engine. It also meant I wanted them to share parts, in much the way that the Apollo spacecraft and Saturn launch system was reused for many missions (orbit, moon landing, Skylab, Apollo-Soyuz and was even on the drawing board for a Venus flyby). To that end I wanted both missions to use the same LKO launcher (which meant they should have roughly the same mass) and wanted to try and use the same lander with minor, plausible differences that suggest they still came off the same assembly line and where covered by the same testing regiment. With my spreadsheets and iterative design I went through a number of designs and a number of mission profiles. Universally the mission to Dres was the better target for the nuclear engine. I found the difference in mass between a nuclear and non-nuclear Duna mission as little as 1 ton. The 3 main profile variations I covered where a direct ascent, orbital fuel renderous and orbital transit renderous. The simplest mission profile was direct ascent (during the early Apollo program this was also the prefered method of going to the Moon because it was the safest, but the required launcher was outside the technology of the time). In a direct ascent a single ship sheds stages as needed to reach the planet, land and then take off and fly back. In my case it was also the safest approach, particularly for the Dres mission (Tyson) where it allowed left over delta-v to be carried over throughout the whole mission. The next mission profile was an orbital fuel renderous. In this scenario the fuel to return home is left in orbit instead of being carried all the way to the surface and then back up again. This configuration requires a docking port on top of the ship, which in turn means that the command pods parachutes need to be attached to the side. Early on this wasn't as much of an issue (the command module used the XL chute which could be cleanly split into 2 radial chutes) but later iterations brought the weight down so that only a small chute was needed on the command pod, which meant this setup required 3 times the parachute weight in order to mount a docking port. For Duna this mission profile could cut between 2 and 3 tons compared to direct ascent, however it created problems for Dres where the balance between the cost to bring mass down was less and the delta-v required for return was more, resulting in the Duna lander being too different from what the Dres lander needed. Even if they used different sized fuel cans left in orbit it would still require two distinct lander designs and I didn't want that. The last profile came from the thoughts about parachute placement. I considered the idea of placing the docking port on the bottom of the command pod (instead of a decoupler). One thing I should note is that ever since .23 came out I've wanted to get to the point where I could build my escape pod - you'll notice there is Kerbin Land Stage with 175dV. This dV is not included in my mission totals but is kept in reserve. It is made possible because of the small amount of monopropllent carried. Not only is the small amount more attractive then the larger tanks that where previously available, but the tank weight is essentially free. This means I just need to add 2 RCS thrusters and solar panels and I have a tiny spacecraft. In the orbital transit renderous profile the ship returns to orbit but instead of docking with a fuel tank it uses the underside docking port to discard the fuel tank, engine and ladder from the lander. It then docks with the remains of the transit stage, using it's more efficient engine and remaining fuel to return. Despite sounding good on paper this design was actually the worst. Because the payload was so little (just short of 1 ton) the mass of the return engine became a serious factor in determining how much fuel would be required. For Duna I could at best break about even on the return requirements but for the longer Dres mission the heavy nuclear engine made the reuse of the transit portion a big loser despite having more then double the ISP (2x ISP isn't worth it when the ship is more then 3x the mass and empty fuel tanks approach the weight of the intended payload). Ultimately I think I've come down to a final lander design. The Duna mission uses the full lander while the Dres mission uses a 95% assembled version - the 3 descent parachutes are never packed (leaving just the cones) and 3 small atmospheric instruments are never installed on the outside of the material bays. The pictures aren't perfect. The first 2 are from the prototype lander which doesn't quite get the rotation of the outer pods right (they are facing 60 degrees off). The third shot is the Dres version with a bit of the lower stage visible but with the atmospheric parts left off and the pod angles corrected. The mass of both missions in LKO is just under 15 tons. As is common in a lot of my designs the goo containers also serve as landing legs. The placement of the instruments on the pod is also not by chance. From previous missions I found that putting the instruments I wanted to get readings from on the pod was very convenient, since it made for a quick EVA to collect them (never leave the ladder). This convence overrode the dV gains by placing them on the lower section. Th gravity and temperature meter where placed by the hatch since those instruments would need to be checked several times in flight. The antenna could be placed on the back along with the seismic meter which only collected one reading and so didn't even need to be collected, it could land with the pod back on Kerbin. There was also an earlier design that went through about 2 iterations before I refined it into something that looked like the final lander (which went through at least 4 iterations though mostly in the transit design). The earlier design used 4 pods instead of 3 and had a heavier fuel load, resulting in a LKO mass of 19 tons. At one point the fuel renderous design for Duna weighed in at 12 tons in LKO. The earlier design also placed the small instruments on the science jrs, so they could be dropped later. You'll notice more instruments on the back and a second access ladder. The revised design simplified the number of instruments (just 3) and placed them low enough that they could read from the ground. For the Icarus mission I think I have a final design but I want to share this earlier one. For the mission requirements I quickly eliminated goo containers (mass vs. science return was terrible) and slowly wittled down the number of science jrs to 0 as well. During requirements gathering I determined that Moho (I've never visited it yet) would have a short capture window based on other peoples posts so it needed to be a chemical rocket. However this earlier version uses an ion engine for the initial transit phase - it actually has over 1000m/s of extra delta-v, since I figured I wouldn't be able to do a direct burn due to the low thrust, so I'd need to thrust out of Kerbal's SOI, then slowly setup an encounter with Moho. It also is a bit different in that it launches upside down. The two boosters (set for something like 30% thrust, the calculations are in the spreadsheet) are there to help lift up the fuel since the T45 can't carry it all. Once enough fuel is burned and they are exhausted they are released, followed later by the side fuel tanks. The T45 finishes carrying the probe to orbit where it detaches (the stack decoupler) and turns around to face the correct direction. At that point the 8 solar arrays (top of picture) around the ion drive spread out. After entering Moho's SOI the ion drive and its solar array are ejected, revealing the chemical rocket. The T200 and T100 fuel tanks at the top of the probe (connected by a jr docking port so fuel will flow without ugly fuel lines) power the engine for the capture burn. Then those big tanks are released and only tiny probe (roughly the height of 3 oscar tanks) lands.

This might not be the best answer for you, but if you goal is just to return to Kerbin (a parachute landing, no fancy orbit) then a direct burn from polar orbit should be entirely possible without losing much delta-v. You just need to plan it manually without mechjeb (mechjeb has a specific program for figuring out how to reach a goal and it will try altering everything else to fit that program instead of improvising - you can see this when it uses tons of monopropellent to dock). Drop down a maneuver node, pull the prograde side out until it reads about 1500m/s, then zoom out to see Kerbin and set it as your target. Now move the node around until it shows you moving into a lower sun orbit instead of a higher one. Push or pull the prograde handle until you have a close encounter with kerbin (little grey arrows appear), then try fine tuning, first with the prograde handle and then with the inclination handle. You may need to move the node a bit too. Alternate between the two until you have a proper encounter. At that point you do the burn and wait until you are outside Duna's SOI. Now plot a much smaller maneuver node (or even just use RCS translation with trial and error) to lower the PE of your Kerbin encounter below 20km.

It really depends on what you need to get to the Mun and then to other planets with your current skill set. The comments so far are all good. Since it sounds like you are not at a Scott Manley you should definitely get all the techs that cost less then 45 each (all 4 of the odd priced techs) and then Science Tech. That gives you the basics to go to the Mun and Minmus (just pack some batteries) and gives you the Science Jr which is the highest value science instrument you can use until very late in the tech tree. From there I would suggest getting the other 3 items that cost 45 science before investing in items like Fuel Systems, Electrics and Space Exploration. If you've been having trouble going to the Mun or Minmus these techs will help. From there it depends on how far you want to go - there is a lot of science on the Mun and Minmus (just try landing in different places). If you are happy staying near Kerbin then you can get a lot of mileage by pursing the techs at the bottom of the tree - Advanced Exploration, Advanced Electrics, Electronics and if you can finally afford it Advanced Science Tech. Investing in these early can greatly increase the amount of science returned by future missions. Now all this really depends on your skill level in piloting and design as well as how many times you want to land on the Mun or Minmus (the Mun has dozens of different biomes, each one can be explored for more science). For example I was planning out my tech purchases like this.

Ok, it looks like my solution will be a spreadsheet template with spots for the UT and MET pulled from the save file after launch, and then places to enter a date or MET that will be converted to the other.

As far as I can tell the only way to see the in game time (year, day, hour, etc) is to visit the observatory, while flying all you can see is the mission elapsed time (MET). You could flip between flight and the observatory to get the two values as close together as possible (or view the save file in a text editor for UT and met), then perform a subtraction to get the mission start time which could be added to MET each time you need to know the date. But I'm wondering if there is a simplier way to get the universal time/date while in flight playing stock KSP, maybe clicking somewhere on the MET display switches it?

Even if the medals and even display where not immediately implimented I'd love to see the stats start to be tracked in the same way as the overall program is. If you examine your save file you'll find information about things like highest flight, first landing on Mun, name of ship, etc. I think that a copy of these stats should also be attached to whatever kerbal was in the ship when they where recorded. Later on the features like medals could be implimented (a ribbin for orbiting, a medal for landing?)

There's something that's always bugged me about the LV-1 (the engine for ants), it doesn't have a shroud when you attach a decoupler or docking port to the bottom. Instead it sort of just stands there as this little flimsy thing that ruins any appearance of the ship having structural integrity. With a docking port (regular or Jr) it's really bad, since you get this big open area visible below it, like the engine is just floating. Since I design my ships with at least some attention to 'realistic' appearance this pretty much rules out using this engine despite some cool designs that could use it. Can the LV-1 just get a copy of the same shroud that is given to the Rockomax 48-7S (the tiny 0.1t engine)? The only issue I could see is the 48-7S is a fraction taller - maybe it could be clipped a little shorter for the LV-1.

With phase 2 complete I'll be starting on phase 3 soon. Phase 3 will work a little bit different - I'll be planning out all 3 missions at once since they will launch in sequence and with varying travel times they will overlap as to when they land and return. I'll also be trying to keep the budget down in a somewhat realistic fashion. Expect the manned Duna and Dres missions to share a lot of common parts in the name of cost savings. I've expanded the tech tree with what I think I might use (or what is required to get it). There is 423 science left to spend. Unlocked techs are: Heavy Rocketry -> Heavier Rocketry, Specialized Control -> Nuclear Propulsion Advanced Construction -> Specialized Construction -> Advanced Metal Works Landing, Ion Propulsion, Advanced Unmanned Tech

The challenge was to land the largest mass using the 'fewest' engines (no parachutes). Scoring was based on a value for the planet, engines used and final mass of the ship. The way the scoring system worked the Mainsail was the obvious choice - in order to land you need a TWR > 1 so you can easily determine the maximum starting mass of a lander. Dividing by score the Mainsail was had a better ratio then the other engines by a large margin (large enough to ignore any differences in ISP). Planet wise Kerbin had an atmosphere and that meant you really didn't to burn as much fuel to land, since drag would remove everything but terminal velocity. Score wise Eve was better (scores seemed to be based on gravity) but Kerbin was obviously much closer. The basic strategy I assumed is that you want to burn as little fuel as possible (to keep the weight up) which meant you wanted to counter the minimal amount of velocity. Every second that you are falling gravity is adding to your velocity, so you want to burn for the shortest period possible. If you 'hover' you are just providing gravity with more time to add velocity that you'll need to kill later. So my calculation was determining when I should turn on the engine so that under a continous burn I would be at landing velocity (<12m/s) just before I touched the ground. First I got some numbers. My ship would be just under 153 tons (1500 kN / 9.8m/s) in order to have the minimum TWR. From the wiki it would consume fuel at a rate of 109.11 l/s at sea level. Since I would be near that I decided to just take that as a constant value (I figured that the human factor would add a much larger margin of error then the fuel consumption difference). Finally I needed my terminal velocity, which I figured by tossing my ship up 5km and letting it fall down. This is a rough recreation of my spreadsheet, some of the initial values are approximate but the final values seem to be close enough to match. My method won't make the higher math folks happy, I've forgotten most of my calculus which could have probably boiled this down to one nice equation without all the errors I've introduced. In the first column A you have how much time has passed. The second column is how big of a time step I'm going to use which is where the calculus folks will cringe. The smaller a value I use here the more accurate the results. KSP experiences the same thing, since it calculates everything in descrete steps. When you use physical timewarp (2x-4x) you are increasing the size of those steps so that fewer have to be done to cover the same amount of time at the cost of accuracy. Column C has my initial mass and every row following is carrying over the value from the New Mass column (L). D, E, F and G are constants for the engines thrust, fuel use, gravity and a calculation of how many tons of fuel are burned for each time step. Column H is my current velocity, which is initially terminal velocity and then carries over from the last rows New Velocity value (K). Column I has my calculation for the ships current thrust, which is just engine thrust divided by current mass. The acceleration (J) is the difference between thrust and gravity and new velocity (K) is the old velocity plus acceleration. New Mass (L) is the difference between the old mass and the fuel burned and finally distance is a running total based on the velocity multiplied by the time passed - this is how much vertical distance the ship has fallen since the burn at terminal velocity started. Using range copy and paste I can duplicate this to hundreds of rows in a single step which is the brute force math part. Scrolling down I find that in just over 15 seconds I should reach landing velocity. The important figures are that by that time my mass will be around 130 tons and most importantly I will have fallen 1400m. Armed with that figure I now have a close approximation of what distance above the ground I should start burning if I want to be at the right velocity when I reach it. Conveniently the radar altimeter has a notch for 1500m which provides enough breathing room to account for human reflex time and the margin of error inherent in my calculations (time steps, fuel usage assumptions, terminal velocity assumption, perfect pitch, etc). In my low altitude tests these numbers worked correctly. I started a burn at 1500m and I typically stopped just before I hit the ground, letting me adjust the thrust a bit and land with 120 tons of mass. For my real orbital drop I was a fraction late which put me even closer to the ideal numbers, hitting the ground at practically the exact speed (I had no chance to lower thrust, just cut it when the landing gear hit) and landing with 125 tons of mass.

You need to be in low orbit, atmosphere or on the surface to take temperature readings. If it says you are 'high above' a location then you can't.

I considered using ion power but it was just too heavy - the mass of an ion engine, tank of xenon and a single XL solar array weighed more then my entire liquid fueled probe including all the instruments. Specifically here is that prototype version which once in LKO weighs less then the lightest manned pod (0.57t I think). The final Berry 1 probe weighed 0.83t fully loaded I believe. This prototype version is lighter because it removes the heaviest component besides the fuel, the parachute. Instead it had ultralight landing legs and with the higher ISP engine and lower weight it had an extra 220m/s of delta-v which was to be used to land it after hitting terminal velocity on Eve. The lighter design also had a simplier launch system thanks in part to the probe's engine having much more thrust. This meant it was practical to tie in the launch boosters fuel supply and use the probe engine to assist in lift off. The essentially SSTO design required a little more fuel (the Round-8 tanks) but saved a lot of weight because it didn't need decouplers or the higher thrust but much heavier LV909 engines. Ultimately I scrapped this version because I knew that I had little hope of doing a powered landing on a high gravity planet, especially with a probe that weighs almost nothing and an engine with a huge amount of thrust making it very difficult to finely control my descent speed. With 220m/s of fuel vs about 85m/s terminal velocity I'd really only get one chance to get it right. I did look into using the barometer as a makeshift radar altitude meter - if it was accurate enough I could have made a stab at doing the landing mathmatically like I did here.

Berry 1 The goal of Berry is to investigate the surface of Eve with an unmanned probe, however the project has been subjected to harsh budget cuts after the fallout of Mint 1. The actual mission itself has experienced some out of game issues - I discovered that trickle charge transmissions don't seem to want to work one way or another in .23 (either a bug or an intended feature that doesn't quite work as intended). I also had an issue with recording. While the recording animation was playing through the whole mission and I stopped it correctly before exiting I found out that afterburner had frozen about 40 minutes in. Killing the process let me access the video file which stops a little while after the first aerobraking, leaving me with a lot of lost footage that I have no way to recover (I can't even replay the mission since I'm playing a single save file). With the budget for Berry being essentially nothing the space center has to make do with what is sitting around and what they can put together with the office budget. They can't even afford to pay the gantry crew or operate the crawler, so instead it falls to Rayfrod and Gregfield to get Berry 1 on the launchpad. The setup starts at 5am before the sun has come up. Rayfrod and Gregfield manage to unlock a side door and begin gathering up used engines from the R&D office. At just over a ton each they need to be rolled one by one up to the launch pad and stood up. Work carries on to about 10 and then its over to pickup the probe. The parachute seems to be new, but the instruments look like they've been taken from the simulator and the unique fuel tanks, which neither Gregfield or Rayfrod have seen before, look suspiciously like metal waste baskets welded together and a life preserver from the zero gravity pool wrapped in plastic. Did we really need space suits for this? As noon approaches Berry 1 is completed on the launchpad. Time for lift off! Ok, zoom in a bit. Now time for lift off. No fancy fuel lines or anything here, after the powerful first stage exhausts its fuel supply it is released and the 2nd stage fires up to take Berry 1 to orbit. With a 71x73km orbit established and 12.9L of fuel left in the booster tanks it's time to plot a course to Eve. The boosters give me just over 5 seconds of burn before they are discarded for the main engines. This is a 4 minute burn for Eve and due to the angle and length of the burn I actually cut through the very top of Kerbin's atmosphere on the way. From the look of the exhaust and the sound I'm not sure if those are real rocket engines or just office fire extinguishers taped to the side. Once outside of Kerbin's SOI a small adjustment is used to refine the Eve encounter to 70km. That will be further adjusted once we reach Eve's SOI. One small issue is transmitting science - if we don't have enough power then the transmission speed slows down while it waits to recharge between each packet. However after the first one we stop getting science. If we check the missing science seems to be available to be transmitted on a second try, but it will transmit 0 science instead. The only way around this seems to be by time warping, which slows down the transmission rate relative to the actual in game clock (transmissions still take the same amount of real world time, but the in game clock is moving faster) while the solar panels recharge using the game clock (so more power is recharged between packets, preventing the battery from reaching zero and causing the bug/'feature'). It's far from an ideal solution and I will be unable to fully transmit some of my major findings (I won't be able to use time warp for the sensor nose cone in the atmosphere, which means despite planning on plenty of time I'll get about 10% science instead of 35%). Once we reach Eve the PE is lowered to 59km for aerobraking. I want to get into orbit so I can choose my landing site, it needs to be on the daylight side and over land (the probe can land in the water but this disables 2 major instruments). It takes drops of fuel (7m/s) to adjust our orbit. At this point it seems that afterburner had silently frozen up and wasn't actually writing video any more, just showing the spinning record icon in the corner of the screen. So the only pictures I have from this point on are those I went back to the planet and snapped and the only numbers I have are those that I remember or scratched out to help adjust my orbit. The descent/parachute phase is lost. After first aerobrake took my AP to 11500km I adjusted the PE to 74km for another aerobraking pass. This lowered AP to 4800km. PE was raised to 85km and two more passes where done to lower the AP to 3800km with an orbital period of an hour or two. From there PE was raised to 120km to allow for 100x time warp so that the larger continent could rotate around to the day side. At that point much more delta-v (about 150m/s from a potential 350m/s left in the tanks) was used to setup a somewhat straight line for the big continent so that no matter how drag affected the path I would stay in the sun and hit solid ground. My plan was to run the thermometer and barometer in the upper atmosphere and transmit their data, then recharge while still falling before transmitting as much as possible with the nose cone from the upper atmosphere. However with the changes in procedure I missed storing all the readings at once, and because of the steep angle I fell right down to Eve’s lower atmosphere before I got around to taking a nose cone reading. So instead I stored a reading from the lower atmosphere before taking and transmitting readings for the thermometer and barometer and again. As I came in for a landing with the chute opened I followed the planned landing procedure which was to enable SAS and then use the W key to tilt the probe slightly again the parachute cord. This way when I lightly touched down on the nose cone (about 4m/s I think) the probe tipped over in the correct direction. The ROUND-8 fuel tank (orange tube) was placed to protect the probes sensitive equipment from contact with the ground. With the probe tipped over correct I had the antenna facing upwards, 2 of the main and 1 of the backup solar panels exposed and all the instruments accessible. Now the nose cone reading could be transmitted, followed by a full suite of ground readings after a recharge. Total science was less then expected, with 665 collected in total. Project Berry completed. Landed probe on Eve Collected 665 science. Science investment coming soon

Berry 1 is outside Kerbin's SOI, but the mission is on a bit of standby until I figure out how I'm going to deal with this bug. Unfortunately it has a big effect on one of my instruments and could mean a choice between landing safely and collecting data. Edit: I think I have a method to deal with it, basically it's transmission spam only with more work and I won't be able to get 100% of the science that transmission is normally supposed to give. I'm not yet sure of how big a loss I'll be taking on the main instrument but it looks like the factors involved will mean a lot.

The reason is the Oberth effect.

Depending on how you put things together there is another way without mods. Let's say that your 8 x 8 symmetry is this: You want to attach eight T800 fuel tanks (the tall skinny ones) to a big orange tank. Then you want to attach 8 radial engines (the tiny orange ones) to the bottom of each T800, for a total of 64 engines. Start with your orange tank. Attach a single T800 tank to the side, no symmetry. Now turn on 8x symmetry and place your engine on the T800 tank, which will place 8 engines around the T800 tank. Now click on the T800 tank (while still in 8x symmetry) to temporarily remove it, then snap it back where you had it. The tank (and the 8 engines) will now be replicated for a total of 8 tanks, each with 8 engines for a total of 64.

Ok, I got some bad news. The budget kommittee just got finished looking at the mission report for Mint 1. They are pleased to see the goals they set out where completed and that so much science was returned. But they are very not-so-pleased that the mission, which already had a stretch goal of a second landing (which was not a part of the kommittee's requirements) took on 2 additional landings and still had over 1000kg of fuel left in the tanks. With the cost to launch just 1kg of cargo into low Kerbal orbit they see this as a massive waste on the part of the kerbal space program. In their words this space program was designed to send Kerbals into space, not money. If the program is to be saved they want to see some serious cost cutting. For starters the kommittee has decided that the budget for phase 2 (small steps) is basically spent at this point. Project Berry will need to be completed using whatever parts are leftover in the VAB from the previous rockets and any remaining parts will need to be bought using the office supply budget. Furthermore the kommittee has caught word of the 'nuclear engines' now in development. These sound very expensive, especially with the rising cost of refined kranium and klutonium. They have decreed that a limited number of nuclear engines will be purchased for the program and will be dependent on the successful completion of each phase. For the next phase of the program, Great Journeys, they will provide the budget to purchase exactly one nuclear engine. For the phase after that (Inquisitive Minds) they will provide the budget for 2, and for the last phase they will provide the money for up to 3 more nuclear engines. Not wanting to stir things up any more the design office only invests in 2 new science ventures, Precision Engineering and Unmanned Tech. Unlocking anything else would be useless since there isn't the budget to buy anything much larger then a photokopier on project Berry. There is now 1958 science saved for later.

Mint 1 The design for Mint 1 isn't new, it is a copy of Cheese 1 which already matched all the delta-v requirements, the only changes are some science instrument upgrades. The inert nose cones on the 2 science pods have been replaced with Sensor Array Computing Nose Cones and the thermometers on the side have been replaced with brand new instruments, the PresMat Barometer and the Negative Gravioli Detector. The command pod now has one of each of the small instruments. The last change is the lander now has a ladder. After some barometer and gravity calibration on the launchpad it is time for lift off. Having used this ship before things go easily, the only change to the mission checklist at this point is that the nose cones take readings in the lower and upper atmosphere instead of the thermometers used on Cheese 1. Once in orbit an EVA is performed to collect all the data and return it to the pod. At this point the first real change in the mission plan is performed where instead of immediately plotting the required burn to the Mun/Minmus Gregfield instead begins performing a survey of the planet with the negative gravioli detector. It is immediately apparent that the easiest way to do this is to measure using the instrument on the command pod so that Gregfield can simply open the hatch, grab the results and hop right back in. The survey only covers the equatorial portion of Kerbin, so no readings are taken of the Tundra or Ice Caps but 6 other areas are scanned. After an orbit to perform the scan a trajectory out to Minmus is plotted. There was actually an opportunity to do a Mun flyby on the way to Minmus, which would have provided a chance for a few grav readings at no cost. However it wasn't in the mission plan and I didn't want to take any risks with Gregfield. With the default conic prediction I couldn't see details about the projected Minmus encounter. It still might have been interesting to risk it though not for the science (this was not the only opportunity for science that was passed over on this mission) The navigation was still done a little seat of the pants - no inclination change is made so the encounter with Minmus is going to be off center. The orbital stage has all the delta-v needed (Minmus requires more for an encounter but less for capture). If we don't capture at Minmus we will have an encounter with the Mun instead. On the way out from Kerbin a few more gravity readings are taken as the planet rotates under us, giving us a few high orbit values. Capture at Minmus uses up about half of the orbital stages remaining reserve, putting the ship into a 1400x19km orbit for surveying. Not much is really seen from high orbit - lowlands, midlands and flatlands - so Gregfield doesn't go around for another pass, instead bringing it down to a circular orbit. After some more observations the orbit in inclined a bit more to bring the ship over one of the low mint green areas where we want to land. The orbital stage has enough fuel left to completely brake the orbit. This is useful since unlike the Mun the surface does rotate under our inclined orbit, putting the landing zone near the edge of the area we wanted. The orbital stage is ejected 8km from the surface so we can begin slowing our descent for a smooth landing. It provides one more useful function by providing a visual indicator of how close the surface is. This is the third time this design has landed and it's on an incredibly flat site so there where no surprises. The ladder does make it a bit easier to get in and out. After a brief stay it's time to check out the higher ground. This time the checklist includes a fuel check, but the center tanks have plenty so there isn't even room to transfer from the side tanks yet. We might have upgraded the design by adding fuel lines to automatically transfer fuel but we didn't. Our destination is that flat plateau in the top center of the picture. Midway there a little thrust is used to gain altitude to make it over the cliff edge. Landing is fine but the legs don't seem to get a good grip on this soil of the plateau, the lander wants to wobble like an uneven table. Toggling SAS on and off gets the legs closer to the ground but it's still wobbling. To solve the issue the primary legs are retracted letting the lander rest on the secondary landing gear (goo canisters), then once the lander is settled the legs can be extended again and hopefully take an even grip. The procedure seems to work. Now it's safe to get out and do science. After the EVA the fuel tanks still don't have space to transfer the sideboard fuel without creating an imbalance. The earlier survey indicated several biomes and so far we've landed in the lower flats and the lowlands. Even though the goo and material bay are unavailable for use we could get several hundred points of science by exploring elsewhere. Gregfield takes off and heads toward an area that looks promising with some small hills inbetween the various higher plateaus. Unfortunately this turns out to be more of the lowlands. Gregfield could have gotten and out and at least planeted a flag but by this time he had already been up for almost 2 days perform a pair of orbital surveys and now 3 landings. With lots of fuel he took off again this time flying further north. Still in the lowlands. There is enough space to transfer fuel now, almost entirely refilling the center tanks. If Gregfield wasn't so tired he could probably do another 4 landings with all this fuel. With Gregfield exhausted mission control gives the ok for him to come home. Lift off is into a polar orbit from where gravity scans reveal he was just short of the polar biome. In theory there is enough fuel that he could continue around and land on the next orbit but the decision to come home has already been made and Gregfield is going to stick with it. After breaking orbit the fuel is put to use accelerating Gregfield's return. He takes a snooze until mission control wakes him up for reentry. The mission returns 2378 science. How I decide to spend all that will have to wait for a side note. Project Mint completed. Landed on Minmus in four places. Collected 2378 science. Science investment coming soon

For the Science Jr you needed to release it later or otherwise adjust your entry so that it stays within 2.5km of your pod during the descent. If it passes outside that range it goes back to the simple 'on rails' simulation, and that simulation marks anything falling below 23km (varies by planet) as crashed and destroyed since it is not simulating complex items like parachutes. For the Goo container you would have been ok if you let it land first. By switching back to the space center you ended the active simulation, putting everything back on rails while the Goo was still falling. Just like the Science Jr that meant the Goo container was marked as crashed and destroyed by the simplier on rails simulation. Here are some examples of keeping everything together during a multiple recovery drop. http://forum.kerbalspaceprogram.com/threads/53159-Science-leads-to-wonderful-things-%28PIC-HEAVY%29?p=706051&viewfull=1#post706051 http://forum.kerbalspaceprogram.com/threads/53159-Science-leads-to-wonderful-things-%28PIC-HEAVY%29?p=854958&viewfull=1#post854958 For sections that don't have a command pod or probe core they'll be listed as debris, so in the observation building you'll need to move your mouse to the top center of the screen to reveal the icon for showing debris. Once you can click on it you can use the green recovery button to get all the items.