Search the Community

This is a graphical issue bug not 100% sure if it is a bug or an oversight though, please let me know. Currently in ksp 2 when you go into water there are special affects to audio and visuals, but as you go deeper that doesn't change as it would in real life and how it would in real life. In real life as objects get deeper into a liquid substance, light gets absorbed more and more into that substance, and also that substance gets denser due to pressure. The image shows how a torch deep underwater looks - illuminating what is ahead of it in a cone, but the environment is otherwise dark as the environment is not getting light from the sun. In ksp2, no matter how deep you go the environment, and your craft, is the same brightness, and lights (floodlights and otherwise) do not get the water-based light scattering that happens not only in real life but also in ksp 1 (with scatterer). This is disconcerting, and takes away from the creepiness and the coolness of deep water that was in ksp 1 when using buoyancy, especially since ksp 2 has awesome SFX for being deep underwater. This happens in every version of the game, tested on multiple computers. Example mage shows environment (from CVUSMO on discord) deep underwater past where any light should be seen without light generation, but no change happens to how water and the craft/terrain look. Finally also solar panels work perfectly fine within bodies of liquid underwater, when irl and in ksp 1 they wouldn't work as light would not reach them. This would also incentivize putting RTG's on your subs - a cool design challenge! Also more stuff underwater would be neat. Included Attachments:

I'd like to suggest the addition of a TARGET window (Picture in Picture) on the map screen. I find that when calculating the maneuver its hard to line up the target to see where interception happens whilst trying to manipulate the node it would be great to see the outcome on the planet or moon without fiddling about with the camera and icons obscuring the node. This could be automatically displayed when the node is created and a target selected.. or it could be an option.. it could also do a nifty split screen so when moving the camera when target goes off screen it does that nice sliced off screen effect..

It'd be nice if the impact indicator that appears when you're on a collision course with a celestial body also told you your impact velocity when you mouse over it, it'd make planning out landings and suicide burns a lot easier. Something like this:

Not exactly as it was before of course. But from everywhere I've heard they removed it in 2. I think it would be very sweet of the devs to give it a proper polishing and return it eventually.

With KSP2 performance on the rise, it'd be great to have a benchmarking tool in-game that could allow users to consistently test their performance across a wide variety of game scenes, something akin to GTA V's "Run benchmark tests" option in its settings where the game runs through a series of in-game on rails scripted scenes designed to test the computer's performance, gradually sloping up in intensity and then outputting the results to a log file, having these scenes be scripted and consistent would allow for highly accurate measurements of system performance to be taken and make it much easier for users to quickly tell if they can run the game, as well as what effects graphics settings will have on the game's performance, it'd also aid a lot with user-polling of performance data across hardware.

1. In the Trip Planner the celestial body list is chaotic. I suggest a logical list, instead of an alphabetical one: Suggested: 2. In the mission planner, add the option to aerobrake where possible 3. allow for manually overriding dv requirements. Say a Mun mission. It will tell you that you need 860 dV to return from Mun Orbit to Kerbin Orbit, but I know you can do it with way less, say 300-400 dv. I want to be able to type that in so I don't have to keep remembering for every exception how much dv I can subtract from the total requirement. 4. Add the option to aerobrake where possible Ideally: 5. Completely manual missions Trip planner could look like this:

I understand the team desire to cut down on single use science experiments but I feel like this has left the amount of experiments feeling rather barren. So I've made a small bundle of ideas for different experiments that could be done, keeping in mind the design goal of making all the experiments more involved than simple button presses. Telescopes! Artificial gravity wheels! Plane science! I hope you enjoyed reading my ramblings after having delved into the current For science! update. Thus far I'm halfway through tier two in a max difficulty ramp up save file (200% reentry heating, -50% science), and this came as a response to feeling like the current science system, while a good base, is rather lacking. I hope these are some fun ideas for you all to chew on! Have a lovely morning, evening, or night! ^w^ ~Sammy

I'll whip something up in photoshop later to explain this better for Visulizations. In Ksp1 I always parked ships somewhere and placed a flag to say what the ship was, and what it did that was great. Like a mini personal space museum. My idea, is that we could have somehow place ships that would not have a poly count, maybe a img or something resembling the ship. and just be able to write about it, what it did, who drove it, how far, and other mission stats. idk, I'd think it would be cute. I know, it would take a long time to be able to do, but LET ME PHOTOSHOP something for you all to see what I mean. I'll try my best to get it looking like its in-game already stay tuned for some nice photoshop work

So I saw this post and I think OP there has a point, but I have my own take on it and at this point, I think it's worth making a new topic. So KSP1 and 2 both have exploration in the sense that they have a great big sandbox for you to travel around in, but I think an "exploration game" is a game where exploration is 1) interesting and 2) challenging. And neither KSP1 nor KSP2 had interesting or challenging exploration. Now, don't get me wrong, both games are challenging. That's a fact. But exploration isn't. Go to Map view and you can see everything in as much detail as you realistically ever will. Yeah, you can't see every rock on the Mun, but it's not like you can do anything with those rocks. And yes you can't see every hill and valley, but none of those hills or valleys are dramatic enough to matter to picking a landing site and you don't get science for exploring deeper-than-average valleys or higher-than-average hills. If you've ever played Minecraft and finally found an ice spikes biome after searching for days and mapping every ocean in a 1K block radius, you know what the joy of exploration is. It's the joy of searching, scanning the horizon, hoping to see what your looking for. Rationing food, creating outposts, running out of resources and having to return home only to go out again to search more. That's exploration. I've never felt that playing KSP, not even close. Because I've always known exactly where I was going, and pretty much exactly what I was gonna find. Now, there is no actual need to have exploration be a major feature in KSP. But I do think it's something that could raise KSP2 to the next level and create a kind of joy and challenge that we have so far not been able to experience. Below I've listed some general ways that I think it would be possible for KSP to incorporate exploration in a more meaningful way. I'd love to hear what you guys have to say about it. 1) Reward variety Minecraft actually provides a reason to go to a desert or a jungle. Different resources, different structures, different locales to build bases. It's not just that deserts have more loot than jungles, it's that they provide different value. You can't get pandas from deserts and you can't get cactus from jungles. KSP1 and 2 both suffer from all biomes being essentially the same. At best you might get slightly more science from the poles or from a monument, but that's not an exciting difference. If, instead, you could make a munar discovery that allowed you to build a special new type of engine by gathering a sample in a specific region, that could be an actual reason to explore. It's a reason to be excited that you finally found a munar valley so you can finally build that probe exactly the way you want to. Even something as simple as unlocking certain paint styles by visiting certain celestial bodies would give you some reason to go to some of the less visited bodies. Rewards that are just science or money become stale when you have lots of both. Rewards that are non-fungible, that are actually unique, those can be really inspiring. ideas for adding this: Samples from certain biomes give you non-tech tree discoveries, e.g. a new compound found on the mun unlocks a special side-mounted engine or a smaller more powerful satellite dish. Samples from Certain biomes unlock special paint jobs for rocket parts Samples from Certain biomes allow you to upgrade certain parts. e.g. the Reliant engine gets an ISP boost because of asteroid debris found in a munar crater. Samples from Certain biomes advance the kerbals understanding of the universe, allowing you unique abilities. e.g. you can now use all maneuver capabilities without a pilot (I know it isn't in KSP2 yet, whatever). Please keep in mind that while it may sound dull to have to go to a specific munar biome to unlock a particular paint job, some of my subsequent ideas might help with that. 2) Variety in Challenges Right now there is an element of tedium to going to each biome on the mun. You can see them all from orbit so you just have to do 5 identical missions landing in different spots. They are all essentially the exact same mission, and that is pretty tedious. Something that could spice things up is providing different challenges for different biomes. Ideas: Certain parts of Duna have major windstorms that blow you to and fro Other parts are very rocky and therefore difficult to land flat in. On the mun you could have basins in the bottom of caves that can't be flown to but require a speedy rover. You could have munar sand beds that are spongy and therefore easier to land on. Certain areas on the Mun could have a ground covering that messes with the ranging meaning you can only use sea-level altitude and not height from ground, making landing more challenging. Even features as simple as steep mountains mean you need to either execute a high-precision landing right on the peak, or make a craft that won't slide down the steep face. These kinds of unique challenges are a nice compliment to unique rewards. If you want a special engine, you have to design a special craft to overcome a unique challenge. It also means that landers cannot be as frequently re-used. You actually need to re-tool your ship for each new destination. 3) "Randomness" in environment Something else that is difficult is that you can see the whole mun in stunning quality immediately. You always know exactly where you are going to land from the start. Having some kind of fog-of-war where you can't see the landing site in detail (perhaps it's all pixelated) until you either scan it with a satellite or get close enough would mean you would need to be prepared for the unexpected. Combined with the variety above, it could mean that you need to build really adaptable ships, or do preliminary scouting, both of which would be exciting and rewarding missions. Another thing that could be done is adding features that simply do not appear on the map view until they are discovered. So perhaps you can see a crater, but you can't see if there is a meteor remnant in the middle, so you need to do an expedition to find out. And then if there is one, you can unlock a unique part or a science reward or whatever. This would encourage people to build a lander with a rover that can go explore. More detail on this kind of stuff below. I should note here I don't think a random or procedurally generated map would be a good idea. Rather everyone should have the same Mun, but you just can't see details of it in the map view until you actually map it. 4) Rules and science connecting environments and informing randomness Something that takes exploration to the next level for me is when you know that there are rules governing your exploration. For example, a Minecraft Savanna will always border a desert. And Ice spikes are often found near cold oceans. So when you are looking for a desert and you find a savanna, you can go around the perimeter, and when you are looking for ice spikes, you can get excited when you see a cold ocean because you know you might be close to your quarry. Being much more science based, KSP2 has an even greater opportunity to do this. On the Mun, give some mares asteroid debris fields on their borders that can be scanned for a chance to recover pieces of a meteor. On Duna have mountains form ranges where some mountains will, on close inspection, turn out to be volcanoes that can be used as a source of geothermal energy. This is the reason you might build a serious all-terrain rover, one that can challenge Duna's mountains to efficiently scavenge them for Volcanoes. Or perhaps it may justify you building a Duna plane with high-res cameras and sensors so you can fly over the mountain ranges hoping to pick up heat signatures. These kinds of connections mean players can get excited at finding a large thing that they can explore, searching for a small thing. And that is the sort of exploration people can really get invested in. It's a problem that is possible to solve with brute force, spending 1000 hours in EVA, but encourages creative problem solving. Creating mega-rovers and spy planes that can automate the tedius tasks. I think that these sort of additions could make KSP2 a true exploration game that rewards and encourages the development of a huge variety of vehicles to overcome equally varied challenges across the galaxy. I don't purport to know exactly how such features would specifically fit, but I hope this is a direction the devs give consideration to.

I would like to suggest that the Starlab does not pause its survey. Ones its deployed and surveying the data, it should continue to do so, until the research is done in the surveyed region. It hinders the pace a bit, especially on planets like Duna where the Biomes changes every few seconds. Maybe i do something wrong, or this is a Bug, but if not, it would be nice to keep the games pace. A alternative would be, that the Starlab automates this procedure, stopping the survey when the region changes, and automatically starts surveying again. I would like to hear some opinions, suggestions or maybe even help, because there is a chance that i do something wrong.

I know people sometimes are divided about bloom in videogames, but ksp 2 looks amazing at times with it, so here is my suggestion. On bop, currently, there is a bloom system in place. Other bodies also have this system but it was most visible on bop. This is a relatively light affect and it adds a lot to the feel of the game, and how pretty it looks, while masking the currently underperforming AA system. It also makes Jool properly shine, and other bodies in the Joolian system have a nice glow to them. BUT the problem is that this isn't on all bodies in the game. The mun could really use this system to highlight the highlands around the mares of the mun, and make kerbin stand out more in the sky. TLDR: MAKE BLOOM AFFECT EVERY BODY Just an idea, let me know what you think of it.

Just a small balancing suggestion, with the removal of the direct vs relay distinction between antennas (all antennas function as relays), it gives the KSP1 relay parts very little reason to practically exist compared to their deployable counterparts besides being immune to aerodynamic forces (Which, while giving a genuine decision making process for the smaller antennas, falls off with size due to the larger antennas often being very draggy). An example; comparing the HG-55 to its non-deployable counterpart, the RA-15, it's clear that the HG-55 outclasses it in virtually every conceivable way: It's much lighter (0.075t VS 0.3t) It has a much higher transmission rate (12.5 KiB/s VS 2.5 KiB/s) It uses much less electricity per KiB sent (0.7e/KiB VS 5e/KiB) \ The deployable antennas are lighter, deployable, more efficient and (barring the 88-88 vs RA-100) have faster data transmission speeds than their heavier non-deployable counterparts, to remedy this in my opinion the non-deployable antennas should be given significantly faster data transmissions speeds than their deployable counterparts (on the order of 3x their deployable counterparts) and better electricity/KiB efficiency, this would them much more of a gameplay distinction than their deployable counterparts and gives a genuine reason why players might choose to go with the much heavier non-deployable antennas compared with their deployable counterparts (Especially for missions that include time-critical EOL situations, such as an atmospheric entry probe that needs to transmit its science before being obliterated)

I'm not liking that a quick look around with the mouse causes a frame of reference change for jet pack controls. Controls staying with Kerbal, not camera, is simpler and expected behavior.

What's this rambling about? Having Colonies locked behind Tier 4 seems like it isn't the right way KSP2 should be played. It would feel too step-by-step I feel. So, introducing it as early as Tier 3 will make the game progression smoother for the colonies, could even put it in Heavy Orbital Operations? And this would probably mean low tech colony parts... And why's that? Colonies are highly anticipated and would change so much to the way we play the game, launching rockets, storing resources, building complex nice looking outposts, this is what would change the gameplay in an interesting way. In KSP1, the way you build stations was nice, but with the addition of colonies, it could be made much easier and user-friendly. And would also make the features get shown to the player much more smoothly, by introducing the concept when it would start to become useful (Like in the quest to go to Jool, you'd build a Duna outpost to make a relay to this planet). An example perhaps. In Tier 3, I'd go on to make a small Duna orbital outpost to coordinate operations to go to Jool, perhaps even launching from there if I could, though this seems rather too advanced for T3... But then, as I progress through the tech tree, I'd have more complex and bigger colony parts to use and expand this Dunian outpost. Like how in the real world cities came from small traveller encampments from the late 1800s and turned into huge cities in the current day... Closing thoughts... I think that colony parts could aid greatly in the exploration of the Kerbol system after T3, as it would serve as homes for science and resources. They'd be the backbone of the Program by aiding crafts in their missions, and providing a command center on the area. Of course, vessels would need to launch a sort of Colony core of some kind... Hopefully the idea is clear, and I hope we would all be able to experience the benefits of colonies even in early game- Limited, but helpful, and expandable in the long run!-

When hovering over a "stage-able "part, it should be highlighted in the staging area as well. Currently it ain't.

Introduction VTOL aircraft are awesome, they're fun to fly and land and generally are super cool: A big problem however is that KSP2 does not have any robotics parts, which severely restricts the options available when it comes to building practical VTOL aircraft in the game, and even when worked around you're still enduring a heavy performance penalty (both in terms of the aircraft's capabilities and your literal PC's performance) when compared with anything you can build in KSP1, those Whittle clusters and reaction wheels cost quite a bit! So, with the understanding that robotics aren't coming anytime soon, I figured I'd put forward my own suggestion for a nice alternative that'd fill this role perfectly, in the form of a brand new jet engine part: Introducing the J-8B "Karrier" Mass: 0.8t Maximum thrust: 80kN (Lifting capacity of 8.15 tons per engine on Kerbin) ISP: 6500s Alternator: 0.5 EC/s Deploy range: 90° (+10° single-axis gimbal, for a total authority range of 110°) Modelled after the Hawker Siddeley P.1127's engine nozzles (One of the experimental aircraft designs that eventually led to the Harrier Jump Jet) This engine is designed to be radially attached in pairs on the sides of an aircraft and can deploy for a full 90 degrees of freedom, plus 10 degrees of single-axis gimbal, giving it a large range of pitch control to alleviate the need for large numbers of reaction wheels to counteract torque. It can rotate its thrust vector downwards for vertical take offs and landings: And then, once off the ground, it can swivel its thrust vector around for horizontal flight: It can also be freely deployed to anywhere between the two angles to facilitate short take offs or other use cases people may think of. This engine fills a much needed niche in terms of VTOL jet aircraft, and would allow for so much more creativity in terms of plane design and functionality, as well as making it possible to build VTOL aircraft that are actually aerodynamic and aren't hard capped to the sound barrier (Whittle clusters suck). Balancing In terms of its stats, it needs to have a high amount of thrust for the obvious purpose of being a VTOL engine, and it also needs to be relatively light and not use too much intake air, that leaves its ISP as the main variable in terms of balancing this engine against other jet engines (Particularly the Panther, which it is rather close to in terms of thrust), I also didn't quite want to give it terrible ISP either as it may be used as the primary engines on certain aircraft designs. In the end, I decided that 6,500s of ISP feels like a nice middle ground, it's far more efficient than the three hypersonic jet engines (Afterburning Panther, Whiplash and Rapier), but simultaneously it's still well below the standard Panther and Wheelsley in terms of efficiency, ensuring that it does not replace either of them for general usage. Conclusion Generally (in my very totally unbiased opinion) as someone who's spent a rather unhealthy number of hours designing VTOL aircraft across both games, I believe this would be an amazing addition to the game that would open up so many new opportunities for aircraft design and construction, the specific stats I've laid out for for this engine are not solid "this is absolutely how it must be implemented" caps, but just represent how I personally feel it'd be best implemented should it become a real part in the game, I hope this post reaches the development team and they seriously consider implementing a part like this to fill this role.

