Sep 8, 2023

Kerbal Space Program 2 - mikey

Attention Kerbonauts!

ICYMI, a few weeks ago we sat down with Senior Mechanical Concept Designer Chris Adderley for an Ask Me Anything. Thank you all for your questions and for tuning in! A reminder that we are in Early Access and plans can change.

Check it out here on YouTube. Chris answered more of your questions below, read the full questions and answers here!

[h5]Alexoff[/h5]
What percentage of the parts in KSP2 were created by you personally?

Depends on how you measure it. Effective zero because I don't do the asset work, by one definition. In terms of maybe inception/conception, in the EA release I'd say I had a hand in about 10%.

What will be the largest part in KSP2?

The largest part I have in my list right now is in the 80m+ size category. It's a lot harder to measure colony parts versus vehicle parts though...

Do you participate in the creation of parts for the colonies?

I participate in the concepting and design phase, yes. It's where I'm focusing a lot of my 'thinking time' these days. Colony parts are both similar and different from vehicles - in what they look like, how they assemble, etc. As we get to those milestones, we refine our designs from player feedback.

How difficult is it to add a new part to KSP2? Is there a big difference? Is it harder than creating a new part for KSP1 as a modder?

Most things in KSP2 end up being more complex than in KSP1. As an example at the basic level, the PBR shading model that we use requires more texture maps than KSP1. That is mitigated by having access to internal tooling and a faster iteration look (click Play in Unity rather than load the game).

[h5]Stephensan[/h5]
Are there any more concepts for more air-breathing engines like the J-90 (smaller or larger)?

There's been team interest in larger air-breather engines, but as always, that's not so simple. Adding an air-breather of say, 2.5m size requires us to also look at the supporting parts in that size, like intakes and cockpits, so the player can have a good experience when using those engines. That balloons the required significantly. I would want to push out the different technologies rather than footprints first. Nuclear jets, propellers - all unlock interesting new player stores!

Is there gear that'll be angled from the fuselage not straight up and down, and finally more tires/wheels in the concept stage (or even remotely thought of)?

We definitely have people on the team who want that!

[h5]LunarMetis[/h5]
How will the sizes of different stars be scaled with respect to Kerbol? Will they be scaled at 1/3 of their real-life analogs like Kerbol and the Sun?

Specific scaling of the actual meshes is less important than defining their specific insolation numbers for input into solar panel math, but yes, they'll be Kerbol-relative.

How do you plan to implement proper motion of other star systems, and how do you expect that to add to the challenges of interstellar travel?

Hah, interstellar travel is going to be hard enough already. Proper motion is something we need to balance carefully there.

[h5]Pthigviri[/h5]
I'm sure you've been deep in colony part design. What are your thoughts on greenhouse and simple life support with snacks, for example? How do you see conveying that colonies are both real places where Kerbals live and 'working machines' like the way vessels are?

Honestly, I don't like basic life support (by basic I mean something like having Kerbals on a ship consume a resource). I've played all (I think all?) of the KSP1 mods for it, and I haven't found something that's interesting and holds my interest beyond frustration for more than a few hours - just not my cup of warm beverage.
More seriously though, systems like this need to have a bunch of considerations. They need really carefully crafted player stories that support different player archetypes, not just advanced players. They should also work on a carrot rather than a stick-based approach. KSP has a lot of sticks right now. Finally, they need scalable solutions that are plannable and toolable. That's a big thing where LS gets expensive in dev hours. We have some things in the works around colonies that ape some of the 'results' of life support, which I hope will get at the idea of colonies being a little more Kerbal-involved than just plunking Kerbals in a command part.

[h5]PDCWolf[/h5]
Has the concept of heating changed at any point based on feedback?

