herbal space program

Interesting for me to learn that they are trying to preserve so much of the way different parts performed in KSP1. I was not really expecting to be able to build the same ship I built in KSP1 and have it work the same in the new game. That seems to constrain a lot of the parameters of the new Kerbalverse significantly.

Works for me if it means I won't have to deal with all kinds of pain-in-the-butt life support!

I guess I kind of overstated what I meant there. It's really just stuff like clipping together 15 fuel tanks under a 1.25m fairing to nullify all their drag that I think should be disallowed somehow, at least in normal career/campaign modes. Extreme part-clipping and offsetting can can of course also abuse the aero model by allowing you to build ridiculously long and thin ships that are far more aerodynamically stable than they ought to be, and I'm not a big fan of that either. OTOH I totally get the aesthetic problems of not allowing any clipping at all. I mean, with the sorry assortment of wing parts we have, it's more or less impossible to build a decent-looking or even ideally functional plane without it. Perhaps this could be addressed by having a limit of 10%-15% of the volume of any non-hollow part that can be occupied by any other non-hollow parts. Hollow parts OTOH could have up to 90% of their volume occupied by other parts, and for design purposes these would include dry wings. Wet wings could also have a higher clipping limit, but at some point you'd have to pay a penalty in terms of their fuel capacity. I think something like that would represent a reasonable compromise between aesthetics and realism, especially since we seem to be getting at least procedural wings/control surfaces, and I hope maybe some other procedural airplane parts as well. And of course I really don't care if it's included in some kind of cheat menu or as an option in sandbox mode. It only really matters to me wrt vanilla career modes, because I don't think it's good game design for a physics simulator to have these exploits available by default. In the context of sandbox challenges, as you say it can be policed by the participants just fine.

I thought I made it pretty plain already, but here goes again: Just try to walk yourself mentally through what a KSP2 campaign-mode game is going to be like, with the goal being not to explore just one, but rather multiple star systems in the end. They are apparently keeping pretty much all the old parts, so that sure makes it seem like they mean to have you start where you started in KSP1 in terms of tech, if not at an even more primitive level. So you play up through all those KSP1 exercises and build all this infrastructure in the Kerbolar system, the main point of which is going to be to enable you to travel to the stars. What happens to all of that after you launch your first interstellar mission if the time it will take to get there is 50 or more times longer than the time it takes to do a Jool return mission at home? Are you just going to put all that on hold while you timewarp at 1,000,000X for 150 years? What if you first need to learn something about the remote system with a probe before it makes any sense to send a larger mission there? How long in terms of the time scale of in-system play are you willing to have that turnaround take? If there are multiple systems to explore, how are you going to manage the development of your resources in the first exoplanetary system you reach while other missions are in flight? If the timescales aren't too far apart, it's a manageable issue, but at some point it will become truly onerous. That is the gameplay problem I am talking about, and it already kind of exists along the lines of "what do I do in the Kerbin SOI to fill up the three or more years it takes for all my interplanetary missions get where they are going there and back?". Except this would represent that issue writ much larger. The only way to mitigate against that massive discontinuity in time scales if you are going to stick to interstellar distances typical of the Solar neighborhood is to make your interstellar ships go more than half the speed of light, which will require pure fantasy propulsion technologies representing a stark four-orders-of-magnitude discontinuity with everything that came before them. OTOH, every order of magnitude you bring your neighboring star systems closer represents an order of magnitude less ridiculously OP your interstellar propulsion tech needs to be to keep the relative time scales in some reasonable balance. That is, if you bring the other stars 100 times closer than that, then you are talking about only a 100-fold power-up, translating to ISPs on the order of 100,000 to build usable ships rather than some absurd number like 10,000,000 so that there can be some kind of plausible 2-way aspect to interstellar travel. I don't think I can make it any plainer than that.

I believe that's only true so long as you don't then enclose all those clipped-together parts in a fairing or cargo bay. I seem to recall some craft that did otherwise totally impossible things that way, so for that reason I hope that KSP2 cracks down on part-clipping in general Obviously this is just silly, so they need to totally rethink that. They totally need to rethink this too. Lifting bodies ought to generate lift, not disproportionate amounts of drag! I generally find this much more annoying than helpful. Between that and the soft stall behavior, when I do what seems like a proper flare, I often end up sailing right back into the air and then gliding along on what feels like some kind of exaggerated ground effect.

Yes, I understand that, and it does not address the point I was trying to make, which I have tried to explain now at such tiresome length that I am not gonna try again. I guess we will just have to see what they do, but if they really end up putting different star systems 2-5 ly apart I will be quite surprised and not particularly happy, because of the other things that will necessarily imply.

It would be different in the sense that if you have some kind of super-fast drive, whatever else you may have been doing in your home system doesn't have to stop completely for you to timewarp ahead a whole bunch of years, which seems to me like it would be really bad for gameplay overall. But as I said above, introducing such OP technology will create its own set of problems, which is why I feel like the best solution is to have the Kerbolar system be in a Kerbal-scaled region of much higher stellar density than the fairly sparse neighborhood our Sun inhabits, so that you can get to the next star system in something like 10 years of game time in a large colony ship that is going only around 100 times faster than the ships in KSP1 do, i.e. at no more than 1-2% of light speed. Perhaps smaller probes that can go a few times faster than this could also be possible, to collect information about other star systems before launching the actual colony ship.

Why even add Kerbals to the game then?

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.