[1.0.X - Experimental] [On Hold] FusTek Station Parts (WIPs on GitHub)

[Starwaster]

Also, I should point out that this isn't really an issue specific to this mod, as many other mods also show a large jump in memory usage when parts are selected in the game. I have a gut feeling that it may be that KSP really doesn't like file formats like PNG or TGA since literally every texture squad uses is in MBM format which appears to have a small memory usage increase, while I can't think of a single part mod that uses MBM over TGA or PNG and most suffer from large memory usage.

Well the way to go is to turn this from speculation to emperical evidence. Convert those textures into mbm and re-test. remove old texutures first. Unity editor can do that but I don't know how other than to export them with some object. I dont know of a mass converter....

[wasmic]

Edit the corresponding fustek_station_icon_*_texture.png files?

PS regarding previous memory usage discussion, this mod is the last one to blame for memory wastage.

A quick check in the GameData folder reveals that this mod uses not one, but TWO 4096*4096 files. That is a whole lot of memory usage. It's equivalent to 32 1024*1024's. And it's especially jarring when you think about the fact that they can be scaled down to 2048*2048 without significant loss of detail.

[Mihara]

A quick check in the GameData folder reveals that this mod uses not one, but TWO 4096*4096 files. That is a whole lot of memory usage. It's equivalent to 32 1024*1024's. And it's especially jarring when you think about the fact that they can be scaled down to 2048*2048 without significant loss of detail.

only two for how many parts?

[wasmic]

only two for how many parts?

A lot, but not that many, seeing as most of them are pretty much identical, except for a logo and the viewport placement. Especially when the 4096*4096 textures are half blank, which means that it could have used 4096*2048 instead. Oh, and there are 23 parts in this pack, which means that there are fewer parts than 1024*1024 textures. And *1024 textures are already unnecessary for most parts. Besides, my point was not that there were too few parts to warrant so large textures. My point was that such large textures don't really help texture resolution at all, and that it could be scaled down to 2048*2048 with negligible loss of texture quality.

[SpacedInvader]

Well the way to go is to turn this from speculation to emperical evidence. Convert those textures into mbm and re-test. remove old texutures first. Unity editor can do that but I don't know how other than to export them with some object. I dont know of a mass converter....

I've been looking for a way to do this for the last couple of days. Unfortunately, I dont' have and have never used Unity editor, so that option would have a learning curve for me and anyway, I'm not 100% sure that I would have all of the parts necessary unless there really isn't anything to worry about beyond the model and the texture.

A quick check in the GameData folder reveals that this mod uses not one, but TWO 4096*4096 files. That is a whole lot of memory usage. It's equivalent to 32 1024*1024's. And it's especially jarring when you think about the fact that they can be scaled down to 2048*2048 without significant loss of detail.

A lot, but not that many, seeing as most of them are pretty much identical, except for a logo and the viewport placement. Especially when the 4096*4096 textures are half blank, which means that it could have used 4096*2048 instead. Oh, and there are 23 parts in this pack, which means that there are fewer parts than 1024*1024 textures. And *1024 textures are already unnecessary for most parts. Besides, my point was not that there were too few parts to warrant so large textures. My point was that such large textures don't really help texture resolution at all, and that it could be scaled down to 2048*2048 with negligible loss of texture quality.

I honestly think these could go all the way down to 512x512 without too much loss of detail, at least the stock textures. Even the alternate textures could be stepped down to 2048 or even 1024 without too much issue. I'm not entirely sure this is the only issue however, as I've shipped my PNG planet textures for RSS as 4096 texture maps, 8192 height maps, and 2048 normals, 16 of which combine to about 120MB of disc space and about 400MB of in-game memory use and planet color maps are always loaded while in game. If it were just the texture size, that would mean that the 300MB increase from one FusTek part would translate to around 2.1GB of use for the 7 always on color maps and even more if you add in normals and height maps. That being said, I will try reducing the textures tonight to see what the result is. I'm sure it will help some, but the question is just how much. My experience with PNGs so far in this game is that a reduction in texture size does decrease memory usage, but not as significantly as you would expect.

