Just why is KSP Physics so slow? (NOT a Rant)

[Nigeth]

My biggest wish right now is for the game to become more stable. I don't need new features. A stable 64 bit release of KSP where most of the bugs and kinks and performance issues have been solved. Just so that I'd be able to play this game for an entire evening without it crashing or stuff exploding.

[selfish_meme]

My biggest wish right now is for the game to become more stable. I don't need new features. A stable 64 bit release of KSP where most of the bugs and kinks and performance issues have been solved. Just so that I'd be able to play this game for an entire evening without it crashing or stuff exploding.

My 64 bit linux session that is streaming to my macbook has been up for over 12 hours, I have played on and off a bit during the day but no big ships just career.

[Laie]

12 fps is playable for a launch, 30fps is fluid video

I'm quite tolerant of low FPS and often do not notice. What I do notice is delayed response, similar to running an interactive program over a high-latency connection. What makes dockign 700 parts so tedious isn't the low framerate per se, but the insecurity wether the game has registered my input or not.

[Nigeth]

10 fps is 100ms input lag. Which is very noticeable

[selfish_meme]

10 fps is 100ms input lag. Which is very noticeable

Average human reaction time is 250ms

[Nigeth]

Doesn't change the fact that you notice it,.

[jaredkzr]

I'm quite tolerant of low FPS and often do not notice. What I do notice is delayed response, similar to running an interactive program over a high-latency connection. What makes dockign 700 parts so tedious isn't the low framerate per se, but the insecurity wether the game has registered my input or not.

I get this as well. When I get below 20fps I'll tend to overcorrect the course of my ships and bounce around a lot when trying to steer.

I usually shoot for above 30fps when doing any kinds of flights. Below that and its just too bad to play. I do not like my games being reduced to a glorified slideshow.

[ygarl]

P'raps we could have "effectively" parts welding on any parts less than a specific mass - because they simply don't contribute to the wobble between each other until they get above a fairly large size anyway.

So, that should save a fair bit of computing if you don't bother computing the "wobble" of a thermometer, for instance - or a single light.

It would slightly less exciting SUDEs (sudden unexpected disassembly event) or GEFs (gratuitous existence failure) at close ranges, but your fuel cells and tanks should still destroy each other correctly (with their welded-on thermometers) in a suitably gratifying way...

[Padishar]

Average human reaction time is 250ms

While that is true, it is not really relevant to the issues caused by input lag in a simulation. The problem is that when you press an RCS translation key the amount of time that it thrusts for is always at least one frame. So, at 10 fps you have to thrust in 100ms chunks rather than 17ms chunks at 60 fps. This gives you much less control when trying to dock so you generally have to take things much more slowly and carefully (and the game clock is slowed down too which makes everything take longer as well).

I've managed to accurately dock some very complex vessels together totalling over 700 parts on a 2.16GHz CoreDuo laptop. I don't think any of the dockings were over 10 fps and the last couple were done at 1-2 fps from the moment I came within 2.2km of the station. Yes, it was very tedious, and yes, I still enjoyed doing it, but I would much rather have had a better framerate...

[selfish_meme]

We all would enjoy a better frame rate, the only thing I object to is the problem being described as trivial to fix, and Squad being not interested in producing a great game. When the only people who have any experience at building such a game and have gone out of their way to build it obviously do find it non-trivial to fix. The only other reason would be some malicious sadistic pleasure they get out of some people's gaming expectations being crushed.

[cantab]

All I'm saying is that in my professional opinion, as someone who develops real time SW for a living, the kinds of bugs and 'kraken behaviours' that are still in this game are an indication that the development process of Squad is lacking in quality control and doesn't have implemented enough steps to ensure that bugs get squashed before a release is shipped or to make sure that old bugs don't rear their ugly heads again. The same can probably be said for the quality of the simulation.

While I agree absolutely with this, I strongly suspect it's not unique to Squad and that you will find similar development process issues in virtually any game development studio, where flashy features not stable bug-free code is what sells well and where the pressure to release yesterday is always there.

[Varsi]

