Jump to content

KSP 64bits on Windows (this time, it's not a request)

Lilleman

By Lilleman
in KSP1 Discussion

 Share

How does the 64-bits version of KSP work for you?  

5 members have voted

  1. 1. How does the 64-bits version of KSP work for you?

    • It worked with no or minor glitches/bugs with DirectX
      157
    • It worked with no or minor glitches/bugs with OpenGL
      24
    • None, it crashed/caused major game breaking/is unplayable.
      62

Recommended Posts

JordanL

JordanL

Posted
Posted
I made some change to the first post again, adding the mouse behavior glitches.

I need some confirmations for the second one though: Ingame, a right-click on a part may not be responsive at all, and I'm not very sure about the workaround (go to the menu then resume).

That happens to me in 32-bit as well, so I'm not sure that's a 64-bit thing.

Link to comment
Share on other sites
SuccessPastaTime

SuccessPastaTime

Posted
Posted

I'm so grateful for this fix, it's really gaining me even more enjoyment out of a game I already love, but I am having one issue, that I believe popped up a few days after I installed the fix, as I don't remember seeing it before.

It happens when I spend around 10 minutes or more in the VAB and then head out to launch, the game crashes. In the error file, it tells me it's an Unknown caused a Privileged Instruction (0xc0000096).

I'm not sure if something else is causing this, so I was gonna do a clean install, but before that, I was wondering if anyone might know of a solution?

My specs are:

I7 2600K running at stock with Turbo Boost enabled

GTX 780

16gb of RAM

Running game on a Corsair ForceGT SSD

Anyone have this problem too?

Heres a link to my most recent crash log files:

https://www./?d3u92c12t3uu2bn

Link to comment
Share on other sites
Cetera

Cetera

Posted
Posted (edited)

So I've done quite a bit of testing. So far the only real bugs I've encountered with the 64-bit edition are decoupler issues. I've not been able to recreate the craft wobble from the map view in the 64-bit version. The screen loading issues with the flicker and the astronaut selection are also 64-bit only, and don't appear in the 32-bit version. All other bugs I've been able to recreate in the stock 32-bit version by forcing DirectX 11.

In the stock 32-bit edition, forcing DirectX 11, RAM usage is lower, the texture issues on the launchpad and the hanger exist, text corruption exists, and the re-entry effects turn everything pink with no textures. However, in the 32-bit version with directx11, lowering the re-entry and atmospheric effects does not seem to resolve the issue like it does with the 64-bit version.

So it appears there are a couple of different things we need to isolate: 64-bit version bugs only, and DirectX 11 bugs only. I'm hoping that it should be easier to isolate DirectX11 bugs for Squad to fix (it won't require new versions of Unity, hopefully). If Squad can release a DirectX 11 version to help save on RAM, hopefully that will tide us over until a 64-bit version can be worked out with Unity.

Edited by Cetera
Missing a qualifier and explanation in the first paragraph regarding versions.
Link to comment
Share on other sites
ArcFurnace

ArcFurnace

Posted
Posted (edited)

Tried with stock and it seemed stable, so I added my usual load of mods. It loads up, but I get semi-random memory access violation crashes (at least once when I hit "autotag" on Part Catalog, at least once when a ship crashed into the ground, but neither reproduced 100% of the time). Updated graphics drivers, didn't seem to fix it. Currently testing OpenGL mode.

EDIT: OpenGL mode seems to work, but it does odd things when I alt-tab out of KSP (I play in full screen mode; without forcing OpenGL mode I can alt-tab out of the game and when I switch back it will go back to being full screen, but in OpenGL it seems to switch to windowed mode when I alt-tab away from it and stays that way until I restart the game). Also getting the known zero-decoupler-force bug and the weird-mouse-shenanigans bug. None are gamebreaking, but they are annoying. Did someone say they managed to fix the zero-decoupler-force bug?

Edited by ArcFurnace
Link to comment
Share on other sites
Wyseman76

Wyseman76

Posted
Posted

I've got my 64bit install running as well as my 32bit with 2 times as many mods, hitting just over 5 gigs of memory while in play. So far I'm now down to the one single issue that is baffling more than myself I see and that is the decouplers having absolutely no ejection force.

