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.

I know this is on the no-no list, but since the devs are chatting about reviving it maybe we could offer ideas on how to implement it? If no mods feel free to lock. I think at present the devs are right to consider how life support becomes something fun, easy enough to understand, and scalable for new to veteran players, and not just an extra thing to accidentally go wrong. This especially becomes a concern when people have many multiple flights in progress, and warping one may exhaust resources on another. Worst case would be sending a probe out to Dres or Jool, and accidentally killing all your kerbals in SOI. To some degree this could be helped by an alarm clock, but even this would have to be somewhat sophisticated to be useful in order to let you know life support was running down in time for you to do anything about it. Even under decent conditions, you could end up in a very tedious place if for instance you had a crewed station around Kerbin and a flight en-route out Jool, and had to constantly break warp on your Jool ship to go back and resupply at your station. Sorting out these issues and balancing everything is no trivial task. My thinking is if it is going to work, it has to be both simple enough not to be tedious, and complex enough to still be challenging and fun. I also think it might be a good idea for the consequences of failure not to be quite so dire as to cause major rage if things go wrong. Updated 1/7/2016: So as this has become the default life support thread I'd like to open this beyond my personal musings on the topic to whomever might have fresh thoughts on how it could be included. We've discussed the topic on in this thread and others at length, the various pros and cons of TAC, USI-LS, Snacks, and what type of scheme might make sense make stock. To summarize our consensus as best I can, any stock life support system ought to: 1) Be a single, simple, LS resource that can be understood at a glance. 2) Be toggleble in the difficulty settings, and offer a less serious consequence for failure like going on strike or hibernating as well permadeath. 3) Offer a 3 to 30 day grace period, either in the form of 'hunger' as in USI-LS, or as a small standard stock for each pod to cover most Kerbin SOI missions. 4) Include a prerequisite mission pre-planner with mission time estimator and alarm clock functions so players could plan ahead and stay informed of each mission's LS status. The exact mechanics of extending and/or regenerating LS are more flexible, but the goal generally ought to be to make a system that is as simple as it can be while still asking players to consider trade-offs in terms of cost, weight, and logistics. Such a system could potentially add an important new layer to the game in which players need to think carefully about time as a cost, as well as adding the tension and urgency of surviving in a harsh environment. What follows are my own ideas on how such a system could be executed: Let's say we stuck to a single main resource: Life Support - Measured in "days" and slowly slides from green to red based on the number of kerbals on board. Different crew capsules could have different stocks, but let's assume each starts with 3 days worth for each available seat. There are however a few ways to extend this: 1) Life Support Tanks - Generally these are sized so that each kerbal consumes 4kg per day by default. Visually they could be designed to look like they hold air, water, and snacks. Tanks don't empty, they slide from green to red as they become waste. Life support/waste can be pumped from one tank to another, at which point players could easily jettison waste tanks if they desired. Small Life Support Tank - (.625m inline and spherical RCS size radial) - 0.125t - 160f - Supports 1 kerbal for 24 additional days (necessary for Minmus, but not Mun missions) Medium Life Support Tank - (1.25m inline and large RCS size radial) - 1.5t - 2400f - Supports 1 kerbal for 360d, or 3 kerbals for 120d etc. Large Life Support Tank - (2.5m Inline) - 7.4t - 12000f - Supports 1 kerbal for 1800d, or 3 kerbals for 600d, or 6 kerbals for 300d etc. 2) Scrubbers - These basically increase life support efficiency at the cost of weight and power. They will probably be essential for interplanetary missions. Because their reductions are across the board, the more kerbals using one the more cost effective it is. However, adding additional like scrubbers will not reduce consumption past the first. Waste-o-matic Jr. - (1.25m low-profile inline) - 0.6t - 1200f - Draws 0.5e/s - Kerbals on-board consume life support at 50% their normal rate (worth it for 1 Kerbal after 150d, and 3 kerbals after 50d) Waste-o-matic Sr. - (1.25m materials bay size unit) - 1.2t - 3200f - Draws 2e/s - Kerbals on-board consume life support at 25% their normal rate (worth it for 1 Kerbal after 300d, 3 Kerbals after 100d, and 6 Kerbals after 50d) 3) Greenhouses - Greenhouses use energy to convert waste into usable life support. When facing sunlight they provide some of their own power and are balanced based on average daily life support output, meaning these numbers would hold at Kerbin but more power would be needed farther from Kerbol. Greenhouses can be set to continual production, stand-down mode, or daylight auto-switching, but if left without power they become defunct and will no longer produce life support. Hydroponics Bay - (2.5m science lab size cylinder, rotates to face Kerbol) - 3t - 6000f - Draws 2e/s when not operating, and 6e/s when producing - Replenishes life support equal to 3 kerbal’s consumption every 6 hours while in operation (worth it for 3 kerbals after 300d in Kerbol or polar orbit, and 600d when not) Large Greenhouse - (3.75m dome) - 4.5t - 9000f - Draws 3e/s when not operating, and 9e/s when producing - Replenishes life support equal to 6 kerbals’ consumption. (Worth it for 6 kerbals after 275d Kerbol or polar orbit, and 550 when not) All of these factors should be calculated by the game, giving a single "Remaining Life Support" number in days both in the VAB and in the vessel resources bar in flight. This way you could play around in the VAB swapping out different parts and watch the days remaining rise and fall and aid your decision making. I think until you get to greenhouses things are intuitive enough for a new player to navigate them, while still offering some fun challenges to veterans who want to optimize off-world farming. 4) ISRU - There are a few different ways to handle this. I initially leaned toward greenhouses being indefinitely self-sufficient, so if a player set up a base or station with adequate greenhouses they could consider them safe and move on to other missions without worrying about resupply. Another simple option might to use something akin to USI-LS’s fertilizer, an intermediate resource consumed by greenhouses in order to operate. If this were the case I would advocate for this resource to be replenishable by converting ore or another harvestable resource directly into fertilizer via a large resource converter so there would be some simple method of living off the land. What also might be nice in the difficulty settings would be a softer consequence to failure than mass kerbal death. Kerbals who run out of life support could go into "hibernation" or “on strike” and wouldn't be able to steer or EVA until the vessel is resupplied. They might also lose some or all of their accumulated experience. Death could still be the consequence for harder difficulty settings. Any LS system to my mind really requires some way for players pre-plan and manage missions in flight. I actually think this could be rather simple, and really ought to be a component of the game with LS or without. All we really need is an Alarm Clock function in the Tracking Station into which maneuvers, transfers, intercepts and LS exhaustion dates would be listed, and a Mission Planner added to Mission control where a player might select "Starting Body" and "Target Body" and be supplied with: Time until next Transfer window: x [Set Alarm] Delta V to Orbit (100km): x Delta V to Transfer: x Time until Intercept: x [Set Alarm] Delta V to Capture (100km): x Delta V to Surface: x And repeat the process for the return journey. This could be staged into building upgrades or even expanded by completing gravoli scans of a given body. Then all a player would need to do is compare the dates from the Alarm clock with the life support rating in the VAB (with some padding) to know that they were properly equipped. Though this is wouldn't be strictly necessary for Life support, I thought a really simple, forgiving way of abstracting habitation for kerbals might be to include a secondary resource called “Happiness”. Happiness - Kerbals leave the launch-pad with 100% happiness and remain so for 25 days. After that, a lone kerbal will deplete at 1% per day, meaning they will reach zero and become “unhappy” in 100 days. For each additional kerbal on board, Happiness depletes at half the rate, meaning 2 kerbals will be happy for 200 days, 3 kerbals will be happy for 400 days, 4 kerbals 800 days etc. At the time of reaching a goal Experience pays out based on how happy they are at the time it was gathered. The whole experience system needs some major work, and obviously if this was part of it everything would have to be balanced around it to make interplanetary missions more rewarding. Aside from bringing extra kerbals, Happiness can be extended with the following modules (Percentages stack with multi-kerbal bonuses, but not with other module bonuses) Small Living Quarters - 2.5m cylinder - 2t - 4200F - draws 1e/s - Reduces happiness depletion for up to 3 kerbals by 75% Large Living Quarters: 3.75m cylinder - 5t - 6800F - draws 3 e/s - Reduces happiness depletion for up to 6 kerbals by 75% Inflatable Habitation Module - 2.5m inline toroid that inflates to approx 5m. - 7t - 11000F - draws 5e/s (while deployed) - Reduces happiness depletion for up to 12 kerbals by 75% Training Module - (inline Dodecahedron approx 3.75m) - 5.5t - 9500F - draws 2 e/s while dormant and 12 e/s while operating - Replenishes kerbals' Happiness up to 90% and allows level-up without returning to Kerbin So 3 kerbals with a small living quarters will arrive at Duna at 75% Happiness, and 6 Kerbals with 2 small or one large quarters will arrive at 97%. You could of course just bring a training module, but it would come at a steep cost. I guess this is a lot of modelling to request, but with about 12 new parts I think there's the bones of a real-feeling colonization platform. Even with a pretty simplified system like this there's a lot going on, and in practice I imagine keeping track of how much life support each vessel has left would still be a challenge. A big part of this would be showing the user when the vessel will deplete both in the tracking station and in map mode, so you can see early on a warning marker along its flight path where life support will exhaust. Also vehicles in the flight list would have a life-support bar showing how much remains and a red date of when it will exhaust. Update 3/28/2016: Here is my best estimate at one-way and round-trip durations for bodies in the Kerbol system, pretty valuable information for anyone thinking about scale/balance in regards to LS balance and scaling: Mun - One way: 1.25d, Round Trip: 2.5d Minmus - One way: 9.25d, Round Trip:18.5d Asteroid Missions - Round Trip, 25d - 215d Moho - One way: 110d, Round trip: 310d Eve - One way: 165d, Round trip: 890d Duna - One way: 300d, Round trip: 1170d Dres - One way: 555d, Round trip: 1290d Jool - One way: 1050d, Round trip: 2530d Eeloo - One way: 1560d, Round trip: 3320d Anyhoo this is my best crack at it. Love to hear others' ideas.

