Search the Community

I love seeing the thought process behind design but, and I mean no disrespect, it's not like we have any shortage of "here's the stuff we're planning"-type posts. The issue that people on these forums tend to have is that they aren't seeing the results from all the design talk. I think what would be most cathartic at the moment is hearing from engineers, so we can see exactly how these designs are being implemented. I think that ties into why people are upset over not seeing gameplay footage and whatnot. Like, it's all well and good to see mock-ups explaining a design, but we've had so much of that since release while seeing the actual nuts and bolts has been very scarce. I hope you (though, more specifically, whoever the people are who decide what information is released) take this as some more constructive criticism. The game has been in development for, let's just say, a while. It's been released in some form for almost 5 months. So I just don't have a lot of interest in more posts about art or design. That stuff is all fun but I've also seen creative teams, startups, Kickstarters, etc, spend so much time on pre-pro and planning but, when it comes time for rubber to hit road, nobody knows what to do next. In this case, I guess that'd be the engineers, so that's what I've been craving lately.

There's lot of interesting concepts out there for radiators and I would certainly like to represent more stuff than just linear things. Look up Curie Fountain radiators for example. Cool ideas! I am definitely no stranger to making nuclear engines of lower power create heat, and I can say with some certainty that it isn't fun (can probably dig up a few pages of arguments from one of my older mod threads, haha). You need a big gameplay bonus to saddle the player with the negative results of heat production, or it feels like busy work. The studies the SWERV is based on also effectively say that the math works out if you keep the Isp below 1800s or so, and the engine's heat generation is fully covered by the exhausted propellant, and while I'm a little skeptical, it's not like we've ever built a functional closed-cycle gas core reactor to check. That being said when these capabilities come in, we'll definitely figure out what plays well, and what appropriate trades to make a player try to work in. It might be that the SWERV is a good place to introduce a player to the concepts of having to add a little cooling for a powerful engine. In addition to what's said in the devlog, it might be worth highlighting a few things Conduction 'resolves' effectively instantly on any significant timewarp unless you are using a thermally isolating piece of kit. Your vessel just tends to a specific equilibrium - one that results in everything being fine if you have enough heat rejectors, or death if you don't. It is more math for the same result. KSP1's conduction model was... interestingly used. The two places you'd run into it most in average gameplay was reentry, where the tools you used were heat shields and service bays, which actually had special modifiers to NOT conduct effectively (or eliminate flux altogether). If you run conductive physics only the vessel that's in focus, you've now created two different thermal paradigms, and a player has to understand what context their ship is operating in to predict their regime. Both regimes should operate in the same way. If your fission reactor is running at 3000K, yes, you will probably bleed heat to things beside it. However, your reactor has probably melted down now and you've got way larger problems. Those problems are the ones we want to focus on. From my previous employment and analysis of these kind of problems, that aligns with mission-level reality. Specifically Systems that are thermally vulnerable are thermally isolated, and tend to be very vulnerable (+/-50 K is the highest range I've seen between difference between instrument death and survival) Environmental conditions are far more important than other spacecraft components. Two macroscale components next to each other don't affect each other at anywhere near the same scale. Both are affected by the local environment before either (this isn't strictly true for the microscale, for example an imaging device increases in temperature while it takes pictures, which could bleed to the other side of the detector array. But even then, we'd thermally isolate them and then supply external cooling or specify a duty cycle for cooling off) I've got some ideas, but the first iteration of this system definitely focuses on cold = good, hot = bad. Thanks! It's important to not go to deep, but also represent it as a real challenge. Good questions! Kerbals don't produce any heat, but they do participate in the simulation. So they are an object when outside of their capsule that can be affected by flux, and have a temperature increase. They'll be thermally squishier than parts, as they should be, so that having things like thermally resistant rovers might be fun. I can't really talk about that too much right now, stay tuned! Yeah this is one of the big pain points of a high resolution system. That goes into player UI tooling. We have solutions in mind, but have to see exactly how you all use the system and where the pain points are. Your comment about inputs and outputs is exactly right - we look at it as making sure you balanced the I/O. We assume the kerbals build their capsules correctly and that they know the heat exchange piping better than you do! That would be a good goal, I personally don't love its looks though, so it'll be reluctantly Flux and temperature have to be tracked per part. We assume that radiators added to a vessel include the piping for a high efficiency heat transfer system, because well, we do that with electricity and fuel flow. It's a similar level of detail. Yes, I took a ton of lessons learned here to heart when we were building the concepts for this out. It's important to make a distinction between element complexity and system complexity, because that's a trade you are often making in any system. If you make a system out of high complexity elements and plug it into a high complexity system, that's scary. It's very challenging to design, implement and particularly, test and tune. Complexity isn't necessarily good, and though reality is complex, representing reality through system complexity isn't always good. A nice self contained example is how parts in KSP1 have heat tolerances in the 1-2 thousand K - though the system is more complex at the part to part level, the result of the complex interactions creates a need to balance out heat spikes with unrealistically high heat tolerances. The core requirements for this system have to cover more user stories than KSP1, and I'm definitely aware that in doing this, I'm always going to break someone's workflow, or create something some players won't like. In this area, we think that serving stories that are completely unavailable in KSP1, like coherent heating from systems, tracking of part heat at high timewarps, and simulating heat items on vessels that aren't in focus, are more important than that. I don't think that's actually wrong. If you have excess heat in space, you can solve it by one of two ways: add a system to take heat off (let's call that vessel architecture) or don't go into that situation in the first place (let's call that mission architecture). That's what we get here. We have situations where you solve a problem with vessel architecture and a ton of heat rejection equipment, and we have situations where you solve a problem by changing your mission. The latter is pretty wide, but that includes things like flying skimming reentries to bleed off speed so you don't need a heatshield, or building your colony near a water body so you have access to easy water cooling. The essence of this is making sure we are representing the right problems, and making sure the right tools are there to use them Hey, that could be a airless planet you're talking about! The point is there though, and functionally, there will always be places where a system will not represent reality. In even more places, a system will not be plannable. Lack of plannability is bad. The example there is pretty interesting because when you dig into it, you need to know a lot of variables. How long is the day? Is the colony ever exposed? Is there orbital eccentricity? What happens if a tiny edge of the colony is exposed? Even if you ignore atmosphere dynamics, radiator re-emission, etc, it's a really hard problem!

