Search the Community

Any example? If the developers are so afraid of everything, then how did they get the courage to release the game and then talk about how proud they are of it? I mean, the forum...? But if you need a specific case, this write-up that could easily have taken a full work day to compose devolved into nitpicking about how x y or z wasn't being simulated. And I don't recall saying anybody was afraid of anything. I'm not sure where that came from. But if you keep getting your hand bit every time you put it in the cage, eventually you gotta wonder why you keep feeding that thing.

Any example? If the developers are so afraid of everything, then how did they get the courage to release the game and then talk about how proud they are of it?

They label themselves a hard sci-fi, non-open-world starfighter sim a la Star Citizen. Their dev team profiles have notable names on them. They namedrop big things. But am I the only one who fails to see a connection between rather ordinary starfighter sim gameplay that goes on on the screen, and the hard sci-fi fluff they push on the side? Visible lasers, extremely close-range dogfighting, some of the ships noticeably lack radiators, one of the ships has pronounced atmospheric features... hell, it seems there aren’t any SC-style gimballed weapon moints!

Old fart here, I think it's about 20 years since someone could call me "lad" without a smirk. But I'm willing to give you my 16 cents (0.02USD corrected by the inflation of the period!! ): The problem is not who is "talking", but who is "listening". Words are like poison - you need to ingest it to be affected by it. Whatever is happening around, it's happening by many, many different reasons - and very few of them are edifying. There're a lot of disgruntled franchise fans, no doubt - and everybody passes trough the 5 stages of acceptance (or grief) at their own pace - but this pace can be manhandled by 3rd parties to achieve some goal, and this is exactly what I think it's happening. The Game Industry is on a terrible disarray, and things are not going to get better in the near future - and I'm betting some snacks that a lot of people are promoting this drama as a way to try to push away the public attention from the real problems and, so, save their face and even their job. And there're also the ones that are actively working on an attempt to… humm… how to say… "hijack" perhaps? the attention of the public trying to get themselves a job that currently is secured by someone else. "Farinha pouca, meu pirão primeiro" - as it's said in Brazil (and, yeah, the successive economical crisis on my country made me an expert on this area). So, nope. This is not going to stop - money talks, and empty pockets hurt. Noisy combination. Really, the only way to push back this drama is by not listening to it. Let them talk to themselves, without audience, and the problem will be solved by itself. Remember what I said above: the most letal of the poisons is harmless if you decided not to ingest it. Whoever is spreading drama and smear, just ignore. Don't react, don't follow, don't like neither dislike and, most of all, do not spread it yourself. Just walk from them - and the problem will just vanish in the thin air.

YEAR 3, DAY 292 - FIRST LIBRA ORBIT SPACE TOURIST REVEALED! Kerbalsaurus Kerman (Left), Felix Kerman (Middle), and @fulgur Kerman (Right) After a long time of consideration, the first tourist to ride in Jeb's Junkyard's Libra Orbit has been decided! And who's the lucky (and rich) Kerbal? Why, it's Felix Kerman of course! The world famous daredevil! He's proposed an idea: a jump into Kerbin's atmosphere from orbit. At first this idea was dismissed as crazy talk. No space suit can survive such conditions. That was, until a new design was proposed. It's cheap, but could work. By strapping parachutes and stainless-steel beams onto a massive heatshield, our engineers were able to create the world's very first open-air spacecraft! This spacecraft is like no other, and very dangerous, but Felix has said he's up for the challenge. Going up with him will be his coach and trainer, who sadly couldn't make it to this press conference. Congratulations to Felix and @fulgur Kerman for their contributions to Beyond and Kerbalkind!

Well, this game violates Steam rules of early acces, rule number 2, 4, 5 and 6. I requested a refund and i think most of the people should. We are not here to fund development, and it clearly says game has to be playable. Rule 2. Do not make specific promises about future events. As i see, multiplayer was promised, i think we are not getting it. Also we didn't get bug fixes we should to be able to play the game. Rule 4. Don't overcharge Steam customers. If 50$ is not overcharging, i do not know what it is. Rule 5. Make sure you set expectations properly everywhere you talk about your game. I don't have to spend words on this Rule 6. Don't launch in Early Access without a playable game. This neither needs explanation.

