@JulianRice Sorry to hear you're facing this issue as well, thanks for your detailed writeup. Unfortunately the stack trace where the exception happens is already known, the question is which call modifies the skeleton's state before SkeletonGraphic.Rebuild is called. As mentioned above in previous postings, if user code modifies visible attachments after SkeletonGraphic.LateUpdate() but before SkeletonGraphic.Rebuild(), things could go out of sync. However, we've already added an automatic check when accessing SkeletonGraphic.Skeleton between these calls and trigger a second update automatically to re-sync SkeletonGraphic to the modification. Modifying the skeleton through a cached Skeleton skeleton = SkeletonGraphic.Skeleton however would bypass this safety check and explain the exception. Are you performing any modification of active skins or visible attachments from LateUpdate() in your scripts? If so, could you please share your exact code? If you're uncertain, you could perhaps add breakpoints in Skeleton.SetSkin and Slot.Attachment.set, or if that's not catching anything: add Debug.Log statements in said methods to see if any SetSkin or Attachment.set call at runtime lies between LateUpdate and Rebuild.
JulianRice Could this be as easy as going through all of the NPCs in the town, resetting the SPINE (whatever default assets/materials are set already), building, and testing it again?
I'm not sure if I understood this sentence correctly. If you mean that you could create a minimal Unity project by reducing the number of skeletons until only the problematic skeleton is left which still causes the issue in the built executable: that would be great! If you could provide us with such a minimal reproduction project, please send it to contact@esotericsoftware.com, briefly mentioning this forum thread URL so that we know the context. Then we can have a look at what's going wrong.
JulianRice Based on the stack trace, the LateUpdate() from Unity's ScrollRect is triggering this error, but only four times... so there has to be some kind of mismatch or issue with timing.
The issue occurs only when more attachment vertices are required (and written to) than are available. When things get out of sync the first time, an out-of-bounds exception will be raised, but when activating the same or a similar skin later, the vertex buffers likely have already been enlarged to sufficient size to cover the new skin, even if it's a different set of attachments now.
JulianRice I'll keep taking a look and will keep you updated, but please let me know if there's anything else I can do to find out the issue for this (and why it seemingly only happens in builds!)
Thanks very much for your offer! We are currently performing some more investigations on our side, but would be very happy if you could see if you could perhaps create a minimal reproduction project as described above, of check whether any calls that change the skin or attachments happen.
