[1.0][Release-5-0][April 28, 2015] Active Texture Management - Save RAM!

[joker169]

Is this working for the 64bit version? I have used this in the past with 32bit version, but when i start with the 64bit KSP, it doesn't seem to be saving any RAM, it usually pauses right at start, then loads mods. Now it starts loading mods right away. it stops loading right at when resource usage for app reaches 7GB, I have 12GB installed on Windows 8.1 64bit. I have tried removing the mod(s) it stops on but still stops at 7GB memory usage. FYI i have the latest mods for .24 except KAS and a total of 76 folders in Gamedata DIR.

[NathanKell]

Hi! I know you're new here (welcome!), but as a general rule it's a very good idea to read the last page or so of the thread before replying. Had you done so, you would see that that is all anyone is talking aboutand no it doesn't.

[joker169]

Hi! I know you're new here (welcome!), but as a general rule it's a very good idea to read the last page or so of the thread before replying. Had you done so, you would see that that is all anyone is talking aboutand no it doesn't.

Thanks for the reply Nathan, had a page open from last night and was looking at it when i posted. Didn't see the others till i came back to check on post. My bad

[sidfu]

Linux 64 bit user here with 8 Gb RAM and I have been using ATM since it was first released and gaining an advantage the whole time.

I hate to disappoint all you Windows users new to 64 bit but if you like to run heavy with mods you are still going to need this! I just re-installed TextureReplacer and EVE in 0.24 and at around 6 Gb RAM used I hit the wall for available texture memory. On my system the Linux 64 bit version does not appear to make all your remaining free RAM available for textures and I seriously doubt the Windows 64 bit version is any different. You will probably find that the aggressive version of ATM is not as necessary as before. I have always been able to run with the basic version. Possibly folks with 16 or 32 Gb of RAM will have a different experience,I don't know but I am interested to know if purchasing more RAM would make any difference.

Thanks as always for the great work rbray89, cheers,

Kaa

we know we will still need this but right now it dont work for .24 hopely we get a update soon or a temp fix if someone finds one.

[p331083]

Linux 64 bit user here with 8 Gb RAM and I have been using ATM since it was first released and gaining an advantage the whole time.

I hate to disappoint all you Windows users new to 64 bit but if you like to run heavy with mods you are still going to need this! I just re-installed TextureReplacer and EVE in 0.24 and at around 6 Gb RAM used I hit the wall for available texture memory. On my system the Linux 64 bit version does not appear to make all your remaining free RAM available for textures and I seriously doubt the Windows 64 bit version is any different. You will probably find that the aggressive version of ATM is not as necessary as before. I have always been able to run with the basic version. Possibly folks with 16 or 32 Gb of RAM will have a different experience,I don't know but I am interested to know if purchasing more RAM would make any difference.

Thanks as always for the great work rbray89, cheers,

Kaa

Yeah, KSP is running at around 5.4gb atm, and thats not even with all the mods i want to use.

[sidfu]

hmm seems on 64bit it does work a little but its not like it use to be before it was around 160mb in cache now its only around 74mb. seems like its not doing its load textures before game loads thing is what it is.

found something new when i loaded game and tried to start a new game it started trying to save memory.

ActiveTextureManagement: Accumulated Saved 1007826100B

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

NullReferenceException: Object reference not set to an instance of an object

at ActiveTextureManagement.ActiveTextureManagement.Update () [0x00000] in <filename unknown>:0

this is when it was trying to load a new save game. dont remember it trying to save when loading a save game before

Edited July 19, 2014 by sidfu

[rynak]

I hate to disappoint all you Windows users new to 64 bit but if you like to run heavy with mods you are still going to need this!

The whole "You don't need this anymore because now you got enough RAM" is an argument made from complete technical ignorance anyways. It should be obvious to anyone who knows even a tiny bit about what is inside a computer - DRAM, video RAM, cpu-cache, the different busses, that need to transport all that data... and finally, (graphical) processors that can only process N bits per second.... anyone who knows this, must simply laugh at people saying "uh, look now i have enough RAM! No need for efficient memory usage anymore!".

