Some lesser-known bits of info for addon developers

[NovaSilisko]

Gonna be posting some random bits of info here that people might find useful - usually fairly obscure stuff.

1. FlagDecal

Put simply, this module lets you put your current mission flag onto a part. You just need a specific mesh that's UV'd correctly. The flag textures are imported from 256x160 and scaled up to 256x256, so it's as simple as just importing a random flag texture and stretching it to fit on the target mesh. Then, put this part module into your cfg:

MODULE
{
    name = FlagDecal
    textureQuadName = the name of your mesh in unity
}

And hey presto, you have a flag showing up on your spacecraft.

2. Docking port IDs

I haven't looked into many mod cfgs, but a number of the ones I have haven't taken advantage of this when it would be very useful. So, for docking port modules, the cfg entry looks like this:

MODULE
{
    name = ModuleDockingNode
    referenceAttachNode = top
    nodeType = size1
}

See that "nodeType = size1" entry? That doesn't actually have to be size#. It can be anything you want, then you can make ports that only connect to ports of that same ID, for your own docking systems. No way to make non-androgynous (requires two parts, which can only attach to eachother) ports yet, though.

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!

More shall come as they're thought of/remembered/invented! Feel free to suggest anything, yourself.

Edited June 11, 2013 by NovaSilisko

[Greys]

I'd imagine TGAs would win out simply because the are compressed and CPUs are faster than HDDs (so this logic doesn't apply to SSDs).

MBMs can be ungodly huge sometimes, especially if there's a lot of them. The gigabyte or so of MBMs from the stock parts take so long to read off a not super fast drive far outstrips any compression time afterwards. I took out a bunch of stock parts and most of the stock IVAs, and it reduced my ksp-boot time by minutes.

[NovaSilisko]

Yeah, there was a plan to start transferring all the stock parts either internally to the game, leaving the cfgs exposed, or just using the TGA textures. Dunno the status of it though.

[sumghai]

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. However, they 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 actually 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!

Looks like I'll have to switch from PNGs in my next release.

[Lack]

Looks like I'll have to switch from PNGs in my next release.

I think I'll have to switch to TGAs, it'll take a fair bit more work though, my fault perhaps for having so many parts.

NovaS, Is there any word from the Unity developers regarding if/when the bug may be fixed?

[NovaSilisko]

Not a clue, rob mentioned it had to do with the WWW asset loading inside unity but I don't know the technicalities of it or if it's being fixed.

[Lack]

Ah, that's a pity.

Also, I don't suppose it would be possible to post a couple of screenshots of one or two stock part's textures? Don't need the whole texture, I'd just like to be able to nick a few hex codes for the shades of the colours (even if they're ball park figures), so I (and presumably others) could get parts to match the stock ones a bit better (as I really like your part's style, your work with that Orion model especially).

[N3X15]

Not a clue, rob mentioned it had to do with the WWW asset loading inside unity but I don't know the technicalities of it or if it's being fixed.

http://forum.kerbalspaceprogram.com/showthread.php/29176-A-lesson-learnt-about-UnityEngine-WWW-and-the-file-uri?p=360219&viewfull=1#post360219

Also a number of posts on the Unity forums. It's hard to debug, as it appears randomly and on any platform.

[Greys]

It really would be helpful if somebody could put some numbers to this format thing, I just made some TGAs for my mod, and they're not a bit bigger, they're 16 times bigger (than PNG), which is still better than 25 times larger for the MBMs. I just find it really hard to believe that increasing the disk read time by 16x will reduce the import time to 1/16th or less. Btw, this is based on 1024x1024 sheets.

Also because image files are easily the largest in any format out of any addon, I feel that if every addon listed on spaceport was increased by roughly 16x, the servers would cry. Especially if that mod was B9, which would then be nearly a gig instead of 73.5MB total uncompressed. Considering the 1.2GB issue which seems to be irrespective of compression, it seems untenable.

[NovaSilisko]

Which TGA format are you using? TGA_Uncompressed is pretty big.

Edit: Updated the TGA entry a little. TGA_Compressed isn't very big, TGA_Smallest is even more compressed but lower quality. At TGA_Compressed, a 1024x1024 texture is roughly 2.5 MB. The larger the areas of solid color in the texture, though, the smaller the file size - a normal map with large flat areas of color can be down as low as several hundred kilobytes. For example, a texture here is 1024x1024 but only 166 kb in size.

I will admit that they are still larger than PNGs, but PNGs import insanely slow with this bug. Bobcat's soviet pack for example takes (and I timed it) sixteen minutes to import... It also depends heavily on the computer - an SSD for example will, naturally, load it much faster. I would rather have a relatively long one-time download than 16 minutes of loading time at every startup.

Edited June 11, 2013 by NovaSilisko

[BobCat]

NovaSilisko

Yep. Its too much time. )) Need change to TGA.

I have question about flagdecal.

i have this in unity

