Search the Community

So much talk about colonies and interstellar travel. I don't want any of these if the game is in a state like this. Devs are constantly hyping what should we expect... Multiplayer Colonies Interstellar travel I think they should first assure people that state of the game is going to get better, because if until now orbits are unstable, it is impossible to build more crafts. For now, it's a single mission game (if you overcome the bugs). Somehow it frightens me how it will work all together with al the features they promised. The base game is not working well at all.

And exactly how did you arrive at that conclusion? Go check out what some of the things people who got inspired by this game have went on to do. Kinda like when I was 7 years old, my Mom won a hot air balloon ride. Now you might call it "just a balloon ride" but that day, I knew that I wanted to be in the sky...like as a career. And it has influenced many of my big decisions since. If you've got an entire village getting on someone's case because their balloon didn't break the sound barrier, I can't say anything besides the fact it's just a balloon. Not on vacation they aren't. Developers deserve vacations. It's hard to talk about a game you like or have hope for if any discussion is going to invite pessimism. Implement submillimeter precision for interstellar distances, run several systems of colonies in the background... simple, right? Here's something that's simple: drop any pre-2020 expectations because the old technical manager was out of their depth with these promises KSP 2 is still trying to reach.

Now I do like to host races on Kerbin, but everytime I set up a challenge people use quicksave while racing. Why would you do that ? I came to understand that quicksaving can save you from bugs, that's totally fine by me. But why cheat (yes, I call it cheating) in a challenge ? What is worst is that I can't prevent people from quicksaving, there is no way to check if they did or not. Let me know what you think and let's be civil about it.

You do relaize that when i talk about the UI i talk about the general looks and style and not about little details and bugs/problems it had? If to you it seems as if i wanted to say that KSP1s UI was perfect - i never meant to say that. I dont have to have expericence in design to know if a UI is more or less ergonomic for me to use. Compressing everything in a small area isnt good design. The view is actually blocked a lot since lots of pointless things are constantly visible or way to big or have grey boxes that block additional view for no reason. I never had a problem with the SAS buttons - they were perfeclty fine - the new ones are way too big. Also those are things most people would probably control via hotkeys at some point if possible. Why should time use up so much time and why move it where you just argued is the most important space of the screen? In genearl shouldnt most of those functions be something done via hotkeys anyways? No i dont like it because having lots of information with lots of details in the same area actually leads to me taking longer to find that information. Im also pretty sure that the new Interface actually takes up more % of the screen than the old one.

I just watched @ShadowZone 's interview with Nate from just before release.* SZ's presumption is that the developers knew what condition the game was in - and that 'management' (my word) rushed / set an arbitrary date for them to release to EA. It had to go out on the date come hell or high water. And it did. Nate mentions the one thing that will likely be the biggest performance enhancement: refining the PQS System. (The Planet Making System) Given that that is likely a big overhaul, and my impression from the interview is that it was an ongoing project before the release... I don't expect it to be part of the first patch. It could be; I just don't expect it. He did talk about the process: Find the biggest resource hog, tame it; find the next biggest. Those actually sounded like two parallel processes - Taming PQS is a long term, not easily solved thing that is a work in progress - the other is regular refinement. So I would expect some performance enhancement with the patch... just not likely to be the one that causes FPS drops like those from looking at space as the background vs a planetary body as the background. Another thing from the video that comports with what I've seen over these last two weeks - there's a lot of stuff in this build that is wrong, that they could not have NOT known about. So the likelihood is that the patch work isn't just 'look what these intrepid players discovered' it's also fixing stuff they've known about for a while. Final note: while I've been doing my bug hunting and reporting stuff on the forums - I keep running into this line of thought where people are liquided that they haven't patched it yet. I think that wishing for a rushed patch is counter productive. My biggest gripe is how poorly the community interaction and contact has been. I get that a project this big has a lot of moving parts and there is greater risk from rushing a bad update out too soon than there is from taking their time and putting out a well thought, well coded patch later. I'm fine with that. But they should be talking to us. I've tried to explain this elsewhere - but let me try again. The Communications Strategy seems to be PrivateDivision driven - by an expectation that they were releasing a fun-to-play and largely functional game that was awaiting some key elements of 1.0 to be polished, and those big content releases would be fed to players in the order outlined in the roadmap. In other words, a functioning EA title. They have Ghostii doing fun tik-toks and showcasing quirky builds, people on Twitter doing fun things and linking to positive articles, they're all over Discord where people can just spam thoughts and they get large numbers of bodies daily -- all of which would be acceptable if the game was what we expected (and likely what PD wrote their Communication Strategy around) : functioning, fun and awaiting key elements. That strategy would be fine if the game were as performant as other EA titles - like Satisfactory (for example). The game did not release functioning like an EA title. It released like an Alpha/Beta hybrid with a few EA elements. You talk with Alpha/Beta players differently than you do with EA communities. You acknowledge the bugs. You collect the bugs - communicate priorities and tell the testers what you're working on. You under promise and over deliver. You don't ignore them - or keep up some semblance of your original marketing plan when the game is this buggy. Case in point: Dakota's content That's my beef. They're not communicating with us in any way that reflects the reality of the game. That failure of communication is actually accelerating the reputational harm. Increasing the frustration. They should be managing expectations - not ignoring them. * Video Link

I remain as supportive, positive, and optimistic as I possibly can be. However, the public news of layoffs, the review scores, the absolute denial and "all is well!" "just do another weekly challenge!" attitude is not helping. Not when 50% of the community has an extremely degraded gameplay experience, and the viewpoint is that there is a straight up refusal to address the communities fears and worries. The fears and worries being that KSP 2 will not see a completed road map. We need, and deserve, answers. Not corp speak, answers. We need and deserve communication, not "in the coming days and weeks and months" Now. Talk to us, the community, and answer our questions, honestly. Please. Side Note: This is not an "Oh god even Rayne is scared!" situation. I've been supportive, positive, and over all optimistic and I will remain so, but todays news of layoffs was an incredibly huge blow to my own moral and hopes and dreams of KSP2 as a player and a lover of this franchise. It was a huge blow to the morale, faith, and overall atmosphere of the community. That, is why I am asking for answers. So in short, Talk to us, please. Respectfully, Rayne.

