Daid

Instead of time limiting it you could "This funding cut stays in tact till you have proven that you can put a rocket into orbit with the limited funds available"

As a software developer. Your effect of this topic is zero. User reports "game crashes, help!1!" -> usefulness is nothing. Nothing the devs can do. User reports "game crashed when I did X" -> usefulness is low. Most likely the devs will not look into it, unless a lot of people report a crash at exactly the same action. User reports "game crashed, I was doing X, I already did Y, I have no mods, and here are the log files" -> usefulness is high. Crashes are hard to track down after the fact. You need as much information as possible. Even then, it could be out of control of the devs. I've seen crashes happen in buggy 3D drivers. I've seen crashes happen in buggy audio drivers! And my personal favorite, crashes due to bad RAM or other broken hardware. Yes, your game crashes every hour (but, oh, I forgot to mention, I also get blue screens from windows every few hours)

Sales does not equal players. I think the achievements of Cave Story+ always reflect this nicely. As the initial set of achievements is gained with progress: http://steamcommunity.com/stats/CaveStory/achievements/ I'll see that many players quit early. A few hours into the game you have about 30% of the players left. Long time players, usually less then 10%.

I was confused as well. I usually only track the devnotes, and no devnotes. Would have been nice if there was a simple "No devnotes today, be cause of... [link to release post]" post instead. I almost missed the fact that the release happened.

That can happen or not happen in-depended on how you manage resource constrains. And I've seen resourced constrain code grow to a steaming mess easier then something unconstrained. (I do not know if the KSP code is a mess. But I do guess that some part is, reading the 1.1 things on modding and that they are reporting large bits of dead code/API)

As a current generation software engineer to an old generation software engineer: Laziness is good. It means you can focus on functionality instead of limitations of your system. You could program KSP so it uses half the resources. But it would take a quadruple amount of hours. Meaning you have 1/4 of the features. You want to use the stock libraries, they are better tested then any code you will ever make. They also have better APIs and logging/debugging then that you will make. RAM is cheap and plentiful these days. It's rare these days to encounter anything with less then 4GB ram (unless it's only used for browsing and text editing)

Inefficient, yes. Much easier to work with as an developer, yes. How much fun would it be if the game froze for a bit to load all the space center textures on your approach to the space center with your bad gliding space plane?

Delta-V and time-till impact calculations from KER. Everything else I can live without do work around. But these prevent a lot of problems for me. The delta-V calculator in the VAB also prevents a lot of staging issues for me. Time-till impact prevents high-velocity lithobraking.

Heatshields are overrated. I tend to use engines as heatshields, you already have them with you anyhow. And they might explode on the way down, but Jeb never had a problem with that. I agree on the statement that the engineering report isn't that useful in its current form. But I also understand the complexity of making it actually work properly.

That reminds me, even worse then forgetting to opening your panels. Forgetting to open your panels, having emergency small panels in there for this case of "being an idiot". And then find out they are on the dark side of your ship and never provide power because of that. (Well, you could bump into your ship with something else to start it up then... hows that for a jump start?)

I discovered yesterday that you can toggle the antenna into a different mode and send science in the "old" way where it can do partial sends with low power. I most commonly forget solar panels. Or when I have them I forget to unfold them...

As a software developer, I can say, patching is hard. Especially when accounting for people modding the game. You would complain just as much if the update system would delete all your mods as it sees them as "old files"

Yes, but if you read the post that goes with it, the context is suddenly changed, and is about sadness of not being able to provide Squad with valuable test data.

Your poll is skewed towards the results you favor. I'm not able to download the 1.1 pre-release. But I also do not care to download it. But my vote still counts towards your favor. As I could still transfer my account to steam (it's old enough) I potentially could download the pre-release if I really wanted. People that are on steam, but haven't noticed the more public info available about the 1.1 pre-release will most likely also answer "no" in your poll.

Didn't test it, that's why I added "I think". If tests shows this amount of acceleration, then this could be the reason for the acceleration. Kerbal engineer should also show a slight decrease in altitude then if you roll down the runway.

