Search the Community

Lately fourms are getting clumped and messy I am meaning There is a Variety of them and they need to be Organized together into Sub-categories of sub-categories So lets start at this standpoint Add-On-Development > Mods But it should be like : Add-On-Development > [Type of Mods, e.g Terrain shader, part mods] And it should be extended for all sub categories of the fourms like Mega-Threads category Mini thread category Types of missions/Challenges category Self promo/ Group promo category etc. Share your thoughts below and give ideas If the Mods see this thread (hopefully this becomes a mega thread full of ideas that they can implement) Signing off Weak Player 5th May 2021

Your drag model has no power over me! Archimedes is a single-seater VTOL SSTO, capable of reaching orbit on Kerbin and Laythe with some dV to spare for docking. It's actually my remake of my friend's stock replica of my 2017 modded craft that itself was lifted off Star Citizen promotional material (talk about a crisis in creative industries...). The defining ring with contra-rotating propellers incurs unpleasant drag and breaking sound barrier is a slog, but the flight thereafter is a rapid and very enjoyable ascent. Same goes for liftoff and landing -- it's got a very low stall speed and you can easily land on a dime in VTOL mode. Powered by 2 RTGs (perfectly balanced). It's a rather useless runabout, except of course if you need to land on aircraft carriers. It's not that large and can hover indefinitely, which makes for nice landings on rough seas of Laythe. I wish I could add folding wings, but it doesn't seem that easy to figure out geometry in stock.

It is simple. Say anything you want that abides with the forum rules in Zalgo text, and please don't make it too crazy. https://lingojam.com/ZalgoText B̶̳̦́e̸͉̰͠͝g̴̢̘͐i̶͖͉̓͘ṋ̴̯̊!̸̦̏!̶̙̂̋ (Begin!!) You do not need to add regular text of what the zalgo text reads as long as it is mostly readable.

The Epstein drive is a literary device, it's not even a theoretical engine. I'm fairly certain it's not going to be in KSP2 and if there are plans for it I'll consider the game an absolute failure. Real talk though, if you want to get to another solar system in a reasonable amount of time you're going to need something which has an isp which is a significant fraction of C. If you use that in-system it will likely trivialize travel but it's worth noting, again, that engines can usually only prioritize thrust or isp so you'll still need landers and utility craft, and you're probably not going to be using something like a nuclear salt water rocket for a lander either because that would constitute landing on a continuously detonating nuclear explosion. The challenge is not going to go completely away.

Honestly I think it is bad. Well it also highlights the currently bad state of development process, so maybe it is good? The reason for me is: Basically every answer about a feature in the post goes like this: Q: "What will be the mechanics of feature X" A: "Well if you do X you have to think about A, B and C and balance them." Then there are some further explanations about A, B and C and how they interact. And that's it. He is usually not answering the question but only explaining some of the things which you have to consider. So the amount of information I got from it was pretty limited because all the talk about "you have to balance different things" is not that complicated actually. Doing the balancing is however difficult and he does not really say how they will even try to balance it. And I think that is what some of us don't like. Another example of this is "New features in 1.5". But they don't say which feature. The feature could simply be the new Unity version. Maybe they do talk a lot. But the amount of information is very limited. Actually I am starting to think that they haven't even started to think about anything on the roadmap yet. Which is probably why we have not seen any gameplay for science yet.

However, considering a few years ago the other "government officials meeting" in Singapore - Their news is quite a lot of nighttime footage of bustling Singapore. And said that "hey look that's Singapore." Meanwhile, many of them have been to China and Russia as foreign students. So, it's very likely that what you think they're going to talk to you about, "I can't find the money for my next meal", but they actually going to talk to you about "how well DJI drones can be modified and carried".

Since I do not really know about you, there's a risk I'm going to talk some nonsense, but on the other hand, there's also a chance of telling something useful. So I a flipped a coin and… Let's go: Chances are that you will miss it in the future. Try to focus on the good things, and try to accept the difficulties as the price you need to pay to getting such memories. This will not make things easier, but it will allow you to build memories that will be precious later in your life. Christmas is a bittersweet time of the year to me - to the point that 4 years ago I didn't mind having to work December 24 and 25 (my son was visiting his mom, so no parental negligence here ). But yet, I have one big regret about this event: I had a friend, one of that friends that you make when you are a teen and carry on for the rest of your life. And by some reason, we ended up getting into the same troubles in life [EDIT: and doing the same things to fix them]. When I fired my family and moved away from them, I took some really harsh years - I made a bold move, I liquidate all my economies buying a home on the Subprime Mortgage Crisis (that also affected Brazil, only a bit later) and I took me almost 10 years to rebuild my finances - the sad fact of life is that somehow my poor economic state leaked out my network and by then all the job offers I got were paying less (because the <piiii> knew I had little to no choice due pressure on paying the mortgage). EDIT: This friend of mine did more or less the same, except by the jobs offer - he did way better than me on this one. No regrets here, I would not had afforded this home otherwise. But it took a toll on my friendship, because I was working all the time, including holidays, for some years to pay all the bills and rebuild my savings (not to mention trying to keep contact with my son, still a kid and living very away from me at that time) - what it means I neglected that friendship, because he was living a bunch of hours away from were I live and I rarely could spare that time at the same days he could and vice versa. What I didn't knew is that he had a serious health condition, and he were risking dying suddenly sooner or later - and, so, every year I failed to spend some days with him on the holidays meant smaller chances on managing to do it next year. And, then, he died. About a week before Christmas. On the very year I was finally sabbatical and could attend something with him. I can't say I regret all that years I spent the holidays working my cheeks out to pay the bills - my son and I have a comfortable life nowadays exactly because I did all that sacrifices. But, yet, I still regret not spending more time with this friend of mine even at the cost of some economical security on the short run. That friend of mine would die nevertheless - but I would have more memories of such friendship, and he surely deserved such. Buy a cargo cart. Second hand, third hand, build one yourself - but get yourself a cargo cart. One that you could use on the streets. I can't emphasise enough how my life got way less hurtful once I started to get old on the very day I bought one for myself. I bought it in 12 instalments to avoid financial risks on the short run, and so I ended up paying almost 25% more than if I had bought it upfront - but even this way, it worth it because I didn't hurt my back anymore since then and, so, didn't had my DayJob© jeopardised by pain in the back (the upper one! ). Check your home's power, you may have fluctuations sporadically on your electrical system. Additionally, do you have a neighbour engaging on ham radio? In a way or another, a HAM radio emitting near you would saturate your WiFi antennas to the point the MCU could not handle the noise and just crash.

Some content has been removed, and a number of posts quoting said content have also been removed. Feel free to state your opinions as you wish. We don’t care if your opinion is for or against. It doesn’t matter. That’s what the forums are here for. What we don’t allow is to make comments about a person, or people in general. Do not tell others how to post, or what to post. Do not make comments about others motives or intent. If you disagree with another person, use facts, logic and reasoning to counter their arguments. Even then, they may still disagree with you, and that’s OK. Reasonable minds can disagree. That means we don’t need to delve into the same arguments in every thread. If a comment had been addressed in a previous thread, it’s often best to reference that thread and continue the discussion there, as the topic has been covered. Granted, given the state of the game right now, that might not give us a lot to talk about. Until we do get more stuff to talk about, rehashing the same arguments over and over won’t do any good.

