rcp27

I think the idea of life support and construction time are interesting for a particular play style, but are quite damaging to others. If what you want to do is just run one single big mission to a particular location, then bring it home, then start on the next one, then these ideas are going to add a dimension to the challenge. If you want to build space stations and bases in lots of locations, though, the need to run repeated identical supply missions, each one taking up construction time and funds, is going to make maintaining a permanent manned presence in space a huge drain on resources. If life support and construction time were added as stock features to the game, the first thing I would do in my save is fly to each of my manned facilities and bring everyone home, and just leave them as unmanned facilities. To me, that would be a shame, and would make the game less interesting, but it would be necessary to remove the endless grind of repeated supply missions.

In a lot of discussion threads, the topics of time based mechanics come up, with things like time based funds and life support being the main ideas. The fundamental problem I have with this is not really knowing in advance how long a mission will take. In addition, when I start thinking about the next big mission to wherever, I have the problem of not really knowing when I hit the VAB how much delta V I might actually need to undertake the mission I have in mind. For mission planning a the moment, what we have is the manoeuvre node system. They are great for figuring out the next step on an under-way mission, but they are a bit lacking when it comes to long term planning. The "skip to next orbit" button is fine for something like getting the right transfer from LKO to Mün or Minmus, but it's really too clunky for something like figuring out the right time to execute my Kerbin to Duna or wherever burn, because that burn might be hundreds of LKO orbits from now. Here's my idea for how to make things better. It would require only three basic changes to the way the game works now, but I think it would bring a huge benefit. In the tracking station, in addition to letting me look at how the situation is with my various flights now, let me see how they will look in the future by having the option to project time forward (with any planned manoeuvres executed according to plan) Let me add manoeuvre nodes to flights in progress in the tracking station view (including in "future time") Give me a list of all planned manoeuvres for a flight, with times and delta V. How does this help? Let's consider planning a mission to Duna. Let's say my plan is to have a main ship that will break orbit from LKO, transfer to Duna, circularise there, have a separate lander that will go down to the surface, do some Science, perhaps with a side trip to Ike because I like Ike, and then come home again. To start with, I go to the tracking station and pick something I have sitting in LKO. We all probably have something there, be it a space station, a satellite to farm the "science from LKO" contracts, or just a dummy satellite we put up for the purpose of mission planning. I advance the view until I think there is a good looking transfer window, then add a manoeuvre to break Kerbin orbit and head for Duna. I then advance to arival and add a capture manoeuvre to get into Duna orbit. For some missions I might want a plane change or other correction manoeuvre part way. I then run forward for enough time to allow for how long I think my Duna and Ike landing missions will take, then look for what I think will be a good transfer window home, add a departure burn, the run forward to arrival and have a capture burn for Kerbin. What i have now is a list of manoeuvres that I would need to execute to complete this mission. I know how long it will take, because the manoeuvre nodes will have times as well as delta V and direction data. I have a total delta V budget that I think is likely to be required for the mission, that I can use to plan the actual craft to undertake the mission. With this information, I can hit the VAB, build my ship, perhaps out of several components assembled in LKO. Once the ship is complete, I can go back to the tracking station, and repeat the mission plan for the actual ship. Once I have done all that, when I go to fly the ship, I will already have the framework of manoeuvre nodes I need pre-loaded into the flight. Of course it is still up to me to actually execute the manoeuvres, and it is likely that any aerobraking will have to be figured out by my own estimation. What it does mean, though, is before I start building my ship, I know that this particular mission will require however many km/s of delta V, and that the mission, if all goes well, will take 2 years, or whatever. I could also then figure out whether I have time to send Jeb on a quick run to Minmus and back before he needs to be on board the Duna mission. If we had such a system in place, it would make flying to more exotic locations feel a bit more like "I have a plan" and less like "there's a good chance Jeb will be stuck on Duna until I can get a rescue mission together". Also, if I had a way of estimating how long the mission would actually take, planning things like life support would no longer feel like a random gamble, but feel more like something I can actually get to grips with.

I had rather supposed that the level of re-entry heating will be different depending on the difficulty setting you chose for your save game, so that starting career on "easy" will have more forgiving re-entry heating than on "hard". On Monday we will find out if this is the case or not.

