Search the Community

Hello all, I have a little over 150 hours in the game now, and while this has been a mostly positive experience, I have been slowly accumulating a list of things that I would like to see changed/tweaked before 0.2/1.0. These items will be split into two parts, the first half being things that are annoying to me, and having them tweaked would improve my user experience, while the second half are things that I think would improve immersion, and contain some minor nitpicks. I have tried to keep this post containing only things that are already in the game, which should remove accidental bug reports, and requests to add new features. USER EXPERIENCE: FLIGHT UI: The flight UI imo, is lacking a lot of key information, that would make flight both easier, and also allow for more complex mission profiles. It needs a TWR indicator for each stage, as well as burn time left for the dV in the stage. Orbital inclination under the AP/PE values would also make precise orbits possible like they were in KSP 1, with its 'advanced orbital info' tab. Another key piece of information that can be very useful for most missions, is suicide burn information; like a countdown, distance, and dV required. I used that info from K.E.R in KSP 1 for pretty much all landing missions, which allowed for thrilling, cool to look at, and efficient missions. One last piece of information that I found useful in landing, was horizonal and vertical speed read outs, which made precision landings a little bit easier (something that could be very valuable with colonies). (Also the trajectories mod made precision landings on atmospheric bodies significantly easier, but that gets well into the realm of additional new features to the game, which this whole section is already bordering on). TL;DR: port KER to the flight UI lol The other part of the flight UI that I think needs to be changed, is the tapes on the navball, and specifically the units they're in. Currently, they're both in km and km/s, which is not particularly useful in any scenario. The times I would look at the tapes for info, is for landing and sometimes taking off. With the units in km, the tapes move very slowly, to the point where they don't provide useful information to the flight. Most landing speeds will range from 2000-0 m/s from orbit to the surface, and with them in km/s, they barely move two units, often less. The tapes should either match the readout units (i.e. the same way the speedometer/altimeter units adjust depending on how large/small the value is), or it should be a log scale. That way, the tapes can provide useful information during critical parts of a mission, like they were intended to do. MANOUVRE NODES: The big one with this point is the 'out of fuel' message that prevents the player from making manouvers past their ship's dV. This design choice has always baffled me, as the old system worked perfectly fine. Especially with the buggy dV readout, which can often read zero despite a fully fueled ship, this change unnecessarily limits the player. Other applications of plotting past a ships capabilities could be to determine how much dV a rescue vessel would need to successfully return to Kerbin, if the readout breaks after rendezvous (happens frequently, even in KSP 1, after rearranging a ship), or simply if the player has infinite fuel turned on. The bar going to read to show that the player was going past the ships dV capabilities informed them well, and could even be improved if it still displayed the 'out of fuel' message. Returning to the old system, the same system KSP 1 used, is what I and most others would certainly appreciate. The other thing I would like to see is the return of the 'plot to next orbit' feature from KSP 1, which was useful for checking for chance encounters (very useful at Jool), or seeing if the next orbit would have a closer approach with rendezvous. TIMEWARP: For timewarp, allowing the player to access all levels of timewarp once in a stable orbit (out of the atmosphere, or 10km above all surface terrain) seems like a no brainer. Waiting for rendezvous transfers for 15 minutes irl, or having to go through a craft switching frenzy to get higher warp for interplanetary transfers, makes interplanetary missions more painful than they ever need to be. With mods already doing this a few weeks after launch, I hope this gets fixed soon. The other thing that needs a return is the ability to switch to physics warp when holding alt. For larger crafts, waiting whole minutes for them to slowly turn around is not fun. Physics warp exists already in the game, but being able to hold alt to access it at any point in flight, perhaps turning the timewarp bar red to indicate this, would be a great improvement. QUICKSAVING/LOADING: I don't like how making f5 saves creates a new quicksave. It should override the previous f5 save if one exists. Currently, manually made saves get lost in the swarms of f5 saves, which makes it difficult to pinpoint critical points of the mission. It's annoying to find the quicksave titled 'orbit', amongst the sea of quicksaves 1-57. The other thing I don't like is the lack of option to load a game save to the KSC. Currently, the only option is to load to a quicksave made, which prevents the player from opening the game to the KSC unless they made a save for it. If the player forgets to make such a save, or perhaps ended their last play-through not at the KSC (stations/bases/rage-quits), then they have to load the game to that point, and then load back to the KSC. Fixing this would reduce the time from opening the game to entering the VAB, which the load times already do so well. LIGHTS: This is just a minor one, but I think that the range of most of the lights should be increased. often lights don't light up the ground early enough for them to be useful, and this is one of their main uses. In my experience, most of the time I see the dust kicked up by the engine exhaust before I see lights illuminating the ground. IMMERSION/MINOR NIT-PICKS: ENGINE PLUMES: This is my biggest issue with the game, that doesn't directly impact my user experience. The atmospheric engine plumes for methalox engines don't look good. I honestly think stock KSP 1 plumes look better, and waterfall plumes look orders better, which I found surprising for obvious reasons. they appear as an almost solid colour, with variations being hard to see, even when zoomed right in. The plumes should be much more transparent, and show those beautiful shock-diamonds, like those in the waterfall mod. They don't look 'powerful' compared to waterfall, and the jarring differences in beauty from all the other fuel types' plumes is very strange. They look stunning in a vacuum, so I just hope that someday the atmospheric plumes can match it. The other issue is that some of the vac plumes appear to be more concave than convex, contrary to irl. The poodle engine is the worst offender of this that I've seen. most of the other engines get it right, but it sticks out like a sore thumb for those that don't. KSC: This point is quite nit-picky, I'll admit, but I'm just not a fan of the KSC. I think having it downrange of the launchpads and runway was a very odd choice, and having it crammed in between the runways and launch pads limits the size of the buildings. It feels like the runways and launch pads were added first, and then the rest of it was added after. Having it on the other side of the runway (west side) would give it all the room it could need, which could let it have have a much larger R&D and tracking station buildings, which I think would match that of an interstellar species well. I think having 1 major, and 3 minor dishes for the tracking station like in KSP 1 would be neat, and buildings like wind tunnels, and engine test stands added onto the R&D would make the KSC feel more alive, while giving even more opportunities for some challenging-to-fly under bridges. VAB: Being able to past in hex codes for colours would be very nice to keep a consistent colour pallet across saves, or if the user wants to return to the colour they made at a later point in their build. Also we need a return of the TWR for each stage, and the ability for it to be calculate it on different celestial bodies (and the same for dV). TERRAIN: Not sure if the coming CBT system will fix this (I really hope it does), but I'll put it here anyway. The terrain in some places is very flat/boring. Obviously most of the terrain is really beautiful, but in some places its just not, specifically on the dark patches of the Mun, and large patches of terrain on Duna. I'm not saying that terrain can't be flat, I'm saying it shouldn't be Minmus Flats II. Just some rolling hills or even the odd minor crafter to break up the land to make it more interesting to look at, while still remaining 'flat'. I think the large craters on the mun in KSP 1 do this really well, as in they look flat from orbit, and are still generally flat on the surface, but the rolling hills and craters bresk up the terrain enough so that it doesn't look jarringly flat. ACTION GROUPS: Group communication deployment with the solar panel action group. every single time i use them, in both games, I've always put them in the same action group, so putting them together just makes sense to me. REFLECTIONS: Reflections are too strong. At some angles, I can hardly even see the craft, because its all white from reflections. Also having stars 'fade' away/lowering their exposer when next to the light side of planets (like what they do in the 'distant object enhancer' mod/irl) would improve my immersion a lot. CLOUDS: Increased cloud coverage, and multiple layers of clouds (instead of them all being at 2 km (i think theyre this high?)). I've always found clouds to be far more beautiful than any clear sky, both irl and in (both) game(s). That is all for now. I hope this post gets heard and at least some of the points are acted upon amongst the bug fixing and new content. Might make another one of these for each milestone, depending on what they're like. Thanks for reading allat. Yours truly, Suppise