I get your point, and your experience is a welcomed addition to the usual atmosphere of these forums, but I think that, as @Bej Kerman said, you're overselling modded KSP1 a bit. Let's not talk about the technical part, and focus a bit on the mere artistic side, KSP1 seems to be made out of assets raided from 20 different games. The fact alone that KSP2 has an art direction makes it better, something that even Restock+ struggles to do. Let's talk about the new VAB system, an unified building environment, with the same rules for both planes and rockets and all that magic happening with saving crafts and sub-assemblies and working together on multiple of them in the same environment without having to go though loops. I spend more than half my time in the VAB, that alone for me personally is worth 20-30€ if it was a KSP1 DLC. I admittedly don't know anything about what's going on under the hood, but on the thing I can see, whenever they speak or show anything I see an amount of competence and thoughtfulness that was never there with KSP 1 development. I'm already taking into account bugs and feature missing at launch, I'm pretty sure we're not going to get the automated supply runs systems until much later in the EA as they're probably going to ship it with resources, and I'm not going to be surprised if the non-impulsive maneuver planner is missing to from the first release, and I wouldn't certainly start to plan some long lasting save file with a tour of the Kerbolar system on the launch day release, but as someone that had my last two big interplanetary projects blocked by the Kraken bugging out random parts of my mother-ships I say that basically the same applies to KSP1.

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.