way back there were plans and concepts for converting the shuttle's external tank into a habitat once in orbit, i think this would work really well for a ksp mod, possibly using materialkits to convert empty tanks, maybe even have premade modular habitat segments to fit any fuel tank, can't currently find any mods like this and I think it could be perfect for setting up simple stations, especially for those who like 70s style NASA builds

Fuel tanks have no valid reason to be in PAM as they don't provide any information and it is just wasted space there, at least inflight. In VAB you can show them there as you can set the fuel level. I am so confused if i right click a fuel tank in flight and wonder why there is no information. And always have to remind myself that there is a hidden Resource Manager.

Problem: I don’t know how much EC (Electrical Charge) my craft uses, produces, and stores. Figuring it out requires math (long math!), which I wouldn’t like to do! Plus, this problem gets even worse for more distant planets, where I must use MORE math to figure out the EC production, because Kerbol’s intensity decreases by distance! My Idea: My idea is to create an app that tells players how much EC their craft uses, produces, and stores. It could feature a system where players type the distance from the star, and the game does the math behind the scenes and uses that to change the EC production. Benefits: This system would help me a ton with designing crafts, as I can know the exact EC needs of it. This would save players from doing a lot of math and help them make even better crafts, as they don’t run out of EC halfway through the mission (speaking from experience here!). I hope you like this! TechieV

