What Annoys You Most About KSP

[qromodynmc]

Mods are real trouble, even though unity engine is problematic when it comes to physic performance, mods are even worse. Most of them won't use resources properly and reduce overall game performance. 

[OutInSpace]

I'm sure it's already been said, but memory leaks, especially with a lot of mods. I have 16GB of RAM, but I run AVP, the entire NearFuture pack, and a grab bag of others. The game usually slows to a crawl after a few hours.

Fortunately fixing it just needs a restart, but off an HDD the initial load takes a good eight minutes.

 

[Scarecrow]

Soggy noodle rocket syndrome.  It would be nice to not have to rely on KJR to avoid rockets flopping about like a drunk worm as it takes off.

[Xyphos]

Lagtastic single core physics. Hello? Frame rate? Where are you?

I know it's been said that multicore physics is impractical, but there's only so much a modern CPU can do in the short amount of time required.

PS. I still say Unity was an awful choice for a game engine.

Edited July 28, 2020 by Xyphos

[Pipcard]

On 7/24/2020 at 10:46 AM, Scarecrow said:

Soggy noodle rocket syndrome.  It would be nice to not have to rely on KJR to avoid rockets flopping about like a drunk worm as it takes off.

Without Kerbal Joint Reinforcement, my main interplanetary mothership would break apart if I tried to do any physical time warp while burning. With KJR, 4x time warp - no problem.

[kmMango]

On 7/18/2020 at 10:08 PM, catloaf said:

 

My main gripe with the maneuver nodes is that they close sometimes, and the visual interface that ends up making you do the wrong thing. It would like be no nice to have a maneuver mode app (like resources in the top left corner) that would open up an interface like this:

-----------------------------------------------------------------------------

Maneuver minimum dV change 0.1 m\s

-----------------------------------------------------------------------------

Maneuver #1

Maneuver in t+ 0d, 4h, 30m | -/+ |

Burn time 5 seco nds

Start burn t+ 0d, 2h, 12m |  50% | -/+ | 

Total dV: 157 m/s

dV Prograde 123 m/s | -/+ |

dV Radial -12 m/s | -/+ | 

dV Normal -22 m/s | -/+ |

Maneuver #2...

-----------------------------------------------------------------------------

So it's probably missing information but it shows my idea. Most numbers that should be edited could be, and you could access it without having to click on a maneuver node. All of the -/+ widgets could be clicked or dragged or clicked, where clicking them would change the time by 1 minute or change the dV by the value in maneuver minimum dV change and dragging them would be like the current maneuver nodes. This system is in my opinion superior to the current one because it's all in one place and does not require that you zoom out in the map view. Clicking on a maneuver will bring up the interface and it could be dragged around the screen.

 

The map screen would be so much better if you could just untether the camera and move it around with WASD. I do like your main screen maneuver editor though. Typically though, once I am ready to go interplanetary in career mode, I slap Mechjeb modules on my stuff and use it for rendevous, basic transfers, and putting rockets I have flown a lot into orbit. It just gets too tedious plotting all of it by hand.

[fragtzack]

Ground physics are wonky. Things bounce around for no apparent reason. A brand new rover when initially spawned and not being powered can start hoping around on the perfect level of the runway. The wonkiness gets much worse on other planets, especially when trying to hook base parts together or refueling 2 ground vehicles. Usually comes down to springs being overloaded, but not always.

 I end up saving and reloading a lot during any ground based operations. 

[Goufalite]

53 minutes ago, fragtzack said:

Ground physics are wonky. Things bounce around for no apparent reason. A brand new rover when initially spawned and not being powered can start hoping around on the perfect level of the runway. The wonkiness gets much worse on other planets, especially when trying to hook base parts together or refueling 2 ground vehicles. Usually comes down to springs being overloaded, but not always.

 I end up saving and reloading a lot during any ground based operations. 

Take a look at the WorldStabilizer mod, it soften physics when loading a ship.

 

[catloaf]

2 hours ago, kmMango said:

The map screen would be so much better if you could just untether the camera and move it around with WASD. I do like your main screen maneuver editor though. Typically though, once I am ready to go interplanetary in career mode, I slap Mechjeb modules on my stuff and use it for rendevous, basic transfers, and putting rockets I have flown a lot into orbit. It just gets too tedious plotting all of it by hand.

Yes, but this is for players like me who don't use mechjeb and the console players who can't. I don't know if you have used principia but my idea is sorta like that except it's not clunky. Also I don't know this.because I play on pc, but I imagine this will make maneuvers on console easier.

