Bilfr3d

ra... ra... rai.... RAILGUNS!!!!! ERMAGERSH!!!! I will totally test anything and everything if it means we get railguns sooner xD speaking of which, going to test the phys rang issue RIGHT NOW!!! Great job @BahamutoD

KSP + joint venture between the engine that powers the aerofly FS sim and also cryengine.

Whats an i3? My main computer I play KSP on has a dual core Pentium clocked at 2.2Ghz. And the GPU is a GTX 240. So yea. Although that recently changed to something more powerful, it was my main gaming PC for about 4-5 years.

Ah, that is a good point. DirectX is Microsoft. Microsoft is not apple. So, apple uses a open source renderer (being OpenGL) by default. That's fine, I only just clicked too xD

I would give you reputation, but it says "You need to spread some reputation around before giving it to Norpo again." Certainly a very odd bug. Maybe try all the poles? Kerbins poles, Minmus' poles, Duna poles, etc and see if it works there. Otherwise people - Exploit it while you can!! Cheers, ToTheMun

As far as I am aware, shadows not rendering is an internal issue with how openGL, well.... renders. At this point in time, I do not believe there is a fix for that. You could attempt "-force-Direct3D". I'm not sure of what the rendering is exactly called on Mac, so if it has a fit... Hope this helps guys, ToTheMun

Have you tried turning it on and off again? xD I would recommend seeing if you get the same issues with a different craft with the SAME jets. If that craft has the same issues, than I would go about uninstalling mods and testing after an uninstall of each mod. If having no mods still does not fix it, I would recommend reinstalling KSP entirely. Hope this helps, ToTheMun

You really want a lot of lift, as well as a lot of control surfaces. Preferably, you'll want your lift-weight ratio to be 1 or more than 1. I aim for about 2.5-3.5. that should make the craft fairly manoeuvrable.

I can confirm that Alt + F9 reloads the last autosave. I started a blank sandbox with no mods, just started launching some ships. after I launched a few, I did Alt + F9. I had not done Alt + F5 at all, but I got reverted to my last craft in orbit around kerbin (when it was originally in orbit around Minmus)

I know that when I crash some huge amount of parts into the ground at the same time it lags, but it doesn't fully stop... I'm on windows, so that may have something to do with it. The explosion itself shouldn't have much affect, unless lots of parts are exploding As @Master Tao said, more info could help. Cheers, ToTheMun

When all of KSC explodes when you launch the ship on the Launchpad -.-

Why not just go into the saves folder, select, Ctrl + C, go to another folder, Ctrl + V. Start playing. Do that before you start your game. Maybe datestamp each save. I could make a batch file to automatically do this to all saves. It's not that hard. - - - Updated - - - This should also probably be moved to suggestions and discussions.

You should totally get this 8.4Ghz AMD Bulldozer CPU. Just make sure you have enough liquid helium to cool it

So you have completely deleted your entire "KSP" directory, then re-downloaded it from your place of purchase (KSP Store or Steam)?

Download more RAM Don't do that, actually. If OpenGL is not working for you (or you just don't like the way stuff looks with it), your best bet would be to use KSP 64 bit. But because of the highly instable 64x build on windows, I would not recommend using it on windows, but instead installing Linux as a dual boot with your windows system. The Linux 64x build is a lot more stable and with the 64x build, you can use more RAM hence load more mods. You could try using the windows 64x build, but be prepared for frequent crashes, bugs and errors. Until the windows 64x build is fixed (which is not a SQUAD problem btw, it is unity), the only USEABLE 64x build is on the Linux system. So yea, if you don't want Linux, your stuck between a rock and a hard place.

I think we need to uhh..... TEST the craft... yes that's right maybe you could upload it so we can TEST it? nothing else but TESTING of course

A new category named "Jeb" is created and the game crashes every time you click the on part in that category - Jeb. He has 1000000000000000 thrust and uses no fuels - cruel developers making everyone crash their game.

7/10 You gotta love that learning wall

How do you even rocket, spartwo?

Notes? tracking? Who needs that? I have never tracked any of my missions. Ever.

120. All time every day. Unless I make a craft over 500 parts :\ In which case it drops down to around 35. @worir4 you use a program to measure the FPS. For example, Fraps gives a readout of the FPS in (nearly) any program you have open.

^^^^ The same KSP version was used and the same craft was used on both tests/benchmarks.

Did you actually read my post? I said that with the specs I posted it will work decently. Once you start getting higher performance hardware "you won't notice much difference." I said that because the only thing that really affects the performance is the CPU. If you start getting a higher powered GPU, the GPU will make barely any difference once you get past a certain point because the CPU still has to dish out the models, meshes, textures, etc to the GPU AT THE SAME TIME as calculating physics. Read the post properly next time. It's called me. Google search "me". No, don't actually do that. I have done several benchmarks in the past on a variety of games benchmarking their performance with rendering as DX and OpenGL. I have done these benchmarks on KSP and whilst using OpenGL, CPU usage is increased and simulation time was about 1/3 more. As I said in my post, it all depends on your system. What hardware you have, what DX version you are running, what OpenGL version you are running, and what OS you have. There is a combination of the 4 that allows OpenGL rendering with no extra impact on simulation times, or physical lag, however I am yet to find this combination. Linux looks promising for it though, so far having only a 19% increase on simulation time while running OpenGL compared to the Windows benchmark which was a 37% increase in simulation time. Both DX versions were the same release, both OpenGL versions were the same release and both OSes were tested on the same hardware.

That's the thing. it doesn't SEEM to run slower. Physically, it does not affect any sort of lag. BUT, and this is a big but (hehe ), it affects the SIMULATION speed which you may not necessarily notice. You will only notice it in some circumstances. It also depends on what OS you are running to how much it actually affects the simulation time because each OS runs their graphical rendering a different way even though they use the same engine (with an exception to OS X, which I am not entirely sure if it has any option to use DX 9/10/11 etc). SO, although you may not notice it, 7/10 it is there but you just don't realise it. Now you are probably thinking, "well if I don't realise it, why did you bring it up?". That's a good question. I brought it up because - because KSP now spends longer on each physics calculation a potential bottleneck may/will occur when more parts and ships are in the physics calculation range at once. Your 1000 part ship that your computer can reasonably handle using DX 11 (or whatever DX you use), your computer may not be able to handle OR there will be a physical decrease in speed whilst using OpenGL. Again, depends on the DX version you are benchmarking against if you are going to do this. Also depends on the OpenGL version you use to benchmark this AND the OS you are running. On some occasions also depends on your hardware. I hope this clears some stuff up, ToTheMun

Defraggler won't make a huge difference. What you are saying happened here is probably the most extreme case. It would've been you hadn't done a defrag for a VERY long time and your cores where always in use trying to index all your files and all the chunks of those files were all around your hard drive. I still don't see why it should have made such a huge difference in idle CPU usage. Its likely that a program that's always running was not in the same place on the hard drive, so the CPU was continually running reading the hard drive and then lining up all those files in virtual memory or RAM. Dunno.