After sorting orbital rendezvous, the big challenge for me was figuring out how to land on a target. Getting down was not too bad, but getting down at a pre-set location is much harder.

From what I understand, she has the same BadAss characteristics as Jeb. This means my space program may well degenerate into a competition between Jeb and Valentina about who can do the craziest thing. In the past, if there was a high risk, crazy mission on the cards, Jeb was the man for the job, no questions asked. Now these two are going to be fighting it out in the Astronaut complex about whose turn it is. Can we have a 2-man capsule please, Squad?

The problem I have with time based mechanics is they fundamentally change the game from a "try it and see" game to a "carefully plan in advance" experience. At present, a mission that doesn't quit go to plan will result in something like a ship stranded somewhere that needs rescue. That in itself presents a fun challenge that may take months or years to figure out. With time based mechanics, a mission that doesn't quite go to plan will result in everyone on board dead, and possibly the bankruptcy of my whole space program. If I'm going to be able to prevent this kind of monumental failure, I need far more tools at my disposal to plan missions so that I can be certain before launching to be sure it will work out. I can't just whack a bunch of components together in the VAB, launching and seeing what happens. Instead, I will have to scratch my head over delta-V measurements, transfer window planning (so that I know how much life support to pack) and construction schedules. To my mind, this change would drain the fun out of the game and turn it into a grind that feels more like the job I do by day rather than the game I play for fun.

I generally support the "no subtitle" concept. If we have to have one for whatever reason, I'd go with "we have liftoff"

In terms of technology, I would put an appropriate start point to be around 1955. Rockets with minimal payload can just about reach the Karman line (70 km on Kerbin), and jet aircraft can reach supersonic speeds in limited circumstances. I think the premise of KSP is different from the environment that gave rise to the development of rocketry in our history. To my mind, KSP has a role like that of NASA: a civilian, not military organisation, with the goal of science, not warfare. In our world, rockets were developed for military purposes. First the V2, then various cold war nuclear missiles. This favoured automatic, unmanned tech, because you don't want a pilot having to fly this kind of mission. Kerbals are motivated by the excitement of riding on fast and exciting rockets, and going places for science. Therefore I regard the KSP target as being much more motivated on doing it manned first. If you can't put a Kerbal on it, what's the point?

I like the list so far, but I'd like to nominate, under the category, "Best Comedy Video" the Scott Manley 0.90 Beta than Ever preview

I don't think having a fixed story to tell would be a benefit to the game. As an open framework for running your own space program, you are free to create your own stories as you play. If you create a fixed story within the game, it will drive players in a specific direction and stifle creativity. What if the story I want to play through contradicts the built in story? - - - Updated - - - But the only reason we know what's out there is because either we've gone their ourselves in game, or we've found sources online that tell us what's there because someone else has gone there. The game itself only tells us quite a limited amount of information about what's actually out there. There is tons of exploration to be done in KSP. The problem long time players have is that they've already explored most of it.

I'm going to swim against the current here. I only ever used the Round8 like once, and didn't find it particularly useful. I have, however, had long range ion probes where I have felt a bigger tank would come in handy. I guess I should head for the hills now before the flaming torches and pitchforks start heading my way.

To turn the premise around, I'd like to ask, "what's this thread trying to be?" Now that KSP is nearly at 1.0, we can see what it is, and the devs have indicated it's pretty much in the state they want to make it. So the simple answer to "what is KSP trying to be?" is "pretty much what it is now". Some posters in this thread are taking the position, "A management sim is X, and KSP is not X so it is not a management sim." More generally, you could say, "a game of genre X has [characteristics]. KSP does not have [characteristics] so it is not genre X." This is a truism. Fine, it's not genre X. But so what? There are three different modes: sandbox, science and career. Some players prefer some modes or others. For me, I play in all three, and each has its benefits and drawbacks. Different modes have different characteristics, and resemble other games to a greater or lesser extent. If we come up with a definitive genre classification that neatly identifies KSP in a particular pigeon hole, so that we can neatly place a label on it, will that make the game more fun? Sure, it might make it easier to make arbitrary comparisons between it and other games, but so what? Will we have more fun if we can do that? I get it that different players enjoy different modes of play. Some people find sandbox fun, others find science mode fun, while there are players who enjoy career mode. There are some players who even enjoy all three.

