Hello,
after updating the project to UE 5.6.1, we are facing an issue where the map validation complains about a mismatch in the Smart Objects vs the Smart Object collection, i.e.
Non-spatially loaded actor X references Spatially loaded actor YWhere X is the collection and Y are the smart objects.
I believe the issue is caused by the changes in the collection, where the assets are not referenced by their `FSoftObjectPath` anymore, but rather by a `TObjectPtr` and `TWeakObjectPtr`, resulting in being picked up by the validation.
This brings me to a question - what is the supposed usage of the collections and smart objects with World Partition, since the way it worked before is not working without errors anymore?
EDIT: Also, for objects with mismatching DataLayer compared to the collection, an error is thrown as well.
Thanks for any respones!
I am also wondering about this. The use case I have is: I have a spatially loaded actor that I would like to reference a Smart Object in another (unloaded) WP cell. Smart Object Persistent Collections seemed to be the solution for this, but if I must make the Smart Object non-spatially-loaded, then it becomes difficult for that spatially-loaded World Partition actor to reference it.
This is indeed an error. You mentioned that this was working in 5.5 as you expected? I know we made some changes to the collections for The Witcher 4 demo to reference by ID to better support Level Instances. I do not remember encountering this on that project, and I believe we use the persistent collection in other projects internally. I can see the same validation failures as yourself in a repro project in 5.6 using the Open World template map, so I do know it exists. I am checking with our dev who owns Smart Objects in case there is a configuration setting or flag that may not be enabled by default for this.
-James
I have logged a bug report for this so we can properly look into the fix. Here is a link to it on our public issue tracker: https://issues.unrealengine.com/issue/UE-354411. It can take a couple days to mirror, but it will eventually update with the ticket info and current status.
-James
We solved it temporarily by backporting the SO handling in the collection via FSoftObjectPath from 5.5.
It might break the usage of SOs in level instances (that the 5.6 change should fix) - but since it worked in our scenario with the 5.5 code, modifying the code to the previous logic was the easiest way forward.
Sorry I don’t have better solution. I am still hoping that someone from Epic steps in and tells us what is the proper solution.
Yeah, in 5.5 it was referenced using a FSoftObjectPath -- reverting to this logic helped us, but if there is a proper solution instead of using the “old” way which does not work well with Level Instances, that would definitely be nice, since we want to start using Level Instances more in the future as well. 
Thanks for checking it internally and following up on this!