Welcome. I'll be documentation the colonization of the soon to be released KSS2 interstellar mod for KSP1. This system contains a number of unique and interesting features. Get yourself a nice beverage that tastes almost, but not quite, entirely unlike tea and follow along. I will be primarily focusing on the needful for FTL trips out to the Aethera system. Unless you are doing this in sandbox mode, there will be considerable buildup of infrastructure and resources (particularly graviolium and fusion pellets) to support the 4-9 day trip. Note: My primary mods Blueshift FTL drive KFS gravatic drive Buffalo2 for rovers Pathfinder for habitat DSEV for various ships Other mods: Custom Barnkit: This provides for a Level 4 Tracking Station. You will need this for communication across interstellar distances GU Parts (legacy): In particular, this provides the antennas with the necessary range to talk back to the KSC. This is desired if you are going to do anything with probes. I'm not sure where this can be obtained now. DM me if you need it. Kerbal Attachment System / Kerbal Inventory System : In particular, KAS in conjunction with DSEV has parts that make the construction of a shuttle craft able to carry all the needful to a planet A note for STL cats: Do not think that you can use stock engines for Aethera. If you are new to Interstellar travel, get yourself acquainted with the numerous mods available to provide blowtorches with the required ISP to get you there - and more importantly - settled into an orbit.

