यह साइट एक आधुनिक ब्राउज़र में सबसे अच्छी तरह से देखी जा सकती है जिसमें जावास्क्रिप्ट सक्षम है।

godot spine, still a bug on setting skin.

Luis Morao

On this post I will mention one git issue with a crash.
Then I will mention I still have another crash seemingly related
Then I will mention a different crash for a different function.

Hi, I've seen the issue EsotericSoftware/spine-runtimes2185
Still i think there's something more going on. By using that build, the crash still happens if I change the skin several times.

I don't have this crash on a mac (m1), but running on the windows: if I changed the skin "10" times, it happens before I can reach ten times.

If there's no fix, I also would like a workaround for now. I've posted my code before https://esotericsoftware.com/forum/d/18329-godot-and-skin-swapping/2

var data = get_node("%SpineSpriteHuman").get_skeleton().get_data()        
var custom_skin = get_node("%SpineSpriteHuman").new_skin(weapon.id)
custom_skin.add_skin(data.find_skin("default"))
custom_skin.add_skin(data.find_skin("weapons/" + weapon.id))
get_node("%SpineSpriteHuman").get_skeleton().set_skin(custom_skin)    
get_node("%SpineSpriteHuman").get_skeleton().set_slots_to_setup_pose()

What I want to do is swap a single attachment on a slot.
I think there's must be a more correct way to do what I am want to do.

My skin is made up this way:

1.    var custom_skin = get_node("%SpineSprite").new_skin("current_skin")
 2.   custom_skin.add_skin(data.find_skin("base"))
 3.   custom_skin.add_skin(data.find_skin("armor/chain_mail"))
 4.   get_node("%SpineSprite").get_skeleton().set_skin(custom_skin)  
 5.   get_node("%SpineSprite").get_skeleton().set_slots_to_setup_pose()

Question: Does the skin "current_skin" include information for each slot of the attachment of both "base" and "armor/chain_mail"?

Stating again what I want:

What I want to do is be able to swap the slot "torso_chest" attachment from the skin "armor/chain_mail" to the attachment of "base".
Right now If I wanted to change the slot "torso_chest" back to showing the attachment from "base" I would call that full block of code without line number 3. And then to swap back to chain_mail I would call the full block of code again including line 3.
This somehow seems silly, because I feel the skin should already have all those attachments. I don't know if that is true, but feels like it should be since the "current_skin" was "add_skin" from the two skins: ["base" and "armor/chain_mail"]. So my question again: Does the skin "current_skin" include information for each slot of the attachment of both "base" and "armor/chain_mail"?

I tried instead to use
get_node("%SpineSprite").get_skeleton().set_attachment("torso_chest", "units/gargoyle/base/torso_chest")
but it crashes the game, on both mac and windows. It's weird, because it's a different type of crash. The one on the git issue linked above, it's a hang/crash, no info is provided, but this one we get a report on the crash

-------------------------------------
Translated Report (Full Report Below)
-------------------------------------

