Search the Community

So I was watching the short film recommended by Nate Simpson and found this scene at the end and it just amazed me. I've aways felt the gas giants in KSP were kind of distant and purposeless, like a distant god that can't be touched, a far wonder that exists only to be contemplated in the skies of their moons. Being able to construct floating bases in those worlds would bring them a surface, landing in one of those colonies would be a new exciting gameplay challenge that could be rewarded with the resources extracted by those facilities. Just imagine the terror of missing the landing spot and falling to the infernal core of Jool. Imagine how beautiful it would be to fly a plane down the cloud layers to extract certain elements and then land back on a floating runway. Imagine the challenge of designing a vehicle capable of diving to the metallic hydrogen mantle and then getting back to the colony by inflating some sort of balloon. The possibilities are endless...

When I press ESC to access the game menu (e.g. to save the game or change some settings) the game should automatically be paused. I think few people need the functionality of the game continuing while they are not paying attention. And currently you need to remember to click pause first, which seems unnecessary.

Science gathering in KSP1 has always felt a bit pointless to me: It was just about clicking your thermometer or whatever in the right place and left you with nothing but a funny text and some points. But you don't really get any new insights: You can see any planet/moon and its properties in the tracking station. I think that just by hiding some information from the player one could make science a much more meaningful part of the game: For example, the "physical characteristics" tab in the tracking station could be filled only after according measurements. Also, what if celestial bodies were blurred out in map view and the tracking center, as if you would see them through a telescope on Kerbin? And only became detailed once you got a spaceship into their SOI? Things like that would add a component of discovery that would make science/career mode so much more exciting!

Having the ability to take-off from runways 27L & 27R instead of only from 09R & 09L. Potentially adding 1 runway running North/South, 36 & 18, respectively. Also having the ability to load-in, in front of the VAB and be able to taxi to our desired runway. Thank you for the teams hard work, I’m having a blast playing 2.

There should be a way to turn down the sun Glare in the VAB Some examples

Personally im the kinda of person to save the game everytime I finish or start something. (I have trauma from the tens of times I did not save) But saving this often clogs up the save folder, and requires a bit more space on my computer. This was not a problem in ksp 1 as you had this feature, however ksp 2 simply lacks this feature, and you can not delete saves without going into the files. I mean sure you can overwrite them but I would like to have a timeline of saves, that I could delete later when Im done the mission. This would be a simple, but useful feature for me, and probably a bunch others. Thanks for reading

Following my experiences with the Weekly Challenge 4 - Recreate Apollo, building a "Hell of a rocket." without auto struts and on par with wobbly Kerbal material engineering, it forced me to clamp down my Apollo rocket with Launch Clamps so that the wind won't mess with the orientation. As with KSP1, KSP2 also incorporate that the altitude of the vehicle in the VAB would also be the altitude of the vehicle on the launchpad due to the Launch Clamps. There should be a button or buttons to make the rocket "sit atop" or just above the ground of the launchpad in the VAB so that when using Launch Clamps, the rocket won't be lifted above the launchpad because of the Launch Clamps. If this feature will be disregarded, another lesser alternative would be:

This could be done in KSP1 and helps a lot when trying to precisely tune the vehicle in VAB for the Launch Clamp. As of v.0.1.1.0, we could only rotate but not translate the parent or Assembly Anchor part. A better alternative would be:

Unlike KSP 1, the VAB has no door/view to the outside, so it’s harder to orient craft correctly (at least for me)… ex: Sometimes it is helpful to pre-incline a rocket/probe slightly in the pro-grade (E/90°) direction to help it find its’ way to orbit, but without knowing which way is which, you have to guess, then reload VAB if guessing wrong (and this has its’ own problems which I’ll post about separately). Adding: Updated to v0.1.1 on Thursday

I've 'tested' 21:9 and 32:9 resolutions, and it looks awesome, clearly this game was made for wider screens looking at how the UI is implemented. And since it does not seem to cause any more bugs. Only thing that needs to be worked on further is loading screens not being stretched but enveloped so we have black bars left and right when loading. Can you stop the game forcing 16:9 resolutions?

Recommendation: Make it possible that you can upload the game state files and vehicle files in the bug report via the launcher and not only images. Matt Lowne also says in his videos that he can submit the LOG data and his save data. Maybe the development team can crush the reported bugs faster.

Dear KSP 2 Developers (including Creative Director @Nate Simpson), I have a feature suggestion. You should add a craft file converter to the game, so players who created vehicles in KSP 1 would be able to use them in Kerbal Space Program 2. I have previously suggested this feature as a mod for the game, but now I think it might work better if it was a standalone feature included in stock KSP 2. As for how you could implement it, I gave an idea in this post along with some UI concept art: https://forum.kerbalspaceprogram.com/index.php?/topic/214938-idea-ksp-1-craft-file-converter/#comment-4259514. A feature like this would be useful for players coming from KSP 1 who want to use vehicles that they spent a lot of time making or have a high part count in the original game and don't want to waste time trying to recreate the vehicle part for part in KSP 2. From my many hours of experience in KSP 1 (over 600!), I know how tedious it can sometimes be to create a vehicle that works and functions the way that you want it to, so having something like this in the game would be very much appreciated... Thanks, @Johnster_Space_Program

Maneuver nodes would be more accurate and precise if we can create them on point to the Apoapsis or Periapsis of the orbit. And/or Maybe a maneuver node where you can type in on what altitude the maneuver node will be created which would be useful in many unimaginable ways. Thanks!

its just a little detail to use once first person or IVA is in the game have your camera bob with the head while walking, flying , landing and etc and if people wouldn't like this setting on they could click a little button in the settings to turn it off or have a slider to change how much head bob there is

this is a suggestion for the multiplayer update or any update it will allow you to Customize your own kerbal hair or hair color facial hair like beards or mustache's etc space suits selection (like ksp1) And custom accessories like hats, glasses and other stuff that will make sense when a kerbal is wearing a space suit or not and possibly suit patches? like the final approach suit patches in ksp1 like and example a arm patch for a mun / min / duna / jool you know type of mission you could also use custom suit patches like flags or just stick with stock