Kerbin has a radius of 600km. The runway is 2526m. By the diagram, half it is "pointing outwards of Kerbin", so 1263m. The sidewards acceleration should be only the division of this length by the radius of the planet. So 1263/600000=0.002105 is the fraction of the gravity that is applied forwards. So 0.002105*9.81=0.0193239m/s^2. I think the fathom acceleration we see is more then that. As with this acceleration it should take about a minute to get up to 1m/s.

It does not do anything you cannot quickly do by hand, as it simply sets processor affinity for processes. Most likely it won't help a damn thing, unless you are running an over-stressed browser in the background with lots of tabs open. (Which you can manually assign to a single core in the task manager of windows) And as KSP is a single core application, it will do even less for you. Don't forget the placebo effect on the good reviews.

According to my data 6 months ago, 15-20% of the Windows users (of my software) are still running 32bit versions of their OS. I did not check if their CPUs are capable of running an 64bit OS.

The trick of going to space is not to go up very fast, it's to go sideways so fast that you do not fall down fast enough to hit the planet. Same goes for a good suborbital, as you will have more time to break on the lighter atmosphere.

First bit. Yes. There is a lot of misinformation about memory and the 2/3/4GB limit. But I'm not sure how a program can use more then the 4GB limit. If you cannot address the memory, how can you use it? Sure, the kernel can do all kinds of things, with PAE the 32bit address space for even a 32bit OS is not a real issue. But your application has no use for memory it cannot access. So I would love to know how you can access more then that? (The 2GB limit is just an very old limit in Windows. It's 1 compile flag to enable it up to 3 or 4GB depending on other factors, so usually nobody talks about this limit anymore)

I also recommend running: http://www.memtest.org/ I've seen a few times when people where complaining hard time that software was buggy as [SUNNY DAYS]. And in the end it was that their hardware (RAM) was broken, and thus was causing all the errors. And, as a word on the "3GB" limit. KSP will crash before it will show 3GB usage in Windows. Windows memory usage display is always a bit odd. And the 3GB is a "virtual address space" limitation. But tough to explain, but it is running out of locations where memory "could be". Does not mean there is memory everywhere, just that it's reserved to be there. Add into the mix that files can also be "mapped", which causes them to take up space in the "virtual address space" the whole thing starts to become more complex. (And I think, not sure, that 3D drivers are also great at using up address space without telling you). But note that I never have issues on my machine. I'm running all graphic settings at the lower possible values, so that might be helping me. (PC is fine, just the Intel graphics card that is slow)

[quote name='TheTom']And again that ridiculous claim pops up. The biggest bottleneck in the game.... is not physics (as: physX) to start with. Ups. Here you logic goes. Despite claimed 17 years. And this is btw. also extremely simple to paralellize into a number of threads. How? Paralellize: PhysX (body motion), Aerodynamics calculation, Resources (one thread per resource), Heat. Introduce SMALL delays - for example calculate aerodynamics on frame behind. Noone will see the difference, suddenly you can use a lot more threads in parallel. Heck, I would even say you do not need to handle most resources every frame, to start with.[/QUOTE] Physics modify body positions and uses forces and weight. Aero uses positions and add forces. Resources modify weight (and, in case of engines, add forces). It's all connected, making it far from trivial to run thread-safe in parallel. [QUOTE]Yes, the code in KSP is partially quite sub standard. Which puts it on par with a lot of cod I have seen. 2x-3x gains are not "exceedingly rare", I have seen quite a lot of them. A ton of code out there in companies is written quite badly thanks to "senior" developers with 5 years programming experience making design decisions.[/quote]2x-3x can be done, but usually means you changed architecture a bit, or added better algorithms. My personal record is a 60x increase (average, best case 10000x), but that replaced everything (including the language the stuff was written in).