What specific questions did you have in mind? I would be curious to know how Intercept was affected by the layoffs. We know about the lead engineer, but were there others? The thing is that it’s really not OK for Intercept to announce this about individuals or individual roles that would let people figure out exactly who was let go (except executives). That’s personal information. You don’t do that to people. But I agree that a bit more communication could help, like, how many roles were cut? When did Intercept know about them? Other than that, what could they say to allay worries? I can’t think of much TBH. They’ve already said development continues apace and according to plan. You can choose to take that at face value, or not, but what more could they say to convince you? The problem is that fans aren’t reasonable people you can talk to reasonably. You can share your internal roadmap with reasonable people because they understand that it’s subject to change; the milestones can change and things can even be dropped from it altogether. You can’t do that with fans because imagine the reaction if, say, they have wind, rain, and snow on it, and later on it gets cut. It would be just a continuous outrage machine. I really wish fan culture would change so there could be more direct and “adult” communication between studios and fans but I just don’t see that happening. You’re by far one of the more reasonable fans @RayneCloud but even you are showing a quite a bit of fan entitlement in some of your posts — and it’s precisely that which makes studios hide behind baby-talk and corpo-speak. You don’t want to say anything to provoke another hissy-fit so you end up provoking one but not saying anything. In sum a big ❤️ to community managers everywhere who have to deal with us. We suck, yet you manage to remain almost invariably positive with us.