The writeup explaining the system is excellent, however the nature of the system and some stuff left out are clear problems: You're trying to tell me this is more complex, yet all you talk about is how it is more simple. Telling me how the sequel improves over the original is a main selling point, and whilst you tell me there's more elements, at the same time those elements are handled in a simplified way, in what's certainly a regression. Another thing that it fails to address, that seems to be too easy a conclusion for readers to come to: how is the heat system not entirely solved by just "add n radiators or heatshields"? Specially now that radiators are procedural parts. Your "shadow of a mountain in a sun-grazing planet" colony example is probably the worst one, since it clearly ignores atmosphere dynamics (hot stuff makes air hot, should saturate radiator output). When. Yes, it becomes more important and more glaring of an issue with each passing day. Re-entry heating was promised as a release feature in the media event, then as a coming soon 143 days ago.

We're in the same boat. While an interesting dev insight, this also leads me to believe it's still in concept phase, which would have been fine if this dev insight would have been released 1-2 years ago, but today it just angers me to think I paid almost full price and only now I see core mechanics are being in concept phase !? I'm pretty sure it wasn't even the slightest hint in interviews, announcements and communication pre-launch at the fact that KSP2 EA will launch without re-entry heating, and that it will be included with the science update which itself will follow towards autumn '23 if we're lucky. I don't know who thought a core mechanic like re-entry heating could possibly come bundled as a milestone update. It only leads me to this example of why this is a bad practice: Why was is it so hard to be upfront about this before launch, "hey, these following features that KSP1 has [insert bullet points], will not be there at launch and they will follow in more than half a year, maybe towards the end of the year, as a rough estimation." I can only say that this is "winging it" or ill intent. Rather than make a quick buck and get more than 50% negative reviews, it would have been more beneficial for your reputation, if you care about it, to have less people buy it initially (which would have no surprise between asking price and what they get) and then more people slowly buy once you EARN their trust by clear communication and clear development goals with deadlines that are being met. There, I said it. Deadlines. Being able to talk about concrete deadlines separates people that know what they are doing from the others.

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

SpaceWarp 2.0: Help Us Shape the Future of Modding! Dear KSP 2 Modding Community, We're thrilled to have grown alongside you as the SpaceWarp modding API project evolved from its inception in version 0.1 as a simple mod loader, to a community-driven modding API in version 1.0, to where we are now. Your continuous support and feedback have been invaluable in making SpaceWarp better. As we look to the future, we're excited to announce that we are beginning work on SpaceWarp 2.0, a new chapter in our modding journey! Learning and Growing Together Our journey through 1.x has been filled with learning experiences. We've listened to many of your suggestions, and have recently introduced some significant updates, such as: specification versions - allowing for major changes while still keeping older mods compatible, codeless part mods - to empower non-programmers who want to make KSP 2 mods, Lua support - for simple scripting without the need to learn C# and .NET, experimental support for the official mod loader - to help us prepare for the future. Those are just a few of the new features that SpaceWarp has seen added during the 1.x development cycle. Your valuable feedback has helped shape SpaceWarp 1, and we're grateful for that. SpaceWarp 1.5 - A Smooth Transition Before we dive into the details of SpaceWarp 2.0, let's talk about SpaceWarp 1.5, the next transitional step, and the last update in the 1.x series. We are going to mark all APIs that will be removed or changed as deprecated, and introduce their replacements, giving you a sneak peek of the changes coming in 2.0. That way, while your existing 1.x mods will continue working in 1.5, you will have enough time to prepare them for the major update ahead. Preparing for the Future We hear you loud and clear – KSP 2 modding shouldn't have to be tied to an external mod loader when there’s an official one on the way. That's why we're working towards making SpaceWarp fully compatible with both BepInEx and the currently unreleased official mod loader. That way, your mods written for SpaceWarp 1.5 and later should require only minimal changes to support the official mod loader once it arrives. SpaceWarp 2.0 - Modularization and Flexibility One of the key architectural differences in SpaceWarp 2.0 is the shift towards modularization. As the library has grown over the past few months, it has gotten to a point where a single project containing all the very diverse APIs and features is simply not sustainable anymore. We want to make SpaceWarp more flexible, so it has enough room to grow in the future without unnecessary complexity, in both the development phase, and in the integration, testing and release phases. Here are just some examples of the module structure we're considering: SpaceWarp.Core – The core mod contract and everything necessary to make a simple mod load in-game. SpaceWarp.UI – Including app bar buttons, UI skins, and other UI-related functionalities. SpaceWarp.Game – Abstractions of game APIs, enabling seamless interactions with many parts of the game’s code without having to worry about game updates breaking your mods. SpaceWarp.Audio – For handling of audio-related features and functionalities. The Right Approach We are currently considering two different approaches to the modularization of SpaceWarp: Approach 1: The Modular Monolith: We would split the SpaceWarp modules into individual projects and .DLL files, while keeping them all part of a single mod, single version, and single release zip. This approach maintains the current setup for end users and modders, keeping SpaceWarp as a monolithic, but not as tightly coupled library that covers various functionalities. The separation of concerns into multiple projects within the SpaceWarp solution will enable easier code management for contributors. Approach 2: Modular to the Max: SpaceWarp would be divided into separate smaller mods, each with its own swinfo.json file, versioning, and independent releases. Modders and players can then selectively use only the modules they need, improving customization and reducing unnecessary bloat. Community contributions to specific parts of SpaceWarp become more streamlined, as contributors can focus on individual modules without affecting unrelated components, making it easier for multiple people to work on many distinct parts of SpaceWarp at the same time independently. *For the sake of transparency – this is the approach that we are currently leaning towards the most, but we want to hear your opinions! Simplifying Installation for Players We understand that ease of installation is crucial for players. While approach 2 (Modular to the Max) brings with it more complexity when it comes to user experience when installing SpaceWarp, we're exploring solutions to mitigate this, such as always providing an always updated all-in-one download option for those who prefer simplicity, or the possibility of only installing the core SpaceWarp mod as a lightweight entry point, which will then prompt you to either download the modules your mods depend on manually, or even download and install them for you. We Value Your Feedback! Your opinions matter to us! We're building SpaceWarp together, and your insights are integral to shaping its future. We'd love to hear what you think about the two approaches we've shared: Are you more inclined towards Approach 1 (The Modular Monolith) or Approach 2 (Modular to the Max), and why? How do you think we can enhance the installation experience for players? Do you have any other suggestions for what you’d like to see in SpaceWarp 1.5 and 2.0? Please share your feedback here, or in the KSP 2 Modding Society Discord server, where the development of SpaceWarp and most KSP 2 mods takes place, for a more real-time discussion! Join Us on This Exciting Journey! SpaceWarp 2.0 promises a more flexible and future-proof modding experience. Thank you for being a part of this journey with us. Your contributions and feedback help us make SpaceWarp better every day, and we hope that we can all help the KSP 2 modding community one day reach the inspiring heights of its predecessor. Let's shape the future of KSP 2 modding, together!

