x64 works ! But I don't know why! Please help me replicate.

[therealcrow999]

Yeah thanks! I just started playing again since last week. Last version I played was .22. So when I saw x64 I knew they increased memory, but wasn't to sure about taking advantage of x64 CPUs and multicores.

Thanks I will go back to x86, seems more stable.

[Alshain]

Yeah thanks! I just started playing again since last week. Last version I played was .22. So when I saw x64 I knew they increased memory, but wasn't to sure about taking advantage of x64 CPUs and multicores.

Thanks I will go back to x86, seems more stable.

x64 is not multi-core support. Two different technologies.

Long story short, computers are binary. Each memory spot (called a byte) need a unique address so it can be located, just like your house! So if you take a scientific calculator (programmer mode in windows calculator) in binary mode enter the number 1 32 times and convert that to decimal you get 4294967295. That is bytes, divide by 1024 to get kilobytes, again to get megabytes, and again to get Gigabytes. The resulting number is 4, so you can address 4GB with 32 bits of space. With 64 bits it's something like 16.8 exabytes but that's a theoretical/mathematical limit, other hardware issues limit it much further.

This can more quickly be divined by simply raising 2^32 or 2^64, but that explanation doesn't illustrate why it is the way it is.

[NathanKell]

One more note on the TGA / PNG front. Taverius reminded me of the loader bug in KSP: unless you have ATM, TGAs don't get compressed. So if you're not using ATM, your memory usage with all TGA converted to PNG (which does get compressed) will be *way* lower. Might this go some way to explaining the difference?

[Alshain]

One more note on the TGA / PNG front. Taverius reminded me of the loader bug in KSP: unless you have ATM, TGAs don't get compressed. So if you're not using ATM, your memory usage with all TGA converted to PNG (which does get compressed) will be *way* lower. Might this go some way to explaining the difference?

It could be. I haven't seen anything posted by anyone that shows KSP was using more than 4 GB after the PNG conversion. That the exact reason why I wanted to get the test to fail on a control test with TARGA files first and then get it to work on PNG while monitoring the process usage to ensure both cases exceeded 4GB on the exe. Unfortunately I still can't get the control test to fail. It's just typical really, the one time I want to fail and it won't.

[MisterFister]

I edited my data post at the bottom of the previous page. Note that one result called for ~6gb ram after load. I posted a dropbox link to my branched log files (mostly crash reports, but there were some non-crashes as well.)

