Unity 5.2.... optimized UI.... coming NOWISH.

[TheTom]

As in: tomorrow No API change according to the post on the Unity3d blog. They just did sit down and start optimize the internals.

Nice. Now if Squad does the same with the extremely slow and badly scaling ressource system (distributing things like electricity) we may get a lot larger rockets again in the next update.

Hope they move KSP to Unity 5.2

[EladDv]

badly scaled resource system? how is that even a thing? you might be confusing the number of parts or their size-i havnt seen or heard of any problem with the actual resource system

[TheTom]

Do a google search. Performance of the "physics" system goes down brutally depending on how many tanks or batteries you have. This is a LOT more brutal than physics.How long do you play?

It is well documented that ressource distribution is a performance hog. Among the issues being that the list of all containers for a resource is regenerated every frame.... It is in their bug list.

http://bugs.kerbalspaceprogram.com/issues/5136

So, it is not "physics" that is slow per se. Not with something as trivial as a 200 part ship

[Xyphos]

wait, wait, wait, WAIIIIIT!!!!

I'm a self-taught computer programmer since I was 12, I'm now 33, and a semi-truck driver.

even I know that rebuilding a resource list every game frame is too taxing. ... is Squad even thinking?

resource handling should be done as an as-needed, event-driven multi-threaded process with concurrency management.

you don't even need Unity to crunch a few numbers in the background on another thread, within a "thread pool" to reduce memory usage and garbage collection.

somebody please get their software team a computer science book.

Edited September 8, 2015 by Xyphos

[Nathair]

It is well documented that ressource distribution is a performance hog. Among the issues being that the list of all containers for a resource is regenerated every frame.... It is in their bug list.

Could you perhaps provide a link to this documentation?

[EladDv]

Do a google search. Performance of the "physics" system goes down brutally depending on how many tanks or batteries you have. This is a LOT more brutal than physics.How long do you play?

It is well documented that ressource distribution is a performance hog. Among the issues being that the list of all containers for a resource is regenerated every frame.... It is in their bug list.

http://bugs.kerbalspaceprogram.com/issues/5136

So, it is not "physics" that is slow per se. Not with something as trivial as a 200 part ship

when each part draws its resources from an entire stage (which can consist of a lot of parts) it takes resources to do so-so yeah there will be lag from that but just having resources on a ship dosnt slow it down much-a simple string is keeping all the resources while not drawing from them.

[DMagic]

wait, wait, wait, WAIIIIIT!!!!

I'm a self-taught computer programmer since I was 12, I'm now 33, and a semi-truck driver.

even I know that rebuilding a resource list every game frame is too taxing. ... is Squad even thinking?

resource handling should be done as an as-needed, event-driven multi-threaded process with concurrency management.

you don't even need Unity to crunch a few numbers in the background on another thread, within a "thread pool" to reduce memory usage and garbage collection.

somebody please get their software team a computer science book.

Yes, and what's really frustrating is that KSP has lots of events that can be triggered whenever anything about the vessel changes (docking, staging, parts breaking off, ect...) so it's not at all difficult to keep an up-to-date dictionary of all the relevant parts. I've done this with [thread=120731]EVA Transfer[/thread] to avoid just that problem of constantly cycling through every part and it seems to work fine.

[Guest]

Yeah, first time I saw that I thought it was madness. KSP can, and very much needs to, be optimized in so many ways

[TheTom]

In this case you can even get a lot more efficient by having a buffer per resource. No need to go to the producers for every tiny request

* At the beginning of the frame, fill the buffer with he complete amount available. Which is a precomuted list that ONLY gets updated when - it needs. Oh, and also get the amount of free storage

* All consumers use the buffer, all producers go into the buffer. Buffer can not go negative. Use the "free storage" available (ONE number) to stop producers as needed, or throw away the surplus.

* End of the frame, use the delta of the buffer to adjust the storage. More in the buffer? Distribute as "fit". Less? Take from storage as fit.

And if you get REALLY smart you do that with 1 physics frame delay. "Transfer time": Which means in Frame x you allocate the resources for the next frame. In a separate thread. Not even unrealistic. Even electricity does not necessarily fail "immediately" with all the condensators electronics has.

There is absolutely NO need to go through this list.

And, btw., this list is not generated once per frame. It seems it is generated every time a resource is requested (!). Which - with most resources - happens quite often per frame

Yes, they are seemingly extremely inefficient - abusing the already horrific (Sorry) GC by generating tons of garbage. And this is why Phyiscs optimizations in Unity 5 will not ring big gains - it is not the physics that is the problem, it seems

[EladDv]

In this case you can even get a lot more efficient by having a buffer per resource. No need to go to the producers for every tiny request