At first I thought: "I'll just get to the Mun and back. That's it. Then I'll be done." Then it was: "Just plant a flag on Minmus, that's enough." "Just see how mining and refueling works..." "Just rescue my Kerbalnaut stranded in Munar orbit..." "Just plant a flag on Duna..." And for a while, that was enough. I did the rendezvous and docking tutorial. One go at that tedium was more than enough. I was even getting a bit bored babysitting every single burn. Going elsewhere with robots was unexciting, and flags and footprints meant docking. Nope. Crew transfers or rescue missions for me meant either planting both parties on an airless celestial body, or MAYBE a orbital rendezvous. Either way, it involved a LOT of EVA propellant and a long space/moonwalk. Then I heard about MechJeb, and KSP took over my life again. I got misty-eyed as my three, helmets-off, intrepid explores watched Jool phasing overhead like a giant lava lamp / clock (waxing quarter at nightfall, full at midnight, and back to a waning quarter near sunrise) in the Laythian night. So, Hi. Nobody in my life plays KSP and I just can't keep all this wonder to myself any longer! I'm also too impatient to wait for moderator approval. So now I'm going to write a book (feel free to not read): LAYTHE 1 - 2-part launch - Grabbing (not docking) in Kerbin orbit - Flight to Minmus - Grabbing and refueling from a Minmus miner/refinery ship. - Then off to Jool's SOI! Jool Aerocapture My first mission to Laythe blew up 6 times (and ended up sub-orbital once) trying to Aerocapture into Joolian orbit because: - I designed and built it wrong: Fully fueled lander W/asparagus staging being pushed by a single-engine nuclear intrasolar transfer vehicle (that was also pushing a lab module) with insufficient fuel. - I'm too impatient to figure out all the parameters for the online Aerocapture tools, so I just kept trying different periapsis until I found one that was sorta manageable. - I docked the lander to the NERV-powered transfer vehicle using the AGU rather than a proper docking port. My engineer kept having to spacewalk to reconnect broken struts that I installed post-connection. At one point, she had five minutes to get outside, climb down a ladder, repair the broken strut, climb back up and get TF back inside before they hit the atmosphere. - I didn't put enough AIRBRAKES (and RCS thrusters and reaction wheels) on to compensate for the 10M heat shield waaaaaaay up front. The whole stack (more like a train) was pretty unstable and I just barely managed to keep it straight even after pumping as much of the fuel to the forward-positioned lander tanks as they would hold. The tail got pretty cooked and I ended up rolling the entire ship (during my successful-enough Aerobrake altitude) at periapsis to keep everything from going completely sideways. Something exploded, but I guess it wasn't important. (I don't know how to access mission logs to see what broke). But I made it! With a small retro burn right after exiting Jool's atmosphere, and jettisoning a full RCS tank (whoops, ended up needing that later). Laythe Aerocapture I think I only blew the ship up twice during the Laythe Aerocapture. All this time, I was just guesstimating the amount of fuel I needed to get the crew home. - I also don't know how to calculate delta-V for vehicles before I've dumped some of the stages, so I didn't know how much DV I'd need to push my much-diminished stack home. Laythe Landing Turns out that a 10M heat shield is unlikely to make a stable reentry when you undock the 100-meter lab, fuel tank, and NERV engine that kept it sort of stable during aerocaptures. I was doing okay until I ran out of monopropellant. Then my lander went Mary Poppins on me much higher and faster than I had planned. Funny, but terrifying. Good thing engines have a pretty high thermal tolerance. I think it took me 3 tries to actually land in one piece, on land. I wanted coasts, but I ended up on a mountain after mashing the "LAND SOMEWHERE" button in desperation. Laythe Jool is SO PRETTY! I love the noon eclipses and the giant green nightlight! I landed on the rim of the big crater so it was almost directly overhead. All my Kerbalnauts developed neck problems from looking up. Also 90 degrees is not easy to pan to. I wanted them to have a swim, but I didn't have the patience to watch them hike for however many physics-warped hours it would take to get down to the water. I disembarked all 3 crew at the same time. What could go wrong? Ladders. Ladders that don't work the same way after a save on an uncrewed vehicle (or something). I tried everything to get my crew back onboard, including welding a solar panel as a "catch plate" for them to jump to from the top of the ------ ladder. Didn't work. And that's when and why I "discovered" the gravity hack. Laythe Launch The lander had launched just fine during a practice run on Kerbin. Not so on Laythe. Probably because I used up all my monoprop trying to survive reentry, and none of the ascent engines, I chose, gimballed. Yikes. My engineer pulled off every piece of "unnecessary" equipment she could reach, tried to compensate for a nasty yaw defect by rebalancing the amount of propellant in the various tanks and changing the staging order. It worked well enough that the lander limped to an orbit above Laythe's atmosphere with just one somersault along the way. Needless to say, Mechjeb was useless for the ascent on my catawampus ship, so it was all seat-of-the-pants. The intrasolar transfer vehicle was able to dip down and rescue the MK-3 reentry pod. Yay! Homeward bound! Jool Escape My Kerbalnauts didn't have enough remaining DV to escape Laythe, then Jool, then lower Periapsis to Kerbin's orbit. Not even close. Whoops. MechJeb said I needed 6000 m/s if I waited 300 years. I had maybe 4K. Luckily Tylo happened to be wandering by when I was playing with impossibly-expensive return trajectories. - The first time I got too excited, did a mountaintop-clipping swingby, and later realized I had dropped the ship's periapsis into Kerbol's corona. Whoops. - Second time I got it right-ish and made it back to Kerbins SOI for around 1000m/s. WOOT! And that was that. - I had enough fuel to straight-up decelerate into Kerbin orbit with a 60km periapsis. - Jettisoned the MK3 pod - Had the intrasolar transfer vehicle climb back to a 400km orbit. As a bookend to the crazy mission, the pod bounced off the atmosphere for 3 orbits and ended up running out of battery (I had left the solar panels on Laythe), and coming in totally dead stick with the ablator on its heat shield completely burned up. Still, any landing you walk away from.... especially one with 6K worth of science! ... which I promptly sold out to finance LAYTHE 2: This Time We're Staying! Laythe 2 Design: - Minimize aerocapture. There are sooo many Joolian moons, and sticking a 10M heat shield on every lander just sucks. - Permanent Laythe Base - Miner/Refueling Ship (probably aiming for Bop) built similar to my overpowered Minumus miner and refinery - SSTO dropship with no ablators. It's supposed to go down and land fully fueled, exchange crews, then fly back up and meet with the Miner/Refueler. It will make the transfer to Jool empty and need to be fueled prior to the first drop on Laythe. - Each component gets its own Intrasolar Transfer Vehicle (ITV) with 3 NERV engines and 14K deltaV (when not docked to something) - Docking to be done with REAL docking ports (the large one), except when refueling. The miner/refinery has a couple of AGU's and LOTS of RCS. Launch: - No problems with anything but the ITV's. Those launched fully-fueled from KSP space center and were heavy as sin. Mechjeb couldn't handle it, so I manually pushed them into orbit. The first one took a couple of tries until I got the hang of it. Currently I have all 3 ITV's fully fueled and docked to their respective mission components. I started building this mission with $9,000,000. Now I have $745,000 left. I have full science and am selling 95% of any new research for cash. A lot of the cost came from hiring Kerbalnauts. 3X ITV's each with Pilot and Engineer + Laythe Base: 4 Scientists, 1 Engineer, 1 Pilot + SSTO: 1 Engineer, 1 Pilot + Mining Ship: 1 Engineer (4 stars) , 1 Pilot. So that's 16 crew in total, and I think I hired 12 of them just for this mission. Lots of greenhorns. Current Issues: - MechJeb keeps blowing up mid-burn for long-duration burns. I have good alignment with the Mun to launch the Jool fleet with a nice flyby gravity assist, but I noticed the target drifting on my first attempt and I had to scrap and restart to a pre-departure save point. This isn't the first time this has happened. - I don't think it's possible to do simultaneous burns and keep the fleet together. Even if I could get a mod that let me fly all the ships at the same time, they have different masses and probably won't stay within physics distance during the long nuke accelerations. That means I'll have to space the ships' departures out by 30-40 minutes or so. Not a big deal, but kind of a bummer and a hassle to re-rendezvous outside Kerbins SOI, if I want to for some reason (like . - I am out of money! - Not super confident that I can land the base and the SSTO within a reasonable distance of each other. The SSTO has wheels but I'm not great at building rovers and it's pretty tippy. - KSP has taken over my life!

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

Alright, by soon I guess I meant a month. Time really slips by, doesn't it? *** CHAPTER 8: SETTING THE FOUNDATION YEAR 2, DAY 120 - DRUZHBA 1 Crew: Bardok, Spokoynyy, Alisa For 60 days the cosmodrome may have seemed completely silent. But inside, it was the perhaps busiest place on Kerbin. Workers for both the CKR Space Program and the Korolev Design Bureau (KDB) have been working hard day in and day out on the CKR's newest manned spacecraft: the Druzhba Spacecraft. The Druzhba Spacecraft is capable of carrying three Kerbals into orbit at once, complex rendezvous maneuvers, and even has the capability to dock to other spacecraft! The CKR hopes to use it in future manned missions to the Mun and Minmus. The rocket, called the K-8 Druzhba, has had a... complicated design history. Originally the rocket was going to be a standard K-8 Grom. But simulations showed that the rocket would be too top heavy, and go crashing into the ocean after the gravity turn began. So, instead, a whole new rocket was designed. The rocket, while sharing some of the core design design choices of the K-8 Grom, is much more it's own thing now. However it's still similar enough to be part of the K-8 lineage. And, guess what it includes now. That's right, a Launch Escape System (LES)! The LES is designed to fire it's motors away from the rocket, carrying it to a safe distance to deploy it's parachutes. Originally, the abort systems on our spacecraft would just be the landing retro-rockets, which could hopefully pull the command module away, and then the Kerbonaut onboard would possibly be able to jump ship manually. And, according to simulations, this would probably work only about 60% of the time. Not good odds. This increase of safety aboard our spacecraft will hopefully carry on to the future, providing more reliable spacecraft for long term missions. Only time will tell. Anyways, where were we? Oh, right. Off with the mission! "Engine ignition, and liftoff on Druzhba 1!" - Gen Kerman "Go for booster sep." - Gen Kerman "Roger, booster sep." - Bardok Kerman The spacecraft fairing separate, revealing our glorious machine! "Druzhba 1, you are go for orbital insertion." - Gen Kerman "Shkiper reignition successful! We are on our way!" - Alisa Kerman Stage 2 is ejected, and Druzhba 1 is now floating freely in orbit! The crew look down on Kerbin in awe, and stretch their legs in the increased space inside the spacecraft. Due to complaints from crew during the Zapad and Zakat missions of the very little leg room during their missions, engineers added a little extra habitable area sort of like another module, and the crew can move into and out of the area at will. Also, this extra habitable area doubles as an airlock! Instead of carrying around that bulky inflatable airlock, Druzhba flies with an airlock built into the spacecraft! Maybe it's still not all that practical, but it's better than that crappy inflatable one. Now, back to the mission. Once in orbit, Druzhba 1 will perform several tests of its systems. The first of these tests will be a test of its monopropellant systems. This will require the spacecraft to fire it's thrusters, forward, back, up, down, and side to side. This is done on Flight Day 2. Que the montage! Once done that, Druzhba 1 will perform an inclination change to align with Minmus's orbital plane on Flight Day 3. This will really just be a test of how well the Druzbha's engines behave on orbit. Que montage again! "Inclination change proceeding smoothly, mission control." - Bardok Kerman Oh, I guess there wasn't much of a montage there. On Flight Day 3, Bardok steps into the habitat/airlock, and upon opening the hatch, his breath is taken away from the completely unobstructed view of Kerbin. "Looking down at our planet, I've had an amazing realization. A realization that make shake our entire world view. I'm in space, and those losers aren't! Haha, I win!" - Bardok Kerman While on EVA, Bardok has to make a visual inspection of the spacecraft. Make sure everything stayed in place and what not. Everything looking good, he takes a chance to look out towards the Mun. Someday, he thinks to himself. Someday I'll be there. Maybe he will. Only time will tell. After about 15 minutes on EVA (the longest yet!), he makes his way back aboard Druzhba 1. He says that it was sad stepping back inside the spacecraft, but hopes that his EVA experience will not be his last. His optimism is paying off though, as the CKR sees him as a valuable pilot in the future. Druzhba 1 spends another three days in orbit, collecting data and photographing Kerbin. However, as missions do, it eventually comes to an end. Druzhba 1 faces its engines retrograde, and begins its journey back down to Kerbin's surface. "Mission control we are beginning our de-orbit burn. Ignition of the engines was successful." - Alisa Kerman Druzhba 1's main command module now makes the trip back alone, as it was the only part of the spacecraft meant to return to Kerbin. "Chutes deployed successfully." - Alisa Kerman "And a perfect inflation! Prepping landing retro motors." - Alisa Kerman And like that, Druzhba 1 safely lands in the deserts of Kerbin! Rescue teams are quickly dispatched to their location, so they should be back at the cosmodrome in a few hours. Druzhab 1's success means that future missions are coming, and continued testing of the spacecraft may finally prove capable of the Mun and Minmus flight it was meant for. All we have to do is see where the program goes. *** YEAR 2, DAY 130 - MUNA 9 While the crewed division was quite busy with Druzhba, they at least had a plan with what the payload looked like. Muna 9 was the exact opposite. The payload was in a constant development hell, and coupled with the current cosmodrome expansions, issues piled up high. Engineers, scientists, and even janitors were throwing around ideas for what the actual lander should look like. The lander had 500 different designs thrown around, some cheaper and more realistic, and others so outrageous and bizarre that nothing short of mining out every resource on Kerbin would make them possible. In the end, a "little" two stage lander was picked. The probe will fly to the Mun, do some science experiments, pick up some surface samples. and then return back to Kerbin after a day on the surface. Pretty straight forward... on paper. "Liftoff on Muna 9, on its journey to and back from the Mun!" - Gen Kerman "Clean booster sep!" - Gen Kerman Muna 9 enters LKO with no error. But the journey's not over yet. Mission control immediately gets to work setting up the spacecraft's TMI maneuver, and before you know it... "We are go for TMI!" - Gen Kerman We are go fo- hey! I was gonna say that! Muna 9's deep space tug stage finishes up the burn, and Muna 9 enters the coast period. The probe will be put on hibernation mode to save energy on the way there. "We are go for our MOI burn." - Gen Kerman "Roger, re-igniting LV-909s." - Kris Kerman Muna 9's de-orbit burn "We are 700 meters from the surface, continuing suicide burn." - Gen Kerman "Contact!" - Gen Kerman Muna 9 is now standing on the Munar surface! However, the job is STILL not done, as now Muna 9 has to collect science. A lot of it. It's brought practically the whole suite of science experiments, and most importantly Mun rocks are picked up. Many Mun rocks. Scientists back on Kerbin simply drool at the thought of having their very own Mun rocks to pick at and study, and if money was still a thing in our society, we're sure these rocks would go for millions. After a day on the Munar surface, the upper stage of the lander is separated and fires it's engines, beginning its long journey back to Kerbin. Interestingly, engineers wanted to launch the spacecraft into a retrograde orbit. This was essentially a stress test of all of the lander's systems "Ignition of the ascent stage engine. We're on our way home!" - Kris Kerman "Kerbin return maneuver in 3,2,1... re-ignition of ascent stage engine, we're on our way back to Kerbin." - Gen Kerman The return capsule has quite a fiery re-entry, entering Kerbin's atmosphere at speeds of over 3,000m/s! "Chute deployed, and we are back home!" - Gen Kerman Yes, after 4 days in space, Muna 9 returns with the very first samples of the Munar surface! Recovery teams quickly circle the spacecraft, pick it up, and carefully extract the load of samples the spacecraft collected. These will be handed to R&D immediately, who will study the rocks and further distribute them to other labs around Kerbin. The data collected from these rocks will give us further information into not just the birth of the Kerbin system, but the birth of the entire Kerbolar system! It's an exciting for the CKR Space Program, and more exciting are certainly to come. *** YEAR 2, DAY 148 - YEVA 1 Kerbalkind once again prepares to extend its influence even further than the Kerbin system. This time, we have our focus set much closer into the Kerbolar system. Her purple majesty, Yeva. Many have speculated what may be waiting for us on Yeva. Some say that, due to it's purple color, it may be very similar to Kerbin. Couple this with the fact that Eve is a similar size to Kerbin, Kerbals who suspect this may not be too far off. Yeva 1 is pretty much a sister probe to Duna 1, but with... oh, no, it is the exact same probe. With the exact same launcher. Hey, if it ain't broke, don't fix it. "Liftoff on Yeva 1, carrying Kerbalkind to the planets!" - Gen Kerman Is this just me, or is it kinda funny to see the hammer and sickle on the side of a building meant to look like NASA's high bay assembly building. Yeva 1 finds itself racing a comet on liftoff. Yeva 1 firing its engines for orbit Once in orbit, ground teams immediately begin preparing for the burn to Eve. This is easier said than done. At the time of launch, the Mun was positioned in such a way that it would always get in the way of every burn we did. And its position was annoying enough that we couldn't use this to our advantage at all. In the end, spamming skip orbit enough got us a good position for a maneuver. And now... We're off to Yeva! "Setting probe to hibernation mode. Good luck, Yeva 1." - Gen Kerman *** YEAR 2, DAY 160 - MYATNYY 8 Myatnyy 8 will follow the exact same mission profile as Muna 9. Nothing else to add. The interesting thing about this mission is more the destination itself. The past few missions to Minmus have shown that Minmus itself is an interesting place. Despite not having an atmosphere, Minmus does in fact have weather! However, the exact way this happens is quite a mystery. Samples of both Minmus's "clouds" and surface ice will be collected, and scientists on Kerbin will use this data to understand more about Kerbin mintiest and most mysterious moon. Launch Sequence Once Myatnyy 8 enters orbit, well, you know the procedure. "Go for TMI!" - Bobak Kerman Myatnyy 8 begins the coasting period of its mission. I will tell you all that I did not get any pictures of the whole orbit process around Minmus, as at this point I was just so sick of the mission. I already had to redo it twice, so I gave up on screenshots and just flew the craft. But I did get pictures of the landing, and that's the cool part. "We are beginning our descent down to Minmus's surface, I need all controllers on standy in case anything goes wrong." - Bobak Kerman "1km up, speeding up suicide burn." - Kris Kerman "Almost there..." - Bobak Kerman "Contact! Myatnyy 8 is standing on Minmus's surface!" - Bobak Kerman After a quick celebration in mission control, work begins on running the experiments on board the spacecraft, as well as the collection of samples on Minmus's surface. After a day on the surface, the ascent stage fires its engines and Myatnyy 8 begins its journey back to Kerbin. Another success under our belt! Myatnyy 8 is quickly recovered, and the mission comes to an end. Myantyy 8 has brought back perhaps some of the most important data in spaceflight to date. However, our engineers and scientists have one more idea for Munar and Minmus exploration, and they expect it to fly sometime late in the year. You all will have to wait to see that. *** YEAR 2, DAY 180 - DRUZHBA 2&3 Crew: Dzhebediya, Bob, Bill; Valentina, Stadun, Derdas We always talk about the capabilities of the Druzhba spacecraft, now it's time to put them to the test. Druzhba 2 and Druzhba 3 will be a test of rendezvous and docking. The spacecraft is, after all, equipped with a docking port. Once docked, both spacecraft will spend a week in space together. Dzhebediya and Valentina will also perform an EVA together, much like Zakat 3 and Zakat 4. Afterwords both Druzhbas head back home one after the other. It's a pretty straightforward mission. Also, due to the expansion of the Kerbal Cosmodrome, pieces of the spacecraft no longer have to be sent to the Dessert Cosmodrome for launch. All of our rockets can be sourced right here. It really streamlines the whole assembly process, as well as save a lot of fuel for the spacecraft during rendezvous. Granted, the changed inclination would be good to do further stress tests on our spacecraft, but really it's better for the engineers this way. The Dessert Cosmodrome is better for satellite launches, anyways. "Liftoff on Druzhba 2!" - Gen Kerman "LRBs depleted of fuel, separate now Druzhba 2." - Gen Kerman "Clean sep, Baikerbanur!" - Bill Kerman "Ignition confirmed on stage 2." - Bill Kerman "Alright mission control, starting our coast to apoapsis." - Dzhebediya Kerman "Rog, Druzhba 2." - Gen Kerman "Druzhba 2 orbital entry established. Good flight!" - Gen Kerman "Alright, thanks Baikerbanur! Tell Druzhba 3 that we can't wait to meet up with them." - Dzhebediya Kerman "Will do." - Gen Kerman With Druzhba 2 in orbit, it's now Druzhba 3's turn to liftoff from the Cosmodrome. "Woooo, I love that feeling mission control! You gotta send me on more missions!" - Valentina Kerman "Clean booster sep, mission control!" - Derdas Kerman "Good to hear! And Druzhba 2 reports that they can in fact see your contrail from liftoff!" - Bobak Kerman "Orbital entry established, Druzhba 3." - Bobak Kerman "Rog, Bobak." - Valentina Kerman With no time to waste, Druzhba 3 immediately gets to work setting up their rendezvous with Druzhba 2. Inclination changes, rendezvous burns, the works. Before you know it, they're already at the spacecraft. Slowing down at rendezvous. "Approaching Druzhba 2." - Valentina Kerman "Docked! Miss me, Dzheb?" - Valentina Kerman "Tease me all you want, I still hold the title for farthest flying Kerbal." - Dzhebediya Kerman "For now." - Valentina Kerman Dzhebediya and Valentina face off outside their spacecraft. For the next five minutes, the words "I'm" and "better" were exchanged in that order continuously. Dezhebediya and Valentina boarded back into their spacecraft after a very mature discussion, and Druzhba 2&3 stayed in orbit for the next week. During that time, much of Kerbin's surface was photographed, and the crew played a game of Linkor, perhaps one of the best board games the CKR had created. It's not a very eventuful mission otherwise. After the week is over, both Druzhba 2 and 3 separate and go their separate ways. Druzhba 2 on re-entry, with the airlock module burning up behind it. Druzhba 2&3 with their parachutes deployed We've proven long duration spaceflight, and we've proven that two spacecraft can dock together in orbit. But what if we did... both at the same time?

Answers to some questions we had to skip over during the AMA but I still wanted to get to: Alexoff What percentage of the parts in KSP2 was created by you personally? Depends how you measure it. Effectively zero because I don’t do the asset work, by one definition. In terms of maybe inception/concepting, in the EA release I’d say I had a hand in about 10%? What is the largest part will be in KSP2? The largest part I have in my list right now is in the 80m+ size category. It’s a lot harder to measure these colony parts versus vehicle parts though… Do you participate in the creation of parts for the colonies? I participate in the concepting and design phase yes. It’s where I’m focusing a lot of my ‘thinking time’ these days. Colony parts are both similar and different from vehicles – in what they look like, how they assemble, etc. As we get to those milestones we refine our designs from player feedback. How difficult is it to add a new part to KSP2? Is there a big difference? Is it harder than creating a new part for KSP1 for a modder? Most things in KSP2 end up being more complex than KSP1. As an example at a basic level the PBR shading model that we use requires more texture maps than KSP1. That is mitigated by having access to internal tooling and a faster iteration loop (click Play in Unity rather than load the game). Stephensan is there any more concepts for more air-breathing engines like the J-90 smaller or larger There’s been team interest in larger air breather engines, but as always that’s not so simple – adding an air breather of say, 2.5m size requires us to also look at the supporting parts in that size, like intakes and cockpits, so the player can have a good experience when using those engines. That balloons the required work significantly. I would want to push out the different technologies rather than footprints first. Nuclear jets, propellers, all unlock interesting new player stories! is there gear that is going to be angled from the fuselage not straight up and down and finally more tires/wheels in the concept stage, or even remotely thought of... We definitely have people who want that on the team . LunarMetis How will the sizes of different stars be scaled with respect to Kerbol? Will they be scaled at 1/3 their real-life analogs like Kerbol and the Sun? Specific scaling of the actual meshes is less important than defining their specific insolation numbers for input into solar panel math but yeah they’ll be Kerbol-relative. How do you plan to implement proper motion of other star systems, and how do you expect that to add to the challenges of interstellar travel? Hah, interstellar travel is going to be hard enough already. Proper motion is something we need to balance carefully there. Pthigviri Hi, Chris! Im sure you've been deep in colony part design. What are your thoughts on greenhouses and simple life support with snacks for example? How do you see conveying that colonies are both real places where kerbals live and 'working machines' much the way vessels are? Honestly I don’t like basic life support (by basic I mean something like having Kerbals on a ship consume a resource). I’ve played all* of the KSP1 mods for it, and I haven’t found something that is interesting and holds my interest beyond frustration for more than a few hours – just not my cup of warm beverage. More seriously though, systems like this need to have a bunch of considerations: - They need really carefully crafted player stories. Those stories need to support lots of different player archetypes – not just advanced players. - They often should work on a carrot rather than stick-based approach. KSP has a lot of sticks right now. - They need scalable solutions that are plannable and toolable. That’s a big thing and that’s where LS gets expensive in dev-hours We have some things in the works around Colonies that ape some of the ‘results’ of life support, which I hope will get at the idea of colonies being a little more kerbal-involved than just plunking Kerbals in a command part. * I think all? It has been a while, maybe some new ones have cropped up. PDCWolf Has the concept of heating changed at any point based on the feedback posted to its thread? I read every post in the thread, which was nontrivial because it was a long and uh, vibrant thread. The short version is no, the long version is yes but… A lot of the interesting discussions sat around things that are further down the roadmap, and they provided us with a couple additional things to consider. Interestingly, the player stories we have were well aligned with the comments that I read, but the way the player stories were addressed were not unanimously approved. That’s fine – part of the EA conversation– and in particular with a lot of discussion being on items later in the roadmap, this makes me confident in the iterative model. We’ll get the basics of the system focusing on reentry stories out to everyone. We’ll evaluate how that works with the playerbase. As we move towards the next milestones, we can use the information encoded in the thread, which I’ve collected internally, to make sure we’re making choices (engineering or design-wise) in conjunction with the feedback from reentry to get good solutions. One thing that jumped out for me was that there’s a lot of talk about macro vs micro solutions. I’ll be the first to admit that the current solution is a macro solution. So future design work will probably focus on whether there’s more microscale interaction to look at. If I know the peak or average specific heat flux a vessel is gonna go through on its final orbit/landing spot, what stops me from just adding enough negative heat flux parts to counteract it? Nothing. That’s what you should be doing. Of course, it’s not really that simple. If this is atmospheric heat from going fast, adding a big radiator is likely to just increase the amount of next flux, because it has a large surface area. Most heat mitigation tools need something else too – a radiator might need electricity, which means you need to supply that, which will enforce additional constraints. Considering its possible uses on the automated logistics network, long missions, and just straight up anything that only requires time to pass, how do you balance not timewarping versus just letting things happen in ultra-fast time? These are the best questions because they’re the hard ones. Often we trend towards supporting a player path that doesn’t reward excessive timewarping, but doesn’t exclude it either. A good case study is resource extraction and deposit concentrations. There’s definitely fun in seeking out and finding the best deposit for mining. Obviously though timewarp makes that kinda moot in timing. You could just start mining a hypothetically low-grade deposit and warp for 50 days. That tells us that time and rate -based mechanics need to have more to work well. A specific example here is that a newly accessible resource should be constrained differently – challenging location, resource transport limitations, etc. We try to move the real player decisions to things that are interesting with and without time as a mechanic. Mostly hypothetical examples, but here’s a few ways of thinking of these things on top of my head: Put a locational constraint on something. If you need to do something in orbit over a specific part of a planet, make it take longer than the average orbital cycle. This might encourage a player to put a satellite in GEO orbit over that place. If you do the work to put it in GEO, you get the benefit of being able to timewarp. Use binaries instead of gradients. Does ore concentration really benefit from a really detailed gradient from 0.0001% to 100%, or can you look at it as a yes/no? Trade that, see if you’re damaging player stories with that simplification. Use supporting systems. Sure, you could mine that deposit at high timewarp. But the deposit is on a planet with a day length of 200 days, and you need power, and the area has no fissionables. How are you going to power it? If you solve this problem, it is satisfying and you get a cookie. You did the work, enjoy your timewarpable extraction! These are really big problems we look at for all of the more complex systems because hey, an interstellar transfer could be 100 years. Players will timewarp that and that’s… the whole length of a KSP1 campaign. Fun with and without timewarping like this is essential. Socraticat What are your favorite tips and tools for new modders? My biggest tip is to do what you want to do and not focus on what others want. Lots of the most creative KSP1 mods didn’t hitch themselves to any one concept of the game, and that’s what made KSP1 modding so successful. You want RO? You’ve got RO. You want to launch kerbals in a cardboard box rocket? That’s there too. You want life support? Oh hey there’s about 5 different concepts out there to pick from. Also don’t try to form a team day 1 . Get some experience, release some stuff, and the team will come to you! Tools - Blender is an amazing piece of free software, and there are a ton of good coding tools out there for the software-minded as well. It has never been a better time to be an independent purveyor of these kind of things, you don’t need to suffer through e.g. gmax or the trial version of Milkshape3D anymore. Royalswissarmyknife Is there any consideration of 1.875 meter parts Building out a whole family of 1.875m parts that includes the core stuff (engines and tanks) plus the necessary ancillaries is a lot of work and not something the team is committing to right now. Strawberry While we do know it wont be added in the short term, the team has previously been wishy washy if radiation/life support will make it into the game. Are these topics something that the team has decided wont be in the game until maybe after 1.0, something the team has a firm answer on what they want to do with but does not wish to disclose it (though if you do wish to disclose please do), or something that the team is geniunely undecided on See answer to Pthigviri about LS stuff. Radiation is a bit more interesting to me because I have a fair bit of history in mods with it, and I’ve eagerly assimilated the early concept work the team has done for KSP2. There are two tradespaces in terms of vessel design, point sources and ambient radiation that we at least nominally want to think about including. Ambient radiation is basically a time trade. How long can you spend in a radioactive environment? You can throw things like radiation shielding, storm shelters, etc but ultimately it all comes down to time to Bad Things. It’s harder to help a player to plan. You have to give them tools to determine how much radiation there is around somewhere and how to figure out how long they can spend there, etc. Point radiation is nuclear engines and reactors. This is harder to implement but is definitely relevant in terms of craft design, because it is a big part of why fictional interstellar ships look the way they do. Interestingly it is easier to model and communicate to the player because you know lots of the variables at vessel build time. One of the messy things here though is that as soon as you throw in radiation, you railroad players into building ships with nuclear engines in a very specific way. We have to craft a solution that hits a nice middle ground. See this comment. I’m candidly going to say that we don’t have the ideal solution in the bag right now – but that’s what EA is all about. I’m sure I’ll write some kinda discourse on radiation eventually for a dev blog and everyone can weigh in on why I’m wrong :P. Pokaia Are there any features you modded into KSP 1 that you are bringing into KSP2? What is your favorite? I wouldn’t want to port anything specific without a good justification, but I really want to bring in more planning tools. The only ones I built were around heat and power management, but yeah. Something like that. One of the cool things about this job is that I get to start again, so to speak, with the support of people who have been in the industry for a while. So if I want to bring in nuclear reactors, I can take my concepts from Near Future Electrical, talk to some Real Designers ™ and get their opinions on what works and what didn’t work, and make something cleaner for KSP2. Filip Hudak What are next parts that are comming into the game? Science parts! But also those gridfins we teased a while ago should appear. stoup Are there any kinds of parts you're going to be adding to KSP2, that as far as you know, weren't even really available as mods in KSP1? Some unexpected bits and bobs, maybe The entire colony loop is more or less stuff that was never really available in KSP1 mods from a system perspective. Modding KSP1 was really wide though – hard for me to say. Kalessin1 Are all parts from Your mods to KSP1 will be implemented in KSP2? Especially large solar panels, station parts & MK4 spaceplane? Hah, no not at all. I like to re-use concepts, but this is a great opportunity to start afresh and to fix some stupid things I did in development of those in my mods. Gotta somehow get more Thunderbirds in the game though. Cocoscacao Will we get all size variants for all parts? Example, hydrogen tank with the smallest radius, only has long option. Why "semi procedural" parts weren't considered, where you can select a tank and set its lenght/radius to some of the predsfined available values? You definitely have me to blame for no smaller hydrogen tanks – just don’t think they’re useful with the low density. Why wobblyness still exists? What are design choices and reasons to keep it, if there is a way to remove it? If there is indeed a way to remove it... I have a post on my thoughts about this as a player. Generally though – it’s not where we want it to be and we’re trying to figure out how to get it there. That’s extremely non-trivial, there are various posts in the forum that do a good job of explaining some of the whys. SAP KSP How advanced will the Kerbal's technology be, will there be very advanced parts such as anti-particle devices? We’ll definitely get way up there in the tech tree. I do want to keep those under wraps for now tho. Infinite Aerospace Are you able to tell us 'something' about science and career modes, there's been an alarming lack of any real information regarding the two. Well! Science mode is cool. It is designed to be a progression-based mode that takes the aspects of KSP1’s Science mode that we like and build upon them to create a solid progression experience that has higher level of agency and approachability. You can expect the return of the experiment loop, with changes, and the inclusion of a very different mission paradigm from Career. One of the fiddlier aspects of the last few months has been taking our full set of concepts from KSP2 1.0 and figuring out how they break down into the early access structure. Delving deeper, what can we expect from science mode, is it the same ‘click and reward’ setup as KSP1 or are you going for a ‘science over time’ sorta approach more akin to Kerbalism? The system as designed is independent from things like Kerbalism, but you could say there’s some concepts that aren’t dissimilar in there. It has been a while since I have played with that mod tough. We definitely want to get to more player agency in science. Instead of it effectively being mandatory to hide 4 tiny science experiments on every craft you send anywhere, we want you to make a more informed decision about what you take with you, and make the actions you take a bit more specific too. I should write a little dev blog on this. What sort of part numbers are we looking at, is there going to be the same sorta number of experiments as KSP1, or significantly more? What does that entail, are the experiments something more dynamic this time, looking at things like NASA’s GRACE mission for example? I should definitely write a little dev blog on this. Similar number, more impactful. In terms of career mode, is there a more dynamic contract system in place rather than the rather ‘rinse and repeat’ system of KSP1? There’s still going to be funding, reputation? I believe we are on record about not using the same framework there. Funding and reputation weren’t our favorite systems and didn’t have the gameplay impact we wanted. As a side question, stations and bases. Are these going to have something of a real use this time around, given that stations were limited to more or less just fuel depots in KSP1. I'm thinking more along the lines of long term research projects, with big pay-off for significant durations of time. Is there some sort of requirement to resupply the stations, perhaps required crew rotation, stuff like that? The progression we want to deliver for bases and stations mirrors IRL conceptions about how these things should work. You will start out with outposts that have limited utility – let’s call that KSP1-like. Fuel depots, maybe comms relays, etc. As you progress through the tech tree, you’ll get access to stuff that provides them with greater utility. That’s shipyards and docks, fuel factories, launch pads, etc. Eventually you’ll get the biggest parts, which are mostly focused on giving you the full capabilities of the KSC at a colony. A core piece of the utility in my mind comes with resource gathering (which is a ways off in the roadmap,) when the specific positioning and configuration of a colony becomes really important. Placing a colony with good access to progression-related resources and having easy access to heat management/power sources will allow you to build specific functions and cool vibes into each colony. Crew rotations and resupply are not currently something we would want to enforce. I hope that when we get resources and delivery routes fully operational though, that this is something modders will hit really hard because the framework of stuff like delivery routes will be there. TheAziz Pineapple on pizza or not? I don’t like it, but recently I was made aware that liking baked potato pizza was weird so I can’t really judge. Superfluous J Having done both, what do you think are the main differences between adding a part (or set of parts) to the game as a modder, vs as a paid member of the team? Accountability and justification are big. It’s easy enough to incept a new part as a generalist modder. I just say that I want it and make the time to model/integrate/QA it myself. In a professional context, that involves the use of studio resources and we have to balance that versus other work we want the staff that would be executing that work to do. A new part needs a concept, it needs artist time, it needs designer time, and it needs QA time. We have to really be sure we want a part before we do it. Pat2099 Will the salt water nuclear engine make a return? I’d like instead introduce the artisanal nuclear fresh water engine, using only the purest Vall-ian glacial meltwater and hand-centrifuged Pol-ian uranium. But yes. TwoCalories You've made several mods for KSP1 in the past. Will parts from any of those mods, like Restock, Far Future Tech, Near Future Tech, and Stockalike Station Parts make a comeback in KSP2? Never exactly, though there’s similar roles. I have a 3.75m command pod in Near Future Spacecraft that is pretty similar in role and profile to one in KSP2, for example. What was the transition like going from being a modder (or, more honestly, a pillar of the modding community) to working on the development team? It was really weird to come into the project and find pictures of my work as references in the team wiki. But it has been great. We have a really solid team working to replicate what amounts to 10 years of hard KSP1 development work. Ways to go though. Justspace103 Is the same approach to design & diameter consistency going to be applied to KSP2, similar to what you did with ReStock? This is already ongoing – we sneak in consistency work where we can depending on the team’s bandwidth. We’ve sorted at least a dozen parts since EA release. The part-ists are probably sick of my hOw’S tHe SiDe CoUnT questions. Mushylog Hello Chris Adderley. How detailed will the reentry VFX be, on the vessel's parts? Will we be able to see the heat propagate relative to what part of the ship is hitting atmosphere the most? (As in, will there be a glow on the entire vessel that spreads as atmosphere becomes more dense, in a reentry? Or will the heating visuals display in every single parts of the vessel individually?) I will leave this one completely to allow future dev communication to represent it. It’s really cool and I think the path to get to what we think is our final solution would be a fun thing to tell people about. Heretic391 What steps is the development team taking to make KSP2 accessible and appealing to new players who may not have played the previous game or are new to the genre? Obviously, the tutorialization we worked into EA will continue as we add new systems. Eventually though we want to enable players to do more with the same skill level. There’s some really big difficulty jumps in the game, and while we are more confident in the ‘get into orbit’ jump, we still need tools and strategies to tackle the next one, which I’d peg as going to another planet. After that, go to another solar system. I saw a really cool concept from the UX team about this last week which made me squeal in happiness. I hope we get to it. VlonaldKerman Can you give some more detail on the supply route system? Can you automate the construction of supply vessels, or does a vessel have to be built to assign an automated route to it? In other words, when the route is finished, does the vessel have to be intact? That system is a ways off and while I think our concepts are pretty solid, they have to survive another round of detailed design, and the EA feedback we get through that time period. So let’s save that for a dev diary later. Intactness is an interesting thing that the system does need to consider. On the one hand, we obviously want you to not crash your ship to create a delivery route. However, we also don’t want to disallow multi-stage approaches to routes. You should be able to create a delivery route with a two-stage rocket. It won’t be as resource effective as a single stage one, but particularly for routes that launch from high G or atmospheric planets, we need to have a design that eventually supports this. It is possible that this could be delivered in phases for effective development – consider a V1 of routes that focuses on single-stage-to-place deliveries and a V2 that is more comprehensive. Also, will metal to build basic rockets and methalox fuel be limited in the early game, or will there be infinite fuel on Kerbin? If so, how is this balanced against the ability to send an arbitrary number of refueling ships to a colony, as opposed to what I think you probably want to encourage, which is ISRU? If you want to create an interstellar empire based on shipping methalox light years from Kerbin, I don’t want to discourage that. That’s kinda cool and would be a big investment in player time and resources, so we would reward that by not constraining it. You’re also probably not going interstellar on methalox… so you are going to be incentivized to not do that in a particular way. Psycho_zs In KSP1 some realism enhancements can be achieved with a relatively simple MM patch, because those mechanics are already in the game, but not used in stock (i.e. engine spool up time, throttle depth limits). Are there any realism mechanics that you wanted to put into KSP2, but couldn't because of the gameplay balance? Any of those that you or somebody else sneaked in for config tinkerers to find? What are the limits of stock realism options and will there be something extra under the hood, in a space between stock and full blown mods? Yeah some of those do exist in the game. Part of that comes in the engine module that supports most of the ‘fancy’ stuff from KSP1 like spool up. As for new things, yeah I’m pretty sure there are some things we’ve asked for but not ended up using. I can’t really think of them off the top of my head. NovaRaptorTV What's your favorite part of the game to work on? I really enjoy the small part of my job that’s artistic – making sketches, concept models and stuff to pass over to the team is quite fun. I also like to make the project plan go brr, ticking off things on milestones makes me happy. M4D_Mat7 Will there be hydrolox fuel type given how we already have hydrogen as a fuel type for nuclear engines? If we get the NERV-US in that will be a need for Hydrolox there. jaypegiscool Are there going to be more design challenges implemented with more fuel tanks and such? E.g. will there be fuel tanks that don't have a centered COM? Fuel tanks are a basic component of ships that we don’t want to have players need to manage too much. There are some interesting trades about that for far future fuel types though. As we get there we’ll examine if they’re interesting to support or whether to leave it to the modding community. norminaluser Are there plans for adding nostalgia/legacy parts? aka, adding some revamps of the KSP1 parts? I mean, some old users would be delighted with these. I’d argue that anytime we have a part that comes from KSP1 it is already a revamp, so I’d be interested to understand what that actually means to you. barrackar In the upcoming Science update - does conducting experiments give you science points? Will there be a tech tree? There will certainly be a tech tree, and science points! For colonies, do we know if/how lifesupport will work? Simple colony expansion or more complicated management of individual resource routes? Will users be surveyed for whether or not we want lifesupport? See answer about life support from Pthigviri. For interstellar, will there be astronomy aspects required to detect/map the other system(s)? Fun things for the future! I can’t be more specific at this time. poodmund Why Quenya and not Sindarin, Telerin or Noldorin? Do you have something against Elves that went to Middle Earth? By the Ninth, I must know the answer. The real answer is that the corpus of Quenya is a lot more complete than say, Sindarin, so when I went to try to learn it, that’s where I went. piotr.__ What real life concept / scientific work gave you the most headache? Is there something you are really proud of, that your creations will introduce to players? Heat and radiation are the hardest concepts to map to gameplay, so I’ll say those. Every time we get a system that is showing a new scientific or engineering reality I get excited. Example - with 0.1.3’s new extensible engines, we’re showing the community that doesn’t follow aerospace precisely than extending engines exist and are useful in some ways. bygermanknight#0 (554725693590732801) Are we going to get some engines like the Orbital Maneuvering System from the Space Shuttle because the current (and only) monopropellant engine is not very liked among the community. The Puff is pretty OMS-like. I’d turn that around and say that something more conventional in terms of attachment modality is probably more useful than something that tries to ape the OMS a lot. M4D_Mat7 When will we see more interiors for the command parts? We want to fully define the IVA system and experience before we commit to more interiors so we limit possible rework. Will the team add RCS to the space shuttle front cockpit section eventually? This is not planned. suppise How do you go about balancing new engines with twr/isp/cost/size/etc? Check out the Engine Archetypes dev blog for the framework – but the overall concepts we use are related to… · Spreadsheeting versus comparables, · Looking sneakily at how mods have done things when possible, · PLAYTESTING Follow up question, with the full 1.0 tech tree, aside from cost/resources, will there be a reason to still use the basic methalox atmo/vac engines we have now, over newer engines/fuel types? Resources accessible to a colony will drive this. Say you’re mining a frozen ice ball of a planet with water ice – that’ll be something that would drive you to hydrogen engines. However, maybe you’ve got a colony on a world with trace atmosphere of CO2 – that might make methalox attractive. mgb125 I routinely exceed 150 parts for spacecraft in KSP 1, would the team consider a higher baseline for the “typical” vehicle? Do you have stats on how many parts players use for their EA KSP 2 craft? We are building our analytics pipeline to give us that data. We have lots of legacy data from KSP1 to help us in the meantime. sylvifisthaug So someone in the KSP2_general channel have pointed out that the "brass line" vacuum engines in KSP2 have some resemblance to your previous modded content as Nertea. How is the process like with implementing these similar designs into KSP2? Do you do it entirely by yourself, texturing and all? Do you do 3D models, coding, or maybe nothing? You just manage the team to do it? I do very little of those things. Effectively I… 1. Try to incept the concept and discuss its utility with the rest of the team, 2. Make sure we can support it with the engineering that has been done, a. There’s a whole side thread about when we need to ask for new gameplay functions. 3. Make concept models, 4. Hand it off to the art team, 5. Coordinate other things we might need for the model – VFX, SFX, animations, 6. Come back once we’ve got all that sorted and do the final integration into the game, and some tuning later on. If you as a team manager delegate others to recreate your parts, how does it feel to let others rummage with your own engines? To be clear, we’re not really recreating parts – when things are similar, there’s often just convergent evolution. But our art team is equal to the task!

Those USAAF guys had no real choice. Their casualty rates were insane, too. I went to an 8th AF luncheon, and sat with a few old guys. A fighter pilot (P-47) gave the talk that day, and he talked about them all being kids and that they felt invulnerable. He said, "If you had told us at the briefing early in the morning that 9 out of 10 of us were not coming home, we all would have all looked around the room and thought, 'You poor bast*ards'."

This topic is used to talk about flags created by everyday people and the largest modders in KSP alike! We welcome any flags, as long as they are Safe For Work. I guess that's it, keep sharing your flags! (eventually I will make a picture of a vessel with all the flags on the topic, to participate you must include a link to your flag in the description as well as the pictr) Posting NSFW flags on this topic will be reported to the moderators.

I've managed to talk to quite a few, and all of them basically say, "I was just doing my job" and/or something like, "The real heroes are all still there, buried."

None* of them want to talk about it, which means remembering it, when they'd just as soon forget it * - (in general, I'll assume there are exceptions).