While I agree absolutely with this, I strongly suspect it's not unique to Squad and that you will find similar development process issues in virtually any game development studio, where flashy features not stable bug-free code is what sells well and where the pressure to release yesterday is always there.

Companies that have released multiple games still manage to leave a lot of bugs in their games.

I assume one of the major problems with Squad is that they've been learning alot while building KSP and there's now plenty of old code that pretty much need to be rewritten completely to fix properly.

[Padishar]

the only thing I object to is the problem being described as trivial to fix, and Squad being not interested in producing a great game.

I don't remember anyone saying (or even implying) that "the problem" (which problem do you mean, by the way?) is trivial to fix. I gave a timescale for fixing one particular cause of slowness (and related bugs) that I believe to be quite accurate based on my investigations and my 23 years of professional programming experience.

When the only people who have any experience at building such a game and have gone out of their way to build it obviously do find it non-trivial to fix. The only other reason would be some malicious sadistic pleasure they get out of some people's gaming expectations being crushed.

The type of game is irrelevant, it is clear that there is a lot of code in the game that is highly non-optimal. This is not surprising in itself, especially considering that the devs have stated quite a few times that a lot of clean-up and optimisation work was put on the back burner while the game was in pre-release and features were still being added. What is somewhat surprising is that this work was not done before the 1.0 release. Ideally there should have been several more updates during the beta period that would have included the new features in v1.0+ and lots of bug-fixing and optimisation work (yes, that old chestnut).

While there are some people on this forum that probably would claim malicious intent, I'm not one of them, though the number of quite serious bugs that have not been fixed for many months (or even years in some cases) despite Squad having been informed of the precise causes and solutions does make me wonder. KSP is a great game and I think the devs have done very well to make it work as well as it does but I'm pretty certain they would agree that there are far more bugs and inefficient bits of code than they would like. I just hope that the project management can pull it's head out from where the sun doesn't shine and let the devs fix the problems sooner rather than later...

[selfish_meme]

I don't remember anyone saying (or even implying) that "the problem" (which problem do you mean, by the way?) is trivial to fix. I gave a timescale for fixing one particular cause of slowness (and related bugs) that I believe to be quite accurate based on my investigations and my 23 years of professional programming experience.

The type of game is irrelevant, it is clear that there is a lot of code in the game that is highly non-optimal. This is not surprising in itself, especially considering that the devs have stated quite a few times that a lot of clean-up and optimisation work was put on the back burner while the game was in pre-release and features were still being added. What is somewhat surprising is that this work was not done before the 1.0 release. Ideally there should have been several more updates during the beta period that would have included the new features in v1.0+ and lots of bug-fixing and optimisation work (yes, that old chestnut).

While there are some people on this forum that probably would claim malicious intent, I'm not one of them, though the number of quite serious bugs that have not been fixed for many months (or even years in some cases) despite Squad having been informed of the precise causes and solutions does make me wonder. KSP is a great game and I think the devs have done very well to make it work as well as it does but I'm pretty certain they would agree that there are far more bugs and inefficient bits of code than they would like. I just hope that the project management can pull it's head out from where the sun doesn't shine and let the devs fix the problems sooner rather than later...

I agree with most of what you say, and I do think pressure was applied to get this game out the door, possibly for the PS4 thing, though I can't see KSP being a big seller on that platform.

However I have my doubts about how quickly any of the more complex issues could be solved, in MY 20 odd years of Network Security and System Administration I have seen too many missed deadlines and catastrophic accidents for simple fixes, even in major corporations that pride themselves on testing methodology. Profiling tools are good but not omnipotent. Squad, having probably little to no experience building a simulation, or a game have probably liberally littered the code with bombshells ready to explode as soon as someone changes an output. This is not because they are bad or incompetent. They just used modern agile methodology and prototyped stuff out the door. They were not building real time systems that had peoples lives at stake and the amount of testing they did was surely adequate for a game. Many major studios have fared worse on their releases. I hope, and I am sure they do too that there comes a time when they can take the time to refactor the project.

[dueb]

...

