Tarmenius

A simple solution would be to require a particular number of completed missions per year in order to receive the subsidies. Each year, the player could elect whether or not to participate in the subsidy program, maybe even select the number of missions desired and therefore the amount of funding.

I remember a while back, when the intended scope of KSP was a tycoon-style space agency game, that HarvestR wanted Kerbals to be capable of completing various tasks (including in-flight maneuvers) and that their degree of success would be influenced by their stats. But that was around two years ago and I haven't heard anything about it more recently, so that all may have changed as KSP has grown and evolved quite a bit since then. I'd love to see the tycoon game he had in mind, and the Space Center's building tiles suggest that it may still be alive, but only time will tell for sure.

My first successful Mun landing came after a few disasters of varying intensity (not surprisingly). And this was after coming to KSP from Orbiter and having landed the Delta Flyer on the Moon (albeit without really understanding how I had done it). In the time of 0.13, I was in the habit of attaching an RCS tanks and thrusters to the command pod as a sort of "emergency return system." But, for reasons that are now lost to eternity, the lander on my first successful mission was powered entirely by RCS. I don't even remember whether they made it back...

Thanks! Are you getting to Duna relatively easily? For the lander, I'd recommend a combination of drogue chute and powered-landing. Its atmosphere is too thin to use parachutes exclusively (unless you have a lot of them). It sure was. Wow, I hadn't considered leaving Jool out of the equation entirely. I'll have to try that next time I head that way, thanks.

So, after playing KSP for more than two years, I finally decided that it was past time to do a round-trip to Laythe. I'd only ever returned a Kerbal from beyond Kerbin's SOI once before (from Duna), and the prospect of returning one from a Joolean moon had always felt particularly daunting to me. I would likely need to construct a large, part-heavy ship powered by LV-N’s which would then require long burn times in addition to the hours-long process of actually getting to one of Jool’s moons. I imagine it would have felt like work. When the ARM parts were released, I recognized that they could give me an opportunity to perform the mission using fewer in-game and real-life resources. I had wanted to do this mission for some time, of course, and over the previous couple of months I’d developed a number of reliable SSTOs; one of which was built specifically to be taken to Laythe, in anticipation of this. When the transfer window to Jool was near, I designed a rocket to be placed underneath the Laythe SSTO and ferry it there (and hopefully back). Here’s how the mission went: I was rather surprised to find that I had taken more fuel than I needed to get back. I fully expected the SSTO to have to finish the transfer burn back to Kerbin, which is why I designed the transfer stage to be docked with instead of including a pod and leaving the SSTO in Laythe orbit. Future missions will probably be done the latter way. And while this mission was returning to Kerbin, I decided that I then had the capability to return from anywhere (except Moho and the surfaces of Eve and Tylo, of course). So, naturally, I made a trip to Gilly and back, though I didn’t really document it beyond a few key images from the landing. While I don’t think I’ll be doing any more missions of this type very soon, when it’s time, my next targets will be Dres and Vall (the last place I have left to visit). Thanks for reading, and feel free to comment on this or offer advice about the trip to Vall, for when I finally decide to tackle that goal; I hear it requires more power and delta-v than people expect.

For people with limited time in their days to allocate for playing games, the additional hours of time required for the process of interplanetary trial-and-error can have a significant effect on their gameplay experience. As I mentioned before, a round-trip to Jool can take a few hours to accomplish even when you use a craft proven to be capable. I can't afford to spend those hours multiple times just to develop a design that works. And so, I have to decide: download a mod, calculate the data myself (and wait until later to find out if I've done my math correctly), or avoid those types of missions. If the stock gameplay experience is intended to include long-duration interplanetary missions, then we need stock tools that will allow us to accomplish them in a time-efficient manner, or people with limited time to spend will be missing part of the core experience.

I recommend that once you have a good idea of what the gravity turn should look like, you use a test rocket to measure your success. For example, if you can get the rocket pictured below into orbit, you can be pretty sure you've got an efficient profile.

I'm pretty sure they still plan to implement some kind of weather system. It was quite a while ago (early 2012), but I remember weather being mentioned along-side pre-flight mission planning as something HarvesR wanted to eventually include in the game. Of course, even a simple weather mechanic would have to come after a revision of the atmospheric model.

This happens for me as well. Any more than two claws and the framerate (even in the VAB) starts to decrease.

I really like this idea; even the first version. A couple things to consider would be: If the "forgetful" version wouldn't change gameplay in any noticeable way, then there's little reason to go through the effort of implementing it. Which is why I think that if any version of this were to be implemented, it should be the first, but as part of a realism expansion or mod due to the micro-management required by the new system (unless I misunderstood how it would affect gameplay). Which brings me to the second consideration: How would it work for vessels that are not under active control by the player or that are under the effects of timewarp?

There already is something in the stock game that references it. The Maneuver Node. Suppose it instead listed the burn time required, as has been suggested. We'd be faced with exactly the same situation: a mod would almost certainly be made to calculate the burn time, displaying it in the VAB and we'd all be here debating about whether the Burn Time Calculator should be included in the stock game. The issue is that the game says it needs something from us (the delta-v for a given maneuver), but doesn't give us a way to tell whether we've met that need until it's too late.

Indeed, it would be wonderful if code could implement itself. The only difference between that and the kinds of posts we see already is that in your example, the question is more informed. Is that really such a bad thing? You make an excellent point here. KSP does tend to inspire some wildly unconventional designs, and getting a delta-v indicator to work with them could prove more difficult than any of us can anticipate. If that turned out to be the case, then you may be right in suggesting that it wait until the game is more complete before being officially considered. Which would put the feature in the category of "things the developers haven't gotten to because of time constraints" and would rightly be left to the modding community. As a side note, this discussion has been very interesting to follow, with excellent points made on both sides. I would be really curious to know whether it has at all changed the development team's view of the topic.

I was torn about this issue at first, but after some thought, I have to say that including critical data readouts as an option which players can enable or disable at will is not only a good idea, but one that probably shouldn't even be debated. It's almost always good game design to give players as many options as possible so that each individual can tailor the game to their own preferences. But keeping something from players who want it will have one of three possible effects: Either the player has to download and install the desired functionality from a third party (which, granted, is both relatively safe and easy with KSP), they calculate it by hand, or they do without. None of those are qualities of good game design. As has been mentioned already, "doing without" is usually no major issue for Kerbin SOI missions, but becomes a serious one when mission complexity increases. I don't do many Jool missions myself for exactly that reason. Just getting there takes a couple hours of real-life time to fly (three-and-a-half hours was my last one-way time, including trial-and-error aerobraking attempts) and I'd rather not have to wait until after I've spent those hours to discover that I hadn't packed enough fuel. I feel like I miss out on some of the game's content because of the real-life time costs involved with the trial-and-error method. Calculating things by hand is not typically considered engaging gameplay, and those who do enjoy it for its own sake would probably do it regardless of whether the game offered them the information already. Finally, mods are good for content that the developers either can't get to because of time constraints (or haven't gotten to yet), or that lies beyond the scope of the game itself. Critical data readouts don't really fall within either category, so there seems to be no good reason to delegate that functionality to the modding community. I don't have anything against mods (I actually installed MechJeb after that Jool mission to see if I could make it back), but every time I get MechJeb or Kerbal Engineer to allow mission planning, I wish I wouldn't have to. Plus, having one of their instruments on my craft slows the game down noticeably for me. If it were stock, I imagine the implementation would run more smoothly. In the end, having it be an option in a menu seems like a no-loss decision. As a side note, the argument that having the data would intimidate new players or confuse them is, I think, under-estimating their intelligence.

As others have pointed out, the first step is launching into Kerbin orbit efficiently. Use a simple rocket (like the one pictured below) as a test platform. If you can get it into orbit, or at least close to it, you'll know you have an efficient ascent profile. Once you've gotten that down, you can practice interplanetary transfers within Kerbin's sphere of influence. Get into orbit around the Mun and try to transfer to Minmus using as little fuel as you can manage. At the end of that process, you will have a much better understanding of what it takes to travel from planet to planet. Hope this helps, and keep asking questions if anything is unclear.

I seem to recall it being said some time ago that the pre-0.23.5 stock engines had terrible performance characteristics when compared to their real-life counterparts. So, when you consider that the ARM parts may have been created as a reflection of their NASA counterparts, it should be no surprise to find that they severely out-class the previous stock engines. And if you consider the purpose for which they were created, you have to ask "If we balance the new parts down to the performance levels of the old ones, can the purpose still be fulfilled?" If that answer is "yes" then what was the point of creating them in the first place? I know it's been stated before that a money system may (when it's implemented) provide the balancing mechanic, but I think the concept of "technology levels" is something larger than a mere monetary issue. As new technology is developed, it leaves behind the old. And so, I believe that it's perfectly reasonable to have a level of technology in this game that makes "lower" parts completely obsolete. After all, if my memory serves (and if the team's vision for the scope of the game hasn't changed much), KSP's career was going to take the player from tech based on jury-rigging piles of scrap metal, all the way to tech beyond our modern equivalents. You can't do that if all the parts available are balanced to every other. Unfortunately, that means that in Sandbox Mode there will be parts the player simply won't use. Interestingly enough, this same "issue" is faced by almost every first-person shooter out there. During the Campaign, the player gradually gains access to better weapons, expanding his or her combat capabilities, but in Multiplayer, only the later unlocks are ever used. This is just the nature of having a limited number of attributes (Thrust/Damage, ISP/Rate of Fire, Mass/Recoil for example) and having more parts than there are combinations of those attributes.