The short version is no, the long version is yes. A lot of interesting discussions sat around things that are further down the roadmap, and they provided us with a couple of additional things to consider. Interestingly, the player stories we have were well aligned with the comments that I read, but the way the player stories were addressed were not unanimously approved. That’s fine – part of the EA conversation – and in particular with a lot of discussion being on items later in the roadmap, this makes me confident in the iterative model.
We’ll get the basics of the system focusing on reentry stories out to everyone. We’ll evaluate how that works with the playerbase. As we move towards the next milestones, we can use the information encoded in the thread, which I’ve collected internally, to make sure we’re making choices (engineering or design-wise) in conjunction with the feedback from reentry to get good solutions. One thing that jumped out for me was that there’s a lot of talk about macro vs micro solutions. I’ll be the first to admit that the current solution is a macro solution. So future design work will probably focus on whether there’s more microscale interaction to look at.

If I know the peak or average specific heat flux a vessel is going to go through on its final orbit/landing spot, what spots me from just adding enough negative heat flux parts to counteract it?

Nothing. That’s what you should be doing. Of course, it’s not really that simple. If this is atmospheric heat from going fast, adding a big radiator is likely to just increase the amount of next flux, because it has a large surface area. Most heat mitigation tools need something else too – a radiator might need electricity, which means you need to supply that, which will enforce additional constraints.

Considering its possible uses on the automated logistics network, long missions, and just straight up anything that only requires time to pass, how do you balance not timewarping versus letting things happen in ultra-fast time?

These are the best questions because they’re the hard ones. Often we trend towards supporting a player path that doesn’t reward excessive timewarping, but doesn’t exclude it either. A good case study is resource extraction and deposit concentrations. There’s definitely fun in seeking out and finding the best deposit for mining. Obviously though timewarp makes that kinda moot in timing. You could just start mining a hypothetically low-grade deposit and warp for 50 days. That tells us that time and rate -based mechanics need to have more to work well. A specific example here is that a newly accessible resource should be constrained differently – challenging location, resource transport limitations, etc.

We try to move the real player decisions to things that are interesting with and without time as a mechanic. Mostly hypothetical examples, but here’s a few ways of thinking of these things on top of my head:

Put a locational constraint on something. If you need to do something in orbit over a specific part of a planet, make it take longer than the average orbital cycle. This might encourage a player to put a satellite in GEO orbit over that place. If you do the work to put it in GEO, you get the benefit of being able to timewarp.
Use binaries instead of gradients. Does ore concentration really benefit from a really detailed gradient from 0.0001% to 100%, or can you look at it as a yes/no? Trade that, see if you’re damaging player stories with that simplification.
Use supporting systems. Sure, you could mine that deposit at high timewarp. But the deposit is on a planet with a day length of 200 days, and you need power, and the area has no fissionables. How are you going to power it? If you solve this problem, it is satisfying and you get a cookie. You did the work, enjoy your timewarpable extraction!

These are really big problems we look at for all of the more complex systems because hey, an interstellar transfer could be 100 years. Players will timewarp that and that’s… the whole length of a KSP1 campaign. Fun with and without timewarping like this is essential.

[h5]Socraticat[/h5]
What are your favorite tips and tools for new modders?

My biggest tip is to do what you want to do and not focus on what others want. Lots of the most creative KSP1 mods didn’t hitch themselves to any one concept of the game, and that’s what made KSP1 modding so successful. You want RO? You’ve got RO. You want to launch kerbals in a cardboard box rocket? That’s there too. You want life support? Oh hey there’s about 5 different concepts out there to pick from. Also don't try to form a team day 1. Get some experience, release some stuff, and the team will come to you!
Regarding tools, Blender is an amazing piece of free software, and there are a ton of good coding tools out there for the software-minded as well. It has never been a better time to be an independent purveyor of these kind of things, you don’t need to suffer through e.g. gmax or the trial version of Milkshape3D anymore.

[h5]Royalswissarmyknife[/h5]
Is there any consideration of 1.875m parts?

Building out a whole family of 1.875m parts that includes the core stuff (engines and tanks) plus the necessary ancillaries is a lot of work and not something the team is committing to right now.

[h5]Strawberry[/h5]
While we do know it won't be added in the short term, the team has previously been wishy-washy if radiation/life support will make it into the game. Are these topics something that the team has decided won't be in the game until maybe after 1.0, or something the team has a firm answer on what they want to do with but does not wish to disclose it (though if you do wish to disclose please do), or something that the team is genuinely undecided on?