My own limitation on being helpful is that, beyond replicating the same steps to get to the title screen (which is how I built that data set in the dropbox link) I'm not exactly sure how to replicably "test" or "stress test" a modded install past the title screen, other than by "playing" it, which is very organic and not very conducive to reliable, replicable testing (I prefer career mode and career-mode-oriented mods) without going to sandbox or just waiting for the occasional rando CTD and posting the crash logs then, along with perhaps the career save folder for good measure if someone thought that would be useful. I can say, however, that I've resumed play on my career save in x64 using this texture-conversion technique (with a slightly expanded modlist from the one I'd settled on for x86, without ATM and with an idle RAM footprint at title screen ~5.8gb) and aside from a slight gameplay issue from having introduced a new mod that wasn't there when I began the save, I have to admit that x64 appears to be running gangbusters. My only frame of reference was an aborted attempt about a month ago to start a career save on x64 that resulted in me giving up due to right-click issues, massive z-fighting, and other stability issues that rendered my gameplay to be so unfun as to be borderline unplayable.

From this point onward, I'll make it a habit to save all output logs after every gaming session, whether it crashes or not, so as to prepare for the possibility that I would run into a crash issue later on in my career progression (allowing for the output logs over time to document any evolving error trends.) I suppose I can just add them to my dropbox link if anyone would care to look.

[MisterFister]

Accidental duplicate post.

Edited September 25, 2014 by MisterFister

[kimiko]

Good evening everyone!

Sorry for the lateness, but I finally got around to test this out again. Thanks for keeping the thread alive! : 3

Test #1:

Method:

For this test I used the proposed mods by Alshain in a clean install:

-Karbonite

-MKS/OKS

-FTT

-B9

-KWRocketry

-NovaPunch

-SpacePlane+

-KerbinSide

All (ingame) Graphical settings were set to maximum with the exception of AA. Two separate GameFolder folders were created, one without any modifications ("fTGA") and one with all TGAs converted to PNGs ("fPNG").

All tested on using x64 D3D.

The RAM memory readings were taken of Windows Task Manager.

Results:

- Both fTGA andf PNG would crash somewhere while adding parts in the VAB.

- Memory usage would stay between 3 and 3.5 GB at title screen, and never exceed maximum available RAM memory.

- During initial loading screen, fTGA would hit up to approximately, 4.1 GB before dropping back when entering title screen.

Test #2:

Method:

Same as Test #1. However, Firefox was run on the side occupying about 50% of maximum available RAM memory.

Results:

fPNG had results similar to Test #1.

fTGA would crash during initial loading screen while closing maximum RAM memory threshold. It seems to crash as some of the RAM memory of Firefox was presumably loaded onto the virtual memory storage on the hard drive, as there were a significant drop in Firefoxe's memory usage (close to 1 GB).

Test #3:

Method:

Same as Test #1, except Texture Quality-setting in the (Ingame) Graphical settings was set to "Half Res".

Results:

fTGA would crash when fiddling around in the VAB, much similar to the first test.

fPNG would work smoothly allowing launching rockets and orbiting.

Findings:

-With the present setup, KSP x64 D3D will crash during when exceeding the 3.5/4GB threshold (assuming that is the threshold).

-It will also crash for reasons unknown while staying under the limit when Texture Quality is maxed out.

-While using fTGA, i.e. mods provided as it is, will crash the game anywhere from launch to editing in the VAB.

- fPNG will eventually work when RAM is available, is under the 3.5/4 GB threshold, and using Half Res texture quality.

Conclusion:

- Converting TGAs into PNGs seems to help out avoiding crashes. Which seems to support NathanKell's (after Taverius) findings.

One more note on the TGA / PNG front. Taverius reminded me of the loader bug in KSP: unless you have ATM, TGAs don't get compressed. So if you're not using ATM, your memory usage with all TGA converted to PNG (which does get compressed) will be *way* lower. Might this go some way to explaining the difference?

HOWEVER:

My main installation (which I am currently playing with the 150+ I presented in my second post) is STILL working with maxed out game settings, including "Full Res" Texture Quality, and exceeding 5GB RAM memory usage.

I don't even...

Apparently the TGA to PNG conversion is not what makes me able to utilize more than 3.5/4GB of RAM memory.

Limitations:

My main instillation had many things done to it, so I don't really know if I can replicate it myself............

What do you guys think?

Some wild shots are: It loads up files in a different manner that may put less "strain" on the process and stopping it for going ballistic?

I am have no idea anymore.

At least we got to know that PNGs are more RAM friendly...

*sigh*

Edited September 25, 2014 by kimiko
aparantly I can't write agian

[Alshain]

Seems like the same unpredictableness I'm having. Something is causing one installation to work fine above the 4 GB cap, while another will not. If the only difference is the mods used then my feeling is it has to be mod incompatibility and not KSP.

[NathanKell]

If you want to be systematic, use this:

https://github.com/ferram4/KSPExceptionThrower

That will make x64 crash on demand, more or less (when above threshold).

Although: it's just the source, it needs to be compiled. Unlike ferram, he usually puts the dll in git too.

[Phantomewzick]

Good evening everyone!

Sorry for the lateness, but I finally got around to test this out again. Thanks for keeping the thread alive! : 3

Test #1:

Method:

For this test I used the proposed mods by Alshain in a clean install:

-Karbonite

-MKS/OKS

-FTT

-B9

-KWRocketry

-NovaPunch

-SpacePlane+

-KerbinSide

All (ingame) Graphical settings were set to maximum with the exception of AA. Two separate GameFolder folders were created, one without any modifications ("fTGA") and one with all TGAs converted to PNGs ("fPNG").

All tested on using x64 D3D.

The RAM memory readings were taken of Windows Task Manager.

Results:

- Both fTGA andf PNG would crash somewhere while adding parts in the VAB.

- Memory usage would stay between 3 and 3.5 GB at title screen, and never exceed maximum available RAM memory.

- During initial loading screen, fTGA would hit up to approximately, 4.1 GB before dropping back when entering title screen.

Test #2:

Method:

Same as Test #1. However, Firefox was run on the side occupying about 50% of maximum available RAM memory.

Results:

fPNG had results similar to Test #1.

fTGA would crash during initial loading screen while closing maximum RAM memory threshold. It seems to crash as some of the RAM memory of Firefox was presumably loaded onto the virtual memory storage on the hard drive, as there were a significant drop in Firefoxe's memory usage (close to 1 GB).

Test #3:

Method:

Same as Test #1, except Texture Quality-setting in the (Ingame) Graphical settings was set to "Half Res".

Results:

fTGA would crash when fiddling around in the VAB, much similar to the first test.

fPNG would work smoothly allowing launching rockets and orbiting.

Findings:

-With the present setup, KSP x64 D3D will crash during when exceeding the 3.5/4GB threshold (assuming that is the threshold).

-It will also crash for reasons unknown while staying under the limit when Texture Quality is maxed out.

-While using fTGA, i.e. mods provided as it is, will crash the game anywhere from launch to editing in the VAB.

- fPNG will eventually work when RAM is available, is under the 3.5/4 GB threshold, and using Half Res texture quality.

Conclusion:

- Converting TGAs into PNGs seems to help out avoiding crashes. Which seems to support NathanKell's (after Taverius) findings.

HOWEVER:

My main installation (which I am currently playing with the 150+ I presented in my second post) is STILL working with maxed out game settings, including "Full Res" Texture Quality, and exceeding 5GB RAM memory usage.

I don't even...

Apparently the TGA to PNG conversion is not what makes me able to utilize more than 3.5/4GB of RAM memory.

Limitations:

My main instillation had many things done to it, so I don't really know if I can replicate it myself............

What do you guys think?

Some wild shots are: It loads up files in a different manner that may put less "strain" on the process and stopping it for going ballistic?

I am have no idea anymore.

At least we got to know that PNGs are more RAM friendly...

*sigh*

The crashes you are having in this instance are due to the mods from Umbra Space Industries like Karbonite and MKS/OKS, once i removed all his mods from my install and converted all my image files to PNG like you said in your first post, and now I am also running without ATM, and I am able to load up ksp past 5 gigs and its working fine, I even copied it to another computer and me and a friend were playing multiplayer with it!

[Blowout]

I've been running KSP 64bit on well over 7gigs of ram for quite some time.

It's an experimental install i'm trying to get stable (good effin luck!!). One thing i did notice is that whenever anything is changed about the gamedata folder, it will break all previous saves. Loading them will consistently cresh the game on clicking a part. Reverting the gamedata folder to the previous state will fix it... mostly.

The new B9 aerospace 5 won't work PERIOD, not eve on a clean install, ditto for active texture management. Though the latter did work on a clean install, just not with any number of other mods. Parts catalog crashed the game on VAB/SPH load consistently. There are a few other mods I have tested that refuse all cooperation, unfortunately I can't quite recall as this has been an ongoing process for... well forever really, and progress is slower than zombie snails.

I WAS running fine with:

- Blizzy's toolbar

- B9 RC4 (with updated plugins)

- Blackhearts procedural fairing textures

- chatterer

- Connected living spaces

- crossfeedenabler

- custom biomes

- DR

- Distant Objects

- EVE

- FAR

- Rastapropmonitor

- interstellar light

- Engineering redux

- nav instruments

- hyperedit

- BA v5

- Cool rockets

- KM Space Shuttle Engines

- KSPRC (without the sound mods)

- Mechjeb 2

- Cargo Bays by Tal

- Hot Rockets

- Docking port alignment

- Final frontier

- ORS

- Procedural dynamics

- Procedural fairings

- Procedural parts

- Remote tech 2

- ScanSat (plus RPM)

- Ship manifest

- SPO

- SMokescreen

- Surface lights

- Texturereplacer

- TACLS

- Kerbal alarm

- Tweakscale

- MKS/OKS

- Karbonite

- DERP lifeboat mod

- Us core

- US tac

- Vesselviewer for RPM

- Module manager 2.3.5

This was working just fine, hours of playtime into the savegame.

Then i added Realfuels with stockalike engine configs to it, and it proceeded to crash every time i click any part. I removed realfuels and the stockenigne configs but the game still continues to crash each time i click a part. So it's back to square one...

One thing is for sure, 64bit KSP is a major PITA, once it starts crashing, good luck getting it back to do anything BUT crash. That being said, it does seem to persistently crash with certain mods installed. B9 is a particularity hard mod to install, as is KM's shuttle engines. I had to delete the fueltanks from the KMSSE mod to get it to work, and the B9 RC4 "sort of" works, as long as you can live with some freaky saber engine behavior and the odd crash on clicking a part. The rest of the mods I've listed are more forgiving. MKS/OKS gave me a few issues at first, but sticking to a clean savegame fixed those.

Edited September 26, 2014 by Blowout

[Jashin]

I've been running KSP 64bit on well over 7gigs of ram for quite some time.

It's an experimental install i'm trying to get stable (good effin luck!!).

I feel you mate. I was playing on a nice stable save using the 64bit version and one day I've tried to use the new B9 version. Next thing I know is hell breaks loose and my install is borked beyond measure. There's no way I'm able to run B9, I run into a ton of NullReferenceException during loading (it doesn't crash but stops loading after ModuleManager is done patching). I'm waiting for the new asset loader coming in .25 and hoping it will improve performance and stability but right now I've lost even the will to play after hours upon hours of troubleshooting.

