herbal space program

A valid point, although just scaling down by 3.5-fold only gets you a short way towards addressing the multiple-orders-of-magnitude disparity between distance scales within and between systems in the real universe. At 10km/sec, which is going quite fast in KSP1, it takes about 3 Kerbal years to cross the ~250 million km Kerbolar System. Even the shorter Kerbal light year is 2.8 trillion km by comparison. For a distance of 5 Kerbal light years, that represents a 56,000-fold difference in the distances within systems and between them. From a gameplay standpoint, I think that having interstellar travel times be more than around 5-fold greater than intra-system times is going to be really unwieldy unless the whole game is just about taking that first trip to another system, i.e. you stop doing anything else back home once you have launched. That seems like it would limit the scope of the game way too much to me, so what I think you're left with is striking some balance between making KSP2 interstellar ships go 10,000 times faster than their fastest KSP1 counterparts and having the next star system be 10,000 times closer than that. My instinct is that roughly splitting the difference, i.e. putting the other stars 100 times closer and making the ships go 100 times faster, will be close to ideal in terms of both keeping the timescales in balance and not having to invoke Star Trek-type pure fantasy technology. Maybe some folks aren't so concerned about the latter because it is after all just a game, but I would say that it is for that very reason that introducing such radically OP elements relative to the prior continuum of technologies is such a problem. Anyway, I'll buy the game no matter what they do, but I do hope they think some of this stuff through.

Well it's not like I'm not going to to buy the game if that's what they end up doing! But I do think it would be fundamentally different from the examples you cited. No light delay, instant build times, and no life support are things that exist in the game because not having them would make playing it way too much of a pain in the end that should not point towards space, IOW they were necessary compromises with realism in order to make the game playable. I think you could also say that rather than those things representing a total disregard for what is physically possible, they more represent just subsuming their implementation, e.g. the fact that in-game you can control your probe in real time at whatever distance just sort of assumes that your mission control Kerbals at home knew how to issue the relevant commands in advance. Ditto for build times. Life support is obviously less like that, especially for really long missions, but again I think that was a question of it just becoming too much for the player to manage in that context. And FWIW you could also explain that away with some kind of implied Kerbal hibernation. Anyway, it will be interesting to see how they deal with that in KSP2. Magical propulsion systems that could never exist within physics as we understand it OTOH seem to me like the game crossing a key line between trying to adhere to some level of physical realism and entering into the realm of pure fantasy. YMMV, but for me scaling interstellar distances down hugely, which is not completely implausible IMO, solves both the problem of needing to create an Infinite Improbability Drive and the problem in terms of gameplay of inter- and intra-system travel timescales being 3 or more orders of magnitude apart.

I'll bet they will be closer than that. Everything else is at roughly 0.1X scale, so I think that 0.2-0.5ly will be the maximum distance they would actually consider, unless they are going to introduce some ridiculously OP engines into the game. And even that is still an immense distance when you consider the game timescale of intra-system travel. If the gulf between those two time scales is too large, it will create all kinds of difficulties for gameplay. My guess is that the Kerbolar system will turn out to be inside a scaled-down globular cluster, with adjacent stellar systems separated by maybe 10-50 times their own diameter. Even so, it would still take a decades to reach nearby star systems using somewhat plausible propulsion systems that can deliver perhaps 100 times the ISP/dV of what we currently have in KSP1. Either that or they just make up some kind of Doubletalk Drive that lets you do it Star Wars-style, but I would personally be against that, and even so the vast disparity in intra-system/interstellar time scales would be a problem for gameplay.

I guess that would explain why they're all green!

This sounds like it could make a great core for a SLS-type combined lifter and transfer stage. the LFO mode will provide good TWR earlier in the ride to orbit, as well as perhaps that extra little kick at PE during ejection, without having to make a separate stage. Nice idea!

Having the ability to make wind turbines and sailing ships would be awesome! It would be fairly easy to model a global prevailing wind pattern that includes equatorial doldrums, low-latitude trade winds, and mid-latitude westerlies. To make it more interesting, within a given physics bubble the speed and direction of these could perhaps change fairly slowly and within certain constraints that depend on the location. In such a scheme the equatorial KSC launch site would also naturally have very little or no wind, although for rocket launches and the typical wind speeds that I would envisage, I don't think they'd represent much of a problem anyway.