[quote name='TheTom']What makes KSP slow are: *SIP*[/QUOTE] Did you profile the code? No? Then don't say what makes it slow. Profiling before optimizing is the only way to do optimizations. Assumptions in this area are usually the biggest ....up. [quote name='*Aqua*']GPUs and CPUs are optimized for fast 32 bit floating point operations because that's the current state of the art. Games like KSP which may profit from 64 bit floats are a seldom. Your average shooter or driving game doesn't need 64 bit floats. And those use cases are what the game engines are optimized for. As you said you can calculate either 8 floats per cycle or 4 doubles. Changing everything to double will [I]half[/I] the speed of floating point calculation.[/QUOTE] AUCH. Your post just hurts from bad info. Floating point calculations in modern CPUs are done in 80bits, always. 32bit operation? Don't care, first turned into 80 bits internally in the CPU before the math is done. As long as all your data fits in the cache, it's the same speed. Else you're just having memory bandwidth issues. GPUs are the most complex things you can think off. While the can do 32bit or 64bit operations just fine, it's the memory access that is speed wise the problem here. As well as branching. It's a bit hard to explain in a short post. But GPUs work by doing the same math on a lot of numbers at the same time, exactly the same math. Got a "branch" (choice) in your code? GPU needs to do it twice, once for both results. You also need a certain set of problems that are usable on the GPU. Physics can be one of these problems, but once again, do not expect miracles. But once again, GPUs are mostly memory bandwidth constrained in these sort of problems. [quote]The only reason why software slowly changes from 32 bit integers to 64 bit integers in the last decade is because there's a need for more addressable memory.[/quote] We didn't switch to 64bit integers (we had those in a Pentium 3 already just fine), we switched to 64bit MMUs with 64bit address space. That's what the 64bit OS and capable CPU is about, and 64bit KSP as well.

[quote name='Stargate525']I think the big one here is that rovers will now finally work properly, as Unity 5 is coming with vehicle support physics as well, I think.[/QUOTE] If you read the devnotes, then you'll have noticed that this "feature" was underwhelming and only worked if your object is a square box with 4 wheels. Not a random shape of shapes with random wheels attached. So there was a lot of work in getting wheels working again. General rule of optimization, do not expect magic. 5% to 30% is a rule of thumb (I'm an software engineer, 10 years of experience) 64bit would be a welcome addition for the windows users, if it's really stable. And might yield some performance improvements as well (software I develop runs about 15% faster in 64bit mode, but I expect way less improvement for KSP)

Been a while since I updated this thread. Game is still being improved. Lots of small tweaks and fixes has been made, as well as this list: Mostly, bugfixes, and small enhancements. * Two new scripted scenarios that actually give you more advanced game objectives then "destroy everything!" * New "science scanning" minigame. Practice makes you better at this, and makes science more engaging to play. * Bunch of new alien ships with a new race. * New AI that fires a volley of missiles at your side instead of taking you head on. * The new ship-scanning "minigame" can be disabled server wide, which is better for conventions where new players are already overwhelmed with the game without this. * Self destruct now has a countdown. (Abandon ship! Have your crew run out of the room like maniacs during this time, tripping over cables and destroying computers in the process) * 5 new transport ship models, with 1 to 5 cargo containers each. * Fixed a few problems when using the 3/4 crew member screen options, where some controls where not accessible. * Added extra console types, "damcon" which is just the top part of engineering, "power management" which is just the bottom of engineering. "database", which is just the science database. Changes for modding/changing the game: * F5 in the GM screen copies the current selected objects to the clipboard for pasting in script files. For easier setup of new scenario scripts. * Music list is no longer hard-coded, and any file in the music directory will be used at random. * Objects can have descriptions that are shown in the science station. * (not yet in the latest release, but code finished). Allow scenarios to define GM functions, that show up as buttons on the GM screen. Also, some people have been testing to play trough the internet, which worked very well according to their report. Does require you to forward port 32666 in your router. And manual IP connecting, as there is no internet server discovery yet. But some preparation in the code has been made for it, as well as allowing for password-protected servers. But no official support for internet play yet.