EDIT: So as a quick test, I down sampled the 4096 normal down to 1024 which cut the memory increase of adding one of the parts down from 350MB to 150MB and this is with virtually no loss in appearance.

Edited June 15, 2014 by SpacedInvader

[sumghai]

Hmm, the last few responses are quite a bit to take in - let's see...

I'll start off by saying that I don't use Load on Demand, so I can't guarantee any results from their use, and nor will I dedicate time and effort to optimizing specifically for LoD.

Also, I should point out that this isn't really an issue specific to this mod, as many other mods also show a large jump in memory usage when parts are selected in the game. I have a gut feeling that it may be that KSP really doesn't like file formats like PNG or TGA since literally every texture squad uses is in MBM format which appears to have a small memory usage increase, while I can't think of a single part mod that uses MBM over TGA or PNG and most suffer from large memory usage.

I've been made aware of this a while back:

3. PNGs import VERY slowly, due to a Unity bug

I strongly recommend using one of the TGA or MBM settings for your exported textures instead of PNG. TGAs are just as editable, but slightly larger. For TGA I recommend the TGA_Compressed setting, TGA_Uncompressed is almost as large as an MBM. Have not tested TGA_Smallest but I believe the texture quality of that is fairly low. TGAs import a lot faster as they're using the same compression method as unity does normally

[citation needed]

. MBMs are not editable and are mostly uncompressed, so are quite large, but import the quickest. However, I haven't done direct time comparisons, so that would help a lot if somebody could get some direct statistics on the loading times for these different formats!

A significant number of add-on authors use PNG because they're easier to edit and preview, and I myself use Adobe Fireworks to allow me to quickly make changes to PNG textures during development.

I previously used to also offer TGA and MBM alternative texture formats, but I no longer see the point in maintaining them when this is essentially still an alpha parts pack that may or may not see significant changes with each revision anyway.

I'm still hoping that Unity and KSP does fix the PNG loading issue, but if that doesn't happen and FusTek becomes feature and scope complete, then maybe - just maybe - I'll consider switching to a different texture format.

A quick check in the GameData folder reveals that this mod uses not one, but TWO 4096*4096 files. That is a whole lot of memory usage. It's equivalent to 32 1024*1024's. And it's especially jarring when you think about the fact that they can be scaled down to 2048*2048 without significant loss of detail.

only two for how many parts?

A lot, but not that many, seeing as most of them are pretty much identical, except for a logo and the viewport placement. Especially when the 4096*4096 textures are half blank, which means that it could have used 4096*2048 instead. Oh, and there are 23 parts in this pack, which means that there are fewer parts than 1024*1024 textures. And *1024 textures are already unnecessary for most parts. Besides, my point was not that there were too few parts to warrant so large textures. My point was that such large textures don't really help texture resolution at all, and that it could be scaled down to 2048*2048 with negligible loss of texture quality.

I honestly think these could go all the way down to 512x512 without too much loss of detail, at least the stock textures. Even the alternate textures could be stepped down to 2048 or even 1024 without too much issue. I'm not entirely sure this is the only issue however, as I've shipped my PNG planet textures for RSS as 4096 texture maps, 8192 height maps, and 2048 normals, 16 of which combine to about 120MB of disc space and about 400MB of in-game memory use and planet color maps are always loaded while in game. If it were just the texture size, that would mean that the 300MB increase from one FusTek part would translate to around 2.1GB of use for the 7 always on color maps and even more if you add in normals and height maps. That being said, I will try reducing the textures tonight to see what the result is. I'm sure it will help some, but the question is just how much. My experience with PNGs so far in this game is that a reduction in texture size does decrease memory usage, but not as significantly as you would expect.

EDIT: So as a quick test, I down sampled the 4096 normal down to 1024 which cut the memory increase of adding one of the parts down from 350MB to 150MB and this is with virtually no loss in appearance.