Ewoks dont talk english and yet in sw: ewoks they talk english because otherwise no one would watch it. Its the same logic as that. Its also the same reason english people dont watch films in french or german because they dont understand it.

Don't you mean "original coders" or "people who were there at Star Theory"? Because I think people who came after are also real coders. But besides me ranting about semantics and assumptions you make on the code, the subject was about the AMAs. The last AMA was from Kristina Ness which join the company one year ago and it was pretty interesting. I have no doubt that engineers (even people that came recently) have a lot to tell. I mean by this time, they have learned what other people do or did, so they can answer things that they didn't code themselves directly. Even Mortoc who came a little before release seems like a very interesting guy. I don't know about you, but personally I have a lot of questions to ask them. I would also like plenty of dev diaries, even small features like orbital tesselation are so much interesting (maybe it's just me, I also liked the GDC talk).

JARVIS has emerged! I should note that the original Actively-Cooled Heat Shield System and Vehicle Including the Same patent by Stoke, establishing the concept of an engine which uses heat from an actively-cooled shield to circulate the coolant, was filed in August 2020 and claims priority to a prior filing from December 2019, and Stoke's Augmented Aerospike Nozzle, Engine Including the Augmented Aerospike Nozzle, and Vehicle Including the Engine patent was filed August 2021 and claims priority to November 2019. In contrast, Blue Origin's patent above was filed in July 2022 and claims priority to December 2021. So Blue Origin seems to be solidly behind the patenting curve here. Even Stoke's most recent Annular aerospike nozzle with widely-spaced thrust chambers, engine including the annular aerospike nozzle, and vehicle including the engine patent, despite being filed in April 2022, claims priority to April 2021, predating all priority by Blue Origin. I'll post more over in the Stoke thread, but I did note that their latest patent includes a depiction of a non-axisymmetric heat shield which would provide lift during re-entry at 0° AOA, although it's unclear how that would interact with the aerospike expansion in vacuum. One of the nifty things about BO's patent is the "plurality of scarfed nozzles" depicted around the heat shield: As Elon Musk has pointed out, one of the reasons that aerospikes suffer is that the primary challenge in rocket engine nozzles is getting the exhaust to go DOWN, and aerospikes aren't great at that. Actually angling and "scarfing" the nozzles into the heat shield like this will make the recessed nozzle surface present a more consistent surface against which the exhaust can expand, reducing intramolecular cosine losses, and it also protects the engines more directly than Stoke's design seems to. An element very similar to Stoke's design (and potentially grounds for a patent infringement battle) is that "The heat shield may be actively cooled [and] The heat shield may include a cooling circuit configured to dissipate heat encountered during reentry of the upper stage." They also suggest "secondary fluid injectors" which may eject fluid (presumably from an open/bleed expander cycle exhaust) along with the scarfed thrust nozzles to help shape the plume, which seems to be the configuration depicted here: Later on they contemplate that the heat shield would "be constructed of thin face sheets separated" by spacers and that "turbine exhaust gas is fed directly into the space between the face sheets and exhausted into the space . . . inside the annular engine exhaust stream through orifices in the outer sheet." Using some sort of base bleed in an aerospike design is a well-known way to improve efficiency (for example, here). It looks like they are considering both a closed expander design (using numerous BE-7 turbine units) and an open/bleed expander design (using one or more BE-3U turbine units), depending on whether they use the base bleed or not. The patent explicitly states that their design saves development time by "repurposing turbomachinery (e.g., powerpacks) and thrust chambers designed for other engines" and references designs being created "for use in other space vehicles." Later on, it gives the non-limiting example of using "two BE-3U powerpacks" to operate the nozzles but notes that as many as five or more powerpacks could be used. BO contemplates that they could "power down some number of powerpacks and/or nozzles to meet thrust requirements" for certain aspects of a mission; this would require that the various thrust nozzles be plumbed to alternating turbopumps so as to keep the thrust vector consistent. They suggest a 23-foot diameter vehicle and a 21-foot-diameter ring of engines which creates, effectively, a single 21-foot-diameter nozzle. They anticipate a specific impulse of 395-425 seconds in one configuration, 400-420 seconds in another configuration, and 405-415 seconds in a third configuration; these configurations are not clearly differentiated. They anticipate that for the two-BE-3U-powerpack configuration, only a single powerpack would be used for vertical landing, with sea level thrust of "about 100 klbf" and throttling capability down to as low as 20%. They talk about each thruster producing 2000 lbf in some configuration but it's not clear how many thrusters they are envisioning with that thrust level. Given that the BE-3U is expected to produce as high as 160 klbf in vacuum, this would imply probably thirty thrusters plumbed to each of the two powerpacks.

