I want to report a Spine mouse offset issue where launching spine on a Mac Sierra 10.12.4
The mouse cursor hit/rollover is at about 75 pixels higher than the visual pointer in the Spine window space.

Resizing the Spine window resolves the offset issue for that application session, but the issue is consistent each time Spine is started.

-Jason

I am using assets from a folder in my project, the image node was the root of the project, I was exporting into a sibling folder of the assets, but this did mean it was in the project folder and therefore read by the images node.
I remapped the images node to only read from the assets folder.
:yes:

I've been experiencing a issue recently with Spine reloading the attachments while exporting a PNG sequence.

1. Opening a spine scene with assets in a 4981x1872 export bounds.
2. Selecting an animation of 256 frames.
3. Exporting the animation as a 30 FPS PNG sequence.
4. Durring export the scene may unload and reload image attachments.
5. Inspecting the exported PNG to see a couple frames had captured the missing state of the attachments.

There are consistently some early frames like frame 9 renders all image attachments as "missing". Then on frame 10 most attachments are normal, some others are still "loading".
These "missing" and "loading" attachments are being exported to the png sequence, and running the export over again will produce the issue at the same frames.
A different animation has this happen on frames 18&19, another on 12&13, The image unload is being consistent to whats happening in an animation.

I would like to second a pixel snap modifier.
The rotation shift to snap is already a great feature, now translation changes are lacking locking assistants.
I've read these concerns on this thread and others about animated translations, rotations etc. The tween interpolation will create sub-pixel values as understandable. However in setup of assets and animations that transition from a set of floored center values to another floored set of values is something I do often. In the finer points of UI, and text assets placement. Therefore I'm always finding myself dropping the decimal point to round the values in the transform panel.
I think a shift modifier during translation for round the x, y values would be a excellent add.

If multiple attachments are selected for a single slot, (say from dragging them onto another attachment for offset placement)
Changing the a current visible of any one of the selected attachments on mouse down hi-lights the correct dot, but on release then often sets the visibility of one of the other attachments (as if randomly)

Spine 1.8.18

Expected result:
When dragging an image region into the Viewport, the region should be created with no Path value defined by default.

Actual result:
If the region is placed into the Viewport the region's Path value is defaulted to the image location i.e.: robots/robot01
If the region is placed into the Hierarchy, either as a new slot, or under an existing slot the Path is not defined i.e.: <name>
A slot may been created with a drag into the viewport, followed by additional region attachments by dragging images up into the Hierarchy -> existing slot. This creates the inconsistency when working with and renaming values in the Hierarchy by double clicking. Some have their Path values pre-defined, other do not.

Thanks,
-Jason

Confirmed inverted Y on trackpad OSX 10.9.2 , Spine 1.8.18

I've been playing with UE4 the past week and trying to understand the easiest way to still utilize the engine for 2D. What I've come up with is that it likes to rely heavily on static mesh data with predetermined UV maps. Which currently means trading in Texture Packer and Spine for Maya or 3DS Max.
However as a feature request for Spine because I like it so much, Nate - I'd love to eventually see if exporting to FBX would be a viable option for use in UE4?

Yikes, If I had that many to change I'd try to work around the pattern of export/import.

Not the best solution for having a centralized spine file... but,
-What you can do here is after setting up one skin.
-Duplicate the skin the additional 12 or so times. This will make 12 of the same skin setups, but you will have named the skins.
-Export the skeleton to a json file with pretty print.
-Open the json file in text editor and use find and replace next, start your cursor just above one of the skin definitions, and use replace next (not replace all) just enough times that you affect the folder name occurrences in that one skin to the new folder path.
-Change your replace pattern before continuing into the next skin definition and repeat.
-Import the json file back into a Spine project.

I could not wait to stay blocked on this. :bang:

The Spine editor is displaying the image referenced by the "Path" field, but the run time is loading the reference from the attachments "Name"
Until Spine runtimes are caught up, make conscious effort moving forward or go back through all your spine files and remove any input in the "Path" field of an attachment. First make sure that the attachment "Name" is set to the expected file. Then select all the text in the Path, backspace, and press tab to commit the change. (pressing Enter will undo the edit :drunk: )
If the image name is not set properly the image in the View will likely display missing. If the Path now reads as "<name>" that means it is displaying what the attachment name value is, therefore exporting the name value you expect, which is the only value of the two the runtimes as of 12-20-13 are concerned with.

Good luck.

<edit>
Heres a new trick I just found:
Export a pretty print json file of your skeleton and edit the file.
with a line the looks like the following, remove the underlined section and save for re-import.
"head-angry": { "name": "ogre/head2", "path": "ogre/head_angry2", "x": 25.74, "y": -2.19, "rotation": -90,

By a series of duplicating slots and renaming paths for attachments the attachment, the names value has been less a concern during authoring. Now that we have exported the json data. We are blocked on the runtime needing the path update. I tried to make my way through the spine-c stuff, but this is really over my head where attachment structs end and atlas begin.

Nate, please don't take too long before patching the Attachment Path use in spine-c

chflags nohidden ~/Library

every time you get an update from Apple

I've been able to narrow this down to images that are attached to bones, where the bone has a set rotation of zero. The image will then not show it's rotation.

At least for me, sending you a video and spine file.

Unless there is a reason I'm not aware of:

Expected result:
Select image or slot and review its rotation value.
Use rotation tool and see the rotation value update.

Actual result:
Selecting a image or slot the rotation value field goes blank, but not disabled.
The value can not be seen for review, but can still be changed.
Using the rotation tool rotates the image, but the value is still not shown.
Selecting a bone displays the rotation field value, but selecting a image again hides the value field again.

current version: 1.6.40