See answer to Pthigviri about LS!
Radiation is a bit more interesting to me because I have a fair bit of history in mods with it, and I’ve eagerly assimilated the early concept work the team has done for KSP2. There are two tradespaces in terms of vessel design, point sources, and ambient radiation that we at least nominally want to think about including.
Ambient radiation is basically a time trade. How long can you spend in a radioactive environment? You can throw things like radiation shielding, storm shelters, etc but ultimately it all comes down to time to Bad Things. It’s harder to help a player to plan. You have to give them tools to determine how much radiation there is around somewhere and how to figure out how long they can spend there, etc.
Point radiation is nuclear engines and reactors. This is harder to implement but is definitely relevant in terms of craft design, because it is a big part of why fictional interstellar ships look the way they do. Interestingly it is easier to model and communicate to the player because you know lots of the variables at vessel build time. One of the messy things here though is that as soon as you throw in radiation, you railroad players into building ships with nuclear engines in a very specific way. We have to craft a solution that hits a nice middle ground. See this comment.
I’m candidly going to say that we don’t have the ideal solution in the bag right now – but that’s what EA is all about. I’m sure I’ll write some discourse on radiation eventually for a dev blog and everyone can weigh in on why I’m wrong :P.

[h5]Pokaia[/h5]
Are there features you modded into KSP1 that you are bringing into KSP2? What is your favorite?

I wouldn’t want to port anything specific without a good justification, but I really want to bring in more planning tools. The only ones I built were around heat and power management, but yeah. Something like that. One of the cool things about this job is that I get to start again, so to speak, with the support of people who have been in the industry for a while. So if I want to bring in nuclear reactors, I can take my concepts from Near Future Electrical, talk to some Real Designers™ and get their opinions on what works and what didn’t work, and make something cleaner for KSP2.

[h5]stoup[/h5]
Are there any types of parts being added to KSP2 that as far as you know, weren't really available as mods in KSP1? Some unexpected bits and bobs, maybe?

The entire colony loop is more or less stuff that was never really available in KSP1 mods from a system perspective. Modding KSP1 was really wide though – hard for me to say.

[h5]Kalessin1[/h5]
Will all parts from your mods be implemented in KSP2, especially large solar panels, station parts, and MK4 spaceplane?

Hah, no not at all. I like to re-use concepts, but this is a great opportunity to start afresh and to fix some stupid things I did in development of those in my mods. Gotta somehow get more Thunderbirds in the game, though.