As I've explained on numerous occasions, the two 4096*4096 PNGs are common texture files shared by all of the parts in the pack, the IACBMs notwithstanding. They are currently quite large because I've been wanting to do a complete overhaul of the art style for quite some time, and I'm still not convinced that heavily reducing the resolution won't make the currently less-than-stellar textures look even worse. And while it's technically true that I currently only need half that area, there are two reasons I won't be changing my mind anytime soon:

- Mipmap generation generally doesn't like non-square textures. If I had a non-square texture as wasmic insists, Unity will simply double the rectangle's height so that it turns back into a square, and then generate the mipmaps as usual, thus negating any hypothetical memory savings from wasmic's proposal.

- I reserved the other half for future parts like solar panels, payload rack holders, procedural trusses, etc. If I started out with a rectangular texture and UV mapped my existing parts accordingly, I'll have to redo all the existing maps all over again if I expand the texture for the new parts.

You are certainly welcome to reduce the sizes of the textures as much as you please in your own setup, but that's not something I'll offer support for.

[SpacedInvader]

LOD (Load on demand) doesn't need anything to be optimized, all it does is shift texture handling away from unity until the texture in question is called by the program. Basically, it just keeps the game from having to load every texture into memory at a small cost in access time. As a result, the memory that KSP shows as an increase when loading a part is usually just to normal amount of memory that part would have taken, but is not shown normally because its mixed in with all of the memory allocation for the other parts. Ultimately, the mod allows you to have a ton of part mods without getting OOM errors before you even get to the main menu as it only loads the textures you actually use on a ship / part.