[odmonk]

Results replicated.

Long version:

I was getting occasional crashes in Sandbox mode running 64bit, but was tolerating it well enough while vetting the list of mods I was planning on using for a new 24.2 Career mode game. Once I had a stable, tested list of mod versions, I started a new Career mode game and *crash* *crash* *crash*: it would crash changing scenes very often and unpredictably; I only occasionally got a chance to play a mission.

So, I tried the method outlined in this thread: made a backup of my 24.2 environment and converted all the non-png graphics to png using XnView.

Miracle! I'm still waiting for my first crash to happen, and have been playing for days. TaskManager shows memory usage of 2.6Gb RAM.

My current Mod list:

Directory Module Version

000_Toolbar Toolbar 1.7.6 [24.1]

ActionGroupManager Action Group Manager 1.3.2.0 [t24]

AdaptiveDockingNode AdapativeDockingNode dll 1.5

AviationLights Aviation Lights 3.6 [24.2]

blizzy Achievements 1.6.3 [24.2]

BoatPartsR[345] Boat Parts R4.55+14dlls? [24.2]

BoJaN QuantumStruts Continued Initial/1.1 [24]

CrewManifest Crew Manifest 0.5.8.0 [24]

Diazo/RCSLandAid RCS Landing Aid 1.2a [24.2]

