Most Annoying thing in KSP

[Pax Kerbana]

Lag.

Admittedly it doesn't krash as often but that's a memory leak problem and the lag seems to have gotten worse. I could launch 800 part super craft, now my computer hiccups on 75 part bases..

[Kobymaru]

Here's my list:

- Performance. 200 Parts on a modern CPU should not be that big a deal. We're not doing weather simulations here.

- Physics bugs, so many of em... Random overheats, phantom torques, changing orbits without force, disappearing rotational velocities,

- Physics "wrongness": Stick air intakes to the bottom of your engines? Drag reduced! Struts of 1 cm length and buried between parts? Increases drag and overheats on reentry! Airbrakes fully deployed in hypersonic airstream while craft is engulfed in plasma? They don't even get warmer!

- SAS that's useless for anything bigger than a 5 part/2 ton ship.

- Spaghetti rockets, stations and planes because the joints are so damn soft. (No, I won't use KJR).

I've never seen a memory leak when changing scenes. Memory leaks in C# are quite rare. While they do happen, as with the temperature gauge, C# is a garbage collected language so any allocated memory is automatically released and recovered by the

garbage collector whenever the allocation falls out of scope. Unlike C++ where we had to manage our memory usage, it typically isn't necessary in C#. In non-GC languages like C++ we had dangling pointers and unreachable variables, but in languages like C#, Visual Basic, and Java, they get recovered the moment (technically, the next time GC is run) you lose track of them. The times when leaks do happen is when you have a loop running in a thread that doesn't end, as with the flashing temperature gauge. In that case the allocation never runs out of scope and rather than reusing what it had, it kept allocating new.

I thought so too. But whatever it is, if you change scenes too often, your game looks like this or this.

[Alshain]

I thought so too. But whatever it is, if you change scenes too often, your game looks like this or this.

I definitely see something wrong there but it isn't evidence of a memory leak, nor is it evidence that it isn't caused by one of your mods.

[windows_x_seven]

Game crashing when you spend a long time designing a craft and decide to press "launch", physics glitches, parts randomly overheating, rockets that try to dance "Wiggle" when you're trying to launch them, and EVA tasklessness.

- - - Updated - - -

What exactly constitutes a "scene change" in KSP?

Basically, when the "Loading" screen shows up, a scene change is happening.

[DalisClock]

The editor(VAB/SPH) is still occasionally buggy and merging two different craft can be annoying at times. Fix that and most of my complaints about KSP will go away.

[p1t1o]

Memory leaks are when a program doesn't release memory properly when it's finished with it, so next time it needs some memory it grabs a whole new chunk instead of reusing stuff. If every time there's a scene-change 10Mb isn't released, for example, then after 10 scene-changes the program is using 100Mb more than it needs. That only gets worse, until the computer just can't assign any more memory - then bye-bye. Knowing this doesn't always make it easy to find exactly where the leak is or to fix it.

That is pretty much what I imagined.

Knowing this doesn't always make it easy to find exactly where the leak is or to fix it.

...is probably the part that most people would find counter-intuitive, that it could occur in the code without the person writing the code being aware of it. Since I don't know much about code, apart from GCSE-level basics, I assume that it is not caused by incompetence, since there is a lot of evidence that the devs are extrememly competent but is this a problem that would take a major re-write to fix, or could it possibly be resolved in a future update?

It does seem to be independent of which exact mods I use, I could never pin it down to any specific one, so I doubt its anything in their code, though the frequency does seem to depend on memory load - I imagine that with much fewer mods and memory usage, there is space for enough scene-changes as makes it almost unnoticeable. But with anything more than a handful of mods it is a constant problem

Could live with most other bugs if this problem wasn't present. Most bug occurrences can be worked around, avoided or straight-up resolved with a save and a re-load. Unfortunately, when you only get 4 or 5 scene changes (this includes loading saves) before CTD, the frustration factor is multiplied many times.

[StarStreak2109]

The memory cap. I'd like to use about three times the mods I currently have.

So I feel sometimes as well. Want to click on all those shiny toys in CKAN, only to find the game is crashing. In the end I find I don't use half of the stuff I got in my install anyway, so one could say "you only have to sort out the stuff you don't use. But I do not want that. I want to try out stuff w/o always thinking about the memory cap. Why doesn't the game use buffering on the harddrive for instance? Also I would love to use more eye candy stuff (e.g. bigger skyboxes!), but that in it self is dangerous...

Most annoying: laggy physics starting at 180 parts and never fixed bugs like the claw related bugs, mirrored part group action restore bug, mining not suspended when tank full bug, everything explodes bug and your savegame is then unusable (which is most likely claw related), and so on and so forth

That is something I find more frustrating than the memory cap. With that I can deal by being cautious. But on any weaker PC it gets to the point where you can't have space stations, because the FPS go down the drain. That spoils it a bit for me sometimes.

[Mighty1]

A long time ago we were given a treat in form of a barn. It went away silently and no word will it ever return. I expected it in 1.1 but it appears it is not comming.

[Xyrus]

/software rant

Armchair software engineering is about as useful and productive as armchair quarterbacking.

First, a point. If your using mods, blaming KSP for bad performance, crashes, etc. is naive unless you can say with absolute certainty it is NOT the mods themselves causing the issues. There are number of mods that cause all kinds of problems with the game, even ones that you would think couldn't possibly impact performance. For example, I had to uninstall a mod that added atmospheric hazing because it would cause KSP to spontaneously switch to use integrated graphics instead of dedicated, dropping my normal 100+ FPS down to 5 FPS.

If you want to complain about crashes and such, first get your issues to happen in a stock game. Then actually send the detailed bug/crash report generated from the game to Squad. If they still don't do anything about it, then you can complain. Squad developers don't have ESP and they are more than likely not going to have a rig set up like your machine. If they don't know about it, they can't fix it. If they can't reproduce it, they can't fix it. Posting about memory leaks, performance issues, etc. in a forum with no descriptions about what you're doing when it happens is pointless and doesn't help anyone. It's like when people send me bug reports about my software that just says "It doesn't work". What the hell am I supposed to do with that?

And memory leaks aren't "foolish". I'd like to see anyone try to develop an application this complex without making mistakes. There is no conceivable way you can test every possible code path to ensure that the code is memory leak free. Worse, even if you identify a memory leak they can be notoriously difficult to track down. Managed languages (like C#) reduce the likelihood of "obvious" memory leaks, but they don't do squat against the subtle ones (like not using weak references in maps). Even with GC'd languages it is damn near trivial to create memory leaks.

/end rant

With that out of the way, the most annoying thing I find about KSP is that information that should be available isn't. There are several mods that I consider "must haves", but they all just expose information that you should have anyway (like KER). Yeah, I can calculate dV by hand, and transfer windows, etc. but I wouldn't consider that the most "fun" part of the game.

[Kobymaru]

First, a point. If your using mods, blaming KSP for bad performance, crashes, etc. is naive unless you can say with absolute certainty it is NOT the mods themselves causing the issues. There are number of mods that cause all kinds of problems with the game, even ones that you would think couldn't possibly impact performance. For example, I had to uninstall a mod that added atmospheric hazing because it would cause KSP to spontaneously switch to use integrated graphics instead of dedicated, dropping my normal 100+ FPS down to 5 FPS.

While I fully agree with that, this is directly in conflict with the "there's a mod for that" mentality. In my opinion (and in all all Mod users opinion, which would probably be the majority of players) the game lacks some critical features.

For me it's life support, for someone else it's textures, even you admitted to needing KER in order to make the game fun. So the game lacks those features, the community responds with "there's a mod for that" and even Squad deliberately does not implement things with the reasoning "it's moddable" (see Ressource System).

Let's face it: KSP is great, but it's mostly great because of its mods. The Stock-Stock game would get really boring really fast.

And then you announce that there's no support for Modded installs, and as soon as someone experiences bugs and problems then the community goes "ah well you shouldn't have modded it". Then let me ask, who of us is truly Mod-free? How realistic is it that a player who spends more than say 20h on the game doesn't have a single mod installed?

[Xyphos]

First, KSP Linux is still C#. Don't confuse C# with C#.NET.

Second, Unity uses a combination of C, C++, and C#. However the C and C++ is irrelevant when coding in C# because even if you allocate an object in C# with a C++ library, that library is self contained, it is up to the library to manage it's own memory and C# will manage the memory of the object itself and dispose of it when the scope ends. So, assuming the Unity library is doing its job properly, it still falls to the garbage collector.

so you're still insisting that C# is perfect, just because it's a managed language, and you're still insisting that the magical know-all garbage collector is the answer to the problems KSP faces and everyone else is just imagining these memory leaks. OK, fine. but understand that even with managed objects, a poorly used API will cause severe problems.

[marce]

so you're still insisting that C# is perfect, just because it's a managed language, and you're still insisting that the magical know-all garbage collector is the answer to the problems KSP faces and everyone else is just imagining these memory leaks. OK, fine. but understand that even with managed objects, a poorly used API will cause severe problems.

Memory leaks in a managed language should happen only in two cases:

1. Bugs in the runtime. KSP runs on a stone-age version of Mono, so I won't count that possibility out completely. Shouldn't be a major issue, though.
   
2. Developers making mistakes. Yeah, you can still mess the memory management up. Not as easy, but there are still a lot of best practices you can ignore to create leaks. For example not using using blocks where you should, registering event handlers (without unregistering) at some long lived object over and over again, etc. In fact the GC does a pretty good job (not starting a discussion about ref counting etc. here), but if you purposely load data into memory over and over again while keeping references to the old copy you can easily leak like a pro. The SQUAD guys are pros
   

To be fair though, since they can't control what Unity does they aren't to blame always (the issues of not owning your engine). The major point they are to blame for is the lacking commitment to release quality, not the occurence of bugs.

[Padishar]

so you're still insisting that C# is perfect, just because it's a managed language, and you're still insisting that the magical know-all garbage collector is the answer to the problems KSP faces and everyone else is just imagining these memory leaks. OK, fine. but understand that even with managed objects, a poorly used API will cause severe problems.

Indeed. Most of the memory leaks that I've investigated in KSP have been caused by incorrect usage of the Unity API. Most objects in Unity have an underlying object pooling mechanism designed to reduce garbage creation (or shift it to scene transitions where the user won't notice the garbage collection running) and they have to be explicitly deleted, you can't rely on simply nulling a reference or overwriting it with a new reference as the object will still be referenced internally in the pooling mechanism. As an example of this, there is a memory leak in the engineer's report caused by it creating a new Unity.Mesh object for each "fault" in the report and just overwriting the old references without explicitly deleting the old objects. This results in at least 6 Unity.Mesh objects being leaked every time the vessel is changed.

[kreutzkevic]

Memory limit in Windows. We'll see if we have "64 reasons to be excited" after the 1.1 release

(cue dated meme)

Edited September 11, 2015 by kreutzkevic

[BudgetHedgehog]

If your using mods, blaming KSP for bad performance, crashes, etc. is naive unless you can say with absolute certainty it is NOT the mods themselves causing the issues. There are number of mods that cause all kinds of problems with the game, even ones that you would think couldn't possibly impact performance. For example, I had to uninstall a mod that added atmospheric hazing because it would cause KSP to spontaneously switch to use integrated graphics instead of dedicated, dropping my normal 100+ FPS down to 5 FPS.

If you want to complain about crashes and such, first get your issues to happen in a stock game. Then actually send the detailed bug/crash report generated from the game to Squad. If they still don't do anything about it, then you can complain. Squad developers don't have ESP and they are more than likely not going to have a rig set up like your machine. If they don't know about it, they can't fix it. If they can't reproduce it, they can't fix it.

To be fair, a few things are stock bugs that mods exacerbate or reveal. A lot of users blamed FAR for overheating parts, when it's stock silliness that is the root cause. High res textures and loads of parts equal OOM crash, sure that's the mods fault, but only indirectly. The direct fault is that the program A, loads everything at the start (Squad wrote that asset loader) and B, can't access over 3.2GB of RAM and crashes when it tries to (engine limitation, I know, but it's not the mods fault. Get enough stock textures and parts and it'll happen in a stock game).

The point is, some bugs/issues don't manifest themselves in a stock game, but the underlying code/reason for them is still there.

[steve_v]

Armchair software engineering is about as useful and productive as armchair quarterbacking.

First, a point.If your using mods, blaming KSP for bad performance, crashes, etc. is naive unless you can say with absolute certainty it is NOT the mods themselves causing the issues.

While certain mods (MechJeb, I'm looking at you) do have a significant impact on performance, this is easily quantifiable.

I have done my fair share of whining about performance issues and bugs, but I am well aware that reproducing the issue in a clean environment is step one in figuring out what's going on.

I'm sure most others reporting issues know this too.

Many of these issues (e.g. the well-known stutter) have been extensively tested, both by myself and many others on these forums.

It's not the mods.

They may well exacerbate the problems, but the root causes for the abysmal performance and memory issues are almost certainly with Unity itself, or a lack of optimisation in Squads code to work around Unity flaws.

Case in point: brain-dead asset loader.

The second most annoying thing in KSP is the constant parroting of:

"It's not Squads fault" / "It's a Unity issue" / "Too many mods" (in a game that claims to be extremely moddable) / "But it's not as buggy as <well known buggy game>" / "It's the users/modders fault" etc. etc.

This happens every time someone brings up the blindingly obvious, well recognised problems in this released commercial product.

Reporting performance problems without context / reproduction steps? Here you go:

Performance is terrible, all the time.

Repro steps: Start game, assemble any collection of 200+ parts in VAB or SPH, launch, observe massive CPU bottleneck and poor framerates.

What more is there to say, I can produce as many test cases and part-count vs. framerate plots as you could ever want - in the stock game.

My gripe with the outstanding bugs and performance problems is precisely that they are well known and well documented.

"Armchair software engineering" is indeed unproductive.

But that's what's left when the old problems still haven't been fixed, and nobody is saying "Ok, thanks for the report, we're working on it and hope to have a fix out in release X, or X.X".

As for ESP - who can tell? There's bugger-all feedback from Squad on the public bugtracker, and it sure seems like they don't read reports on these forums at all, complete or otherwise.

"Poor performance / OOM" reports especially - they get tagged "Unity issue" or "Mods" and are never seen again.

The third most annoying thing in KSP is the lack or required information, but there are mods for that... Oh, wait a minute, it's mods causing all the problems isn't it? Now what?

[godefroi]

If a mod exposes a "bug" in KSP that is not exposed without, then is the bug in KSP, or is it because the mod is exercising the game in a way it was never designed to be?

Things that make you go, "hmm."

[cantab]

Quite. A craft can be fine in stock and persistently overheat in FAR, I call that a FAR bug. After all it's Ferram Aerospace Research, not Ferram Thermodynamics Research, and I'm of the view that it should leave the heating the heck alone.

[nismobg]

MOST ANNOYING is the fact that nobody can fix for 2 years the VIEW of the ships/planes being implemented so badly to the COM.

[legoclone09]

The editor, elevons in B9 procedural wings attach at weird angles, usually about 3* rolled or yawed.

[Provisional Name 41]

"NOT ENOUGH DATA STORAGE TO RESEARCH THIS" During your big Munar expedition that cost you half your entire funds bank.

I hate it so much.

[cantab]

"NOT ENOUGH DATA STORAGE TO RESEARCH THIS" During your big Munar expedition that cost you half your entire funds bank.

That message pops up all the time when I choose to convert science results into data. The data still gets made and put in the lab though, provided there is in fact enough space.

[BudgetHedgehog]

Quite. A craft can be fine in stock and persistently overheat in FAR, I call that a FAR bug. After all it's Ferram Aerospace Research, not Ferram Thermodynamics Research, and I'm of the view that it should leave the heating the heck alone.

I'll just leave these here:

@cantab: At this point, the only option left available to me is to disable explosions due to overheating. It's a stock bug, all the skin temperature settings have been set to use the stock code as a fallback if it reaches the point where FAR could exacerbate things, there is absolutely jack that I can do.

Take your bug report to SQUAD and ask them why they didn't bother to hotfix it. I'm not chasing after their bugs.

Given the extent that people seem to want to complain about FAR exacerbating this, I guess I'll try and rush out an updated version with the only heating tweak I could find.

So the basic problem seems to be that stock utterly sucks at handling parts with very low skin thermal masses; it doesn't have an overall cap on the amount of temperature change between physics frames for skin temperatures, so it can oscillate out to infinity if the skin thermal mass is small enough that the temperature change puts it well above / below the parts it's connected to. Then that difference continues to grow over time.

The main reason that FAR seems to exacerbate it is that FAR sets the skin area (and thus, the skin thermal mass) from what's actually exposed (as well as setting the stock "shielded" flag if it is completely shielded), as opposed to stock that basically does all-or-nothing, only getting minor changes from stack-attached parts, not surface attached. Adding a very quick hack to make the skin area never drop below what stock would calculate should make the problem smaller.

It won't go away, because it's a stock bug, so don't get your hopes up. All of these issues are likely to continue, because it's a stock bug. And remember, I can't fix a stock bug.

FAR doesn't touch the thermal system at all, it's stock being stupid that's causing the problem (it's possible to get craft to overheat and explode, while stationary on the runway due to this bug, in a stock game).

Edited September 11, 2015 by ObsessedWithKSP

[steve_v]

The editor, elevons in B9 procedural wings attach at weird angles, usually about 3* rolled or yawed.

Yup, and it's been explained before why this happens. Limitations within KSP that modders can do nothing about - specifically that "symmetry" in KSP really isn't.

The number of workarounds for stock editor screweyness needed to do something as obvious as procedural parts is... disturbing.

- - - Updated - - -

FAR doesn't touch the thermal system at all, it's stock being stupid that's causing the problem (it's possible to get craft to overheat and explode, while stationary on the runway due to this bug, in a stock game).

Correct. The instability in the stock thermal system is well reported, Squad have acknowledged it and there is word of a fix in 1.1. That it hasn't been hotfixed already is baffling.

Please, everyone stop blaming FAR now.

Edited September 12, 2015 by steve_v

[78stonewobble]

"NOT ENOUGH DATA STORAGE TO RESEARCH THIS" During your big Munar expedition that cost you half your entire funds bank.

I hate it so much.

Right now, it's this for me as well and I still don't understand why the limit is there. I don't see the point in my waiting for a number to drop rather than doing mun landings.

I don't need to get more science or faster science than I normally would, but the timewarp and micromanaging is a chore.

So I say either raise the datalimit quite a big or give us some datastorage modules we can use to offset the low lab limit.