Hey there.
When I uncheck the "Export" box in the options of an image it still is exported. I'm not sure if this is maybe an unfinished feature... so sorry, if so.

Thank you for the answer.

I would want to disable inherit scale of the child bone if I wanted it to not scale as it's parent in every animation. But when I want this behaviour just in one particular animation I wouldn't ;-) (That's how I came to this porblem.)

Well I guess I have to bite the bullet and manually shear and scale the child bone then.

It seems as if the compensating of scaling isn't working correctly anymore.

When I scale a bone on only one axis (with compensate on) the contrary scale of the child bone/image seems to be too much. (see image below) I don't think, this is supposed to work like this ;-)

Works fine if I scale both axis at the same time though.

No comment of the developers on this?

BPO_Jeff escribió

1) If you use meshes, you'll have to manually open the .JSON file after exporting and change the word "deform" to "ffd" so GM knows where to find the mesh animation data. Just a quick search and replace of one word and it should work perfect.

Thank you for that tip. Unfortunately using skinned meshes still isn't possible with this trick.
It's sad that spine has such a low priority for yoyo games that they haven't updated the runtime for over 1.5 years now.

I reproduced your steps yesterday - unfortunately my internet made probles so I wasn't able do write another answer. It seems as if you added a lot more to your last post meanwhile.
Nevertheless what I wanted to comment remains the same:
You're right. The image doesn't swap. But I don't think this is a bug. It's just the way it works. Spine just thinks you want the draged image as part of the skin. How should spine know that the one attached to the skin placeholder isn't an "old" one but should be kept instead. Moreso...should spine keep in mind where each sprite was attached before it was moved? (I'll explain a case down below)
I understand that in your case swapping would be comfortable but in other cases it would be strange. So esoteric just had to make a decission for one way how spine behaves when dragging another image into the skin laceholder.

Case where swapping would be hard to realize or strange:
Imagine you have a skinplaceholder with a sprite attached. Let's call it "hand1". You realize that this is the wrong sprite.
So you drag another image "hand2" from the library into this skin placeholder. It will replace "hand1" - Great! Because that is what you wanted. With your swapping version "hand1" would be now a regular attachment to the slot instead. And it would force you to delet it. (would be anoying if you had to do several times)

Another case: "hand1" is attached to a slot called "hand_lft". You drag it into the skin placeholder "hand" wich is attached to the slot "hand_rt".
Now you drag the sprite "hand2" from the "hand_rt" slot into this skin placeholder. Where will "hand1" go in your swapping solution? Back to "hand_lft"? (this means spine needs to save the attachment history for every sprite) or will ist got to "hand_rt" because this is where "hand2" came from? (this could be very annoying too)

You see what I'm trying to say? There are always cases where one or the other version feel strange or would make more work. This doesn't mean that it's a bug ;-)

I'm not sure what you mean by "swapping position". I assume you want to have several sprites in your slot to switch between them? (for example to do a frame animation)
If so you will need a skin placeholder for each sprite.

If you just want to change the list order (swapping position?) then I have to tell you that this is impossible. The order is always alphabetical or defined by the bone hirarchy.

I hope this can help you with your problem.

Those are some usefull features. Also great examples to show the possibilities of path and transform constraints. :yes:

I just played arround a littlebit with these new features and allready have a small wish. It would be great if you could invert values at the transform constraint. For example to create a chain of gears (every seccond one shoud rotate the other way round). Or maybe there is allready a posibility for this (exemple creating 2 constraints of course) ? I tried invertig the scale but this didn't invert the rotation direction.

Like I said just a smaaaaaaaall wish. In the end it wouldn't make a lot more work to create 2 constraints in that case. The whole feature does save us a lot of work allready the way it is ;-)

Hey, Michael!
Als offenbar die wenigen aus Deustchland, die Spine nutzen...sollte man sich ja vieleicht mal vernetzen. Über Facebook, Xing, LinkedIn oder sowas...

Subject: Spiners unite! Where are YOU living?

Michael escribió

Another german guy here
I am studying Computer Science (Master) @ HS Coburg and work with spine personally.
I am also working in a start-up and we are thinking about using spine there.

Most of this cuts no ice with me but I have to admit that a motion capture/rotoscope feature sounds like a fascinating thing.
Just the idea of beeing able to load a video as reference into (let's wish for it) spine sounds very compelling. (Even though it's use for rotoscoping would be limited for realistic artstyles... but... you know. It sounds so cool :p )

Hey, looks cool!

That's a really nice style and fine animations. There's just one thing that makes me skratching my head... why is the flame of the torch dark? Sdhouldn't it be bright as it even seams to be the lightsource?
But no offence! The overall look and quality are great. :yes:

Hi there!

Got this strange problem.... I've created a mesh for an image and animated it by bones.
The thing is... there is a lot of transparent pixels within that image. So when I export the project with "strip whitespace"-boxes checked the result ingame (or also in your skeleton viewer) looks as if the sprite was stretched (just as if the stripped version was stretched to the original size of the image WITH whitespace).
By unchecking the "strip whitespace" option everything looks fine but the exported spritesheet(s) have enormous size (of course).

I guess for the moment there's no opportunity to replace the image without having to redo all the mesh-work, do I? For I don't want to get unnecessarily big spritesheets.

Nice style!

I'd love to see the setup of your characters. Seams as if you were working with a lot of "layers"(/seperate objects) and mesh deformation.

If it should be a very simple arc movement you could attach your object to another bone with a offeset. If the object itself should rotate - you just use another bone (wich contains the slot) attached to the rotating bone and uncheck inherit for rotation.
Of course you could also attach even more complex objects to the rotating bone.

(But I'm not sure if this solves your porblem)

I'll attach a screenshot of an example to support my description.

I just rushed through that tutorial - and as far as I can tell that "transformation" is nothing more than a frame-animation. While the artist there used flash to draw the single frames. Maybe there are some tools that make it easier for him.

Frame animation IS possible in spine. So, yes, spine is capable of doing something like that - except the drawing within the tool. You will have to draw each single frame with a drawing programm (e.g. photoshop). As long as it is just for a small animation - say one before the level starts (as you mentioned) - this is no big deal. If you might want to morph a fully spine animated ingame character it might take a litte bit more effort. Though it is possible .

I think the idea of a morphing character is very interesting and I'm quiet motivated to do a small test/example animation now. But actually I'm at work right now - so I have to do other things :p and I'm a littlebit short on time the next week. This means you might have to wait some days untill I could show one, sorry.

I think it might be interesting for some people if you could tell a littlebit about the game. What kind of game it is and (maybe even more important) what kind of artstyle you have in mind. So that people can evaluate if that's a project they are interested in/their skills are appropriate. (but maybe I'm wrong and it's just my nosiness ;-) )

Devils&Demons finally is released.
It's out on iOS and android!

Here's the trailer which includes some ingame scenes:

Thank you for your mail, Nate. :yes: I forwarded it to our coders. As our project is in the final phase before release there are a lot of gamebugs they have to take care of. :S
It seems as if we will stay with our workarround untill realease. After that the coders will have time to have a look at your example and test out a littlebit more. This means it might take a while untill I can give you more feedback.

At least I can/will send you screenshots of this bug by mail.