[WIP] Loading textures only as required

[Cocox]

Exactly what I'm getting.

Same here, yet it works!

Without it and active tex management my 32bit ksp would crash. Only with LOD, KSP uses 2-2.5 GB of RAM..

Bless you for this mod!!

[BananaDealer]

Ok, so I got LoD to work with my x64 install. As far as I can tell there was a problem with KSO textures causing the crashing. That or the x64 version of LoD still implements ome sort of memory restriction...

I'm now getting the good old VAB crash at times, usually when selecting a new part from the editor...

[BananaDealer]

Finally managed to get it stable-ish... Still crashing at times, but not too often.

Old bugs are making their comeback however. There's still "missing" black textures and textures fail to get prepared sometimes, resulting in this:

[Alewx]

Hey Faark, got some strange LoD behaviour at some parts of SSE.

Some textures are black while all others are ok, and the Log didn't show something I would notice.

Might it be that LoD suffers from x64 like so many other mods?

[BananaDealer]

Hey Faark, got some strange LoD behaviour at some parts of SSE.

Some textures are black while all others are ok, and the Log didn't show something I would notice.

Might it be that LoD suffers from x64 like so many other mods?

That's a known bug. It's been around since v3 and it's not just with SSE parts. I've posted about it a couple times now (literally in the post above yours)...

[Alewx]

That's a known bug. It's been around since v3 and it's not just with SSE parts. I've posted about it a couple times now (literally in the post above yours)...

Maybe I'm colorblind but for mee the screenshot looks like pink/missing textures but not black

Well if it is not related to x64, than it is Faarks most loved extermal TGA code.

[BananaDealer]

Maybe I'm colorblind but for mee the screenshot looks like pink/missing textures but not black

Well if it is not related to x64, than it is Faarks most loved extermal TGA code.

That's a different bug, the part textures getting not prepared properly at start up; resulting in "naked" models... I've already given screens for the black textures a while ago.

[Alewx]

Hmm strange what mod did you have the black textures in 23.5?

[Guest]

Home Grown Rockets experimental (all .tga textures) and Space Shuttle Engines (orange tanks) turn black with LoD.

[BananaDealer]

Hmm strange what mod did you have the black textures in 23.5?

HGR, Shuttle Engines, mostly. Those two I can remember since the bug's persistent in .24...

Also Procedural Fairings- the inside of the fairings is black. That's not much of a problem but still...

I think there were others as well but I can't remember them right now...

[Alewx]

HGR, Shuttle Engines, mostly. Those two I can remember since the bug's persistent in .24...

Also Procedural Fairings- the inside of the fairings is black. That's not much of a problem but still...

I think there were others as well but I can't remember them right now...

That sounds good because I have it with the exact same mods, that makes it a systematic bug.

Faark are you still there, please donn't abandon us, you do so awesome work.

[Guest]

It's been here since 0.23.5, so that's not 64bit, that's just plain old LOD issue. In the meantime, modders could move away from the .TGA format for the LOD users benefit. .PNG is just as good.

[Jim Kernan]

I'm using 64 bit KSP. After loading the dependencies the mod requires, it crashed a couple times. On a hunch I removed ATM and right now it seems to be working fine. I'm going to add a few more mods and see what happens.

[BananaDealer]

I'm using 64 bit KSP. After loading the dependencies the mod requires, it crashed a couple times. On a hunch I removed ATM and right now it seems to be working fine. I'm going to add a few more mods and see what happens.

LoD doesn't "require" any dependencies. ATM is just for when you already have a massive modlist. You don't need either to run the other. And yes, currently there's some problems between ATM and LoD...

[Jim Kernan]

I should have been more clear. What I meant was these:

"Requirements

- Windows & DirectX9 only, for now.

- Latest .NET Framework (4.0) installed.

- Visual C++ Redistributable Packages for Visual Studio 2013 (vcredist_x86.exe) installed."

I suppose these are requirements as opposed to dependencies. Anyway, I was getting an error on startup before adding the Visual C++ requirements. Afterwards I didn't get the previous error message but it started crashing at every load. Removing ATM fixed it. I'm going to double check with the latest ATM just to be sure.