Process:               Godot [19401]
Path:                  /Users/USER/*/Godot.app/Contents/MacOS/Godot
Identifier:            org.godotengine.godot
Version:               3.5.2 (3.5.2)
Code Type:             ARM-64 (Native)
Parent Process:        launchd [1]
User ID:               501

Date/Time:             2023-03-25 06:15:30.5368 -0700
OS Version:            macOS 13.2.1 (22D68)
Report Version:        12
Anonymous UUID:        D0397991-DB07-4FDF-B026-10DE8B023AD0

Sleep/Wake UUID:       9AA20482-5FCD-4A4D-BF33-9B1E3519828F

Time Awake Since Boot: 510000 seconds
Time Since Wake:       186342 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000

Kernel Triage:
VM - pmap_enter retried due to resource shortage


Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	       0x1954e6868 __pthread_kill + 8
1   libsystem_pthread.dylib       	       0x19551dcec pthread_kill + 288
2   libsystem_c.dylib             	       0x1954562c8 abort + 180
3   libsystem_c.dylib             	       0x195455620 __assert_rtn + 272
4   Godot                         	       0x106e45d50 0x104600000 + 42229072
5   Godot                         	       0x104f19974 spine::Skeleton::setAttachment(spine::String const&, spine::String const&) + 260
6   Godot                         	       0x104f80eb8 SpineSkeleton::set_attachment(String const&, String const&) + 340
7   Godot                         	       0x1059b866c 0x104600000 + 20678252
8   Godot                         	       0x106ab7804 Object::call(StringName const&, Variant const**, int, Variant::CallError&) + 376
9   Godot                         	       0x106b68c18 Variant::call_ptr(StringName const&, Variant const**, int, Variant*, Variant::CallError&) + 128
10  Godot                         	       0x1048bccd8 GDScriptFunction::call(GDScriptInstance*, Variant const**, int, Variant::CallError&, GDScriptFunction::CallState*) + 88124
11  Godot                         	       0x106ab7738 Object::call(StringName const&, Variant const**, int, Variant::CallError&) + 172
12  Godot                         	       0x106b68c18 Variant::call_ptr(StringName const&, Variant const**, int, Variant*, Variant::CallError&) + 128
13  Godot                         	       0x1048bccd8 GDScriptFunction::call(GDScriptInstance*, Variant const**, int, Variant::CallError&, GDScriptFunction::CallState*) + 88124
14  Godot                         	       0x106ab7738 Object::call(StringName const&, Variant const**, int, Variant::CallError&) + 172
15  Godot                         	       0x106b68c18 Variant::call_ptr(StringName const&, Variant const**, int, Variant*, Variant::CallError&) + 128
16  Godot                         	       0x1048bccd8 GDScriptFunction::call(GDScriptInstance*, Variant const**, int, Variant::CallError&, GDScriptFunction::CallState*) + 88124
17  Godot                         	       0x106ab7738 Object::call(StringName const&, Variant const**, int, Variant::CallError&) + 172
18  Godot                         	       0x106b68c18 Variant::call_ptr(StringName const&, Variant const**, int, Variant*, Variant::CallError&) + 128
19  Godot                         	       0x1048bccd8 GDScriptFunction::call(GDScriptInstance*, Variant const**, int, Variant::CallError&, GDScriptFunction::CallState*) + 88124
20  Godot                         	       0x106ab7738 Object::call(StringName const&, Variant const**, int, Variant::CallError&) + 172
21  Godot                         	       0x106b68c18 Variant::call_ptr(StringName const&, Variant const**, int, Variant*, Variant::CallError&) + 128
22  Godot                         	       0x1048bccd8 GDScriptFunction::call(GDScriptInstance*, Variant const**, int, Variant::CallError&, GDScriptFunction::CallState*) + 88124
23  Godot                         	       0x106ab7738 Object::call(StringName const&, Variant const**, int, Variant::CallError&) + 172
24  Godot                         	       0x106b68c18 Variant::call_ptr(StringName const&, Variant const**, int, Variant*, Variant::CallError&) + 128
25  Godot                         	       0x1048bccd8 GDScriptFunction::call(GDScriptInstance*, Variant const**, int, Variant::CallError&, GDScriptFunction::CallState*) + 88124
26  Godot                         	       0x106ab7738 Object::call(StringName const&, Variant const**, int, Variant::CallError&) + 172
27  Godot                         	       0x106ab9a4c Object::emit_signal(StringName const&, Variant const**, int) + 1400
28  Godot                         	       0x106ab8140 Object::emit_signal(StringName const&, Variant const&, Variant const&, Variant const&, Variant const&, Variant const&, Variant const&, Variant const&, Variant const&) + 184
29  Godot                         	       0x105c182d8 Node::_propagate_after_exit_branch(bool) + 308
30  Godot                         	       0x105c15dcc Node::_notification(int) + 104
31  Godot                         	       0x106ac3a44 predelete_handler(Object*) + 44
32  Godot                         	       0x105c46650 SceneTree::_flush_delete_queue() + 116
33  Godot                         	       0x105c45da0 SceneTree::iteration(float) + 1656
34  Godot                         	       0x1046387f8 Main::iteration() + 572
35  Godot                         	       0x104610c08 OS_OSX::run() + 284
36  Godot                         	       0x1046164f8 main + 568
37  dyld                          	       0x1951f3e50 start + 2544

Thread 1:
0   libsystem_pthread.dylib       	       0x195518e18 start_wqthread + 0

Thread 2:
0   libsystem_pthread.dylib       	       0x195518e18 start_wqthread + 0

Thread 3:
0   libsystem_pthread.dylib       	       0x195518e18 start_wqthread + 0

Thread 4:
0   libsystem_pthread.dylib       	       0x195518e18 start_wqthread + 0

Thread 5:
0   libsystem_pthread.dylib       	       0x195518e18 start_wqthread + 0

Thread 6:
0   libsystem_kernel.dylib        	       0x1954e184c __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x19551e638 _pthread_cond_wait + 1232
2   libc++.1.dylib                	       0x19546aac4 std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&) + 28
3   Godot                         	       0x106ccf40c _IP_ResolverPrivate::_thread_function(void*) + 160
4   Godot                         	       0x106c34cbc Thread::callback(Thread*, Thread::Settings const&, void (*)(void*), void*) + 172
5   Godot                         	       0x106c3524c 0x104600000 + 40063564
6   libsystem_pthread.dylib       	       0x19551e06c _pthread_start + 148
7   libsystem_pthread.dylib       	       0x195518e2c thread_start + 8

Thread 7:
0   libsystem_kernel.dylib        	       0x1954e184c __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x19551e638 _pthread_cond_wait + 1232
2   libc++.1.dylib                	       0x19546aac4 std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&) + 28
3   Godot                         	       0x1068b5d64 VisualServerScene::_gi_probe_bake_thread() + 148
4   Godot                         	       0x106c34cbc Thread::callback(Thread*, Thread::Settings const&, void (*)(void*), void*) + 172
5   Godot                         	       0x106c3524c 0x104600000 + 40063564
6   libsystem_pthread.dylib       	       0x19551e06c _pthread_start + 148
7   libsystem_pthread.dylib       	       0x195518e2c thread_start + 8

Thread 8:: caulk.messenger.shared:17
0   libsystem_kernel.dylib        	       0x1954ddfcc semaphore_wait_trap + 8
1   caulk                         	       0x19ea02cfc caulk::mach::semaphore::wait_or_error() + 28
2   caulk                         	       0x19e9e5634 caulk::concurrent::details::worker_thread::run() + 56
3   caulk                         	       0x19e9e5278 void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, void (caulk::concurrent::details::worker_thread::*)(), std::__1::tuple<caulk::concurrent::details::worker_thread*> > >(void*) + 96
4   libsystem_pthread.dylib       	       0x19551e06c _pthread_start + 148
5   libsystem_pthread.dylib       	       0x195518e2c thread_start + 8

Thread 9:: com.apple.audio.IOThread.client
0   libsystem_kernel.dylib        	       0x1954de050 mach_msg2_trap + 8
1   libsystem_kernel.dylib        	       0x1954f011c mach_msg2_internal + 80
2   libsystem_kernel.dylib        	       0x1954e6c24 mach_msg_overwrite + 452
3   libsystem_kernel.dylib        	       0x1954de3cc mach_msg + 24
4   CoreAudio                     	       0x19792cbbc HALB_MachPort::SendSimpleMessageWithSimpleReply(unsigned int, unsigned int, int, int&, bool, unsigned int) + 104
5   CoreAudio                     	       0x1977ff488 HALC_ProxyIOContext::IOWorkLoop() + 3612
6   CoreAudio                     	       0x1977fe024 invocation function for block in HALC_ProxyIOContext::HALC_ProxyIOContext(unsigned int, unsigned int) + 116
7   CoreAudio                     	       0x197988aec HALB_IOThread::Entry(void*) + 88
8   libsystem_pthread.dylib       	       0x19551e06c _pthread_start + 148
9   libsystem_pthread.dylib       	       0x195518e2c thread_start + 8

Thread 10:
0   libsystem_pthread.dylib       	       0x195518e18 start_wqthread + 0

Thread 11:
0   libsystem_pthread.dylib       	       0x195518e18 start_wqthread + 0

Thread 12:: com.apple.NSEventThread
0   libsystem_kernel.dylib        	       0x1954de050 mach_msg2_trap + 8
1   libsystem_kernel.dylib        	       0x1954f011c mach_msg2_internal + 80
2   libsystem_kernel.dylib        	       0x1954e6c24 mach_msg_overwrite + 452
3   libsystem_kernel.dylib        	       0x1954de3cc mach_msg + 24
4   CoreFoundation                	       0x1955fdbb0 __CFRunLoopServiceMachPort + 160
5   CoreFoundation                	       0x1955fc49c __CFRunLoopRun + 1232
6   CoreFoundation                	       0x1955fb878 CFRunLoopRunSpecific + 612
7   AppKit                        	       0x1989ac19c _NSEventThread + 172
8   libsystem_pthread.dylib       	       0x19551e06c _pthread_start + 148
9   libsystem_pthread.dylib       	       0x195518e2c thread_start + 8


Thread 0 crashed with ARM Thread State (64-bit):
    x0: 0x0000000000000000   x1: 0x0000000000000000   x2: 0x0000000000000000   x3: 0x0000000000000000
    x4: 0x0000000000000000   x5: 0x0000000000000000   x6: 0x0074736568635f6f   x7: 0x000000016b7fa9b8
    x8: 0x8b9095669c5fb984   x9: 0x8b9095676cf538c4  x10: 0xcccccccccccccccd  x11: 0x000000000000000a
   x12: 0x0000000000000000  x13: 0x0000000000000033  x14: 0x00000000000007fb  x15: 0x00000000ec8380e1
   x16: 0x0000000000000148  x17: 0x00000001f590b6d8  x18: 0x0000000000000000  x19: 0x0000000000000006
   x20: 0x00000001f0aa8140  x21: 0x0000000000000103  x22: 0x00000001f0aa8220  x23: 0x000000010738a779
   x24: 0x00000001ee56e000  x25: 0x0000000000000010  x26: 0x0000000000000013  x27: 0x0000000100000000
   x28: 0x0000000144255e70   fp: 0x000000016b7fac10   lr: 0x000000019551dcec
    sp: 0x000000016b7fabf0   pc: 0x00000001954e6868 cpsr: 0x40001000
   far: 0x0000000282014000  esr: 0x56000080  Address size fault

Binary Images:
       0x1954dd000 -        0x195516feb libsystem_kernel.dylib (*) <3dcd49b9-b3c5-3d90-be40-a3b807cb9cd7> /usr/lib/system/libsystem_kernel.dylib
       0x195517000 -        0x195523ffb libsystem_pthread.dylib (*) <9f3b729a-ed04-3e65-adac-d75ad06ebbdc> /usr/lib/system/libsystem_pthread.dylib
       0x1953dd000 -        0x19545dffb libsystem_c.dylib (*) <14cd841b-0c7b-34a2-a342-cc6796ef9259> /usr/lib/system/libsystem_c.dylib
       0x104600000 -        0x107f1bfff org.godotengine.godot (3.5.2) <98e2fcfa-47d9-3949-8a12-3ca258e2fe13> /Users/USER/*/Godot.app/Contents/MacOS/Godot
       0x1951ee000 -        0x195278ba3 dyld (*) <191e84f1-4b95-39c8-b253-1c1ef56c0fa8> /usr/lib/dyld
       0x19545e000 -        0x1954c4ff3 libc++.1.dylib (*) <e2679357-b2af-30d4-8130-50d31765af88> /usr/lib/libc++.1.dylib
       0x19e9e3000 -        0x19ea0cfff com.apple.audio.caulk (1.0) <41def0d0-3b1f-3029-8e99-2c9304571021> /System/Library/PrivateFrameworks/caulk.framework/Versions/A/caulk
       0x197619000 -        0x197d20fff com.apple.audio.CoreAudio (5.0) <e182f603-d6fa-3458-afb4-e3ccf4273180> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
       0x19557c000 -        0x195a53fff com.apple.CoreFoundation (6.9) <18260df4-69a8-30d3-8175-fb8ae7ae7709> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
       0x198848000 -        0x199753fff com.apple.AppKit (6.9) <88722053-0df0-3d4f-bf55-7e3c2d2c8e29> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=1.1G resident=0K(0%) swapped_out_or_unallocated=1.1G(100%)