Engines: How to Avoid Shipping a Rocket Scientist By Chris Adderley We’ve mentioned approachability as a core pillar of our KSP2 design, and I’m here today to talk about one of the less-obvious ways we are focusing on helping players reach the stars. An area we’ve noticed players struggling with in testing is making sense of the dizzying array of engines you’re presented with in the VAB. KSP1 had 35 engines for you to choose from (more if the Making History DLC is installed), spread across Liquid Fuel/Oxidizer, Liquid Fuel, Monopropellant, Xenon and Solid fuel types. This leads to a good deal of player confusion when starting out – what engine should I use? What engine is best for what I want to do? Why isn’t this rocket lifting off the pad even though I put 20 Terriers on it? There’s a lot of trial-and-error gameplay before you learn the hard-won lessons about specific impulse, thrust to weight ratio, and fuel density that can rocket you to success in KSP. Hah. It unfortunately gets a bit worse. When you're looking for an engine, all of your important details are buried deep. You're searching for specific impulse, thrust, mass, heat production, and how the engine performs in multiple situations (sea level, orbit, other planets). It's a lot of work when you're learning! When we look at our plans for KSP2, we’re only making this problem worse. We’re adding more engines, more fuel types and more engine sizes. Ouch. Clearly, we need to find good ways to teach new and returning players how to select an engine and teach players at the very least which engines are better at which missions they want to accomplish. I’m going to go into some detail on how we’re going to work towards addressing this, focusing in on the most common type of engines in KSP – the venerable liquid fuel engine category, which boasts such illustrious names as the Mainsail, Rhino and… Ant. Liquid Fuel -> Methane Before we get into this, a bit of terminology. Let’s start with talking about… methane and methane accessories. KSP1 gave us an abstracted resource to run our most common workhorse engines: the well-regarded Liquid Fuel . For KSP2, we’ve decided to take this resource and… name it. It’s methane. For their space program, Kerbals have passed over the brutish kerosene, toxic hypergolics and seductive lure of liquid hydrogen to settle on this nice middle ground fuel. It’s a good choice – a number of commercial companies are currently moving engines using methane and oxygen propellants to operational readiness. When we talk about engines you might recall from KSP1 that sported the Liquid Fuel/Oxidizer moniker, we’re always talking about methalox engines. Yes, this nomenclature change applies to jet engines as well for simplicity, so jet engines are now methane engines. Engine Archetypes So, looking in detail at the methalox engines we have inherited from KSP1, we can see that we’ve got an interesting challenge on our hands. More than half of those 35 engines are methalox, and they’re practically the first engines a player gets introduced to. If we’ve done our job right, they’ll continue to be useful engines in some niche even after you have access to objectively more power engines, so they’ll stick around for a while. So, how to sort and help players determine how best to use them? I’ll present the concept of Engine Archetypes. Rocketry fans will be familiar with three high-level types of liquid fuel engines. Firstly we have the high-thrust, high power engine which we can call the booster engine. These engines are great for getting a ship out of the atmosphere and pushing really heavy payloads, but don’t [SG16] have the efficiency to make them great deep space engines. Examples of this could be the Saturn V’s F-1 engines, or the Falcon 9’s Merlin engines. Secondly, we have the sustainer type engine. This is typically a more efficient engine that burns for a longer duration, but doesn’t really have the oomph needed to throw heavy payloads into orbit without a little help. This type of engine is often paired with extra boosters of some type to get a kick up into orbit. Good examples of this include the Space Shuttle’s RS-25 engines and the Ariane series of rockets’ Vulcain engines. Thirdly we have pure vacuum, orbit-only engines, best for operating in the cold depths of space and really, really efficient, but it will be lucky to push an overstuffed Kerbal though even thin atmospheres. A shining example here is the Aerojet RL-10 engine, which has existed for so long (early versions flew in the early 1960s, and the current version is used on the SLS rocket’s Interim Cryogenic Propulsion Stage) that it is basically the kitchen appliance of rocketry. We can map these engine archetypes to KSP engines fairly well – see the following table. Archetype KSP Examples Booster Reliant, Mainsail, Mammoth Sustainer Swivel, Skipper, Rhino Vacuum Ant, Terrier, Poodle This provides a good starting point for laying out KSP2’s methalox engine lineup. Vacuum Engines – an aside We’re always looking for opportunities to improve teaching about real rocketry concepts. One of the places KSP1 hasn’t quite lined up with the literature is the nature of the vacuum engines it uses. In reality, the shape and size of the nozzle attached to a rocket engine makes a big difference in terms of its performance at different atmospheric pressures. A good way of looking at this is to compare something called expansion ratio – which is a measure of the difference between the area of the engine’ s throat and its area of the nozzle exit. In vacuum, the ideal expansion ratio is extremely large – a good vacuum engine has a very narrow throat compared to its exit. To make a given engine work better in vacuum, we use a really big nozzle (though there’s obviously a lot more to it that just making your booster engine’s nozzle bigger). Simplified rocket engines with small and high nozzle expansion ratios Of course, reality sets in here because you can’t just add moar expansion ratio (a multi-kilometer wide nozzle might be a bit heavy) .Rocket scientists have tested novel concepts like the inflatable nozzle (look this one up), the hinged nozzle, and other creative ways of compressing nozzles so they become really big in orbit but can be launched with a smaller footprint. A working example of that is the RL-10B-2 engine that uses an extending lower nozzle cone that deploys once the rocket’s upper stage separates. You’ll see something like that in KSP2 with our NERV-US engine. Unfortunately, KSP1’s vacuum engines are actually smaller than their atmospheric counterparts, which causes no end of consternation among the more technically minded of KSP players. This is a bit of dichotomy, because we all love using the Terrier and Poodle as lander engines due to their small footprint and suitability for landing legs. For KSP2, we will we be looking at moving towards a model that keeps these heritage KSP1 engines around as a subclass of engines that we’ll define as the Orbital class. These will maintain some level of excellence in space, get a bump to their atmospheric stats and leave the door wide open to the long, efficient Deep Space class of engine that lines up more with idealized vacuum engines – a new set we’ll be introducing through Early Access. KSP2 Methalox Engine Archetypes So, given all the above we have defined four engine archetypes: Booster, Sustainer, Orbital, and Deep Space. With these archetypes in mind, we can design for them and use them to teach players. Players who know how to use Thrust and ISP to find the engines they want still have that information. More novice players can build to that point by first learning archetypes. How do we teach archetypes? Well, here’s what we’re working on: Terminology: We have aligned ingame terminology, like subtitles and descriptions, to specifically work on teaching player that any given engine belongs to specific archetypes. At Early Access you’ll for example see the Mainsail comes with a tagline of ‘Methalox Booster Engine’ that helps players situate it in the hierarchy of engines. Archetype subtitle for the Terrier Visuals: We have created specific design languages for each engine type, so picking up an engine and looking at it will be a good way to think about how it performs. Building these languages into our engine models is going to be an ongoing process through Early Access. Balance and Tuning: We have mapped broad bands of engine characteristics to types, and then aligned many engines to better tell their stories. There are always strange engines, but they get to be strange because standard engines exist (like the Dart, that weird little aerospike guy). Visual Language Having good visual language for concepts is one of my passions. We want KSP’s rocket engines to be similar to, but not be real life engines. Reality is full of cool engines, and some of our engines hew very close to existing or conceptual designs. It's tempting to do that all the time, but the closer we lean to reality, the more the engines must skew to reality in all regards. I call this the "Why can't I build a space shuttle with three Vectors" problem. In addition, we’re unlikely to have anything close to the great variety of fuels and tanks that reality has, so being very high fidelity with designs for engines creates disconnects for a detail-oriented realism players (this terrain is great for modders). Instead, when we’re looking at our archetype language for KSP, we will try to be a bit more general and inspired by real engines, rather than creating exact copies. I’ve put together some sketches of these four archetypes to guide our artistic design going forward. The goal is for each of them to have a distinct visual look that is preserved through all size classes, and is versatile enough that, for example, a Mainsail doesn’t just look like a smaller Mammoth. We can pick and choose from a number of reality-alike design elements to create cool, Kerbal-native engines. Booster engine features and possible design variations Sustainer engine features and possible design variations Orbital engine features and possible design variations Deep Space engine features and possible design variations The first place you’ll see this visual language in Early Access is the 3.75m engine lineup featuring the Labradoodle, Mammoth-II, and Rhino. Applied design! From left to right, the Labradoodle, Mammoth-II and Rhino engines sporting, respectively, Orbital, Booster and Sustainer visual queues, courtesy of artists Jonathan Cooper and Pablo Ollervides. Balance and Tuning As we get to the end of this article, I wanted to touch on balance and tuning. Our guiding principles in tuning engines can be summed up with 3 points: Don't deviate from KSP1 for the sake of it. A methalox rocket in KSP2 should perform similarly to a similar looking Liquid Fuel/Oxidizer rocket from KSP1 Engines of an archetype have similar characteristics. Engines within a fuel type exist in a similar band of power, so newer or larger engines should not make older engines obsolete. These rules still give us a lot of room for play while letting us increase approachability. Some engines, like the Vector, needed a hard look under these guidelines. We’re basically trying to follow this chart, which I find a useful way of looking at the overall capabilities of engines. If an engine is a Methalox Sustainer, it should fall in the blue region, as an example – and we are really trying to keep things out of the Useless and Way Too Useful regions . The Way Too Useful region is a story for later in Early Access with more exotic engines , which have their own, unique challenges for building and flying. Taken together, this means that outside of some specific areas, you won’t see massive statistical changes to most engines in KSP2 from KSP1, despite the naming change from Liquid Fuel and Oxidizer to Methalox. Places to watch out for are: KSP2’s 3.75m engines have had some overhauls to account for the addition of an Orbital engine in this size class (say hello to the Labradoodle, as named by Scott Manley!) KSP2’s Orbital engines have better atmospheric performance than their KSP1 counterparts. The relationship between the Mammoth (now Mammoth-II) and the Vector has been adjusted for KSP2, as they no longer need to match visually. Putting it all Together I can sum everything up using a table. Tables are almost my favorite things, narrowly being edged out by graphs. Other Fuels “But Chris!”, you say, “I thought KSP2 was about MORE than just Methalox?”. That’s absolutely true, and we’ll be looking to follow the same general rules when creating archetypes through other fuel types as we reveal things through Early Access.

