Dengar

Does ANYONE read the first post in this topic? Could you try it for me?

I will admit, I never quite thought of such a scenario. In theory that should work as normal, but apparently it doesn't. I'm not sure how to fix it. Have you tried SpriterDotNet along with my addon?

I'm afraid I do not understand the problem. Do you have screenshots or a video?

Oh yeah it's definitely possible. I just don't know how, personally.

@Bisoux I did not see your edit until just now. If that's a result from SpriterDotNet, then you might want to ask @loodakrawa about this over in the SpriterDotNet topic. I merely attach an animatorController.

What I am wondering is, though. What is the argument against just using the Sprite Packer?

Didn't I already add something like this to the very first post in this topic? People keep posting the same issue over and over and over and I have to give the same answer every single time.

It's not supposed to do that, but I don't know why it does that or how to fix it. Long story short, try importing your images a Sprite, rather than Texture2D. Set your Project Settings to 2D while you're at it. Then reimport the .scml file.

I'm not entirely sure if I can do that. I can probably add something similar to the AnimatorRelay, provided that SpriterDotNet actually supports these features, I'm not sure if it does. @loodakrawa would know.

Well, the Unity manual has the explanation of how to use it, but basically it takes advantage of the fact that Unity uses its own graphic compression methods to put multiple sprites into a single atlas whenever you build the game. It has the advantage of making each individual sprite its own asset you can reference, but in the built game they are just an atlas and a set of coordinates.

I really recommend against using sprite sheets at this point in time. I don't know what loodakrawa thinks, but to be able to use a sprite sheet in such a manner would mean importing the sheet through script, then somehow, through script, slice the sheet to create the sprite references. I don't even know if this is possible, and I really have no motivation to find out. There's also zero need for such a feature since Unity has the Sprite Packer. I suppose there's ONE thing that's possible. But this also wouldn't use Spriter's sprite sheet functionality. But basically, you just use separate files as normal, and then have a script in Unity automatically set the packing tags and generate the atlas. I'm fairly sure that's possible to do through script. If loodakrawa doesn't pick this up I might look into this myself.

I updated the project to also add a behaviour to the root StateMachine that lets you customize Any State transitions. I really would appreciate it if people checked out the project and pointed out features that seem important but are currently missing.

I updated the project to also add a behaviour to the root StateMachine that lets you customize Any State transitions. I really would appreciate it if people checked out the project and pointed out features that seem important but are currently missing.

I appreciate the compliment. It doesn't actually create any Mecanim animations (since that is unnecessary) so it's more of a "pseudo pretend Mecanim". The animation states are just empty shells that tell the SpriterAnimator what to do. Here's the github link for anyone interested in tinkering with it. https://github.com/Dharengo/SpriterDotNetMecanim The main feature is basically for just basic statemachine-based animation, you use the AnimatorController just as you would with full Mecanim animations. With transitions, parameters and whatever you will. User-side scripts would communicate with the Animator component just like most Unity-users are used to. There are a few caveats though. Unity's AnimatorController is quite... limited in its runtime accessibility. I already have to hop through a number of hoops just to make it possible to edit individual transition lengths. As such, some features might work a little differently than one would expect. Animation blending and blend trees are a thing that don't work at this point in time, but substatemachines should work (in theory, it is untested). Regarding the blending, I'm not sure if I CAN make it work. Like I said, the runtime accessibility, and even the edit time accessibility leave much to be desired. That said, it appears that a future version of Unity will come with additional statemachine-based shenanigans, maybe the answer will lie therein.

Okay as a little update. I had all this neat stuff prepared, but now my iCloud Drive is malfunctioning something bad. I still haven't managed to fix it, but I managed to salvage most of the project and moved it to my dropbox. So anyway, since the project is still in its developmental stage, I'm just going to drop this here. https://github.com/Dharengo/SpriterDotNetMecanim It's very bare bones. The only thing it currently does is create the AnimatorController, and as of yet the AnimatorController has limited functionality. That being said, I'd appreciate it if some people felt like taking it for a spin and tell me what sort of features they feel like they're missing. I can go further from there.

I don't think it's a big secret that a lot of fixes for current bugs with the importer keep eluding me. The base functionality is there, but when you try to use more advanced Spriter features, chances of something going wrong increases. So I took a look at SpriterDotNet and started working on a little alternative by just adding a dash of Mecanim to it. Here's what I've been able to achieve thus far. Not sure how much of Mecanim I'm able to implement this way, but I'll keep exploring some new options. I am unsure whether this will completely replace Spriter2Unity, but it might become an appealing alternative.

I've been doing some experimenting with SpriterDotNet and thought, maybe I can just add a tiny whiff of Mecanim to the mix. This is a little demo of what I've been able to do thus far.

As a matter of fact, that can be done. Quite easily too. Just look at the "SCMLProcessor" class and fiddle with it a little. Rename the method to something else, have some way to have the user target the .scml file (like Selection.SelectedObject (or something like that, idr the exact property)) and then create a menu item from it or something.

I considered the idea at one point, but I'd rather not put an incomplete product on the asset store. That said, I'm sort of brewing a new edition in my mind that may or may not be easier to create and maintain. No ETA on that yet though.

Well it's good to know that there is at least ONE tool that makes it fully compatible with Unity at least.

So this seems to have gone by me completely unnoticed. How does this tool compare to my Spriter2Unity? It doesn't use MecAnim? I wonder if this is preferable over Spriter2Unity or whether the two tools are so different that different people might prefer one over the other. Does it suffer from any of the stupid bugs and issues that Spriter2Unity suffers from?

<moving this question to the unity specific version>

It does not, and in fact it cannot. I mean sure technically if I used some really complicated math I could fake it, but it's very difficult to do and not very high on my priority list at all. I'd rather implement character maps before anything else. EDIT: And before that, I'd like to do something about the anomalous curve issues.

You are probably setting the pivots in the animation while neglecting to set default pivots.

The "for some reason" is obviously because I didn't update the package. ..... I updated the package. Also the settings no longer rely on a physical asset.