KSP 64 Bit Windows

[uglyduckling81]

I have been getting crashes every other launch due to memory issues. I have a lot of mods installed, perhaps forty. I have run all the texture reducers etc to try and make it more stable but it's just not enough.

This made me try Linux and more specifically Mint since it's 64 bit works fine and enable me to play with all the mods. (I spent several days learning how to even use Linux as I have never used it before and all just to play KSP)

The problem I have is Linux doesn't support SLI very well and in fact with SLI enabled I get about 50% less FPS.

I created a 200 part ship to stress the system on launch. In Linux the frame rate is just terrible, I couldn't get an exact figure as the FPS counter was playing up and kept reporting no lower than 25 FPS when the reality was it was more like 5 FPS at a guess.

In Win8.1 just running a single GPU for comparison the frame rate is almost twice as good at about 9 FPS average. Once I enabled SLI my frame rate went up to 17-18 FPS making the game feel smooth and responsive which amazed me since I always thought you needed 30 FPS to be smooth but apparently not.

This brings me to my argument and point. 64bit Windows mode should be #1 priority for the Devs. It's current broken state is not good enough. Everything I see them listing as the next release I can do without. Aerodynamics model, I have FAR to do that. More space plane parts, I have numerous mods including B9 which already cover this ground. You name it and it's already done with mods. Better chutes, re-entry heating, kerbal alarm clock....etc etc etc. Its all there already.

Using more than 32bit memory isn't being done by mods and needs to be addressed by Squad. Let the community do their job of creating content, and Squad fix the game so I can use more than 4gb of Ram.

I ask this because it's almost certainly a lot easier to fix the 64 bit client for KSP than it is for someone to sort Linux out and make it more mainstream. Make 1.0 the 64 bit release please.

[sumghai]

Here's the official response regarding KSP 64-bit for Windows.

[uglyduckling81]

Here's the official response regarding KSP 64-bit for Windows.

I put this in the Unity 5 discussion but ill just put it here as well.

http://blogs.unity3d.com/2014/11/19/porting-to-unity-5-the-untold-rust-journey/

That is a first hand account of changing a game from Unity 4 to 5. It's not a difficult process, obviously it is work but considering the biggest issue with the game currently is memory usage I think it's warranted.

I also read the official response to not integrating mods into the game which basically contradicts this official statement in some ways. On one hand they are saying we aren't implementing mods because it becomes extra work they then need to do when it's being done by others for free right now. Then they are saying we aren't going to fix the (in my opinion) biggest problem with the game because we are too busy adding features which as I said in my previous comment is already available by using mods.

[sumghai]

It is preferable not to cross post the same request over different threads, but since you've posted here, I'll respond as well.

No two games are created equal. A smooth porting transition for the developers of Rust does not guarantee a similar experience for SQUAD and KSP.