While the game already includes randomly generated hairstyles, skin colours, glasses, and eyeball sizes, expanding this system to allow for comprehensive customization beyond just suit colours would greatly enhance our connection to the little green kerbanauts and their missions. Drawing inspiration from the discontinued kerbalizer game, we would be able to create or modify unique Kerbals with distinct facial features, hairstyles, and outfits & accessories that they would wear when idle (in the astronaut complex, colony habs, or floating around on a space-station).

the title says it all

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.

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...

There is a kerbal wiki about this: Faz - Kerbal Space Program Wiki. It should be considered for ksp2 if the dev's want it.

The indicators to begin and start a burn are unclear if it automatically burns I wouldn’t have to worry about that if this is considered then make sure you can turn the feature on and of. Copy and paste this for the private division launcher feedback please.

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.

having more symmetry options enable new things. 5x symmetry is my favorite modded symmetry from KSP 1. now you as a reader probably think: who would ever want 5x symmetry and why. the answer is: me and here comes the why: my first argument for 5x symmetry is redundancy when designing a lander how many legs should it have? well at least 3 because the center of mass needs to be within the triangle formed by the legs. 4 legs is not the best option (sorry Apollo) if any one leg fail the craft is unstable and it will fall over. 5 legs will allow for any single leg to fail and still be upright, and up to two legs could fail as long as they are not next to each other. but for me personally the main reason is to be able to build crafts like this. now how does 5x symmetry stand out from the rest? 5x symmetry allows construction of tesselating structures in 3d space (balls) one great example are the platonic solids, most of the fun ones require 5x symmetry. the one in the image is a Icosahedron that was twisted a bit. note that every node has 5 arms. there will probably be a mod for this, but to simplify craft sharing of designs like this it would be nice if everyone could download and play with them. as a spoiler i will add pictures of other designs that use the same symmetry. adding more symmetries would not be harmfull. 7x could probably be cool for making heptagrams or something. it would be a very smal addition to the game to add this and it would probably go unnoticed by many, but it would make my day!

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.

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

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.

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?

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

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.

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

When clicking and dragging different parts of the staging section, make it so the boxes/icons move around with your mouse.

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