It’d be nice to be able to add waypoints on planets to mark places of interest or landing spots. You could add waypoints from the map view or from satellites.

These would be relativly short runways near the North and South poles of Kerbin that allow the player to land safely. They don't even have to be accessible from the VAB, they could just be little 'things'.

Currently my least favorite part of KSP 2 and the thing that keeps me from playing it is the tedium of interplanetary transfers. It’s always incredibly frustrating to plan out your transfers and they don’t work because of how incredibly tedious maneuver nodes are. There are a few things that need fixing and I have some new ideas. 1. Mouse Sensitivity When I’m zoomed out in the map mode, I can never get the camera orientation I want because insane sensitivity. Please fix that. 2. Time Warp Burning I don’t know if this is a bug but my craft never follows the maneuver whole time warp burning. This is terrible. Please fix this. Here are some suggestions for making planetary transfers much much much nicer. 1. Add a top down camera button Make a map mode where the camera is locked top down and the user can move the camera left and right but not change the orientation. Make it so we can select different planets/ planet systems. This would be like the camera angle blueprint things in the VAB. 2. Add a side view, similar to the top down view to see orbital inclination. Make it so we can see the whole solar system, planet systems and planets and so we can pan around the planets. Also similar to the blueprint idea in the VAB. 3. THIS IS THE BIG ONE. Add a good and reliable calculator that determines when to do interplanetary transfers. Like the one in ksp 1 but one that actually works. Again, planning maneuver nodes is incredibly tedious and unfun. If you really want us to keep manually planning maneuver nodes, then just warp us to the best time for interplanetary transfers. Again, transfers are tedious and because they’re so tedious are not fun at all to deal with. Focusing on quality of life should be paramount when creating such a complex and time consuming game such as this. Please take the time to consider this.

I would like to suggest few things for the Part Manager: Decrease the font size, it is too big. I recommend to use the Breadcrumb font size (see the attached images). This should be the size for the default UI scale (100%) If a tree node is empty, do not show the arrow. These nodes should not be clickable nor openable. Windows should scale by the UI scale game options Pinning parts in the Parts Manager should be handy during flight. A pin button on the right side of the part would look nice. If player pin a certain part it will remain open and moves on the top of the Parts Manager (could be a new group (eg.: Pinned/Favorites)) Let the windows width resize more and add multiple columns if the width of the window is wide. Instead of this we could have this size. This image shows the columns as well.

I created a feedback report explaining the situation in detail. https://bugs.kerbalspaceprogram.com/issues/24853

Ksp has always had this problem where there was no real reason to use generators, as the engines on your ship have could always just power everything. It’d be nice to actually have to attach generators to your ship to keep the power up. If they do decide to implement this a good quality of life feature would be to have a bar indicating how much power your ship needs vs the amount being produced, kinda like command and conquer.