• Runtimes
  • [XNA] region missing

Related Discussions
...

Hi,

I'm hoping this is a really dumb mistake on my part, but I keep getting a region missing error on loading the skeleton and atlas.

Region not found in atlas: CharacterSprites/Guy/head (region)

Here is the atlas:

guy.png
format: RGBA8888
filter: Linear,Linear
repeat: none
CharacterSprites/Guy/head1
  rotate: true
  xy: 2, 2
  size: 24, 38
  orig: 24, 38
  offset: 0, 0
  index: -1

The Tree looks like the following:

  • bone
    • slot (CharacterSprites/Guy/head
      • region CharacterSprites/Guy/head (path - CharacterSprites/Guy/head1)

the images tree looks as follows:

  • Images
    • CharacterSprites
      • Guy
        • head1

In the json file, it has the following under slots:

{ "name": "CharacterSprites/Guy/head", "bone": "bone11", "attachment": "CharacterSprites/Guy/head" }

And the following under skins:

 {
		"CharacterSprites/Guy/head": {
			"CharacterSprites/Guy/head": { "path": "CharacterSprites/Guy/head1", "x": 26.76, "y": 0.87, "rotation": -88.12, "width": 24, "height": 38 }
		},

Any help appreciated, I'm sure I'm missing something obvious here.. I've used the default settings in the 'export' menu, and have successfully loaded the example character.

Cheers,

Try removing the "1" in head and export again. See if that sorts the problem. Afraid it's not my area of expertise, Nate will be able to help more

Not sure I understand. The image filename is head1, so if I rename that it can't find the image.

Just tried with a new project and get the same thing happening. Here's what I did..

New project,
Import an image ("sword1")
Select root bone
Click new - slot called "sword"
Drag the image "sword1" onto the new slot (sword)
Save and export

Does that sound about right?

edit- as a note, changing the atlas to "sword" instead of "sword1" and the json file skin path to "sword" instead of "sword1" does seem to fix the issue, but wouldn't call it an ideal solution. Here's the originals

test.png
format: RGBA8888
filter: Linear,Linear
repeat: none
sword1
  rotate: false
  xy: 2, 2
  size: 93, 80
  orig: 93, 80
  offset: 0, 0
  index: -1
"skins": {
	"default": {
		"sword": {
			"sword": { "path": "sword1", "width": 93, "height": 80 }
		}
	}
},

An issue with the exporter or me setting things up incorrectly?

If you're not using libGDX, paths haven't been implemented yet so changing the path won't affect anything and the runtime will rely on the name to find the atlas region.

If you really need to rename stuff and are feeling adventurous, you can try picking up this fork of Spine-C#:
https://github.com/pharan/spine-runtimes/tree/unity-ffd

It has path support.

It was made to accommodate FFD in Unity, but XNA and Unity share the same Spine-C# backbone and as long as you're not using meshes in your project, using the Spine-C# here should work just fine.

Thanks for the reply. I may take a look at it but I dont really need to rename things.

I'm quite confused here, the examples work fine when loaded into my game, such as dragon, so what are they doing differently to me above? My first attempt I didn't rename anything, only drag and dropped.

Sorry, I'm not sure if I got the point across:
path doesn't work in the current version of Spine-C#.

If the filename is sword1, the attachment name (not the path because the path doesn't matter right now) should be sword1 and the atlas and json will reflect this accordingly.
What you did was rename your attachment from sword1 to sword. That's what breaks it because the current Spine-C# doesn't support it yet. What you should do right now is keep the name "sword1".
The slot name doesn't matter but the attachment name does.

That's what I mean when I'm talking about renaming things.

As long as you have the current runtimes, paths won't work correctly.

Thanks, that makes it clearer. I'll have another look at the project and see if can get it working. Cheers!


Okay, I've had a look and can get it working now. The problem was when I dragged the image "sword1" onto the slot, it created an attachment named "sword". I'm guessing this is because of the Path stuff, so as long as I remember to rename the attachments to the image names it works fine.

Thanks for the help guys!

Good news is, this won't be an issue forever. Just until the runtimes get updated. I'm glad it's working on your end.

From what I understand, the editor did this automatically and you didn't actually do any manual renaming?
That editor behavior sounds peculiar. Might be something to look at for Nate.

Pharan a écrit

Good news is, this won't be an issue forever. Just until the runtimes get updated. I'm glad it's working on your end.

From what I understand, the editor did this automatically and you didn't actually do any manual renaming?
That editor behavior sounds peculiar. Might be something to look at for Nate.

Yeah that's right. If my image is named "head1", then when I drag it into a slot the attachment gets renamed to "head" without any manual renaming. When I drag the same image again into the slot, the 2nd instance is renamed to "head2", then "head3" and so on.

Maybe I should have just called my image "head" 😉

Interesting. Sounds like a bug to me.

Nate?

Sorry about that, fixed in 1.8.18, available in a few minutes. 🙂

Awesome, thanks guys! =)