I suggested performance improvements to kerbal space program support, and they requested I post it here because they thought it would greatly help the developers. First off, I love KSP2 and think it's a great game. Y'all added a lot of features I really appreciate, like procedural wings, coloring (man do I love coloring), and the SAS control and UI I like so much more. I'm also really excited for all the features in the roadmap. Secondly, I'll say what I believe to be true and what you should do working off of those assumptions. I don't mean to sound pretentious, just writing this because I want to help if at all possible. I could also be completely wrong because I don't have that much experience. I believe if you knew all this though, you wouldn't be having the performance issues you're currently having, but I could be wrong. If my assumptions are wrong then my suggestions won't help much either. My assumptions: KSP2 is currently built in Unity, which uses PhysX engine for its physics, which is really good for collision detection, but only that. Therefore, your structure is probably something along the lines of every part is a prefab, players then are basically dragging prefabs to build a ship that is then loaded into the world. These prefabs probably all inherit from some part class that handles gravity, joint force, and aerodynamics. Then fuel tanks and engines (where you're currently having performance issues when users add several) have additional scripts handling fuel and force application. This is probably all within FixedUpdate, which is called serially. This means that every single part is executing its script on the main thread sequentially, which is why some computers with good single CPUs instead of multicore CPUs are performing well. However, most modern CPUs are built with multiple cores and threading in mind because of how much more efficient it is. This doesn't matter though, because Unity's APIs aren't thread safe and prevent multithreading. Final assumption, you're not using the GPU for a lot of your calculations. Where I believe you can go from here working off of those assumptions: It's kind of infeasible to just improve performance. Like sure, you can make your functions better, but only so much better, and there are some calculations you just have to perform. Once you get to colonization you also get ridiculously large structures and physics. Unity may not support multithreading (which honestly at a colony part level won't help too much), but it does support compute shaders which would allow you to perform a massive amount of calculations very quickly. For most of your parts you probably have the same function, just different inputs depending on the size and shapes. Then engines probably all have the same script that handles fuel consumption, just different thrust and ISPs, which is perfect for compute shaders, which are really good at performing the same function with different inputs in parallel. Unity even allows you to pass structs to the compute shader, which means each part could be simplified to a struct of its various variables, and then sent to the compute shader. Each block of the compute shader could be a different function / calculation, i.e. aerodynamics, gravity, fuel consumption, and each thread a different part (or be really fancy and use textures for input output through rgba values). Meaning most modern computers will be able to handle 1024 parts at the exact same rate as 1 part, because most have about 1024 threads. Worst case scenario you only get 512 parts, but even so Unity's compute shaders allow for a third dimension which means expanding beyond 1024/512 parts is simple. Or if you don't have a GPU, it will default to the fastest device which will be your CPU and now you've threaded it since CPUs just simulate the GPU and thread if there isn't one. Basically, any where you have for loops, double for loops, or scripts on every part that perform the same calculation, you could probably offload to the GPU to increase performance. Concerns: - GPUs are slower. Yes. But if you have 1000 calculations and the CPU runs 3 times as fast (approximately maybe), the GPU does all 1000 calculations in 3 CPU time, because they are parallel. The CPU does 1000/3 = 333, which is a much bigger number than 3. - GPU answers are a large array you'd have to loop through on the CPU anyway. Just do thread reduction. - It'll slow down rendering since we're using the GPU now. Well, rendering waits for the CPU calculations, and your structure would look something like this CPU (initial calculations and storage) -> GPU (parallel calculations) -> CPU (handle those calculations and store them for the next frame) -> GPU (render). Besides, slower rendering doesn't really matter if your calculations are the bottleneck. - You don't have that many parts. Yea, actually the GPU is worse for if you only have like 10 calculations. Best I'd say is if you reach a threshold offload to GPU otherwise use CPU. But I imagine for colonization you will have to use the GPU. I have two examples, one using CUDA, the other a compute shader to prove how many calculations you can achieve. The compute shader performs collisions, collision reaction, and gravitational constants (which are bad for the GPU since there's a cube and a square root involved in the calculation) 1.04 e10 (like 10 billion ish) times a second (10 blocks of 1024 threads that have a for loop going over all 10240 objects at an average of 100 fps - given, I took a lot of shortcuts to make it stupid efficient which you won't exactly be able to do in Unity. 10 * 1024 * 10240 * 100). The CUDA program is the same principles as the compute shader wince it runs on a GPU, but the CUDA program has a reduction implementation that's quite simple since it's only thread reduction. It performs about 20,000,000 calculations in .3 seconds. If you partition each function onto a block you can do the block reduction on the CPU since block reduction is difficult and can be risky. You have to go back to the CPU anyway to store the information for later frames, and looping over blocks isn't going to be that long of a task. Both of these examples are using OpenGL and C, but Unity's compute shaders are pretty easy to use and comparable in principle, just use HLSL instead of GLSL. I have the repositories for the two examples but don't particularly won't to blast my personal information so if requested I'll send links to them (they have my name and some info and such). I hope this is helpful and you didn't already know all of this and I just sound like a jerk. I think that with great performance nobody cares as much about bugs since they can just immediately restart and not be waiting 10 minutes to see results again. I think performance is especially important since you want to make science accessible to everyone, and most people not properly exposed to science don't have modern hardware. I'd also be happy to talk through some questions or concerns if you have any. Thank you for your time.