The fact that development started in 2017 does not mean that large parts of the game were not scrapped at one point. I don’t think it’s a scapegoat- I think it constitutes mismanagement and also dishonesty when they didn’t come out and talk about it and continued to promise that the full game was temporally close. Personally, I’m maliciously spreading misinformation.

Which is a feat still undefeated by KSP2. At the "best" time we'd get an upnate that told us they couldn't tell us the date, and then a communication from Dakota that the patch was near, and then it was just bugfixes and nothing more. The last proper devblog was July 21 (83 days) , about the heat system. The last "dev chat" was 12 days ago (after being delayed from a release statement in August, from which another video is still missing). The last "upnate" was June 30 (104 days). Now, you could argue that the dev chat would obviously stand as the latest communication, but I'm sure you'd quickly be reminded that not only did it state nothing about the game but it was also nothing about what could be coming to the game, considering it was only theoretical talk about an internal tool to maybe let them try some solutions. One can call people naysayers, haters, meltdown havers, and whatever else, but I once again invite you and everyone to take a snoop outside these forums (and much more the discord), and actually get a taste at what differing opinions look like. It's way too easy to call people toxic and cower under the blanket thinking everyone else is the problem. Here you go, have an album.

Players do not allow full releases to be released in poor quality. This is allowed by the developers and publisher. Players can only criticize the game on the Internet and make a refund. And regarding KSP2, we must take into account the previous history of delays; for many years there was no talk of any early access.

T2 is the biggest publisher in gaming, and have clearly noticed that if the concept works, it can bring in big money. Again, SQUAD managed to sell 5 million copies of the previous game with a budget that didn't even reach 6 digits. I'm positive that level of investment vs returns is exactly why T2 would allow them to delay the game 3 individual times, and to re-fund an entire year of hiring and shuffling employees around (that stuff is expensive, plus it wasted an extra year). Do you really think they'd do that for any other game? They themselves have kicked people out for failing to produce games, and put a lock on those projects. In that aspect alone, KSP2 is pretty much the one single exception in the whole gaming industry, and anyone other concept would've probably gotten the boot. I don't need Nate to tell me they're funded, it is really obvious they are funded because they potentially have a golden egg goose in their hands. Now, I'm sure there's a limit to the patience and funds T2 is willing to give PD (which is probably why they kept branching to publishing other projects and KSP2 is no longer their main thing). I'm sure we'd all love to talk about concrete stuff, but we haven't been given concrete stuff in a while. If you dare check outside the forums, nobody shares this view. The most popular opinion about the game literally anywhere but here and the discord is that the game is dead, or on a skeleton crew, or that the devs smashed and grabbed and are doing something else.

You do relaize that when i talk about the UI i talk about the general looks and style and not about little details and bugs/problems it had? If to you it seems as if i wanted to say that KSP1s UI was perfect - i never meant to say that. I dont have to have expericence in design to know if a UI is more or less ergonomic for me to use. Compressing everything in a small area isnt good design. The view is actually blocked a lot since lots of pointless things are constantly visible or way to big or have grey boxes that block additional view for no reason. I never had a problem with the SAS buttons - they were perfeclty fine - the new ones are way too big. Also those are things most people would probably control via hotkeys at some point if possible. Why should time use up so much time and why move it where you just argued is the most important space of the screen? In genearl shouldnt most of those functions be something done via hotkeys anyways? No i dont like it because having lots of information with lots of details in the same area actually leads to me taking longer to find that information. Im also pretty sure that the new Interface actually takes up more % of the screen than the old one.

I just watched @ShadowZone 's interview with Nate from just before release.* SZ's presumption is that the developers knew what condition the game was in - and that 'management' (my word) rushed / set an arbitrary date for them to release to EA. It had to go out on the date come hell or high water. And it did. Nate mentions the one thing that will likely be the biggest performance enhancement: refining the PQS System. (The Planet Making System) Given that that is likely a big overhaul, and my impression from the interview is that it was an ongoing project before the release... I don't expect it to be part of the first patch. It could be; I just don't expect it. He did talk about the process: Find the biggest resource hog, tame it; find the next biggest. Those actually sounded like two parallel processes - Taming PQS is a long term, not easily solved thing that is a work in progress - the other is regular refinement. So I would expect some performance enhancement with the patch... just not likely to be the one that causes FPS drops like those from looking at space as the background vs a planetary body as the background. Another thing from the video that comports with what I've seen over these last two weeks - there's a lot of stuff in this build that is wrong, that they could not have NOT known about. So the likelihood is that the patch work isn't just 'look what these intrepid players discovered' it's also fixing stuff they've known about for a while. Final note: while I've been doing my bug hunting and reporting stuff on the forums - I keep running into this line of thought where people are liquided that they haven't patched it yet. I think that wishing for a rushed patch is counter productive. My biggest gripe is how poorly the community interaction and contact has been. I get that a project this big has a lot of moving parts and there is greater risk from rushing a bad update out too soon than there is from taking their time and putting out a well thought, well coded patch later. I'm fine with that. But they should be talking to us. I've tried to explain this elsewhere - but let me try again. The Communications Strategy seems to be PrivateDivision driven - by an expectation that they were releasing a fun-to-play and largely functional game that was awaiting some key elements of 1.0 to be polished, and those big content releases would be fed to players in the order outlined in the roadmap. In other words, a functioning EA title. They have Ghostii doing fun tik-toks and showcasing quirky builds, people on Twitter doing fun things and linking to positive articles, they're all over Discord where people can just spam thoughts and they get large numbers of bodies daily -- all of which would be acceptable if the game was what we expected (and likely what PD wrote their Communication Strategy around) : functioning, fun and awaiting key elements. That strategy would be fine if the game were as performant as other EA titles - like Satisfactory (for example). The game did not release functioning like an EA title. It released like an Alpha/Beta hybrid with a few EA elements. You talk with Alpha/Beta players differently than you do with EA communities. You acknowledge the bugs. You collect the bugs - communicate priorities and tell the testers what you're working on. You under promise and over deliver. You don't ignore them - or keep up some semblance of your original marketing plan when the game is this buggy. Case in point: Dakota's content That's my beef. They're not communicating with us in any way that reflects the reality of the game. That failure of communication is actually accelerating the reputational harm. Increasing the frustration. They should be managing expectations - not ignoring them. * Video Link

No more talk of darkness, forget these wide-eyed fears. I'm here, nothing can harm you, my words will warm and calm you. Let me be your freedom, let daylight dry your tears - I'm here, with you, beside you, to guard you and to guide you.

How would Kerbals structure calendars? In Earth, we have days, weeks, months, and years. And, from what we see in the game, Kerbals have a very similar way of telling time. Except, we only get days and years, and nothing in between. However, this is still a lot of information to start with. Let’s start with structuring weeks. On Earth, a week is 7 days. On Kerbin, a week could also be 7 days. If we do the math, 6x7, which is 42, a Kerbin day can fit perfectly into a 7 week period. This doesn’t translate very well when compared to a year, though. If we do 426/7, we get 60.8571429, which is a really odd decimal. But if we do 426/6, we get a round 71. It’s be easier to structure a calendar like this, so a Kerbin week is most likely 6 days. Now, what about a month? On Earth, a month is averagely 30 days. If we do the math, 30 days fits well into a year. 426/30=14.2. Much like on Earth, Kerbals can shift around days, making months longer or shorter. Therefore, Day = 6 Hours Week = 6 Days Month = 30 Days Year = 14 Months I hope you enjoyed my Ted Talk.

I remain as supportive, positive, and optimistic as I possibly can be. However, the public news of layoffs, the review scores, the absolute denial and "all is well!" "just do another weekly challenge!" attitude is not helping. Not when 50% of the community has an extremely degraded gameplay experience, and the viewpoint is that there is a straight up refusal to address the communities fears and worries. The fears and worries being that KSP 2 will not see a completed road map. We need, and deserve, answers. Not corp speak, answers. We need and deserve communication, not "in the coming days and weeks and months" Now. Talk to us, the community, and answer our questions, honestly. Please. Side Note: This is not an "Oh god even Rayne is scared!" situation. I've been supportive, positive, and over all optimistic and I will remain so, but todays news of layoffs was an incredibly huge blow to my own moral and hopes and dreams of KSP2 as a player and a lover of this franchise. It was a huge blow to the morale, faith, and overall atmosphere of the community. That, is why I am asking for answers. So in short, Talk to us, please. Respectfully, Rayne.

