SciMan

If Nate has said "no comment" every time, everyone's gonna see what they want to see in that. The people who want life support are going to see it as a confirmation of life support, and the people who don't want it (probably because of past negative experience) are gonna see that as Nate saying that it's not in the game. Me? I see it as [error data not available]. No comment is just that. A comment that doesn't exist. In other words, it's the same as saying "I can't confirm or deny 'thing XYZ'". Gotta remember to take off your rose-tinted glasses and look at the thing objectively. So do we know if life supports in the game yet or not? NO! After considering all the data available about the subject (which is nothing), I'm 100% certain that I have no idea if life support is in the game or not. This is very much a "known unknown". Now that that's out of the way, I can start discussing the topic like the rest of you have been. If life support IS in the game, I expect there are 2 potential locations on the timeline where it would be introduced. LS is in the game from day 1. Or LS is introduced into the game along with the colonization mechanics, either because the majority of LS is focused on "making sure your colonies can supply a habitable environment for the kerbals that are living there", or that it's for both ships AND colonies, and it doesn't make sense for one to exist without the other if they're eventually both going to be in the game.

Just had an idea about making it less grindy. Maybe there are a not small number of experiments that can only be run in certain biomes? For instance, robotic sample collection. IRL, you can't really get that much science done with only a sample scoop, especially if your land in a rocky riverbed. Your sample scoop simply won't be able to pick up those large rocks, even if your lander or rover is perfectly capable of landing in or traversing over such terrain without issue. For a rocky riverbed (or other rocky terrain), you'd want something like a rock drill, maybe the kind that extracts a core, maybe the kind that just pulverizes the rock and collects the created rock dust in a small container for conveyance to the sample analyzer system. If it extracts a core, it's kinda hard to analyze it on-site with robotic equipment, but you could store it and eventually return it to KSC to be analyzed there. If it creates rock dust, that's a lot easier to analyze, probably the best instrument to do that would be a gas chromatograph and mass spectrometer. Or you could do what Curiosity did, and mount FREAKING LAZER BEAMS that vaporize a small amount of the surface along with a specialized camera that can categorize the spectra of the (probably turned to plasma by the laser) rock vapor, to determine what it's made of. That laser DOES work pretty much anywhere since with enough heat everything turns into plasma that can then be analyzed, but there's a tradeoff in that you can't really analyze the physical structure of the rock or sand or dust you shot the laser at, all you can do is figure out some of the chemical makeup of it. Additionally, if the sample had any complex chemicals in it (maybe organic in nature?), the laser beam would certainly have caused those chemicals to be decomposed by the intense and highly localized heating, so in your spectrogram you'll be sensing the decomposition products not the chemical itself, and that means there's going to be an amount of uncertainty about what exactly that chemical compound could have been, because you'll only be able to detect "what elements and what relative abundances", not so much "what configurations were the atoms and molecules attached to each other". Water is easy enough to find with this method, but true evidence of life (complex organic chemicals) needs another experiment that collects samples a different way and doesn't expose them to such harsh heat. That's rocky terrain covered, what about more sandy or dusty terrain? Well obviously, scoops work a lot better here, and rock drills don't work quite as well (you can switch drill heads to make it work better, if for instance you have a rock grinding drill bit and a simple auger drill bit you'll have better coverage). Even the Dmagic science experiment mod in KSP 1 has 3 different ways of "sampling the surface to find out what it's made of", and that should be reflected in KSP 2's science system I think. The days of "just one kind of surface sample" should be long gone, because it's not that simple, different samples take different tools to collect, and each one will tell you different things about the planet. And the same goes for a bunch of other kinds of experiments and sensors too. There should even be a tiny ISRU experiment (however for the sake of the game it would be fun if it could also do double duty as a truly probe-scale ISRU, enabling a rocket-powered surface hopper to be made entirely unmanned, that might not be needed if rovers are a lot better in KSP 2 than in KSP 1 but I'd still love the option of a micro-scale low-output low power consumption ISRU suited to be put on just about anything (but it can't synthesize life support resources, so that would become the limiting factor of your vessels unless they're robotic, always gotta consider the tradeoffs).

It appears my reputation precedes me. Oh well. I usually have a lot to say about something, but that one, well I had basically already said mostly the same thing above it so I didn't feel the need to expand on it even further.

I'm sorry, but you're going to have to elaborate on your points a little bit better than that. Because right now, all I see is you saying "I don't agree" with every single point I mentioned, without making note of "why" you think that way, or "how is that wrong". For instance, when you say that the same reasoning can be applied to orbital mechanics. Maybe you're misinterpreting my statement, I'll admit it was quite vague. I disagree with you saying that you can apply the same reasoning. But the reason is this. Life support as a game mechanic is very hard to implement in a way that isn't "purely punitive". In other words, what do you get for having a working life support system on your vessel when it needs one? Your crew doesn't die. That's it, that's all you get, you get no "benefit", you just "don't get punished". That's not fun to me, and I doubt it's fun to many other people either. Now I get how that could be applied to craft design, because for instance if you build a gigantic fairing on the front of your rocket and you don't put large fins on the bottom of the rocket, it's gonna flip out and probably crash. But I don't get how that can be applied to orbital mechanics. Well, I guess I see a few ways that invalidate it is what I'm trying to say. What do you get for not putting enough fuel on your rocket, you don't get to space, yeah that's a point for you. But what do you get if you ignore orbital mechanics and you just build a gigantic high power rocket that can just burn towards the target for half the journey and burn to slow down for half the journey? You've ignored orbital mechanics again, but this time you achieved your mission goals, so that's the way I see that you can't apply the "it's only ever neutral or not fun" logic to orbital mechanics. When I said that I didn't like the "you must play my way and not your way" kind of message that some of those choices I mentioned seem to imply, I didn't mean "someone might want to play a different video game entirely" like you seem to have interpreted it. Instead, I meant that KSP 2, like KSP 1 before it, is going to be a sandboxed game focused on enabling player creativity, and a "only punish, never reward" type system is a system that restricts player creativity more than I think is warranted. When I said "why wouldn't people just time warp thru the signal delay", well you may have said there's other things going on, but that's not a 100% true fact, it's an assumption. There are cases where you're stuck without anything else to do and all you can do is just time warp thru that signal delay, and that doesn't sound like fun to me. As for your final statement, well I'll be slightly blunt, since it looks to me like you were similarly blunt. I don't see what your line of reasoning is to be able to reduce the entirety of that multi-faceted statement to such a simple thing as an "i win button" type game. To be honest, it strikes me as slightly offensive. I am aware of the "reduce to an absurdity" format of some logical arguments, but at the same time in this case I'll simply reject it unless you can go into more detail on how you've reduced my argument to that point, hopefully over the course of several steps. In other words, "Show your work". EDIT: If the "show your work" line of argument fails, I'm going to just have to agree to disagree, as I've realized that we're just comparing opinions, not facts. EDIT 2: Additionally, if we were able to reduce such a game to that PNG of "you win" as you mention, well that's obviously not a game, and nobody with any kind of sense would pay $50 for it. The "theoretical simplest game" isn't a game. IDK what it is, but it's not enough of a game to be a game, even if it meets the established requirements for "a game". Because that's the problem with defining what a game is, for every time you change the definitions, I could make a "different game" that doesn't "feel like a game". That's what happens when you try to use numbers to describe things that are better described with words or feelings.

I would like some more comments on my ideas about the little details I went into about the antenna system, I thought that was a rather engaging gameplay mechanic that gives you several ways to solve any one communications problem. Anyways, about the quote (couldn't figure out how to put that little beginning statement above the quote that I picked out): Well, that's why I think all "sensor" experiments should be able to be run in "data-logging" mode, or in other words continuously. For the thermometer at the launch pad example, not only would that give you more "basic" data to work with (to for example build an idea of what the "average temperature range" is at that location), but it would also allow you to track time-varying trends in the data, which if you have any experience with meteorology then you'll know that having a good network of sensing stations that can be polled for data at any time is one of the central pillars that holds up that whole arm of science with regards to weather forecasting. So a player might start with just pressure and temperature data, but then they might come back later with a better instrument package that adds in wind speed, wind direction, humidity, and potentially even can make the communications antenna do double-duty as a lightning detector (Lightning bolts, being electric arcs, are a source of very powerful EM radiation, and that includes wide-band radio noise). How does it make the antenna do that? Easy, antennas are the thing used to send or receive radio waves, and like I just said, lightning bolts put out a lot of radio waves. If there's also a microphone on the weather station, a relatively low-power and low-capacity microprocessor can be used to measure the delay between the lightning strike and when the thunderclap arrives at the weather station, and from that divide by the local atmospheric speed of sound to get a distance to the lightning strike. With a network of such sensors, you can build a map of where lightning has struck recently, and this is done IRL on many weather radar sites (look thru the options on the display to find it, it should be there and not too hard to find). So what does that mean for KSP 2? Well, to me it means that you could gain either science or get paid to put out a network of weather sensor stations around Kerbin, maybe for max science return or payment you'd need to put down X per biome, with Y meters distance between the sensors. Ideally they would be placed in a way that forms at least one triangle, so just dropping them out the back as you fly overhead in a straight line wouldn't be ideal (you can't triangulate with a straight line unless the sensors can also tell what direction the data came from). But even more in line with what KSP 2 is all about, you can measure planetary surface weather (and solar weather as well) using satellites and probes. IRL, we technically have a weather satellite around Mars right now (it also does mapping and communications relay duties, NASA seems to use all 3 capabilities pretty much equally). And that probe we have in Mars orbit has been critical to our ability to further explore Mars with probes. It will also likely be critical to the manned exploration of Mars (or replaced by superior equipment), whenever we're ready to do that. So basically, the point is this. If you can run a sensor for longer than "spit out one measurement and then don't do anything again until the player interacts with it", the player should get rewarded for that. However, obviously, sometimes that's not possible because of constraints of communications, time, or power, so the sensor type experiments should retain the ability to be operated in "one-shot" mode as all experiments operate in KSP 1 (this would use a lot less power and not take any appreciable amount of time to transmit the data, but it would also severely limit the amount of science data you'd gain from it to say 5% of the total compared to an experiment that is allowed to run to completion). If you're getting the idea that I want science in KSP 2 to work more or less a lot like it does in Kerbalism in KSP 1, well that's exactly correct. The main reason I don't use Kerbalism in my KSP 1 games is because it "adds too many things and makes KSP not play like KSP" to me (and yes I realize that that is an opinion, and therefore totally subjective, I'm not trying to start an argument about Kerbalism here). Experiments that return data over time are good, some experiments can't do that (surface samples are the only one that comes to mind at the moment, and no I don't think the materials bay experiment should be an "instant" experiment because when we sent a "materials bay" into orbit IRL using the Shuttle, it did indeed "run over time" before it was recovered and brought back for study, if you want to look up that experiment it was called the LDEF, or Long Duration Exposure Facility).

