Dengar

The old version? It actually DOES have a guide. Or you could use the current version which doesn't have that problem in the first place.

There's also ways to do it without dragging references. You could use a Resources folder or an AssetBundle. That said, for purposes of that particular animation, I do recommend creating references since those textures will always be used while that "Bardbarian" is in the scene.

Would you mind sharing the .scml file with me? I've had great sucess isolating problems in the past when people shared their files.

I'm not sure what causes the problem but it might be a pivoting issue. Re: How to use with sprite atlas: No problem, just make references to the original texture. Unity automatically changes those references to atlas texture when the player is built. It's all nice and all that people would like an API for Unity users to use is a great goal, but the thing you are trying to do is 1) something anyone can do with a simple script and 2) simply not the Sprite Swapper's intended purpose. This isn't just about "expanding its capabilities" but would in fact repurpose the thing for something else entirely. Maybe this is partly my fault in naming the Sprite Swapper thus. But it DOES, in fact, swap sprites, so that's why I came up with it. Maybe I'll give it a different name in a next version to avoid confusion. I'll go in-depth on why the Sprite Swapper exists. Basically, in Spriter animations, sometimes, a particular part has multiple textures. Think of facial expressions, or maybe a slightly different angle, or maybe the guy's face changes color when he's poisoned, it can be anything really. The problem is translating that into something that's nonintrusive in Unity, because most of the "default" implementations had huge problems. 1) You could let the animation take care of changing the texture. This creates a HUGE problem because this "hard codes" the textures into the animation, and I do not believe they can be changed at runtime. At least not in the animation. You'd have to jump through some hoops and play "tug o' war" with the animation to change your sprites. (for example to add different outfits, or do other things that are not animation related, but rather script related) 2) You could use AnimationEvents to change sprites instead. Better. This does not set the textures in stone quite as much, and you could put references to the different textures on a component somewhere. That way the user can change the references on that compontent instead. This could be seen as a sort of "proto-Sprite Swapper". I abandoned this idea because it gets a bit messy when the user wants to add their own AnimationEvents. 3) Create a component that is directly manipulated by an Animation Curve. This is what I ended up doing. The Sprite Swapper is added automatically and only when necessary (which is when the AnimationClip needs a way to change textures), after all, if the AnimationClip doesn't touch the displayed sprite, the user can just manipulate the Sprite Renderer directly with their own scripts. In other words, if you want to change a texture by a means other than a Spriter animation (which is automatically through script), the procedure is VERY simple: If there is a Sprite Swapper, you change the textures used by the Sprite Swapper. If there isn't a Sprite Swapper (which is always when that part only has one texture to begin with), you change the texture used by the Sprite Renderer. That's it. It's that simple. Nothing complicated at all.

Ah yes see. I didn't actually create the Sprite Swapper with that kind of functionality in mind. The Sprite Swapper is driven by the animation, not by script. It's meant to account for texture changes you do in Spriter. If they don't happen in Spriter, it's no use adding such functionality to the Sprite Swapper. The importer is meant to import Spriter projects and make them usable in Unity. Anything that falls outside of that scope falls to the hands of the user, doesn't it? If you want to randomly change the texture every few seconds through script... Just write a script that does that? Am I thinking about this from a weird angle? Again: Other than replacing the textures that are used by the Sprite Swapper, the user is not meant to interact with that component.

So wait, pardon me for being out of the loop. Exactly what is the goal of this? What can the user do?

It actually just smushes all the textures together in a new graphic file that's hidden away in the Libary folder somewhere. And then draws them from that.

I'm afraid I don't quite follow what you are trying to use the sprite swapper for here. Can you like break the process you have in mind into steps? Maybe with an example of what you're trying to do, because I'm afraid I'm drawing a blank as it is. Not sure about 'core functionality' given the fact that I didn't even know that Spriter worked like this, and it only happens under very specific conditions. That said, I already said I'd work on it next time I work on it. I just don't know when that'll be. Two straight weeks of devoting every drop of my free time to this has kind of worn me out.