And I'm hearing that the second installment will be quite good. ...possibly good enough for my spouse to actually enjoy! I got bored last winter and started digging through this box of old paperbacks in my basement; books I've had (and kept because I loved them) going all the way back to the 70s and 80s. That's ownership; most are reprints of classics, with some like the Julian May (Many Colored Land) series being 'new' when I was reading them. There's a lot in there that did not age well. I'm actually okay with that; my daughter is the only one in the family that really enjoys SF... and she enjoyed watching the show. Plus - I can talk math with her!

@Superfluous J @Hotel26 I don’t think it has anything to do with logic or whether we could build a simulation with our understanding of computers. In my opinion, if there is a simulation it was built by something of such great knowledge and power its actions would be indiscernible to us, just as a fish isn’t really capable of discerning complex human behaviors. But yes, the question of “Are we in a simulation built by ourselves/other humans” can be answered with a pretty certain no. Unless we start getting into questions of whether “we” is literally us, as in I built this simulation for myself but wiped my memory as I went inside. Which isn’t really a question about “are we living in a simulation” but could begin slipping into arguments about solipsism. Pretty much. Insofar as it isn’t a scientific idea but is being peddled as a sort of “higher truth” “within the boundaries of science*” it basically hits all the marks for New New Age theological thinking without the theo. *At least this is the strong vibe I get from such believers who talk about their ideas. EDIT- It should also be noted simulation theory can be an idea held while being religious too. Look up Philip K. Dick’s 1977 speech in Metz, France.