Link to comment
Share on other sites
Walsht9

Walsht9

Posted
Posted

Adding "PhysicsSignificance = 1" to the .cfg of any stack decouplers fixed the election force for me, but it didn't work on any Fairings (kw or pf) or radial decouplers. My guess is that this is some sort of collider issue.

Link to comment
Share on other sites
MoparGamer

MoparGamer

Posted
Posted
Adding "PhysicsSignificance = 1" to the .cfg of any stack decouplers fixed the election force for me, but it didn't work on any Fairings (kw or pf) or radial decouplers. My guess is that this is some sort of collider issue.

Decided to try and work on the ejection force issue as well, I instead put negative values in and got some decoupler force (Although I think it's in the wrong direction). Sadly I was doing this before school so I haven't been able to extensively test it.



MODULE
{
    name = ModuleDecouple
    ejectionForce = -250
	explosiveNodeID = top
}
}

Would someone try this more extensively well I'm gone?

Link to comment
Share on other sites
Lilleman

Lilleman

Posted
  • Author
Posted

No luck with those two fixes unfortunately.

But I did managed to have one decoupler ejection. Only one. Totally random. Just by clicking and decoupling by hand, but it didn't happened since.

This bug is weird.

I also tried

MODULE

{

name = ModuleDecouple

ejectionForce = 250.0

explosiveNodeID = top

}

}

But it does not work either.

Also agreed this is getting difficult to isolate the bugs coming from 32-bits and those specific to 64-bits version.

I'm still looking for ideas for the first post to make the troubleshooting easier for everyone.

Link to comment
Share on other sites
gl0ryh0und

gl0ryh0und

Posted
Posted

Just my 2 cents.

After doing some tests I found that the 64Bit version while allowing more parts to be loaded, was a bit of tenuous trade off of stability and part count.. I was able to easily exceed with 4GB wall, but load times were growing the further I ventured from 4GB.. also I found no appreciable difference in the amount of parts that the system could handle.. somewhere in the 1400 - 1600 part range was playable on both, but slow enough to basically eliminate any joy to it.

Mods also affected stability, which seemed had little connection with the memory bloat and more to do with what the plugins were doing.. so part bloat = ok Plugin bloat = instability for what ever reason. I didn't dig into it.

In short, I can see why Squad isn't interested in pushing the 64bit right away.. maybe somewhere down the road, but the payoff in resources seems to be in odds with the effort required. The 64bit would really shine however if Unity made use of the multiple cores that are basically standard in today's computers, which it doesn't appear to do.

Very cool that you found this work around though. Nice find.

Link to comment
Share on other sites
Wyseman76

Wyseman76

Posted
Posted
Just my 2 cents.

After doing some tests I found that the 64Bit version while allowing more parts to be loaded, was a bit of tenuous trade off of stability and part count.. I was able to easily exceed with 4GB wall, but load times were growing the further I ventured from 4GB.. also I found no appreciable difference in the amount of parts that the system could handle.. somewhere in the 1400 - 1600 part range was playable on both, but slow enough to basically eliminate any joy to it.

Mods also affected stability, which seemed had little connection with the memory bloat and more to do with what the plugins were doing.. so part bloat = ok Plugin bloat = instability for what ever reason. I didn't dig into it.

In short, I can see why Squad isn't interested in pushing the 64bit right away.. maybe somewhere down the road, but the payoff in resources seems to be in odds with the effort required. The 64bit would really shine however if Unity made use of the multiple cores that are basically standard in today's computers, which it doesn't appear to do.

Very cool that you found this work around though. Nice find.

I don't disagree with anything you have said but I would like to mention that one of the biggest factors is the breathing room that the 64bit allows. With it, I can install the same number of mods I was before without having to hyper compress textures and completely lose most of the beauty of things like EVE.

Link to comment
Share on other sites
gl0ryh0und

gl0ryh0und

Posted
Posted
I don't disagree with anything you have said but I would like to mention that one of the biggest factors is the breathing room that the 64bit allows. With it, I can install the same number of mods I was before without having to hyper compress textures and completely lose most of the beauty of things like EVE.

