Why is part loading like it is?

[raxo2222]

Hah I think every heavily modded game is memory hog and will crash, when they are 32 bit. I think best solution is go fully 64 bit.

We have this ATM mod here: http://forum.kerbalspaceprogram.com/threads/59005-0-23-5-Release-3-1-Active-Texture-Management-Save-RAM-without-reduction-packs!

Bud did you knew about Load on Demand plugin, which is available here: http://forum.kerbalspaceprogram.com/threads/73236-WIP-Loading-textures-only-as-required ?

[Deadweasel]

If Active Texture Management can compress the textures from inside the program, so can KSP. Then have it save the textures alongside the original files. When it loads it can check to see if the compressed file is out of date or missing, and if so re-generate it. Otherwise it only has to work with the more efficient compressed texture. It's still easy for modders because they don't have to create odd formats (though I don't see why there shouldn't be a tool to let them) and efficient.

Well, while that's true, it's also more work that the game has to do on loading. The idea is to remove as much work as possible beforehand, so load times are quicker, RAM load is lighter, and performance is faster.

Active Texture Management does work, but it's just a bandage, not a final solution. Currently, it does the compression every time you load the game, so it actually freezes for a minute or so while it does that. Now, if all of the textures were already compressed, (and if the game were prepared to work with them natively), that wait would be completely removed.

Also, .dds and .dxt aren't "odd" formats. Those are the compressed and graphics card-native formats I've been talking about all along, and there are tools out there to let designers pre-compile their textures. As already mentioned, nVidia offers a free Photoshop plugin that allows it to read/write the .dds format.

[includao]

this should be top priority, even with all the limitations of the Unity engine.