GluttonyReaper

Genuinely I'd rather the choices be wilder than they are now - I want to see Kerbals with afros and mohawks, practicality be hecked.

The point is more than having a full-sized solar system draws attention to how weird and small the Kerbol system is - having them be that small is a concession made for gameplay rather than a deliberate lore choice. You don't really notice how tiny the Kerbol planets are because there's nothing to compare them to (unless you know enough about the game to know they're scaled down obviously) and they feel pretty big still. The planets as they are now are clearly supposed to be roughly analogous to real-life planets with some slightly cartoony elements, having those same real-life planets but at full-size would create some... interesting tonal issues for the base game. As for modding though, I'd be very disappointed if it wasn't possible and relatively easy to add the real-life system as a separate system. That's exactly the kind of thing that mods are for, and would probably be something I might try out for a challenge every so often.

It's a bit hard to tell from that picture (I'm not sure exactly when you separated / the design of the probe & rocket), but I think this might a drag issue? A light, non-aerodynamic probe would experience a lot a drag as soon as it's released into the atmosphere, slowing it down quite a lot. While your rocket (even empty) is probably heavier and more aerodynamic, and is able to "punch" through the atmosphere a lot easier. I can't find any examples now, but I remember that Scott Manley used to keep his empty boosters attached a little longer while in atmosphere if he wasn't thrusting, for this exact reason. As for that experiment you've linked - I don't know the specifics because I'm not familiar with Tweakscale, but @Lisias might be able to clarify - it looks like the result there was that the higher cross-sectional area was what was slowing down the larger booster enough to counteract the additional momentum from the higher weight, which isn't always necessarily true for every design. Downwards acceleration from gravity is the same no matter your weight is.

Bah, you can't toss a pizza in cosmology without hitting some new tension or another...

It's just a little bit of extra feedback - another way of the game telling you "yep these two parts are definitely the same diameter, good job".

This actually would be really neat. Like having a highlighted 'ring' around the attach node that shows up when you pick up a part that corresponds to highlighted rings on open nodes of the same diameter would be neat too, just as a bit of extra visual feedback. Even just a small indicator next to parts that have the same node(s) size as the part you've just placed would go a long way - now that I think about it, having a coloured ring around the last placed open node that corresponds to the diameter indicator colour in the parts list would work. If it's subtle enough, it won't confuse new players, but could be an extra visual shorthand to knowing exactly what diameter you've placed, to help speed up construction for more experienced players.

Tangential, but I do find it somewhat funny that we're at the point where we can reasonably simulate galaxy and dark matter web formation... but clouds are still something that totally eludes us.

I was about to say that Venus is arguably a counterexample to this (with a notoriously high temperature and albedo), but I suppose that's not really applicable given that Venus' clouds aren't water-based (and I have no idea what the properties of sulphuric acid are with regards to infrared insulation). And we don't see runaway heating on Venus at present, just a higher equilibrium... although it's still a fair example of what can happen if you can pump enough CO2 into an atmosphere, even if the Earth will never reach those kind of percentages. Anyway, the lack of modelling of cloud effect definitely seems... odd, given that you'd expect models to be relatively mature by now. I'd still wonder whether increasing temperatures will produce enough additional cloud cover to make a substantial difference (i.e. enough to counter greenhouse effects), but that's exactly the kind of question only proper modelling can answer.

I haven't got access to this transcript obviously - is there any mention within it of the insulative effects of clouds, i.e. are they claiming that the energy input blocked by cloud cover is greater than the effect of heat being trapped in the atmosphere by the same clouds?

The good news is that KSP lets you plan manoeuvres before you commit to them - you can always try out different transfers with the manoeuvre tool before going for an actual burn, usually with pretty low time commitment

If KSP1 started receiving regular updates again through open source contributions, that would put it in direct competition with KSP2, no? That just... doesn't seem like a good idea from a business perspective, especially given that KSP1 is both cheaper and current more feature-complete. Not to mention that a good chunk of KSP2's potential buyers are people who already own KSP1. It's a neat idea, but I doubt it'll happen unfortunately. The best case scenario is that we get an extra update or two to fix some of the worst outstanding bugs, and perhaps open up some additional modding flexibility... but other than that, I think it's fine to let KSP1 rest. Not every game needs to be updated in perpetuity.