Also, on maneuver nodes another thing that sucks is that they assume the impulse is instant. Ion engines and nuclear engines would be much better if you could accurately plot maneuver nodes that understood that the impulse would be applied evenly over the course of the burn time. Of course an easy simplification is to create small 1 sec burn time maneuvers in the predicted trajectory. Basically every time the node changed it would create a 1 sec burn time maneuver, than another, than another but forgetting the predicted trajectory for the first, for performance, and doing it until the required dV is spent, then using that to show the final prediction. This would make ion engines vetter, because you wouldn't lose efficiency from correction burns and inaccurate maneuvers. If my changes were made maneuvers would be a lot more fun. Sorry for the terrible explanation, but what it does is creates a 1 sec burn time maneuver predicted trajectory, and then another 1 second after the last one (on the new trajectory) and then again but delete the first maneuver. This would be literally a for loop and some copied code, come on squad.

[swjr-swis]

It's still not finished. So close, and yet ever so far.

It was my main complaint back in my 2017 review, and it still, now 3 years later, does not seem to have even the slightest intention to ever be finished. Every single patch released adds another set of issues and further ignores the list of long-known and recorded/reported ones. Sigh.

KSP is an amazing game. I love it to death, and aside from the few years I spent almost literally living in EVE Online, it is easily and by a very long shot the game that I spent most time on, ever. A quick calculation back when I posted my review on Steam told me I had long passed the 10k hours on it... back in 2017. I've since then spent at least a similar amount of hours on it. It's awesome, and it draws me back in and makes me play, still now.

And every single time I play it, I run into the same set of long-standing and long-known faults, and every new patch coming out makes it evermore unlikely they will ever be solved. I so ... wish they would just get up and get the game into a state I can finally just load up and not have to deal with obviously missing parts, glaringly incorrectly rotated/offset textures or models, mindbogglingly sim-breaking drag cube definitions, half-implemented functionality, major bugs, or random wonkiness anymore.

Sit down, tally it all up, and just methodically work down the list and finish the damn thing already. We can argue to hell and back about how we can't ever know how much effort it would take, but some of them are so stupidly low-effort to do that they are literally just a set of MM patches away from getting fixed, for literally years now. And they are still there.

Certain issues may (not entirely convinced, but hey) in all honesty not be solved on the current codebase anymore; then for Kerbol's sake just pick the nearest compromise that will avoid the issue, or simply deimplement them entirely. Yes, at this point, even complete removal of for-all-intents-and-purposes dead or never-to-be-completed-or-fixed features is on the table in my opinion. Why insist in including simulation of leg/gear suspension if the only thing we can ever reliably make them do is play Wacky Springs (tm) all day? Why even bother with semi-realistic friction if the nearest real life equivalent we can actually simulate is Holiday On Ice or Glacier Creep? Accept defeat, fake it and remove those from the entire physics engine that apparently can't ever be taught to simulate them even half-decently. For those sufficiently emotionally attached to such features, there's always mods - which somehow seem to find ways to add things in a working fashion anyway even when the devs insist it's not possible.

I don't care if this means DLCing whatever other features you still have in the never-to-be-revealed pipeline. Heck put a price on those to make the additional effort of a finishing run economically viable if you must. I may even buy them if they're interesting and I have money to waste, as long as I have the choice to not using them to avoid any new bugs/issues that they may add... if I know they are funding an honest-to-goodness finishing run.

But please. Just ... finish it already. I can't stress how much it irks me encountering the same old flaws still glaringly still there, every play, or new ones being added in newer patches, of this absolutely amazing game that I am clearly doomed to play into eternity.

...

"Why won't you let me love you, KSP?" - Sisyphus (reportedly)

 

[kmMango]

27 minutes ago, catloaf said:

Yes, but this is for players like me who don't use mechjeb and the console players who can't. I don't know if you have used principia but my idea is sorta like that except it's not clunky. Also I don't know this.because I play on pc, but I imagine this will make maneuvers on console easier.

Also, on maneuver nodes another thing that sucks is that they assume the impulse is instant. Ion engines and nuclear engines would be much better if you could accurately plot maneuver nodes that understood that the impulse would be applied evenly over the course of the burn time. Of course an easy simplification is to create small 1 sec burn time maneuvers in the predicted trajectory. Basically every time the node changed it would create a 1 sec burn time maneuver, than another, than another but forgetting the predicted trajectory for the first, for performance, and doing it until the required dV is spent, then using that to show the final prediction. This would make ion engines vetter, because you wouldn't lose efficiency from correction burns and inaccurate maneuvers. If my changes were made maneuvers would be a lot more fun. Sorry for the terrible explanation, but what it does is creates a 1 sec burn time maneuver predicted trajectory, and then another 1 second after the last one (on the new trajectory) and then again but delete the first maneuver. This would be literally a for loop and some copied code, come on squad.

