WWW in WebPlayer vs. standalone

Questions & Answers
1

I am trying to load a binary data file from an external server via the WWW class. This works well in the editor, but in the WebPlayer the download never finishes and its progress is always 0. Are there any limitations in the WebPlayer that I should be aware of(eg. can't load binary files or similar)?

I am aware that there was a similar question here, but that was solved by prefixing the url with http:// which I already did.

Edit: I found out that the problem has to do with the way I'm waiting for the download to finish. Instead of yielding the www result to wait for it to finish I just do something like that:

WWW download = new WWW(url);
while(!download.isDone){}
Debug.Log(download.data);

This doesn't work in the Webplayer somehow. I don't know why, but it does work when I change this to the usual:

WWW download = new WWW(url);
yield return download;
Debug.Log(download.data);

The problem with that however is that the download takes place in a piece of code that isn't a MonoBehaviour, so I can't start a Coroutine (i'm using c-sharp) for the download, or at least that would require some major refactoring, which I'd like to avoid if possible. Any ideas on this?

Oh, and as some people already asked, yes I am sure, that the server is up, reachable and serves the file as it's supposed to, because the exact same code with the exact same url is working fine in editor and standalone. Plus it doesn't seem to be a problem with a certain file type, as this happens with html xml midi text and custom binary files. (I tried them all because I ran out of ideas...)

3

A while ago I made a small script to manage this, although it wasn't because I ran into the same problem you're having. I just wanted to be able to start and wait for WWW requests from any script, whether or not it's a MonoBehaviour. I ended up writing a script which creates a temporary GameObject for the purposes of using coroutines to monitor the downloads.

So, very roughly speaking, I have a script called "WWWLoader" which is a central script for handling all downloads and http requests. In that script is a static property called 'instance'. This is a property in the c# sense. It uses the singleton pattern to create a single instance of itself, although while it does so, it creates a new temporary gameObject to attach itself to. So the first time 'instance' is used, it gets set up correctly for use, and any subsequent times, it uses the reference that was already made, like this:

private static WWWLoader s_Instance = null;

public static WWWLoader instance
{
    get
    {
        if (s_Instance == null)
        {
            GameObject obj = new GameObject("_WWWLoader");
            s_Instance = (WWWLoader)obj.AddComponent(typeof(WWWLoader));
        }
        return s_Instance;
    }
}

Now, we have an active GameObject, so we can use coroutines on it. So, we can set up a static method which calls on the instance to start a coroutine that waits for the WWW request to complete:

public static void Load(string url)
{
    WWW www = new WWW(url);
    instance.StartCoroutine(WWWLoader.instance.WaitForLoad(www));
}

And then we need to implement the corresponding instance method (which is the actual coroutine function):

public IEnumerator WaitForLoad(WWW www)
{
    yield return www;

    if (www.error != null)
    {
        Debug.Log("WWWLoader Error - \"" + www.url + "\" : "+ www.error);    
    } else {
        Debug.Log("WWW completed!");
    }
}

This now means that - from any kind of script, including non-monobehaviours - you can call this static function (no need to instantiate anything yourself) to start a WWW download:

WWWLoader.Load(url);

This is an extremely simplified version of the script, for illustrative purposes. In practice, you would almost certainly want to add better error handling, an event/callback system to notify the original object which made the request when the download has finished, and possibly even a queue system if you are using it to download a sequence of requests. But I hope it gives you some pointers in the right direction!

2

Have you checked that the server is actually serving up the file that you're requesting? (eg, by trying the file url in your browser's address bar?).

Some servers (IIS) require that you explicitly set up the correct mime type for all types of files that you want to serve, so if your file has an extension that isn't yet set up with a correct mime type, the server will just act like the file isn't there to clients. This could be the problem.