I think actual, dynamical storms would be just too difficult to model reasonably, let alone navigate through, so they're probably out. Clouds however should be comparatively easy, as should static and locally flat wind fields. I do think the latter would definitely add something to gameplay at least for me, and could be integrated into the standard career difficulty scale or toggleable/nerfable in other modes. Moreover, I think of at least visually modeling clouds and rain on planets with atmospheres as kind of an essential aesthetic upgrade for the game as it transitions from indiehood to a major studio release.

I think the way to keep them from being OP is to make them require an immense amount of electrical power and also to require the transport, landing, and physical assembly (by qualified engineers with robotic cranes, etc.) of both a (heavy) base station and however many (lighter, but large) driver segments as are needed to reach the required ejection velocity. Each segment could perhaps telescope out from 10 to 25m for installation. Aiming them more than a few degrees from their build angle should also require re-assembly, and especially long ones should moreover require an appropriately angled slope to support them. Factoring all those things in, I think they could be brought into balance fairly easily.

My biggest (but by no means only) problem with space elevators is that I just don't think they are compatible with the level of technological development presumably encompassed by the scope of this game. Building one that is remotely plausible would be a bigger effort by orders of magnitude than just building your reaction-powered interstellar colony/exploration ship on orbit. The latter could also conceivably be achieved with "around-the-corner" technologies, while the former is still mostly a pure pipe dream in terms of actual implementation. On top of that (and as has been pointed out), modeling one as any kind of interactive physical object rather than a purely visual stage prop is pretty much out of the question, so its actual use would basically amount to triggering a cutscene. To me that idea just seems kind of at odds with what the game as we know it is all about. And lastly, what you get for having one , i.e. a cheap and easy trip to synchronous orbit and only synchronous orbit, doesn't seem like anything particularly unique or valuable to me. Just having fully automated supply missions for on-orbit construction projects would provide far more gameplay value without creating a stark discontinuity in the whole conceptual framework IMO. Electric mass drivers OTOH, as a cheap and easy means of delivering mined resources from various low-gravity extraction outposts to Kerbin or orbital construction projects, seem much more within the plausible scope of this game to me. And they would actually solve a real gameplay problem, which is how to deliver various types of remotely located Unobtanium to the places where they are needed without flying a separate mission every time. They would also obviate the need to provide resource-return fuel at every mining outpost, at the price of transporting the parts there and constructing it in situ. I also don't think the argument that they would break the physics bubble is valid either, at least not for the toy-sized Kerbolar system and the no-atmosphere, low-gravity bodies where I would envisage their use. Orbital velocity on Minmus is around 170 m/s, and on Mun it's around 650 m/s. So a 10g mass driver would need to deliver its acceleration for only 1.7 seconds on Minmus and around 6.5 seconds on Mun to launch its payload to orbit. For Mun that would mean a length of around 2.1km, which is pretty unwieldy but still smaller than physics radius, but on Minmus it would only be 112.5 meters, which is totally doable! And of course the max G tolerance of Kerbals in their command pods as well as other parts is actually 50 rather than 10. At 40g, a Munar orbit-capable mass driver would only measure 0.5 km, and a Minmus escape-capable one would measure only 50m. That seems eminently doable to me.

My meaning was actually exactly what you said here. Absolutely you should have in-game resources that display all of those data, but only after you've jumped through some kind of (easy) hoops. My only issue with KER was that it tells you all of that right off the bat without you having to do anything at all to earn it beyond going there . I still use it though. The current stock game OTOH tells you what biome you're over when you EVA, but then it doesn't record that info and it only tells you about that one spot, making the process of mapping biomes ultra-tedious. I think it would be much better if instead after you EVA over some biome it would reveal all the places that biome exists on a map you can subsequently pull up. Moreover, you'll then know where you need to EVA the next time to encounter a new biome, making the whole mapping process much less annoying. At some point in the tech tree you can also get probe sensors that will map biomes for you, perhaps initially one at a time like doing an EVA, but eventually all of them at once from a polar orbit. I dunno, maybe you could even give the sensors some whacky, off-the-wall names like "survey camera" and "survey mapper". And if I'm really going out on a limb, I might even suggest that the terrain detail in which you can see bodies other than Kerbin in the tracking station should be tied to these measurements! Similarly, you could tie terrain elevation data to some kind of radar sensor or even the existing gravioli detector. In my ideal version of career KSP, every single bit of novel science you do would give you either some useful knowledge about the Kerbolar system or some progress along a specific, somehow related branch of the tech tree. It would make the whole process of acquiring science so much less pointless and grindy! Seems like a no-brainer to me for a game that's all about space exploration.