I've managed to accurately dock some very complex vessels together totalling over 700 parts on a 2.16GHz CoreDuo laptop. I don't think any of the dockings were over 10 fps and the last couple were done at 1-2 fps from the moment I came within 2.2km of the station. Yes, it was very tedious, and yes, I still enjoyed doing it, but I would much rather have had a better framerate...

I remember some 2000+ parts UFOs back in the days...

[jkool702]

Are there any mods for the current version of KSP (1.0.4) that weld/fuse joints to reduce part counts? I looked for Ubizor's mod after seeing this thread and couldnt find it updated for anything past 0.90.

[Violent Jeb]

FWIW, it seems to have gotten a little worse post 1.0. I notice significant lag on the launchpad with crafts over 200 parts. Suffice to say I don't have problems with any comparable game, and didn't have problems with 250

I see the mentality in keeping the crafts "wobbly" and doing calculations on the parts that are in play. I even agree that separators or docking ports should be somewhat flimsy when they get extreme weight affecting them. With that in mind, I don't see why double or triple stacked tanks couldn't be "welded" prior to launch. IRL, I would imagine a fuel tank is usually made to order, rather than made by cutting the top and bottom off two fuel tanks and attaching them together.

This wouldn't bring part counts down entirely, but I would expect a reduction on the order of 30%, on simple cylindrical shapes that should be easy to scale/calculate as a whole. It seems like a happy medium approach, doesn't nerf or inhibit accurate calculations or animations, while lowering part counts.

I don't know of any mods for 1.0.4, I just try to keep the part counts sub 200.

[Laie]

With that in mind, I don't see why double or triple stacked tanks couldn't be "welded" prior to launch.

This wouldn't bring part counts down entirely,

Just do a tally of your ship's parts. Last time I did that (pre-1.0), the tanks were the least of my problems. This may have changed a little as we now have to fabricate pointy tips which often are two or three parts apiece. But what really drove part count, back then, were a) struts and all those tiny bits that are necessary to make a vessel work.

An Eve lander could easily be 20% struts and 5% ladders by part count. For a Jool-5 type mission, the struts could be fewer (but usually still over 10%) but every subassembly that needs to be independently mobile requires 8-10 parts for that purpose: probe core + battery + rcs system + docking port + power source....

If probe cores also had reasonable torque and battery capacity, that would help a bundle (the one from the asteroid day mod has become my favorite). A fifth nozzle on the RCS block. And overall, more rigid connections so that one doesn't need to go over the top with struts.

And yes, some degree of welding or procedural parts would also help. Is it really necessary that the nosecone be independent from whatever part it's attached to? And would it really break gameplay if I could have 7/8ths of an orange tank in a single piece?

However, all of these are only dealing with the symptoms. If it's really true that the calculations are as wasteful as they were made out to be some pages ago, then fixing them would be my preferred solution.

[Archgeek]

Now this has been quite the interesting and informative thread.

'Seems like the core flight simulation loops are in significant need of tightening up, as it seems the entire ship is scanned every step for every part that wants to consume or provide a resource, which is frankly terrifying. They very likely would see a surprising performance jump if it were scanned once -- with the scan populating lists of producers, storage, and consumers for each resource (EC, LF, O, Mono, Xenon, Ore, and I hope ablator was written as a special case) which are cached until lost, and flagged when depleted. Tightening resource scans alone would help a lot, but other loops seem to need tightening as well, which would in turn better expose where they can get away with parallelizing things for multi-threading (even my poor old Core 2 Duo would benefit from this)

I throughly understand how off-the-cuff that initial exploratory "can we even make this work" phase can be, but once a proof-of-concept is together, next should really be tightening it up enough to not want to explode, then profiling and fixing glaring computational bottlenecks and redundancies before adding more features (though ideas for making new or planned features will turn up and should be considered when tightening stuff up to avoid over-optimizing the incomplete version). Test-based design and unit testing would be great for preventing and early sqashing of bugs, but I'm guessing with a team that small no one had time to learn something like cucumber, though the argument could be made that the beta phase should've been just that.

Still, good on SQUAD for making this awesome thing in the first place. Hopefully a code-repair pass will find itself embedded in all the unity 5 re-writing.