Yes, he's being sarcastic. And to not deviate from the subject again: It's just vacation time, maybe they have just been doing bug fixing and they have nothing more to share, we still have the bug update status which is a nice addition in my opinion (Some people don't like Nate talk so maybe they're happy about that?)

The minimum for any space station is; comms - have an aerial on there So we can talk to it power - batteries and solar panels So the comms works! Docking port You can EVA crew between craft but you can't transfer fuel with an EVA Remote control of some form Even if it's crewed have this then you can transfer the pilot off the craft and still have control RCS and monopropellant So you can manoeuvre to dock A high efficiency rocket and fuel To de-orbit at end of life or for large scale orbit changes If you want it crewed then you need to add; Crew compartment (or lab) Cupola or similar control pod Otherwise they're jut passengers coffee machine After that it is just a case of what do you want it to do. I tend to build everything with two 2.5m docking ports so I can dock craft but not lose a docking port in the process.

Am I used to my worldview not being celebrated by popular culture? LOL Well, at least we don't have to worry about that for the near future. 2023 SAG-AFTRA strike Maybe if we're lucky they'll all get made redundant by AI. As a complete aside, I always LOL over the content filter here. My father fought the real pedants. The ones who almost conquered the world, not these lame posers that are prancing around these days. But for some reason I'm not supposed to talk about that. I could fill this thread with memes. But I like @Vanamonde, so I play nice.

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.

For my money, the most useful/interesting IG content tends to be (in decreasing order): - Patch Notes - Bug status reporting and patch Predictions - Longer term dev work and roadmap development - Dev diaries for either of the above (far more interesting to have a deep dive but it takes more effort to create so typically covers less ground. Still more please if someone has the capacity and something really interesting to talk about) - Challenges and Community Highlights vaguely entertaining but I don't have much free time to engage with them ATM) - AMA (tend to be a bit short on new information)

So you can talk about KSP1, KSP2 is not so different from the first part This is easy to do when trained specialists bring the finished line, find suppliers, hire and train personnel. It's easy to hire Nertea and take a bunch of parts from him for the game You can learn a lot from squads in 6 years. I understand it is very difficult to add anti-aliasing, parachutes for kerbals and frame rate capping to the game. It would be understandable if the developers would have difficulty adding realistic physics, but even the banal things are still not done.

unfortunatelly i dont think i can talk about the Hows to do it here, come to the KSP2MS discord server! we're more then open to help you there! https://discord.gg/ksp-2-modding-society-1078696971088433153 but about the parts JSON configuration, that is not yet as simple as modifying a file, you'd need to repack the files in unity, We on the KSP2MS are developing a ModuleManager a like for KSP2 tho!

It was Ghostii, on the Discord in late April. yes it does! Nate is actually a huge fan of HOTAS, so it is something we talk about occasionally. I think it be after 1.0 though so that the majority of the issues are ironed out