Anyway, I understand the concept of having a common texture for everything (it's a pretty good idea, just like the interchangeable models), I think we're just making the point that there are still large for what they are accomplishing. That being said, I also understand your reasons for keeping them large for the time being, I was just trying to make the point that even shrinking the pngs can save hundreds of MB of used memory. I will shrink them for myself in the short term and look forward to something more optimized when this is finally completed.

I've also done some poking around with squad's parts and have found that they seemed to have capped their texture resolution at 2048, with many of their parts being as low as 512, which is probably why they have such a low impact on memory usage compared to the textures used in many part packs which are often 4096. I would also point out that KSP decompresses compressed files like PNGs so even if they are small on disk, they can still be large when loaded into the game's allocation of memory.

Edited June 16, 2014 by SpacedInvader

[sharpspoonful]

Well, than as an aside from all of that: how would I go about making a model edit to the resupply part? I want to remove the curved structural part from the top of it and replace it with a functional 2m ICBM docking port. I've tried in the past and it never loads.

[Starwaster]

Well, than as an aside from all of that: how would I go about making a model edit to the resupply part? I want to remove the curved structural part from the top of it and replace it with a functional 2m ICBM docking port. I've tried in the past and it never loads.

Looking at the part config, deleting this bit should do it

    
    MODEL
    {
           model = FusTek/Station Parts/Parts/modelKarmonyEndRing
        position = 0.0, 1.09375, 0.0
           scale = 1.0, 1.0, 1.0
    }

Then, in the VAB slap on your docking port.

Edit: Instead of editing the original part, you should use a module manager config...

@PART[FusTekResupplyModule]
{
	!MODEL,1{}
}

Edited June 18, 2014 by Starwaster

[sumghai]

Important update regarding the add-on conflicts in the FusTek Resupply Part:

It seems that the latest version of Modular Fuel Tanks (v5.0.3) now works properly with TAC Life Support - life support resources are now correctly displayed in the VAB/SPH, and any vessels using the Resupply part will now load properly in the flight scene again.

I would appreciate it, however, if other users could please update their MFT plugins, test this out themselves and report back on their results.

[orangewarning]

Do those kirs docking modules need docking ports on them?

and can clamp o trons dock with the docking ports in this pack?

[falken]

Kirs docking modules do need a docking module added.

I would imagine so on the clamp o trons. Give me 5 minutes and I will tell you.

e: No such luck. Stock clamp-o-trons will not mate with the IACBM docking nodes. They don't even physically look right due to the clamp-o-trons collar being a fair amount narrower than the IACBMs.

Edited June 18, 2014 by falken

[Ar_Taq]

Do those kirs docking modules need docking ports on them?

and can clamp o trons dock with the docking ports in this pack?

Yes, the docking module needs docking ports.

Yes, I am able to get them to dock together with no problems. Just make sure that they are the same size docking port, because you can't dock a 1.25m to a 2.5m port. (Exception: The KW Rocketry Docking Port)

[Starwaster]

e: No such luck. Stock clamp-o-trons will not mate with the IACBM docking nodes. They don't even physically look right due to the clamp-o-trons collar being a fair amount narrower than the IACBMs.

They're not supposed to be compatible with clamp-o-trons. IACBM docking ports are only meant compatible with each other.

[sumghai]

Do those kirs docking modules need docking ports on them?

and can clamp o trons dock with the docking ports in this pack?

Kirs docking modules do need a docking module added.

I would imagine so on the clamp o trons. Give me 5 minutes and I will tell you.

e: No such luck. Stock clamp-o-trons will not mate with the IACBM docking nodes. They don't even physically look right due to the clamp-o-trons collar being a fair amount narrower than the IACBMs.

Yes, the docking module needs docking ports.

Yes, I am able to get them to dock together with no problems. Just make sure that they are the same size docking port, because you can't dock a 1.25m to a 2.5m port. (Exception: The KW Rocketry Docking Port)

They're not supposed to be compatible with clamp-o-trons. IACBM docking ports are only meant compatible with each other.

To clarify:

- The Kirs Docking Module is simply a pressurized crew tunnel, to which you will need to add actual docking ports on both ends; I named it the Docking Module simply because it was inspired by the Mir Docking Module / ISS Pirs Docking Module.

- The IACBMs are not supposed to be compatible with the Clamp-O-Trons.

[Ar_Taq]

Could this be a 64-bit error?

No, I'm just an idiot. The part that I was testing it with is the same. Sorry!

Edited June 19, 2014 by Ar_Taq

[sumghai]

Could this be a 64-bit error?

Since I don't run the community hack for the 64-bit Unity, I cannot confirm this.

[orangewarning]

Hey sumghai,

I was wondering if something like that would work?

[sumghai]

Hey sumghai,

I was wondering if something like that would work?

http://i.imgur.com/NVOL2YF.png

That...looks odd.

You should only use the 2.5m docking ports with the flat-ended modules, and the 1.25m ports with the taper-ended modules - trying to make a "universal" docking port for the sake of convenience is strongly discouraged.

[falken]

Sumghai, do you have any plans on making 3.75 modules as well? For larger skylab style stations. Just curious (I love your current modules!)

[sharpspoonful]

Infernal robotics truss sections work well with some minor fiddling

[sumghai]

Sumghai, do you have any plans on making 3.75 modules as well? For larger skylab style stations. Just curious (I love your current modules!)

Probably not - it's a whole new system and set of dimensions I need to get acquainted with, and the current 2.5m diameter modules are close enough to the real-life USOS segments to satisfy my original focus.

[montyben101]

Is there a way i can not use CLS since i really dont want it but still want to use fustek parts

[sharpspoonful]

Unless you have TAC-LS installed, you will not have any life support systems to worry about. Sumghai simply made a Module Manager file to support TAC-LS, Deadly Reentry, and Modular Fuel Tanks. As for CLS, it makes sense to have it and Crew Manifest installed, otherwise you wont be able to move any Kerbals from module to module

[J.Random]

As for CLS, it makes sense to have it and Crew Manifest installed, otherwise you wont be able to move any Kerbals from module to module

Or you may simply install Crew Manifest without CLS, which will work perfectly and you won't be limited by parts from other packs which may not have CLS config.