Diazo/TWR1 Vertical Velocity 1.13 [24.2]

EditorExtensions Editor Extensions 1.3 [24]

Engineer Kerbal Engineer Redux 0.6.2.10 [24.2]

ExtraplanetaryLaunchpads Extraplanetary Launchpads 4.2.3 [24.2]

Firespitter Firespitter 6.3.5 (Sept. 1) [24.2d]

Fusebox Fusebox 1.0a [24.2]

GingerCorp Ginger Corp Station Hubs 1.1 [24]

Goodspeed Goodspeed Aerospace Parts 2014-04-1B [24]

HabitatPack Inflatable Habitats V0.4 (Apr 23) + cfg [?]

HooliganLabs Hooligan Labs SQUID 1.5.1 [24.2]

Hooligan Labs Airship 2.6.0 [24.2]

Hooligan Labs Airship Model Rework July 30 [24.X]

Hooligan Labs Ballast 1.3.0 [24]

JSI Sensible Pumps 1.1 [24]

KAS Kerbal Attachment System 0.4.8 [24.2]

KerbalJointReinforcement Kerbal Joint Reinforcement 2.4.3 [24.2]

Kerbaltek Hyper Edit^ 1.2.4.2 [t24]

Kethane Kethane 0.8.8+.1 [24.2]

KipEng Universal Docking Port Set 0.9.4

Low Profile Hubs 1.04

Klockheed_Martian base KM2.1.2

Asteroid +KMA2.1

Smart Parts +KMSP2.1.1 [24.1]

Special Parts +KMSp2.1.2

kOS kOS Scriptable AutoPilot 0.14 [24.2]

KSPX KSPX 0.2.7

MagicSmokeIndustries Infernal Robotics 0.19a [24.2]

ZodiusInfuser:Structural/Robotics IR Rework – Structural PrS05

IR Rework – Robotic PrR11

IR Rework – Struts Prs01

IR Rework – Utilities PrU01

IR Rework – Athlete PrA01

ToadicusTools ZodiusInfuser:Struts 0.0.0.0, in Prs01

TweakableEverything ZodiusInfuser:Struts 1.1.5259.20661, in Prs01

MechJeb2 MechJeb Autopilot 2-2.3.1.319-319 [24.2]

ModStatistics ModStatistics 1.0.3 [24] (opt out)

ModularFuelTanks ModularFuelTanks 5.1.1/KSPAPI [24.2]

ModuleManager Module Manager 2.3.5 [24.2]

NavBallDockingAlignmentIndicator NavBall Docking Alignment Indicator V4 [24]

nothke_DROMOMAN DROMOMAN Build 2-2013-06+PATCH

ProceduralFairings Procedural Fairings 3.0.9/KSPAPI [24.2]

ProceduralParts Procedural Parts 0.9.18/KSPAPI* [24.2]

RealChute Real Chutes 1.2.4 [24.x]

SCANsat SCANsat 7.0rc4 [24.x]

SelectRoot Select Root July18 [24]

SpaceplanePlus SpacePlanePlus 1.3 [24]

StageRecovery StageRecovery 1.5.0 [24.2]

Targetron Targetron 1.4.1 (patch) [t14]

