Addressable loading 10x slower than normal + Unknown Assembly error + Feedback

My game is quite large and has some resources that I don't need until later in the game, and they aren't tied to a particular scene. I load these resources asynch during loading screens.

I was putting these assets into a /Resources directory, which worked fine until I tried making a build and found out that you can't have more than 4GB of Resources.

The easy solution, which in hindsight I should have gone with, is to just put everything into a master scene load that scene as a substitute asset bundle. However, I am stubborn and have wasted two days trying to get a better solution.

Which brings me to the new Addressable system. In FastMode everything works fine, load speed is good, so far so good. I can't load synchronously, which is a huge design flaw and created a lot of bad architecture but that's another topic.

The topics for this post...

First issue: Building assets for packed play mode, I'm spammed with

Code (CSharp):

1.  
2. Unknown Assembly ModV1
3. UnityEditor.Build.Content.ContentBuildInterface:GetPlayerDependenciesForObjects(ObjectIdentifier[], BuildTarget, TypeDB)
4. UnityEditor.Build.Pipeline.Tasks.CalculateAssetDependencyData:Run() (at Library\PackageCache\com.unity.scriptablebuildpipeline@1.5.2\Editor\Tasks\CalculateAssetDependencyData.cs:107)
5. UnityEditor.Build.Pipeline.BuildTasksRunner:Run(IList`1, IBuildContext) (at Library\PackageCache\com.unity.scriptablebuildpipeline@1.5.2\Editor\Shared\BuildTasksRunner.cs:50)
6. UnityEditor.Build.Pipeline.ContentPipeline:BuildAssetBundles(IBundleBuildParameters, IBundleBuildContent, IBundleBuildResults&, IList`1, IContextObject[]) (at Library\PackageCache\com.unity.scriptablebuildpipeline@1.5.2\Editor\ContentPipeline.cs:118)
7. UnityEditor.AddressableAssets.Build.DataBuilders.BuildScriptPackedMode:DoBuild(AddressablesDataBuilderInput, AddressableAssetsBuildContext) (at Library\PackageCache\com.unity.addressables@1.1.7\Editor\Build\DataBuilders\BuildScriptPackedMode.cs:132)
8. UnityEditor.AddressableAssets.Build.DataBuilders.BuildScriptPackedMode:BuildDataImplementation(AddressablesDataBuilderInput) (at Library\PackageCache\com.unity.addressables@1.1.7\Editor\Build\DataBuilders\BuildScriptPackedMode.cs:90)
9. UnityEditor.AddressableAssets.Build.DataBuilders.BuildScriptBase:BuildData(AddressablesDataBuilderInput) (at Library\PackageCache\com.unity.addressables@1.1.7\Editor\Build\DataBuilders\BuildScriptBase.cs:60)
10. UnityEditor.AddressableAssets.Settings.AddressableAssetSettings:BuildPlayerContentImpl() (at Library\PackageCache\com.unity.addressables@1.1.7\Editor\Settings\AddressableAssetSettings.cs:1608)
11. UnityEditor.AddressableAssets.Settings.AddressableAssetSettings:BuildPlayerContent() (at Library\PackageCache\com.unity.addressables@1.1.7\Editor\Settings\AddressableAssetSettings.cs:1590)
12. UnityEditor.AddressableAssets.GUI.AddressableAssetsSettingsGroupEditor:OnBuildPlayerData() (at Library\PackageCache\com.unity.addressables@1.1.7\Editor\GUI\AddressableAssetsSettingsGroupEditor.cs:239)
13. UnityEditor.GenericMenu:CatchMenu(Object, String[], Int32) (at C:\buildslave\unity\build\Editor\Mono\GUI\GenericMenu.cs:121)
14.  

ModV1 among other assemblies are used by my game to hold external code.

I created a link.xml to try to include this, not sure if it's needed, the docs aren't really very helpful as to when to use link.xml, why I would use it, or even how to use it or where to put it.
<linker>
<assembly fullname="ModV1" preserve="all"/>
</linker>

Anyway, if I ignore the error and run the game it does appear to load.

Here is part of link.xml at Client\Library\com.unity.addressables\StreamingAssetsCopy\aa\Windows\link.xml

<assembly fullname="ModV1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null">
<type fullname="ModV1.AI2.AI2Ambience_SV1" preserve="all" />
<type fullname="ModV1.AI2.AI2AmbienceAnimationEventListener" preserve="all" />
<type fullname="ModV1.AI2.AI2AudioTrigger" preserve="all" />
<type fullname="ModV1.Source.AIAllianceConditionalEvent" preserve="all" />