Too much talk about a funky little teaser, not enough talk about how incredible this all sounds! Honestly it fixes a problem I didn’t realize I had with KSP1 in that rocket launches sometimes didn’t feel impactful enough for how powerful they were. Absolutely love the time and investment you’ve put into this. Have to wonder what the fancy futuristic engines are going to sound like…

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

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!!!!!

So I thought we could talk about this image and what makes sense, what's missing, and what might make designing and building surface structures more fun. So from the outset we can see solar panels, the off-world VAB, some tanks of some kind, glass domes, a runway ramp, some kind of semi-procedural habitation block system, and maybe a starter colony hub in the center? Now, admittedly this is a very old image and we have seen much cooler looking reactors and fuel processors since then, so I'm personally hoping quite a bit of work has been put into this system and that it will continue to be refined before colonies are added to the game. First the good. The system looks relatively easy to implement, copying over landing strip tiles for instance (those need more thickness btw) and having support piers automatically plant underneath. Those piers should really have footings (more on that later) but otherwise a pretty doable implementation. And while the VAB and colony hub (maybe?) look like they're plucked out of a different universe I do like that we'll be able to play with larger masses and won't be in a purely modular design world. From an aesthetic standpoint I hope the procedural masses allow more visual definition--larger windows, no windows, alternate textures--rather than looking so generic. Now some room for improvement. Again obviously this is early but what Im not seeing is how this behaves as an efficient machine, just the way design works for most other aspects of KSP. Aside from structural elements and connector tubes all of the major modules and design elements should have a gameplay function--increasing habitation space, production output, power, whathaveyou. We're not seeing production infrastructure, neither fuel processing or materials for rocket and colony parts. There are a couple of domes there for aesthetics but Im not seeing greenhouses capable of supporting the population that would live here. More importantly what is the purpose of the larger massing blocks? Are they living space? Working space? Purely aesthetic? I'll say out of the gate I hope it's not the latter. Even if we do have a lot of creative freedom over how these enclosed spaces are shaped I hope there's some simple gameplay element that increases max population caps and/or production based on overall size. Next let's talk about materials and the kit of parts. The concept of a kit of parts is an important idea in architecture and has obvious tie-ins to a parts-based game architecture like KSP. Right now we're seeing a few different procedural truss systems some with footings and some without, just a couple of the more modular parts from other renderings of inflatable habitation, and this fairly uniform hab-space massing system. I would love to see a few additions to this kit that would add more depth to structural and architectural design for colonies. Web trusses - Web trusses are especially important in ground-based colony design where the loads are mostly vertical (while wind-loads and uplift would be cool, I doubt they're in scope.) This could open a lot of cool design space for bridges, cantilevers, and anything that's doing long spans between support piers. This could be a cool design mechanic depending how much these structures cost in terms of materials. Just as we learned there were tradeoffs between ISP and TWR there would be optimums for distance between piers and truss depth--ideally procedural with the ability to fine-tune. Cable stays/ Tie-rods - This would open a whole world of design opportunity especially for spires and tensegrity structures that use much less material for the same load. This could be an incredible tool for orbital station design where the compression loads are very minimal and what you're really trying to achieve is maximum stability with minimum mass. Im particularly thinking about harmonic wobble resonance when you dock a 1kt interstellar vessel to a station without any tensile reinforcement. Concrete piers, footings, and structural shafts - Concrete is a great material for planetary surfaces. There are a few different options from more familiar water-based carbon silicate based cements to liquid sulfur options. For the purposes of the game I think we could simplify the ingredients to base materials like "volatiles" and "regolith". We've all probably seen the funky 3d printed concrete domes made by robots in mars colony animations but this is not particularly realistic. Concrete requires specific conditions for curing and more importantly rebar or other tensile reinforcement to be stable. Formwork is also at a premium, so precast units produced in conditioned space are much more likely. For the game that's a good thing, as you could have simple set of procedural or modular concrete forms from footings, piers, or hollow shafts with built in egress to support larger buildings. All told I think you could boil ingredients for colonies down to just a few ingredients: Metals, Plastics, Regolith, and volatiles like water or 02 if we're considering LS. There could be some cool evolution as your production increased from harvesting mostly fuels, perhaps converting them to inflatable habs mostly made from plastics, into more metallic structures and later more robust buildings made mostly from excess regolith agregate from larger scale mining operations. You might also see concrete storage casks for some materials, especially the more radioactive ones. Thoughts? We've seen so little on this system so far.

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