Talk about loaded questions. My biggest gripe with the talk about performance is that 90% of all the "gains" comes from removing elements from screen. Take a look at how low graphics looked in 0.1.0 vs 0.1.4 and it's pretty damning that there's been minimal performance gains, only fidelity losses.

we questioned what you know of phisics because you do not talk like an expert. Except for a few throwaway line that do hint at technical competence, like mentioning the physics of two spaceships orbiting each other (without whom I'd just dismiss your claims of MS as internet bravado), most of your messages come across as just ranting about things that have perfectly reasonable explanations. what you described in your first post was perfectly compatible with orbital drift, so the simplest explanation was that you were experiencing orbital drift and had no physical knowledge. even now, you boast of a MS in aerospace engineering but you never correctly describe orbital drifting. Their guidance code and whatever else they covered for their masters definitely won't pertain to the "space" in aerospace if they're having trouble coming to grips with the fact two orbits will behave differently to one another. I think that their qualifications are likely irrelevant to the discussion.

first you said that the acceleration was slow, now you say rapidly. which description is false? keep in mind that ksp has smaller planets with faster orbits, and so the effects of drifting are bigger than in real life. both hotel26 and 18watt already did mention the possibility in their answers. if the two ships are sharing the same orbit, one in front of the other, they can be very stable. if they are one above the other, they will drift away much faster. perhaps. what you described the first time is perfectly compatible with normal orbital drift, now you say that the change in speed is fast. I have experienced bugs with trajectories too, so there may be a bug at work. we questioned what you know of phisics because you do not talk like an expert. Except for a few throwaway line that do hint at technical competence, like mentioning the physics of two spaceships orbiting each other (without whom I'd just dismiss your claims of MS as internet bravado), most of your messages come across as just ranting about things that have perfectly reasonable explanations. what you described in your first post was perfectly compatible with orbital drift, so the simplest explanation was that you were experiencing orbital drift and had no physical knowledge. even now, you boast of a MS in aerospace engineering but you never correctly describe orbital drifting. We who are posting here have years of practice at this game. we do not have a degree, we do not know how to write guidance control code, nor we know about crafting techniques for advanced aerospace materials, realistic aerodinamic models, actual gravitational equations, or a bunch of similar stuff I suppose is studied in aerospace engineering. but we do have a lot of practical experience running orbits, rendez-vous, dockings, transfers. I showed ksp to a friend with a phd in physics - he specialized in particle physics, but he took courses in orbital dynamics - and I was surprised at how much more knowledgeable I was than him. I would bet good money that when it comes to this practical understanding of the kind of orbital operations required in this game, we are actually more experts than people with actual degrees. in this specific field of space navigation, we are even more experts than several people working at nasa, because there's plenty of people who are not working on orbital mechanics but are instead building rovers, improving thermal shields, ruggedizing delicate science instruments so that they will survive space, how to establish communication protocol. Or perhaps writing code. And so we also don't appreciate being talked down to with snarky comments questioning what we know about physics either.

Chapter 2: The Ascender Year 1, Day 29 The new KSP has been planning their next move, and they decided to go big or go home. This is the Ascender Capsule, manufactured by AtomicTech, a major contender in the post-war aerospace sector. While the capsule had been a scrapped project from the old program two decades ago, AtomicTech was able to secure blueprints as well as manufacturing components from the warehouse. The Ascender Capsule can hold two kerbals as well as some basic flight instruments. Before the KSP can launch the capsule to orbit, they first have to test the abort system. "John, I think it's working!" "Successful abort system fire! The capsule is still intact." "Let's just drive to the capsule and check it out." "I can't see any damage. I think we're good to go!" Later that evening, John and the growing team of 28 employees held a meeting. "Now that we have a crew capsule, we can attempt to visit whatever the old program left in orbit. The most prominent of these is the Hope Orbital Research Platform. Although the radio equipment used to communicate with the station have long been destroyed, we can try to establish comms to this station. However, we would need to send a crewed vessel to install the equipment within the station." Herbrett blurted, "Why do we have to put the equipment inside the station when we can just attach a utility module to the station on the outside?" Herbrett continued, "We can use those grabbers that you brought to work today, Nathanael. That way, we won't need to worry about whether the station's docking ports still work." John interrupted Herbrett, "Enough talk! Let's get to work!"

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): new_engine_testing.mp4 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!