Second issue:
What I'm actually loading is a custom ScriptableObject that holds a List<GameObject>.I can actually load it, the problem is instead of a list of 39 GameObjects, it's a list of 39 null pointers.

Third issue: loading takes 10X longer in packed play mode vs. local! This totally defeats the point of loading asynch during loading screens since the total time is longer.

I don't care about loading game data from remote systems, content updates, whatever. I just want to get around the 4 GB limit. How can I load resources dynamically that
1. Is fast
2. Doesn't duplicate the resource (which Addressables and AssetBundles do?
3. Doesn't have a size limit (Which Resources does)?

 

"what version of addressables and the editor are you using?"

It was the latest version at the time I wrote the post, I downloaded it the day before. Probably 1.1.7. Editor 2019.2.0f1

"What if you hand edit our generated link.xml and add preserve="all" to it?
<assembly fullname="ModV1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" preserve="all">"

I can try again, but already reverted the code in favor of using scenes as resources bundles. I load the scene that contains a game object, that contains a reference to my scriptable object. Because scenes are not ready the same frame they are loaded, I had to find every place in the game code that used a resource, which I could formerly load blocking, and change it to use IEnumerator.

"Is it actually a List<GameObject> or is it List<SomeComponentType>? "
List<GameObject>. I wanted to clarify this, because even if it was List<SomeComponentType> that would work if I used Resources, or used my current method of using Scenes as a fake asset bundle. I need to be able to have scripts on my assets.

"I'm not sure exactly what you're comparing. Packed vs Fast mode? Packed vs having things in Resources? 99% of your dev can probably be done in Fast Mode. "
Comparing packed vs. resources

 

Has there been any change on this? I have a similar issue and this error fires 800 times when I generate bundles. Unity 2019.2.17, Addressables 1.7.5.

Code (CSharp):

1.  
2. Unknown Assembly Rewired_Core
3. UnityEditor.AddressableAssets.Settings.AddressableAssetSettings:BuildPlayerContent()
4. PlatformBuilds:BuildDLCStatic(BuildTarget) (at Assets/Scripts/PlatformBuilds.cs:369)
5. PlatformBuilds:<BuildDLC>b__15_0() (at Assets/Scripts/PlatformBuilds.cs:339)
6. UnityEditor.EditorApplication:Internal_CallDelayFunctions()
7.  
8.  

 

I am now seeing this after updating to addressable 1.8.3 from 1.7.5 while on unity 2019.3.9f1

Unknown Assembly DOTween
UnityEditor.GenericMenu:CatchMenu(Object, String[], Int32)
Unknown Assembly Sirenix.Serialization.Config
UnityEditor.GenericMenu:CatchMenu(Object, String[], Int32)

 

I'm having the "Unknown Assembly DOTween" as well since 1.8.3 on Unity 2019.3.11
Not sure if this is harmless yet as I haven't made a build yet. But if it is, I'll revert back to 1.7.5
Here's the stacktrace from the editor log

Code (CSharp):

1. Unknown Assembly DOTween
2. UnityEditor.Build.Content.ContentBuildInterface:GetPlayerObjectIdentifiersInAsset_Injected(GUID&, BuildTarget)
3. UnityEditor.Build.Content.ContentBuildInterface:GetPlayerObjectIdentifiersInAsset(GUID, BuildTarget)
4. UnityEditor.AddressableAssets.Settings.AddressableAssetEntry:CreateCatalogEntries(List`1, Boolean, String, IEnumerable`1, Object, HashSet`1) (at Library\PackageCache\com.unity.addressables@1.8.3\Editor\Settings\AddressableAssetEntry.cs:664)
5. UnityEditor.AddressableAssets.Build.DataBuilders.BuildScriptFastMode:GatherAssetsForFolder(AddressableAssetEntry, AddressableAssetsBuildContext) (at Library\PackageCache\com.unity.addressables@1.8.3\Editor\Build\DataBuilders\BuildScriptFastMode.cs:163)
6. UnityEditor.AddressableAssets.Build.DataBuilders.BuildScriptFastMode:ProcessGroup(AddressableAssetGroup, AddressableAssetsBuildContext) (at Library\PackageCache\com.unity.addressables@1.8.3\Editor\Build\DataBuilders\BuildScriptFastMode.cs:138)
7. UnityEditor.AddressableAssets.Build.DataBuilders.BuildScriptBase:ProcessAllGroups(AddressableAssetsBuildContext) (at Library\PackageCache\com.unity.addressables@1.8.3\Editor\Build\DataBuilders\BuildScriptBase.cs:119)
8. UnityEditor.AddressableAssets.Build.DataBuilders.BuildScriptFastMode:BuildDataImplementation(AddressablesDataBuilderInput) (at Library\PackageCache\com.unity.addressables@1.8.3\Editor\Build\DataBuilders\BuildScriptFastMode.cs:90)
9. UnityEditor.AddressableAssets.Build.DataBuilders.BuildScriptBase:BuildData(AddressablesDataBuilderInput) (at Library\PackageCache\com.unity.addressables@1.8.3\Editor\Build\DataBuilders\BuildScriptBase.cs:74)
10. UnityEditor.AddressableAssets.Build.AddressablesBuildScriptHooks:OnEditorPlayModeChanged(PlayModeStateChange) (at Library\PackageCache\com.unity.addressables@1.8.3\Editor\Build\AddressablesBuildScriptHooks.cs:59)
11. UnityEditor.EditorApplication:Internal_PlayModeStateChanged(PlayModeStateChange)
12. UnityEditor.EditorApplication:set_isPlaying(Boolean)
13. UnityEditor.Toolbar:TogglePlaying()
14. UnityEditor.Toolbar:DoPlayButtons(Boolean)

 

I see the same errors every time I hit Play. I was sure it was something specific to this project only. Also using DOTween and Odin. Surprising to see it's a common issue.

Addressables 1.8.3
Unity 2019.3.9

 

It seems to prevent me from building the bundles so I'm reverting back to 1.7.5

 

Same here

 

I decided to revisit addressables and it is still the case that Addressables doesn't work when your project uses DLLs.

In the case the name of my DLL is ModV1



When I double click the error it goes to this line of code:

var referencedObjects = ContentBuildInterface.GetPlayerDependenciesForObjects(includedObjects, m_Parameters.Target, m_Parameters.ScriptInfo);
in CalcualteAssetDependencyData.cs line 107

Using Addressables 1.1.10 with Unity 2019.3.11f1

In the Addressables Window I click Build / Build Player content then wait for an hour to get this result.

 

@unity_bill

Previously you suggested "What if you hand edit our generated link.xml and add preserve="all" to it?
<assembly fullname="ModV1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" preserve="all">"

Referring to: "E:\Work\EmpireOfEmber\Client\Library\com.unity.addressables\StreamingAssetsCopy\aa\Windows\link.xml"

My own DLLs are listed twice:
<assembly fullname="ModV1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null">
and
<assembly fullname="EmpireOfEmber, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null">

I added preserve="all" per your suggstion
<assembly fullname="EmpireOfEmber, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null" preserve="all">
<assembly fullname="ModV1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" preserve="all">

However, upon hitting Build / Build Player E:\Work\EmpireOfEmber\Client\Library\com.unity.addressables\StreamingAssetsCopy\aa\Windows\link.xml is deleted by Unity, therefore my changes are lost.

If there is some other place I should creating a new link.xml let me know.

 

I've filed this as a reproducible bug
https://fogbugz.unity3d.com/default.asp?1243008_u0mordu61ousc0o5

 

Any updates on this issue? Seems like a pretty major regression for Addressables. I hoping for a rapid fix. I submitted a bug report as well.

 

I'm also experiencing the "Unknown Assembly DOTween" issue!

 

I can confirm the "Unknown Assembly DOTween" with Unity 2019.3.11f1 and Addressables 1.8.3

 

I can confirm the "Unknown Assembly DOTween" (and with Odin's dll too) with Unity 2018.2.17 and Addressables 1.8.3

 

Near as I can figure there is a dependency check happening and scripts that belong to DLLs are coming up and being processed. I see this primarily with Rewired because all the ControllerData files are types that exist only in the RewiredCore dll.

 

Confirming
"Unknown Assembly DOTween"
and also
"Unknown Assembly Sirenix.Serialization.Config"

with Unity 2019.3.13 and addressables 1.8.3

 

@unity_bill any updates on this issue ?
Thanks

 

I get "Unknown Assembly DOTween" too with the latest addressables and unity 2019.3. It doesn't happen with 1.75, though this version is giving me headaches too.

I updated to 2020.1b to try and fix (and it seemed to) but there were so many other problems w 2020.1b that I had to switch back.

That bug above was closed bc the reporter decided not to use addessables after the trouble - weird reason to close a bug :\
https://fogbugz.unity3d.com/default.asp?1243008_u0mordu61ousc0o5

 

Agreed, whether I personally use addressables is unrelated to whether or not it is a bug or if it should be addressed. I recommend opening your own case.

 

I tried 1.7.5 with my repro case and that version did not work either.

 

same issue here. Unity 2019.3.1f1 and Addressables 1.8.3

 

Can also confirm.

Unity 2019.3.2f1 and Addressables 1.8.3

- Unknown Assembly DOTween
- Unknown Assembly Sirenix
- Unknown Assembly ArticyRuntime

 

I am also facing this issue when updating from 1.7.5 to 1.8.4. Did someone fix this issue?

 

More than a month passed since last update. Any insights about the roadmap for future Addressables updates would be highly appreciated.

 

Same problem. Please fix this already.

 

Have anyone actually filed a report via Unity bug reporter? Probably they won't respond to this unless someone does this.

 

I encountered the same problem, and failed to load AssetBundle randomly.

 

The question is: what is the bug? The appearance of the log message?
On my end these errors do not break anything in my project.

We need someone from Unity to tell us what this is. I have some other problems related to addressables and don't know if this has something to do with it. Care to comment @unity_bill ?

 

On my end these don't seem to break anything as well. But I argue that useless error messages in console (especially indicating possible incompatibility with all pre-compiled libraries) is indeed a bug.

 

Previously I had the issue that the bundles didn't build due to this error. But I tried again and the bundles are being built. So either it's fixed or the previous time that I tried something else stopped me from building the bundles.

Either way, it seems like a harmless error now.

Noticed that for some reason after upgrading from Unity 2019.3.14 to 2019.3.15, my addressables package got updated automatically. Not sure why that happens but I suddenly saw this error pop up again and was looking at why it suddenly did this as I didn't update the package myself.

It seems to work so I guess the error can be ignored safely unless someone tells me otherwise.

 

For the same engine version, this error doesn't occur in Addressables v1.7.5, but occurs in v.1.8.3+. Why the conclusion is this is an engine issue?

 

It is 100% a "harmless" error. With 2019.3 I've noticed that the delay associated with the logs showing up goes down. However, the more assets that fall under "exists in a pre-compiled assembly" the longer it takes. Since, as I'm sure you know, outputting a large number of logs can be very slow.

The only harm is time wasted (which could be a major problem to some folk).

 

I get the same issue with addressables 1.9.2 and Unity 2019.3.f14, for DOTween. I downgraded to 1.7.5 and it went away. To behonest, I am using addressables for the first time and reading the rather "uninterested" Unity replies above makes me think if I am betting on the right technology :-/

 

Unity 2019.4.0f1 addressables 1.10.0

- Unknown Assembly PlayMaker
- Unknown Assembly MadCompileTimeOptimizer.Editor

Is does not seem to affect anything but the main issue is that it spams the console with that log +999x and very inconvenient to see real errors.

We were previously on Unity 2019.2.4f1 addressables 1.6.0 and the issue was also present.

 

Here's the stack trace for the log error of my previous message:

Code (CSharp):

1. Unknown Assembly PlayMaker
2. 0x00007FF64C6D936C (Unity) StackWalker::GetCurrentCallstack
3. 0x00007FF64C6DD321 (Unity) StackWalker::ShowCallstack
4. 0x00007FF64ADDEFE5 (Unity) GetStacktrace
5. 0x00007FF64D3548EE (Unity) DebugStringToFile
6. 0x00007FF64D354602 (Unity) AssertImplementation
7. 0x00007FF64B1138B6 (Unity) IsAssemblyEditorOnly
8. 0x00007FF64B113C34 (Unity) BuildPipeline::ObjectIsSupportedInBuild
9. 0x00007FF64B129068 (Unity) BuildPipeline::ContentDependencyCollector::GenerateInstanceID
10. 0x00007FF6499F933A (Unity) RemapPPtrTransfer::Transfer<AnimationClipSettings>
11. 0x00007FF64C66E9D1 (Unity) TransferField_NonArray<RemapPPtrTransfer,Converter_UnityEngineObject>
12. 0x00007FF64C692C92 (Unity) Transfer_UnityEngineObject<RemapPPtrTransfer,0>
13. 0x00007FF649B5DDEB (Unity) ExecuteSerializationCommands<ConfigSettingsRead>
14. 0x00007FF64ACE6D31 (Unity) TransferScriptingObject<RemapPPtrTransfer,0>
15. 0x00007FF64ACE481A (Unity) SerializableManagedRefTransfer::Transfer<SerializableManagedRefBackupGenerator>
16. 0x00007FF64B1267EF (Unity) BuildPipeline::ContentDependencyCollector::CalculateDependencies
17. 0x00007FF64B10DFFC (Unity) BuildPipeline::CalculatePlayerDependenciesForScene
18. 0x00007FF64B413915 (Unity) ContentBuildInterface_CUSTOM_CalculatePlayerDependenciesForSceneInternal_Injected
19. 0x000001495FDB7CD7 (Mono JIT Code) (wrapper managed-to-native) UnityEditor.Build.Content.ContentBuildInterface:CalculatePlayerDependenciesForSceneInternal_Injected (string,UnityEditor.Build.Content.BuildSettings&,UnityEditor.Build.Content.BuildUsageTagSet,UnityEditor.Build.Content.BuildUsageCache,UnityEditor.Build.Content.SceneDependencyInfo&)
20. 0x000001495FDB7AD3 (Mono JIT Code) UnityEditor.Build.Content.ContentBuildInterface:CalculatePlayerDependenciesForSceneInternal (string,UnityEditor.Build.Content.BuildSettings,UnityEditor.Build.Content.BuildUsageTagSet,UnityEditor.Build.Content.BuildUsageCache)
21. 0x000001495FDB7693 (Mono JIT Code) UnityEditor.Build.Content.ContentBuildInterface:CalculatePlayerDependenciesForScene (string,UnityEditor.Build.Content.BuildSettings,UnityEditor.Build.Content.BuildUsageTagSet,UnityEditor.Build.Content.BuildUsageCache)
22. 0x000001495EC6A0A3 (Mono JIT Code) [CalculateSceneDependencyData.cs:91] UnityEditor.Build.Pipeline.Tasks.CalculateSceneDependencyData:Run ()
23. 0x000001495DF0DB4F (Mono JIT Code) [BuildTasksRunner.cs:56] UnityEditor.Build.Pipeline.BuildTasksRunner:Run (System.Collections.Generic.IList`1<UnityEditor.Build.Pipeline.Interfaces.IBuildTask>,UnityEditor.Build.Pipeline.Interfaces.IBuildContext)
24. 0x0000014954EEF60B (Mono JIT Code) [ContentPipeline.cs:130] UnityEditor.Build.Pipeline.ContentPipeline:BuildAssetBundles (UnityEditor.Build.Pipeline.Interfaces.IBundleBuildParameters,UnityEditor.Build.Pipeline.Interfaces.IBundleBuildContent,UnityEditor.Build.Pipeline.Interfaces.IBundleBuildResults&,System.Collections.Generic.IList`1<UnityEditor.Build.Pipeline.Interfaces.IBuildTask>,UnityEditor.Build.Pipeline.Interfaces.IContextObject[])
25. 0x000001495CF1101B (Mono JIT Code) [BuildScriptPackedMode.cs:156] UnityEditor.AddressableAssets.Build.DataBuilders.BuildScriptPackedMode:DoBuild<TResult_REF> (UnityEditor.AddressableAssets.Build.AddressablesDataBuilderInput,UnityEditor.AddressableAssets.Build.DataBuilders.AddressableAssetsBuildContext)
26. 0x00000148C2C22298 (Mono JIT Code) [BuildScriptPackedMode.cs:78] UnityEditor.AddressableAssets.Build.DataBuilders.BuildScriptPackedMode:BuildDataImplementation<TResult_REF> (UnityEditor.AddressableAssets.Build.AddressablesDataBuilderInput)
27. 0x00000148C2C0F51D (Mono JIT Code) [BuildScriptBase.cs:74] UnityEditor.AddressableAssets.Build.DataBuilders.BuildScriptBase:BuildData<TResult_REF> (UnityEditor.AddressableAssets.Build.AddressablesDataBuilderInput)
28. 0x00000148C2C0D1F5 (Mono JIT Code) [AddressableAssetSettings.cs:1729] UnityEditor.AddressableAssets.Settings.AddressableAssetSettings:BuildPlayerContentImpl ()
29. 0x00000148C2C0CCFB (Mono JIT Code) [AddressableAssetSettings.cs:1711] UnityEditor.AddressableAssets.Settings.AddressableAssetSettings:BuildPlayerContent ()
30. 0x00000148C2C0C363 (Mono JIT Code) [AddressableAssetsSettingsGroupEditor.cs:270] UnityEditor.AddressableAssets.GUI.AddressableAssetsSettingsGroupEditor:OnBuildPlayerData ()
31. 0x00000148C2C0BEF3 (Mono JIT Code) [AddressableAssetsSettingsGroupEditor.cs:265] UnityEditor.AddressableAssets.GUI.AddressableAssetsSettingsGroupEditor:OnBuildScript (object)
32. 0x00000148C2BB7326 (Mono JIT Code) UnityEditor.GenericMenu:CatchMenu (object,string[],int)
33. 0x00000148C2BB6F8F (Mono JIT Code) (wrapper runtime-invoke) <Module>:runtime_invoke_void__this___object_object_int (object,intptr,intptr,intptr)
34. 0x00007FF85622CBA0 (mono-2.0-bdwgc) [mini-runtime.c:2809] mono_jit_runtime_invoke
35. 0x00007FF8561B2112 (mono-2.0-bdwgc) [object.c:2921] do_runtime_invoke
36. 0x00007FF8561BB10F (mono-2.0-bdwgc) [object.c:2968] mono_runtime_invoke
37. 0x00007FF64C64D29E (Unity) scripting_method_invoke
38. 0x00007FF64C64700D (Unity) ScriptingInvocation::Invoke
39. 0x00007FF64A2C3F0A (Unity) CustomPopupMenuInterface::Execute
40. 0x00007FF64A20C4BC (Unity) MenuController::ExecuteMenuItem
41. 0x00007FF64ADF56AD (Unity) ShowDelayedContextMenu
42. 0x00007FF64AE050D5 (Unity) GUIView::OnInputEvent
43. 0x00007FF64A30F3CC (Unity) GUIView::ProcessInputEvent
44. 0x00007FF64ADFBF3D (Unity) GUIView::DoPaint
45. 0x00007FF64AE07AAD (Unity) GUIView::RepaintAll
46. 0x00007FF64A49F137 (Unity) Application::TickTimer
47. 0x00007FF64AE03EC0 (Unity) MainMessageLoop
48. 0x00007FF64AE0DFB8 (Unity) WinMain
49. 0x00007FF64DDF2BE2 (Unity) __scrt_common_main_seh
50. 0x00007FF8C9B87BD4 (KERNEL32) BaseThreadInitThunk
51. 0x00007FF8CB6CCE51 (ntdll) RtlUserThreadStart
52.  

 

Hi,
I have those same messages, using addressables and sensibly the same plugins,it started about the same time I switched from VS to Rider... Could that be a factor? Which IDE are you using?

 

We are using Visual Studio.

 

Anyone found a fix to this error message "Unknown Assembly DOTween"?

 

As commented in the thread, 1.75 doesn't have the issue. Just downgrade to that one

 

This issue is safe to ignore AFAIK. We have it in production version and it doesn't seem to affect anything.

 

The issue with this issue is, that I can't build Addressables. Playing the editor is fine and all.

 

Make sure you didn't uncheck "include in build" on your groups, that happened to me when I wanted to put all the groups in remote load, and mistook the "build" for the app build.

 

In that case you need to find the actual build error that's preventing your build. You're probably looking at the wrong error message.

 

Groups are fine.

I had to downgrade to 1.7.5 and then magically all the problems went away.

 

Fixed in 2019.4.1f1

 

Hi there! Does this "fixed" refer to the unknown assembly error, or the addressable loading times?

We're on 2018.4.16f1, trying to use addressables (1.10) on the Nintendo Switch, and in despair about how slow they are. We have scenes in one set of bundle groups, the assets they reference in another (basically a bunch of "duplicate asset isolation" groups, which we tried to optimize - e.g. if an asset is referenced by levels 1 and 3, it will be in a group labelled "level1_3"). Loading scenes this way is prohibitively slow on the Switch. Disabling CRC checks helps somewhat, but loading via bundles is still nowhere near as fast as building the scenes into the data. Any chance bundle loading would be faster on 2019?

 

Only the [unknown assembly error]. Don't have a switch dev kit, but loading performance on android is still a lot slower than other platform.