What specific questions did you have in mind? I would be curious to know how Intercept was affected by the layoffs. We know about the lead engineer, but were there others? The thing is that it’s really not OK for Intercept to announce this about individuals or individual roles that would let people figure out exactly who was let go (except executives). That’s personal information. You don’t do that to people. But I agree that a bit more communication could help, like, how many roles were cut? When did Intercept know about them? Other than that, what could they say to allay worries? I can’t think of much TBH. They’ve already said development continues apace and according to plan. You can choose to take that at face value, or not, but what more could they say to convince you? The problem is that fans aren’t reasonable people you can talk to reasonably. You can share your internal roadmap with reasonable people because they understand that it’s subject to change; the milestones can change and things can even be dropped from it altogether. You can’t do that with fans because imagine the reaction if, say, they have wind, rain, and snow on it, and later on it gets cut. It would be just a continuous outrage machine. I really wish fan culture would change so there could be more direct and “adult” communication between studios and fans but I just don’t see that happening. You’re by far one of the more reasonable fans @RayneCloud but even you are showing a quite a bit of fan entitlement in some of your posts — and it’s precisely that which makes studios hide behind baby-talk and corpo-speak. You don’t want to say anything to provoke another hissy-fit so you end up provoking one but not saying anything. In sum a big ❤️ to community managers everywhere who have to deal with us. We suck, yet you manage to remain almost invariably positive with us.