[h5]Cocoscacao[/h5]
Will we get size variants for all parts? Example, hydrogen tank with the smallest radius only has a long option. Why were "semi-procedural" parts not considered, where you can select a tank and set its length and radius to some predefined available values?
You definitely have me to blame for no smaller hydrogen tanks – just don’t think they’re useful with the low density.
Why does wobblyness still exist? What are the design choices and reasons to keep it, if there is a way to remove it? (If there is a way to remove it...)
I have a post on my thoughts about this as a player. Generally though, it's not where we want it to be and we're trying to figure out how to get it there. There are various posts on the KSP Forums that do a good job of explaining some of the whys.
[h5]SAP KSP[/h5]
How advanced will the Kerbal's technology be, will there be very advanced parts such as anti-particle devices?
We'll definitely get way up there in the tech tree. I do want to keep those under wraps for now, though.
[h5]Infinite Aerospace[/h5]
Are you able to tell us something about Science and career modes? Delving deeper, what can we expect from Science mode? Is it the same 'click and reward' setup as KSP1 or is the team going for a 'Science over time' approach akin to Kerbalism?
Science mode is cool. It is designed to be a progression-based mode that takes the aspects of KSP1’s Science mode that we like and build upon them to create a solid progression experience that has higher level of agency and approachability. You can expect the return of the experiment loop, with changes, and the inclusion of a very different mission paradigm from Career. One of the fiddlier aspects of the last few months has been taking our full set of concepts from KSP2 1.0 and figuring out how they break down into the early access structure.
The system as designed is independent from things like Kerbalism, but you could say there’s some concepts that aren’t dissimilar in there. It has been a while since I have played with that mod though. We definitely want to get to more player agency in Science. Instead of it effectively being mandatory to hide four tiny science experiments on every craft you send anywhere, we want you to make a more informed decision about what you take with you, and make the actions you take a bit more specific too. I should write a little dev blog on this.
In terms of Career mode, is there a more dynamic contract system in place rather than the 'rinse and repeat' system of KSP1? Is there still going to be funding or reputation?
I believe we are on record about not using the same framework there. Funding and reputation weren’t our favorite systems and didn’t have the gameplay impact we wanted.
As a side question, stations and bases. Are these going to have real use this time around, given that stations were limited to more or less fuel depots in KSP1? I'm thinking more along the lines of long term research projects, with big pay-off for significant durations of time. Is there some sort of requirement to resupply the stations, perhaps required crew rotation?
The progression we want to deliver for bases and stations mirrors IRL conceptions about how these things should work. You will start out with outposts that have limited utility – let’s call that KSP1-like. Fuel depots, maybe comms relays, etc. As you progress through the tech tree, you’ll get access to stuff that provides them with greater utility. That’s shipyards and docks, fuel factories, launch pads, etc. Eventually you’ll get the biggest parts, which are mostly focused on giving you the full capabilities of the KSC at a colony.
A core piece of the utility in my mind comes with resource gathering (which is a ways off in the roadmap,) when the specific positioning and configuration of a colony becomes really important. Placing a colony with good access to progression-related resources and having easy access to heat management/power sources will allow you to build specific functions and cool vibes into each colony.
Crew rotations and resupply are not currently something we would want to enforce. I hope that when we get resources and delivery routes fully operational though, that this is something modders will hit really hard because the framework of stuff like delivery routes will be there.
[h5]Superfluous J[/h5]
Having done both, what are the main differences between adding a part/set of parts to the game as a modder versus a paid member of the team?
Accountability and justification are big. It’s easy enough to incept a new part as a generalist modder. I just say that I want it and make the time to model/integrate/QA it myself. In a professional context, that involves the use of studio resources and we have to balance that versus other work we want the staff that would be executing that work to do. A new part needs a concept, it needs artist time, it needs designer time, and it needs QA time. We have to really be sure we want a part before we do it.
[h5]Heretic391[/h5]
What steps are the development team taking to make KSP2 accessible and appealing to new players who may not have played the previous game or are new to the genre?
The tutorialization we worked into EA will continue as we add new systems. Eventually though, we want to enable players to do more with the same skill level. There’s some really big difficulty jumps in the game, and while we are more confident in the ‘get into orbit’ jump, we still need tools and strategies to tackle the next one, which I’d peg as going to another planet. After that, go to another solar system. I saw a really cool concept from the UX team about this last week which made me squeal in happiness. I hope we get to it.
[h5]VlonaldKerman[/h5]
Can you give some more detail on the supply route system? Can you automate the construction of supply vessels, or does a vessel have to be built to assign an automated route to it? In other words, when the route is finished, does the vessel have to be intact?
That system is still a while out and while I think our concepts are pretty solid, they have to survive another round of detailed design, and the EA feedback we get during that period. So let's save that for a dev diary later.
Intactness is an interesting thing that the system does need to consider. On the one hand, we obviously want you to not crash your ship to create a delivery route. However, we also don’t want to disallow multi-stage approaches to routes. You should be able to create a delivery route with a two-stage rocket. It won’t be as resource effective as a single stage one, but particularly for routes that launch from high G or atmospheric planets, we need to have a design that eventually supports this. It is possible that this could be delivered in phases for effective development – consider a V1 of routes that focuses on single-stage-to-place deliveries and a V2 that is more comprehensive.
Will metal to build rockets and methalox fuel be limited in the early game, or will there be infinite fuel on Kerbin? If so, how is this balanced against the ability to send an arbitrary number of refueling ships to a colony, as opposed to ISRU?
If you want to create an interstellar empire based on shipping methalox light years from Kerbin, I don’t want to discourage that. That’s kinda cool and would be a big investment in player time and resources, so we would reward that by not constraining it. You’re also probably not going interstellar on methalox…so you are going to be incentivized to not do that in a particular way.
[h5]piotr[/h5]
What real life concepts/scientific work gave you the most headache? Is there something you're really proud of, that your creations will introduce to players?
Heat and radiation are the hardest concepts to map to gameplay, so I’ll say those. Every time we get a system that is showing a new scientific or engineering reality I get excited. Example - with 0.1.3’s new extensible engines, we’re showing the community that doesn’t follow aerospace precisely than extending engines exist and are useful in some ways.
[h5]sylvifisthaug[/h5]
So someone in the KSP2_general channel on Discord pointed out that the "brass line" vacuum engines in KSP2 have some resemblance to your previous modded content. How is the process like with implementing these similar designs to the game? Do you do it entirely yourself?

