Animations can be played either once or in a loop. How the animation plays is determined by the playback mode:
go.PLAYBACK_NONE
go.PLAYBACK_ONCE_FORWARD
go.PLAYBACK_ONCE_BACKWARD
go.PLAYBACK_ONCE_PINGPONG
go.PLAYBACK_LOOP_FORWARD
go.PLAYBACK_LOOP_BACKWARD
go.PLAYBACK_LOOP_PINGPONG
But in 2D animation I don’t recall see such formatting.
I’m asking because the go.XXXXXXX thew me off as I was thinking I had to list the GO url shortname like spinemodel or something. But nope it’s just a hard coded go.
What am I missing here? Why even have go if it’s used for all playbook loops? Just kill it and make it less confusing.
My 2 cents, but I’m probably missing something obvious. So my question is, is it ALWAYS go. or can it be something else when animating spine models? If it is always go. then why have it?
We could put playback modes in the global scope in Lua, but that is not how we generally do things. Initially we only had go.animate() in the engine and then it was only logical to put these constants on the go module.
Later when we added the model component and spine component we used the same engine functionality for animating properties as when animating game object and script properties and rather than duplicating the playback mode constants in the spine and model components we reused the constants in go.*.
Thank you. I knew there was a good reason, but it’s a bit confusing when looking at the documentation. I didn’t realize go. meant go. I thought it was referring to my gameobject. So I finally just said screw it and left it as go. and it worked. LOL.
go. is just kind of a bad namespace imo. It makes it harder to document how to use the function because it needs to be explained that it isn’t refering to your in game go for the spine model. Changing this will be design breaking for a ton of people though. maybe a 2nd namespace where you can still use go for existing code but future code is encouraged to use a new name like engine.animate