ANNOUNCE Release 2.4.7.4 is available for downloading, with the following changes: A serious regression was detected on 2.4.7.3. The code intended to fix Issue 307 triggered Yet Another Bug on Editor™, and had to be removed. This, unfortunately, resurrects #307. Closes Issues: #314 The Editor is screwing with me again when scaling Parts with PartModuleVariant ReOpen Issues: #307 Attachment Points are not being scaled (or being reset) after changing the Variant A SERIOUS REGRESSION were (finally) diagnosed. The fix for the Issue 307 ended up triggering a new bug on Editor (or an old bug in disguise), what lead into the problem reported on Issue 314. Exactly "how" this happens is (hopefully) diagnosed, "why" I will never know and "when" is currently work in progress - the aim for the next TweakScale release is to close again #307, but without screwing anything else this time. Until there, please select your Variant before scaling the part, what's exactly what you had to do before 2.4.7.3 anyway. I'm not happy with the time I took to finally understand the problem, but I least I could issue a fix in less than 2 hours after detecting it. My apologies for the borkage on the wild - but Real Life™ and Day Job© sometimes conspires together to screw my life, and the last 8 weeks were being royally screwed - and the few days I got to rest I, well, rested. @AnFa, I'm afraid I didn't managed to diagnose correctly your report, my apologies - but as a matter of fact, I think you were bitten by BOTH problems are the same time (mine and ReRoot). In a way or another, if you are still using TweakScale, please check this fix, thank you. Know Issues Attachment nodes are being reset when changing Variant on a scaled part. Please change the Variant before scaling the part as a temporary workaround. See issues #307 and #314 for the gory details. There's a long standing issue on TweakScale about scaling ModuleEnginesFX's plumes - some engines' plumes is just not scaled, while others scaled pretty badly. It's something that never worked right on TweakScale, and it will only be really fixed on TweakScale 2.5 (when this thing goes gold) The best workaround (and also the reason I'm dragging my feet on this) is to use SmokeScreen or Waterfall. For SmokeScreen, you need: SmokeScreen itself. Real Plumes (to enable SmokeScreen on Stock parts) Additional Part Sets and Add'Ons may need specialised support not included on Real Plumes. For Waterfall, you need: Waterfall itself. StockWaterfallEffects (to enable SmokeScreen on Stock parts) Additional Part Sets and Add'Ons may need specialised support not included on StockWaterfallEffects. See Issue #27 Disclaimer By last, but not the least... And since we are here, a very important disclaimer and serious warning: please, pretty please don't give attention to character assassinations attempts against my add'ons. I'm perfectly aware that they are not perfect, but under no circumstances they are malicious. There's absolutely NO CHANCE any of my code would do shady things on you, neither try to force you to do something by your back. I may bork trying to do the right thing, but it's all. In special, this crap: is, well… CRAP!! That "shady ass version of a Module Manager tampering library" is a tool to PROTECT YOU from fatal mishaps on installations: You forgot to install Module Manager, or by some reason it isn't operational? It will bark on you. You installed an older version of MM by accident, what fools KSP on using the older version? It will try to fix it, and then will bark on you so you restart KSP and use the right one. You installed a different version of MM by accident? It will remove the alien one (no matter what it is) so the MM you want to use will be safeguarded against replacement. You screwed something while trying to get rid of PD Launcher? It will bark on you, warning that things are not going to work 100% fine, no matter what anyone else tells you the KSP.log ending up on the wrong place is already a sign that you should not do it this way!!! You forgot to install a dependency that makes TweakScale to bork? It will bark on you and prevent you from loading the game, what would destroy your savegames!! You forgot to install a dependency that makes KSPIE bork? Same thing! You have any Add'On that screws up the savegames if incorrectly installed? Talk to me and I will implement a WatchDog for it. And since Module Manager (forum) itself is being prevented somehow to yell when Reflection Exceptions are detected while loading DLLs nowadays (see Issue 312), Module Manager WatchDog is, now, the only defense you have against such borkages! And even this "shady" feature can be easily disabled when using CKAN or any other PackageManager that handles itself the problem, as we can see on this link. I never pushed my weight on users, and this will not change. I have my share of problems to fix, I'm not denying it and I'm bashing my cheeks to have them sorted out. No one needs half baked, unfunded and easily refutable (the freaking thing is OPEN SOURCE, damnit - anyone can read the code and check themself!!!) accusations to be added to my already significant workload - unfortunately, this means that I will need to defend myself from such crapness as I'm doing now. This is not even about my reputation anymore (I don't need help to screw it up myself!! ), we are talking about people intentionally putting users at risk. I will not even try to speculate about the reasons. (sigh). Vida que segue. This Release will be published using the following Schedule: GitHub, reaching first manual installers and users of KSP-AVC. Right now. CurseForge. Right Now. SpaceDock. Right Now.

The list of of alumni of Bauman* Moscow State Technical University reads like a who's who of air, space, nuclear and arms industry - Zhukovskyi, Korolev, Chelomei, Sukhoi, Tupolev, Myascischev, Pilyugin, Lavochkin, Dollezhal, Nepobedimyi... to this day, pretty much only Bauman graduates are considered for the assignment of a Soyuz engineer. * Nikolay Bauman was a small-time veterinarian and the leader of Moscow's Bolshevik cell who in 1905 got killed during a demonstration nearby; he had absolutely nothing to do with the then Imperial Moscow Technical School. There is, however, one Baumanka graduate most people really don't like to talk about: Alfred Rosenberg, of Revel (now Tallinn), a literal achitect turned writer, as well the figurative architect of the ideology of the German National-Socialist Workers' Party and the Reich Minister for the Occupied Eastern Territories. Evidently, history likes to try to put a spoonful of tar into every barrel of honey.