If you are using the patreon volumetric clouds and not the standard ones, they are yet to be optimized and frame drops are to be expected, we aren't really allowed to talk about those here though because they aren't free yet. If not, then I really have no idea, sorry.

Speaking of skepticism, I've been doing a bit of a deeper examination than I usually do. The following is entirely speculative, wildly so even. You know how people talk about whether they ever mentioned 1000+ parts ships and such... Of course the reality is they've never mentioned any number, only hints here and there. We don't know the part budget they have in mind and they refuse to put a number on it, so speculation is sure to come up. Now, if you go around the bug report subforum, you'll see this new one (which I recommend you upvote as it's pretty critical IMO): I... couldn't really think of that as a bug, maybe inefficient or hard to scale, but not a bug: we want colonies, orbital shipyards, miners, processors, thrusting vessels and such to work whilst we're away, we also want the heat system and to work whilst vessels are unloaded... At the same time we don't have any effective way to differentiate which vessels shouldn't be part of this system: Heat buildup and such could take a really long time, so just assuming equilibrium doesn't work, thus all vessels should remain simulated. Almost any vessel could be used to thrust whilst in warp, so all of those should be part of the simulation as well. Lastly we definitely want colonies and shipyards with their logistic lines working (we know there'll be a proof of concept system so logistic journeys don't load yet another vessel in the simulation). Of course there's a lot of simplification to be made: Colonies can extract to an abstract pool of resources to not account for individual tanks (unlike ships), craft in equilibrium and unloaded can probably ignore the whole heating system, and probably a lot more that I'm missing, so the system can be reduced a bit. But still, the system is not really scalable as more craft are added... and I can't imagine how multiplayer handles it (if it even attempts to at all). Then I remembered the stuff that has been shown the whole way about colonies and interstellar, and the stuff said on the interviews about those topics. Everything hints to monolithic "One big part for a lot of stuff" pieces being the norm. Plus now procedural parts help cut down some of the main part-count wasters like wings and radiators, like this single ring part transforms like 40 into one: So, they have this seemingly inefficient system that doesn't scale well with partcounts, they're really trying to stop us from lego-ing solutions to certain stuff like we would in KSP1, and they also have a clear aversion to tell us the partcounts they're aiming for... Once again my nose picks up a sour smell.

I have thought about teaching at nearly every career change I've had over the last 30 some odd years. Never pulled that particular trigger (until now). For a while I thought my path would take me to college or law school where I could Professorize - it seemed the most obvious choice. Oddly, my friends who are Professors talked me out of it. (It would take too long to explain everything - but do talk to some folks currently in the college / university system before deciding) I was able to get a full teaching certificate for my state without having to go back and get a (nother) masters degree. High school students really do need talented people - and having 'real-world' experience is a bonus. That said - it ain't as easy as it looks. Thankfully my background involved a LOT of teaching (some classroom, much impromptu) - so I know how to run a class. But your first year is a LOT of work - especially if you don't inherit the prior teacher's materials / plans. Even when you do, you discover that they cover the material in a way that doesn't jibe with your philosophy. The cool thing is that you generally have the freedom and flexibility to teach however you want, so long as you are meeting the broad requirements. It's also really cool to see kids making connections that never occurred to them - they're terrible poker players... you always know when you are getting through! All of which is to say 'after 3 weeks, I still like it!' ;D

I know you're working hard, and no doubt heads down and all hands on deck working on new content, features, bug fixes and performance... but please talk to us. Talk to the community. We need open, clear, concise communication regarding plans, please. Even something as simple as "hey Kerbonauts, we're hard at work on the first patch right now that will focus on performance and critical bug fixing." In an EA environment like this, you should probably be talking to the community at least on a weekly basis. It will help with morale with in the community. On a side note, you're doing great, keep it up, lots of us are rooting for you and KSP 2 as a whole! This is going to be another grand adventure, and lots of us know that "Things can only get better." Much love and respect.

It’s even more true when you talk about your own! I’d love to talk more about what we do but I won’t because somebody would latch onto every little thing, blow it out of proportion, and start a hate campaign. Even if I didn’t say anything bad! I don’t want to do that to my colleagues and I don’t want to deal with it myself!

The game is still a barely playable hot, buggy mess. When I can put a rover on Mun next to a lander without encountering decaying orbits, jumping landers, and disintegrating time warps then come talk to me about playability and enjoyment. Currently the game remains an exercise in frustration because of how little actually works.

If you decide that for yourself, that is perfectly fine. If you go around and tell others, what THEY need to find funny and what THEY should think and write according to your perception of the world, you have an issue at hand. Kindly consider that: it is not your role in this world to tell me what I need to find funny and what I need to enjoy. I am happy for you, that you enjoy the game and I wish you lots of fond memories with it. But other people are not you If I would talk to a person interested in the wold of space flight, orbital mechanics and Kerbals, there are very, very good reasons to introduce them to KSP 1 first before urging them to buy KSP2. The price tag is significantly lower, the program is more stable and has more features and the available mods are almost as plenty as the stars itself. Actually, I am playing with my 2.5 year old occasionaly and he is enyoing Kerbals. And explosions. And being able to toggle ladders, landing gears and engines. The thing is, KSP2 is not the only alternative, it is not existing in a vacuum right now. It stands on the shoulders of a green-skinned (little) giant, and from that it is righly judged. I am looking forward to the day I am buying the game and when I can recommend it heartily to others. Alas, this day is not today, my fellow Kerbonaut.

Right now we have a playable Sandbox mode which has been improved immensely with ~700 bugs fixed since launch. The foundation is solid now and performance has also improved. There have been numerous dev diaries, interviews and AMAs. We have a bug tracker and community managers actually talk to us and relay our feedback to the team. The parts look great. We know that the terrain will use a new CBT system, rendering is being upgraded to Unity HDRP, the lighting will be better. We have the buyoncy, heat system and science mode updates to look forward to. The teams are working in parallel on Colonies, Interstellar travel, new star systems - with a lot of unreleased assets to show for. Things are materially improving and the game is continuously getting better. Devs have gone on record that they are going to address the limp rockets issue. There is so much cool stuff in the pipeline. There's every reason to be hopeful and positive.

wow, you know I left the ksp subreddit exactly because of how toxic of a community it had become, I would hate to do the same here. Some people really only see the worst of the worst, and if there is even one tiny bug in a game, you'll never hear the end of it. They bring up arguments like "back in ancient history, the EA was only 15$ and wasn't as buggy". Well, back in ancient history, there were no features in that game either, and every game you bought, EA or not, costed less than half of what you would pay for the modern equivalent. look at NBA2K for example, back in 2013, that game was listed at about 30$, this years version the standard edition is 70$. neither were EA. so KSP1 in EA was half the price of a AAA title full release. Baldurs Gate 3 was 60$ early access. stop using that as an argument, that's just how it is now in almost every studio. that's inflation for ya. You can talk straight to the devs right here on this forum, you are informed of patches on twitter, here and on steam, as well as what is included in the patches and what they are still working on, and if there are any delays. communication is better than 99% of other developers. This is only true for that small toxic part of the community that seems to bleed in everywhere. plenty of people are still optimistic, including myself. but we just leave places where it's starting to become toxic. Like I said, I literally left the ksp subreddit, where I had spent years of my time, because I got so sick of the toxicity. I can understand if YOU have no hope, if YOU have no incentive to continue participating, if YOU have lost your passion, but don't speak for others. There has been many promises made by the team, and there's been many sneak peeks of those promises as well. you act like nothing has been done, but don't know what's happening behind the scenes or what features are included but just disabled until the foundation is strengthened. I know for a fact those features are already there, and I wish I could enable them and play them now, but I'll just have to be patient like everyone else.

Let's not talk about the UI overall layout, that's entirely different conversation. KSP1, while obviously not very ergonomic to use, had all the information on the screen as clear as day. KSP2 went full on early LCD and let's face it, that era did not bring us improvements in readability. That was a compromise we accepted for getting more space, as the screens became flat. But it left us with small letters in weird shapes. The 1st gen console-style ain't helping either. Of course, feel free to discuss other accessibility elements other than the interface.

I have not been able to play KSP2 since launch, First it was stuck on "Pumping Sim Once" and now its "Setting Universe State". I cant seem to find any threads that talk about this. HELP!!!!!

Let's take a minute to talk about the lighting systems we use in our planes, spaceships, and other amazing creations. Right now, they're just not as bright as they need to be. Picture a rover on the dark side of a moon or planet. Can our developers honestly say that the light from two headlights is enough? I believe our current lighting just isn't living up to the overall quality of our game.

Hey everyone! Chris Adderley here, one of the designers on the KSP2 team here at Intercept Games. If you've been around for a bit, you might also know me as Nertea! In aerospace, a recurring joke is that every discipline considers their part of the project the most critical to mission success. Propulsion – obviously without engines you’re getting nowhere! Mission analysis? Where will you go without an actual mission? How are you steering your rocket without guidance, navigation, and control? Electrical and life support – obviously key. Pulling off a successful space mission is really a massively interdisciplinary undertaking. It's that way with KSP2 as well. Different community members have varied perspectives on what features we should add or improve next. As KSP1’s modding community proves, there are thousands of possible features, and dozens of possible approaches to each feature. That’s a lot to take in. One gameplay system that we have heard a lot of enthusiasm for is thermodynamics, and thermodynamics is very dear to my heart. In this dev blog I’m going to go into the design of the thermal systems in KSP2. It is rather long, but it is a complex topic worthy of discussion, and the community deserves a good analysis of what we’re doing, where the core challenges are, and where we are making specific design choices for interesting gameplay. Thermal Challenges In Kerbal Space Program 2 we try to introduce prospective rocketeers to the edges of various space disciplines. A lot of this skews towards mission planning and vehicle design but making sure we touch on many of the core spaceflight challenges is important. Heat management is one of the more underrepresented challenges in spaceflight, which is too bad, because it’s pretty… COOL. We are aiming to have a much larger scope of thermal gameplay elements when compared KSP1 – we need to be able to surface new and exciting challenges that range from the mundane (don’t dunk a Kerbal in an active volcano) to the exotic (fitting a few thousand square meters of radiator to your interstellar vessel) to the really hardcore (building a functional mining colony in the shade of a mountain on a tidally locked planet really close to a star!). This all comes from the vastly increased set of environments we have under construction, parts you’ll use, and missions we want you to fly. What this fundamentally means is that for KSP2, we have had to redesign the entire thermal system from scratch. This system needs to do a few things right that we felt couldn’t be accomplished by the KSP1 thermal model: It must feel authentic and model the core challenges of heat for spaceflight, atmospheric flight and colony building. At the same time, it should have an appropriate level of abstraction so that it is teachable in the same way that other KSP systems are, such as fuel and power flow. It must be predictable, plannable and stable enough so that players can feel confident planning missions and building vehicles or colonies in contexts that involve heat. It needs to work at different scales – we need to handle a single heat producing part at 1x time warp, and we need to handle 50 heat producing parts at 10,000,000x time warp. These are big challenges – and they don’t even include the technical challenges of making the system stable and performant throughout the whole game. Divining Core User Stories In designing a system for KSP2, we often want to get a sense of the physics and reality that relate to a system. These can inform the user stories we want players to grapple with when playing the game. There are three core areas of heat management we want to deal with: Generation and removal of heat using parts on a vessel or colony Reentry and atmospheric heating on planets with atmospheres Environmental heat sources and sinks (oceans, etc.) that can affect vessels and colonies. I’ll start out by examining some of the physics and reality behind these three stories. Avoiding Meltdowns In everyday life, almost every useful process generates some level of waste heat. Your computer generates waste heat when it plays KSP2, a nuclear reactor making electricity generates waste heat, and even your body generates excess heat. A good rule of thumb is that the more exciting the piece of tech you’re running is, the larger the waste heat generated, and there are some really cool pieces of technology we’re looking at for use in KSP2. When things heat up, we need to get rid of the excess energy somehow. Not getting rid of it results in consequences, like nuclear meltdowns. The three common processes that move heat around There are three processes that can do this: convection, conduction and radiation. Convection is a very effective way of dispersing heat, using atmospheric or fluid currents to move heat away from a heat object. Conduction is also efficient and relies on two objects touching – heat will flow from the hot to cold object. Radiation is the least effective way of dispersing heat and relies on the tendency of hot objects to emit photons, which carry away heat energy. Heat in space is a real problem. You might think that it is cold in space – after all, it is very high up, and dark, which we associate with cold. Seems reasonable. Trekkies among the audience may be familiar with a famous line from Star Trek II – “it is very cold in space”, which reveals that though Khan has a great flair for the dramatic, his grasp of thermodynamics might not be all that great. Specifically, without air or another medium, the only way we can get rid of heat is through radiation, using heat radiators. An astronaut servicing a thermal control radiator on the International Space Station, and a large KSP2 interstellar vessel with several radiators in its midsection. For KSP2, we want to pull several specific user stories out of this idea of heat transfer: Parts on a vessel or a colony should be able to generate heat. These could include engines, drills, factories, and power generators. Players should be able to make use of the three processes of heat transfer to cool vessels. That could be using radiation, with radiator parts in space, or by using the local atmosphere’s convective abilities on a planet, or possibly by using conduction to treat an asteroid as a heat sink. These stories are not completely unfamiliar to veteran KSP1 players – drills and ISRU units generated heat that needed to be removed with radiators, and our three heat processes were simulated with great accuracy for focused vessels. However, we need to expand this to handle much higher fluxes, expand the range of parts that can generate heat, and most importantly improve how all of this is communicated to the player. Slightly Singed Landings When spacecraft reenter the atmosphere, they travel at such a high velocity that the compression of the air in front of the spacecraft creates extreme heating and is liable to damage or destroy the spacecraft. Special flight paths can be used to reduce the heating, and special materials are used to withstand extreme temperatures – often through ablation, where the material burns up slowly during reentry events, and in doing so carries away the heat. The ESA spacecraft Jules Verne burning up in reentry This is an integral and important part of spaceflight, so definitely something we want to represent in KSP2. We can collect a few more smaller user stories from this. Travelling in atmospheres at high velocities should cause vessels to heat up. Players should be able to use occlusion to protect parts on vessels from reentry heating. Players should have access to specific parts that are more effective at mitigating heating than others. Reentry stories: you should really add a heat shield. Again – this is a similar set of things to KSP1, but we go up in scale again. With more exoplanets, higher velocities and more varied types of atmospheres, we increase the scale of the challenge we need to consider. Exoplanets? More Like Exothermic Planets! Aside from reentry, we also need to think about environments. Traveling through the KSP2 universe will expose your Kerbals to everything from somewhat pedestrian to exotic environments, with situations like: Close proximity to a star. Infernal, glacial or just right atmospheres. Heated or molten ground. Icy or frozen planets. These are all things that, when sending probes or Kerbals to another planet, we would like the player to consider. We want to build interesting puzzles that require clever use of parts, innovative use of the environment, and clever mission design to solve. This means that all that heat transfer stuff from earlier should be influenced by environments. A cold planet might give you a useful bonus to run your mining drills. A lava planet should give an extra interesting colonial challenge. We can extract another set of user stories from these environmental considerations: Parts exposed to strong solar illumination should heat up. Immersion in atmospheres and oceans should heat up or cool down parts. Proximity or contact with surface features should heat up or cool down parts Environmental stories. Damnit Jim, I'm a designer, not an artist! These user stories are another core expansion of KSP1. In particular, the interaction between the part ‘layer’ and the environment ‘layer’ is going to have a much larger effect. More on this later. Smaller, Simpler Problems But wait – there’s more! Parts should have a variety of thermal parameters to make them easier or harder to use in select thermal situations (heat up at varying rates, explode at different points). Parts exposed to engine exhaust jets should heat up. We can’t neglect the little stuff. When designing this system for interesting gameplay we need to think about how we will represent the range of thermal properties we want for parts. So parts should have some different heat tolerances, some different heat limits. Oh, and we want engine exhaust jets to generate heat. Can’t have you pointing a torch drive at a colony with no consequences! Putting It Together Let’s recap. From the above set of thermal user stories, we want to have a thermal system in KSP2 that will let us: Create parts that generate and remove vast quantities of heat, via the three physical heat removal methods. Simulate atmospheric entry and mitigate it with heat shields. Model a vast set of environments from cold to hot and have those directly feed into the two previous bullets. Provide appropriate variation in thermal part behaviors. We can check these stories against the four design pillars of KSP2 to make sure they fit well. Our thermal stories are strongly focused towards Realistic Space Flight and Exploring New Planets, but I have to give a shoutout to Building Cool and Unique Rockets, because I can’t resist a bad joke. In addition, the thermal system needs to be predictable and plannable. More on that in a bit. Consider a Spherical Cow in a Vacuum Something I touched on earlier is that the KSP2 thermal system needs an appropriate level of simulation and detail. The level of detail we build into any system depends on the user stories. If the system is too detailed, we may build something that is difficult for a player to understand, or too difficult for us to tune, creating undesirable edge cases and making it impossible to fill those user stories. If it is too simple, we might compromise our realistic spaceflight pillar and make things too easy for the advanced player. I like the metaphor of a spherical cow in a vacuum – if we needed to analyze a cow for some reason or other, we could assume the cow was a sphere, and assume it was in a vacuum. This is a fairly simple situation to analyze physically. This may however lead to oversimplification of the problem. I can describe our search for a good thermal system as a search for the right geometric approximation and environmental context for our cow. Should it be cylindrical? Composed of several boxes? It probably shouldn’t model all the contours of a real cow in a grassy field because that would be very complex. This cow is exchanging energy with its local environment! The right thermal model for KSP2 has a good blend of realism, hits all our user stories, and is simple enough for players to understand and engage with. The right level of simplicity also allows us to build good intuitive tools to help players understand, in a nutshell, when their vessel or colony may overheat and how to solve it. Determinism vs. Simulation A common trade in simulation type games is the level of determinism versus simulation. The more simulation in a game, the more the game relies on lower-level rules to drive gameplay. A good example of this in our thermal context is a heat radiator. Determining how a radiator performs could be approached in a very simulation-centric fashion: Define the useable area of the radiator, Determine the temperature of the radiator in response to various factors (each of which might also need to be simulated), Use physical relationships such as the Stefan-Boltzmann law to model the amount of heat removed by the radiator. A radiator with a few of the parameters that might be needed to physically simulate it This simulation approach provides a high precision approximation of radiator heat rejection. However, it does require more design and computational work, as we need to figure out that temperature value, and we now create additional challenges of teaching the players about the radiator’s area, the radiator’s temperature, and how the two combined feed into the physical relationship. The latter is harder if the relationship is complex (here it is somewhat complex – heat radiation is proportional to temperature raised to the power of 4). In addition, we may create simulation-level inconsistencies – is this too detailed compared to other things that are simulated in the game? That’s a lot to unpack. Alternately a simpler deterministic method could be used. We might just: Define the amount of heat removed by the radiator A radiator with a single deterministic flux value, informed by physical relationships This is evidently a lot less complex for a designer to manage and a player to understand. Often, we can mix the two approaches – in this example we could use physical relationships to guide what value we set (for example we make the values for heat removal chosen related to the surface area of the part and derive them from ‘typical’ temperature relationships but never directly show this to the player). This has some advantages – for example decoupling gameplay from visuals, so we have more flexibility to work on these separately. KSP1 erred on the side of the simulation in this trade. In the KSP1 thermal model, all vessel parts calculated their own energy exchanges (via convection, conduction, and radiation) with the environment as well as other parts, calculated internal sources of heat, tracked up to three different temperatures, and required considerable frowning at KSPedia to start to understand in a way that you could engage with the system. The KSP1 simulation-focused thermal model, as shown by the in-game KSPedia KSP2, we’ve made the decision to rely on what I’ll call a reality-informed deterministic model with fewer moving parts. This model is still complex enough to hit all the user stories I’ve defined earlier so as not to compromise our commitment to reality but will use a reduction in complexity to achieve much better player comprehension. What's Changed Given the above, where are we modifying the simulations? Simplifying temperature values: We want to avoid having a player interact with three different part temperatures when planning missions and playing the game. One is ideal. Part high resolution thermodynamics: We don’t have a lot of user stories that benefit from simulating conduction between parts, or intrinsic simulated thermal emission. A lot of the time this reduces to equilibrium in KSP1, particularly at high time warp factors. In addition, if we want this simulation to apply to vessels in the background, we need to simplify things. It’s hard enough computing thermodynamics for 500 parts on a vessel – imagine if we wanted to crunch fancy thermodynamics on 50000 parts on 100 vessels! This has to scale effectively and be performant. Simplifying environmental interactions: Similar to the previous bullet, the level of interaction between the environment and a given part can be simplified. The ex-thermal physicist in me is pretty sad that we won’t be modeling the differences between longwave and shortwave radiative transfer in low Kerbin orbit - but I’ll get over it. Shape of the Solution Given all the above, we have designed a rad system. More puns, yeah. KSP2’s thermal system will use a model based around managing heat fluxes – the amount of energy applied to something over some amount of time. Every process we want to model boils down to applying a heat flux to a part. This flux can be positive, causing a part to increase in temperature, or it can be negative, causing a decrease. Here is a sampling of fluxes we care about from our user stories: Positive flux from things going on in a part, such as drilling, resource production and powerful engine reactions. Negative fluxes from things going on in a part, like heat radiators and other heat sinks. Positive flux from stellar sources in sunlight. Positive or negative fluxes from warm or cold atmospheres, fluid bodies or surfaces. Positive fluxes from high velocities in atmospheres (reentry). Using this model, we can sum up all the fluxes affecting a part and communicate a single value to the player. If the sum of all fluxes is positive, the part heats up. If it is negative, the part cools down. In the absence of any fluxes, a part is stable. If the part’s temperature increases above its maximum, well, you get an explosion. I’ll illustrate with a few cases! Thermal system in a reentry context Let’s look at a reentry case – a capsule with a heatshield travelling quickly into the atmosphere. Here, we have the presence of a Convection flux on both parts, as we have an atmosphere, and a Reentry flux, as we’re moving fast. The capsule is being occluded by the heatshield, and the heatshield is getting a positive flux. It is heating up and the capsule is not. Thermal system in a reentry context Let’s look at another case of a 3-part spacecraft in orbit around Kerbin. In the first image, we have a idle spacecraft doing nothing. No fluxes. Nothing changes. In the second image, the engines is firing, generating a positive flux, so it is heating up. There are otherwise no fluxes. In the absence of anything else happening, the engine part will eventually explode. A more complex ship makes for a more complex example Now, let’s add radiators to the mix. Here I haven’t labelled all the parts, but we have an ion drive spaceship with a nuclear reactor. In the first image, the radiators are not working and the reactor is on. The reactor part is heating up as it outputs 200 kW of heat flux and will eventually fail. In the second part, we’ve thankfully extended the radiators, and they’re each pulling 100 kW of heat flux from the reactor. Everything is balanced and nothing will explode. A zoomed-out example, with a colony! As a last example, let’s make it complicated (I’ve simplified the doodle though). Here’s a colony in an atmosphere. The cooling tower is using 2 MW of heat flux, the reactor is making 2 MW, the factory is making 1 MW, and we’re using the water as a heat sink to dump 2 MW of flux. We have a nice little negative flux and our colony is happy because the engineers considered the environment. It’s a great story because it starts to show you where you might end up with advantages and disadvantages in terms of colony placement. If that water was lava, this would not be a good thermal situation We can see how this system is plannable too. Although there are a lot of details, a player technically only needs to know what the net heat flux is on their whole vessel. No matter how many different parts are making heat, and no matter how the environment is configured, each part just contributes a single number to the situation. Add them all up – if it is positive, you have a problem. If it is zero or negative, you don’t. The second part of this is how we define relevant fluxes. Instead of having a very complex environmental model where we specify every possible flux and simulate them for every possible source, KSP2 assumes that every part has some level of ability to self-regulate in an average thermal environment. Kerbals build tough! Positive fluxes will only start to appear in well defined abnormal situations that correspond to our user stories, and the puzzles we want players to solve – the user stories from before. As your vessel approaches a star. When your vessel reenters the atmosphere at high speeds in a fiery plume. When a part is doing something that creates a large excess of heat. We’re not considering small heat sources like cryocoolers and capsule life support systems. When you point your fusion drive at your orbital colony. We’ll apply negative fluxes at times where you might expect useful temperature drops in response to intuitive situations. When your vessel is floating on an icy ocean or flying in a frigid atmosphere. When a part is doing something that removes heat, like running a heat radiator. Using these two concepts, we can work through all the user stories we defined in the previous sections and reduce the things we need to communicate to a player to effectively two values: the net heat flux on a part and the temperature of a part. The former is something you want to make as close to zero as possible, and the latter is something that tells you how close you are to critical failure. A word on temperatures and maximums – there is a relationship between the temperature of the environment and the temperature of a part. Typically, you simply can’t bring a part into an environment is hasn’t been designed for – if you try to take a part with a low heat tolerance (let’s say it breaks at 500 K) into a 600 K atmosphere, you’re going to be in trouble regardless of the local heat fluxes. In this case, you’ll need to use creative solutions, like cargo bays. Timewarp and Loading A core requirement we have on this system is for it to work well in timewarp and provide consistent behavior at high and low timewarp levels. Similarly, we have to consider how the system behaves on vessels that are unloaded. This work supports colonies and interstellar vessels. For interstellar vessels, or anything else on a long burn, we expect players to want to timewarp at very high levels during long burns using engines that generate a lot of waste heat. In short, we need to make sure that when you do this, there is consistent, stable performance from our thermal system. If your vessel can take the heat at 1x, it should take it at 10,000,000x – this may seem obvious but leverages very specific requirements on the technical solution. For colonies, we also need to handle these timewarp levels but also bring a focus to things working in the background. In KSP1, a number of systems only worked on vessels you had loaded – things didn’t always calculate in the background (especially thermal), because there wasn’t a lot of need for them. To fit our user stories we need to have a strong picture of the concepts we want to present to players. Again – consistency is a requirement. If I want to produce resources at a colony, or run delivery routes, I want this to be seamless regardless of whether I am actively observing the colony or not. Resources should be produced while I’m doing other things. This again leverages requirements on thermal mechanics: since most complex colony functions like resource processing are going to produce heat, we need to account for that heat in production calculations and be able to do the math when we’re not observing the colony. Our flux-based system fits these requirements very well. In the absence of any additional flux, temperatures don’t change, so we can simplify a lot of these calculations or ignore them completely. When flux is involved, we’ve specifically designed a mathematically simple system. I like to think of this in terms of timewarp. If your vessel’s giant interstellar engine produces 100 MW of heat, and you have 1000 MW of radiators, we can make some solid assumptions: As long as your radiators are running, your engine will never explode. If your radiators are not running, your engine will more or less instantly explode at any medium to high timewarp level. Even so, making sure things are stable and comprehensible is a large technical challenge. Comprehensible means we also need player tools to enable system interaction though, so let’s talk a bit about planning. Planning for Success I mentioned before that a key improvement we absolutely need for KSP2’s thermal mechanics is plannability. The system that I’ve outlined here gives us an appropriate level of detail to do that. Just like you can check your vessel’s thrust-to-weight ratio and delta-V, you will want to check your vessel or colony’s thermal performance. We have a number of tools and concepts that we’re investigating as part of this effort, from UI tools to part-based approaches. We’re excited iteratively work through the final solution through Early Access and consider the best of the community’s feedback to make flying vessels into Kerbol as exciting and predictably awful for your Kerbals as possible. Development and Deployment Because we’re in early access with a specific roadmap, it doesn’t make sense for us to try to cram a system of this complexity into a single update, particularly with the huge rash of user stories we want to cater to. We’re going to deliver functionality iteratively where it is most appropriate in the roadmap. Here’s how things are looking right now, though we will refine this roadmap dynamically so heat problems appear at the right times. By the time we get to our first roadmap update, for example, the user stories around reentry heating become very relevant, because the puzzle of returning science experiments to Kerbin is much more interesting if they can burn up when returning. That means that reentry heating takes the first priority of all of our user stories, and you can expect that to arrive before or with this update. Similarly, dealing with radiators and parts that generate heat isn’t something that becomes exciting until we introduce actual heat generating parts, likely as we move towards the second roadmap update. These start to show up when we introduce more advanced propulsion systems and power sources like nuclear reactors. There’s a nuclear reactor in the game right now, but you’ll notice it has integrated radiators – a nice sidestep to the problem. Larger reactors will be separate and need their own radiators! This is where we’ll also need to bring in a first cut at some planning tools. By the time we introduce some of our exoplanets and Kerbals go Interstellar, we want those environmental heat user stories to be fully fleshed out. That’s when we can expect to deliver advanced environment heat and even more planning tools to help your build cooler colonies and vessels. Overall – if we have a lava planet, that lava planet should be a thermally bad place to be. I hope you’ve found this writeup to be informative and indicative of the direction and challenges KSP2 needs to deal with when implementing thermodynamics – I enjoyed writing it. Until next time, Chris Adderly Senior Mechanical Concept Designer

This new log have essentially the same exceptions from the last one I checked. No news, everything appears to be the same. There's no other option but to talk to FAR maintainers - I don't know this thing, I don't have the slightest idea about how to fix it. About the CryoGenic Engines, I checked the dependencies. It needs Cryo Tanks 1.6.3 - but the latest release is the 1.6.5. I'm guessing you need to downgrade it to 1.6.3 to fix your issue? It's a wild guess, it's safer to talk to Nertea about it. You may want to reach CKAN guys too and see if they didn't forgot to set something on the NetKAN file. CKAN is giving me some headaches since some time already, by the way.