I might be misunderstanding the usage of this feature, or doing something wholly wrong. Just to say up front, I’m already working around this and don’t necessarily need to know why this is happening, it’s just something I was doing as a temporary shortcut, and am currently moving on from anyway (though it would be nice to know for future if and when I do actually want to use this feature…)
Essentially I have a GO with a single sprite attached, and want to be able to pull images from 2 different pre-defined atlases using the “go.property(“ABC123”, resource.atlas())”
This actually works perfectly fine using go.set to change the atlas and sprite.play_flipbook to specify the image, however, it does also give an error:
ERROR:GAMESYS: Unable to play animation ‘blahblahblah’ from texture ‘/_generated_b557c10e.texturec’ since it could not be found.
It seems as if the sprite is constantly being called behind the scenes to say “you’re imageX, you’re imageX, you’re imageX…” including between the go.set and sprite.play_flipbook messages, where an image of that name doesn’t exist in the new atlas, thus the error.
Strangely, I get the same error even if i set sprite.play_flipbook to the new image name before switching to the new atlas (error complaining that the previous image doesn’t exist in the new atlas, when I might expect in this case an error complaining that the new image doesn’t exist in the old atlas instead).
Seems like this likely all comes down to timing behind the scenes, but again, this is the first time I’ve tried using the new resource properties, and could easily have no idea what I’m doing here…thoughts?
I took a look at the code now. When you change image on a sprite to another atlas we expect the new atlas to also contain an animation with the same name as the one currently being played (we also try to maintain the same offset and playback rate). If the new atlas doesn’t contain an animation with the same name you get the error you saw.
If you make sure to name the animation groups in the two atlases the same you no longer get an error. Is that a solution that could work in your case?
My case was simply a shortcut to test a piece of code i was working on visually without having to build a new atlas for images i didn’t have yet (basically items look 1 way on screen, and a different way when attached to the cursor/in inventory). I didn’t have the “cursor” images yet, so just swapped the atlas that was assigned to the cursor to the one used for the items in the scene as a way to test that my inventory/cursor system was running properly (which it was!) For what I’m working on now, in the end I probably won’t be using the atlas swapping, just building either 1 larger atlas, or having 2 separate ones for scene items and inventory/cursor items.
I can sort of see the benefit of the way the system is laid out currently, say having “skins” for characters in different atlases with the same “run,” “jump,” “shoot,” “die,” etc animations, but i can also see the advantage of having the atlas swapping not assume anything about what you’re attempting to accomplish.
Maybe having the go.set() take an extra optional parameter at the end for which image or animation to choose when switching atlases, defaulting to the current animation name if not specified (as it works now)?
Note that there is no actual Lua error, just a (non fatal) error in the log that we output. We can either downgrade it to a warning, or remove it altogether (but I feel that might be too difficult for users to find any potential issues then).
Yes, it’s a bit of a timing issue, and that might suggest that we should just downgrade the log error to a log warning.