I'd like to talk about the upcoming bleeding edge releases, which'll be all you see for a while: The next "big" release, release-190, is actually due to be a fairly huge one for users and focus on performance (though there may be a feature or two as well). It'll be happening in the public eye, as bleeding edge prereleases for testing dropping quite frequently. There is likely to be quite a few over the next month or so. You are encouraged to test these in a controlled environment, but as usual, we really strongly advise you either have a "testing" save you don't care about, or backup your save before hand. The first part of these optimizations, the safe part, already got released above with release-189. We are getting more aggressive now. Each release has code that may or may not cause bugs. Testing is important. I only have one bugtester so I'd encourage the community to test these releases if they have time and report back, ideally with performance metrics if they can (before/after fps will do, from landed and/or in orbit is usually good enough. Get landed on a "very distant" body for bonus points in bug testing. All data and scenarios are good and we thank you). We won't release a shoddy product for "moar fps" so that's why I'm expecting a month to get through all the Q&A. But you can help with speeding this along, if you feel safe doing so, by testing prereleases. Optional, but very very helpful. Thanks for reading. And without further delay, the first such release. This one should mainly help while craft are landed with the distant collider fix enabled: New in this latest version release-190 RC1: 1.) More experimental optimizations to the SinkingBody bugfixes, using caching, and benefiting mainly when landed. Known Bugs: 1.) Not exactly a bug, but worth mentioning: The Kopernicus_Config.cfg file is rewritten when the game exits. This means any manual (not in the GUI) edits made while playing the game will not be preserved. Edit the file only with the game exited, please. 2.) At interstellar ranges, heat can sometimes behave strangely, sometimes related to map zoom (be careful zooming out). It is best to turn off part heating when traveling far far away. (I am not sure if this is still relevant as of Release-159, feedback welcome). 3.) When zooming out all the way out in map view at interstellar ranges, the navball furthermore sometimes behaves oddly. We are working on this and monitoring all the interstellar bugs actively. (I am not sure if this is still relevant as of Release-159, feedback welcome). 4.) Very Old craft files may complain about a missing module. This is a cosmetic error and can be ignored. Reload and re-save the craft to remove the error. 5.) Sometimes when reloading a quicksave to KSC, you will get the KSC sunken into the ground. This is cosmetic only, another reload of the same save will fix it. (This error has been around forever, just now listing it). 6.) When you uninstall a mod that had installed a Terrain Detail preset you were using, it may be listed still in the Graphics settings as "New Text." This is by design. If it bothers you, please reinstall the mod that setup that preset, or delete settings.cfg and let it regenerate. 7.) Some mods that used custom Terrain Presets may require you to delete your settings.cfg file and reset your settings with this release. This is rare, but can happen. See this post for details Known Caveats: 1.) The 1.12.x release series works on 1.12.x. The 1.11.x,1.10.x,1.9.x and 1.8.x releases are deprecated 2.) Multistar Solar panel support requires an additional config file, attached to release. 3.) As of release-107, scatter density underwent a bugfix on all bodies globally that results in densities acting more dense than before on some select configs. Some mods may need to adjust. Normally we'd not change things like this, but this is technically the correct stock behavior of the node so... if you need the old behavior, see config option UseIncorrectScatterDensityLogic. 4.) As of release-151, polar generation behavior has changed slightly. Though it will be safer overall for new missions, be careful loading existing craft there. This is probably not lethal but I don't want you to be unaware. Maybe make a save just in case? 5.) The "collider fix" as it's called, which fixes the event in which you sink into the terrain on distant bodies, is now on by default. If you really need distant colliders, turn this off, but you'd best have a good reason (I can't think of any). 6.) The particle system was hopelessly broken and has been since sometime past 1.10.x. Few mods used it, so it has been removed completely as of Release-146. 7.) Because we now unpack multipart PQSCity's correctly, you may find some PQSCity structures are in the earth or floating. Report such bugs to your planet pack author as this is an intended change (only cosmetic).

Do companies have any liability for violations? Not hiring violations, technology transfer violations. Ie: Say they hire a barista (one of the example jobs at Starbase) and employees are having lunch, and talking about rocket stuff. Obviously if any employee was to sell information to a state actor that's an ITAR violation, regardless of citizenship status, then SpaceX gets fined? Lack of diligence in hiring reliable people? Or are employees at a company facility not allowed to talk about work (maybe SpaceX needs to invent the Cone of Silence (when the kids were little I totally would have bought one )? Assuming they do any sort of background check on people, is such a check possible at the same level for someone whose history is mostly outside the US and hence unavailable? Is it more expensive to hire such a person (checks, etc, presumably carry some cost)? Also, does this mean literally no "US Persons" in this refugee category have ever applied for and been denied from any other defense contractor, or is the DOJ going against all defense contractors all the time for this, or does LockMart, etc, simply hire them?

NMS even 6 months after launch was less talk and more updates, including content updates. Not only that but I'll eat my hat and socks if we will ever see an honest apology along with a real explanation of this launch, let alone an expansion to KSP2 released for free for the poor souls who bought the game expecting we will actually progress through the roadmap at a very decent pace (their statements, not mine). In the meantime NMS did so with several feature packed expansions across several years, who were released for free, and they still do it today, many years since launch. Sure, NMS launched bad too, everyone screws up, but what separates boys from men is how you handle it afterwards and if you own up or finger point or just pretend it didn't happen. Which is why I bought NMS on every platform I own to support that kind of attitude and respect towards players. IMHO KSP2 is already too late to be a story similar to NMS, but time will tell.

When we talk about nuclear weapons, you hear 4 countries that show up on that list.. Namely America, Russia, China and India. Well, now we have a new Space Race between America, (Both NASA and Space X), China, Russia and now we can throw India into that same list of  lunar Landings.. This proves one thing in spaceflight.. Even up and coming Countries do have the right to land on the moon. Not just an exclusive few... It sort of reminds me of that old Comedy film called The Mouse on the moon. Where a small country like the Duchy of New Fenwick get to the moon first.. But as was pointed out in the movie , it's not who gets to the moon first, but rather the first to get home.. To get the Prestige. But at least now we know one thing.. We now are starting to get a community started on the moon. I'll be only a matter of time when we have actual bases up there.. Who knows? We might just see it happen.

Propaganda to appeal to existing vested interests, corporate lobbying to enforce those interests, and internet influencers to mould public opinion in favour of the status quo. Talk is cheap. Talk which is merely telling people what they want to believe anyway is even cheaper.

If people cannot expect an early access product to be enjoyable, it follows that potential buyers should buy the product to support its development into its promised state. Otherwise, why is the product even in early access? But when we talk about consumer expectations of early access, we must also consider the expectations set by publishers and distribution platforms of potential buyers, as exemplified by the warning you get on Steam for any early access product: In essence it tells potential buyers: "Buy only if you would be happy with what you got with no further changes." And indeed, arguments to that effect have been made on these forums many a time in discussions about the state of the game and early access. From this, it follows that potential buyers should wait until such time as the product is enjoyable and not to expect it will be developed any further. So... Are we buying early access games for what they are supposed to become, or what they are right now with a potential bonus in further development? Certainly, the latter is the safer guideline for a potential buyer. But if everyone strictly followed it, there would have been a lot fewer sales at launch.

Maybe, maybe not. I don't know. After the unfixable Kraken attack that kept exploding the station, I've just lost all motivation to do the station. But that really isn't BDB related, so if you want to talk about it anymore, please message me on the Dreaming Big thread, thanks. (Context: Dreaming Big is a mission report series by me where I make super large space stations.)