I found the quote that @Turbo Ben was referencing on the Discord, from 24 April in the ksp2_general channel: yes it does! Nate is actually a huge fan of HOTAS, so it is something we talk about occasionally. I think it be after 1.0 though so that the majority of the issues are ironed out AFAIK while there have been other statements that full controller support is on the roadmap, this is the only one that has tied it to a specific point.

Let's talk about your other point about the KSP1 documentation being lacking. I happen to agree with you there and see both the existing KSP1 docs and what we've got going for KSP2 as a necessary but not sufficient thing. Can you elaborate on what you'd really like to see in addition to the existing KSP1 documentation? I'm asking because our KSP2 docs are themselves highly extensible via articles and your feedback here would be valuable in helping us move the ball forward! What kinds of articles do you think we should add to a site like that so we can better meet the needs of the modding community?

In the video you linked we see Nate Simpson talking about modding (and representing Star Theory, not yet IG). I played it multiple times and listened carefully, but did not hear where he promised documentation specifically. Scott Manley says things like "make it easy, not have to decompile, un obfuscate large parts of the code", and Nate is clearly nodding his head emphatically through that part. Nate answered by saying "That's one of the nice things about knowing exactly what you're gonna make when you start making it, so we can really make some core architectural decisions to make sure that it's highly moddable, highly stable, highly expandable, ... we wanna see a platform that has a life... I mean the original game's continued to evolve over nearly a decade..." That said, I've yet to hear anything from IG other than that they want to support modding. I'd be quite surprised if they don't deliver some sort of documentation at some point, but what I see and hear in this video is a clear articulation of support in general, not a specific promise of documentation. For that matter, I'd say based on what I've seen that they have, in fact, delivered much of what they said they want to do in this video. We do have a highly moddable game with a core architecture that reflects their design choices to make it so. In the three patches (4 counting the hot fix) that have come out so far there have been only very minimal impact to mods - though a good portion of the credit for that belongs to people like @munix and @cheese3660 wisely making design decisions at our end to ensure there's minimal impact. Let's talk about the other point you made where you seemed to be implying that we're practicing some form of piracy and may in fact be in violation of this forum's rules. Did you visit the site we linked? If so, did you happen to notice the long and detailed article I wrote there meticulously describing the process we followed? If not, then I'd like to encourage you to please read it. https://schlosrat.github.io/articles/HowMade.html The site we've got is made without decompiling the game's code. The information presented is the same as what you'd get from Visual Studio if you dropped an untouched copy of the Assembly-CSharp.dll in as a dependency and then wrote your own code to use it. All we've got is the publically available API interface that the code itself presents. There's not a single line of source code from the game. You might want to give that a gander before suggesting that piracy is a foot, my friend.

