What is this?
Unloading 2 unused Assets to reduce memory usage. Loaded Objects now: 361.
System memory in use: 99.0 MB.
Unloading 0 Unused Serialized files (Serialized files now loaded: 4 / Dirty serialized files: 4)
and how do I stop it from happening?
The Assets are not unused, Unity just doesn’t know that I’m using them. They’re being accessed from a custom .dll of mine.
The app is working in the editor and failing in built exe.
Interesting bug. Can you please submit a bug report and PM me with the case number? Attaching a repro case to the report would be especially helpful.
Edit - oops, didn’t notice the “working in editor but not in build” caveat. What happens if you include the assets in a folder named “Resources”?
thats not really a unity bug, but a bug with your code.
If you want to use unity assets, you must have a reference to them, even if you use them externally.
So what you need to do is have a small manager class that holds references to all externalized media, that way they will not get unloaded.
Would be as if you went out, used delete on a C++ obj and expect a dll to work with it, without blowing up (thats basically the same thing you do here cause by not having a reference on a unity class, you delete it defacto as the engine internal asset ref count reaches 0 - assets are not freed and held basing on the .NET ref count!)
How is it not a bug in Unity? I’m fully open to the possibility of bugs in my code, but if something worked in 2.6.1 (editor and built), works in the 3.b5 editor, but does not work in 3.b5 built exe, that screams out BUG. I thought one of the major design criteria of Unity was “if it works in the editor, it will work in built code.”
I didn’t go into too much detail above, but that’s what I have constructed. I have a “don’t destroy on load” global object script that has a boatload of Assets assigned to variables. On Awake() I assign each of these Assets to a static class’s matching variables inside the .dll. This assignment should (definitely does) increase the .net refcount of the objects. The dll remains in the same assembly space as Unity, so there is no magic barrier where .net refcounts would be lost. There is someplace in Unity that does separate refcounting on objects that is not bookkeeping properly. The memory manager (as noted by the error) then cleans them up. And it does this only in a built exe, not in the editor.
Well, not to be pedantic, but it’s nothing like that at all. I see what you’re getting at, dreamora, but the analogy is false. .net memory management and c++ memory management are completely different. The analogous c++ item would be an old-school MFC/ATL smartpointer, that does internal refcounting. It’s not a 100% match, as smartpointers were each separately managed and the .net GC does centralized management.
Anyhow, I chose to use an external .dll to superclass GUIX in order to add localization/internationalization support and a richer eventing model (amongst other things). The other reason for a .dll was to also have a WinForms dev tool to construct all of the data in my text-heavy, multi-language game.
Perhaps this architecture is not necessary, and everything can be done in script. Poking through the 3.b5 build files, I see Assembly-CSharp.dll. Looking in Reflector, I see all of my script data types, &c. So one question is, where is the analogous .dll for the editor (I would bet that it is in memory, but it might be cached somewhere in the file system), so I could reference it for my separate dev app while still providing the internationalization and eventing model for the UI? I suppose I could reference the built .dll. Once the code is somewhat stable, the relevant pieces will not cause too much of a hassle…
Ethan, what is the significance of the Resources folder? Are there different assent management rules for items stored there?
Oh, and thanks for the feedback and discussion, and for the new version. U3 is freaking amazing!
bump