I personally liked the pre-EVA KSP1 kerbals, which were just green blobs with eyes and a mouth in a spacesuit. No indication of any individuality, and only had the three most important emotions: indifferent, terrified, and maniacal.

This is definitely nitpicking, but as someone who hasn't played KSP2, I didn't know what "First Time User Experience" or "Cadet Orientation" were at all at a glance. FTUE feels like some kind of development term (I'd probably assume it was some 'easier' version of the game with some altered mechanisms) and CO sounds like a gameplay feature (like some kind of training mechanic for new kerbals). If I really had to choose, FTUE is slightly more meaningful... but I'd definitely have to click the tooltip to understand what the toggle actually does. "Enable tutorials" seems like the most obvious solution (if a bit bland), and is pretty common among other games. But really, I don't think it matters that much if there's a clear tooltip anyway.

As much as I appreciated the idea behind KSP1's system, I do wonder if there's a better way to streamline it - would it not be enough to have the name of a craft just be tied to the first command pod placed or something by default? I always found the KSP1 way of doing it to be fairly fiddly and easy to miss.

A mobile version of KSP would presumably have to be functionally a very different game - unlike most games, KSP has traditionally always been CPU-limited, and specifically works best on CPUs with a few high-performance cores, due to the way it simulates physics. I haven't followed the latest phone hardware, but I assume they're more optimised for running lots of threads at once. I'm not saying it's impossible... but it'd probably just be easier to build a whole new game. Which, uh, is exactly what Juno is anyway, so may as well play that instead.

True, that's fair, I'm probably being pretty unclear with my terminology here. I'm not saying that any elements are purely "simulation" or "game" and can be easily categorised as such, I'm saying that most of the features we've seen all blatantly lean heavily towards the "game" side to my eyes. "Simulation" aspects I would define as anything that exists to mimic reality, with a higher degree of simulation being closer to reality. "Game" aspects are... trickier to define, to the say the least (I also don't think it's the best term either - it's not like KSP would cease to be a game if it didn't have enough "game aspects"). I'd say it's anything which exists to engage the player in an arbitrary way that keeps them playing, which I appreciate is a loose definition. Importantly, "simulation" and "game" aren't necessarily always opposites - in fact, to a point, they can complement each other quite nicely, which is exactly what made KSP attractive in the first place, taking orbital mechanics in a direction that was actually fun to utilise. I guess the key here is intent, which obviously I can only speculate at, that separates your proposed interpretation over mine. It appears to me though that the evolution of most core features involved developing them as "game" and "simulation" aspects, then continuing to develop the "game" aspects once the "simulation" aspects became counter to them. I think that the presence of mostly "game"-ish features that don't really connect to "simulation" at all is fairly strong evidence of that (i.e. career mode features), whereas if it were the other way around, I think we would see a lot more almost-pure "simulation" features (e.g. part degradation, life support, etc.). Side note: This is all somewhat muddied by the fact that KSP1 arguably tries and fails to prioritise these "game" features, despite spending almost half it's pre-1.0 development on them - I don't think things like contracts and Kerbal professions ever really worked to be the engaging features they were intended to be fundamentally, which lead to a lot of people (me included) dropping them entirely for sandbox mode. I've probably already covered this above, but obviously the issue here is that you can't separate "game" from "simulation" for most features, so pretty much everything outside of career/exploration mode is directly connected to the core physics. And if KSP2 is better designed than KSP1, then exploration mode features should be connected just as much ideally, but that's another can of worms.

I really don't know where people are getting this idea that KSP2 (or 1, for that matter) was ever supposed to be a simulator above all else. The only part of KSP that has ever been remotely simulator-esque is the orbital mechanics, and even that is set up to highly value Fun, hence why we have a massively shrunken solar system with made-up brightly coloured planets. Everything else is set up to be incredibly abstract and often just ignores reality entirely. Aerodynamics? If it's pointy at the top and draggy at the back, it'll probably fly. Rocketry? Here's some super heavy parts that you can slap together, no need to worry about ullage engines or limited ignitions. Mining? Drill up any old rocks, do some processing, and then shove them through your engines, no problem. KSP1 and 2 have both historically traded realism for fun whenever given the opportunity, it's only ever really been mods that have tried to pull the game over that 'simulator' line. Reality has been a great source of inspiration obviously, but the KSP2 team seem to committed to actually making a fun gaming experience rather than a hardcore simulator.

As I understand it, this is only sort of true - everything 'orbits' the centre of the galaxy, but unlike a solar system, you don't have the same overwhelmingly large mass in the middle that makes the point source approximation (and Keplarian orbits) reasonable. Instead, there's a fair amount of mass everywhere, exerting gravitational pull all over the place. You still end up with a vaguely circular orbit, but you also get weird effects like stars bobbing in and out of the galactic plane, and some intense precession. I don't think this is necessarily true. To get anywhere in a reasonable timeframe on interstellar scales, you need to be moving at some fraction of the speed of light - to get to a system 1 light year away in 100 years, you need to be moving at 0.01c... which is about 3,000,000 m/s, or 10,000,000 kph. It's still moving, but you'd be going a lot faster than your actual destination, compared to what we're used to an interplanetary scales. You can't really do Hohmann transfers when going interstellar in the same way. To be clear, I don't disagree that it'll be harder than going interplanetary (can you even do meaningful correction burns at those speeds?), but I think it's also going to be fundamentally very different.

Slightly off-topic perhaps, but I am curious how interstellar travel will actually work UI-wise - I'm not entirely convinced it makes sense to use the standard patched conics system when you're out in interstellar space, given that you're not really 'orbiting' anything in the traditional sense. Plus to get anywhere in a reasonable time frame, you're going to be moving at relativistic speeds towards effectively stationary targets... definitely a bit outside the scope that KSP usually has to deal with.

Good old KSP1 v1.0, where you had to attach your NERV engines to the biggest fuel tank possible as a heatsink, or risk them exploding on long burns

Not saying I disagree, but also... this doesn't feel that surprising? Given there hasn't been a major update in 10 months, and that many (most?) of the EA buys were likely KSP1 players, a game which still exists and is more feature-complete than KSP2, it doesn't seem like a massive revelation that people aren't playing at the moment. I genuinely don't know what kind of numbers are typical for an Early Access sequel (given there aren't many of those regardless...), but this doesn't seem super crazy. "Quit" is a bit strong. There are very few (even complete) games that people will play for 10 months straight (or even a month straight). I doubt it's as dramatic as everyone else actively quitting the game in a fury, never to return - it'd be more accurate to say "not actively playing". There's plenty of games sitting on my hard drive(s) that I like or am ambivalent to (which I suspect is where most KSP2 purchasers sit), but that I'm not particularly in the mood for playing right now this minute. Not only that, this is something that KSP1 never actually explains. In fact, it does the opposite - the main heat generating parts (drills/converters) have a "required cooling" value displayed in the VAB IIRC... and all you have to do to maintain the correct temperature is add enough active radiators, which have their own "cooling rates" displayed, to match this. The weirdly complex heating system is entirely a background thing which the game never encourages you to engage with, not that I personally think it would even add that much if you did.