Engines: How to Avoid Shipping a Rocket Scientist By Chris Adderley We’ve mentioned approachability as a core pillar of our KSP2 design, and I’m here today to talk about one of the less-obvious ways we are focusing on helping players reach the stars. An area we’ve noticed players struggling with in testing is making sense of the dizzying array of engines you’re presented with in the VAB. KSP1 had 35 engines for you to choose from (more if the Making History DLC is installed), spread across Liquid Fuel/Oxidizer, Liquid Fuel, Monopropellant, Xenon and Solid fuel types. This leads to a good deal of player confusion when starting out – what engine should I use? What engine is best for what I want to do? Why isn’t this rocket lifting off the pad even though I put 20 Terriers on it? There’s a lot of trial-and-error gameplay before you learn the hard-won lessons about specific impulse, thrust to weight ratio, and fuel density that can rocket you to success in KSP. Hah. It unfortunately gets a bit worse. When you're looking for an engine, all of your important details are buried deep. You're searching for specific impulse, thrust, mass, heat production, and how the engine performs in multiple situations (sea level, orbit, other planets). It's a lot of work when you're learning! When we look at our plans for KSP2, we’re only making this problem worse. We’re adding more engines, more fuel types and more engine sizes. Ouch. Clearly, we need to find good ways to teach new and returning players how to select an engine and teach players at the very least which engines are better at which missions they want to accomplish. I’m going to go into some detail on how we’re going to work towards addressing this, focusing in on the most common type of engines in KSP – the venerable liquid fuel engine category, which boasts such illustrious names as the Mainsail, Rhino and… Ant. Liquid Fuel -> Methane Before we get into this, a bit of terminology. Let’s start with talking about… methane and methane accessories. KSP1 gave us an abstracted resource to run our most common workhorse engines: the well-regarded Liquid Fuel . For KSP2, we’ve decided to take this resource and… name it. It’s methane. For their space program, Kerbals have passed over the brutish kerosene, toxic hypergolics and seductive lure of liquid hydrogen to settle on this nice middle ground fuel. It’s a good choice – a number of commercial companies are currently moving engines using methane and oxygen propellants to operational readiness. When we talk about engines you might recall from KSP1 that sported the Liquid Fuel/Oxidizer moniker, we’re always talking about methalox engines. Yes, this nomenclature change applies to jet engines as well for simplicity, so jet engines are now methane engines. Engine Archetypes So, looking in detail at the methalox engines we have inherited from KSP1, we can see that we’ve got an interesting challenge on our hands. More than half of those 35 engines are methalox, and they’re practically the first engines a player gets introduced to. If we’ve done our job right, they’ll continue to be useful engines in some niche even after you have access to objectively more power engines, so they’ll stick around for a while. So, how to sort and help players determine how best to use them? I’ll present the concept of Engine Archetypes. Rocketry fans will be familiar with three high-level types of liquid fuel engines. Firstly we have the high-thrust, high power engine which we can call the booster engine. These engines are great for getting a ship out of the atmosphere and pushing really heavy payloads, but don’t [SG16] have the efficiency to make them great deep space engines. Examples of this could be the Saturn V’s F-1 engines, or the Falcon 9’s Merlin engines. Secondly, we have the sustainer type engine. This is typically a more efficient engine that burns for a longer duration, but doesn’t really have the oomph needed to throw heavy payloads into orbit without a little help. This type of engine is often paired with extra boosters of some type to get a kick up into orbit. Good examples of this include the Space Shuttle’s RS-25 engines and the Ariane series of rockets’ Vulcain engines. Thirdly we have pure vacuum, orbit-only engines, best for operating in the cold depths of space and really, really efficient, but it will be lucky to push an overstuffed Kerbal though even thin atmospheres. A shining example here is the Aerojet RL-10 engine, which has existed for so long (early versions flew in the early 1960s, and the current version is used on the SLS rocket’s Interim Cryogenic Propulsion Stage) that it is basically the kitchen appliance of rocketry. We can map these engine archetypes to KSP engines fairly well – see the following table. Archetype KSP Examples Booster Reliant, Mainsail, Mammoth Sustainer Swivel, Skipper, Rhino Vacuum Ant, Terrier, Poodle This provides a good starting point for laying out KSP2’s methalox engine lineup. Vacuum Engines – an aside We’re always looking for opportunities to improve teaching about real rocketry concepts. One of the places KSP1 hasn’t quite lined up with the literature is the nature of the vacuum engines it uses. In reality, the shape and size of the nozzle attached to a rocket engine makes a big difference in terms of its performance at different atmospheric pressures. A good way of looking at this is to compare something called expansion ratio – which is a measure of the difference between the area of the engine’ s throat and its area of the nozzle exit. In vacuum, the ideal expansion ratio is extremely large – a good vacuum engine has a very narrow throat compared to its exit. To make a given engine work better in vacuum, we use a really big nozzle (though there’s obviously a lot more to it that just making your booster engine’s nozzle bigger). Simplified rocket engines with small and high nozzle expansion ratios Of course, reality sets in here because you can’t just add moar expansion ratio (a multi-kilometer wide nozzle might be a bit heavy) .Rocket scientists have tested novel concepts like the inflatable nozzle (look this one up), the hinged nozzle, and other creative ways of compressing nozzles so they become really big in orbit but can be launched with a smaller footprint. A working example of that is the RL-10B-2 engine that uses an extending lower nozzle cone that deploys once the rocket’s upper stage separates. You’ll see something like that in KSP2 with our NERV-US engine. Unfortunately, KSP1’s vacuum engines are actually smaller than their atmospheric counterparts, which causes no end of consternation among the more technically minded of KSP players. This is a bit of dichotomy, because we all love using the Terrier and Poodle as lander engines due to their small footprint and suitability for landing legs. For KSP2, we will we be looking at moving towards a model that keeps these heritage KSP1 engines around as a subclass of engines that we’ll define as the Orbital class. These will maintain some level of excellence in space, get a bump to their atmospheric stats and leave the door wide open to the long, efficient Deep Space class of engine that lines up more with idealized vacuum engines – a new set we’ll be introducing through Early Access. KSP2 Methalox Engine Archetypes So, given all the above we have defined four engine archetypes: Booster, Sustainer, Orbital, and Deep Space. With these archetypes in mind, we can design for them and use them to teach players. Players who know how to use Thrust and ISP to find the engines they want still have that information. More novice players can build to that point by first learning archetypes. How do we teach archetypes? Well, here’s what we’re working on: Terminology: We have aligned ingame terminology, like subtitles and descriptions, to specifically work on teaching player that any given engine belongs to specific archetypes. At Early Access you’ll for example see the Mainsail comes with a tagline of ‘Methalox Booster Engine’ that helps players situate it in the hierarchy of engines. Archetype subtitle for the Terrier Visuals: We have created specific design languages for each engine type, so picking up an engine and looking at it will be a good way to think about how it performs. Building these languages into our engine models is going to be an ongoing process through Early Access. Balance and Tuning: We have mapped broad bands of engine characteristics to types, and then aligned many engines to better tell their stories. There are always strange engines, but they get to be strange because standard engines exist (like the Dart, that weird little aerospike guy). Visual Language Having good visual language for concepts is one of my passions. We want KSP’s rocket engines to be similar to, but not be real life engines. Reality is full of cool engines, and some of our engines hew very close to existing or conceptual designs. It's tempting to do that all the time, but the closer we lean to reality, the more the engines must skew to reality in all regards. I call this the "Why can't I build a space shuttle with three Vectors" problem. In addition, we’re unlikely to have anything close to the great variety of fuels and tanks that reality has, so being very high fidelity with designs for engines creates disconnects for a detail-oriented realism players (this terrain is great for modders). Instead, when we’re looking at our archetype language for KSP, we will try to be a bit more general and inspired by real engines, rather than creating exact copies. I’ve put together some sketches of these four archetypes to guide our artistic design going forward. The goal is for each of them to have a distinct visual look that is preserved through all size classes, and is versatile enough that, for example, a Mainsail doesn’t just look like a smaller Mammoth. We can pick and choose from a number of reality-alike design elements to create cool, Kerbal-native engines. Booster engine features and possible design variations Sustainer engine features and possible design variations Orbital engine features and possible design variations Deep Space engine features and possible design variations The first place you’ll see this visual language in Early Access is the 3.75m engine lineup featuring the Labradoodle, Mammoth-II, and Rhino. Applied design! From left to right, the Labradoodle, Mammoth-II and Rhino engines sporting, respectively, Orbital, Booster and Sustainer visual queues, courtesy of artists Jonathan Cooper and Pablo Ollervides. Balance and Tuning As we get to the end of this article, I wanted to touch on balance and tuning. Our guiding principles in tuning engines can be summed up with 3 points: Don't deviate from KSP1 for the sake of it. A methalox rocket in KSP2 should perform similarly to a similar looking Liquid Fuel/Oxidizer rocket from KSP1 Engines of an archetype have similar characteristics. Engines within a fuel type exist in a similar band of power, so newer or larger engines should not make older engines obsolete. These rules still give us a lot of room for play while letting us increase approachability. Some engines, like the Vector, needed a hard look under these guidelines. We’re basically trying to follow this chart, which I find a useful way of looking at the overall capabilities of engines. If an engine is a Methalox Sustainer, it should fall in the blue region, as an example – and we are really trying to keep things out of the Useless and Way Too Useful regions . The Way Too Useful region is a story for later in Early Access with more exotic engines , which have their own, unique challenges for building and flying. Taken together, this means that outside of some specific areas, you won’t see massive statistical changes to most engines in KSP2 from KSP1, despite the naming change from Liquid Fuel and Oxidizer to Methalox. Places to watch out for are: KSP2’s 3.75m engines have had some overhauls to account for the addition of an Orbital engine in this size class (say hello to the Labradoodle, as named by Scott Manley!) KSP2’s Orbital engines have better atmospheric performance than their KSP1 counterparts. The relationship between the Mammoth (now Mammoth-II) and the Vector has been adjusted for KSP2, as they no longer need to match visually. Putting it all Together I can sum everything up using a table. Tables are almost my favorite things, narrowly being edged out by graphs. Other Fuels “But Chris!”, you say, “I thought KSP2 was about MORE than just Methalox?”. That’s absolutely true, and we’ll be looking to follow the same general rules when creating archetypes through other fuel types as we reveal things through Early Access.

