Nate,
Thanks so much for your response! Here are some answers to your suggestions:

Nate wrote

AnimationStateData has a defaultMix field so you don't have to set the mix for all combinations. How are you changing animations?

Good to note the default mix. I assume you are talking about this one here:

	local self = {
		animationToMixTime = {},
		skeletonData = skeletonData,
		defaultMix = 0}

However, I am not currently mixing all animations. I've found that if the attack animation includes a projectile, mixing from the attack back to idle will mess up the projectile's animation. It may actually be possible to correct this by using tracks, but this is the solution for now.

Animations change using statements similar to the initial one in the new function:

    self.owner.sprite.animState:setAnimationByName(0,self.anim, false)
    self.owner.sprite.animState:addAnimationByName(0,'idle', true)

Nate wrote

Note you can use a single SkeletonData with many Skeleton instances (assumign of course the skeletons use the same JSON). This avoids loading the same data multiple times.

Units are unique per player, so there will only ever be 0-2 in any game. However, if I preloaded all skeletonDatas into a table ahead of time, this could optimize opening and closing the game module.

Nate wrote

The logged error seems to be in C code, inside image:removeSelf(). The Corona guys might have some insight as to why this happens. I would expect this function to never crash, so I guess there is a bug in their stuff. We might be able to work around the state that causes the function to crash.

I will definitely post this to the Corona forum as well.

Nate wrote

Maybe the image has already been removed? I don't see how this should happen though. Maybe a parent of the image has been removed?

To me, this is the most obvious offense, but I also do not see how it would occur. All manipulation to the skeleton is done through the runtime, I am not attempting anything programmatically. If this is the issue, it would explain sim/device inconsistency.

Nate wrote

Maybe the device is out of memory?

I doubt this. Like you said, the sim mostly works fine. Running a memory monitor shows low memory use and no leaks associated with the animations. On the device, memory use continues to rise, even just sitting and having the idle animations playing (I'm assuming this is due to the continuous runtime errors).

Nate wrote

The best way to continue is to figure out the simplest example program that shows the issue.

I did write a basic animation viewer so we could view our animations without having to actually play the game. I am hoping to use that as a base for debugging this isse. However, I was converting it to use the new spine runtime and had an issue locating a name field. With the last runtime I was using:

self.animState.animation.name

This would access the name of the animation currently playing. It now gives me 'animation' as nil. Where can I find this name?

Nate wrote

It's strange the simulator has a problem. It could be a different problem, or maybe its the same Corona bug manifesting differently?

From my experience with the simulator, I would guess it's the same issue. The simulator (on Windows at least) is much more forgiving of warnings/errors than devices. Our tutorial scene worked perfect on the sim, but was ruined on devices because we had one image with .PNG instead of .png. Using remove methods on non-existing Corona objects doesn't typically give an error, so it could be that the asset is previously removed as mentioned before.

Nate wrote

To debug this further it's probably best to add logging. Eg, log the attachment for a slot where the attachment isn't appearing correctly to see if the slot actually has an attachment. If the slot has the correct attachment and it just isn't being drawn, add logging for when that slot is drawn to see if the image is being created, etc.

Good thoughts, I will work on this. Again, thanks for your help.

An update:
Building the "goblins" example to the device worked with no issues. It runs fine and the log is empty. However, when I replace the goblin with my own character (making only minimal changes, such as filepaths, etc) I again get the runtime error for removeSelf @line 110. This error is still present on device logs only, and not in the simulator. If so, does that mean the problem could be in our actual animations? Could this be a side effect of non-uniform scaling? If this is the direction I should be looking, I may ask you to take a look at our skeleton jsons and/or speak with our animator. Thanks.

Okay, I found the issue. The device was not locating certain attachment images. The device is case sensitive, but the simulator is not, which is why it was working on one, but not the other.

Our team works remotely using both Dropbox and Github. The animations are completed in Spine on the dropbox side and work fine using correct filenames. However, when pushing the new animations using Git, if the asset already exists in the repository, it uses the pre-existing case designation of the file. (For example, if mouth.png was changed to Mouth.png, it will not recognize the difference and continue using mouth). For this reason, some of the image filenames used in the build were incorrect case and so the display objects could not be created. When removeSelf was called on the non-existing objects, it gave the runtime error at line 110.

object:removeSelf() does not check for nil, but display.remove() does. From the Corona API:

display.remove( object )


---

 is a faster way of doing this:
if object ~= nil then
    object:removeSelf()
end

Using this in the runtime could prevent the error, however leaving the error in may alert developers when problems are actually occuring.

In any case, thanks for your support Nate. Keep up the good work! :clap: