Nate Simpson
-
Posts
182 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Patch Notes
Bug Reports
Posts posted by Nate Simpson
-
-
9 minutes ago, cocoscacao said:
Just out of curiosity, why bother with short-term solution if it's gonna end up in the trash can eventually, but consume so much effort and time?
This is a great question. We're aware that the people who have chosen to play the game in Early Access have done so because they want to have fun (while participating in the evolution of the game). There continue to be some bugs that are active obstacles to fun - these are distinct from bugs related to polish, presentation, or ease of use. Fun-killing bugs have to go to the top of the pile. Thankfully, the process of settling on a joint rigidity solution isn't made all that much more difficult by running through the potential remedies and recognizing that one of the lower-cost choices could make the game more fun for people while the extensible, interstellar-friendly version is under construction.
-
In case people are wondering why I listed "wobbly rockets" as our current top bug and not "orbital decay," it's because a hotfix just went out (38 minutes ago) that not only fixes the recently-detected registry bug, but also addresses the orbital decay issue. It's a huge relief, both as a developer and a player, to have this finally squared away:
-
17 minutes ago, ChrisShourai said:
@Nate Simpson do you have even a remote idea when either a temp or the long term fix might be realized?
I have a very strong idea when the short-term fix is likely to materialize, but the complexity of this game has a way of turning "low-risk" predictions into misstatements. To my eyes, it feels very close. But there are always questions that can only be answered by testing (which for a game like this can take time). Does it work in all situations? Does it introduce new bugs? Does it break a seemingly unrelated system in a hard-to-detect way? I'm reminded of how the joint reinforcement technique we introduced for a narrow subset of parts created an initially subtle but ultimately game-breaking fuel flow bug that flew under the radar for weeks.
What I can say, without fear of misrepresenting things, is that it's a priority task for our most senior developers, and it is internally our most-wanted fix right now. We released this video to underscore that it's a priority for us and that we're approaching the problem with the nuance and openness that it deserves. Our goal here, given requests we've seen here for greater transparency, was to provide more visibility into the way we navigate the sometimes complicated terrain of requirements presented by this game.
-
I hope you enjoyed this chat! Since this conversation took place, David has been developing a tool that allows our team to compare multiple wobbly rocket remedies, including selective wobbliness for certain part categories, KSP1-style autostrut for the entire vehicle, and various flavors of packed vehicle physics. We are testing these now, with the goal of achieving a near-term improvement in vehicle rigidity while developing a more ambitious long-term fix that's performant at all scales. We'll post more information when we've arrived at a balanced solution.
We know you've waited a long time for a solution to this issue, and we're excited to be closing in on a resolution.
-
1 hour ago, NoNameWonder said:
Why is no one talking about the large wings? The control surfaces have been like a teeter tot since launch but I haven’t seen ANYONE talking about them?
I think you may be referring to the same phenomenon listed in the original post as "SAS causes runaway pitch oscillation for aircraft in flight." SAS does not currently like to provide incremental control surface commands - it's very all or nothing right now, which leads to the up-down seesawing. It's bad enough that I don't really even attempt SAS when I'm flying aircraft these days. It's a high-priority issue for us.
-
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!
Art Director Kristina Ness AMA
Did you catch our Art Director’s AMA yesterday? She was asked lots of interesting questions, many of which ranged well beyond the domain of art. She gave fantastic and detailed answers, and if you missed the stream, it’s definitely worth watching here. 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!
KSP2 Steam Sale
This is the second week of Private Division’s 20% off sale for KSP2, which ends on July 13th. If you’ve got any friends who you think might enjoy the last little 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 under the parking garage bridges (from the water), under the R&D bridge, and then back through the parking bridges
- Tim C-level goal: Fly a loop arouund 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 handle forum posting for a while. In the coming month, you’ll still see the following on the forums:
- Bug report updates
- More AMAs
- Challenges
In addition, we’ll be uploading more gameplay clips to our social channels.
I’ll still be lurking both here and on Discord, so you’ll see me in the comments from time to time. We’ve got a lot of good momentum coming off the last update and we’re already making great headway on the next one. I’m looking forward to sharing our progress with you soon.
-
We believe this issue is fixed in the v0.1.3.0 release build. Please let us know if any of you are still experiencing this problem. Thanks!
Edit: Sounds like maybe this was premature. Still gathering data.
-
I am following up on this one today - my best theory is that we accidentally failed to exempt this texture from some MIP compression script. Will update when confirmed.
-
Thanks to Community Member @Kavaeric for making this banner
Happy day-after-update, fellow Kerbonauts!
Many of you have had a few hours to experience the v0.1.3.0 update, and hopefully you have found the gameplay experience improved! Many players are reporting significantly better framerates, but there are more than just performance gains on the menu. Among the new fixes and features we’re most excited about for this update:
- New parts, including three new engines, new docking ports, and the A.I.R.B.R.A.K.E.
- The Flight HUD UI is now rescalable via player settings
- Several decoupling-related flight bugs have been resolved
- We knocked out several of the vehicle-falls-through-terrain bugs
- We nailed that really annoying VAB bug that kept you from putting down procedural parts after picking them up
- We strengthened wing attachments with a new automatic multi-joint system
- We fixed the asymmetrical separation forces on radial decouplers, restoring the beauty of booster separations
There are many other fixes, big and small. Take a look at our patch notes to get the full rundown.
What's Next
This update represents an incremental step in the ongoing Early Access process of addressing game-breaking bugs while moving toward our first Roadmap update, which will add Science collection, a new Mission system, and parts progression to the game. We still have quite a few game-breaking bugs at the moment, as well as aspects of gameplay that still need refinement (wobbly rockets, overactive control surfaces, strange SAS behavior). We will be posting our new top-ten most wanted bugs next week (three of which will be carrying over from our previous top-ten list). If you’re playing the latest update and you come across a bug that you’d like to report, please do so via the Bug Reports subforum; you can upvote existing reports, or if your issue isn't listed, you can submit a new report through the form. We will be following those threads very closely to track which issues are most important to the community as a whole.We are aware that one of the decoupling fixes in this update has introduced a new issue that breaks aerodynamic drag after a decoupling action. Thanks to early reports from the community, we have been able to reproduce the bug and are working on a fix. If the fix proves stable and low risk, we will consider releasing a hot fix in a few days.
Some players have also correctly noted that the orbital decay and SOI transit trajectory bugs are still present in v0.1.3.0 - while we had high hopes for an eleventh-hour breakthrough, neither fix made it across the finish line in time. In the days after code lock, a new fix for the SOI transit issue was submitted and is being tested. Our engineers have also isolated the orbit decay issue and believe they have a good remedy on deck. With updates, there’s always the temptation to hold the build just a couple more days to sneak in additional fixes (which we actually did this week). Alas, at some point the train has to leave the station, but it’s at least comforting to know that these issues will be addressed in an upcoming update. We appreciate your patience, and we hope that the changes that did make it into this week’s update have improved the game for you.
Other questions that we’ve been asked:
- Where’s reentry and heating? - We are working hard on both. We expect reentry VFX to arrive earlier than thermal systems and heat-related part destruction, so there may be a short phase during which reentering vehicles look like they’re being heated, but really aren’t. We don’t want to reverse any of our recent framerate gains, so we’re taking the time needed to make sure reentry is both awesome-looking and performant. To give you better visibility into the work taking place in this area, we will be posting a new dev blog about the heat system soon
- What’s going to be in v0.1.4.0? - As we continue to work through our critical bugs list, those that are fixed by the next update will be included. We are still targeting foundational bugs and playability issues. As we work down through the list, we’ll report on our progress.
- When is the Science update? - The first of the headline Roadmap updates - which will add Science, Missions, and an R+D Center, is still several months away. A lot of work is going into the "Dot Two" update — deep architecture work, bugfixing, new systems, and a lot of new content. We will continue to release incremental updates until that time, with the goal of eliminating the major game-breaking bugs prior to v0.2.0.0. We’ll provide a release date for that version as soon as we can
Steam Sale
With summer upon us, Private Division is holding a 20% off sale for the Steam Version of KSP2. The sale ends on July 13th. If you’ve got a friend who has an interest in participating in Early Access, now is a great time to hop on board!
Upcoming AMA
On Thursday, June 29 at 10am PST, our art director Kristina Ness will be fielding your questions about KSP2, and this is a rare opportunity to get detailed answers about the game’s art! You can submit questions for her via Discord, Steam, or the KSP2 forums.
Weekly Challenge
Last week’s "Score a Goal" Challenge was extra challenging, but those who conquered it created some very original vehicles!First, there’s this submission from Miss, which deserves special mention as it’s the only attempt that involves not only a ball, but a rocket-powered foot!
Squidplaz did some reaction wheel magic to get a ball under the R+D Center bridge:
User @pyasupro posted this beauty on Twitter, and made goals on both the Mun and Moho:
Klapaucious made two glorious attempts, and both deserve a mention. First, the gigantic gumball ramp:
Then he deactivated his targeting computer and hit the bullseye from the air:
And finally, Mottl did... I don’t know what Mottl did, actually. How did this one end up going, Mottl?
This week’s challenge: we’re going to Jool! Here are the deets:
- Primary goal: Launch a single-Kerbaled mission (only 1 spacecraft may depart Kerbin's SOI, but it can be built in Kerbin orbit) that passes through the SOI of all 5 of Jool's moons at least once before returning to Kerbin
- Secondary goal: Same as primary, but land a probe on each of Jool's moons (the probes don't have to return)
- Jeb-level goal: Same as secondary, but plant flags on Bop and Pol
- Val-level goal: Plant flags on all 5 moons of Jool in one mission before returning safely to Kerbin
Have a great weekend, everybody!
-
12 minutes ago, The Space Peacock said:
Sorry for the ted talk, this got a bit out of hand! This is the first time i've shared so much feedback under a dev post, so i hope i've done so in a respectful and comprehensive way. I did this because i really feel strongly about these features in particular and believe i am somewhat qualified to share my opinion on them. I truly believe that if even some of this advice is taken to heart, it could lead to a better science mode especially than anyone could have ever expected. However you may choose to tackle these issues tho, i wish the teams the best of luck with them and can't wait to see what they come up with!!
Great comment. This is my favorite kind of feedback, thorough and well-argued.
-
1 hour ago, regex said:
I certainly hope interacting with this system is purely optional. While systems like this are fun sometimes, they're tedious at others, and I'd prefer to drive my own space program rather than have you guys dictate the direction it goes in order to get better replayability and challenge potential.
Thanks for the update.
It is entirely opt-in. You can just go and explore at your own discretion if you like, and you'll collect Science the same way that you did in KSP 1. The mission system just adds interesting additional goals for those who want them.
-
Credit to Kavaeric for this week’s update graphic remix
Good afternoon, fellow Kerbonauts.
The release date for the v0.1.3.0 update has been revised to June 22 (a two-day delay, from next Tuesday to next Thursday). We have a couple of critical bugs that we think will significantly affect the quality of the update, so we’re giving our team a couple of extra days to knock them out and test the changes.
As always, we will post detailed patch notes when the update goes live. The list of fixed items is significant for this one, but major bugs still remain (to give just one example, we still have not completed our fix for the orbital decay issue, which is number one on our priority list). Once the update is live, we will reset the the Bug Reports subforum for new report submissions and re-assess our internal priority list based on both community feedback and our own internal testing. On the following dev update, I’ll post our new top-ten most wanted list based on that information. In the interest of avoiding repetition, I will not re-post the current top-ten list here, as all relevant fixes will officially continue to be in QA review until the update goes live.
A Word About Wobbly Rockets
Our team shares the community view that overly-wobbly rockets are a major issue in KSP2 (it is number 10 on our top-ten issues list). We have introduced a number of mitigations to address aspects of that issue (altering inertia tensor values to decrease joint issues that emerge when high-mass and low-mass parts are connected, introducing various bespoke multi-joint augmentations to areas of known over-flexibility), but we still see this as an area where major improvement is needed. For the record, this is our official view on what a successful implementation would look like, and against which we continue to measure the effectiveness of ongoing mitigation work:
- For inline parts that are connected serially, in most applications there should be little to no flexing. This is especially true when neighboring inline parts are the same core size
- For radially-attached boosters or cantilevered subassemblies with single-point radial connections, some flexibility is expected. There are some applications for which manually-applied struts should be required
- Wings should not require struts to stay rigid
- Docking two vessels in orbit should result in a strong, non-wobbly connection that doesn’t fold on itself as soon as the player tries to move the resulting vehicle
- Wobbly rockets are sometimes fun and funny. A big part of what originally got many of us hooked on the original KSP was the silliness and emergent problem solving that came from playing World of Goo with rocket parts. Broadly, we see this as part of the Kerbal DNA, and want to preserve it in some form. Whether that means limiting wobbliness to certain types or sizes of parts, or relegating certain behaviors to player settings, is the subject of ongoing internal discussion. We of course are following community conversations with keen interest, and this is an area where Early Access participants can have a significant impact on the 1.0 version of KSP2
- Joint physics impact CPU performance, and as we progress through the Colony and Interstellar roadmap milestones the part counts will increase dramatically. Any solutions we arrive at for the above requirements must accommodate this reality
- We would like to move away from autostrut, or any other band-aid solution that involves hidden settings that automatically apply additional joints to make a vehicle more rigid. Whatever solution we arrive at, we’d like it to be predictable and transparent to all users. If over the course of Early Access we find that some form of autostrut is still necessary to allow the creation of ambitious vehicles, we’ll revisit this requirement
As a person who has dive-bombed more than one physics meeting with an exasperated "can’t we just make the joints stiffer" comment, let me assure you that in true KSP fashion, this is not a problem with a simple remedy. We’ve got very capable people on the case, and we will arrive at a good solution.
Ongoing Work for the Science Roadmap Update
As our architecture-facing teams chase down critical bugs, the content-focused feature teams have continued to work on features for the Science update, which will introduce the first major suite of new features to KSP2 since the beginning of Early Access. While we don’t have anything to share yet on timing, the following areas have seen significant progress:
- An all-new Science collection and transmission system, along with the assignment of Science biomes to all Kerbolar celestial bodies
- A new Mission system that provides compelling player goals and tracks flight events to determine the achievement of those goals, along with the activation of the Mission Control building to access those functions
- New Science parts that are distinctive enough from one another that they provide interesting vehicle design choices to the player
- An all-new tech tree that provides an interesting part progression that will later expand to accommodate the arrival of future interstellar-grade and colony parts
And of course, there are some new Kerbal animations for sample collection:
New Dev Blog
Yesterday, we posted a new dev blog entry from Senior Designer Chris Adderley that goes into some detail on the aero occlusion bug that we fixed this month. It’s a nice example of how certain bugs can not only be tricky to detect (it was in fact a community member who first identified the problem), but how bugs within interdependent systems can compound on one another in ways that make tracking them down especially complicated. It’s a cool detective story, and now that we’re through it, I’m glad that Chris has broken it all down for the rest of us.
Weekly Challenges
Last week’s Build a Base challenge generated some amazing results. Kerman_von_Braun’s achievement appears to have involved the use of a time machine, as it was submitted to YouTube a week before the challenge was announced! But it’s so great, I have to give it a shout-out anyway:
And then there’s Banana Base, by Suppise (some kind of signal noise appears to be corrupting some of these images - we’ll ask somebody to look into it):
We also really liked this Duna tower and rover by Hammo1603:
There’s also a recent trend of players recreating the Challenge banner art drawn by Matthew Poppe. For the record, I think Matt has really been enjoying this. Look at this one from Jaypeg:
Congratulations to all the other people who conquered this one! We can only post a few here, but we enjoyed all of the creations posted to the Build a Base thread.
This week’s challenge: Score a Goal! That’s right, those big spherical hydrogen tanks are about to be kicked, dunked, and spiked across the Kerbolar system! There will be extra (imaginary) points for style:
- Primary gooooooooooal: Use a crewed vehicle to roll an uncontrolled spherical hydrogen tank under the KSC bridge
- Secondary goooooooooooooooal: Deliver a spherical hydrogen tank to the surface of the Mun and knock it through a Mun arch
- Jeb-level goooooooooooooooooooooal: Roll a spherical hydrogen tank into the Mohole on Moho
- Val-level goooooooooooooooooooooooooooooooooooooal: After scoring the goal on Moho, dunk a second hydrogen tank from the same vehicle into the center of the KSC communications dish
We are counting on you to perform some ludicrous displays. We don’t want to see anybody walk it in.
Cheers!
-
17 minutes ago, RocketRockington said:
You have to remember that virtually everything Nate has said or written except very close to an actual release has turned out to be a huge upsell. He's marketting when he speaks to us.
It is my job, both within the team and outwardly to the public, to create and communicate goals. Another one of my jobs is to look at the current state of the game and talk about where we stand with respect to those goals. Those goals have not changed.
We have shown footage and screenshots of as-yet unfinished features for years. That is a part of the goal setting and communication process. Have I sometimes thought we were closer to the finish line than we really were? That's a matter of public record.
Given that I'm both a fan of KSP and an enthusiastic person, I often can't wait to share a cool thing I've experienced with other fans. Is that marketing? If "marketing" means "misrepresenting for profit," I don't think it is. Is it unwise to show off something before it has reached a shippable level of polish? Sometimes it might be, but when I think back to how much I enjoyed hearing about upcoming features back in the HarvesteR days, it's hard not to err on the side of oversharing. It is very nice to be the bearer of good news.
As I've mentioned here before, the parts and environment art teams are always ahead of the other teams, just by virtue of how the pipeline works. That means that some updates will include new parts. This is not meant to obscure any uncomfortable realities. Those who have the expertise to fix trajectory or decoupling bugs are fully devoted to fixing them. Those who have the ability to design and implement parts are putting their hearts and souls into that work.
One thing I do not have direct control over is velocity. Our team has learned quite a lot over the years, and I think both our production processes and our ability to communicate with one another have improved tremendously. But it is a learning process, as you've seen from the evolution of these forum posts.
I understand that the community would like all of these planned features to arrive as soon as possible. Everyone on this team is doing everything they can to improve efficiency so that we're able to take the most direct path to those big roadmap goals. But we also are learning to measure twice and cut once, to reduce tech debt, to improve our testing protocols, and to improve communication between feature teams - all with the goal of making sure that when those roadmap features go live, that they are stable and performant.
The goals remain the same, and the thing that keeps me going is the thought of one day driving a resource collection rover out of a colony VAB on an extrakerbolar planet. On the day I finally do this, I'll probably sublimate into a gas, my work on this planet finally having been completed.
-
2 minutes ago, RocketRockington said:
This fix seems like it's only going to address the wings falling off in one direction - from drag - rather than helping with forces in the dorsal/ventral direction.
This is by design: we are not trying to create a system in which wings never fail. We just don't want them to fall off inexplicably. Please take the new system for a spin and let us know if you think it's still producing frustrating results!
-
2 minutes ago, Acid_Burn9 said:
But what if a collision with another object happens? A stage separation? A vehicle being affected by an exhaust of another vessel?
I really hope the system in question here is not as primitive as described.Excellent question. Actually, there is an analogous system in KSP1 that works similarly. Off the top of my head, I don't know how it handles decoupling or other non-propulsive physics events. This may require a scalable solution that can be expanded to include edge cases (for example, the effects of stage separation), but the current effects of which are so profoundly game-impacting that a simpler approach gets us to more stable footing sooner. My short-term goal for this feature is KSP parity. That said, I'll bring up your concerns the next time I chat about this with an engineer.
-
This is beautiful work! I really love the clarity of the arrow-in and arrow-out SOI transits. This would be great material to keep in the backs of our minds the next time we're contemplating a UI update. Cheers!
-
Hello, fellow Kerbonauts.
The Intercept Games office is buzzing with activity as we submit our last check-ins for the upcoming v0.1.3.0 update and QA puts all the changes through their paces. We’re currently aiming for a June 20 update, but as usual I’ll hedge a bit by pointing out that QA always makes the final determination about whether the final build is release-ready. As we near that date, we should have more confidence about release timing, as well as more details about exactly what fixes and changes will be present in the update. As always, we’ll share detailed patch notes before the update goes live.
Bug Status
We have seen movement on most of the items in our top 10 list this week! It’s very exciting:-
Vehicles in stable coasting orbits sometimes experience orbit instability/decay
-
Status: fix in progress
We’ve figured out what’s going on here: when an orbiting vehicle is not under on-rails time warp, the effects of minor joint fluctuations within the vehicle rigidbody cause tiny but cumulatively significant changes to the vehicle’s velocity. The outcome of this is that orbital parameters can change due to all of this subtle wiggling. A system is now being crafted to prevent orbital velocity changes when a vehicle is not under thrust. This change will likely not make it into v0.1.3.0 update, but we know what’s wrong and the steps to fixing it are well understood.
-
Status: fix in progress
-
Trajectories change when vehicles cross SOI boundaries
-
Status: fix in progress
Engineers believe they understand the cause of this issue and are working on a comprehensive solution (at time of writing, there is a rumor that we've fixed this, but this news is so hot off the presses that I won't update the status quite yet. If it is in fact fixed, it will make its way into the 0.1.3.0 update)
-
Status: fix in progress
-
Certain inline parts cause aerodynamic drag numbers to spike
-
Status: fix being tested
Next week, Chris Adderley will be posting a dev blog entry describing the aero occlusion saga. It’s a doozy. The fix is in and being tested by QA. We believe it is solid for v0.1.3.0.
-
Status: fix being tested
-
Returning to craft from VAB causes craft to go underground (possibly related to Kerbals and landed vehicles dropping through terrain while being approached)
-
Status: multiple fixes being tested
This was actually two unrelated bugs, but happily we have submitted fixes for both of them and they’re both looking good for v0.1.3.0.
-
Status: multiple fixes being tested
-
Decoupling and/or undocking events result in various issues including loss of control, incorrect controllability of decoupled subassemblies, loss of camera focus, and other issues
-
Status: may have many causes, but some fixes in progress
This bug describes a nebulous family of bugs that have one thing in common: decoupling sometimes causes weird things to happen, and sometimes those weird things result in loss of control or other flight-killing outcomes. Our engineers have submitted six separate changes that address an array of decoupling-related issues, and they’re all being tested right now. These will be broken down in detail when we release patch notes for v0.1.3.0, but it’s a good bet that some edge case issues will still persist after the update. This is an area where public information submitted to the Bug Reports subforum can help shine a light on player stories that may be difficult for us to replicate internally.
-
Status: may have many causes, but some fixes in progress
-
Save files get bigger over time (TravelLog experiencing "landed" status spam)
-
Status: fix being tested
We are cautiously optimistic that a fix has eliminated the runaway filesize issue. It is being tested for inclusion in v0.1.3.0.
-
Status: fix being tested
-
Opening part manager causes major frame lag
-
Status: experiments ongoing
We’ve been working on this issue from different angles for quite a while, with varying results. Currently, engineer Patrick DeVarney is working on a method of invoking entries within the part manager on an as-needed basis, rather than always loading all part attributes simultaneously on PAM deployment. This fix will not make it into v0.1.3.0, but if the experiment bears fruit in the future it will have a significant impact on PAM deployment lag.
-
Status: experiments ongoing
-
Major post-liftoff frame rate lag immediately above launchpad (associated with engine exhaust lighting)
-
Status: fix being tested
As we said last week, the short-term remedy for this issue was to turn off shadow casting for point lights associated with engine exhaust. We’ll likely revisit this once we’ve got other performance-impacting issues sorted out.
-
Status: fix being tested
-
Root parts placed below decouplers cause issues with stage separation
-
Status: fix being tested
This is actually related to bug 5, and relates to engine plates being the root part. It has been fixed and is in QA review.
-
Status: fix being tested
-
Vehicle joints unusually wobbly, some part connections unusually weak
-
Status: under investigation, some fixes in progress
We are testing a fix for one of the most irksome manifestations of this issue, and I’ll elaborate below...
-
Status: under investigation, some fixes in progress
Wings be poppin'
One of the trending bugs on the Bug Reports subforum relates to wings spontaneously popping off of vehicles. This phenomenon is exacerbated by wings in KSP2 being large, unitary parts with a single connection point - a situation that was less problematic in KSP1, where wing stresses were spread out across a large number of parts and joints. You may have been aware that for some inline stack nodes, we automatically apply a trio of additional joints to increase the rigidity of the connection. Engineer Jamie Leighton has implemented a new system that applies a similar multi-joint reinforcement to wing roots, and does so in a way that is physically correct. Now, the surface attach node of a wing element is augmented by additional joints that are placed linearly along the wing’s root, and the distance between those joints is controlled by the length of the wing’s root. Check it out:
Magenta circles show the positions of wing root joint reinforcements
This fix is being tested and is slated for release in the v0.1.3.0 update.
There are lots of other bugs going down this week as we’ve entered the cherry-picking process going into the final stretch on v0.1.3.0. It's important to keep in mind that while we've been focusing on sharing our progress on top community issues in these dev updates, a lot of work has been done to solve a lot of lesser-known issues as well. We’ve fixed the issue with not being able to rename vehicles in the tracking station, for example. We also think we’ve knocked out an inertia tensor bug that was causing radial decouplers to eject with inconsistent force directions and magnitudes (and messing up our Korolev Crosses).
While we’ve knocked out quite a few big bugs over the past couple of months, there’s still plenty of work to do. We’re hoping that this upcoming update makes a big dent in some of the most frustrating issues you’ve been encountering, but we don’t intend to let up at all in our pursuit of the remaining bugs and performance issues standing in the way of a stable, reliably performant gameplay experience. Our bug-hunting momentum is good and morale is high.
Bug Reports Subforum
I mentioned last week that Dakota Callahan and the Community Team were continuing to add new functionality to the Bug Reports Subforum. You can now upvote issues that you have encountered, add additional information to existing bugs (especially handy to the devs when a bug is caused by a weird or complex edge case - for example, it’s already been instrumental in helping us to track down a VAB "not enough resources" issue), and see the list sorted by prevalence. This will give our team an up-to-date view of the community’s most requested fixes. After the v0.1.3.0 update goes out, our hope is that both we and the community can get a faster and clearer picture of community priorities via this subforum. Check it out and let us know what you think!
Weekly Challenge
Last week’s challenge produced some very clever Gilly landers dockers, and some very original low-gravity rovers.
How about this space dualie by Socraticrat?
Or this incredible lander by ChaddingtonDuck:
In addition to celebrating all the challenge-inspired community creations over the past week, we also posted a Player Highlight calling out Coriolis, one of our most prolific vehicle builders. We’ve been enjoying their creations for a long time, and we can’t wait to see what they come up with next!
Another Coriolis masterpiece
This week, we’re challenging you to make bases! Sure, you can land in a cool spot. But can you land other stuff near the same spot to make an off-planet village? We’ll have colonies one day, but that’s no reason not to do some early scouting for the best camping spots! Here are your goals:
- Primary goal: land a habitat that can hold at least 20 kerbals on the surface of the Mun or Minmus. It should have solar panels and at least one antenna
- Secondary goal: Near your initial habitat, land a pressurized rover that can hold at least 6 Kerbals, and land an observation tower that is as tall as possible (for scanning the horizon for interesting rocks from the comfort of a sofa or beanbag chair)
- Jeb-level goal: Use the same transport vehicle design (booster, transfer stages, sky crane, etc.) to deliver each of the above base elements
- Val-level goal: Build this base on a body outside Kerbin's sphere of influence.
- Tim C-level goal: Build this base within 1km of a unique point of interest (e.g. the mohole, Dres canyon, Vall crevasse, etc.)
Good luck, space campers!
P.S.: The title of this post is not my fault. Please blame our Art Director, Kristina Ness.
-
Vehicles in stable coasting orbits sometimes experience orbit instability/decay
-
Good afternoon, Kerbonauts.
This week, we’re working on many of the same bugs we were working on last week (one aspect of our increased transparency is likely to be that you get to share in the joy of waiting for the oven to go "ding"). We did see some encouraging movement on a few items, but I’ll keep the original ten bugs on the list until we’ve got bona fide QA sign-off on them.
Bug Status
For most of this list, investigation and/or testing is ongoing. Areas that saw significant change have been marked in bold:-
Vehicles in stable coasting orbits sometimes experience orbit instability/decay
- Status: possible fix in progress
- Trajectories change when vehicles cross SOI boundaries
- Certain inline parts cause aerodynamic drag numbers to spike
-
Returning to craft from VAB causes craft to go underground (possibly related to Kerbals and landed vehicles dropping through terrain while being approached)
- Status: possible fix being tested
-
Decoupling events result in various issues including loss of control, incorrect controllability of decoupled subassemblies, loss of camera focus, and other issues
- Status: may have many causes, but some fixes in progress
-
Save files get bigger over time (TravelLog experiencing "landed" status spam)
- Status: fix being tested
-
Opening part manager causes major frame lag
- Status: experiments ongoing
- Major post-liftoff frame rate lag immediately above launchpad (associated with engine exhaust lighting)
-
Root parts placed below decouplers cause issues with stage separation
- Status: under investigation
-
Vehicle joints unusually wobbly, some part connections unusually weak
- Status: under investigation
Issue 2 - Trajectories change when vehicles cross SOI boundaries
We have three engineers looking at this and we have already ferreted out a couple of issues - the introduction of axial tilt to KSP2 introduced some discrepancies, and our SOI transit handoff math had some inconsistencies as well. A few other issues surfaced in the simulation code, and we’re assessing both the impact of those issues and the scope of work required to correct them.Issue 3 - Certain inline parts cause aerodynamic drag numbers to spike
This bug is the one that saw the most movement this week. Our investigation of the spiking drag numbers revealed that we had a problem with drag occlusion — there is special code that reduces the frontal drag impact of a part that is blocked by another part, and in some cases we were seeing inline parts behave as though they weren’t shielded from airflow at all. In some cases, we were also seeing the opposite - wide parts that should have been creating drag were not having their frontal drag assessed at all. Of course, this latter case would rarely register as a problem, whereas the initial problem manifested in all sorts of unpleasant ways - essentially, parts positioned aft of other problem parts behaved like airbrakes, affecting both the overall drag and stability of the vehicle. Even weirder, these drag occlusion issues only arose when a vehicle was built horizontally!This problem has been corrected. In fact, it’s been SO corrected that after we fixed it, we started to get messages from QA that aircraft felt too fast! We checked the numbers, and they’re correct. We’re still testing this fix, but it’s looking very good for the upcoming update. The details of how this problem was analyzed and corrected would make a very interesting dev diary from Chris Adderley, if he ever gets a few moments to spare.
Issue 8 - Major post-liftoff frame rate lag immediately above launchpad (associated with engine exhaust lighting)
Quick clarification: engines had previously each spawned a point light that cast shadows. While this was very pretty, it wasn’t great for performance (and this impact was increasingly pronounced at high engine counts). We have turned off shadow casting for those lights and are seeing an improvement in framerate near the launchpad.Bug Reporting Progress
I also mentioned last week that we were exploring ways of communicating our current priorities more clearly, as well as giving members of the community more agency to communicate their own experiences and priorities to us. With that in mind, Dakota Callahan and the Community Team have begun to make some changes to the Suggestions and Development subforum. We’ll get into more detail about our specific implementation next week, but Dakota has already shown some of his work in that subforum - he’s taking several steps, including creating a new Bug Hunter member role, reformatting threads so that they can be up-/down-voted (this is just for bug threads), adding recommended tags/prefixes, and setting up a system that allows administrators to combine duplicate issues. This will start as a pilot program, and its success will hinge on how useful the community finds it and how maintainable our team finds it. The best possible outcome would be that players use the subforum to surface the issues they find most pressing, and our devs have the ability to ask directly for additional context. Again, I’ll provide more detail about this new structure when it’s fully in place, but in the meantime check out Dakota’s post - he’s got some great ideas!Engines
After posting footage of the three new deep space methalox engines that will be arriving in update v.0.1.3.0, we’ve been asked by a few people what those engines can really do. Our Lead Producer Nestor Gomez (of KSP1 fame) suggested that we share some stats in the time-honored old-school way - with cool blueprint-style graphics!
Without further ado, here are the three new engines (with special thanks to Matt Poppe, who continues to do amazing work on everything he touches):
I have run a few missions with these engines, and I can attest that they’ve opened up quite a few new capabilities - ones that will become invaluable when the R + D progression enters the picture and nuclear thermal engines are not yet in reach.
Community Highlights
Last week, we did a space station challenge! Several of your impressive submissions can be seen over on our recent Community Highlights post. Some of this stuff is just nuts.Check out this shot from <[I Flaze I]> on Discord:
Or how about this bad boy from HitchHacker:
I also really love this plane from spartandh211 (I’m a sucker for creative coloring tricks):
And then of course there’s a little sax-playing... cricket? From @The Space Peacock:
Be sure to check out that thread for even more fantastic creations. Thanks to all who submitted!
Weekly Challenge
This week’s challenge is technically about landing, though given Gilly’s low gravity, it might just as easily be called a docking challenge. Here are your goals:-
Primary goal:
Land onDock with Gilly - Secondary goal: Dock with Gilly, plant a flag, and return safely to Kerbin
- Jeb-level goal: With just a jetpack, de-orbit from above Gilly, dock with Gilly, plant a flag, and return to your orbiting spaceship, then return to Kerbin
- Val-level goal: As above, but capture into the Eve system by aerobraking
Share your submissions over here on the forums or over on Discord in #ksp2_challenges.
Good luck to you all, and see you next week!
-
Vehicles in stable coasting orbits sometimes experience orbit instability/decay
-
Good afternoon, Kerbonauts.
This past week has been a learning experience. My last post here received a lot of comments, many of which expressed doubt, frustration, and in some cases even anger about either the seeming lack of progress on KSP2 or the perception that I am concealing some dark reality about the state of the game. Our team has been reading your comments and asking one another if there’s some way we can do better.
In the past, every item in these forum posts has had to cross a threshold of certainty - I don’t want to announce some new feature or target date, only to experience a trust-eroding failure to follow through. I feel this burden especially keenly because in the past I have personally announced dates that turned out to be incorrect. For that reason, I have avoided talking about features in progress, bugs under investigation, or internal delivery deadlines. With a game this complex, nothing is ever assured until it has been thoroughly tested by QA. When you combine this "stay quiet until you’re absolutely sure" ethos with a more dispersed update cadence, what you get is long periods of silence.
Now, of course I haven’t gone literally silent. I still post here every week. Before each post goes out, I meet with the production and community teams to review the past week’s progress, and a great many exciting developments are discussed. They often take the form of "we’ve made great progress on x category of super annoying bug" or "this feature looks good but we haven’t had time to fully validate it yet." By my standard of "don’t talk about it until it’s truly done," neither of those scenarios yields anything that’s safe to post about. What is safe, then? Well, for the most part, content updates (new art, new parts, new graphics improvements) come along in nice, neat little parcels that are not only visually pleasing, but also unlikely to generate an unmet expectation. They’re fun and they’re safe, and artists are always creating new content. So you see lots of that.
But the other thing you see lots of is some variation on "improved stability and performance." That’s my catch-all term for that very meaningful category of progress that, because of my reluctance to write bad checks, can’t yet be talked about in detail. When I hold back on such items, I comfort myself that the less I reveal now, the more surprising the patch notes will be when we finally release them.
Still, I’m questioning my choice to withhold information about systems in progress. Yes, there’s always the chance that when we talk about a feature in development, that we’re also creating an expectation that the feature will be present in the next update. Similarly daunting is the possibility that we’ll announce that we’re working on something that the community perceives as "easy" (an especially common situation when we’re working on a feature that is already functional in the original KSP), and then take such a long time delivering that feature that people may decide we don’t know what we’re doing. In such cases, we then need to take the time to explain in technical detail why the implementation of such and such a feature is non-trivial in KSP2. Increased transparency carries costs, and those costs always have to be balanced against other feature-facing work we could be doing.
So what I’m going to try to do right now is to extend some trust to you. I’m going to talk about a few things that are not yet complete so that you can at least see some of the ropes we’re hauling on every day - some of which may prove to be long. This list is not exhaustive (there are dozens of people working on dozens of items simultaneously, and there are some features that we really do want to be surprises), but it will hopefully give you some visibility into the breadth of issues we’re tackling. Please do not assume that if a bug didn’t get mentioned in this list that it is unknown to us or not being worked on — this is a top-ten list.
Our bug prioritization is broadly guided by the following logic:
- Category A: any bug that causes loss of a vehicle in flight (physics issues, trajectory instability, decoupling instability, loss of camera focus, unexpected part breakage/RUD)
- Category B: any bug that affects the fidelity or continuity of a saved game (rigidbody degradation, save file inflation, loss of vehicle or Kerbal during instantiation or focus switching)
- Category C: any bug that negatively affects the expected performance of a vehicle (drag occlusion, staging issues, thrust asymmetry, joint wobbliness, landing leg bounciness)
- Category D: any VAB bug that prevents the player from creating the vehicle they want to make (symmetry bugs, fairing/wing editor bugs, strut instability, inconsistent root part behavior)
While there are many bugs that live outside these four categories (and in some cases, such bugs end up getting sorted out during normal feature development), the four categories above are the biggest fun killers. Until a player can envision a vehicle, create it without being impeded by VAB issues, fly it with a reasonable expectation that physical forces will be consistently applied, and save their progress at any point without worrying about the fidelity of that save, the KSP2 experience will be compromised. Obviously, now that we are layering in progression mechanics (Science gathering and transmission, missions, and R&D tech tree) in preparation for downstream Roadmap updates, the importance of addressing these issues only increases.
Therefore, here are a few of the biggest issues we’re wrangling with right now:
- Vehicles in stable coasting orbits sometimes experience orbit instability/decay - Status: possible fix in progress
- Trajectories change when vehicles cross SOI boundaries - Status: fix in progress (see below)
- Certain inline parts cause aerodynamic drag numbers to spike - Status: under investigation
- Returning to craft from VAB causes craft to go underground (possibly related to Kerbals and landed vehicles dropping through terrain while being approached) - Status: possible fix being tested
- Decoupling events result in various issues including loss of control, incorrect controllability of decoupled subassemblies, loss of camera focus, and other issues - Status: may have many causes, but some fixes in progress (see below)
- Save files get bigger over time (TravelLog experiencing "landed" status spam) - Status: fix being tested
- Opening part manager causes major frame lag - Status: experiments ongoing
- Major post-liftoff frame rate lag immediately above launchpad (associated with engine exhaust lighting) - Status: fix being tested
- Root parts placed below decouplers cause issues with stage separation - Status: under investigation
- Vehicle joints unusually wobbly, some part connections unusually weak - Status: under investigation
We’re tracking down some strange vehicle behaviors associated with spurious autostrut errors. As we’ve discussed here before, some radially-attached parts are reinforced by additional invisible autostruts to improve their stability. It turns out that these autostruts don’t always break cleanly during decoupling events, and may be the cause of some of our more frustrating decoupling issues (including those where detached vehicle elements appear to still affect one another’s behavior). We’re still investigating this one, but we have high hopes that its correction will result in a reduction of mission-killing errors.
Finally, we have zeroed in on the cause of some of the trajectory errors we’ve been seeing - especially the situation in which a trajectory changes spontaneously when crossing an SOI boundary. This one is deep in the code and its correction may end up fixing a few other downstream issues. This is a complicated problem, however, and we may not solve it in time for the June update. We should know more about this one soon.
I’ve provided the list above as a stopgap. We have been discussing internally how best to improve bug status visibility so that you have a better idea of what we’re working on. We’re looking at a lot of options right now, and I’ll update you when we’ve settled on something. We recognize the need for this transparency and we’ll come to a solution soon.
ANYWAY... we have some nice content news! Update v0.1.3.0 will be the first KSP2 update to contain not only bug fixes, but a few new parts. Right now, we can confirm the arrival of the following:
- A.I.R.B.R.A.K.E
- Clamp-O-Tron shielded docking port
- Clamp-O-Tron Inline Docking Port
- MK2 Clamp-O-Tron Docking Port
- Cornet Methalox Engine (new small extensible-nozzle orbital engine)
- Trumpet Methalox Engine (new medium extensible-nozzle orbital engine)
- Tuba Methalox Engine (new large extensible-nozzle orbital engine)
- S3-28800 Large Inline Methalox tank (longer version of large methalox tanks)
Here’s some video of those new engines in action. The Tuba has individually-swiveling mini-nozzles that might be one of part designer Chris Adderley’s coolest ideas yet (final parts built by Pablo Ollervides, Jonathan Cooper, and Alexander Martin):
We are still testing the new grid fins. Because these parts require some special part module support, engineering work is ongoing. Due to the complexity of this work, we don’t believe grid fins will make it into the v0.1.3.0 update.
Last week’s challenge produced a few spiffy designs. Check out this rocket, with which user Well braved the Kraken and managed to deposit a lander at the bottom of the Mohole:
Gotta respect the ingenuity of using antennae for landing legs:
Thanks to those who participated!
Next up, at the suggestion of @RyanHamer42 on Twitter, we’re building space stations! Your mission, should you choose to accept it:
- Primary goal: build a station by docking at least two Wayfarer habitat modules together in orbit above Kerbin
- Secondary goal: add a deployable solar panel truss and a fuel depot tank to your station
- Jeb-level goal: dock a transfer tug to your station and place the station in orbit above another planet
- Val-level goal: send a lander to your station that can be reused for down-and-up flights to the surface of the planet below
Thanks for the suggestion, Ryan! Good luck, everyone!
-
There's been a lot of activity on this thread, and a lot of valid concerns expressed. I'll try to address the points I saw most frequently, but there's a lot here. I'll do my best.
- Some have wondered why we are showing the progress we've made on features peripheral to the larger mission of "fixing the game." Eg. why are we working on grid fins when we still have trajectory bugs? That's actually a really apt question, as we had a major breakthrough on wandering apoapses last week (and it probably deserves its own post in the future). The issue, as many have pointed out, is that we have a lot of people on this team with different skill sets, working in parallel on a lot of different systems. Our artists and part designers have their own schedules and milestones, and that work continues to take place while other performance or stability-facing work goes on elsewhere. I like to be able to show off what those people are working on during my Friday posts - it's visual, it's fun, and I'm actually quite excited about grid fins! They're cool, and the people who are building them are excited about them, too. So I'm going to share that work even if there is other ongoing work that's taking longer to complete.
- A few people are worried that because I haven't yet posted an itemized list of bugs to be knocked out in the next update, that the update will not contain many bug fixes. As with earlier pre-update posts, I will provide more detail about what's being fixed when we have confirmation from QA that the upgrades hold up to rigorous testing. As much as I love being the bearer of good news, I am trying also to avoid the frustration that's caused when we declare something fixed and it turns out not to be. I will err on the side of conservatism and withhold the goodies until they are confirmed good.
- The June update timing does not mean "June 30." It means that I cannot yet give you a precise estimate about which day in June will see the update. When I do know that precise date, I will share it.
- We continue to keep close track of the bugs that are most frequently reported within the community, and that guidance shapes our internal scheduling. As a regular player of the game myself, my personal top ten maps very closely to what I've seen in bug reports, here on the forums, on reddit, and on Steam. The degree to which I personally wish a bug would get fixed actually has very little impact on the speed with which it is remedied. We have a priority list, and we take on those bugs in priority order. We have excellent people working on those issues. I can see with my own eyes that they're as eager to see those bugs go down as I am, so there's not much more that I or anybody else can do but to let them do their work in peace.
- We - meaning, our team and the game's fans - are going to be living together with this game for many years. As aggravating as the current situation may be, and as much as I wish we could compress time so that the waiting was less, all I can do for now is to keep playing the game and reporting on what I experience. The game will continue to get better, and in the meantime I will choose to interpret the passionate posts here on the forums as an expression of the same passion that I feel for the game.
Thanks as always for your patience.
-
A fine May afternoon to you, fellow Kerbonauts!
I’ll start with a bit of good news: the v0.1.3.0 update will be dropping in June. We’ll announce an exact target date when we’re a little closer to the big day. We’ve already seen a few big bugs go down (you can throw a fairing away now in the VAB without endlessly redeploying its editor, for example), but I’m going to hold off on itemizing other fixes until they’re confirmed zapped by QA. Regardless, we’re feeling good about our progress in all areas and are confident that the next update will provide good performance, stability, and gameplay improvements.
In the meantime, our design and content teams continue to bring new parts to life. What they’re building now: grid fins! These were designed by Chris Adderley and brought to life by Alexander Martin (and Chris would like me to point out that the fin on the right is shown upside-down so that you can see the beautiful serration detail):
Our tech artist Jon Cioletti (with the help of graphics gurus Chris Mortonson and Phil Fortier) has pulled off the impressive feat of improving both polish and performance by overhauling the solar lens flare occlusion system. Lens flare occlusion (the scaling/disappearance of the sun’s lens flare when passing behind objects) no longer uses raycasts or colliders — now we’re literally counting pixels on the sun itself. The result: no more sun peeking through terrains or oceans, no more weird flare behavior behind vehicle parts, and the sun now shines correctly through visors, trusses, parachutes, and windows! Check it out:
In community highlight news: we’ve reviewed your capybaras and have found them variously cute, hilarious, and unsettling. For more capybara shenanigans, check out this roundup. Lookit this little fella from @Inyxia:
In other creative news, the last Dres-bound Weekly Challenge produced some very ambitious missions. We have very much enjoyed following your successes and near-successes. We know that flights of this complexity can anger the Kraken, especially in the game’s current state, and we salute those who push through regardless.
Check out this not-at-all-precariously-balanced lander by AVATAR Aang:
Or this cool rover hauler by GoldDragon:
Let’s see if we can rival these results with our next challenge: we’re going to Moho! Visiting the innermost planet of the Kerbolar System takes quite a lot of Delta-V, but if you’re up to it, you can try one of the following:
- Primary goal: do a Moho flyby and take some screenshots from orbit!
- Stretch goal: land on Moho and return to Kerbin!
- Jeb-level goal: land a Kerbal in the Mohole... and then return them to Kerbin!
- Val-level goal: all of the above, but get your Moho intercept by using a gravity assist from Eve!
See you all next week, and happy flying!
-
Good afternoon, Kerbonauts!
I wanted to start off by saying thanks to all of you who have been so patient and supportive as we’ve progressed through Early Access. We play KSP2 a lot, and we understand both the big and little frustrations around playing the game in its current state. It’s easy enough for me to say, in my corporate way, that we’re "aware" of these bugs and that we’re working on them, but I don’t think that gets close to the urgency we feel. This is a project to which we’ve devoted all our energy and passion. For many of us, the 1.0 version of KSP2 will be a crowning, career-defining achievement. We’re not just "aware" of the bugs. They stand between us and the promised land, and we are making every effort to eradicate them. It means a lot to us that in spite of the setbacks, the community still believes in this team and in the overall vision for KSP2.
We’ve been working on the usual stuff this week (bugs, stability, performance, and new feature work for the Science update). We expect to be able to communicate timing for the upcoming v0.1.3.0 update next week. In the meantime, we’ve been building some lovely Science collection parts, which are meant to provide interesting, meaningful payloads for research missions. This is one of our new radial science collection parts (designed by Chris Adderley, built by Alexander Martin, and animated by Paul Zimmer:
Bonus points to anybody who can identify what all the science bits do!
On to this week’s challenge: we’re going to Dres! If you in fact are a believer in Dres’ existence (I myself am skeptical), feel free to attempt the following:- Primary goal: Land on Dres
- Stretch goal: Land in one of Dres' canyons and return safely to Kerbin
- Jeb-level goal: Land a rover on one side of the Dres canyon and jump the canyon. (You can use rockets to hop and cushion impact, but use wheels to gain speed)
- Val-level goal: Place a satellite in orbit within the outer gap in Dres' rings
- Tim-level goal: Do all of the above in one mission
Finally, if you’re in the mood to check out some other players’ impressive vehicles, take a look at kspbuilds.com! Not only do these downloadable workspaces contain vehicles that are fun to pilot, it can also be super instructive to pull one of these into the VAB and take it apart to see what makes it tick. Here’s a little taste:
Some very creative use of procedural wings in there, right?
Have a great weekend!
-
Good day, fellow Kerbonauts.
In last week’s post, I communicated our intent to decrease the update cadence during Early Access to allow our team to devote a greater portion of their time moving toward 1.0 and a little less time prepping incremental public updates. Perhaps not surprisingly, some of you have expressed concern that this change signified some dark portent. To ease some of your concerns, here are a few clarifications:
- Our team is fully funded, properly staffed, and completely focused on executing the full vision of KSP2. Our velocity is good and our morale is great. This is still a dream job, and we’re still committed to making this game spectacular
- We want to balance our desire to be Santa (literally the most fun part of my job) against our goal of delivering an excellent product. The update cadence we’re looking at right now extends the previous cadence by 2-3 weeks - structurally, the change is not radical. I know the waiting can be painful, especially when there are still game-breaking bugs. Hopefully, the fact that each update will contain more improvements due to that lower frequency helps to offset some of the frustration of waiting
- This project has from the beginning been viewed as a long-tail endeavor requiring a long-term investment. We are not worried about keeping the lights on, and we will be delivering all of the promised roadmap features over the course of Early Access
- We will continue to post these weekly forum updates to provide visibility into areas where gains are being made. These posts are by no means comprehensive, not least because many of the improvements we’re seeing aren’t necessarily photogenic. They are meant to give you a taste of what’s to come
For example: we have seen rescalable UI elements in action for the first time this week (with many thanks to our newest engineer Ryan Ekhoff). We know this is a highly-anticipated improvement, especially for players with higher-resolution displays. The sample below is work-in-progress (yes, I see the app bar isn't scaling yet) -- the final implementation is likely to index to preset sizes to avoid scaling artifacts. I’m certainly looking forward to this upgrade:
Yesterday, Darrin House, our Director of QA, posted a really in-depth dev blog that I think does a great job of showing the behind-the-scenes reality of testing this game. It pairs well with a lot of recent discussion in the community about the role of QA in the development process, and it gives some insight into the unique challenges presented by KSP2. No shade on previous dev blogs, but this one raises the bar. I am perhaps betraying how much I like pictures here. It has lots of pictures.
This week saw some unprecedented radness on the ksp2_screenshots channel. Check out these masterpieces from @Coriolis, @Little Earl, @memes1, and @Schwing2727:
I can't stop, there's just too much cool stuff. Here are four more creations by @hidearimjosh, @Keagan1st, @Suppise, and @APairOfVintagePants:
For more like this, take a peek at our screenshot roundup here!
Finally, this week’s Challenge: fly a mission inspired by ESA’s JUICE program. While we wait for the RIME antenna to get itself unstuck, let’s send good vibes ESA’s way by flying our own multi-moon probes to the satellites of Jool! Now’s a great time to polish up your gravity-assist chops. Your mission, should you choose to accept it:- Primary goal: send your probe to Jool
- Stretch goal: visit Jool and one of Jool's moons with your probe
- Jeb-level goal: visit all of Jool's moons with the same probe
- Val-level goal: achieve the Jeb level goal while doing one or more gravity assist maneuvers
Have a lovely weekend!
-
Happy Friday, brave Kerbonauts!
A little bit of a slow news day here at Intercept Games as we gather feedback and data from our latest update and continue to work on stability, perf, thermal, and new features. I’ve spent more time than usual over the last week building rockets in the 0.1.2 build, and I’m relieved to see that my own personal points of frustration are mirrored in the feedback we’re getting from the community. I know we may sometimes seem remote, or that it may feel like your feedback submissions are falling on deaf ears. Not only are we collecting and reviewing your feedback, but the frequency with which you’re reporting on certain issues is incredibly helpful to our goal of prioritizing fixes. As always, we appreciate your patience as we work down the list and shore things up for update 0.1.3.
On the subject of updates: our update cadence is going to slow down a little bit. There are a couple of reasons for this, not least of which is that every time we release an update, we divert resources that would otherwise be focused on continuing to improve the game. We are always balancing our desire to improve the current Early Access experience against long-term goals that involve more time investment. This is a very personal issue for me, because as a fan I want the game to be perfect and awesome right now! But since genies don’t actually exist, that’s not how we’ll arrive at the best version of KSP2. We will continue to release updates prior to our big Science Feature update, and hopefully a slower update cadence will mean that when they do go out, they contain more robust improvements. We are still working out what that exact cadence looks like, and I’ll update you here when I know more.
Among the improvements that we’re seeing this week here at the studio, our planetshine system has taken a very big leap forward, and the next patch will feel quite different at night. Now, reflected light from planets and moons is much more apparent both in space and on the night side of a celestial body. A little sample of what Jool-light looks like on the surface of Laythe:
This week’s challenge: we’re building sci-fi spacecraft! There are already some very impressive entrants appearing in the KSP2 Discord ... check this thing out (by @S_Coriolis)!
That flux capacitor! MWAH!
Please also check out our TikTok! Our community team is very active over there, and their meme skills are quite breathtaking.
Have a great weekend!
KSP2 Dev Chat - Wobbly Rockets with David 'Trigger' Tregoning
in KSP2 Discussion
Posted
David's instinct to measure twice and cut once is one of the traits that makes him an extremely effective engineer. It was clearly honed over his years of dealing with similar challenges in KSP1. I'm always impressed by his calm and analytical approach - he never jumps to a prescription before we understand every dimension of the problem we're trying to solve. Trust me when I say that my own eagerness to solve a problem in the "obvious" way is almost always proven misplaced once we've done a deep dive on the causes of an issue. David is a treasure and we all love working with him.