It is sadly a very common denominator for people to talk about wobble forgetting you're supposed to use the same tanks, structural parts, and many other stuff to create things that aren't rockets.

The issue is that all we seem to get about anything are excuses rather than fixes. Like Rayne I don't and won't go to yet another discord for answers. I have to sit on way to many of them as it is, but the lack of communication and what communication does go out is bad, Like I thought honestly that Frontier Development had set my bar of 'can't be any worse than' after their handling of Elite Dangerous over the years but ever since the "We are cutting back post" things here have gotten worse. It shouldn't be a big ask for Community Managers to take 5-10 minutes out of a week to get a round up of what is going on and be able to communicate it, I mean it's part of your job. It shoulnd't be 7 months in that we still have zup, nada, no idea of when the updates for features that were promised to be 'rapidly put out' are and some how the few video's that have been released by you all don't fill me with confidence of late either, as core fundimental items that should have been dealt with before EA are being tossed around like 'well hey we got 50$USD from these suckers we are living on their dime now" and while that might not be what is intended it is how it feels. While I want to say congrats to Mike for his recent personal events, as a customer and a consumer at the same time those personal events should not have the roll on impact that communication and updates with the community fall behind. Especially given that it's not like what has happened was 'sudden' either it was kinda going to happen and based at least roughly on how events go you've had as a company 7 months to plan for 'fixes' so to be 'hiring' at the point when it becomes a problem kinda makes me even less confident in how things are being ran. There are a thousand and one ways that you all as a company could be communicating better, there are thousands of examples heck one of the easiest would be to do something as simple as this https://trello.com/b/HsMiJggJ/heatblur-public-roadmap and that btw is from a very small developer, but I've seen larger companies do the same. But the lack of comms and then the trickle of well we shared some ss's or a talk wtih a dev that's communications isn't. 7 months and we have 0 featuers from the Roadmap, we don't even have all the proper features that were promised to release 'quickly after launch'. And what's worse Community Managers whom won't actually go to bat to get those answers it seems. One thing I'll say about Rayne is that while we might have butted heads on the old forums once or twice she at least always did her best to get the community answers.

Set to right before talk. They are working with Berkeley on using an objective mirror that already exists for a ground telescope as a SS launched space telescope—several meter dia objective. (7-8m, Webb is 6.5m)