Abstract I hereby propose a system to avoid players breaking physics by traveling faster than the speed of light using futuristic drives. Introducing futuristic engines in KSP is needed to deal with the insane distances between stars in order to avoid mega time warps that would fast forward time by hundreds of years. From this arises a problem. Namely, people abusing said engines to break known physics to travel faster than the speed of light - even if using cheats. As an educational game this should be prevented to not spread misinformation about the cosmos. A simple yet realistic (relativistic haha) system to deal with that is time dilation! A space ship approaching the speed of light experiences time more slowly. Down to a full stop at the theoretical limit of the speed of light. At that point chemistry stops working (no time -> no chemical reactions etc.) and a space ship could not accelerate faster. You'd be trapped actually, hence only a theoretical limit. You can't reach it. Since the player is not part of the ship just an observer from a different dimension, time dilation would only affect the ship. Not the ingame clock. How this could be implemented: Reaching a threshold of lets say 30% of the speed of light every engine would start to lose thrust in tangential-exponential fashion. Optionally also reaction wheels and even Kerbals themselves for the player to notice that something strange is going on and he is not just running into a bug. This could be solved with a local time-warp factor <1 that only affects the craft and everything in physics range. If you'd EVA a Kerbal at 99% the speed of light he would also move 7 times more slowly. The ship would rotate 7 times more slowly and produce 7 times less thrust. Or 0.14x thrust: t = t0 / sqrt(1 - (0.99c)^2/c^2) t = t0 / sqrt(1 - 0.99^2) t = t0 / 0.1414 The bottom figure shows the relation between the time of the player and the time of the Kerbal as our velocity is approaching the speed of light c. The closer to the speed of light the more time it takes for the Kerbal to do anything the player asks it to. Up to about 0.3 or 30% of the speed of light the graph can be simplified as linear. This means time passed for the player and time passed for the Kerbal are equal. Hence no calculation is needed for optimization. f(x) = x/sqrt(1-x^2) Conclusion Adding Time Dilation into KSP is necessary to deal with problems that arise from the educational nature of the game and from players being players trying to break physics. Those who dare would be surprised and left in awe as to how much attention to detail the developers put. There are simply no cons besides a few minutes of development time. Thank you! Sources: Calculation by ChatGPT Graph by GeoGebra Calculator PhD. in Kerbal Astrophysics and Goo Dynamics.

Probably the wrong place for this, but could the admins create an additional RSS feed for this forum category that's featured posts only? This would allow easily subscribing to just the weekly challenge posts with RSS. Relevant Invision Community docs

The pause button is very cool. It got me thinking... Rewind?

Landing with interstellar engines should be possible in KSP2. Engines that output that much power wouldn't be limited by atmospheres for the most part so landing crafts like in Avatar 2 should be possible. See this image for how that might be a possibility:

I'm kind of stunned that an artifact of the original game's game engine limitations were carried over to the sequel. Wobbly rockets were always a bug. The KSP1 devs spent years trying to minimize the problem, even bringing on new members to work on the issue. Most people don't like them, and they introduce an un-intuitive stumbling block for new players or people that want to learn space. eg. Rocket veers off course on launch. Why? The control part wobbles away from the heading, resulting in SAS shenanigans and off COM thrust. Furthermore, everyone gets rid of wobble to the best of their ability by adding struts, resulting in a higher part count. So you have a feature, that only produces greater part counts. Why? To keep the destructive effect, just define stress tolerances for parts at which they explode, disconnect, crumble or shear. Also, real rockets don't wobble. Scott talking to KSP1 devs about the wobbly rocket bug. They go off on tangents but almost the entire rest of the interview is on the topic. KSP1 dev describes his next gen parts physics sim in which wobbliness is not a feature. --- If you're new to KSP, wobble is that wet noodle, jello rocket thing. Please get rid of wobble all together. Thank you. Development on the issue:

the color manager is one of the few satisfying experiences in the game's current state, being able to color parts individually makes our rockets look so much better! however it can get a bit cumbersome when trying to work with multiple colors, so i would suggest adding the ability to save multiple color schemes instead of just 1 (the agency color). in addition it would be nice to have an input field for hex color codes for easy sharing and importing of colors. also, having like an eyedropper / color picker feature would make things alot easier.