I'm not sure if any of them can get to orbit in under 5 mins (mine also takes anywhere between 7 and 10 minutes depending on ascent path). But I'm thinking that as long as a craft is technically capable of getting there, all I should want to test is how it handles in flight. Take the original Aeris 4a for example. It's technically capable of reaching orbit, though for a while I couldn't manage it. Getting it there or not seems like more a reflection of the pilot's skill than of the crafts capabilities. So, as long as someone has shown that a given craft can get to orbit (typically the craft's creator), my main concerns when testing should be how it performs during flight at various fuel loads and whether the RCS (if any) is balanced for docking. Given that, I think my testing will involve attempting to land the craft once with a full fuel load and once at almost empty. This will tell me a lot about the craft's lift characteristics, potential climb rate, and maneuverability. Then, I can hack gravity and see how the RCS behaves in zero-G. I'm pretty sure I can accomplish all that in under 5 minutes and have a good picture of how the craft behaves at the key points in a typical flight. After the first couple tests, I'll have a better idea about whether this is going to be a reliable method...

Thank goodness we have the extra time. With 39 entries to test (so far), if I spend even five minutes on each, that's 3 hours and 15 mins of testing. I'll to have to devise a testing method that gets the most out of those 5 minutes...

I love the compact frame. If your looking for an aesthetic improvement, I'd suggest the structural wing (triangular) over the swept wing. Of course, I may be a bit partial to that piece; but the way I see it, if the fuselage is compact then the wing form should be as well. The way it is now, I think the Plover looks too wide for its length. But the looks of a craft will have little influence over my vote anyway, so take that as you will

Thanks! When I decided to do a twin RAPIER configuration, I wasn't sure what to do with the central fuselage. I considered adding a tail assembly, but that came with a huge risk of tailstrike on the takeoff roll so I decided against it. I also wanted to have the option of adding a small satellite to give the design some "purpose" beyond simply getting a Kerbal into space, but without sacrificing the IVA view (usually, the docking port and probe would be in front of the inline cockpit). This was the only solution that was simple and effective. I guess that's why I kept coming back to that design; I really like how the craft turned out.