If we're setting the bar high as "completely agreed" then that sets quite a high bar. I don't know how you could make thrust curves for SRBs ​tweakable in a way that is both reasonably realistic and accessible to a non-expert player. In the linked thread, there is the following comment: I don't object to the idea of the behaviour of SRBs being altered from the way they are now, but I don't think making it tweakable would make the game a better experience to a regular player. I definitely disagree with this. There are plenty of good options for both simple and complex life support systems from a number of modders. There have been tons of threads about the idea of life support, and the idea is definitely very controversial, and has no place on a "Completely Agreed" list. I have made clear my personal feelings on this subject in another thread, so I won't repeat them here. What does this actual involve? What's lacking in the current model? A feature I would like to see: fuel cells. A part that consumes liquid fuel and oxidiser and converts it to electrical power. Fuel cells have been parts of real world space missions since at least Apollo, and would give a useful alternative to solar panels or RTGs.

If we go on the basis of a countdown being number of days till launch, I would think a countdown from either 10 or 5 is likely. More than that is a bit too far off to kick things into this high a gear. 10 days from now is Sunday 26th, which strikes me as an unlikely day for release. 5 days from now is Tuesday 21st. Tuesdays are more typical of the previous releases, so my money is on that as a release day.

Squad has certainly demonstrated how the early access model can work well, and it looks like KSP will be a pretty good game. It won't be "perfect", but it will definitely (in my mind it has already) exceed the "good enough" threshold. I've played games for enough years to have encountered loads of games that released with far bigger flaws than KSP 0.90 has. I think the most important factor of KSP using the open access model has been to free the devs from a lot of the issues of making the game too hard. Making it hard allows it to offer the potential to do really cool things, which is great, but without a community offering support, discussion and demonstrations of those cool things, I think a lot of newcomers would just give up at the "I can't reach orbit" stage. The community offers the motivation to newcomers with examples of cool things you can do, and it offers the assistance to newcomers to get them from the "I can't get to orbit" to the "I can land on Mun" stage. That community would not exist without early access.