Edit: Yeah even with the newest ATM it crashed. I'm going to keep LOD for now and see what else it may not like.

Edited July 25, 2014 by Jim Kernan

[BananaDealer]

I should have been more clear. What I meant was these:

"Requirements

- Windows & DirectX9 only, for now.

- Latest .NET Framework (4.0) installed.

- Visual C++ Redistributable Packages for Visual Studio 2013 (vcredist_x86.exe) installed."

I suppose these are requirements as opposed to dependencies. Anyway, I was getting an error on startup before adding the Visual C++ requirements. Afterwards I didn't get the previous error message but it started crashing at every load. Removing ATM fixed it. I'm going to double check with the latest ATM just to be sure.

Edit: Yeah even with the newest ATM it crashed. I'm going to keep LOD for now and see what else it may not like.

Oh. Well remember that if you're using LoD with the x64 version of KSP, you need the x64 vcredist (same download link, just choose the other option).

And as I said, the current official version of ATM, which is the "old" pre-.24 version, has problems with KSPx64. If you absolutely want ATM, there's an unofficial(and I cannot stress this enough) 0.24 recompile somewhere in the latter posts in ATM's thread...

[BananaDealer]

I've got another one for the bug-pile... Probably related to the whole "textures not loading" thing.

Some textures getting loaded properly, others getting their pink undergarments revealed...

The LoD display shows as all textures having been prepared and then loaded...

Trying to "Refer All" again doesn't seem to do much...

[MK3424]

Hey Faark, i have maybe a small request:

You know that it takes time to convert all textures to the low res right?

What about using a text file that acts as a checklist: when the plugin loads up, it checks the checklist and the textures, when there isn't a texture on the checklist, then it makes a low res texture and add it's name to the list.

and when a texture is not found but is on the checklist, you'll delete the low res texture that isn't been used anymore.

I hope this can help, and i hope you will understand what i'm talking about.

[Hurry- Starfish!]

MK3424: Doesn't it already do that?

[eygc]

Love the mod, absolute lifesaver. Lets me run many more mods than without it! This bump is for the black texture bug, however. Are you still working on this plugin?

[Gaalidas]

I also still use this thing. I loaded up KSP without it a while back while trying to fix a major bug in my installation and regretted it immediately when I hit the main menu and everything was extremely stuttery. I have encountered none of the reported problems and have not experienced any crashes due to this plugin. My only issue is that when reloading teh database (in this case with the Module Manager reload button) the mod tried to reinitialize and failed to create a native bridge. This is probably because it already had its native bridge and was using it since the game was currently displaying something that was under the management of this plugin. I did not get the chance to see if it still worked after the reload unfortunately. Just something for others to be aware of.

[MK3424]

MK3424: Doesn't it already do that?

I don't think so: it always makes new textures when booting ksp up, regardless if they are already made.

[BananaDealer]

I don't think so: it always makes new textures when booting ksp up, regardless if they are already made.

It shouldn't... The way LoD works is that, upon starting KSP with LoD for the first time (i.e- you just installed it or are missing the LoadOnDemand folder and its' contents), it generates a thumbnail for all the textures you have at that point. From then on, it uses those thumbnails to substitute their respective textures when they're not "required" (a part using that texture getting loaded). Any texture you add after the initial "round up" (I'm calling it that) gets added to the list with its' own thumbnails.

It shouldn't try to make new thumbnails of textures that already have them. Unless the texture itself got changed, in which case it will replace the old thumbnail with a new one...

LoD will however make new thumbnails (again- replacing older ones) if you load-up KSP at a lower/higher res than the current thumbnails used...

[djnattyd]

I keep getting a "LoadOnDemand has detected a problem and might not work. Failed to create NativeBridge, even legacy mode!" message. Having a look through the thread I seem to have the requirements to run it, I even went and got the vcredist_x86 to be sure only for it to tell me that I already have it installed.

I am using the very latest ATM version that was compiled for .24 and I've turned off compression in Texture Replacer so... Anyone got an idea what's wrong?

[Bit Fiddler]

could you implement KSP-AVC support so we will know when this gets updated?