After five other designs that were almost right, this is the one I kept coming back to. It showcases the new RAPIER engine while still making the pilot worry about asymmetric flame-out. I'm not sure whether it will actually go into a spin if I let it, but it certainly will yaw menacingly. The Rasvelg is capable of reaching a 100 x 100 km orbit, even if the pilot switches modes at only 25,000m and under 1200 m/s. I'm pretty sure in one of my many test flights, I was at as low as 23,000m when I switched over, and I still got to orbit. On takeoff, it is possible to damage the probe against the runway if you have the nose high enough at any takeoff speed. This is intentional, though easily avoidable. Recommended takeoff speed is anything above 70 m/s, though it can be done (without damaging the probe) as low as 60. It is not terribly maneuverable with a full fuel load, though it's meant to be climbing, so that's less important during the first half of the flight. Still, it can make an immelman turn in under 1500m at full throttle, so that's not too bad, right? When the Rasvelg is almost empty, it flies as I want it to: it's more responsive, easy to handle and has a good glide slope. I really designed its flight characteristics for what I consider the most important phase of the flight: Landing. Too much lift here and it may be difficult to get it to the runway. Too little and, well, we all know what happens then. Rasvelg craft file Action Group 1 toggles the RAPIER engines. Action Group 2 switches between the RAPIER modes. Action Group 3 closes and opens the air intakes. Action Group 4 releases the probe, extending its Communotron and activating its ANT engine. Action Group 9 toggles the ladder, Action Group 10 extends the Rasvelg's Communotron. None of the Action Groups are necessary, as the staging can be used to activate the RAPIERs then release the probe. Intakes don't need to be closed to reach orbit, and the engine is capable of switching modes automatically. But advanced pilots may wish to have a greater level of control, and they certainly can. All of the important information here can also be found in the Rasvelg's description field.

You don't really even need maneuver nodes to get a successful rendezvous, though it does speed the process up a bit. All it really takes is knowing that if you need to catch up, have a lower orbit. If you need your target to catch up to you, have a higher orbit. Then it's all about making sure the orbits cross and waiting.

This is both fun and useful! When it's done collecting experiments from various biomes, I send one lander to retrieve the data and Kerbals. More science than I can shake a stick at! An Orbital Lab like this (and its accompanying fuel) enables one lander to repeatedly visit the surface, store whatever experiments it brings up, and scrub the equipment for subsequent uses. When the mission is over, it returns to Kerbin with the lander crew and all that wonderful science. I've never found the transmission boost to be of any practical value, but the ability to retrieve all science from a given body in one or two launches from Kerbin is quite valuable to me.

This is the source of my own design dilemmas. The Aeris-4a has obvious flaws, but they're there on purpose: to inspire the player to tweak and experiment with the design while measuring whether the player has a handle on the standard ascent profile for SSTO spaceplanes. Given it's true purpose, the Aeris-4a is actually an excellent craft. So, I'm faced with a choice: do I recreate the original craft's intent or make an easy-to-use craft that has few flaws, potentially gaining more votes? Either approach seems like a valid design choice, but one will result in a significantly different kind of craft from the other. How then do we compare entries that serve such different purposes? Thankfully, we still have a few days left in the build phase. With 15+ SSTO spaceplanes already in my hangar, I may just pick my personal favorite and throw it into the mix On a somewhat-related note, I'll be very glad when .24 comes out. The Inline Clamp-o-tron is quite dangerous now and some of my designs have been made unusable by the incredibly bendy connections!

I think this pretty well sums it up for me.

Also notice that in the pictures during flight, the SAS is applying as much pitch control as it can to keep the plane level. In the picture where CoM is in front of CoL, the SAS looks like it's trying as hard as it can to pitch up to compensate. And where CoM is behind CoL, the SAS is trying to pitch down. That strongly suggests that the CoL and CoM need to be closer together. So if this were my design, I'd focus on fixing that and making sure that no landing gear is very far behind the CoM. Then see how it behaves and continue adjustments as needed.