The problem with jet engines is less due to the engines themselves and more due to how intake air is implemented. In the most basic sense, the gross thrust of a rocket engine or a jet engine is the mass flow leaving the engine * the velocity that mass leaves at (let's call them m_ex and V_jet). In a rocket motor, all of the m_ex comes from the fuel and oxidiser carried on board, so V_jet is the ISP. In a jet engine, a small amount of fuel is burned in a very large amount of air, and the resulting mass flow all leaves at V_jet. In terms of ISP, of a jet engine, V_jet = ISP * m_fuel/m_air. Because m_air is very much larger than m_fuel, V_jet is very much smaller than ISP. The important issue, though, is where the m_air comes from. In essence, an air intake is a reverse-rocket. Air enters the intake at a high velocity, and is slowed down to the speed of the aircraft. If the gross thrust of a jet engine is m_ex * V_jet, then the intake drag (ram air drag) is m_in * V_air (V_air is the aircraft speed). For a high bypass ratio airliner engine, a typical V_jet might be in the region of 300 m/s, and for a military engine for a fast jet might be 1500 m/s. For a rocket, V_jet might be something like 4000 m/s. What this means is, if you have a jet engine with a V_jet of 1500 m/s (a reasonable value for the turbojet), the combination of jet + intake will generate full thrust while stationary, 2/3 of thrust at 500 m/s, 1/3 thrust at 1000 m/s and no thrust at all at 1500 m/s. Because the rocket engine doesn't use atmospheric air, it suffers no ram drag. While I'm not entirely sure how the game models air intakes, the fact that jet powered aircraft can be flown up to well over 1500 m/s on jet engines alone, I strongly suspect that the impact of ram drag is not at all properly represented.

Any poll on the forums here is going to suffer severely from selection bias. Most of the people posting here have played lots and got to grips with the basic game, so adding complexity is something that can breathe life into the game again for them. Most people who have tried the game, found it too complex and given up, are unlikely to be hanging around the forums here.

A lot of people have covered the basic ideas. To summarise my view on the matter, I would say: Features I think need to be in 1.0: 1) bug fixes and polish. There are plenty of bugs in 0.90 that need sorting out, and things like tutorials and IVAs still missing. I would include balancing existing parts and the tech tree in this. 2) aerodynamics. This change will make a big difference to gameplay, and will likely make craft that work today not work in future. It is important to make sure that craft that work in 1.0 continue to work in 1.x. 3) re-entry. A core function of spaceflight, and something that if introduced later risks breaking people's save games, not something we want to see after 1.0. Features discussed for 1.0 that can safely be pushed back: 1) in situ resource mining. The core game is building and flying space missions. Resource mining is a great idea, but isn't essential to the core game, and would work well as a new feature for a future update. I imagine the mechanics associated with this feature risk bringing in lots of bugs and will need a fair degree of QA and testing. Perhaps better to leave it for a future update 2) delta V and engineering reports. Sure, it would be nice to have this information, and to have a "checklist" when you build your spacecraft, but to be honest the game as it works now is "good enough", and I would have no great upset if we had to wait for this polish. The radical suggestion: If you want to remove scope from 1.0, I suggest you entirely pull the Mk3 spaceplane parts from the game. Perhaps have a "custom" option to "use experimental parts" or something so that you can use them as they are in 0.90. Here's why: Mk3 parts as they are need a lot of attention. The fuel tanks are not balanced. The cockpit and crew tanks need IVAs. The current wing sections and undercarriage are undersized and very difficult to use with these parts. The current jet engines are really too small, and you need 6 or 8 engines to get them to work. This is really kludgy. To make Mk3 parts useful in the way that Mk2 parts are, we need bigger wing sections, bigger undercarriage, better engine and air intake options, perhaps re-worked fuel flow mechanics, ideally wet-wings or other more radical parts (like thick wing sections that can incorporate engines and intakes in the leading and trailing edge segments to mimic engines burried in the wing root). Realistically to get Mk3 sized spaceplanes to work with the degree of intuitive construction and ease of flight. I think the whole Mk3 space plane building experience is at a level below that of other aspects of the game. Having a dedicated 1.x release of "new bigger planes", with these parts done well, with the full range of functionality would probably lead to a better 1.0 experience than having the current somewhat incomplete state of affairs.

I sent a Kerbal there to take a surface sample so that we could definitively answer the question. Unfortunately he had eaten it by the time he came back.