Base game as far as I know is confirmed to have at least the starting Kerbol solar system, the DebDeb system, and AT LEAST one more. So I'm going to say "minimum 3, maximum 5 in base game, DLCs will add more (how many I don't know, depends on how long the developers intend to support KSP 2 I suppose, since the DLC is what brings in the money), and then mods will add probably 100x what the DLC adds". That should just about cover it, at least in my opinion.

To be honest, I think procedural solar panels are almost a shoe-in. Let me explain. We already know we're going to have procedural radiators right? What's a solar panel but a radiator with the energy going in instead of out? I assume they'll be simulating solar heating on the procedural radiators, and from that it's only a short (coding) leap to procedural solar panels, right? Now I don't know if we'll get procedural PIVOTING or procedural DEPLOYING solar panels, since I haven't seen those kinds of radiators as procedural parts yet. But it wouldn't surprise me to see them, because as has been said in this thread, the only difference between a procedural radiator and a non procedural one is if you can tile the bit in the middle or not. The art side of things might take more to sort out than the coding side, in reality. And yes, that would indeed make all solar panels look sort of "samey" but that's not a horrible thing. If it is seen as a negative thing, then it's just more work for the art department to add solar panels (or radiators, or wing parts) that look different from the other ones while still being procedural.

I think that most experiments should be "sensor-type" experiments. There would be exceptions, like surface samples for instance would be a "instantaneous" result (and we really need a way to collect those without the presence of a crew). All the experiments give you "Data" or "science points", or "whatever they come up with to represent scientific data in a general sense" (the name doesn't make a difference to me personally). The data would require time to be analyzed by the scientists back at KSC (or in an orbital science lab, if the signal can reach it, no you don't have to bring the actual experiment back unless it's something physical like a surface sample or goo pod or materials bay). Sensor data would be generated over time, not instantly. Physical experiment data like surface samples would be gathered instantly, and you would get only a vanishingly small amount of data from transmitting it without a "sample analysis" experiment to go with the "sample collector" experiment (similar to the sort of instrument used to analyze soil samples that's carried by Curiosity). To generate sensor data, you would need 2 things: Power to run the sensor(s), A place to put the data. There are 2 places to put the data: A data recorder, An antenna that has a valid connection to any of (a crewed science lab, a colony with a research lab, or KSC itself). Antennas are the primary means of moving data around. You "can" return data recorders to "within recovery range" of anywhere that would accept an antenna connection, but this doesn't gain you anything over just transmitting the data. It might be the only way to do things for some missions tho, due to mass, power budget, or tech limitations. Put another way, data recorders act like "a battery for sensor data". All probes and command capsules would have a pretty small data recorder built in, enough to store the data of one instant experiment, or the data from most of an orbit of a sensor experiment. There would be a separate data recorder part (in several sizes) that would be able to add on to that capacity, if needed (and if you have more than one sensor going and expect to lose signal, you're going to need that extra data recording capacity). Later tech data recorders would be smaller and lighter than early tech data recorders, eventually going to solid state data recorders that are packaged in a radiation vault (still lighter than a rad-tolerant magnetic tape recorder, because it's just a few chips in a thin lead box). Data recorders "charge" or store data when the antenna can't handle transmitting the data back to somewhere else. This can be because the antenna doesn't have enough bandwidth, and/or it can be because the antenna doesn't have a valid connection. But if the antenna has a valid connection, and the antenna is not using all the bandwidth that it can carry, the data recorder will fill in the extra bandwidth to allow the antenna to operate at full speed, until there is no more data in the recorder. So if you have a high-bandwidth experiment like a video camera, you should really be using high bandwidth antennas, tho these would obviously take a lot of power to run. But if you have a low-bandwidth experiment like a thermometer, you'd probably want to save power by choosing a lower bandwidth antenna. Because no matter what bandwidth of science data signal is being carried by the antenna, it uses a fixed amount of power to transmit. However, it CAN still makes sense to use a high bandwidth antenna even on small probes, because there's a trick that reduces the power needs. You need a data recorder AND the antenna tho. It's called "Data burst mode". This makes a data recorder and an antenna work together. The data recorder stores data until it's mostly full, and then (using a lot of power but only for a short time in the high bandwidth antenna) the antenna will transmit the data in the recorder until the recorder is empty. The cycle then repeats. If you're familiar with what a "relaxation oscillator" is, this is basically one of those in a way. There are 4 factors in play with the antennas (both IRL and in my proposal): Range, Power usage, Bandwidth, and physical Size For the same Bandwidth and range, the smaller the antenna is, the more power it's going to use, because this means the signal is less directional (more power gets "wasted" by not being pointed at the antenna on the other end, so you need more transmit power to compensate). For the same Bandwidth and Power usage, the smaller the antenna is, the shorter its range will be (again, the signal spreads out more with the smaller antenna, so it's not "loud" enough to be received as far away as with a larger antenna). For the same Range and Power usage, the smaller the Bandwidth you need, the smaller the antenna can be (it takes a longer time to pick out a smaller signal from the background noise, and smaller antennas that use the same power don't emit as much of a signal in the right direction for it to get picked up by the antenna on the other end). "OK", you're going to say, "What does this gain the player?" Glad you asked. Having this many different variables in play allows the player a lot of choices for how they want to solve their data transmission problems. Having this many choices means that there's a lot of solutions that can be made to work. It also allows you to simulate things like the Galileo mission, where the main high-gain antenna didn't deploy right and they had to use the included data recorder to store data that would have otherwise been transmitted as it was gathered, but the low-gain antenna didn't have the bandwidth to do that.

It makes the player click more buttons, and use a few more seconds or minutes, for no added benefit (IMO).

Agreed, that's the same problem Life Support has. What purpose is there to the added realism? What perceived benefit? We don't need an "enforced iron-man" game mode, as the default game mode, that's what I'm trying to say. And as much as it's a minor step, putting communication delay of ANY sort into KSP 2 would in fact be a step towards that. If it's an option that's default off, and if that's the case you can bet every cent you have that 90% of players won't touch that option, why even code it in the first place, especially when you have to hold it to such a high standard as the rest of the game? Same with life support, aside from being "realistic" what benefit do you gain from preventing the player from sending someone on an interstellar voyage on an external command seat? Not really any benefit that I see, aside from a "you must play my personal own way not your way" kind of message, that I don't think KSP 2 is trying to send. KSP 2 is trying to tell you to work with the laws of physics, it's not trying to enforce a standardized interstellar vessel design guide, you know? Each player has to come up with their own standards, (or not!) it's totally up to them. Part of KSP 1's charm is in fact the fact that you CAN do these very "unrealistic" things that a life support system (or communications delay) would prevent. And if it's only the science transmission that gets delayed, then why would the player not just time warp thru the delay, introducing a waste of time that doesn't actually gain the player anything that they wouldn't have if the transmission completed instantly? Perhaps an analogy is in order: Nobody likes having to wait to play with their new toys, right? Some of you reading this might know that feeling of being told you can't unwrap your winter holiday presents until after the winter holiday dinner. I know that as a kid if I was told to do that, and I was physically prevented from unwrapping my presents, I'd throw the mother of all temper tantrums. Even today, if I was told to wait and I saw other people unwrapping presents, I'd start unwrapping my presents, and I wouldn't have a care as to what words my parents said to me regarding "don't do that yet". This isn't because I'm an entitled brat. This is because to a kid, the word "wait" means the same as the word "no", and I know my little kid brain would have been thinking "my parents always say no to my fun ideas, so I'm just going to skip the step where I ask and do what I want anyways", despite me now with my adult brain having a good understanding of why they won't for instance "let me play with matches" or "eat the tide pods" or "play with dad's gun" or something else that when I was a kid I thought might be fun, but my parents back then knew that those activities would actually either harm me or destroy things that are valuable to either myself or my parents, so they were forced to say "no" to a lot of things because kids are not logical thinkers. Well, let's say now you're playing KSP 2, and you've just finished a big mission to a distant planet, and you want to send the results home to unlock more parts to use on the next mission to another planet. ".... What do you mean I have to wait for the message to get here?" (inner kid comes out) "I wanna play with my new toys!" "This game sucks!" "I want a refund!" "Who cares that science says that signals travel at the speed of light, I read somewhere that the Kerbol solar system is 10x smaller than the IRL solar system, so the speed of light delay should be 10x lower, right?" .... "Are you kidding me, they ALSO lowered the speed of light by 10x? That just breaks MORE laws of physics!" "This whole game is full of arbitrary and unrealistic design decisions that just force me to waste the limited time I have available to play it!" "I'm never playing this again and I'm telling all my friends that we'll just go play some other (less realistic) space game instead, or who knows, we might just play Minecraft or Fortnite anyways because it was already incredibly hard to convince my friends to even look at this game because they saw it and all they saw was a bunch of 'math homework'" Point is, raising kids is hard (which is why I'm never having them), and video games make terrible parents So don't make players wait to use the science data they just transmitted from the mission they spent so much effort piloting, which just wastes their precious (irl) play time. As much as time warp helps, it still takes a few real-life seconds to warp 5-20 minutes in-game. And that only gets worse with increasing signal delay. This is one of the things KSP got right the first time, and it shouldn't mess with it. Because if they DO mess with it, you just know that there's VERY quickly going to be a mod released that removes that gameplay mechanic entirely, and it's gonna be VERY popular. EDIT: I guess that puts me firmly in the camp of "option B: No delay for anything" being the option that will most likely be put into the game. This is very much something that should be left to the modders. On a side note, there's only one way to include CONTROL signal delay. And that's if you have the rule that "presence of a crew removes signal delay entirely, and probe cores can have sequences of commands uploaded to them to allow for them to complete things despite the signal delay". That's basically how Remotetech (of it's various versions) worked, it's how you have to play RSS-RO/RP-1, and to be honest it's not that bad. But it requires something else to be coded, and that kinda kills the whole idea. It requires the includsion of a full-featured autopilot, similar to (and likely superior to) MechJeb. Otherwise, you're pretty much left fumbling in the dark, fighting against game mechanics that bring far more tedium and pain than they bring joy and fulfillment.

