Nigeth

Yeah, right mate.

Fortran, Lisp, C, Java? Pah! When I started out we didn't have such fancy schmancy high level languages. We had to make do just with ones and zeroes. Sometimes we didn't even have ones. Seriously though Unity is a great choice and C# is actually a really good language. You'd almost certainly run into similar issues using Unreal 4 and C++/Lua or in fact any other game engine/language combination. - - - Updated - - - Friends don't let firends program in java though

He is concerned that the paging mechanism of modern operating systems will ruin his SSD due to excessive write accesses. (Hint: it won't) He therefore turned a gradual decline in system performance (the OS swapping out unused memory to disc when RAM gets limited) into a full on system crash (the OS kernel crashing as soon as peak memory usage exceeds actual physical RAM) Which is rather stupid in my opinion but to each his own I guess

So many misconceptions. Java is not an "engine". It is a programming language. The most common install of Java the programming language includes a software development kit (SDK) that includes a lot of functionality to make the lives of programmers easier like GUI library functions and so on. It is no "engine" though and it lacks a lot of functionality a game engine like Unreal, Unity or Frostbite provide. The choice of Java for Minecraft is also probably the biggest drawback and issue for minecraft. Secondly writing a game engine from scratch is hard and a huge waste of time and development budget. Being under the delusion that you'd have to write your own engine has killed many studios already.Studios that were usually way bigger and had way more money. It usually leads to a buggy mess that lacks even the most basic functionality a commercial off the shelf engine like Unity or Unreal offers. The amount of time and effort is almost always better spent getting it to run in one of those engines and extending them if necessary. Thirdly the choice of programming language matters less than you think. If KSP had chosen language X over Y or engine A over B chances are that you'd notice no real difference. It might even crash the same amount. What matters is that you chose a programming environment that offers you everything you need to develop a game. Decent tool support (debugging, editing and compiling code, helper tools to debug memory usage, static code analysis etc.), helpful documentation and add-on libraries and the ability to extend and modify existing code and systems (important for modding) Most of the current issues KSP faces have nothing to do with Unity or the C# programming language. The stem from design choices the dev team made in the beginning that turned out to be not entirely suitable to the way KSP has evolved (a fact Squad can't be blamed for because no one else would have known that right from the start). Also from the fact that Squad favors new features over cleaning up code and fixing long-standing issues. Which is understandable but means that bugs pile up over time and reinforce themselves. - - - Updated - - - When the switch to Unity 5 and 64 bit is complete the biggest explanation for KSP's issues (game crashes due to the game process hitting the 3.5 GB memory barrier) will be gone. We'll see how many issues remain then that can o longer be blamed on 32-bit Unity.

Then I'm looking forward to FAR Navier, and FAR Stokes because many fluid dynamicists died to bring us this SW

Ferram, what will you do with your naming scheme once you've reached Weber, Weissenberg or Womersley and have run out of dimensionless physical constants? (AFAIK there's no dimensionless quantity beginning with a "Z" - - - Updated - - - Null Reference Exception I'd guess. Accidentally using a reference to an oject that doesn't point to an actual object (a so called NULL pointer or NULL reference)

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

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

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.

Well if you're content with that performance more power to you. 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. I do realize that this is mighty arrogant of me to say. If it weren't for Squad I wouldn't be able to play this game at all and I don't know enough about their business to say if this is not based on necessity rather than carelessness. I just hope that - instead of introducing yet another new system - they'd sooner rather than later did a pass over the code to try and fix most of those issues.

I'd consider 12 fps to be unplayably slow

Quite literally.

Use fixed point arithmetic instead of hard coding. If accuracy is good enough then it would also kill a lot of the issues you get with floats or doubles (renormalization issues, floating point errors, the issue of NaN etzc.)

It still means that the algorithm is at least O(n) even though it probably doesn't have to be. Even worse if iterating through the main list triggers iterations through other lists as well or if a significant state change would require you to iterate through the main list for a second or consecutive time. It almost certainly doesn't need to be updated on every frame. Yeah but you'd be mostly iterating over parts whose state didn't change at all. Without knowing the dirty details I can see several ways in which you might be able to optimize it. Reorder/resort the list so that you don't have to iterate through the complete list (tradeoff between the speed of the 'naive' algorithm and the sorting overhead). Different data structures that could make that process more efficient (hash tables, maps etc.). If you really need to iterate through every entry you could see if you could flag entries as 'dirty'/in need of update. Then at least the check needed to see if you need to update a part's state is fast. Maybe group similar/identical parts and update them all at once. Linear searches/Linear iterators are usually not the best/most efficient algorithms if you know your problem domain well enough. - - - Updated - - - Tom: In this case the signal processing definition of aliasing is used and you usually don't want that sort of aliasing because it doesnt mean that your calculations are only slightly inaccurate.

My computer engineering sense is tingling and tells me that this might be a tad inefficient. BTW I didn't intend my list to be comprehensive or complete I just wanted to give a few examples. - - - Updated - - - I agree. You probably don't need to recalculate resource consumption and EC flow on every frame though.