No, those two sentences are the exact ones they have to use when asked about stuff they can't talk about, by a myriad of reasons. In fact, those are the phrases they should've used when the community mentions "1000 parts" or when they were asked in the interview. Did you listen to the podcast? Since you ask about context, we can move a minute back, starting from around 1:12:00 and end after the full quote. Nate and Paul are (were, since Paul got fired) a team, and it seems to me you're assuming they went in blind and got assaulted with questions and were incapable of saying no to this one question in particular, or for Nate to be incapable of stopping Paul. Well, not only do I not believe any of that, but they're also a team representing the same company and product, so what one ways, unless the other interjects and denies, goes. Interviewer: You kinda touched on this earlier. Have any features from mods inspired features in KSP2? Answer (Nate): Yes, the easiest answer is visual fidelity, it needs to feel epic, and there've been a number of visual mods for KSP that have raised the bar regarding what's possible. [...] Eve and Scatterer [...] at least show what the minimum should be and we want to exceed that drastically. We talked about parts mods as well, and when you're making a game that has a bunch of interstellar class engines, Nertea has set the bar very high. We need to be about as realistic and detailed. Is there anything else that pops into your head Paul? Paul at 1:13:35: We're working with some graphics engineers not only to make our game more beautiful but again performant, we've got some numbers in this week for what our expectations are on machines and holy **** it looks great and performs great. [...] Interviewer: That's awesome, specially when you have these massive arrays of rigidbody parts. If you have a 1000 parts craft in KSP1 your computer is not gonna be having a good time, no matter what computer it is. Paul again: That's one of the big boulders we're breaking apart on the engineering team, making sure that framerate performance does not suffer, I mean look, the scale of KSP2 is so much larger than KSP1, with so many more orbital bodies and potentially so many more ships and colonies doing autonomous background systems there's so much more to maintain, there's so many more systems that are just living in simulation, so we've gotta make sure the thing you're seeing on screen is behaving in a physically accurate and interesting and educational manner that makes sense and is still fun gameplay, but then all these things in the background are still doing what they're doing, is something is in some geosynchronous orbit and you back to it a year later it has be in the right place considering where it is in time, no matter how many times you're timewarping, no matter how many other colonies you have, how many other ships you have or are being built. So making sure all of that feels consistent while the thing that you're doing right now: to have fun or explore or build or launch or blow up in some spectacular fashion is also also there and awesome and feels tactile and realistic, like that is the number one challenge for the engineering team right now. I mean if you just change my example to say whatever else, yeah, sure. That's not what happened, and you have the quote up there to read, and years of evidence of them promising a finished, performant product all over. Sony is not half as demanding as you make it sound though, even for first party titles (Bloodborne comes to mind), heck, even the KSP1 port on the PS4 was painful. Yes, but they've decided to not say anything happened, so since we're working with their textual words to discount "1000 part ships" promises and others, we can't quote them saying something happened, we can only quote them saying KSP2 will come out performant, or if you ignore the last year, a full product and performant.

The amount of "we can't talk about that" and "no comments", and the average (low) quality and seemingly improvised nature of most of Nate interviews makes me think otherwise. Here they're talking on a podcast that was new at the time, not CNN. Implies it's Nate talking. Implies it's only one person saying all of this, and that person being Nate. Conveniently you've also cut out all the discussion about the background simulation. That's misleading at best. There's a whole argument to be had about the gaming community making up Devs promises and then getting angry at things they've imagined while they over-hyped themselves to oblivion. A big part of it is that anyone trying to deflate hype and debunk fake lies is seen as an enemy twice at first then they don't blindly believe at everything the hype machine says, pointing out that nobody ever talked about something, or confirmed anything. And then after the game released when they say that the thing they where hyped about was never even mentioned by any actual dev. Then someone makes a list of lies on Reddit, or Crowbcat makes a video, both of which will be 90% wrong, but still saying it automatically puts you in a "you're the enemy" position. I'm still not saying that it's the case here, I'm more than open to receive a definitive piece of evidence, a recording or post from Nate saying "100000+ parts", but weirdly enough while everyone seems to agree that that was promised, the only examples are 2 interviews in which the devs clearly evade the question and are very careful at not committing to anything. Interviewer: "Mr. Dev, will your car have 5 doors?" Mr. Dev: "Well, doors, uh? It's a thing we're working on... You see, you can't have a car without doors, and we're working on this new type of hinges that will optimize the door utilization, allowing us to have a number doors on our car." The community: "You've heard that? They said the car will have 10 doors! And that hinges must be needed to flap the doors and fly, so fully autonomous flight capabilities too" The car releases, it has 3 doors, the community is mad because it can't fly.

I ban you right back to your starting point from my last ban, only now there are 500,000 times the mosquitos and 1 sentient gator that wants to talk to you about your cars extended warranty and an exciting time share opportunity. But wait theres more! He has an opportunity for you in his mlm! 011507082023

Talk about colony parts and other star systems has me excited. It means they aren't going "We all work on Stage One, then we all work on Stage Two". I know we've been told that already, but finding out about progress on the Roadmap gives me hope that the delays are in bugfixing the 'Foundation', so that the rest of the Roadmap will be faster.

If you talk about this: He mentions how some of the change that we'll see is disabling some graphics for low settings to allow even more people playing the game (alongside other optimization for everyone). We can already see some examples of these changes in the previous patches: No ETA on other optimization though (beside the occasional ones each patch), especially the new terrain system. I hope we'll get some news on this (I think it will take several months but I would like to know if their implementation is getting good results).