I think that pretty much all the purely informational aspects of MechJeb and KER except perhaps the unmasking of biomes are fine. Regardless of tech level, there's no good reason you shouldn't always know your mass, the dV of your stages, your airspeed and Mach number, your horizontal and vertical speeds, your skin temp, and your terrain altitude. I guess perhaps the game could make you ship the relevant sensors to know those things, but those should be available very early on. Similarly, knowing when all the transfer windows occur in absolute time is not something players should be made to calculate on their own. Perhaps that could be made to require some amount of game progression, but that knowledge should be given early as well. The transfer planning tool should also at least allow you to move your ship forward in virtual time and place maneuver nodes in its future and see what will happen with them. If you are stuck orbiting Tylo and waiting for your Laythe gravity assist to go back home, it would be great if you didn't have to wait for the phase angles to all be right before you can even figure out your maneuver.

That's a very convincing argument. I am convinced that trying to debate with you about how this should all work is a waste of time!

It would be nice, but I'm also optimistic that what they will end up giving us will cover all the functional bases and also make everything we've had so far look like it was found lying by the side of the road.

I have no problem at all with whatever MechJeb features getting unlocked in some normal level of Career difficulty as you demonstrate in-game that you can do those things. Even the MechJeb mod as it exists now only unlocks its features incrementally as you advance up the tech tree, precisely to keep you from using it as a crutch to avoid all the deliberately imposed challenges of early career. I mean, what is even the point of having a progression of more and more capable pilots, probe cores, and remote control units in the tech tree if you can just slap all that on your ship from the get-go? It all only makes sense if you have to earn these features of convenience by jumping through the hoops that the career game sets for you. And isn't that how pretty much all computer games work in campaign mode? And having said that, as you point out there are some MechJeb features that don't currently exist in stock that I actively want the stock game to have, above all some kind of pitch angle hold for planes. But I want those to have to be earned as well, unless you are playing in either sandbox or some kind of Beginner Career mode.

As Slashy said, we were just talking about the stock LF/O lifting engines, and I was specifically talking about what TWR at launch makes for the best payload fraction to orbit. Jet engines are another beast entirely because of their insanely higher ISPs, which let you give up a whole lot of impulse to gravity early on without it making a very big dent in your fuel supply. The other thing about the high-end jet engines however is that they also get a much more favorable TWR when they are operating at high speeds, comparable to the best LF/O engine TWRs, and it's really that phase of their profile (i.e. from ~380 m/s to ~1,400 m/s) that does 90% of the work in the air-breathing part of your run. All the low-TWR stuff at the beginning is just about getting you to that point.

I have no trouble at all building planes in KSP that can take off and land just fine, on Kerbin or any other body I'm designing for. You just don't know how to do that yet and want to blame anyone/anything besides yourself for that.

I can't even imagine flying in KSP with just the keyboard anymore . I always use a generic Nintendo-style game controller, with pitch/yaw under my left thumb, roll under my right thumb, and throttle controlled by my left index and middle fingers (I'm left-handed). If the plane is well-balanced, I generally feel very much in control that way. And if your plane is tending to float back up while flaring, then I would suggest that you just haven't bled off enough airspeed before initiating it. The point is to hit your stall speed, whatever that may be, right above the ground. Try a slightly higher pitch angle on your pre-flare glide slope next time.

I honestly don't think that landing a well-designed plane is so hard. There are just 1,000 ways of making a really lousy plane, and flight sims generally take that design process out of the equation. If you have a plane that is sturdily built, with sufficient landing gear, good ground clearance, a stall speed of < 50m/s, and good aerodynamic trim, landing it pretty much anywhere on Kerbin is not going to be particularly hard. (edit) ...And as I think about it, that is actually one of my biggest issues with all those MechJeb features being available in Stock. It encourages the design of lousy ships that only the computer can fly. A good plane or spaceship should be easy to fly. Realistic designs moreover need to include some margin of error, like Neil Armstrong had with the LEM to choose an alternative landing site at the last second. Papering over all that with MechJeb takes away from that whole aspect too.

I don't even know what you mean by that. What is so reprehensible about awarding achievement badges for feats of flying in a game that is at least in large measure about flying spaceships? Maybe you just haven't figured out how to build a good plane yet. That's actually not so easy.

