List with obsolete API?

Unity Engine
1

Is there any info about obsolete API?
I can’t find anything in the ScriptReference about obsolete functions and their replacements :frowning:

e.g.:
The type or namespace name `ResourceRequest’ could not be found. Are you missing a using directive or an assembly reference?

2

The project converter automatically replaces obsolete API calls if you want, so you could let it do so and then diff to figure out what the changes were.

3

Hi.

I am one of the devs in charge of the automatic API updating infrastructure. I checked and did not find any configuration for this type. I’ll investigate more and get back to you.

1 Like
4

I also noticed that this class is missing. Which means, we can’t use Resources.LoadAsync currently.

5

This API was added in a patch release; unfortunately, it will not come back in 5.

6

ok… do you mean Resources.LoadAsync will not come back, or just ResourceRequest? Is there a new way of loading resources in the background?

7

Hi, after discussing with the engineering team, we found out that the introduction of the type ResourceRequest and the related method Resources.LoadAsync() were not well planned and were not meant to be public, so we’re going to mark them as obsolete in 5.0 (i.e, any code that uses it will at least generate a more informative compiler error).

The AssetBundle class should be used instead of Resources.

We’re sorry for any inconvenience caused.

Best

Adriano

8

Does that mean that all Resources methods and the Resources directory are obsolete, or just Resources.LoadAsync()?

Currently, for patching standalone games, the AssetBundle class uses some faraway temporary directory for the asset bundles it downloads and caches (certainly on Windows). It would be better if we could download patches to the game’s own directory structure. For standalone games that require patching, the current AssetBundle system isn’t perfect, it seems more tailored towards mobile and browser platforms.

9

Only Resources.LoadAsync() will be obsoleted (as error); the other Resources methods will still work (even though they may be eventually be obsoleted, but as warning, for 5.0).

Best

Adriano

10

As far as the Resources goes, thanks for the heads up on that, Adriano. I’ll make sure I don’t use any of them in future projects.

11

We use Resources.LoadAsync extensively in our Master Audio plugin, for pro users only.

Will there be a direct API replacement for Resources? I need to know how to retrofit our code to work in Unity 5 for when the deprecated Resource methods get removed. From what I understand about Asset Bundles (admittedly very little), they are not for the same scenarios as Resource files. Resource files would be loaded from the local device, and Asset Bundles would be loaded from a URL on the internet. Has that changed? Or are we totally losing the coolness of Resource files with nothing to replace it?

12

We need Resources.LoadAsync back… When it came out I was so happy because we really needed it. Asset Bundles are a pain. I really vote to keep Resources.LoadAsync in Unity 5… I don’t see why not.

13

I’m of the same mind. So far what I’ve seen of Asset Bundles, it’s a pain.

14

Yeah it’s not something anyone loves. Resources.LoadAsync is probably my favorite addition I saw in Unity 4. I see no reason for them not to support it.

15

If we get enough votes, could the decision be reversed?

16

Could we have more documentation and a good set of examples for using Asset Bundles in all circumstances; streamed, and cached. I’ve watched the Unite presentation a number of times, and it’s not much clearer on the fine points.

2 Likes
17

If enough people vote for it, I’m sure they’d reverse it. Problem is, nobody will know it’s gone till Unity 5 is fully released. Then people will complain, asking “Where’s LoadAsync?”. We probably have to wait till then.

18

My customers will know, I’ll tell them right now on my thread and tell them to post here.

19

This is absurd. Resources.LoadAsync was a HUGE feature, we’re so surprised by its removal. Loading resources in the background was quite an useful thing to do.

We were planning to upgrade to Unity 5 (that sexy 64-bit editor and the UI/Audio features are really appealing to us), but we should reconsider if that option is missing in the next Unity iterations.

2 Likes
20

We’re discussing what to do about this.

Bear in mind that the AssetBundle system has changed quite a bit in 5.0. I did a little experiment to see how difficult it would be to approximate the ‘Resources bundle’ - which, really, is just a special AssetBundle under the hood anyway - so as to get back an async-load behaviour. It turns out not to be too difficult:

  1. Tag the resources you want to load to be in a ‘resources’ bundle. You can do this via the UI (next to where asset labels are set up) or via the API.

  2. Create an editor script to build the asset bundle into the StreamingAssets folder. Something like this:

using UnityEngine;
using UnityEditor;

public class BuildAssetBundles {

    [MenuItem("Tools/Build Asset Bundles")]
    public static void Build()
    {
        System.IO.Directory.CreateDirectory (Application.streamingAssetsPath);
        BuildPipeline.BuildAssetBundles (Application.streamingAssetsPath, BuildAssetBundleOptions.UncompressedAssetBundle | BuildAssetBundleOptions.CollectDependencies);
        AssetDatabase.Refresh ();
    }
}

  1. Run the script via the Tools menu to build an asset bundle from your resources.

  2. Add a script to load and expose the bundle as a singleton:

using UnityEngine;

public class MyResourcesBundle
{
    private static AssetBundle _bundle;
    public static AssetBundle Get()
    {
        if (!_bundle)
            _bundle = AssetBundle.CreateFromFile (System.IO.Path.Combine(Application.streamingAssetsPath, "resources"));

        return _bundle;
    }
}
  1. Now you can pretty much swap “Resources.LoadAsync” for “MyResourcesBundle.Get().LoadAsync”:
using UnityEngine;
using System.Collections;

public class MyResourcesLoadTest : MonoBehaviour {

    IEnumerator Start () {

        var loadReq = MyResourcesBundle.Get ().LoadAssetAsync<Material> ("TestMaterial");
        yield return loadReq;

        GetComponent<Renderer> ().material = (Material)loadReq.asset;
    }
}

It’s not quite as automatic as Resources in the sense that you need to remember to run “Tools → Build Asset Bundles” when you change something in your resources bundle - but it also means that if you haven’t changed anything in the bundle, you can skip building it, making for a faster build time.

Also, once you grok this kind of thing, it’s much more flexible: you can pack your resources into different bundles and take control over loading/unloading them, to get substantially better memory usage than the built-in Resources bundle (which, IIRC, is entirely loaded at app startup and cannot be unloaded). Also, packing your resources into a larger number of smaller bundles allows you to get better build times by only rebuilding those bundles that you know have changed.

Is this a reasonable workaround for now?

2 Likes