There are existing ways to mitigate this. Say you have a two minute burn. You start firing your engine one minute before the node, so half the burn takes place before, half after. This minimizes, and for shorter burns, effectively eliminates, the error created by not delivering the required Delta V instantly.

With that said, I like your solution a lot. My only concern would be performance for lower end machines, as KSP is not exactly known for being a well optimised game. From how you described the required code, it doesn't seem like such continuous recalculation would be too intensive.

[catloaf]

1 hour ago, kmMango said:

There are existing ways to mitigate this. Say you have a two minute burn. You start firing your engine one minute before the node, so half the burn takes place before, half after. This minimizes, and for shorter burns, effectively eliminates, the error created by not delivering the required Delta V instantly.

With that said, I like your solution a lot. My only concern would be performance for lower end machines, as KSP is not exactly known for being a well optimised game. From how you described the required code, it doesn't seem like such continuous recalculation would be too intensive.

No, I do the start before maneuver node thing, I'm talking about ion engines, where it gets to the point of having different phase angles because you've moved 150 km away from the node by the end of the burn. It's ten times worse with mods. For example in an episode of beyond Kerbol, the ship was halfway out of Fust's (about Duna sized) soi before the burn was complete, and the trajectory was definitely off, probably wasting 200 m/s in correction burns. Also, an idea I had about lag is the higher the burn time the less small maneuvers, so a quite 1 m/s burn could have 0.01 m/s burns 10 m/s would have 0.1 m/s, and 100 m/s would have 1 m/s. That way big burns would have low accuracy, because high accuracy is unnecessary, and small burns would have high accuracy to be more precise. Also, as the fps dropped it could increase the the it took to calculate to use was resources, also, you could have a dV cutoff for the more accurate burns, so for example, a burn would need to be more than 200 m/s before the more accurate system would be used.

[MalneyKerman]

I don't know if this has been said already, but what annoys me most of all about KSP is the awful, leaky memory management.

[GigFiz]

1. Input locks. it's great that you can fix it easily (alt F12 menu), but I have to go clear them out far too often, just to be able to do basic things (getting locked out while you are switching stages mid burn is super fun).

2: The cameras. The SPH camera is totally fine; but instead of being the same(ish, at least), the VAB camera is this whole other thing where you have to constantly fiddle to keep things centered and get the angle you want.

The in flight camera is mostly fine (at least usually), but when docking it is a nightmare to get the angle and position I want. And on larger craft, using Aim Camera to hop around because I can't move the camera, just to get to the parts I need, is also really annoying.