With regards to the inclusion/exclusion of features from add-ons, at the end of the day, KSP is SQUAD (and Harvester's) baby, and they have an original vision that they are aiming for. Add-ons that don't fit this vision are generally not considered in the grand scheme of things, at least for 1.0.

Also, integrating add-ons isn't a simple matter of "here, take my code and put it into your game". SQUAD has their hands full maintaining their existing codebase, fixing bugs and implementing features that were originally planned as part of their internal roadmap to KSP 1.0, and adding foreign code that is potentially unoptimized or makes use of outdated workarounds/hacks for problems from the base game adds to their workload significantly.

Finally, not all players agree one what add-ons should be integrated into the stock game - for instance, I'm an avid user of MechJeb for flight automation because I'm personally more of a infrastructure manager than a hotshot ace pilot, but many people aren't. SQUAD's choices on which add-ons to make stock is mainly dependent on what fits their vision of the game and what doesn't.

[stupid_chris]

I have been getting crashes every other launch due to memory issues. I have a lot of mods installed, perhaps forty. I have run all the texture reducers etc to try and make it more stable but it's just not enough.

No, that's just the Windows 64bit client being himself. A complete unstable mess.

The problem I have is Linux doesn't support SLI very well and in fact with SLI enabled I get about 50% less FPS.

I created a 200 part ship to stress the system on launch. In Linux the frame rate is just terrible, I couldn't get an exact figure as the FPS counter was playing up and kept reporting no lower than 25 FPS when the reality was it was more like 5 FPS at a guess.

In Win8.1 just running a single GPU for comparison the frame rate is almost twice as good at about 9 FPS average. Once I enabled SLI my frame rate went up to 17-18 FPS making the game feel smooth and responsive which amazed me since I always thought you needed 30 FPS to be smooth but apparently not.

I've got really bad news for you. KSP is not GPU greedy. At all. Like not at all. KSP barely needs your GPU, a basic graphics card with 1GB of memory would do the job without any problem. KSP is limited by the CPU. While the game is multithreaded, the Unity API is not threadsafe. What this means is that you cannot split one task across multiple cores. And the culprit is physics. They're stuck being calculated by a single core, which is really suboptimal. And when you increase your part coutn, this is where the load increases. Not on the GPU. But on the ever growing physics thread.

This brings me to my argument and point. 64bit Windows mode should be #1 priority for the Devs. It's current broken state is not good enough. Everything I see them listing as the next release I can do without.

That's about as good as a priority as saying switching to Unity 5 is the priority.

Aerodynamics model, I have FAR to do that. More space plane parts, I have numerous mods including B9 which already cover this ground. You name it and it's already done with mods. Better chutes, re-entry heating, kerbal alarm clock....etc etc etc. Its all there already.

Wow, it's almost as if there were more modders than devs... hold on.

Using more than 32bit memory isn't being done by mods and needs to be addressed by Squad. Let the community do their job of creating content, and Squad fix the game so I can use more than 4gb of Ram.

Hold on. I'm not sure you understand that statement. The stock game runs very well on 32bit. Stock itself is not eating up the memory limit. Mods are. This is why 64bit should not be a priority. The priority is to finish the game and have it functional vanilla. Modding capacity is candy. It's very important candy yes, but it should not drive the priorities of the game, it should drive the *execution*.

I ask this because it's almost certainly a lot easier to fix the 64 bit client for KSP than it is for someone to sort Linux out and make it more mainstream. Make 1.0 the 64 bit release please.

Fixing the client, is, unfortunately, probably the hardest task you could ask from the devs. I don't think you understand how this works. The problem is not native to the game, it's native to Unity itself. Literally, there are things that the devs can't do even if they spent a month on them. Fixing the client is going to at least require switching to Unity 5, which actually brings forward 64bit stability on Windows.

That is a first hand account of changing a game from Unity 4 to 5. It's not a difficult process, obviously it is work but considering the biggest issue with the game currently is memory usage I think it's warranted.

No, porting to Unity 5 is not an easy process. Especially not on a game like KSP, which is extremely physics intensive and pushes Unity to it's limit. It's a long, hard, and complex process, which may not work at all without large parts of the codebase being rewritten from the ground up.

I also read the official response to not integrating mods into the game which basically contradicts this official statement in some ways. On one hand they are saying we aren't implementing mods because it becomes extra work they then need to do when it's being done by others for free right now.

I don't understand that statement. Modding has always been on a volunteering basis, and unpaid. Squad is working on a game which they are trying to make revenue from. They need to complete their game, and integrating a mod is sometimes more complex than writing it in the game. It requires adaptation and restructurations, and a lot of legalese.

Then they are saying we aren't going to fix the (in my opinion) biggest problem with the game because we are too busy adding features which as I said in my previous comment is already available by using mods.

They aren't going to fix the problem because most of it is not even in their hands. There's no use in fighting windmills.

Edited March 20, 2015 by stupid_chris
moar

[uglyduckling81]

@stupid_chris

I only use 32 bit windows version due to the buggy mess the 64 bit client is in like you state. 64 bit Linux works fine.

I'm not as good at these forums as you so I will keep mine in one block and try and answer your points.

1. I'm sure your right about the CPU and thread thing however when I was testing for resource use and FPS over the last day or so I did notice when I told my large rocket to break up by releasing boosters the CPU usage immediately fired across all 4 cores. 1 was used then on staging all cores went crazy so that was interesting. Oh and despite your claim of GPU having no impact I observed a noticeable and recordable difference between SLI and non SLI configs in windows. I can only go off my own interpretation from Linux as I was having some weird behaviour from the FPS counter.

2. I agree there are more modders than devs, that's why I'm saying Devs fix the engine by changing across to U5 and let the myriad of modders fill in the content in the mean time. I am saying U5 should be priority. I understand there can be complications with the physics etc but the Rust is a physics game as well so it is possible and according to his report not that hard. I personally have no experience in it you are right so I can only go off what I can read, listening to those who are experienced and more than likely a lot smarter than me.

3. Your point about U4 engine being extremely hard to fix I'm sure is also right however that's why I'm saying move onto U5 because that is the fix. The developers have upgraded it specifically to include 64 bit as native among other things of lesser note.

4. I mentions the transition to U5 and certainly it wouldn't be the easiest way out. The easy way is to say .... it, leave it as it is and move on. Perhaps Squad will leave it, perhaps they will fix this issue. Only they know for certain. KSP is about the physics but U5 bring a more capable physics engine which I'm sure will be a lot of work to transition but the rewards I would think are worth it.

5. Your comment about modding. I'm saying exactly what you are saying. Let the modders do the modding, add content etc. Let the developers fix the major issues that modders can't fix. We don't need more official content right now. We have a large and thriving modding community making amazing content and it costs the developers nothing to maintain or implement. This is the time for the developers to fix the engine problems before all the content that they plan to include is in place. If they add more content now and then decide to fix the memory issues by changing the engine its probably going to create more work fixing even more official content. At no point am I saying incorporate mods in officially at this time.

6. They should be fixing the memory issue because the engine developers have already fixed the issue by creating and releasing a new and relatively easily transferable engine.

I'm not saying they should transition the engine in 2 hours like Rust did. Use the whole patch development cycle. How long has it been since 0.90 came out? Long enough to have U5 up and running that's how long. It is their game and they need to make money but if they are planning on making a transition at all it should be priority because everything else is covered by mods.

[michaelsteele3]

That is a first hand account of changing a game from Unity 4 to 5. It's not a difficult process, obviously it is work but considering the biggest issue with the game currently is memory usage I think it's warranted.

Then why don't you do it?

Anyways, the devs are still trying to clean up things for 1.0. Upgrading a game engine WHILE doing all these fixes would not be great at all.

- - - Updated - - -

Also, you can go without having 40 mods installed. Just be creative

[uglyduckling81]

Then why don't you do it?

Anyways, the devs are still trying to clean up things for 1.0. Upgrading a game engine WHILE doing all these fixes would not be great at all.

- - - Updated - - -

Also, you can go without having 40 mods installed. Just be creative

I have no talent or clue of how to develop games. I am merely echoing the comments from the Rust developers.

Mods add so much though. Once you play with all this great content you just can't go back. I will probably remove one of the parts packs and just keep B9. Or perhaps just keep playing on Linux, since I devoted several days of my spare time to learning how to use it. Just avoid huge ships.

Edited March 20, 2015 by uglyduckling81

[stupid_chris]

1. I'm sure your right about the CPU and thread thing however when I was testing for resource use and FPS over the last day or so I did notice when I told my large rocket to break up by releasing boosters the CPU usage immediately fired across all 4 cores. 1 was used then on staging all cores went crazy so that was interesting.

I told you, KSP is multithreaded. It *does* use all the cores. What I said is that it can't split on task across multiple cores, and that is the problem. And when I say can't, it literally can't. If you do as much as spawn a Texture in a thread with Unity, and then try to reference it in another thread, the game crashes. Unity 4 has zero threadsafe capability.

I'm not saying they should transition the engine in 2 hours like Rust did. Use the whole patch development cycle. How long has it been since 0.90 came out? Long enough to have U5 up and running that's how long. It is their game and they need to make money but if they are planning on making a transition at all it should be priority because everything else is covered by mods.

Unity 5 came out about a week and a half ago. They couldn't even if they wanted to. And no, since the time when 0.90 came out, even if Unity 5 had been out atthat exact moment, they'd could be done just as they could not even have reached a stable halfway mark. Of course they're gonna try, maybe things will go better than expected. Coding is just a massive whatever fest. Sometimes things work and you have no clue why. But the opposite is true. Chances are transfering to Unity 5 could take half a year, and yield unstable results. And then even, as Harv mentioned, Unity 5 is not a promise of fixes. Transferring to Unity 5 is not necessarily going to fix the 64bit client. All in all, if you want to transfer to U5, completely fix the win64 client, and completely multithread KSP with the physics being correctly split across cores, I'd expect it to take something around 6-12 months with the current team. And for an indie developper, it's not something you can afford.

[sal_vager]

Squad will look at Unity5 after 1.0, right now they cannot support a 64bit release using Unity4x and cannot fix issues that are caused by the Unity4x 64 bit builds.

There really is nothing more that can be said, continually asking for it won't make it happen any faster either.

Thread closed.