The only thing that 64bit solves for KSP, is "out of memory"-crashes with regards to main RAM. All the other issues remain entirely unchanged, including unity's questionable performance.

[Kaa253]

hmm seems on 64bit it does work a little but its not like it use to be before it was around 160mb in cache now its only around 74mb. seems like its not doing its load textures before game loads thing is what it is.

.....

I can confirm this observation. On the Linux 64 version it does appear to be working "a little". Sorry I am no expert on what is or isn’t working. If I can help by testing something in some way or by submitting the KSP/Unity_Linux style Player.log file please let me know.

Edited July 19, 2014 by Kaa253

[JonBar]

The only thing that 64bit solves for KSP, is "out of memory"-crashes with regards to main RAM. All the other issues remain entirely unchanged, including unity's questionable performance.

Odd because I used to have more lag with larger part count vessels in 0.23.5, now in 0.24 (x64) I have way less lag with a higher part count vessel (tested on 300 part vessel).

[rynak]

But you're comparing 0.23.5 32bit with 0.24 64bit. Compare the same versions and installs.

Furthermore, apps running in 64bit-mode can be significantly faster, but again this is completely irrelevant to what i explained, for multiple reasons:

1. It only means that CPU tasks will be faster. It doesn't speed up memory access or GPU processing. So, you might experience less lag, because CPU bottlenecks are lessened. Others remain as they were.

2. And even for the CPU - just because you can do something inefficient faster, it doesn't make it more efficient: If you'd do it efficiently, you could do it even faster.

3. Finally, Intel and AMD are *censored* liars. That apparent speed boost when running in 64bit mode? You think thats because 64bit is faster? Well, that is what they want you to believe, because else back then there would have been no reason to buy 64bit CPUs and OSes. Here's what really happens: When they introduced 64bit CPUs, they not only upped the addressing and increased the size of registers, they also VASTLY increased the NUMBER of cpu-registers. And not just a bit, but almost TEN-FOLD. Then they went and made those features only available for apps running in 64bit mode, even though this got nothing to do with 64bit at all. But they needed an incentive to make 64bit LOOK faster, to justify the switch (No, RAM limitations wouldn't be a justification, because 32bit x86 can actually address more than 4GB in total... thats another lie. In fact, XP32 was already capable of addressing more than 4GB from the POV of the OS, but the feature was purposefully disabled in a configfile, so that applications wouldn't use it, and thus users would think they have to upgrade to a 64bit OS, to access more than 4GB).

[JonBar]

The only thing that 64bit solves for KSP, is "out of memory"-crashes with regards to main RAM. All the other issues remain entirely unchanged, including unity's questionable performance.

Odd because I used to have more lag with larger part count vessels in 0.23.5, now in 0.24 (x64) I have way less lag with a higher part count vessel (tested on 300 part vessel).

But you're comparing 0.23.5 32bit with 0.24 64bit. Compare the same versions and installs.

You're right, I was comparing the 2 because there are differences in the 2 other than what you said (as far as I can tell so far), besides you also compared the 2 by stating 'the only thing x64 bit solves...'. I agree Unity's performance and Squads coding could be better, which is why they both update periodically.

Not trying to argue with you, just pointing out that not only do we not have the NEM crashes but a slight advantage in having less lag with larger part count ships by using x64. Everything else you said was a bit irrelevant to my statement.

Edited July 19, 2014 by JonBar

[Galane]

The only thing that 64bit solves for KSP, is "out of memory"-crashes with regards to main RAM. All the other issues remain entirely unchanged, including unity's questionable performance.

I'd like to know what bogs KSP down so much on CPU power to where an AMD 2.5Ghz 7550 socket AM2 dual core starts to choke on it around 250~300 parts in a scene. A Phenom II 550 dual core socket AM3 doesn't fare much better.