I did not know that you can change the pivot point while animating. Probably because I could not think of a reason why you would have a different pivot for each frame of an animation. That said, you probably have a reason for it (I'm interested in hearing why). I'll consider this a subject for my next update. Not sure when I'll get around to it though. I have some other things to do. Well probably because putting them on every frame of the animation is a waste if it doesn't change from the default? I use the pivot on the <file> element PRECISELY to set the pivot on the file in Unity. If I didn't do that, I'd have to use all sorts of funky maths to make sure the sprite parts don't get misaligned. EDIT: The real reason why it's there, is (most likely) so Spriter knows what the pivot point default is. Remember, you can set the pivot on textures that aren't even used in the current animation. And then add them later.

What's an origin point? If you REALLY want to do me a favor, backup your project, remove Spriter2Unity, then add Spriter2UnityDX, then reimport your .scml file, then tell me what happens.

Thanks Mike, I really appreciate having all these samples to work with.

Or you know, you could just use Unity's Sprite Packer and solve the issue that way. The previous version of Spriter2Unity wasn't being supported by anyone, and the current one is only like a week old. I don't actually know anything about TexturePacker or how it works or even that it existed. That being said, with Unity's Sprite Packer being a thing that exists, inegrating this isn't very high on the priority list. There are still a whole lot of unsolved graphical issues that need fixing, and some other actually useful features that need supporting. I am also the only one doing active work on it, and I'm doing all this in my spare time, for free, so I'm sorry for not having implemented every little detail for you.

v1.0.3: Fixes: -Fixed an issue where flipped (negative-scaled) bones caused child sprites to appear out of place and in odd angles Features: -Added a toggle to the Entity Renderer that allows you to apply the .scml file's Z-index to the order-in-layer property of the Sprite Renderers -Removed Spriter2UnityDX components from the Add Component menu, since they are automatically added or removed About the toggle: The "Apply Spriter Z Order" toggle that now appears on the Entity Renderer adds a whole bunch of calculations to the mix, so for performance reasons it's better to leave it off. Not that it's a performance heavy operation. Just that every little bit makes a difference. Applying the Z order to the "order in layer" properties of the child sprites also introduces some overlap issues when multiple spriter entities overlap. These issues can be resolved by placing different entities on different layers, but that requires you to create more layers. However, it has come to my attention that sometimes, when a lot of stuff is happening on screen all at once, the sprite won't always render properly using just the position_z. In these cases, turning on Spriter Z Order on the Entity Renderer will likely fix the issue.

I probably won't work on it right away, and I'm going to need to know exactly what I'm looking for, so I need an explanation. That said, any example of irregular behavior will help tons with improving the tool.

v1.0.2: Fixes: -Fixed an issue where sprites appeared distorted when resizing bones. -Exceptions are wrapped up nicely and no longer abort the whole process Features: -Now adds AnimationClips to existing AnimatorStates if they exist -Autosaves no longer trigger the importer Note that there is still some anomalous behaviour here and there. But the weird distortions should see about a 95% decrease. Special thanks to dagondev for helping me identify the issue, and Mike and Edgar for teaching me some things about Spriter to help me fix the issue. It's a bit of a shame that the tool is getting slightly slower with every update, but it's still within reason. I was able to import a project that has over 60 different AnimationClips in less than 20 seconds. I also have to add that most animation transitions work best if they are instant (IE no blend). Although it's really a case by case basis. But generally if the poses between two animations are radically different from one another, you want the transition to happen instantly.

That's peculiar. I can't really tell what the problem is though. Maybe if you send me a sample I can check it out for myself and see what's up? Several different .scml files have been successfully converted to Unity, so there's probably something different about your .scml but I can't tell what without examining it. @Wledig: That's pretty cool, I tried my very best to make the code as easy to work with as I could. If it can be combined with 2DTK that would be pretty awesome. I don't know much about 2DTK myself but I heard some really good things about it.

Nonono I just said, I fixed the issue. Errors shouldn't happen anymore. :P I already uploaded the fix. Basically, what happened, I assume, is this: Suppose you have an "effect" sprite, like one of those tornado things. That sprite isn't present in every animation. Now, suppose that while it's not present in EVERY animation, the Z value is different per animation. The importer would attempt to detect that the Z value changes, and attempt to access the sprite's Z value on the first frame of the first animation (to use as a control).... EXCEPT that sprite isn't present on the first frame of the first animation. So I just changed it so it accesses the sprite's actual first Z value. Not specifically the first frame of the first animation.

Curiously, I tried it with your Green Monster and Dragon Bat, and I was able to import them just fine. That said, I fixed your issue anyway. I have a feeling what configuration would cause it to crash. Not upping the version number just for a hotfix to the new feature though.

v1.0.1: Fixes: -Fixed an issue where the Z-order would get messed up if body parts were moved during animation Features: -Z-order can now be mutated by the animation

For now I think I'm gonna return to my own project. All the base features are worked out now. Should all be cool beans. I'll work on expanded features at a later time.

I went ahead and put my version in the opening post. Most of what you need to know is in there as well. At a later point I'll add some documentation on the new Script Components.

Maybe it's because I'm tired but I had a difficult time trying to understand that. But from what you are saying that the Entity Renderer only affects active GameObjects. This should not be the case. In fact, I tested it earlier. It works on inactive renderers as well. UNLESS you are talking about the layer dropdown. I quickly ran a test and it appears it does not work quite the way I thought it would. Lemme quickly write a fix. Aaand it's fixed.

Thanks for the support, but I have to give credit where it's due: Malhavok, Mythgarr, Bonus2113 and alaa-eddine did most of the work on the previous version (or currently-active, since my version isn't done yet). That being said.... https://github.com/Dharengo/Spriter2UnityDX/raw/master/Packages/Spriter2UnityDX.unitypackage This should be like, the "final test" version. After this, all of the basic features should be complete. I fixed that scaling issue, so boind, your wings should appear correctly now. I also added a final feature I felt that it needed: The Entity Renderer Component. This is a component that's added to the root GameObject, it allows you to control all of the Spriter Entity's renderers simultaneously. There may be a bug or two in it that I haven't found yet though, so feel free to play with it as much as you want and tell me about any irregular behaviour. Oh, one thing I should mention: Disabling the EntityRenderer component will also disable all of the Renderers. Enabling it will enable them again.

Ok, so before I jumped the gun and started trying to translate negative scale to rotation, I just went into unity and tried to scale the wings myself. (want proof of this, check the "storm" sprites) Negative scaling actually isn't a problem in Unity, so the wings disappearing has to be caused by something else. .... I see it now. The wings are being scaled along one axis only aren't they? Apparently Unity then defaults the axis values to 0. That's what's causing it to "disappear".

Thanks for the thanks. I do get a lot of personal gratification out of this stuff too. I've been wanting to play with Spriter2Unity for a long time, but I always kept this stance of "I'm not gonna be doing any active work on this" because the source code was so difficult to work with. Writing it all from scratch has been rather liberating. ^^