This is a pretty simple one. Give me a way to tell KSP2 to "stay in its lane" and keep its save data in the game's install folder, where it (at least in my personal opinion) belongs. I have 1 save game, with just a couple dozen vehicle (attempts, with little success due to bugs) and I have nearly 250MB of data in my %appdata% now. I can easily see this growing since the breakdown so far is about 50% crash data, and 50% game saves a 1 vehicle workspace is about 4MB of JSON data and a save file seems to contain a primary file between a couple KB and 6ish MB and then a set of four autosaves at 4MB each for a total of about 25MB of save data for a game with no active missions and just some junk I cant delete so I expect this to significantly grow in size with active missions, as it appears to be keeping the entire vehicle hierarchy in the main save in addition to any individual workspace files. (I'll update this if I manage to get multiple things into space and save without crashing so I can tell if the file size increases correspondingly) Crash data for this game is at a little over 3MB per crash, and the KSP crash reporting currently has 39 crash report files. Which feels pretty close to the number of times the game has crashed to desktop on me. So I expect this folder is just growing without any limit, which I have no issue with in normal circumstances, but given how many crashes I have in 27hrs, thats less than 1hr per crash, this will likely grow to a significant size and cause issues with my main user "windows" drive. My C drive is not my biggest drive, never has been, its often my smallest. Ive got media files on HDDs, project and asset file asset dirs on larger SSDs I can easily drop into a new machine if anything happens to this one, and a more expensive M2 PCIe NVME drive for the stuff that needs high IO like my development environments so the compiler can pull all the small files together, etc... and spread out across all of these are steam libraries with the location chosen based on how I feel... tiny 30MB game, chuck them all on the spinning rust, they arent big enough i care, large game I rarely play and dont mind the load time, sure HDD again, game I like and want to be able to open quickly, maybe on the SSD, game I want to load as fast as possible or hate any interruption while playing, maybe that gets a place on the expensive high IO NVME... I gave KSP2 a spot on that NVME drive, but it seems to want to put its data on my slower windows drive... and fill it up with crash reports. This is silly. I dont want yet more junk in %appdata% If I delete KSP2, I want to delete KSP2, that means all the data gone, not taking up extra space somewhere else. Having a hard coded one true directory where every version of KSP2 puts save files, feels like it will cause issues with conflicting files between different versions of KSP2 once we have updates and start having to deal with things like Mod compatibility between versions of KSP2 Early access = lots of bugs, lots of bugs means lots of crash reports, lots of crash reports mean filling up my windows drive, don't fill up my windows drive. %appdata% isn't %tmp% (not that windows is particularly good at keeping %tmp% clean) don't fill it up. Just give me a place in the global config or something like that, where I can say "data files live in the game directory"... or better yet, make that the default behavior, because the current one doesn't make sense for a game that expects to have a modding community in the future. The current default will either need workarounds to avoid conflicting save file versions between multiple copies of KSP, or its going to cause problems... or a different save directory can just avoid the issue entirely.

I like that we can strip the paint off and have a nice silver metal. It looks awesome. Down the line, I would love to have metallic colours added. I'd love to be able to have a gold or cherry red metallic painted ship. Cheers!