3. The optimization (as others have mentioned). How I can run AAA games on ultra, yet a decently high part count vessel will stutter and lag (I do understand that this is also a CPU vs GPU thing, too. It's still aggravating, though).

4. The rigid attachment & autostrut system is great for dealing with noodle syndrome, but having to do it to every part individually, every time, is incredibly tedious.

Ok, done yelling at clouds for now.

[Pipcard]

Rendezvous with a vessel, you slow down to a reasonable speed (few m/s) relative to the target and time warp. The ship you're trying to rendezvous with then jumps several meters to the left or right.

Edited August 6, 2020 by Pipcard

[Probro]

ngl i was kind of annoyed at the fact that ksp will have saturn v parts locked behind a dlc paywall and the rotors, i still loveksp and i have both the dlcs but still i was livid when they locked the saturn v parts and the electric motors behind a paywall

[Lewie]

[snip]

Then there is the ‘toy’ scale mod. It makes everything 1/10 the size of the stock game scale...

Edited August 29, 2020 by Vanamonde

[Bej Kerman]

[snip]

Do a grand tour, landing on all the planets, and tell me the game is too small. Making it bigger would just add time to the game.

Edited August 29, 2020 by Vanamonde

[katateochi]

Considering the scope of this game and how long I've been playing it, there aren't too many things that really annoy me.....but there are some
I would put  memory issues as the worst offender, but others have mentioned that already.
 

This

THIS
This bit of UI design makes me irrationally angry every time I see it, It offends me on several levels.
If I accidentally open the contents of a science container (especially one with that many results in it) I then have to click through every single result just to close the window.
It's actually easier/faster to do a quicksave and reload or switch to another craft and back again just to close it.
Even when you're not pillaging a planet for all it's sci in one go, and just have an action group that runs all stock experiments, that's still too many clicks required just to close a window.

A simple close button in the top right corner would make this a lot better, but even with that it's just a bad bit of UI.
It's ok to get UI design wrong when you're creating a novel bit of UI, but this is just a standard "list and view", a UI concept that's as old (older) than HTML. There are standard conventions for this sort of interface.
It should have a list view, where you can see all the results as a list (preferably with options to group and sort it by various attributes like which biome or body it came from, experiment type, science value etc). From the list view you should be able to click on each one to view the details and take actions (although you should also be able to make common actions (ie delete, transmit, process in lab) from the list view). And from the details view you should be able to return to the list view.  And from any view you should (WITH ONE CLICK) be able to close the window.
It also would be nice if the window would remember it's position on the screen and not always appear centre stage like it's the most important thing ever!

 

The other thing in KSP that upsets me is watching your base do an impersonation of a glacier and gradually creep down hill. I say "hill", I  don't think a 1.2 degree incline should really be called a hill, but even on such small inclines, surface craft will still gradually move.  There needs to be a mechanism which locks stationary craft in place until an internal or external force acts on it.

 

[LittleBitMore]

I'd say either one of 3 things:

1. The tech tree. It's unbalanced, some parts are in the wrong order, and crew comes before probes. I do not see this being changed in KSP 2.
2. The price. It's an excellent game, don't get me wrong, and I don't regret buying it, but my wallet did not like the fact that I bought KSP and its 2 DLCs. I do not see this being changed in KSP 2.
3. As mentioned above by others, the lack of unique science messages. As a hobbyist programmer myself, I know it's not hard to build some wacky arrays filled with all sorts of science messages, and I feel as if they kinda decided to be lazy with this one. While this might be changed in KSP 2, it's a lot more work to do this for several solar systems instead of just one.

Edited August 9, 2020 by LittleBitMore

[steve_v]

Updating to the latest patch because it's claimed to fix bugs introduced in the previous one, to discover that the only fixes were the lowest-hanging fruit, and a bunch of new bugs have appeared. Repeating this cycle ad-nauseam, since beta.
Seeing all the hype about features nobody asked for, while the patch notes make no mention of bugs that people have been complaining about for years.
Watching the GNU/Linux build get progressively slower and more broken with every update.
Every single .0 release being horribly broken in some blindingly obvious way.
Hotfixes for the broken .0 release that don't address all, or even the most annoying of the new bugs. Then silence until the next major patch, which breaks something else.
Consecutive releases alternately fixing and breaking the same systems in different ways, repeatedly.
Every second release breaking fairings, cargobays or aero occlusion.
Trying to use wheels for anything since 1.1.
Landed craft sliding around for no apparent reason.
Orbital precision problems that have plagued the game since beta still not being fixed, and new orbital drift problems being introduced.
Returning to craft to find them rendered useless by joints have been permanently displaced, then seeing the relevant bug report closed with wontfix "acknowledged".

Edited August 9, 2020 by steve_v

[Goufalite]

Lack of stock docking tools and UI

Docking takes a lot of part of the game (space stations, refueling,...) and there's a lack of docking UI helpers. I know that a lot of people do the "lowne lazy method of docking stuff" by switching to target mode on both ships, but what if one of the ships is a huge space station? without reaction wheels? without control?....)

Docking is here for a long time and we're missing

• An alignement indicator. We have to rely on two mods for this: Navball Docking alignement indicator (which gives a helpful yet tiny indicator) or the Docking Port Alignment indicator (which depends on module manager). Aligning docking ports (angle and position) is 80% of the work, the rest is slowly coasting.
• A Precise view of docking. Again the Docking Port alignment indicator gives info but if the ships are massive we can't see well the alignment with the camera. The HullVDS mod fixes this, or the advanced tweakables to have a "aim camera" option.
• A BETTER TUTORIAL. The tutorial is litteraly "smash the IJKLHNCV buttons until you dock". It doesn't hint on the normal axis trick to auto-align small ships for example. Also it should be splitted into two tutorials:  rendezvous and docking, like the asteroid tutorial.

Since 1.7 I'm happy to see nice UI improvements for dV and orbital info, but since then nothing for docking... So this is more an annoyance than a rant since I'm waiting for a new update to add this.

[Okhin]

The lack of save this settings and make it the default for all parts forever. I'm specifically thinking of the "Rigid attachment" settings.

Or a way to group items for assigning them to action groups, or default actiosn group (like having the solar panel switching on/off assigned to one AG forever).

[Starhelperdude]

there is a bug in 1.8.1 that annoys me:

When I want to launch a rocket, the rocket doesn't launch, but the TWR is over 1 (most times 1.2-1.8) and sometimes boosters fly off, it appears as if the kraken had glued my rocket to the ground

[Pipcard]

Flickering orbits in the map view.