A lesson learnt about UnityEngine WWW and the "file://" uri

[TriggerAu]

This is a bit of a Public Service Announcement, so forgive me if I post it in the wrong location. In the Kerbal Alarm Clock I use quite a few images/textures and these get loaded when the plugin spawns. After mucking around with directories, etc I found that I could use code like the below to load these from subfolders inside plugindata into Unity.Texture2D Objects.

public static void LoadImageIntoTexture(ref Texture2D tex, String FileName){
    WWW img1 = new WWW(String.Format("file://{0}Icons/{1}", PlugInPath, FileName));
    img1.LoadImageIntoTexture(tex);
}

This worked great for me, and lots of people, but there were a number or people who found that when the plugin was loading the game would "freeze". On investigating the plugin would eventually load, but would take about 3-5 secs per file (regardless of size), after some fiddling and with the assistance of some very helpful KSPites who helped me test on machines with the issue I figured that this was some form of client thing around the use of the file:// uri.

In the end I went back to using the KSP.IO.File.ReadAllBytes and the Unity.Texture2D.LoadImage functions - just means all my images are in the one folder, and noone has these pauses in the loading..

I never did get to the bottom of why some clients seem to have a timeout of some sort occuring for each loaded image, but thought I'd share this in case any coders see this behaviour and wonder if its a new thing.

UPDATE - From other thread - User Nando found a working solution! was posted elsewhere, but have edited this as well in case people end up here.

Disable any and all network devices on your computer which are not currently in use. Instructions on how are below. Many thanks to Nando for finding the solution!

http://windows.microsoft.com/is-is/windows-vista/enable-or-disable-a-network-adapter

http://levynewsnetwork.wordpress.com/2011/12/01/windows-7-default-internet-connection-choice/

Edited June 11, 2013 by TriggerAu
Adding fault details - so people dont have to read the whole thread

[EndlessWaves]

Firewall settings perhaps? If WWW is acting as a web/network client and loading via localhost or similar then it could well be security settings interfering.

Have you tried PartReader.BitmapReader.ReadTexture2D(string path)? I haven't tried it, but I know the model reader in the parent class works.

[JeBuSBrian]

Performance in Unity drops the more separate texture files you use. This is because for every material (texture in this case), Unity has to make a new draw call. If all of your objects use the same material, all of your objects will get batched together into a single draw call. I would suggest combining all of your icons / textures into a single larger texture.

It has also occurred to me that this may play a small part in the overall poor performance of KSP in general. I don't believe the parts can properly batch in the Unity engine, because Squad has for some reason forced each part to use its own texture. Anyway, that has nothing to do with you, sorry.

[TriggerAu]

I did try a bunch of different things - and I think security settings/IEZones is probably the cause. Even if it is something like that I can't control how people run their clients (unless I run a botnet ), so more wanted to post this in case a dev is using it and wasn't aware that some people do see an issue, or if they get reports of issues at the loading screen with their plugin and this may help them find a resolution so more people use their plugin.

[TriggerAu]

Performance in Unity drops the more separate texture files you use. This is because for every material (texture in this case), Unity has to make a new draw call. If all of your objects use the same material, all of your objects will get batched together into a single draw call. I would suggest combining all of your icons / textures into a single larger texture.

I'll definately look into this one, thanks

[SkyRender]

This particular Unity issue has been getting a lot more attention lately since now the main game itself is exerting this anomalous behavior for the unlucky few. We've got an active effort now to track down what's causing it. So far the best results we've gotten are from looking at what Windows is actually doing during that lag via Process Monitor. The results are interesting (also, huge; there's about 670MB overall of data between two different versions of KSP with a total time recorded of about 1 minute and 30 seconds; it's kinda ridiculous).

KSP 0.20.2 no-mods Process Monitor file

KSP 0.19.1 Process Monitor file with HOME, DEMV ANT, and KER installed

