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

[LameLefty]

Or you could just ignore my repeated suggestion to simply make a specific exclusion of the full file path to exclude.

[AlphaAsh]

...

Anyways, I suppose it's worth mentioning that I've tried my config in the RealChute folder as well... no dice. I'll give that global setting a try though, that's a good idea.

Ahhh, yeah we are misreading each other. That global setting is a proposal. Pretty sure it doen't exist.

EDIT - Erm sorry bout that Nitrous Oxide. I should use less short-hand and actually write full sentences.

Edited January 21, 2015 by AlphaAsh

[Nitrous Oxide]

Ahhh, yeah we are misreading each other. That global setting is a proposal. Pretty sure it doen't exist.

Derp, would be useful... lol.

@LameLefty: There's 3 icons, I don't think in theory that replacing the wildcard entry with 3 separate entries linking directly to the files will change anything... unless you've got a working config for RealChute, then by all means, please do share. Either way, here's the config I've been using (it works for every other icon, just not the 3 RealChute icons)...

ACTIVE_TEXTURE_MANAGER_CONFIG
{
	folder = RealChute
	enabled = true
	OVERRIDES
	{
		RealChute/Plugins/PluginData/.*
		{
			compress = false
			mipmaps = false
			scale = 1
			max_size = 0
			make_not_readable = false
		}

	}

}

I've had that in my ATM_configs folder, the RealChute folder and the RealChute/Plugins/PluginData folder... same result. It ain't workin'.

[mecki]