No need for procedural heat shields to be "confirmed" in any way by any of the evidence provided so far. Just make the part's overall heat tolerance high enough to generally survive reentry, and then using the (confirmed) ability to paint your craft pretty much however you want, simply apply a heat shield texture to the underside. "Best part is no part" after all, right? EDIT: Of course, having the ability to make procedural parts that act as a heat shield would be nice, but my point is that it's not in any way absolutely required for the game to be "complete". All you need is enough heat shield sizes to be useful with the various reentry-capable crew capsules, and maybe some more to cover the larger cylindrical fuel tank diameters. The space plane parts can, as I mentioned, just have a fancy paint job and a normally high heat tolerance, because most space planes IRL don't even use an ablative heat shield in the first place (well, neither the Shuttle nor Buran did anyways, and the X-34's heat shield isn't "supposed" to ablate, but it "can" if the temperatures get too high, and that's also how Starship's heat shield is probably going to work (as in it will also be an "optionally ablative" heat shield)). END EDIT Trust me, I'm not trying to be a pessimist here, but at the same time, KSP 2 isn't "the ultimate accurate space flight simulator" and never was intended to be. KSP 2 is a Capital G "Game", and a very much lower-case s "simulator". From that, not everything needs to be simulated super realistically. Lots of things ARE, but that's because they're part of core gameplay loops. If your vessel survives reentry or not isn't something that they're going to be focusing a lot on, because all it has to do is have a reasonable "pass" and a reasonable "fail" state. Nothing more is required of it. They don't have to force you to optimize the heat shield thickness so your barely-good-enough spaceplane lands with a razor-thin margin left on its heat shield. It just has to have a high enough heat tolerance that the player can believe that it would survive reentry if it has the right paint job on it. Heck, before the Mk2 parts were part of stock KSP (and yes, they were originally a mod), the description made particular note of the "painted on heat shield tiles and oh just trust us it'll survive reentry *wink*" more or less, it was very tongue in cheek (also back then reentry heating wasn't even simulated at all, neither was the reentry plasma effect in the game, those came around back in 0.17 IIRC, and we still had to deal with "air-hogging" SSTO's and the "souposphere" instead of the atmosphere we have these days that meant you basically couldn't exceed the speed of sound no matter how much thrust you had below 10km altitude). And back then, we only had like maybe 5 people complaining about the lack of accuracy of the atmospheric modeling, we just kinda dealt with it and had our fun because we didn't know it could be any better until it actually got better (you can thank Ferram of FAR fame for pushing forward the idea that KSP's aerodynamic physics were all kinds of messed up, these days there's not much difference between the stock aerodynamic model and FAR but back then it was night and day). All it is is that I see an easy way that they could get something that looks and functions like it has "procedural heat shielding" on it, without actually needing that system (that needs time spent to code it, iterate on it, test it, and finally bring it to a polished state). In other words, my way gets the same results faster, even if it means the simulation isn't simulating as much.

More parts AND less parts, at the same time. Allow me to explain, because that probably sounded like "a lawyer that is trying to have their cake and eat it too by giving a non-answer to a legitimate question", but I promise that's not what was intended. It really IS "both" more parts and (maybe) less parts at the same time. How is this possible? Procedural parts in both the "more parts" and "less parts" answers. It depends on how you look at it. I know this might not be how it works in ACTUAL KSP 2, but let's just say for example that it works like in KSP 1, with each part having one config file. From that, you can easily figure out "how many parts are in the game" by counting the number of config files that are parts that are included with the game. And because procedural parts are adjustable parts but you only need one config file to represent them, you might end up with a game that has enough parts to allow the same amount of creativity in designing your creations, but uses LESS config files (and therefore "less parts") to do so. However, from another angle each procedural part can be said to contain many parts "inside" it because it's adjustable. This definition is still entirely valid, but I find it less useful than the first definition because if you can just type in "nearly any number" into each of the various adjustable parameters for the part, you end up with a functionally infinite (aka "big enough that just saying infinite doesn't change the answer enough to make a difference") number of parts even if you have just a single procedural part in the game. Of course, they'll probably put limits on just how big of a number you can put in those boxes, and might also put limits on just how small of a change you can make to each value, just so that they don't have to use 64 bit signed floating point numbers to represent the shape of a procedural part because really the difference between 0.001mm and 0.1mm being the smallest change you can make to a part won't make or break the design of any large craft, and if you really need a wing that is 100m long you can probably make it out of several 10m long sections without angering the physics engine that much. And within those limits, you can make pretty much any shape or size part you desire or have need of, suited (or not) entirely to the task at hand. But if you want my opinion on if there are going to be more or less parts in the game, going by the "1 part = 1 config file defining a part, even if it's a procedural part" definition, well here it is: Short answer: I have no idea! Longer answer: There's a lot of changes coming to KSP 2, some of them add parts, some of them take away parts, but I think that overall we'll have a "more complete" list of parts, even if the overall number of different parts is smaller. Details: I think we'll lose a lot of parts that we currently have in KSP 1: We've seen in the latest trailer that we're probably only going to have a limited number of different wing panel and aerodynamic control surface parts to choose from, but they'll be procedural (effectively more parts, but less "config files for parts"). We also know that we're getting procedural radiators, but I haven't seen any data that shows if the KSP 1 non-procedural, sun-tracking (orients to edge-on to the sun), deployable radiators will still be in the game, or if those too will indeed become procedural. I'm pretty certain that we'll also be getting procedural fixed solar panels, because well that's just low-hanging fruit if you already have a framework for making procedural flat parts like wings and radiators, but again we might also be getting solar panel parts that are procedural in more ways, like being able to choose if they can be deployed, retracted, track the sun, or have a cover to shield them from aerodynamic forces while retracted (likely only a few different kinds of solar panels in any case, with procedural options filling out the areas "in-between" the default options). We do also know that we're going to be getting fuel tanks that are 7.5m or larger, which would be new parts even if they're procedural in length. IIRC (but I forget where I saw it), we're going to be losing some parts that are dedicated to having only a single resource in them, because now we'll be able to choose the contents of fuel tanks when in the VAB (and maybe after, but that's something a mod will take care of if it's not in the vanilla game on day 1 or "eventually"). So the "liquid fuel" and "Rocket fuel" fuselages for 1.25m, mk2, and mk3 form factors will be unified into one line of "generic fuel tanks" that will have options to set what's actually in them. This might also get rid of many of the monopropellant tanks, tho I'm not sure of that. However, I also think we'll GAIN a lot of parts. I've seen at least a few "new-looking" crew capsule parts in the various feature videos that have been released for KSP 2, so that's more new parts. I also think that they will be filling at least some of the gaps in KSP 1's parts offerings. Those gaps in KSP 1's parts list include: There's no good "booster" type engine that fits a 0.625m diameter fuel tank (the Spark is more a "mid-stage" engine, as it has "okay" ISP at both sea level and vacuum, and middling thrust, I want a BOOSTER engine that's heavier (maybe 0.375t), has higher thrust (maybe 40-50kN), as well as higher ASL ISP but lower Vacuum ISP. Such an engine might also make a good option when clustered on a 1.25m diameter low-mass booster stage that you'd otherwise have to put a full Swivel engine on. There's only the one length of 0.625m LFO fuel tank (the Oscar-B), there should be a whole range of lengths that preserves the Oscar-B's excellent ratio of fuel amount to physical size (lengths should range from 1x Oscar-B to 8x or 16x Oscar-B, making the 0.625m diameter finally usable for tiny launch vehicles without turning into a wobbly noodle rocket). I'd really like more RCS thruster options that use LFO instead of monopropellant, my large upper stages that dock things and then de-orbit themselves really could do with having lower part count instead of having over 12 Vernors just to get full 3-axis control in both translation and rotation. I think that the idea of an engine that responds to the main throttle that uses Monopropellant should be expanded on, the Puff is plenty good but I'd love a version I can put on a 0.625m stack, as well as versions that have good ASL ISP, as well as lower thrust versions intended for probes (IRL plenty of satellites use "monoprop" aka Hydrazine for both RCS and main propulsion). There is only the one Ion engine, and there is only the one NTR engine (I know that KSP 2 is adding at least one more NTR engine, thankfully). There should be a higher efficiency option for RCS thrusters available, likely this means some form of quick-responding Electric propulsion thruster miniaturized into a series of RCS parts (both linear ports and many configurations of multi-port blocks). Building on the 3 points above this one, I think there should be an entry-level electric propulsion option (as in you unlock it BEFORE the xenon ion engine). This would be a Resistojet or Arcjet. Initially, such a thruster would pass Monopropellant thru either a heating element or an electric arc in order to generate a jet of hot gas to be ejected out an exhaust nozzle. If it wasn't already obvious, the laws of physics that dictate how rocket engines means that resistojet thrusters must have a lower vacuum ISP than Arcjet thrusters, because the propellant that is passed thru a Resistojet does not reach as high of a temperature as that passed thru an Arcjet. One of the higher efficiency RCS thruster options I was thinking of in the point above this one is Resistojet or Arcjet RCS parts, the advantage that these would have over say a small Xenon Ion engine re-purposed as an RCS port or block would be that Arcjets and Resistojets are very versatile when it comes to what propellant they are willing to work with, so with these arcjet/resistojet RCS parts (and the associated engines which respond to the main throttle), you should eventually be able to unlock the ability to use them with other propellants instead of Monopropellant, such as Methane (aka KSP 1's Liquid Fuel), Hydrogen (good for vessels using NTR engines), Xenon (in a pinch, and this might be the way that the Kerbals discover that Xenon makes a good ion engine fuel), and even Atmospheric gases (assuming the presence of a related intake device more usually used for air-breathing engines, this last option would make it possible to build jet powered VTOL craft that don't have to carry around Monopropellant unless they also visit the vacuum of space). Ideally (because Arcjets and Resistojets are SO versatile), you'd be able to choose which propellant to use in-flight without needing an Engineer to go EVA and actually change the plumbing, because it should be as simple as having more than one propellant supplied to the appropriate thruster or engine. Now that I'm thinking of it, provided a steady supply of electricity such RCS thrusters and engines would also make ideal propulsion for a craft that relies on ISRU, because there's gotta be SOMETHING in those rocks that you can refine and push out a rocket nozzle, right? Speaking of ISRU, you know what a good way to push around an asteroid is? Sorry, this isn't a DART reference, instead I'm advocating for a Mass Driver part, that would take any mined resource and eject it at great speed in a very specific direction, in order to create thrust. This doesn't have to create a lot of thrust, or be particularly high specific impulse, but either or both of those things would be very welcome. It would however probably have to take a lot of power. And this would be a great way to do two things. I've already mentioned the use of a mass driver for propulsion, but there's more things you can do with this. You can throw rocks into high suborbital trajectories. If you put tiny rockets on those rocks, you can get them all the way into a stable orbit, for later collection by vessels that service an orbital station. From there, that station can make use of those raw materials, which means you can put the refinery in orbit instead of on the surface. Just like using a mass driver for propulsion, it would take a lot of power, so it's probably best suited to use in a Colonization and Resource Gathering context, so maybe it isn't in KSP 2 on day 1. But I'd love to see it in the game. Back to parts that KSP 1 doesn't have that I think should be in the list of parts that KSP 2 has: There are literally zero "single-part" solutions for engines that fit a fuel tank diameter of 5m or larger, and we know we're getting at least 7.5m diameter fuel tanks (and probably larger) so that's a gap that needs filling. There is no "low profile landing engine" similar to the Poodle but built for a main body diameter of 3.75m (or 5m and above but that stems from the above point). There are no SRBs that have thrust vectoring that are of a diameter smaller than 2.5m (the Kickback should have it at least). Speaking of SRBs, there are no SRBs larger than 2.5m, and there are no SRBs that are optimized for use in a vacuum by the presence of a larger exhaust nozzle to improve vacuum ISP. Now on to the tiniest of the SRBs that are in KSP 1, the Sepratron. We need more options for separating spent stages from our main launch stage: A nose-cone that incorporates a Sepratron-like SRB (available in many diameters as well as perhaps Mk2 and Mk3 fuselage nose cone form factors). A Sepratron-like SRB that mounts in-line but fires out the side to help push away the bottom of spent liquid-fueled booster stages (or creative people could use them as the final braking rockets for a lander that has parachutes for landing something on its side but doesn't quite have enough parachutes to slow down to a safe landing velocity, sort of like how the Soyuz capsule works IRL). I'd love to see Radial and In-line decouplers that have built in sepratron-type separation SRBs, because that saves even more parts. Most of the reason that I barely ever put the separation and ullage thrusters on my KSP launch vehicles is for one reason, and one reason only: I want to minimize the number of parts I use on the launcher, because that means I can use more parts on the payload (or just have a less laggy rocket overall). It doesn't matter how much optimization they do, more parts will always and forever mean more lag and a lower framerate, and vice versa less parts will always and forever mean less lag and a higher framerate, assuming you have the same computer parts for both sides of that test. A procedural airbrake would be a nice part to have, I guess it would replace the existing airbrake (or there could be more shapes of airbrake available). It would also be nice to have Grid Fins available as a type of toggleable control surface (as in they would fold out from the craft like on the Falcon 9 and Falcon Heavy, or alternately be able to be fixed in place (and largely ignored by the aerodynamics simulation) as they will be doing on Starship's SuperHeavy booster stage). Also would be nice to have Starship type control surfaces available, that way we could make craft that do a similar "belly flop and flip" type EDL sequence. Oh yeah and if I can ask for the moon and have a chance of getting it, a type of "landing gear" that I'd love to see is Airbags (complete with the bouncy-castle in a breeze like "bounding over the surface of the planet or moon" type final part of the EDL sequence, like what happened with Spirit and Opportunity, and Sojourner before that).

So what if they're incomplete games? 3 of the 4 games I have been playing for the past year are feature incomplete. Right now, I've spent the past year playing Satisfactory, Dyson Sphere Program, KSP, and Factorio for the most part. Factorio is so amazingly optimized that it's coming to the Nintendo Switch despite being originally developed for PC. And when I say "developed for PC", I guess I don't mean "gaming PC", or at least that's what my experience has been. I'm shocked at my own experience, but as a joke I installed Factorio on a 10 year old laptop that was originally like $300 (so not a gaming laptop) and this thing is these days basically only good for being a gorified web browser, but despite that I was able to import the save of a huge and complex factory (not the biggest I've ever built, but plenty big), and the game STILL ran perfectly fine at 60FPS after turning down some of the more demanding graphics options to account for the fact that I'm working with a GPU that's integrated into the CPU, and not a dedicated GPU that has its own VRAM. The other 3 of those games are feature incomplete (KSP, Satisfactory, and DSP). Of those, 2 of them are very open and transparent about the fact that they're still very much in early access, in fact you can't play them (without mods) without having a little part of the GUI in the corner of the screen put a label on there saying "Early Access build: blahblahlbah" or something like that. Spoiler: Factorio on the Nintendo Switch is a pretty big deal, in actuality!

@Motokid600 Take Two is just a corporation like any other. They can do things that are greedy and seen as "evil overlording capitalism company blah blah blah" but they don't OWN the people making KSP 2. So if Take Two made a decision that REALLY would kill KSP 2's prospects of being loved by the fans of KSP 1, those developers would simply join together, and pretty much collectively say "Fine, we'll do it on our own!", followed by them all resigning from Intercept Games and forming a wholly KSP fan owned and operated company dedicated to finishing the work on KSP 2. Also, games that have those bad monetization models and "pay to win" or "pay to not grind" type of game loops tend to be designed to play that way from the start. There were no games that I know of that got "infected" with microtransactions "after release". They either got them during early access (in which case it was likely always in the road-map from the start), or they had them from the start to begin with (again, that means that monetization would have always been in the plan from the start). In other words, "Take Two stands to gain exactly nothing by being an overly meddling game producer company for Intercept Games, because these people love this game so much that they'll get it done the right way even if that means problems producing it". From the modding angle it doesn't make sense either, and here's why: KSP fans are so dedicated that merely putting a DMCA takedown on a mod won't kill that mod. They'll come up with another implementation of that mod (maybe coded differently and better, maybe just forked) with a new name, distributed somewhere else, within a week or 3. Even if that means using back-channel methods to distribute those mods. But in reality, it'll never come to that, because Take Two probably knows to not mess with this game in that way. The whole thing with banning modding of GTA 5 did NOTHING to stop people from modding GTA 5, they continued on like nothing happened, because from Take Two's perspective, it's an impossible game of whack-a-mole. You ban or sue one modder, and 5 more pop up doing literally the same thing in their place. Besides, you can't do any of this if KSP 2 doesn't require a persistent online connection, because then you can't force it to verify its game files (aka the stuff people would be modifying) before you play with it. That whole "not requiring an online connection" is another thing that is designed in to KSP 2 from the ground-up. Along with no DRM. Combine all that together, and you get a game that's not only open to modding on purpose, but even if it wasn't it wouldn't be too hard to make sure mods stay working from version to version of KSP 2 even if you had to do things like code injection (like you have to do with a few other games like Valheim and Risk of Rain 2 and Dyson Sphere Program). So I'm of the opinion that modding is inevitable and not able to be prevented.

I usually try to explain things with an "in-universe" explanation first. But at the end of the day, "it's a game, let it be a game, games are supposed to be fun, XYZ new weird mechanic that nobody asked for isn't fun and shouldn't be in the game" is my fallback line of reasoning. And this time, "lightspeed communications delay for science transmission only and not probe control" is... very much not fun. Nobody likes having to wait to play with the new toys that the game told you "you unlocked this new thing" but you "can't actually play with them" because "the message hasn't gotten here yet" or something. I'm not playing KSP 2 to "wait for something in the mail", which is what lightspeed communications delay for science transmission and tech tree unlock synchronization does. I only put up with 2-day delivery on Amazon because it costs an absurd amount of money to get even faster shipping. It costs 0 dollars to not play KSP 2 because it has a mechanic that introduces too much grind or "I could be doing so many other things right now that would probably be more fun" type incentives. I don't do no hit runs. I don't do speed runs. If a game is too grindy, I'll cheat or just not play it. I generally don't play rogue-likes for a long time, even if I was really interested in them to start off. KSP 1 as it is is already too grindy, which is why instead of playing it continuously I play it in short bursts of like 2-3 months at a time. After a while I forget how grindy it is, and I start thinking it's a fun game again, so I come back, find out it's very grindy, and get turned off of it. And that cycle repeats. I don't want that happening with KSP 2. I don't even play KSP 1 career because locking things behind money just gets in the way of building and flying rockets. Same with the research requirements in Science mode, now that I think of it. All it does is get in the way. The tech tree isn't even organized in such a way that you get the truly useful and "really you should have these from the start" structural parts like beams and girders (the kinds of things that should be able to be taken directly from mundane architecture instead of having to unlock a "space rated" version), because parts of literal ground buildings shouldn't be locked behind needing to get research from the Mun. Same with the aerodynamics parts, there's no reason going to the Mun should unlock research about how to go faster thru the atmosphere with air-breathing propulsion.

I can agree with that, I guess it's even better if it doesn't need a reason to explain it away, especially if that reason violates the known laws of physics. "Because it's a game, dangit" is a fine reason. Not all things need to have an in-universe "immersive" explanation. If you provide an in-universe explanation for everything, you do make a very immersive universe. But you also have to very carefully skirt around falling into the pit of making your "different" universe just be "Real life but almost not".

Easy. All capsules probably still have small monopropellant tanks (they might have even increased the capacity of the monopropellant tanks because that reduces part count). If that's still the same-old Mk1-3 capsule that I think it is, then it should store 30 units of monopropellant. If you're really good at rendezvous and docking, that's way more than you technically "need" to dock probably 1 or 2 times. I generally don't put that much monopropellant on my craft. The RCS is only used for docking and OCCASIONALLY to prevent an extremely seriously sideways landing attitude from becoming a landing that flipped on its side. As for what happened to this particular lander, I can only imagine that since the terrain is relatively flat that they tried to contact the ground while still having some significant sideways velocity (my estimates are in the range of 3-5 m/s horizontal velocity at touchdown). This then caused the classic "flip over and oh crap shut off the engines" response, when they should have seen that they were tilting sideways when they touched, mashed "full throttle" while the craft still had the engines pointing "sort of down" engaged the RCS and corrected attitude to pointing up again, cut throttle, point retrograde, and tried for landing again. EDIT: This would have resulted in them likely having an "eventful but largely successful" landing EDIT 2: I know that this is the right thing to do because I've had a very similar situation happen to me on more than one occasion. It's a lot like landing on an aircraft carrier. If you miss the arresting cable, you don't cut throttle. You go to FULL AFTERBURNER as quickly as the engines can do that, because you're not gonna be able to stop, your only choice is to go around and try again.

Did the forum just break somehow? Because all those "the parallax thread can be found here" links are coming up as a white box with a sad face saying "Sorry, this content is no longer available." But from what I saw on the OP, Parallax looks great, at least on Kerbin. I'll echo the thoughts of some others here when I say that maybe things that look like "life" shouldn't be found on other planets in the Kerbol system, not on Even and not on Laythe. The atmosphere has no oxygen on Eve, and there's far too much radiation on Laythe thanks to it orbiting Jool with Jool's theoretically immense Van Allen radiation belts that Laythe should be right in the middle of (tho I suppose some form of radiotrophic microbe that somehow puts out oxygen would make some sort of sense there)

Small diameter "lifter grade" parts are something I'd love to see. But then that might also require smaller still payloads. I think a 0.625m rocket should be able to make it to orbit. But I don't know what I'd put on top of it other than a nosecone. I'd ideally like a 0.625m diameter payload fairing part, so I'd be able to put the payload in something to prevent it from having atmospheric drag on the way up, even if it doesn't need thermal protection. So, an 0.625m high-ish thrust sea level engine (maybe 40kn thrust at sea level, ISP of... maybe 250s at sea level and 275 in vacuum, and under half a ton dry mass), an 0.625m vacuum rated engine (Spark is fine for this, but I'd really prefer a little less thrust and a little more ISP in vacuum, say 10kn and 335s ISP in vacuum, with maybe 0.075t dry mass since it's "less engine" than the Spark), longer 0.625m fuel tanks that share the Oscar-B's strangely high fuel capacity for its small volume, and of course the payload fairing like I mentioned. Might need a smaller diameter decoupler to go with that payload fairing as well, payload fairings don't like to work with a decoupler that's the same diameter. But there's another category of "small rocket" parts that might be nice to have. Or maybe "not so small" rocket parts too. SRBs that are optimized for use in vacuum. IRL there have been many hundreds of satellites launched to geostationary transfer orbit that used a solid rocket motor to raise their periapsis most of the way to a circular geostationary orbit, with the satellite's own propulsion systems making up the rest of the velocity needed because these things need some real fine tuning to stay where they're supposed to be stationed and an SRB is ill-suited to that. So, something like a Star-37 or Star-48v would be nice. Yes, I mentioned the Star-48v instead of another star-48 variant for a reason. It has a nozzle that is capable of thrust vectoring. Additionally, perhaps some specific special variants of larger vacuum-rated SRBs could be complex enough to incorporate blow-out panels intended to be used as a thrust termination system? You still can't stop the SRB from firing, but you can stop it from providing meaningful thrust by opening the other end of the tube! Maybe also adjustable multi-pulse SRBs, for similar requirements where you want to precalculate where the burns start and end, but also useful for times where you don't want to use 2 or more SRBs with part loads of fuel in each one when you could save weight by using one larger SRB and dividing up the fuel by putting one or more high temperature burst disc(s) and additional ignition system(s) in the middle of it to split it into multiple smaller "segments" of SRB thrust. Both of those things exist IRL, tho in general they're only used on ICBMs. Plenty of places where you could use them in a space exploration mission tho. You could use a thrust termination capable SRB to get a moderately precise transfer burn done to encounter the Mun, and then a multi-segment SRB to do the Mun capture burn as well as the de-orbit burn and braking burn, with liquid fuel only taking over on final descent. We shouldn't be forcing players to learn that they need to spin-stabilize their small solid rocket motor stages or provide additional systems in the form of RCS for them, that seems like something that just adds more parts and reduces fun even tho it's realistic, and who's going to code in a "yo-weight de-spin system" into Kerbal when that's a thing that's hardly ever going to be used outside of some extremely specific situations anyways, realistic or not?

IMO light speed communications lag just doesn't belong in KSP 2. The speed of light in KSP 2 could be said to be "observed to be as close to infinity as our instruments let us measure". This gets rid of the entire problem quite handily, with exactly ONE departure from the known laws of physics. Besides, it's just not a good gameplay mechanic (I'll explain below), and it would require a lot of complicated calculations to implement, because believe it or not you're opening a HUGE can of worms when you want to introduce speed of light delay (and I'll explain why it's such a huge can of worms further below). Why is it a bad gameplay mechanic? It's all stick, no carrot. There is only ever a punitive effect given to the player. Light speed communications lag as a game mechanic is a bad idea, because there is no situation where NOT knowing about some important advancement in technology or science is ever beneficial to any race of sentient beings, Kerbal, Human, or Other. So if knowledge is power, you want all the "power" all the time, as soon as possible, right? At least that's how IRL is going, humans have the ability to look up more knowledge more quickly now than at any other time in history, ever since the advent of smartphones with an internet connection and access to a search engine. It's the same reason why I think Life Support is a bad game mechanic, at least in the way pretty much all the KSP 1 mods for it implement it. What do you get if you design a ship with a good life support system? The crew gets to experience that greatest luxury known as "Not Dying". Aren't you happy the game didn't kill you? No? Why? Is it perhaps because "the game didn't kill me because I did something right" sounds like the start of an abusive relationship between you and the game? That's what it sounds like to me, or at least it's a very few steps removed from it. "Do right and don't get punished" without a "do right and get rewarded" isn't how you design a fun game. Maybe some people find that kind of game fun. I guess that's why Elden Ring is so popular these days. But I don't find Dark Souls type games to be fun at all, there might be "some" "carrot" type rewards you get, but it's not much, and it's buried under a MOUNTAIN of "stick" type punishments for not doing something EXACTLY right. I don't appreciate the games I paid money for treating me like I'm a misbehaving dog. And just like a misbehaving dog, I probably won't understand why the game's punishing me the first few times it happens, leading to a period of trial-and-error before I decide that the whole thing's just not worth it and I avoid the situation entirely by not playing the game anymore. Put another way, you don't train any living thing well if all you ever do is use the stick. Sometimes, you have to use the carrot. Besides, there's no communication delay in KSP 1. Why put it in KSP 2? Sure the distances are greater, but there's other problems with this. And here's where I explain the part where implementing lightspeed communications delay opens up a whole can of worms that I promise you you don't want to open If you implement ONE feature of "communications delay, or ships not being able to go faster than light", you have to implement BOTH of them, or your game will be inconsistent with respect to the laws of physics. If you fail to simulate EITHER ONE, you get SOME form of the possibility of FTL communications. If you simulate Relativity but not Lightspeed Communications Delay, you get "FTL radios". Plenty of games do this, but none of them have realistic orbital mechanics based spaceflight. But if you simulate Lightspeed Communications Delay but not Relativity, you get "FTL mail ships". Plenty of games do this too, but again, none of them have realistic orbital mechanics based spaceflight. Either way the message is allowed to travel at speeds greater than the speed of causality, with the resulting issues of time paradoxes arising naturally. What's an "FTL mail ship" you ask? Well, let's say you don't have relativity saying you can't accelerate a physical thing faster than the speed of light. But you do have light speed communications delay making messages take literal years to cross the gap between stars. That's fine. You can just design your fastest possible ship, and send messages on that ship, rather than on electromagnetic waves. A physical carrier for a message of data. A mail ship, that goes really fast. A mail ship that goes faster than light. Or you could skip right to the end and call it a FTL mail ship. Or an FTL Courier even. This brings up a problem, naturally. If you use such ships to carry parcels like we use airplanes to carry Amazon.com orders, causality gets weird. Not only does your package arrive instantly. Oh no that wouldn't cause a problem. What happens is that your package arrives before you even ordered it! Now I don't know about you, but that sounds like a universe-ending problem. Because the link between cause and effect would have been effectively broken. Besides, it is my personal opinion that methods to break causality, either with a physical thing or a simple electromagnetic wave somehow traveling faster than light, always result in the universe de-stabilizing and it only becomes stable again when the universe has eliminated all evidence of that method of breaking causality. Likely by containing them inside the event horizon of black holes. In other words the only stable universe is one where there is no possibility of backwards time travel or violating causality. That's why I think setting the speed of light to be "infinity as far as we can tell" is so smart. If the speed of light is infinite, then you can't go faster than light, no matter how fast you go. Of course the concept of measuring distances in light years also evaporates with that, so we'd have to switch back to physical standards for length, but that's a small price to pay IMO for doing away with the whole problem of not breaking causality, while also not unduly penalizing the player for "the universe being the way that it is".

Life support on COLONIES makes a lot of sense to me, when you think about how it interacts with the other gameplay mechanics. Sure, it might not be a major drain on your resources, but it could be a key element in allowing the player to derive maximum benefit from these "Population Boom events" that the devs mentioned several times as being a large part of overall gameplay. I can think of two situations where life support on colonies comes into the picture. In one case, it's a negative thing, however in a way it's because you the player messed up or forgot something. In the other case, In either case, life support would play into the challenges faced. First off, the "negative thing" type of Life Support interaction with Population Boom events: If you have all your colonies sized "just right" for their population, and you have a population boom event happen, then you could suddenly have a bunch of Kerbals on your colonies that don't have a place to call home. To fix that, you might have to delay sending that next exploration mission or mining station out from the colony until you can solve the housing problem by expanding the habitation section of the colony, as well as maybe adding more life support equipment as well. Now for when the interaction can be a positive thing: If you planned for the population boom event BEFORE it happened, you could have the colony ready to accept a larger population before you make the boom event happen, and by doing this you might even be able to get a "bigger boom event bonus" out of the situation. For example, the life support systems might say they're "rated to support X Kerbals" but for short periods the life support systems can actually support let's say "X+5" kerbals, and with the habitat spaces there's only so much hot-bunking you can do. In both cases, you'll eventually hit a "hard capped maximum" population beyond which population will never increase no matter what, unless you expand the habitation spaces and add more life support equipment. In the negative case, that could be a reason why a colony doesn't see its population increase as much as expected during a boom event. However a smart player could think "hey, I'm about to try to do something new or set a new record, I should probably have a plan in the works for if that sets off a Boom event", and so they preemptively increase the size of their colonies hab section and life support equipment to handle the incoming EXPECTED Boom event. In this case of being prepared beforehand, the player could be positively rewarded for thinking ahead, by getting bigger population increases, as well as bigger bonuses to things other than population (doesn't matter if they're temporary or permanent, or if they're colony-wide or civilization-wide bonuses). As for life support on SHIPS, that I'm not sure of. To be honest, I'm of the opinion that it should only be a limiting factor on the smallest craft that aren't expected to be on their own for longer than say a month. On ships larger than that, a part should be available that enables fully (or almost fully) closing the resource loop of the life support system with the only true requirement being the ability to sustain an electrical draw for an extended period, and that is without regard to whatever those resources used by life support might end up being.

That's nice and all, but it still doesn't stop Steam from "aggressively" updating the game when you just wanted to enjoy your save a few more months even tho a new version just came out and broke everyone's mods. Of course, it would also be nice if a save game from an older version could prompt the game to say... close itself, tell steam to revert to the same version as the save game, re-open, check to see if all the mods are compatible with the (now older) version of KSP, and only then continue to load the save (while telling the user what it wants to try to do as well as allowing the user to override whatever choices the game has made "for" the user.

Well, wheels are "good enough" for movement tech, provided they ACTUALLY WORK (which takes far too much fiddling with the KSP 1 wheels, and even then you still flip over and crash and explode after 5 minutes of driving in any case, so I basically only ever use wheels to move around surface base parts when docking them together). But yes, having some tank tread type parts would be nice, as well as some sort of ground movement option that has HIGH SUSPENSION TRAVEL. I feel the need to put that in all-caps because while some of the wheels in KSP 1 do have high suspension travel compared to the size of the wheel when compared to typical automobiles seen here on the roads on Earth, it's still not enough. I'm an auto mechanic, and it's not just because there's good money to be made in this line of work. No, it's because I like cars, and I like working on cars. That means I probably have some knowledge about pretty much anything with wheels. And it just so happens that I know of a type of suspension that is suitable. The idea is to optimize for high suspension travel. Go look at a "Stadium truck" suspension, or the suspension on a "baja desert race" type truck. That's what I want out of a wheel. Not the giant "tank turning only" type wheel that is the largest one in the game right now. No, I want a wheel at least as big as that (physical size of the wheel itself minus everything else), with a tunable suspension, actual "pivoting wheel" based steering like the rest of the wheels in KSP 1, and a suspension travel of something like 1.5-2 meters from fully extended to fully depressed. Also needing to be addressed is the "binary" way that KSP 1 wheels lose their grip on the terrain, either they grip so well that you you flip, or they can't grip at all and you get the feeling that instead of being on another planet you might as well have stumbled into a banana peeling factory where the floor is both Teflon coated and you can't put your foot down anywhere without stepping on a banana peel, so you can't climb any slopes at all, and there seems to be not much of a range in between those two behaviors to me, so it seems you're stuck with one or the other, and no "happy middle ground". If KSP 2 wheels had a much more GRADUAL grip failure than that, then I think that we'd be able to build rovers that can navigate over the surface of pretty much any planet, at high speed, without worrying about the rover flipping over every 5 minutes or more often. And that's key if we want to use rovers to transfer resources between surface outposts on a given planet, which is what I would love to be able to do but can't even think about doing it in KSP 1 because the systems in place just aren't up to the task.

Well if Minmus IS indeed made of ceramics, it would seem natural that materials found on minmus would be REFRACTORY ceramics, aka they're useful at very high temperatures as an insulating or shielding material (SiC is one of those). So, extracting minerals from Minmus might be the key in the Kerbin SOI that lets you produce aerospace parts rated for both atmospheric reentry AND not based on using ablative heat shields, aka one of the key pillars for building a truly rapidly reusable SSTO. As in a vessel capable of Airliner levels of "fast turnaround". Land, unload anything you brought back, check over the craft quickly, go to the payload loading building, get refueled, and then launch again (maybe swap out the crew?). Can't do that with an ablative heat shield, and lightweight, high temperature ceramics are one key to realizing a lightweight and indefinitely reusable heatshield for something like a spaceplane or rocket-powered VTOL SSTO.

Well, tripropellant rockets "can" have better ISP than bipropellant rockets. Or you could do what the Russians did when they were trying to make a spaceplane. Make a rocket engine that is normally Hydrolox, but at launch you can inject extra LOX and Kerosene (RP-1 or RG-1 or even Syntin which isn't quite kerosene but it acts like it except for better ISP I think) to get more thrust out of the engines for when you really need to push up and out of the atmosphere with all that fuel that you haven't burnt yet. Enter the RD-701 Now, like you said, you can in theory use a tripropellant rocket engine to get improved performance. However, most of the studies that I have read were about using Hydrogen, Lox, and Lithium in combination. I don't know about you, but last I checked, Lithium is... problematic to handle, because you have to keep it hot enough to stay melted. That means the fuel tanks are gonna be heavy, and as every study I read found out (by doing the math), that is more than enough extra weight to chew right thru all that extra margin you got by "improving" the performance of the rocket engine. Gotta watch out for those kinds of things when you think you're on to something "better". It usually has a critical downside that might be getting overlooked. That's why the RD-701 is such an interesting engine. It's not trying to improve performance over a Hydrolox engine, it's trying to be what's basically a dual-mode engine. However, there are other means to improve the specific impulse of a hydrolox rocket without sacrificing so much performance by extra weight in the fuel tanks. It doesn't involve a third propellant tank tho, so technically it's still a bipropellant chemical rocket. The idea is that you add something more reactive than oxygen to the oxidizer. Most of the time this ended up being Fluorine, because that's the most reactive halogen (Oxygen is technically a halogen, but biology likes that one so most people think of it as it's own thing unrelated to the other halogen-type elements like iodine, chlorine, fluorine, bromine, oh and Fermium, but that one's so radioactive that it decays before it can react chemically most of the time, so that's another one considered to be its own thing). The oxidizer created is named "FLOX", for "fluorine-doped LOX". Studies showed that when you could stop the stuff from rapidly corroding literally anything made of metal to the point of nonfunctionality, it provided a specific impulse boost of I think 20-30s or more over the ideal ISP of straight hydrolox. However, like you might have caught on to, that's "when you can stop the stuff from eating the metal parts of your rocket". And that took some careful design and engineering work on protective coatings. Of course, the exhaust from such a rocket engine is also spectacularly toxic, seeing as it has a high proportion of anhydrous Hydrofluoric Acid in it, and if anyone here has experience with that stuff you know that the best reaction to seeing that stuff leak is a good pair of running shoes. Not because it'll eat you alive. No, the stuff is acutely toxic to life as we know it, AND it'll eat you alive in sufficient quantities. You'll get poisoned first tho.