Writable regions: Total=1.7G written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=1.7G(100%)

                                VIRTUAL   REGION 
REGION TYPE                        SIZE    COUNT (non-coalesced) 
===========                     =======  ======= 
Accelerate framework               256K        2 
Activity Tracing                   256K        1 
CG backing stores                  768K        4 
CG image                           176K        7 
ColorSync                          528K       25 
CoreAnimation                      160K       10 
CoreGraphics                        32K        2 
CoreUI image data                  432K        6 
Foundation                          16K        1 
Foundation (reserved)               16K        1         reserved VM address space (unallocated)
Kernel Alloc Once                   32K        1 
MALLOC                           750.3M      112 
MALLOC guard page                  192K       10 
MALLOC_MEDIUM (reserved)         632.0M        6         reserved VM address space (unallocated)
MALLOC_NANO (reserved)           256.0M        1         reserved VM address space (unallocated)
OpenGL GLSL                        256K        3 
STACK GUARD                       56.2M       13 
Stack                             14.4M       13 
VM_ALLOCATE                       61.7M      878 
__AUTH                             684K      175 
__AUTH_CONST                      12.2M      338 
__CTF                               756        1 
__DATA                            3061K      328 
__DATA_CONST                      16.6M      343 
__DATA_DIRTY                       800K      115 
__FONT_DATA                        2352        1 
__GLSLBUILTINS                    5174K        1 
__LINKEDIT                       773.5M        5 
__OBJC_CONST                      1542K      148 
__OBJC_RO                         65.5M        1 
__OBJC_RW                         1988K        1 
__TEXT                           304.3M      359 
dyld private memory                256K        1 
mapped file                       83.1M       24 
shared memory                      896K       16 
===========                     =======  ======= 
TOTAL                              3.0G     2953 
TOTAL, minus reserved VM space     2.1G     2953

