Hi Pharan,

Thank you so much for taking your time looking into this.

This is what I had in my game...

Separator Slot Names
 Loading Image

Slots/Attachments in the model
 Loading Image

Playmaker commands that disable 'Blush', 'Skirt' and 'Top'
 Loading Image

So when I start the game those three attachments get disabled immediately and elements 12 and 13 stop pointing to 'Top' and 'Skirt' and start pointing to 'R_Arm' and 'Head'. And the following elements 14, 15, etc., point to the slots assigned to 16, 17 and so on. In fact, elements 20, 21 and 22 end up by pointing to no slots at all. I suppose due to element 19 getting the rest of them.

However, one thing I didn't realized after writing this thread was that 'Blush' didn't get me any problems even if it's also disabled at the game start. But that slot is included in a render separator along with other slots... so when it got disabled, its parent element must have ignored that fact because it still had other slots to render.

In the light of this discovery I've made some tests and yes, it's confirmed...: even if you assign a slot to be hidden to an element, but it also "owns" other slots before the next part, you can click on the skeleton parts renderer and still has the remaining mesh/es drawn and it keeps from assigning itself to the next non-disabled slots.

So, my understanding is that as long as you don't create a separator that ends up with no slots to paint, then all will be fine and your sorting order will not get messed up.

Now... is this a desired behavior? In my humble understanding I'd say no. I'd very much prefer to be able to have render separators that only have one slot to render, and have the peace of mind that even if I disable their only child they will refrain from messing up my carefully set up layer sorting order. :think:

The only workaround I can think of, short of resourcing to not disable them and getting them transparent, would be to create a fake slot in Spine and put it "inside" of the separator with the slot to be disabled. But it also would need to be a transparent mesh and it would complicate my workflow even more.

So, could it be possible to prevent those renderers to think on their own?

Thank you!

Hehe... actually I don't think I need so many in the final version, but I'm in the initial phase of ordering the model parts around and I prefer to have maximum flexibility.

This is how it looks like for a specific animation I'm working on now:

 Loading Image

The numbers on the center are the 'order in layer' and the numbers on the extremes are the corresponding element. As you can see there a lot of them that could go in only one group. 15 and 18 are exceptions but yeah, I could do much better than this. :p

10 Mar 2017, 17:49

Hi there,

Not wanting to be an ass necroing old posts, but I never got a solution for this and I humbly think that this is a HUGE problem in the Unity runtimes. At least from my point of view.

In short...: if you assign a given slot to a skeleton renderer separator element, and that slot end up with no active attachments at some point (which could happen with slots for clothing, jewelry, weapons, etc) the whole sorting order scheme gets pretty messed up, because that element loses its assigned part renderer, being effectively skipped. So the 'Order in Layer' value you did set for the original (skipped) renderer "overwrites" the next one in the list.

I don't know about you but I strongly believe that one should be able to configure a separator slot name to any slot, regardless if it could be either have active or inactive attachments at some point in the execution.

And why this is a problem? Because I'm making my characters interact with each other. Hence the need for renderer separators and so many elements that could be sorted out in a fairly complex way (adult game). :p

Well, I think the way it works now is ok if you're assuming your characters will always be separate entities. I also think that its been assumed that a slot will always be populated with an active attachment... and IMHO that's assuming too much. For me it's only normal wanting to have a special slot for clothing pieces that can perfectly go over an existing body part... being "can" the key word here. That's the point of this...: if I have a bracelet image that I want to activate for some characters but not for others, I want enabling/disabling them to be a seamless process.

The only thing that comes to my mind to resolve this is to, instead of enabling/disabling attachments, get them transparent or not... but... man, that would be so awful and inelegant that I'd want to cry as a baby every time I see my code... :S

Mmm, another "solution" would be to create placeholder slots in between the real slots I want separated, and put in them a transparent pixel attachment that I never disable and then assign that slot to the separator... another dirty fix.

So, any chance to get a proper solution instead?

I'm on 3.6.09-beta! Also, the runtimes are more or less from ten days ago, I think.

But... now that you're saying that it's supposed to be fixed in 3.5... mmm, maybe I need to do some more testing because now I'm working in another game from the date of the original post, and I'm not actually sure if what it's happening to me reproduces exactly as I mentioned in my last post.

Man, it would definitely be shameful if I misinterpreted what I've seen in my own game... :p

Will update this with my findings. Thank you for replying.

Hi Pharan,

Sorry for taking so much time on checking this, but today it seems it's SkeletonRendererSeparator issue party. :p

I only wanted to mention that it seems I still have the problem described above, even with 3.6-beta runtimes.

In my current project I have a model that has a drooling (saliva) image and a pelt over his head and frontal arm. Both images are meshes inside their own slot each. 'Drool' is disabled by default. 'Pelt_F' is present only in one skin (Chieftain).

For sorting purposes I've put both of them in one Part Renderer. And the last Part Renderer covers the whole frontal arm.

Now, if I select the 'Chieftain' skin, all works as intended...:

But if I select another skin that doesn't have 'Pelt_F' enabled by default, this happens...:

The script parses the attachment list, and when it sees that one Part Renderer doesn't have any enabled attachments, it skips it altogether and I end up with the last one not rendering anything, and what it's far worse: with a different 'Order in layer' value.

This issue adds more grief to the one I've sent today, and sums to my understanding that maybe I'll be better off if I generate separators at runtime, because right now SkeletonRendererSeparator is not capable of being as flexible as I need.

But you also mentioned before that this was supposed to be fixed in recent runtimes, so I don't know what to think (?).

Is this working as intended or I have a bug on my hands?

Thank you for your time!

10 May 2017, 15:53

Update: I've returned to my previous workaround...

Adding a transparent 4x4px image to the 'Drool_' skin placeholder, I manage to guarantee that the Drool slot will always have an active and "visible" attachment, so its associated PartRenderer never gets "orphaned" and skipped.

I'd prefer to avoid doing this, but if there's no other way...