ThunderAerospace TAC Fuel Balancer 2.4.0.3 [24.2]

TAC Part Lister 1.2.0.2 + patch [24p]

TAC Self Destruct 1.3.1.3 [t24]

TriggerTech Alternate Resource Panel 2.5.1.0 [24]

Kerbal Alarm Clock 2.7.8.2 [24]

TweakScale TweakScale 1.43/KSPAPI [24.2]

UmbraSpaceIndustries Deployable Airbags 0.4.0 [24.2]

US_Core Universal Storage (Core) 0.8.4.22[24.2]

ResourceConverter ResourceConverter 1.2 [24.2]

US_KAS Universal Storage (KAS) 0.8.3.12 [24.2]

[MisterFister]

I have to say, I've been running this experiment for the past week or so, and x64 seems to be as smooth as butter for me after having converted those texture formats. This is not to say that it's been crash free, as even x86 crashes. While it's true that I hadn't been keeping "thorough" track of my crash-rate before this experiment, I estimate that with average play sessions of approximately 2-5 hours each, I run into a crash approximately once every 2-3 hours or so, give or take, and that this is roughly comparable to what I got on x86 as well. My memory footprint trends ~6.9gb at title screen with this setup, with no ATM.

I've been posting my partially annotated output logs to https://www.dropbox.com/sh/escqxych4z180de/AAA4FyP6t2NccUz6b5cBgodxa?dl=0, which is also where you can find my original experiment stats.

The only "new" symptom I can report after extensive x64 usage isn't technically a new symptom at all, just a new manifestation of an old one. Previously, it did occasionally happen (both in KSP x86 and outside of KSP entirely in other programs, including once in a web browser, and a handful of times over the years in other games) where my usb sound device would just go dead. This tended to happen, on average, after extended periods (days or longer) of Windows not being shut down and instead being slept or suspended between work sessions. The problem could have been fixed with a hard reboot or by unplugging-replugging the usb cable to the sound device. Google searches confirm that this is not unheard of in Windows including Vista, 7, and 8. (I currently run 7, but I recently downgraded from 8, and originally purchased KSP while running Vista.) Those same Google searches are wholly unhelpful, however, on revealing a cause.

The new dimension to this issue since going feet first into x64 is that this seems to happen much more frequently now. While it can occasionally happen twice during the same Launchpad sequence, I can report that it SEEMS more likely to happen within the first 90 seconds after a KSP scene transition. This sound loss persists even after exiting KSP, but is quickly restored by the unplug/replug method or by a hard reboot. This suggests to me that it's not a KSP problem specifically, but something about the way KSP x64 (or Unity x64) addresses memory exacerbates an already known underlying problem. My personal, uneducated, suspicion, is that Unity and KSP both need memory streamlining that is a few versions off in the future, and / or we might have a memory leak of some kind.

I do not anticipate abandoning my x64 play any time soon, however, even with this issue. I run AOL Instant Messenger (remember that?) and it's taken in recent weeks to throwing certificate errors at idle, so I may have other incentives to do some reworking on my system that would also address this sound loss issue. In any event, x64 with full-res textures is GLORIOUS and it feels like the way it's supposed to be played. I shall not willingly go back.

[MisterFister]

For the record, I've seen the anti-x64 movement from modders, not the least of whom ferram4, who have affirmatively withheld x64 support. Until I manage to install Linux (a process to which I do not look forward) I shall enjoy the fact that I archived my 0.24.2 install and segregated my mods. I am very well past the threshold where ATM could even possibly help me remain within x86 memory limits. Pity.

[MisterFister]

Kerbals and Kerbonauts, I am revisiting this thread because I want to continue experimenting with this idea in Linux x64. However, the XnView conversion utility seems to have undergone an update since v0.24.2 and the last somewhat-playable Win64 build. I'm just wondering if anyone else has any insight as to how to go about converting lots of .tga files to .png across a sprawling GameData that by itself weighs in around 2.2Gb with exactly 133 individual first-level folders, not counting the per-mod subfolders?

[DaniDE]

Cant you do a search for *.tga in the gamedata directory and drag them into xnview / xnconvert? At least xnconvert batch converts them flawlessly here when I tell it to use exactly the filename of the original (default setting adds _result to the filename), save to original folder and delete the originals, I use Windows x64 though and my last experience with linux is from several years ago sorry. It is really like drag search results over to xnconvert, drop, three clicks and a few seconds of waiting. Ok it´s a SSD, but still, no big deal.

Edited December 5, 2014 by DaniDE

[MisterFister]

I managed to find an old archived version of the converter utility in my backups and forgot to post here with the update.