The main interesting similarity between these are that Kerbal Engineering Redux parts in 0.19.1 are exhibiting the same issue as stock files in KSP 0.20.2 are. I can't confirm for certain that KER is loading files the same way as mentioned in this topic, but given that the symptoms are so exact, it seems likely.

[OrbitusII]

The Unity WWW class is primarily used to access webpages, not files. Unfortunately its functionality is severely limited to either grabbing images or unparsed code, not the actual webpage as users will see it. It can be used to access files that are present on the user's computer, but compared to KSP's default system it's not as effective (as evidenced by the OP).

[TriggerAu]

The Unity WWW class is primarily used to access webpages, not files. Unfortunately its functionality is severely limited to either grabbing images or unparsed code, not the actual webpage as users will see it. It can be used to access files that are present on the user's computer, but compared to KSP's default system it's not as effective (as evidenced by the OP).

Some indications from a number of people show that the new KSP loading system "may" be using this method for resource loading - So "maybe" this is the new default system, thus SkyRender's comments. For more you can read http://forum.kerbalspaceprogram.com/showthread.php/32897-Excessive-start-up-loading-times - most reports from these people show the same behavior seen in my first post.

Yes, I know theres some assumptions here, that do need to be confirmed.

[jheriko]

Unfortunately its functionality is severely limited to either grabbing images or unparsed code, not the actual webpage as users will see it.

Its a matter of perspective. It lets you do everything that is possible with HTTP GET and POST... which is most of the internet. making web requests should be distinct from rendering... you get the same data for a webpage that your browser would get for instance.

i'm glad to see this works. I just wrote a pile of code with HTTPWebRequest and am now refactoring to use UnityEngine.WWW instead...

About loading times, I've heard that everything needs loading up front? Is this really true? Surely we can create textures on the fly? In which case a multithreaded/timesliced background loading type solution is completely feasible. (I may have a past history of assembling these with such 'impossible' timescales as 'a week' or 'two days' )

My existing solutions are all native code that runs across every platform so they will probably be awkward to repurpose and wrap into C# for KSP use but there is no reason why similar can't be remade in C# very quickly. The key is just being able to load the textures etc. on the fly - all the threading/timeslicing stuff is less important afaik and rewriting it using nice handholdy C# should be a breeze. there is probably some lockless job queue thing already laying around.

I know very little about Unity, just learning right now for the sake of modding KSP. Shame we don't have a good, clean, portable interface for the mods... just thinking of the needless overhead of 'do nothing' mods makes me light headed... 5000 super late binding C# calls are not healthy.

[jheriko]

Okay, so now I have used this I am worried about people using it without understanding what they are doing and why this can create huge stalls.

UnityEngine.WWW starts an asynchronous process when instantiated. To dumb that down a bit - it makes a thread on 'new'.

What this means for you is that you are now writing timesliced or multi-threaded code, and you must account for the case of a single hardware thread where you need to yield to allow execution - implementing efficient spin-waits is a subject all of its own, but luckily the C# devs did it for you. Unfortunately that mechanism doesn't work in KSP :/

EDIT: just realised i missed the 'linking information' - file i/o is always at least partly asynchronous and thread-safe! which explains why not doing this will result in stalls...

EDIT++: actually the code I gave actually doesn't work in KSP, although it works fine in general unity/.net... for whatever reason KSP can't load SpinOnce from mscorlib.

Edited June 6, 2013 by jheriko
missing info

[SkyRender]

So a fix was found for this problem. For mod makers using this command who have had users complain about long lag times, suggest to them that they disable all network connections on their system that are inactive. Apparently Unity's handling method for this particular command has to contend with all possible connections, even ones that are disabled. Once it's down to only active connections, the load times drop back down to normal levels.

[TriggerAu]

So a fix was found for this problem. For mod makers using this command who have had users complain about long lag times, suggest to them that they disable all network connections on their system that are inactive. Apparently Unity's handling method for this particular command has to contend with all possible connections, even ones that are disabled. Once it's down to only active connections, the load times drop back down to normal levels.

Thanks for the update SkyRender. This is great to know, and makes a lot more sense than some form of random hardware issue.