* At the beginning of the frame, fill the buffer with he complete amount available. Which is a precomuted list that ONLY gets updated when - it needs. Oh, and also get the amount of free storage

* All consumers use the buffer, all producers go into the buffer. Buffer can not go negative. Use the "free storage" available (ONE number) to stop producers as needed, or throw away the surplus.

* End of the frame, use the delta of the buffer to adjust the storage. More in the buffer? Distribute as "fit". Less? Take from storage as fit.

And if you get REALLY smart you do that with 1 physics frame delay. "Transfer time": Which means in Frame x you allocate the resources for the next frame. In a separate thread. Not even unrealistic. Even electricity does not necessarily fail "immediately" with all the condensators electronics has.

There is absolutely NO need to go through this list.

And, btw., this list is not generated once per frame. It seems it is generated every time a resource is requested (!). Which - with most resources - happens quite often per frame

Yes, they are seemingly extremely inefficient - abusing the already horrific (Sorry) GC by generating tons of garbage. And this is why Phyiscs optimizations in Unity 5 will not ring big gains - it is not the physics that is the problem, it seems

while your last conclusion is somewhat questionable(it will bring it some boost anyways and while not as significant as lower-mid machines due to diminishing returns it still will be noticeable) i generally agree that the whole part,resources and underlying physics calculation system needs to change to squeeze even more performance from the game. TBH if they would have wanted to have a welding for parts or changing the way resources are handled they would have made it by 1.0 already but i guess it wasnt on their mind, maybe with advancements toward multiplayer they would start to think how to minimize the data transfer between KSP instances which i hope will just improve performance also in singleplayer

[cantab]

I'm sure Unity 5.2 is too late for KSP 1.1. But point updates of Unity have usually made it into KSP as a matter of course, so it will probably be seen in KSP 1.2.

And yeah, KSP wants a lot of optimisation, along with some other things. Ultimately I think that while Squad have an inspired and visionary game designer, they have for much of KSP's development been getting by with mediocre programmers and artists.

[TheTom]

I'm sure Unity 5.2 is too late for KSP 1.1. But point updates of Unity have usually made it into KSP as a matter of course, so it will probably be seen in KSP 1.2.

And yeah, KSP wants a lot of optimisation, along with some other things. Ultimately I think that while Squad have an inspired and visionary game designer, they have for much of KSP's development been getting by with mediocre programmers and artists.

I am actually not. It may not be a large update so updating it may just take an hour Not saying it is likely, but I would at least evaluate it at this stage, if I were in charge

[Padishar]

I'm sure Unity 5.2 is too late for KSP 1.1. But point updates of Unity have usually made it into KSP as a matter of course, so it will probably be seen in KSP 1.2.

I don't know why you would think that. Given 1.1 isn't even in QA yet (or only just, if it is), it will be at least a month before it gets released. If there really are no API changes then I wouldn't expect 5.2 to give them (m)any more problems than 5.1 has and I will be quite surprised if KSP 1.1 doesn't use it.

[Alshain]

I don't know why you would think that. Given 1.1 isn't even in QA yet (or only just, if it is), it will be at least a month before it gets released. If there really are no API changes then I wouldn't expect 5.2 to give them (m)any more problems than 5.1 has and I will be quite surprised if KSP 1.1 doesn't use it.

Because they aren't even going with 5.1. It's already been said they will be using Unity 5.0.

http://forum.kerbalspaceprogram.com/threads/126473-Devnote-Tuesday-Patching-for-Days!

[anarkhon]

Hey.

Obsidian already released a game written in Unity 4. (Pillars Of Eternity)

- 34 gigs of assets

- multi-thread

- etc.

Unity 5.x cant help KSP.

Maybe a computer science book for their software team?

[Alshain]

Hey.

Obsidian already released a game written in Unity 4. (Pillars Of Eternity)

- 34 gigs of assets

- multi-thread

- etc.

First, multithreading and multi core are two different, albeit related, things. If it is Unity 4, it isn't multi-core. Second of all, that game is nothing close to KSP, so comparing them is drastically fallacious.

Unity 5.x cant help KSP.

That remains to be seen.

Maybe a computer science book for their software team?

Or perhaps a computer science book for you...

Edited September 8, 2015 by Alshain

[Padishar]

Because they aren't even going with 5.1. It's already been said they will be using Unity 5.0.

http://forum.kerbalspaceprogram.com/threads/126473-Devnote-Tuesday-Patching-for-Days!

A dev notes post from two and a half months ago that says:

I have a bit of bad news about the Unity 5.1 release we discussed earlier. Unfortunately it seems Unity 5.1 brought many more problems than we expected, it got to the point where the project can’t even be compiled without the Unity editor crashing. We don’t have the time to troubleshoot this kind of problems now, so we’ll stick with 5.0 for the moment.

(emphasis mine)

...is a long way from a definite statement that 5.2 will not be used for the release, for all we know, 5.2 might fix the compilation problems they were having...

[Alshain]

A dev notes post from two and a half months ago that says:

(emphasis mine)

...is a long way from a definite statement that 5.2 will not be used for the release, for all we know, 5.2 might fix the compilation problems they were having...

Anything can happen, I just don't expect it in 1.1 unless they say otherwise.

[juanml82]

Yeah, first time I saw that I thought it was madness. KSP can, and very much needs to, be optimized in so many ways

And I don't think Squad will ever do it

[xtoro]

God I wish I had access to KSP's source code... Optimizing code is my bag baby! Maybe if they overhaul 1.1 for U5 they can release the old source code, but probably not due to licensing etc... But it would be huge to get a whole community working on it and contributing to the base code...

[MartGonzo]

I'm not a programmer but even I can see that the way KSP goes about it's calculations is needlessly cumbersome.

but frankly squad seem about as interested in optimisation as they are in art assets.

which is why we still have a skybox that looks like it's been scaled up from a 128X128 thumbnail and water that can only be described as hideous.

[StarStreak2109]

Quite frankly, I do not get why there is so much negativity towards the game and towards SQUAD regarding the ongoing development of KSP. Many of us bought the game for a bargain, taking the hours of enjoyment into account for the price we paid. And SQUAD is a smallish indie developer, not EA, and keep in mind that the quality of the likes of EA is also not always spit and polish.

So, might I suggest keeping to constructive criticism, civil comments and a more positive attitude. It is not like SQUAD owes you a certain product. When most of bought KSP, it said "in development".Yes, there are bugs. Yes, the product could use a significant visual overhaul. And yes, some of them do hurt our eyes and brains (qualitywise)! But, they are still working on it. And hopefully soonâ„¢ some of the more blatant issues are going to be removed.

In the meantime, we can enjoy what we have (I do at least!) or we can delete the game folder and move on to better (?) games and leave those alone doing the first thing (enjoying the game!).

But that's just a suggestion!

[cantab]

First, multithreading and multi core are two different, albeit related, things. If it is Unity 4, it isn't multi-core.

Unless the programmer either does pointless multithreading of a non-parallel algorithm, or does something really weird and stupid with forcing core affinity or similar, a multithreaded application will run on multiple cores at once. And KSP is already multithreaded and will use more than one core, but the single physics thread dominates the CPU load.

Quite frankly, I do not get why there is so much negativity towards the game and towards SQUAD regarding the ongoing development of KSP. Many of us bought the game for a bargain, taking the hours of enjoyment into account for the price we paid. And SQUAD is a smallish indie developer, not EA, and keep in mind that the quality of the likes of EA is also not always spit and polish.

Because we see potential that isn't happening, and that's just frustrating and disappointing. It's the same as watching a film and thinking it was OK but it could have been so much better.

And "Better than Electronic Arts" is the height of damning with faint praise.

[goldenpsp]

Quite frankly, I do not get why there is so much negativity towards the game and towards SQUAD regarding the ongoing development of KSP. Many of us bought the game for a bargain, taking the hours of enjoyment into account for the price we paid. And SQUAD is a smallish indie developer, not EA, and keep in mind that the quality of the likes of EA is also not always spit and polish.

So, might I suggest keeping to constructive criticism, civil comments and a more positive attitude. It is not like SQUAD owes you a certain product. When most of bought KSP, it said "in development".Yes, there are bugs. Yes, the product could use a significant visual overhaul. And yes, some of them do hurt our eyes and brains (qualitywise)! But, they are still working on it. And hopefully soonâ„¢ some of the more blatant issues are going to be removed.

In the meantime, we can enjoy what we have (I do at least!) or we can delete the game folder and move on to better (?) games and leave those alone doing the first thing (enjoying the game!).

But that's just a suggestion!

Because there are even more armchair quarterbacks on the interwebs.

[rkman]

Because we see potential that isn't happening, and that's just frustrating and disappointing.

Correction: hasn't happened yet.

What is a bit frustrating is that on the one hand the game is pretending to be finished (1.x and out of early access), while on the other hand it clearly is not finished and Squad acknowledges that. It's as though they made the bungeled releases of some recent AA titles into a formal development strategy.

I think some criticism there is fair, but to conclude that KSP never will be as nice as it can be (or close to that), is taking it to far.

Edited September 17, 2015 by rkman