Monsters like this one are very laggy on the Phenom II and pretty much impossible to to do a thing with on the 7550. Gotta get me a faster/newer AM3 CPU at least quad core.

screenshot9 by g_alan_e, on Flickr

[Agathorn]

I'd like to know what bogs KSP down so much on CPU power to where an AMD 2.5Ghz 7550 socket AM2 dual core starts to choke on it around 250~300 parts in a scene. A Phenom II 550 dual core socket AM3 doesn't fare much better.

Monsters like this one are very laggy on the Phenom II and pretty much impossible to to do a thing with on the 7550. Gotta get me a faster/newer AM3 CPU at least quad core.

https://farm3.staticflickr.com/2826/12429931853_7b7a6aaae8_z.jpgscreenshot9 by g_alan_e, on Flickr

One word (so I get over the min character requirement): Physics.

[BigD145]

One word (so I get over the min character requirement): Physics.

Part count, specifically, but that's physics on every part. It's all CPU.

[Raptor831]

I seem to be having an issue loading .24, and I'm trying to figure where my problem is. I'm starting here because it seems a likely candidate.

Basically, I don't think ATM is working on my .24 install, at all. I've no idea why this is happening, but I can say if I remove ATM completely the game actually gets further along with texture loading. It always hangs when loading textures during startup. The exact texture on which it eventually crashes varies depending on my texture settings, but the same settings with almost the same mod mix (I added DMagic Orbital Sciences for 0.24, but shouldn't be so massive as to cause memory crashes at launch) I crash not even half-way through texture loading. I'm getting this line for a lot of textures in my KSP.log:

[LOG 21:52:56.439] Load(Texture): KWRocketry/Flags/KWFlag02 OUT OF DATE
[LOG 21:52:56.439] Load(Texture): KWRocketry/Flags/KWFlag02

It would seem that I'm loading two textures for a single file when this line appears, which could explain why I'm running out of memory. But this doesn't happen in .23.5, and it doesn't happen if I remove ATM from .24.

Loading stock .24 seems to be fine, with about 1.1 GB RAM usage, which is about the same as before. Might be a bit higher, but again shouldn't be enough to crash it that early. Worst part is that I can't get any idea from the logs what is causing the crash other than being out of memory, so my guess is that ATM isn't squashing textures like it should.

player.log file here: http://cl.ly/210Z1B0j1H3g

MacOS X 10.9.4, 4GB RAM, 1GB gfx card, 32bit KSP

If you need me to run tests or give you more info, let me know. Any help or direction would be much appreciated.

[Virtualgenius]

If you read back a few pages you will see we are all in the same boat ATM isnt working properly squad changed something Rbray is aware of this and is looking at it, so its hurry up and wait with the rest of us

[Raptor831]

If you read back a few pages you will see we are all in the same boat ATM isnt working properly squad changed something Rbray is aware of this and is looking at it, so its hurry up and wait with the rest of us

Figured another report and logfile couldn't hurt. Though I didn't see any reports with my issue. One was getting hung up on the new image files, and another had 64-bit errors from ATM's dll. I didn't have either of those issues (yet). I run too many mods...

[Nereid]

The whole "You don't need this anymore because now you got enough RAM" is an argument made from complete technical ignorance anyways. It should be obvious to anyone who knows even a tiny bit about what is inside a computer - DRAM, video RAM, cpu-cache, the different busses, that need to transport all that data... and finally, (graphical) processors that can only process N bits per second.... anyone who knows this, must simply laugh at people saying "uh, look now i have enough RAM! No need for efficient memory usage anymore!".

Well, your right in some way, but wrong in some other. Developing software is an expensive task. Modern software depends on frameworks and is very complex compared to software ten or more years ago. So you have to make a decision: get the most out of the hardware and optimizing ram usage, performance and so on or just tell the user to add a few gigs more. Ok, what is the price for let's say 8 GB ram? A few hundred to a few thousand dollar (it depends on the hardware). And what does it cost to reduce the memory usage of an application? Let us assume two developer spending three months of time for it. Each of them has a salary of 80,000 dollar per year. So optimizing costs 40,000 dollar and that's not including the possibility of new bugs that have to be solved later. And unfortunately those developers were needed for other tasks and and you can't hold your deadlines if you spend time for optimizing... another 50,000 dollar spent for external support, additional meetings with the customer, lawyers,...

Do you still think, it would be best to use less ram? I hope no.

So it's not technical ignorance. It's just economic efficiency.

Edited July 20, 2014 by Nereid

[westamastaflash]

Well, your right in some way, but wrong in some other. Developing software is an expensive task. Modern software depends on frameworks and is very complex compared to software ten or more years ago. So you have to make a decision: get the most out of the hardware and optimizing ram usage, performance and so on or just tell the user to add a few gigs more. Ok, what is the price for let's say 8 GB ram? A few hundred to a few thousand dollar (it depends on the hardware). And what does it cost to reduce the memory usage of an application? Let us assume two developer spending three months of time for it. Each of them has a salary of 80,000 dollar per year. So optimizing costs 40,000 dollar and that's not including the possibility of new bugs that have to be solved later. And unfortunately those developers were needed for other tasks and and you can't hold your deadlines if you spend time for optimizing... another 50,000 dollar spent for external support, additional meetings with the customer, lawyers,...

Do you still think, it would be best to use less ram? I hope no.

So it's not technical ignorance. It's just economic efficiency.

Exactly. One of the first rules of software development is that premature optimization is a bad thing. I would guess that if the version of the product is at 0.24, significant optimization gains may be made around 0.7 or 0.8.

[sp1989]

I really need my ATM! I know you are working on it Im just letting you know that I really need my ATM. Currently in my life right now this ATM is just as important as this ATM......

[Starwaster]

Figured another report and logfile couldn't hurt. Though I didn't see any reports with my issue. One was getting hung up on the new image files, and another had 64-bit errors from ATM's dll. I didn't have either of those issues (yet). I run too many mods...

As for getting stuck on the new image files, I posted a workaround solution for that. Unfortunately it involves ignoring the entire Squad folder because there is no way to selectively ignore just the Agencies folder.

But it does work, with the caveat that the Squad files will not get compressed.

A second solution that allows Squad files to be processed, would be to manually convert all of the *_scaled.truecolor to another format, such as PNG. (and then to remove the *.truecolor files)

[sidfu]

game always has a chance to hang on files even in stock ive had it happen a few times normaly with a fresh install. when u hang on a png or such u can remove the folder its in start game once u get to the start screen start a random sandbox then exit game and re putting the file back in. this normaly fixes it long as its not a MM file issue.

[Furious1964]

Any chance on an ETA on when this will be updated? Sorry to ask, btw.

[Borklund]

I'd like to know what bogs KSP down so much on CPU power to where an AMD 2.5Ghz 7550 socket AM2 dual core starts to choke on it around 250~300 parts in a scene. A Phenom II 550 dual core socket AM3 doesn't fare much better.

Monsters like this one are very laggy on the Phenom II and pretty much impossible to to do a thing with on the 7550. Gotta get me a faster/newer AM3 CPU at least quad core.

http://www.cpubenchmark.net/compare.php?cmp[]=77&cmp[]=332&cmp[]=2275

You're running on half a decade old hardware, or 5-6 generations old hardware in computer processing terms. That's ancient in human terms.

[agises]

I managed to make the plugin work, is dirty but works:

1-delete all .truecolor textures from GameData\Squad\Agencies (of course make a backup 1st)

2-edit agents.cfg in the same dir and change all logoScaledURL entries removing the _scaled so ie: "logoScaledURL = Squad/Agencies/R&D_scaled" becomes "logoScaledURL = Squad/Agencies/R&D"

3-run the game with atm as normal, enjoy

note the logos will look a little ugly now, but at least for me is ok...

Salud.