Search the Community

Absolutely NOT in my opinion. He made so many wrong calls, that KSP1 started progressing in a right direction only after he left. if you talk off-record over a beer or two to any of late KSP devs who has seen Harverster's late days in the team, you won't hear many good words about him. That's not to take away his achievement of the very creation of KSP, but at some point things turned for the worse. That just shows once again importance of leaving at just the right time before your star has finally set for good.

I'm gonna talk about the possible human remains found in the sub. I'll put it in a spoiler box since it will probably be upsetting to some;

@AngryBaer 1. On that I only mean the broadest strokes. Colonies, resources, interstellar (and multiplayer tho tbh that one I’m not as excited for.) The steps and exact vision will be different and no I am not expecting feature parity with CGI trailers with hundreds of ships. Absolutely some take this point too far like you say. 2. This is a good point. I couldn’t imagine yelling at a waiter regardless of the quality of service. And this is why I try and and make sure the object of my frustration is clearly communicated. I’m angrily criticizing whatever suit decided to charge $50 for this and launch in the state it’s in. To me they were either wholly incompetent, or willfully deceitful launching those trailers knowing what’s going on behind the scenes. Either way those type of publishing decisions is what I want the gaming community at large to stop putting up with. People who complained about the developers going on vacation were rude. As far as “where is re-entry comments” my view is quite simple. They know they messed up there yet they don’t acknowledge it. I mess up constantly. I apologize to my wife, my coworkers even my son who’s too young to talk. An acknowledgment and an apology shows mutual respect. My irritation with this situation is 90% the lack of acknowledgment or an apology. It seems more similar to people who gaslight and manipulate out of taking responsibility and lines up more with the “ksp2 is an intentional scam” narrative than I believe is true or would like. A post about thermal systems was the perfect time for a “we are sorry we missed our goal on the timing of this feature but here is how we are working hard to make it awesome.” That line would make me not bring it up anymore. Not getting that line to me is disrespectful, but I agree with the point and will do my best to keep my voicing of this frustration limited and pointed at the right people. It’s just easy to get more frustrated the longer the problem is ignored. I agree that the investment was large enough they will try to recoup that by funding development for a long time. My fear is that it’s already been a long time and the pace of progress has not given reason for confidence. On communication style, absolutely there has been improvement. They are still not as open as most EA titles I have played during development. Most are able to say “sorry” for not hitting a stated development milestone on time or, if they know they are still building a system in the game from the ground up, do not promise it to come out “a short while after launch.” But I don’t want to be a negative Nancy, I agree progress is being made just sharing why I feel there is still some criticism here.

@moeggzYou can't expect the KSP2 apologists to be polite when they don't face nearly the sort of scrutiny that the 'haters' do from the powers that be - and they know being rude and getting people to fight in threads they don't like gives those same powers the excuse they're looking for to lock them. Win-win from their perspective, they get to trash talk AND they get to silence people.

Just as the more determined of the apologists have taken the contrarian view and will grant infinite patience and understanding now matter how absurd the contortions required to grant IG the benefit of the doubt are. Potato potato. Is hanging out on a game forum, discussing an EA stage game where the devs are clearly on their own road and not at all paying attention to the community, a productive use of time for anyone, whatever their opinion is? I personally find it cathartic to share my thoughts, but I'm not under the assumption that I'm changing anyone's mind or doing something productive with my time. You asked a question of 'why' but you yourself seem fairly locked in on your own take too. These have gotten somewhat better, but my sense is that it's more 'we literally can't gild the turd more because the release is the release' When they talk about long term plans - and when you look at the pre-release communications, especially over the years, it seemed like they BS'd as much as they possibly thought they could get away with. Even Nate's more recent comms about how the delays are for better QA (next release - major showstopper got released and had to be hotfixed) and for feature work (no feature work is evident) still rub me the wrong way.

It actually could have been much clearer, but generally people who actually know what they are talking about (which is quite obviously the case here) tend to also know better than to talk excrements about other peoples work that they know nothing about.

This is how a developer who's awkwardly struggling to say something nice while also being totally honest sounds, in transparent and unscripted human statements. Such a breath of fresh air. I absolutely love how he then moves on to talk about how there's no wobbliness in his current game, because even he knows that was jank to be learned from and moved past.

One further note: The current maintainer of TweakScale has not requested to have TweakScale removed from CKAN. CKAN has a strict policy that such requests are to be honored; mods are only in CKAN if the author agrees to it and doesn't request removal. You can draw your own conclusion about how seriously to take talk of "ditched" and "support" based on that.

5/10. I appreciate the philosophical stuff about human flaws, but the way you talk is too formal and suspicious. Of course I am a human, I have passed a Captcha test before.

I just made quick but extensive tutorial about the FDAI (navball) - Flight Director Attitude Indicator. An incredible instrument ! First flown on Gemini, then Apollo, the Space Shutlle, and still used today ! : ) I talk about its history a bit, as well as its functionning, and then how it used in KSP retro styled IVAs, with some examples Cheers

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.

I'm working on a patch that will add fire storms (I asked him how to do it, pretty straight forward in that regard) and eventually fire tornados to Moho (there was talk of him adding in tornadoes & hurricanes, I'm just going to make them fire-like if possible). So patching all the planets in OPM by an experianced planetary modder (I'm not) shouldn't be too hard. Apparently Auroras are also on the list to be developed, it will be quite a mod once fully released.

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

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

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

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

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

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

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

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