I'm also having problems with RealChutes Icon (as also stated in the RealChutes thread). I'm using nearly the same rule but no success – ATM seems to ignore the Plugins folder in any case (it doesn't even create any cache files for its contents) but resizes the icon anyway.

In the Git pull request I sent yesterday I added rules for all the icons of all the mods I'm using to be preserved and to preserve all icons in /Icons/ folders.

What I then found out surprised me again: I still need a config file for every mod that has a /Icon/ folder, even if there is nothing in there but the "enable" command. Otherwise the rule from the main config is being ignored…

Of course it would be nice for ATM if all mods would have their icons in a specific folder…

@Nitrous Oxide maybe you could also send a pull request with your rules or send them to bray or me to be included?

And another question: What about DDS textures (like the ones Real Solar System uses)? Are they also being resized by ATM? They also don't have their own cache files but even for 2048px textures they look unsharp to me…

Edited January 22, 2015 by mecki

[garithmar]

I keep getting the initial load times from ATM every time i load ksp. Its ..... Annoying, anyway to fix this?

[rynak]

I'm also having problems with RealChutes Icon

As stated in the realchute thread, this is not caused by ATM, because it happens even without ATM installed (and i also have another mod, where it happens without ATM). Instead, it probably is KSP itself downsizing the icon. It might not happen for stock icons and most other mods, because their icon textures are larger than neccessary (if that were true, it really would be ironic, because then KSP would basically force modders to use wasteful texture sizes).

In other news, still unable to use ATM because of the heap crashbug. Yes, i'm running with the extended address space switch, and without ATM i have about 1,5GB free. It probably is not related to memory size, but memory handles. Perhaps too many threads.

Edited January 23, 2015 by rynak

[adsii1970]

Nice. This is pretty much what I expected to happen. I kept getting the excuse that people didn't have room for my Cloud and City Lights mod. Shouldn't be as much of an issue now.

Just wanted to say thanks for the great mod. This has tremendously sped up my game; before I found this particular one I was using the one recommended by B9 (it simply showed up as "Texture Reduction" in my GameData folder). While it was good and did what I needed it to do, yours seems to free up more memory resources.

As a side note, I was already using your cloud mod and have some really great pics with your clouds in them; however, I am hesitant to use the city lights component because of my personal hang-up. Why have city lights when there are no cities? I know that it is a pretty narrow argument, but nothing beats reentering the atmosphere having city lights at the terminus between day and night, knowing there will be no city "footprint" once the same spot is in the daylight. As I have said, it's my personal opinion about the city lights...

Again, thanks for the hard work!

[mecki]

As stated in the realchute thread, this is not caused by ATM, because it happens even without ATM installed (and i also have another mod, where it happens without ATM). Instead, it probably is KSP itself downsizing the icon. It might not happen for stock icons and most other mods, because their icon textures are larger than neccessary (if that were true, it really would be ironic, because then KSP would basically force modders to use wasteful texture sizes).

In other news, still unable to use ATM because of the heap crashbug. Yes, i'm running with the extended address space switch, and without ATM i have about 1,5GB free. It probably is not related to memory size, but memory handles. Perhaps too many threads.

What address "space switch" are you talking about?

[rynak]

In 32bit mode, windows normally reserves 2GB for "kernelland", which is where the system and all the drivers are residing. The remaining 2GB are "userland" which is where all the normal programs run in - like KSP.

So, KSP in 32bit mode actually has just 2GB available.

However, windows can be told to only reserve 1GB for "kernelland" and 3GB for "userland"... of course, this is only feasible if the drivers you're using aren't overly bloated (else they might actually need 2GB). The method to tell windows to use 1/3GB instead of 2/2, is different for winXP and win7. Just google it - not hard to find. A hint though: set it up as a second boot option, instead of replacing the default one - this way, if your system no longer boots properly (i.e. because of bloated drivers running out of memory), you can still boot into the standard 2/2GB setup.

EDIT: Seperate from the above is another thing not many users know about: 32bit CPU's are actually capable of addressing more than 4GB of memory! For reasons we would rather not think about though, MS disabled this by default - it can be enabled with another switch in a configfile. The problem however is, that a program has to be compiled for this, to make use of the extra memory. With this setting being disabled and hidden by default, almost no app is compiled to make use of this - i guess this back then was a good selling point for 64bit CPUs and new Windows versions >.> XP technically was capable of breaking the 4GB barrier, but MS needed a reason to sell Vista and Seven.

Edited January 23, 2015 by rynak

[BudgetHedgehog]

Slightly wrong there - KSP on a 32bit OS can only use about 2Gb, due to the OS limitations (that can be changed as above). 32bit KSP can actually access about 3.5Gb before it crashes and to do that, you need to either have a 64bit OS or tell it it can use more (if you have a 32bit OS). I think you're confusing 32bit KSP and 32bit OS. You can't switch between x86 and x64 OS, but you can change how much RAM 32bit KSP is allowed to use (provided you have an x86 OS. x64 OS will always allow more RAM usage than x86 KSP can actually use).

[rynak]

I wasn't confusing both, but apparently unaware that 64bit OS's running 32bit apps, allocate 3,5GB userland.

By the way, a 32bit OS can let KSP use 3GB, but as mentioned in my post, it requires an option in the OS configfiles.

[BudgetHedgehog]

I wasn't confusing both, but apparently unaware that 64bit OS's running 32bit apps, allocate 3,5GB userland.

By the way, a 32bit OS can let KSP use 3GB, but as mentioned in my post, it requires an option in the OS configfiles.

Yeah, the first is one of the most common causes for crashes. x86 KSP will always meet its limit before x64 OS will stop limiting it. I force OpenGL for my x86 KSP and still use about 2Gb - without it, using DX9, I run about about 3.4 odd Gb. Doing pretty much anything crashes it. And yeah, as I mentioned in mine, the x86 OS-enforced limit can be changed by allocating more VRAM. I agree with you on that, yes

[LameLefty]

What's worse is that as of 0.90, KSP is actually more sensitive to memory and crashes much earlier for me than it used to. In prior versions back to 0.19, I could skate up to that 3.4 - 3.5 gigabyte edge, and sometimes right along side of it for hours, before crashing. With 0.90, I've yet to see my KSP session get beyond 2.95 gigabytes before a crash-to-desktop.

This is on OS X 10.10, just as a reference point.

Edited January 23, 2015 by LameLefty

[rynak]

@lamelefty: That's because it now uses much more memory. I suspect it has to do with the upgradable facilities, but that's just speculation - haven't looked into assets to be sure.

[LameLefty]

@lamelefty: That's because it now uses much more memory. I suspect it has to do with the upgradable facilities, but that's just speculation - haven't looked into assets to be sure.

I don't think that makes sense, actually. The KSP process itself used to consume 3.4-ish gigabytes easily, sometimes for an extended period, before crashing. Now when I have crashes, the process is a generally frozen and using no more than 2.9 gigabytes.

[rynak]

You mean with mods or without? Changes to the mod setup of course will change memory consumption. I was talking about memory at startup without mods. Between 0.24 and 0.90, it went up by almost 400mb for me.

[Nitrous Oxide]

I don't think that makes sense, actually. The KSP process itself used to consume 3.4-ish gigabytes easily, sometimes for an extended period, before crashing. Now when I have crashes, the process is a generally frozen and using no more than 2.9 gigabytes.

I've noticed that too... KSP doesn't seem to be grabbing the full 3.5GB anymore... And this is Windows, so the issue is OS-independent it seems.

0.25 I could load a GB of mods in full res, now I have to set it to 1/2 res just to make it through load... and that's with ATM... any way to make full use of this 2GB VRAM I have?

Edited January 23, 2015 by Nitrous Oxide

[LameLefty]

You mean with mods or without? Changes to the mod setup of course will change memory consumption. I was talking about memory at startup without mods. Between 0.24 and 0.90, it went up by almost 400mb for me.

It doesn't matter - with or without mods at startup isn't what I'm talking about.

I'm talking about the total usage of the KSP process on my system after it's been running for a couple hours. It formerly maxed out just under 3.5 GB and could be stable there for hours until a stray memory leak caused a crash.That has changed with 0.90 for me.

[Rebelgamer]

I've seen the same thing LameLefty, KSP is definitely more crash prone at lower total memory used than previous versions were, mine mostly start at around 3.1GB, though I use the dx11 switch instead of opengl for the slight speed boost(gl loads more into vram though).

[rynak]

An update on the heap crashbug:

I've just downloaded the source from github. I was expecting having to delve into complex code, but just to see if compiling works right, i did a compile with the unmodified source, then launched KSP.

No crash!

What happened? I'm not sure but i have two candidates: v4.3 was released a month ago. The last commit on github also is about one month old, so one would think the source on git is identical to 4.3. Well, if that is so then why are there commit comments about 4.4beta? If that is no mistake, then 4.3 might have been released from a different branch, because 4.4 was considered beta - yet already fixed a crashbug.

The other possibility is that i might have compiled it with no multithreading, without doing so on purpose (the devs use MS tools, while i use CSDevelop, so my IDE might have skipped some directives in the project file).

In any case, either the heap issues have been fixed, or it indeed is a matter of compilation settings (my bet is on threading - too many heap handles).

Edited January 24, 2015 by rynak

[etcetc]

Anyone have insight on the following crash information?

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

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

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

I am able to load my game up once (the very first slow load) but if I try to restart it it consistently gives me that error.

[rynak]

Anyone have insight on the following crash information?

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

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

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

I am able to load my game up once (the very first slow load) but if I try to restart it it consistently gives me that error.

That is an overly complicated way of the game telling you, that ATM tried to use something that does not exist (aka nullpointer).

EDIT: From the func names, it seems to be looking for a texture it thinks is there, but actually is missing.

[Starwaster]

An update on the heap crashbug:

I've just downloaded the source from github. I was expecting having to delve into complex code, but just to see if compiling works right, i did a compile with the unmodified source, then launched KSP.

No crash!

What happened? I'm not sure but i have two candidates: v4.3 was released a month ago. The last commit on github also is about one month old, so one would think the source on git is identical to 4.3. Well, if that is so then why are there commit comments about 4.4beta? If that is no mistake, then 4.3 might have been released from a different branch, because 4.4 was considered beta - yet already fixed a crashbug.

The other possibility is that i might have compiled it with no multithreading, without doing so on purpose (the devs use MS tools, while i use CSDevelop, so my IDE might have skipped some directives in the project file).

In any case, either the heap issues have been fixed, or it indeed is a matter of compilation settings (my bet is on threading - too many heap handles).

Another possibility is that one was compiled for the wrong .net version. It should be 3.5

It would likely still compile against 4.0 and even execute, but not necessarily stably.

Just a possibility

[wjy123456918]

Landlord Hello, I am from Chinese users, I use your mod，but it eject "too many heap sections "the pop-up window how to solve? ;

My English is not very good, Sorry for the Inconvenience

[AlphaAsh]

As stated in the realchute thread, this is not caused by ATM, because it happens even without ATM installed (and i also have another mod, where it happens without ATM). Instead, it probably is KSP itself downsizing the icon. It might not happen for stock icons and most other mods, because their icon textures are larger than neccessary (if that were true, it really would be ironic, because then KSP would basically force modders to use wasteful texture sizes).

Good catch rynak. I think you're onto something there. I've used enough GUI code in KSP to know for a fact that if a 'texture' is larger than the space allocated for it, it does indeed get squashed and if it's too small, it gets stretched.

EDIT - And nope. Huh. The latest version of RealChute has a toolbar icon that's 1kb and 38x38. That shouldn't be a problem. There is a FilterIcon_selected.png which is 52kb (!) which is 32x32. If that's stretched to fill a 38x38 allocation, then it could end up blurry but is that the toolbar icon? Don't know, I don't use RealChute. Regardless, I think you're right that it isn't ATM at fault here and that an exclusion file in that folder does actually work.

Edited January 24, 2015 by AlphaAsh