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.

If you want a simulation that at least approaches a behaviour like you would expect it in real life - let alone a semi-realistic one - then yes, KSP would have to count those as individual parts. As far as a simulation is concerned those 300 solar panels: - change the drag of the vessel and therefore change the aerodynamic behaviour - change the drag of the vessel and therefore change the shock heating, aerodynamic heating and heat transfer/conduction behaviour of the vessel - change the mass of the vessel and therefore change fuel consumption, TWR and astrodynamic behaviour of the vessel. - change center of mass and center of lift - probably don't change mass and drag evenly and therefore add additional force vectors to the vessel - forces applied during flight could exceed the physical limits of the joints/connections between the panels and the tank or of the panels temselves. Panels could break of or get destroyed. So yes, if you want a somewhat authentic behaviour those would have to be treated as individual parts and the physics model would need to be applied to all of them. Unless they are OX-STAT panels because then they are physics-less

Havok is a different physics middleware. The problem I have with PhysX is that it's not really a product but an NVidia marketing incentive. They bought Ageia so that they'd have something that they could use to promote their CUDA feature to gamers and game developers. They also bought Ageia to have something thyt would let them compete with Intel who had bought the company responsible for Havok two years earlier. PhysX is there so that NVidia can promote CUDA to gamers. Similar to other NVidia technologies and GameWare features it will not work as well when used without an NVidia product or on competitor's technology. Similar to other technologies developed by NVidia it is likely to be intentionally crippled in one way or another if you use it on competitor's products. At least the current version is finally somewhat well maintained and feature complete. It still works best in conjunction with NVidia cards though. - - - Updated - - - x86 Processors support SIMD instructions since the Intel Pentium 5/AMD K6-2 in 1997/1998 when Intel introduced MMX and AMD introduced 3Dnow.

I'd still rather use Havok if possible. - - - Updated - - - Splitting rockets like suggested would also reinforce the notion of KSP vessels being set-up like a tree with a single node at the top and allow for even less ways to have multiple connections between parts (think struts or decouplers for example). I'd rather they find a solution that made the setup of vessels more flexible (e.g. multiple radial decouplers per booster so that you don't need to stabilize them via struts)

It would help if the stock game stopped treating vessels as a collection of individual parts and didn't apply physics calculations to any part individually. While this is useful or even necessary for some components it's not for others. I think the biggest performance gain in stock could come from using a "FAR-like" approach to physics modelling and to replace stock components with procedural parts where apropriate. In that case you wouldn't have to apply your model to a lot of individual wing parts because you can either treat them as/replace it with a single component that you then apply the modelling to. If we had procedural tanks for example one wouldn't have to build big tanks by stacking smaller ones on top of each other and if we had procedural wings one wouldn't have to build big wings by putting smaller ones together. In that example the physics model would then only have to be applied to one part rather than a collection of smaller ones that pretend to be one bigger part.

Given that 90% of all day to day flight maneuvering on commercial airliners is done by the auto pilot system that makes all commercial airline pilots cheaters in the eyes of some of you I guess.

Refactoring code only works if you have a robust unit test/regression test framework in place that covers most of the critical parts of your code base. Parameter validation, safety checks and other debug artifacts shouldn't be active in a production compile anyway. Don't confuse debug assertions and run-time checks used for test automation with exception handling. The former should be removed in release versions of your SW the latter can't. Performance evaluation of non-UI code is trivial and should be covered by any sort of decent profilling package and most memory leaks can be detected by Valgrind or a similar solution. Add a tool for static code checking (like PC lint or QAC) into the mix and you have an extensive and complete set of tools to evaluate the performance of new or refactored code, to do automated testing and regression tests and to find most of the stupid but common bugs everyone of us does. If you can randomize tests you're even better off. The rest is the responsibility of the testing team. The fact of the matter is that if Squad had a comprehensive and robust set of test and performance evaluation tools in place then a basic and easy to find bug like the heat shield bug in 1.0.3 should have never ended up in the released version. The same with the overheat indicator UI and memory leaks Valgrind or a similar tool would most certainly have found that issue. These are bugs that at least one of the testing stages should have caught. If no one else than at least the system test guys. In that context I'm not convinced that the current performance baseline of KSP is simply a matter of the complexity of the calculations involved and not also an issue of an implementation that could use additional optimization work. - - - Updated - - - Take the new heat physics for example. The new calculations should have been tested with different ships and component configurations. They should have been tested with massless parts. They should have ben tested with clipped parts. They should have tested what happens when you migrate an existing save from 1.0.2 to 1.0.3. There should have been a performance evaluation of the new equations and models especially on complex vessels with many parts The fact that most runaway overheating failures of ships happen with massless parts, clipped parts or on migrated saves shows that they didn't test that or they were not thorough enough. Even though those are basic use cases. This makes me think that there is still a lot of potential for optimization in the existing code basebefore we hit some sort of performance ceiling.

I'm rather shocked over the non-chalance with which people would like to mandate how other people have fun and enjoy themselves in their own free time. Food for thought: Just because you like to enjoy a game in a certain way doesn't mean that you have to force everyone else to enjoy it in exactly the same way as you. It is entirely possible, allowed and expected for you to enjoy your hobby regardless of how others enjoy theirs

FAR and DRE combined don't affect performance as much as the stock physics model so I'm not convinced that it's simply an issue of complexity.

I'd rather have someone who didn't have the need to use a skewered analogy to prove a stupid point.

What gave you the impression that you have any authority to dictate how other people play their game? Don't you think that it is a tad arrogant of you to think that you can decide for all the players out there what is the right way to play a game? Don't you think that your comparison of a game mechanic to a real life licence to operate a motor vehicle is quite a bit out of line? Some people...