(This was also posted in response to a MN bug report, but as I got carried away, went on a tangent and provided a suggestion - I will also place it as it's own suggestion here) I'm not a physicist, astrophysicist, scientist, rocket scientist, astronaut, a rocket surgeon or even a space shuttle door gunner. My understanding of orbital mechanics stems completely from KSP (and lately also Juno: New Origins...which does some things I like - like auto burn even though I sometimes prefer to do it myself), and I'm not even very good at understanding most of that. So when you all talk about Delta V in the second half of the burn being easier due to less mass, or the efficiencies of burning prograde and not pointing to target or pointing to target and using SAS hold, I'll just smile and nod. I understand the concept of what you're saying, but not the math involved. I know how to get to the Mun without using manoeuvre nodes, how to get into an orbit (in transit) if my periapsis is too low and how to circularise an orbit without them too. Getting an orbital encounter I can do in KSP1 - with nodes, not without...not so great in KSP2 in part because of the node system and it's "intuitiveness". But that's not the point - the point is the manoeuvre node is supposed to correctly and accurately calculate these things for me way better than I ever could. I like the fact that the nodes now tell me when to burn, and grab my attention in some way just prior to the burn however, as it stands, every burn I make "trusting the node" is wrong and I have to fix it manually using what little I know of orbital mechanics. Even getting a circular orbit in KSP2 - starting the node from apoapsis, or even before it - is difficult. I have to make significant correction burns if my intent is for a circular orbit - otherwise I generally just burn out of orbit from whatever kind of orbit I'm in to get where I'm going. "Brute force it", so to speak. What I would like is if the node was "intuitive" enough to figure out I'm trying to burn for Mun (or any planet) periapsis, or get into/circularise an orbit, or intercept/encounter a target and apply some sort formula to compensate when calculating the burn based on the parameters I've set when planning my node - so I don't need to figure out how many seconds three minutes and 49 seconds), what half of that is and then subsequently realise I've missed the start of the burn because I was too slow with my calculations and there's nothing grabbing my attention to start said burn (in KSP1) - and in what direction to burn in order to make the burn I planned work as I intended. What I would also like to see is, potentially in the right click radial menu of the node, a button for calculating an orbital circularisation burn based on the current/intended apoapsis (as we all do this A LOT, so this will save us a lot of time) and a button for calculating an intercept of the target (something else we'll be doing a lot of, I imagine) be that a ship or a celestial body - and if it can't get us a perfect intercept/encounter, it gets us close enough to whatever we're trying to get close to so we can do a mid-course correction burn to get us even closer, rinse repeat until intercept/encounter). I would also like to see a way to manually input our desired apo/peri either in our current or desired orbit (at the desired target) and have the manoeuvre node calculate a burn to accommodate that for us. In "campaign mode", these options would be later-game but in EA sandbox (i.e. what we have currently) they could be implemented and fine-tuned so that come v1.0 release we're all singing off the same sheet of music. It doesn't have to be perfect (or perhaps, 'perfect' course plots can be another upgrade) it just needs to get us in the ballpark so we can course correct or establish an elliptical orbit or whatever our plan is for where ever we're intending to go. In KSP2, I feel that automation of the more common navigational manoeuvres should have "quick access" (circularise, intercept - as this would also cover interplanetary insertion burns) buttons in the manoeuvre node. I also feel that automation of the more repetitive tasks (such as getting a ship into orbit, and/or circularising an orbit, and docking) could (or perhaps as a selectable option, should) be a thing the devs prioritise - especially to make the game more accessible and especially when we have colonies and resource gathering to worry about. Example 1: You've been manually launching rockets for 20 hours - but since you've upgraded to the Level 3 Tracking Station, here's a series of buttons to help you automatically launch your craft, circularise its orbit and, if need be, calculate an intercept of a designated orbital target. Example 2: You've been building ships module by module in orbit with varying degrees of success (if you can get the nodes to work for you) for the last 50 hours - but since you've upgraded to the Level 4 Tracking Station, here's a button that will 'auto-dock' you - right way up, every time - to your target, provided you're within 1000m and your velocity relative to target is 0 m/s. No more twisted, misaligned modules from now on. Example 3: You've gone to Debdeb and back, six times, and docked landers to your orbiting ships 9,700 times in your 120 hours of KSP2 - but since you've upgraded to the Level 5 Tracking Station here's a button that calculates the intercept of a celestial body and more accurately calculates orbital intercepts from the ground - and also plots the trajectory of an interstellar burn. Good job, you've earned it! Does that make it "too easy"? In Sandbox, yeah maybe. But if you wanted the challenge, you'd be playing a career mode. And if you're playing career mode, after doing the same thing a billion times (like you do in career mode), a more efficient way of doing it would be appreciated. You'd obviously have to "do the hard yards" to earn (and therefore deserve) them by the time you've reached the late game. Plus, these are/could be optional, with the unchecking of a box in the Settings menu you can still do these things manually either as good as, or perhaps even better than, the nodes can. But they're there to help players and reduce the micromanagement and monotony of constant launches, orbits and trans-planetary insertion burns and whatever else. But for any of that, we need this manoeuvre node thing looked at because as it stands right now, I'd much rather "do things manually" (yes, I'm aware MechJeb is a thing) in KSP1 than deal with whatever the hell is going on with KSP2.