I do very little of those things. Effectively, I:
Try to incept the concept and discuss its utility with the rest of the team
Make sure we can support it with the engineering that has been done (there's a whole side thread about when we need to ask for new gameplay functions)
Make concept models and hand them off to the art team
Coordinate other things we may need for the model like VFX, SFX, and animations
Regroup and do the final integration into the game, and further tuning later on
As a team manager if you're delegating others to recreate your parts, how does it feel to let others rummage with engines you've made?
To be clear, we're not recreating parts - when things are similar, there's often convergent evolution. But our art team is equal to the task!
Keep up with all things Kerbal Space Program 🚀
KSP Forums
KSP Website
Facebook
Twitter
Instagram
Intercept Games Discord
KSP YouTube

Aug 30, 2023

v0.1.4.0 Patch Notes

Kerbal Space Program 2 - mikey

🚀 <-- This rocket denotes a fix that community members directly helped our dev team fix. Thanks to all of you who send in bug reports!

Bug Fixes

Flight & Map

Added input binding for toggling freecam in flight
Added NavBall texture color changes based on velocity state
🚀 Improved orbits decaying when vessels are not applying any thrust https://forum.kerbalspaceprogram.com/topic/212388-appe-are-dropping-orbital-decay-when-in-low-orbit-of-some-planetsmoons/
🚀 Fixed: Airbrakes respond to roll inputs https://forum.kerbalspaceprogram.com/topic/217891-airbrakes-deploy-when-performing-roll/
🚀 Fixed: Camera orientation flips 180 degrees after switching to flight from map https://forum.kerbalspaceprogram.com/topic/217818-camera-resets-position-every-time-you-enter-and-exit-map-view/
🚀 Fixed: Normal SAS orientation maneuver burn at periapsis is inaccurate https://forum.kerbalspaceprogram.com/topic/216619-incorrect-maneuver-on-inclination-change-normal-and-anti-normal/
🚀 Fixed: Kerbals eject with extra velocity when EVA'd from Grumble Seats while in space flight https://forum.kerbalspaceprogram.com/topic/217883-kerbals-still-flung-at-high-speeds-when-going-eva-in-space/#comment-4297898
Fixed: Dates don't start on Year 1 Day 1
Fixed: Activate/deactivate action button for engines gets out of sync
Fixed: Alternators produce power when engines are off
Fixed: Animated engine gimbal forces are incorrect after reverting
Fixed: Animated gimbals don't function when offscreen (when in map or offscreen during flight)
Fixed: AP and PE markers of inactive vehicle in orbit stay on screen after switching focus to a landed vehicle within the Tracking Station
Fixed: Action vessel can be controlled while in the Tracking Station
Fixed: Camera zooms in and out when scrolling in some flight apps
Fixed: Cargo bay aero shielding sometimes leaves contained parts out of collider checks
Fixed: Errors generated when launching a vessel with a fairing
Fixed: Hibernate in timewarp doesn't work properly for probes
Fixed: Mouse look does not stay active when pressing Tab in flight
Fixed: Probe cores stop consuming electricity after being decoupled
Fixed: RCS blocks don't work in fine control mode
Fixed: RCS thrusters remain on when switching away from a vessel
Fixed: SAS and throttle sometimes reset when decoupling stages
Fixed: SAS mode buttons do not always register clicks
Fixed: Timewarp overshoots when crossing SOI boundary, causing orbit to change

Optimizations

Added LODs to some KSC buildings
Added LODs to spotlight shadows at KSC
Cleaned up code and UI to improve performance of some windows
Improved performance when hovering over items in the parts picker UI
Improved UI performance when adding or removing stages in the VAB
Improved VAB framerate by optimizing part bounds calculations
Massively improved speed of PAM deployment/closure
Optimized code in the sonic boom system preventing unnecessary calls
Optimized terrain shader by removing expensive and infrequently-used features
Optimized undo and redo actions in the VAB to reduce update delays

Saving & Loading

Fixed: Error generated and failure to load when attempting to load a game with a crash-landed vessel
Fixed: Error spam while loading a game with a vessel orbiting Kerbol

Parts & Stock Vessels

Adjusted colliders for all landing gear parts so they are more accurately selectable/highlightable
Fixed: LY-60 landing gear sometimes flips when extended
Fixed: Rovemax M1 twitches back and forth at the suspension when off the ground in flight
Increased fairing maximum length for AE-FF000, AE-FF125, AE-FF250, AE-FF375, and AE-FF500 parts
Updated drag cube for the HS-I Deluxe Inflatable Heat Shield so that it properly changes when deployed and retracted
Updated the side count of the RF-AD-L 800 fuel tank to better match like-sized parts
Updated the side count of the RS-AD 800 fuel tank to better match like-sized parts

UI / UX

🚀 Fixed: Flight UI flickers when using an AMD GPU https://forum.kerbalspaceprogram.com/topic/217867-graphical-glitches-on-amd/
Adjusted interactable area on scrollbars
Improved how loading tips are displayed to show more of them
Updated fairing editor icons to improve legibility
Fixed: HUD issue that occurred when scaled to 50%
Fixed: Holding click and dragging some buttons can cause the wrong visual state to display
Fixed: Only one celestial body name can be pinned at a time in the Tracking Station
Fixed: Part description does not expand when pressing Shift in the part picker
Fixed: Save window in the VAB can be dragged horizontally
Fixed: Tracking Station load screen remains visible when transitioning from Training Center

Construction

🚀 Fixed: Center of Thrust, Center of Mass, and Center of Pressure markers appear when there's no vessel in the VAB https://forum.kerbalspaceprogram.com/topic/216597-centre-of-massthrustpressure-vectors-sitting-on-the-vab-floor/
🚀 Fixed: The player is unable to change symmetry modes while holding the first part of a strut or fuel line. It is now only locked when holding the second part. https://forum.kerbalspaceprogram.com/topic/217953-cannot-change-symmetry-while-holding-a-strut/
🚀 Fixed: When Alt-copying a subassembly with wings, the copy has one of the wings flipped upside down https://forum.kerbalspaceprogram.com/topic/217851-plane-wings-invert-on-copy-paste/
Fixed: Camera panning orientation does not update when toggling vehicle orientation modes in the VAB
Fixed: Engine shrouds are generated incorrectly when stack attaching a non-root engine above other parts
Fixed: Current anchor point and potential anchor points are not differentiated in the VAB
Fixed: Fuel bar is sometimes empty when loading a vessel in the VAB
Fixed: Undo removes the held part
Fixed: VAB and anchor points appear when they should not
Fixed: Parts Manager shows the pod icon for all categories
Reduced delay for disappearance of fairing and wing edit buttons when cursor has moved away from procedural part
Fixed: New workspace not resetting history snapshots for the Undo tool
Removed duplicate history snapshots for the Undo tool for compound parts
Fixed: Part of the LY-35 Landing Gear shakes uncontrollably when placed in the VAB
Fixed: Base size of TOOB-375 adjustable tube causes stacked tubes below to generate the wrong size fairing in the VAB
Fixed: RF-AD-B 400 does not create a copy of the part when node attaching a part

EVA

Fixed: Jetpack cannot be used on previously EVA'd Kerbals when EVAing a new Kerbal

FX & Audio

Adjusted timing of voiceover when reaching a maneuver in the burn timer
Fixed: Audio stopping under some circumstances
Fixed: Sounds based on time of day do not play correctly at KSC
Fixed: Vessel audio is not heard when throttling or staging the vessel while in map mode

Tutorials

Fixed: First time user experience confuses map view for tracking station view
Fixed: The player loses keyboard and camera control when pausing and resuming a tutorial mission while in map mode in the Training Center
Fixed: Training Center shows artifacts in the background when transitioning from VAB
Fixed: Tutorial "Deorbiting" does not detect a crash event correctly

Localization

Integrated: Localized strings for save gameplay menu

Modding

Fixed: LoadByLabel not properly respecting assets in addressables in mod asset bundles. Labelled addressables should load properly now.

Known Issues

Orbital Decay: Improvements have been made to address the issue and we continue to work on eliminating it completely.

Performance Degradation: While we have seen improved performance in many ways as noted in the Optimizations section above, some players may see issues on GPU-bound setups while in orbit around Kerbin or on the surface of other planets. We are working to resolve this issue. If you see any changes in your performance, please fill out a bug report through the link below.

Submitting Bug Reports and Feedback

If you'd like to provide feedback about this build, there are many different ways to do so:
Submit Feedback through the Game Launcher
Suggest a Change on the KSP Forums
Join us on Discord to discuss potential changes

Bug reports should be shared to either:
Private Division Customer Support
Dedicated Bug Reports on the KSP Subforum

Jul 21, 2023

Developer Insights #21 - Rockets' Red Glare

Kerbal Space Program 2 - mikey

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're 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.

Diving 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.

[h5]Avoiding Meltdowns[/h5]
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. Credit: NASA

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 by using radiation with radiator parts in space, using the local atmosphere's convective abilities on a planet, or possibly 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.

[h5]Slightly Singed Landings[/h5]
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. Credit: NASA

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.

[h5]Exoplanets? More Like Exothermic Planets![/h5]
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. 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.

[h5]Smaller, Simpler Problems[/h5]
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'll 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!

[h5]Putting It Together[/h5]
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, 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 an 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.

[h5]Determinism vs Simulation[/h5]
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 usable 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.

Alternatively, 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.

For 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.

[h5]What's Changed[/h5]
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 50,000 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 flux from things going on in a part, like heat radiators and other heat sinks
Positive flux form 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 an orbital context, with a part.

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 engine is firing and 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 it 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.

[h5]Timewarp and Loading[/h5]
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.

[h5]Planning for Success[/h5]
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 to 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’ve enjoyed writing it.

Jun 30, 2023

Hot Fix Summer

Kerbal Space Program 2 - mikey

Good afternoon, intrepid Kerbonauts!

Lots of stuff to talk about today! As many of you know, a couple of new bugs were introduced with last week’s v0.1.3.0 patch. The most significant of these bugs relates to a loss of atmospheric drag (and physics in general) when capsules are decoupled. For the first time ever, we issued a hotfix to correct that issue yesterday morning.

Yesterday's v0.1.3.1 hotfix also contained a fix for a VAB bug in which fairing editor UI elements were drawing on top of one another.

We discovered after yesterday’s hotfix that people were unable to launch the game outside of the Private Division launcher. This was not intentional, and has been fixed — due to a configuration error on our end, we accidentally included Steam’s built-in DRM. KSP2 is DRM-free, just like KSP1. The fixed update was pushed to Steam this morning. Sorry for the headache!

We’re testing a second hotfix (timing TBD) that corrects the blurry navball issue. And because we’re sneaky little devils, we’re also doing some testing around a fix for the SOI transition trajectory bug. If these fixes prove stable and low-risk, we’ll release a second hotfix. Fingers crossed! The work that’s gone into the SOI transition issue — number 2 on our top-ten most wanted bugs list — deserves a special mention. Engineers David Tregoning, Mark Jones, and Shalma Wegsman put in colossal efforts to both track down the cause of the issue and to craft a solution. This one has been a long time coming, and it’s great to be able to knock such a big item off the list.

The credit for the fast turnaround on all the latest fixes goes to a well-coordinated joint effort between engineers, production, and QA. We’re still learning as we go, but things are feeling good.

Bugs: The Next Generation

Based on the Bug Reports subforum, these are the community's 10 most-upvoted bugs:

Orbital Decay [25 votes]
Incorrect Maneuver on Inclination Change [10 votes]
Cannot Change Craft/Vessel Name in Tracking Station [9 votes]
AIRBRAKES Deploying on Roll [9 votes]
Camera Resets Position Map View [8 votes]
Graphic Glitches on AMD [8 votes]
Engine Sound Effects Not Playing [7 votes]
Cannot Change Symmetry While Holding Strut [7 votes]
Center of Mass/Thrust/Pressure Vectors Sitting on VAB Floor [6 votes]
UI Artifacting [6 votes]

Note: Navball Blurry [18 votes] and SOI Trajectory Line Issues [18 votes] have been left out of the above list since we're considering them for the second hotfix.

Thank you to everyone who took the time to submit bugs in the subforum. Even if you don’t have a new issue to report, your upvotes help us determine the relative priority of the bugs that have already been posted. While we investigate the bugs above, two other non-feature items also feature in our top ten:

Rockets are still too wobbly
SAS causes runaway pitch oscillation for aircraft in flight

Lots to do! Thanks again for submitting such detailed and well-documented bug reports. It's going to be a busy month!

AMA with Kristina Ness, Art Director

Did you catch our AMA with our Art Director yesterday? Kristina was asked a lot of interesting questions, many of which ranged well beyond the art domain. She gave fantastic and detailed answers! If you missed the stream, it's definitely worth watching on YouTube! With the help of streaming wizard Dakota, she even got to show off some visuals as well! You can find a transcript of the AMA here as well. Thanks, Ness!
https://www.youtube.com/watch?v=GTFcLtqtdfI

KSP2 Steam Sale

This is the second week that KSP2 is on sale for 20% off, which ends on July 13th at 1pm ET. If you've got any friends who you think might enjoy the last bit of heat-free reentry during Early Access, now's a great time to tell them about the sale!

Weekly Challenge

Last week’s Jool 5 challenge produced some of the coolest, most ambitious craft designs we’ve seen in KSP2. Check out this absolute unit from DarlesChickens:

Or this beauty from Razorback:

And here’s a unique one from Tr1gonometry:

We know that in the Wobbly Rocket Era, missions of this kind can be extra challenging. Kudos to everybody who braved the bugs and slipped the surly bonds of Kerbin regardless!

This week’s challenge? You’re putting on an air show! Build a maneuverable stunt plane and show off your fancy flying skills. Buzz the tower! Under the bridge! Do some barrel rolls! To get specific:

🏆 Primary Goal: Fly an inside loop, an Immelmann turn, and a split-s turn.
🏆 Secondary Goal: Fly an outside loop, a barrel roll, and a hammerhead stall turn.
🏆 Jeb Level Goal: : Fly under the R&D bridge as fast as you can.
🏆 Val Level Goal: Fly through the parking garage bridges (from the water), under the R&D bridge, then back through the parking bridges as fast as you can.
🏆 Tim C Level Goal: Fly a loop around the R&D bridge so that you pass under it twice in one maneuver.

Don’t forget to wear your G-suit — you’re about generate some wing loads that’ll make your crew chief very grumpy! While your screenshots are always welcome, video capture will be the best way to show off your maneuvering prowess. Good luck!

Summer Changes

Now that Summer's here, with all its vacation-related comings and goings, I'll be letting other parts of our team takeover these posts. In the coming month, you'll still see the following here:

Bug report updates
More AMAs
Challenges

In addition, we'll be uploading more gameplay clips to our social channels.

We've got a lot of good momentum coming off the last update and we're already making great headway on the next one. Looking forward to sharing our progress with you soon!

Keep up with all things Kerbal Space Program 🚀
KSP Forums
KSP Website
Facebook
Twitter
Instagram
Intercept Games Discord
KSP YouTube