Counterpoint: what if it was more purple?

I was merely joking For real though, it's definitely something you could easily run into in the early game - in particular I'm thinking of scenarios in which the game wouldn't know that you don't want that battery power used, for example if you're doing a fly-by with limited time/energy to collect science, and would rather transmit once you're in a more practical location. Kerbalism sort-of had an option to allow this by stopping transmissions if you retracted your antenna... but that feels a bit artificial and creates problems for probes that might need the signal connection for control purposes (I guess you could also block EC flow from a single battery even in stock KSP1, but again that feels artificial). It's not that I don't think automated transmissions should be in the game, but there should definitely be an option to switch that off at any point. If anything, I'd say having it left on manual by default is better, for the sake of letting new players understand what's actually happening in an interactive way (an issue I had with Kerbalism), with an option to switch on automatic transmission available once you know what you're doing, in the VAB or in-mission.

That's efficient design - no need to pack all that extra power generation if you can just wait until you're back in the daylight

Not saying I disagree, but a big stumbling block here for KSP2 in particular is that eventually there'll be interstellar travel, apparently with no FTL mechanics. This means that at certain point in a career, you might have a spacecraft that's travelling to another star for decades rather than years. Having played with time-mechanic mods in KSP1, I often would almost never actually have a mission arrive at Jool, because I'd end up finishing the tech tree while it was travelling and/or get bored with doing routine inner solar system stuff. I feel like this problem would only get worse when some journeys are a magnitude longer - it'd be pretty frustrating to have to make sure every one of your colonies is resupplied every year or two while trying to timewarp to another star.