I am using fullserializer to generate save files which are read and written to disk. One type of field I frequently need to save/load is an array of sprites. Serializing and deserializing these fields results in them reappearing as null.
My workaround to this would be to put the sprites in a resources folder, and instead serialize the paths to the folder, then do resources.load after de-serializing. The problem is that I do not see a way of getting the path at runtime (I know you can do it in editor mode with AssetDatabase but this is not helpful).
My question is: how do I get the path to an object that exists in the resources folder at runtime? What is the correct way of serializing a reference to a sprite to disk? The solution has to be flexible enough that a user can change the array at runtime to other arbitrary sprites in the resources folder, of which there could be many.
Reference to Unity objects cannot be serialised and deserialised to disk. Nor can you look up the path or GUID of assets at runtime.
Generally you need to introduce some kind of look-up table yourself (such as a scriptable object referencing all the sprites you may need), and convert the direct references to some kind of path or ID that be used to look up from the table. Some serialisers have ways to convert these references during serialisation as well.
This is less straight forward with built in Unity object types as you can only really work off the name of the asset as a unique identifier, as their GUID is not something we can access at runtime. With custom assets, like scriptable objects, you can have it express unique ID’s.
Alternatively, you can work with indirect references. Ergo, rather than have direct references to the sprite, you instead have a wrapper class that provides an implementation for looking up and returning the sprite based on some ID it’s saved internally.
All-in-all, you may have to build a wrapper scriptable-object type to make this workable. Otherwise you’ll have to work off the names of your sprite assets.
Simply just loading all the sprites in Resources, and then checking each one is an option, too. Not a good one, but it’s an option.
I believe sprite mode - multiple is just an importer thing, which generates a bunch of sub-object sprites. I don’t believe you can access sub-objects at runtime without having existing references to them.
Notably with Addressables, sub-objects need to be specifically referenced via an asset reference. You’re not able to derive sub-objects through the parent object. This is likely the same with the old Resources API.
Does that not mean it is impossible to address objects in unity without having a reference to every sprite in my commercial project active in memory simultaneously? Its a large scale game so I cannot just keep live references to every sprite laying around all the time there are thousands of them.
E: even if there was just a way to know how_many subobjects there are, it would work, because I could just write $“{spritename}_{i}”. Maybe there is a way to do that?
The addressables system can allow you to have indirect references that can be loaded on an as-need basis. You will just need a middle-man system that handles this.
I’m like 99.99% sure you can only access sub-objects via the main object in the editor only. At runtime you need pre-established references.
Again, sprite mode - multiple is an importer setting; it’s not reflected in the actual sprite properties. It just generates a bunch of sub-object sprites, but the parent object has no way to access them directly or any knowledge of their existence. The setting is stored in the editor-only meta file as part of the importer.
You know these paths. You program to load resources from a Resources folder, so you know the paths. Neither the user nor your app is ever going to save files to a Resources folder. You may want to use StreamingAssets instead.
The important question here is: WHY are you trying to do this?
Sounds to me a lot like you try to do this to solve a problem you may not actually have, or where you could use a Unity built-in module or package that you aren’t aware of (eg Addressables as mentioned).
If you have many sprites, surely you are using Sprite Atlases? If not, look into them. You’d be wasting both performance and memory not using atlas sprites. And when it comes to memory usage, there are also options to use compressed textures or reduced color depth.