Report Spriter for Unity 5.0 in Spriter Implementations Posted June 10, 2015 Really, REALLY? Dang. If I had known this sooner I would have fixed it long ago. Thanks for the heads up though. Next time you find out something like this, let me know, or create a pull request. I'll add it to the next update regardless. I still can't believe I made a basic mistake like that and had it go unnoticed for weeks. How long have you known this? Because I would like to have known about it as well. Can't really fix things if I don't know they need fixing. hmm. Well the first problem was the infinite loop. We had the same problem as other newbs made in the earlier version of SpriterUnity not DX. Make sure your images are set to Sprites not Textures. With DX there was a better natural flow to it all. Are first import worked fine(images were already set to Sprites). We only noticed the loop occur after a new Spriter image update came in with 2 new pieces of art. We down prioritized the issue for about a week as our project had more important matters to attend to. But then we had a show and tell and we needed to get these resolved. So after spending time inserting debug logs I finally remembered non DX version had to have them images set to sprites having watched where the loop started. The artist informed me there were new sprites. So I checked out the sprites and found they were set to advanced. Now since they are advanced they showed up in game world no problem, but then I switched them to sprite and problem fixed. No more inifinite import loop. We found this 1 week prior to my fix post for Valaar. As for the ordering issue. Same situation. We just had another presentation coming up. So I observed the sorting order after turning on the forced sorting. When the scene loaded the sorting was fine. Even going through every Sprite Renderer all the index was fine. Only after moving did the sorting order go funny. I couldn't find out why. So I went through the code stuck debug logs in. Eventually I found the * 1000 to bump the zposition into usuable integer values. So I checked what was happening to my movement in the game world. Although we only move on X/Y, we are using Spline Pro for movement. Even though those are still z.0. I was getting movement along the z axis. Some was larger, some was smaller. So when the z axis at a point was too small. The *1000 division was just to minimal for the system. Followed the code and found the that the math was working on world.z, rather than local.z. Changed to local z, and boom I was crying with tears of happyness. Considering are artist did over a month of animation using Spriter, and our dead line 1.5 weeks from now. Not having Spriter would have been a major hit to our work. As for time line. I was sitting on this fix about 2 days prior to posting to Valaar's problems. I have been to this thread regularly to see if anyone was posting fixes. but I was in a bind. Either fix the problem myself by spending a couple of days, or losing a month of work and cut everything that used spriter. I figure 2 days of working hunting down these issues was worth the effort. Fortunately it only took part of the day. So. may seem like I have been sitting on this problem for a weeks, but really only a matter of days. Glad I could help. Spriter is awesome and the Spriter2UnityDX has really helped my project. We still have the occasional non bone image not in the right spot. but when out spriter guy attaches a bone to the image. The spriter objects tend to work better. So it's a working work around for us. So we aren't going to be investing a code fix for this.