I definitely find this particular part of the science progression the hardest to get past. Unlocking the landing legs takes a lot of science, and it's hard to land on Mun or Minmus without them. Without landing, science is hard to come by. Probably, but see later comments on the Science Jr. If you're in low orbit around the equator going in the same direction as Kerbin rotates, you will first pass a bit to the south of the ring shaped mountains (the crater thing), then over the big desert, then an ocean, then some grasslands with a line of mountains in the middle, with some ocean beyond. The KSC is on this last bit of land, on the far side of the mountains, on the coast. All of the science instruments work in basically the same way. From your current tech tree, you should have the mystery goo container and the science Jr available. What you need to do is put them on a ship and fly it to where you want to get science from. When you're there, right click on them and there is an option to run the experiment. Click on this and you get the dialogue box with some text and the options to "reset" "keep data" or "transmit". You probably want to go with "keep data" for the time being. The Science Jr and the Mystery Goo are once-use items, so once you get one set of data, they can't be re-used (the big science lab changes this, but that's not important right now). The other instruments (thermometer, barometer, seismic accelerometer and gravioli detector) can be used multiple times. If you now just bring the whole ship safely back to land on Kerbin and recover it, you get the science. There is another option, though. Once you have run the experiment and selected "keep data", send your pilot on an EVA, go over to the Science Jr (or Mystery Goo). If you are close enough, when you right click you get the option to "take data". Once you have done that, when you go back to your capsule the data is stored there. This means that you can now dump the actual Science Jr or Mystery Goo container and return with just your capsule, and bring the science with you. This can be useful if you're in Mun or Minmus orbit or on the surface because you can leave the heavy materials bay or goo canister behind and just take the data back with you, so you need less fuel (although some people don't like the space junk that results from this). The first time you do a particular bit of science, you get maximum science from it. With some stuff you can get a bit more by doing it a second time, and afterwards doing the same science measurement in the same location gets you no more extra science. There is no penalty for "second attempt" in the sense that if you go somewhere and don't do a particular bit of science, you can go back and do the science on a second or subsequent mission for full value. From the way you describe it, I assume what happened is something like this: you tried to escape from an orbit of Mun, so went for a prograde burn, and escaped Mun orbit, and ended up on an orbital trajectory that not only escaped Mun's sphere of influence but also escaped Kerbin's sphere of influence too and now you are in some orbit around the Sun. This happened because you did your burn at the wrong point in the orbit. When you're orbiting Mun or Minmus in a roughly equatorial orbit, one half of your orbit will be in the same direction as Mun's orbit around Kerbin and the other half is in the opposite direction. If you make your escape burn so that you depart Mun in the same direction as Mun's orbit around Kerbin, you will end up on a much higher orbit and possibly escape Kerbin. You don't want to do this (as you have discovered). You need to time your escape burn so that you come away from Mun in the opposite direction from its orbit around Kerbin. When you escape you will then find you are in an elliptical orbit around Kerbin with quite a low Pe. You need to adjust that orbit to put the Pe inside Kerbin's atmosphere, preferably lower than about 30 km. The atmosphere will then slow you down enough that you come in for a landing. If your Pe is in the atmosphere (below 70 km) but higher, you will likely find you don't lose enough velocity to come down that orbit. When I first came back from Mun, I made this mistake and ended up going around about 20 times, each pass through the atmosphere bleeding off a bit more velocity until eventually my orbit decayed and I landed. To recover this unfortunate Kerbal from an orbit of the sun will take quite a lot of time to learn the techniques to do it. Your first step will be to learn how to perform an orbital rendezvous in low Kerbin orbit. To learn to do this, launch a simple rocket into LKO, then go back to the space centre and launch another one to a similar orbit. By playing with manoeuvre nodes you can figure out how to make the two meet in orbit. This is a key skill in KSP, and takes a fair bit of learning to perfect. There are plenty of youtube videos giving tutorials on how to do it. Once you are confident with orbital rendezvous, you need to build a rescue ship. This will have to have lots of fuel capacity and either a spare seat or "the Klaw" on it. You can then launch this into a Solar orbit, perform a rendezvous with your stranded vessel. If yo have The Klaw, you can dock with the lost vessel and bring it home. Alternatively, just bring your rescue ship near to it and use EVA to bring the pilot across to the rescue ship to bring him home and leave his ship behind. I suggest you leave this poor chap where he is and get on with learning the game. Once you have managed a successful Duna orbit and return mission, you will have sufficient experience to know what you need to do to rescue this guy. Think of it as a long-term objective. I'd say 100 hours gameplay is a realistic time frame depending on how easily you get the hang of things. As a general strategy, I would make the following suggestions. 1) if you haven't already done it, use the Mystery Goo and Science Jr to get extra science from places you have already been to. 2) send missions to orbit Mun and Minmus, with the Science Jr and Mystery Goo, and get science from orbit of those, as well as crew reports and EVA reports. All the planets and moons have Biomes on them just like Kerbin, so you can get lots of science. With the science you get from these missions, your first target will be to unlock the basic solar panels and batteries. This will let you transmit crew reports and EVA reports and make life easier. Your next target will be to unlock the thermometer (the 90 point node with the "man in space suit" symbol". This lets you get more science from biomes, and you can take it to the places you have already been. Once you have that, your target should be "landing" (the 90 point node with the undercarriage wheel on it) and then "advanced landing" (the next one along, 160 points, with the rocket on legs). These give you landing legs, which will give you the parts you need to actually land on Mun and Minmus. You get lots of science from landing on (and running experiments on the surface of) various biomes on these two moons. At this point, you should be getting loads of science to get much of the middle part of the tech tree unlocked, and you can probably figure it out yourself from there. Edit: I've not seen it suggested before, but I think it might be easier to learn to perform orbital rendezvous in orbit of Minmus rather than LKO. The smaller size/gravity makes the whole process much easier to perform. Once you have the technique figured out, it can be done anywhere. - - - Updated - - - I disagree: I think Science mode is the place for beginners to start. When I started with sandbox, I found the whole thing confusing because there were too many parts and I didn't really know what they did, and when to use one part instead of another. By starting in science mode, you slowly unlock the parts in a somewhat rational progression, so that each part is introduced as you need it. It flattens out the learning curve a bit.

The current aerodynamics model in stock KSP is not a realistic representation of the way aerodynamics really work, so looking up references to real world aerodynamics will not help you in KSP. It might be worth bearing in mind that the aerodynamics model is being entirely changed for 1.0, so if you are planning on putting a lot of effort into getting your script right, you might be better off waiting until after the change. My understanding of how KSP models drag now has the drag force on a part proportional to the mass rather than cross sectional area and linearly with velocity rather than as the square of velocity. I'm not sure how the atmospheric density profile is represented, though. In the real world, aerodynamics is a deeply complex subject that can't really be summed up in a simple forum post. The temperature/pressure/density profile obviously varies with weather, but is modelled in a number of ways, for example the International Standard Atmosphere, but I would not be surprised if the KSP atmosphere is not at all representative of the real atmosphere.

Unless, of course, a nearly sandbox experience is what you are looking for. The game I felt like playing was science mode with kerbal experience, because I like the idea of actually having to take the places to make them more useful. No actual option exists for this, but massive funds rewards in career mode, and not abusing outsourced R&D gives me that game style.

The time it takes to complete one orbit is a function of the "semi-major axis". The major axis is the orbital distance between Pe and Ap. If you increase that distance, the orbit takes longer, if you decrease that distance the orbit is faster. There are probably more efficient ways to do it, but this method gets the job done: First, get onto your desired orbit. It doesn't matter where you are relative to your ground target. Check to see where you are. If you are ahead, you need to slow down. If you are behind, you need to speed up. To slow down, you need to increase your orbital period a bit, so burn prograde to raise your Ap a bit. Now, to get from where you are (now the Pe), to the same point on the next orbit, takes longer than the target orbit, so you will arrive there "behind" where you began. Keep going round until you reach your Pe over the point on the ground that is your target, and circularise. To speed up, burn retrograde, and drop your Pe below the target orbit, and the Ap will remain on it. Each time round you will gain some ground, so keep going round until you arrive at Ap over your target, then circularise. Be careful not to overdo the burns, though. You need to complete one full orbit to arrive back at your target before you can circularise. If you go too far on your adjustment, you may find you overshoot your target. It's easier to make a small adjustment orbital correction and have to go round a few times before reaching your target than to repeatedly overshoot. With practice you will get a feel for how to fine-tune it.

In map mode, on the right of the screen is a button with a Kerbal face on it. Click on that and it gives you a crew manifest for your ship, with names, specialisations and level and where in your ship they are sitting.

I've been feeling the same way lately. I like the idea of the upgrade path to buildings and Kerbal XP and stuff, but the regular career is a bit to grind-intensive to get the money, and when I do finally decide it's time for the grand expedition to a far off planet, I feel all bad about the money I'm "wasting" that took so long to earn. My new strategy is to run career mode in "custom", and push the starting funds and contract rewards funds all the way to the right. It basically gives me all the funds to do what I want to from a few simple contracts. On the basis that "it's not wrong if you're having fun", it's the game for me right now. - - - Updated - - - The problem is, "space program management" in real life is pretty repetitive and, if reproduced in a game, would feel like a complete grind fest. I'd put money on it that if you take the KSP save with the most satellites launched in various orbits of Kerbin, it is far and away less cluttered, probably by an order of magnitude, than the real Earth's local area. Consider: GPS has used 68 satellites. Iridium (the satellite phone network) has 72. Would you like to get a contract to "build a satellite phone constellation" that required 72 identical satellites in specific orbits?