• Runtimes
  • Corona ERROR: RegionAttachment.lua:137

Related Discussions
...

Just dropped the latest corona-lua folders into our project and received the error: RegionAttachment.lua:137: attempt to index field 'region' (a nil value).

Our old corona-lua didn't have this issue so something in the new version is not working. It seems to be coming from the following block of our code, which uses skeleton:createImages where the latest example uses the imageLoader function.

local imageSuffix = display.imageSuffix
local suffix 

if       imageSuffix == "@2" or display.pixelHeight > 2048 then    

---

 Don't append @2 if it has it already
      suffix = ""
else    suffix = params.suffix or "@2"                     

---

 Do add the @2 suffix or a passed in suffix firstly.
      
end

local json          = spine.SkeletonJson.new()
json.scale          = 1

local skeletonData        = json:readSkeletonDataFile("spineData/"..data..".json")
local skeleton         = spine.Skeleton.new(skeletonData, nil)
local root             = skeleton:getRootBone ()



---




---

 Attachment Loader


---



function skeleton:createImage (attachment) 

---

 called by spine.lua (function self:createImage (attachment))
   return display.newImageRect("spineData/"..dir..skin..attachment.name..suffix..".png", attachment.width, attachment.height)
end

If it is we need to update createImages to imageLoader can you provide an example of the following code without atlas support as we need to continue using separate images:

local imageLoader = function (path)
   local paint = { type = "image", filename = "data/" .. path }
   return paint
end



---

 load the atlas
local atlas = spine.TextureAtlas.new(spine.utils.readFile("data/" .. atlasFile), imageLoader)



---

 load the JSON and create a Skeleton from it
local json = spine.SkeletonJson.new(spine.AtlasAttachmentLoader.new(atlas))
json.scale = scale
local skeletonData = json:readSkeletonDataFile("data/" .. jsonFile)
local skeleton = spine.Skeleton.new(skeletonData)

Separate image support has been deprecated as it unifies the code base and gives a huge performance boost. Can you elaborate on why you can't use atlases? The only alternative is to stick to the old runtime I'm afraid as we have no plans to add support for non-atlas images back in.

We'll investigate the use of atlas. First issue could be atlas images that are bigger than 2048x2048.


Here is one question about atlas:

  • How do separate spines (data.json) files use shared images? With the original createImages approach that was straight forward for multiple files to share images in a common folder. How to do this with atlas apparoach?

You load an Atlas, give it to an AtlasAttachmentLoader, then give that to a SkeletonJson:

local atlas = spine.TextureAtlas.new(...)
local json = spine.SkeletonJson.new(spine.AtlasAttachmentLoader.new(atlas))
local skeletonData1 = json:readSkeletonDataFile("skeleton1.json")
local skeletonData2 = json:readSkeletonDataFile("skeleton2.json")

More here:
Loading Skeleton Data - Spine Runtimes Guide: JSON and binary data

Note that you can run the texture packer separately from exporting JSON, see #2 here:
Texture Packing - Spine User Guide: Packing

Thanks for the reply Nate. Although not sure if this addresses our issue. We can set up and export an atlas fine, the issue is about multiple skeletons referencing some shared atlas images.

User case:
Using goblin and spineboy in separate spine project files, imagine they both use a shared asset, let's say a hammer. When it comes to exporting the atlas of goblin and spineboy, the hammer will also be exported from each project. But how can goblin atlas not create a second hammer but access the hammer that's already been created out of the spineboy project atlas?

You export the atlas separately from the JSON files. When you export the JSON for goblin/spineboy, you uncheck the atlas option in the export dialog. All you will get is the JSON file. Next, you export a combined atlas, as outlined in Texture Packing - Spine User Guide: Packing.

Regarding the texture size: this is not a problem. The new Lua runtime works with multi-page atlases. When you export your atlas, you can specify the maximum atlas page size. Also note that the performance has been vastly improved compared to the old way of rendering, especially because of the atlases. While you could share a single image in the old runtime (which you can still do using the process outlined above), you would get a huge number of texture switches, which greatly impact performance. This is no longer the case with atlases.

Thanks for the help. I am away from a test computer so just trying to clarify this stuff theoretically.

As we are staggering the delivery of spine scenes (json, images, atlas), it will be ok to update this one atlas each time with new images? This won't over write subsequent data?

Yes, if you always specify all source images you want in the atlas, you should be fine.