No disagreement there.. Me I don't mind the light version of the texture compression, I still find it beautiful.. On another note I did notice a slight difference in the way memory bloats between the two.. on 32Bit the memory usage tends to grow faster.. so while your mods might bloat to 3.8GB on 32bit, the same mod load on 64Bit takes 3.2 or some noticeably less amount. This might be a result of how memory space is allocated and a reflection of how uncompressed textures in the 32 bit environment waste memory space.. I say it that way because with texture compression I was able to take my normal 2gb mob load on 32bit and see it load to 1.6gb under 64bit.. actual performance difference? virtually none.. unless you smashed a 1400 part rocket into the ground.. then you will see how quickly the 64bit recovers from the chaos vs the 32bit.. its' quite noticeable.

Link to comment
Share on other sites
koksny

koksny

Posted
Posted (edited)

I have been working on the decouple force in x64 version for quite few days, here are my conclusions for now:

Issue is related to decouple() function itself. There doesn't seem to be any clear way of debugging it, but i have checked values on input on both x64 and x86 - to no success. And i disagree with statement that's issue with force - i'm pretty sure force is calculated correctly, what's wrong is force vector.

I found the issue while playing with KAS. It uses decouple() function on grabbing things. While force (and amount) seem to be applied correctly, the vector is wrong, resulting in smashing things up. Resulting in decoupling having no force (because direction of this force is null or negative).

Adding "PhysicsSignificance = 1" to the .cfg of any stack decouplers fixed the election force for me, but it didn't work on any Fairings (kw or pf) or radial decouplers. My guess is that this is some sort of collider issue.

Could you please elaborate on that? I have tried to get any sort of workaround with PhysicsSignificance but to no avail, it doesn't seem to make any difference. The reason why it's not working in ProceduralFairings might be because the PhysicsSignificance = NONE/FULL is hardcoded into mod dll.

For anyone also cracking on this problem, there are two links that might me related to the issue:

http://bugs.kerbalspaceprogram.com/issues/2412

http://forum.unity3d.com/threads/hybridobbcollider-crash-issue-in-x64-standalone-player.224486/

Any help on topic would be greatly appreciated, especially if anyone knows what is inside decouple() and how to modify it.

EDIT:

There is brilliant finding few pages back:

I've experienced this as well. At first I thought it was a problem with pfairings but then I realized all my decouplers were having the same problem. From what I've seen the issue only presents when you stage a decoupler. Manually triggered, the decouplers seem to work fine, though it is a bit tedious.

With PhysicsSignificance = NONE and manually clicking the decouple action from RMB menu - it works. There is different method/function being called when manually activating decoupler from RMB menu. Where's the difference?

This thing may be the key to hotfix.

EDIT2:

Triggering decoupling from Action Group also works.

EDIT3:

Can confirm earlier testings, it doesn't work 100% times, still better than staged decoupling.

EDIT4:

Nope, it's all totatlly random, can decouple with staging too. Sometimes.

Edited by koksny
Link to comment
Share on other sites
MoparGamer

MoparGamer

Posted
Posted
No luck with those two fixes unfortunately.

But I did managed to have one decoupler ejection. Only one. Totally random. Just by clicking and decoupling by hand, but it didn't happened since.

This bug is weird.

I also tried

MODULE

{

name = ModuleDecouple

ejectionForce = 250.0

explosiveNodeID = top

}

}

But it does not work either.

Also agreed this is getting difficult to isolate the bugs coming from 32-bits and those specific to 64-bits version.

I'm still looking for ideas for the first post to make the troubleshooting easier for everyone.

Seems I just had a streak of luck this morning, both of the test I was able to do earlier were just lucky right clicks. After getting home I ran through several test with a 25+ decoupler vessel with various Ejection forces and it seems that ejection force is unrelated to the decoupler issue. (tried activating decouplers with staging for awhile as well, no luck there either) It seems that I was able to get about 1 in 5 decouplers to activate by right click though. So I think that at least narrows down that the decoupling method/module is working but often gets some sort of error with the 64 bit unity player.. I also took a look at my output log as well, outside of a few odd errors (Hyper-edit, Distant object enhancement) the only thing I found was this type of line:

Part KW1mDecoupler cannot load module #1. It only has 1 modules defined 
(Filename: C:/BuildAgent/work/d3d49558e4d408f4/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 53)


PartModule is null.

(Filename: C:/BuildAgent/work/d3d49558e4d408f4/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 53)


Part KW1mDecoupler cannot load module #1. It only has 1 modules defined

(Filename: C:/BuildAgent/work/d3d49558e4d408f4/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 53)


PartModule is null.

and

(Filename: C:/BuildAgent/work/d3d49558e4d408f4/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 53)

Part KW3mDecoupler cannot load module #1. It only has 1 modules defined

(Filename: C:/BuildAgent/work/d3d49558e4d408f4/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 53)


PartModule is null.

(Filename: C:/BuildAgent/work/d3d49558e4d408f4/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 53)


Part KW3mDecoupler cannot load module #1. It only has 1 modules defined

(Filename: C:/BuildAgent/work/d3d49558e4d408f4/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 53)


PartModule is null.

(Filename: C:/BuildAgent/work/d3d49558e4d408f4/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 53)


Part KW3mDecoupler cannot load module #1. It only has 1 modules defined

(Filename: C:/BuildAgent/work/d3d49558e4d408f4/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 53)


PartModule is null.

Just a note, I set the 1m decoupler to have an ejection force of -2500 and the 3m to 2500 (As I was testing to see if various ejection forces had any effect)

Link to comment
Share on other sites
koksny

koksny

Posted
Posted
Just a note, I set the 1m decoupler to have an ejection force of -2500 and the 3m to 2500 (As I was testing to see if various ejection forces had any effect)

As default, 3m decoupler has PhysicsSignificance = FULL, that might have tainted your results, right clicking doesn't work then.

Link to comment
Share on other sites
Lilleman

Lilleman

Posted
  • Author
Posted (edited)

I can confirm, this is totally random. I tried to modify a standard stage decoupler (Rockomax Brand Decoupler) with no sucess, but radial decouplers are kinda fun.

If you put a large ejection force (I tested x100) and "PhysicsSignificance = 1", the decoupler will not move but will apply a force to the main rocket. (If symmetry is applied, you will not see the effect.)

With a large ejection force and "PhysicsSignificance = 0", the decoupler randomly eject things correctly. Even with staging.

I don't really get it. My guess was:"some functions might be needed from the 64-bits unityEngine.dll after all."

But, nope. Don't work either...

I didn't test mods with explosives separators or separator nosecones, though. Might add a nice Role-Playing touch.

Edit: just played a bit with KAS. Did not expect this grabbing bug (I find it hilarious, I'll keep this mod just for this), but I'll add it to the first page with the expected glitches. Thanks for noticing koksny!

Edited by Lilleman
Link to comment
Share on other sites
Bloodbunny

Bloodbunny

Posted
Posted

Ok, I may be reaching the limits here, I start to get some really insane FPS drops.. like maybe 1 frame every 2 seconds. It recovers, but it happens often enough to make it unplayable. The game is stable and doesn't crash, but I start to get it once I reach around 9 gigs of RAM use. BoatParts caused it, then I deleted it and back it normal. Now KSO is doing the same.. will delete and see if it fixes it.

Link to comment
Share on other sites
JordanL

JordanL

Posted
Posted
Ok, I may be reaching the limits here, I start to get some really insane FPS drops.. like maybe 1 frame every 2 seconds. It recovers, but it happens often enough to make it unplayable. The game is stable and doesn't crash, but I start to get it once I reach around 9 gigs of RAM use. BoatParts caused it, then I deleted it and back it normal. Now KSO is doing the same.. will delete and see if it fixes it.

9GB is enough that the OS might be paging. If that's happening, the memory management in KSP has to be really good to prevent slow down like what you experienced.

How much RAM do you actually have installed?

Link to comment
Share on other sites
Bloodbunny

Bloodbunny

Posted
Posted

I've started to get crashes right as I pass through the EVE lower cloud layer.. persistent and repeatable..never seen it before. This is frustrating because there is no way to know if the crash is caused by 64 bit, or if its just a garden variety mod conflict crash

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...