this in cfg

...and this ingame

What im make wrong?

[Lillegre]

OK; any idea on where the mudflation is coming from in PNG --> MBM conversion in unity. I am making parts with tiny PNG textures, like 82KB, after exporting from unity, the MBM is now 769kb??

Regards

Lil'

[Greys]

MBMs are effectively uncompressed, PNGs are compressed very effectively, PNGs will always be a lot smaller than MBMs

[EndlessWaves]

Are there not other methods of loading you could use for PNG? Maybe Texture2D's LoadImage function in conjunction with a BinaryReader?

[Lillegre]

MBMs are effectively uncompressed, PNGs are compressed very effectively, PNGs will always be a lot smaller than MBMs

My bad then, I re-read the tut on hex editing to a MBM file and realised that the starting point was a PBM, not PNG. I'll stop optimising my texture assets then

Next silly question, can you make multiple assets call the same texture for if you have say 6 models all using the same texture, or is the same texture loaded 6 times?

Regards

Lil'

Edited June 12, 2013 by Lillegre
Spelling Monster...

[BobCat]

Next silly question, can you make multiple assets call the same texture for if you have say 6 models all using the same texture, or is the same texture loaded 6 times?

Check KSP debug menu

[NovaSilisko]

I have question about flagdecal.

It displays as blank in the VAB at the moment - it should show up in-game. To make it less apparent in the VAB I just apply a blank flag texture to it.

[Nuke]

i think uncompressed tga is (((w*h*bpp)/8)+18) bytes in size (unless its indexed color which requires space for a color table, probibly 256*32/8 bytes, but im not sure). compression is rle so its not very good with noisy textures, if you have a lot of contiguous colors it can take it down a lot, but if there is a lot of noise (like all my textures), compression suffers. but wherever there is compression there is the time neccisary to decompress it. im actually quite surprised that were not using dds textures with dxt1 compression, which makes smaller files and they can be used by the video hardware in their compressed state (so its just load and go).

Edited June 23, 2013 by Nuke

[Tiberion]

Well, moving from PNGs to Compressed TGAs is takes 4x to 5x more disk space for the average texture in NovaPunch, and thats just on the older textures, I'm not sure how big of a leap the size will be on the new large textures that frizzank has been doing.

This just plain sucks.

[frizzank]

Has anyone tested the ram comparison between using png's and uncompressed textures?

[minime]

It's highly unlikely to make any difference in the amount memory used by the images when loaded in the game.

[jaked122]

I was just wondering if it was possible to combine a command module and an engine.

I tried to do so, with the module information here: http://pastebin.com/n3YkWEZV.

It does add it to the launch bar, but it does not provide any real thrust, is this possible?

Or am I wrong in my methodology?

[Greys]

Engine models contain a specific non-visible object called a thrustTransform which is in a specific place and pointing a specific way, this is how KSP knows where to apply the engine's thrust force to, and in what direction. No stock command pod contains a thrustTransform so they cannot be made into engines alone; you should be able to include additional models via MODEL{}ing to circumvent the problem, or make a custom command pod that does have a thrustTransform.

Other than that, the things that make an engine an engine and a command pod a command pod are entirely separate, there should be no conflict with having a single part be both.

[MainSailor]

I was just wondering if it was possible to combine a command module and an engine.

I tried to do so, with the module information here: http://pastebin.com/n3YkWEZV.

It does add it to the launch bar, but it does not provide any real thrust, is this possible?

Or am I wrong in my methodology?

cBBp's Dragon Rider capsule has monoprop powered engines integrated in, so it is definitely possible. I don't know if you're working with Unity but maybe you could see where he added the ThrustTransform elements. The fuel usage is just as simple as adding the resource spec in the cfg file.

[Greys]

So I've been trying to run the numbers based off a the last log in my dev instance, this is not a clean KSP instance, it does not contain all of /GameData/Squad/ and it does contain HexCans, ModuleManager with ModularFuelSystem, and KerbTown with my runway only.

I set out by building a regex search to filter out all the junk I don't need and separate it all into a comma separated value format.

I don't pretend to be good at regex but this is my expression: \[LOG \d{2}\?P<minute>\d{2})\?P<seconds>\d{2}\.\d{3})\] (?P<type>Load\(.*\)|Config\(.*\)|PartLoader\: .*):? '?(?P<file>.*)'?

Then I moved the results into Excel and added in a column calculating the time that passed between an entry and the one after it.

Here's the synopsis of my results as far as event type goes

I can also say at this point that it takes roughly 2 seconds to complete all of the events involving HexCans, and about 48 seconds to load the textures in /GameData/Squad/, while there's 40~ hexcan parts and ~200 Squad .cfgs, so this doesn't make a ton of sense to me.

Also, All of HexCans textures are PNGs, and they take less than two seconds total, clearly format is not an issue for me.

Edit:

Edited August 29, 2013 by Greys