Summary:

If you please, I would like a response to my question (if the skin has the attachment info from two skins),
I also would like to know what is the correct workflow for changing attachments.
I reported 2 crashes in this post.

Mario

When you call custom_skin.add_skin(some_skin) then all attachments in some_skin are added to custom_skin. When you then call custom_skin.add_skin(other_skin) then all attachments of other_skin will be added. Attachments added from some_skin will be replaced by attachments from other_skin if the slot and attachment name are the same. In you csaea, if you first add the skin base to the custom skin, then add the skin armor/chain_mail, then attachments in the custom skin previously added from base may be replaced by attachments with the same slot and attachment name found in armor/chain_mail.

A skin really only knows what attachment is assigned to a slot + attachment name pair. What skin that attachment came from is not known or stored by skin. If you replace an attachment in a skin, than that's the new attachment for that slot + attachment name pair. If you want to go back to the old attachment for that slot + attachment name pair, then you'll have to either call add_skin with the original skin you got the attachment from, or you can surgically replace just a single attachment.

Another scenario goes like this. Let's assume the base skin only has an attachment set for the slot "foo" and attachment name "bar". Next you add a skin "on top" of that which has an attachment for the slot "fuzz" and attachment name "fizz". The custom skin now has two attachments set, one for "foo/bar" and another for "fuzz/fizz".

If you now want to go back to just the "base" skin, you have two options:

You can create a new custom skin and add the base skin. This is what you are currently doing. This is absolutely fine and will have 0 performance impact. It is also very easy to code up and easy to understand.
You can "surgically" juggle removing/replacing attachments you no longer want in the custom skin. This is complex and error prone, and likely also slower than just creating a new skin, as you have to scan through all the attachments of all the skins you combined and figure out which attachments to remove/replace. I would not recommend this.

As for the 2 crashes you reported, I'm afraid I can not reproduce either of those. Could you maybe modify the mix-and-match example scene in the example project of the spine-godot runtime so it crashes like you describe?