I never said I did it deadstick! Although a couple of times I did hit it so close it only required a tiny bit of thrust from my jet engines to put it on the runway, and more often I've either had to fly under power for a few minutes to reach the KSC or alternately do some sort of a go-around. Even in those cases however, I rarely manage to both touch down and stop on the runway on the first try. And TBH if I end up in one piece anywhere near the KSC, I'll generally call it a day!

Agreed, but I also think the latter of those two things is quite a bit harder than the former. I could probably count on the fingers of one hand the number of times I've made a perfect runway landing from space on the first try, and I've flown a lot of space planes. I'm sure I could get the hang of it eventually though, and I'll happily afford an extra measure of prestige to those who can. I even think there should be in-game badges for such achievements.

In sandbox, it can be whatever you want. In career however, it has to be part of some kind of "extra easy" difficulty mode if you want everything enabled immediately. If you can't or won't learn some of the core skills of the game, then you have to pay some kind of prestige penalty for that.

Some find that tedious, while others like me find it meditative, but either way I don't think anybody here is disparaging the use of MechJeb by the former sort of player, especially by very experienced players operating beyond or outside of the scope of the normal career mode. If OTOH you find yourself doing that type of repetitive grind as a highly experienced player just to get through career mode, then perhaps you have not played career recently or else have suffered from a failure of imagination about how to make it more interesting for yourself. In the career game I'm just about done with now, my overarching goal was to do as many different exploration things as quickly as I could, and only to accept contracts that meshed readily with those goals, avoiding repetition as much as possible. Even with "hard" rates of science/rep/money returns, there were only a handful of specific missions I felt I had to fly repeatedly, which were mostly Kerbal rescue contracts to get more crew. I also did a number of passenger, repair, and ore contracts several times because they were so lucrative, but other than that I just explored away and took contracts only as they fit readily into that plan. In the process, I did a bunch of things I had never done before in sandbox, like redirect/mine asteroids, design a Grand Tour-capable ISRU platform, and create a prop-driven Eve lifter. It was way more grindy than that back in around 1.2x when I last played through career. "Docking mode" is perhaps the most useless feature in the entire game, but TBH from your description I think I'd find setting up a docking in MechJeb more tedious than just doing it manually. All you need to do once you're within a couple hundred meters is target/point the two ships at each other and then use the RCS controls on one of them to keep the target and prograde markers aligned and make sure the closing speed isn't too fast at the end. I generally use time warp during that process as well, so that the whole thing from 300m out to docked takes me perhaps 2 minutes on a bad day. I really don't see what's particularly tedious about that. With due respect, the first step to becoming a tank commander IRL is learning how to drive a tank. I don't have a problem with it if they create a "training wheels" difficulty mode for people like you to get through career. However what I don't want is for them to nerf the difficulty of the whole game just to accommodate you, because then I would find it boring.

My take is similar to @Pthigrivi's above. In a game that is about both building and flying spacecraft, just letting players ignore the whole flying part from the get-go would defeat the purpose. And to answer to a comment by OP about everybody using MechJeb because of how many people have downloaded it, I actually have MechJeb 2 installed, but I basically did so out of curiosity more than anything else and have never used it once in career to fly anything, and only in sandbox a few times to learn how it works, over the course of what by now must be something like 3,000 hours of gameplay. Having said that, I think that a lot of the vessel/flight informational resources provided by KER and MechJeb should be available in stock pretty much immediately. I also think that information about when various orbital transfer windows happen, as well as better tools for planning maneuvers, should at least become available pretty early in the career game. I mean, I actually did create my own transfer window and dV calculation tools in Excel, but I can respect that not everybody should be required to deal with that. But as to having the game actually fly missions for you, if you want that in stock career I think you should have to earn it. You don't want to manually fly the same run over and over? Then do it once manually, and after that the pilot who did it can do it the next time automatically. Other tools like suicide and de-orbit burn calculators/automation should require a certain level of pilot experience before they are unlocked. And as to nobody wanting to repeatedly drive some rover for hours to repair a crashed lander, 1) that problem is less about automating stuff than it is about the silly way the contract system in KSP1 works, which is something that has been commented on here endlessly, and 2) If you have to drive your rover for hours, maybe you should have figured out how to land it a little closer to its target! And lastly, in sandbox mode everything should be available immediately and there's no reason anybody should want to fight about it.

This is actually something I was thinking about doing in my current career game once I'm done with all my current missions, but with asteroids that haven't been mined out yet: Build a giant station complex out of at least 27 of them in the shape of the Borg cube.