Wall Worm Forums

Hi,

These days Valve did an update of CSGO, and it change the skeleton/animations and other things... the problem is the next; on Zombie Reloaded Servers (The most famous mod on CSGO) there is a crash called "SlerpBone" it's happens when the playermodel has a "wrong" skeleton and on some ramdom times the engine crash.

On the old csgo skeleton, I found the way to do it fine but on this new one the exporter F#$@ it, I explain more or less:

When I import the model to 3DSMax I have it;

version 1
nodes
  0 "pelvis" -1
  1 "spine_0" 0
  2 "spine_1" 1
  3 "spine_2" 2
  4 "spine_3" 3
  5 "neck_0" 4
  6 "head_0" 5
  7 "clavicle_L" 4
  8 "arm_upper_L" 7
  9 "arm_lower_L" 8
  10 "hand_L" 9
  11 "finger_middle_meta_L" 10
  12 "finger_middle_0_L" 11
  13 "finger_middle_1_L" 12
  14 "finger_middle_2_L" 13
  15 "finger_pinky_meta_L" 10
  16 "finger_pinky_0_L" 15
  17 "finger_pinky_1_L" 16
  18 "finger_pinky_2_L" 17
  19 "finger_index_meta_L" 10
  20 "finger_index_0_L" 19
  21 "finger_index_1_L" 20
  22 "finger_index_2_L" 21
  23 "finger_thumb_0_L" 10
  24 "finger_thumb_1_L" 23
  25 "finger_thumb_2_L" 24
  26 "finger_ring_meta_L" 10
  27 "finger_ring_0_L" 26
  28 "finger_ring_1_L" 27
  29 "finger_ring_2_L" 28
  30 "weapon_hand_L" 10
  31 "arm_lower_L_TWIST" 9
  32 "arm_lower_L_TWIST1" 9
  33 "arm_upper_L_TWIST" 8
  34 "arm_upper_L_TWIST1" 8
  35 "clavicle_R" 4
  36 "arm_upper_R" 35
  37 "arm_lower_R" 36
  38 "hand_R" 37
  39 "finger_middle_meta_R" 38
  40 "finger_middle_0_R" 39
  41 "finger_middle_1_R" 40
  42 "finger_middle_2_R" 41
  43 "finger_pinky_meta_R" 38
  44 "finger_pinky_0_R" 43
  45 "finger_pinky_1_R" 44
  46 "finger_pinky_2_R" 45
  47 "finger_index_meta_R" 38
  48 "finger_index_0_R" 47
  49 "finger_index_1_R" 48
  50 "finger_index_2_R" 49
  51 "finger_thumb_0_R" 38
  52 "finger_thumb_1_R" 51
  53 "finger_thumb_2_R" 52
  54 "finger_ring_meta_R" 38
  55 "finger_ring_0_R" 54
  56 "finger_ring_1_R" 55
  57 "finger_ring_2_R" 56
  58 "weapon_hand_R" 38
  59 "arm_lower_R_TWIST" 37
  60 "arm_lower_R_TWIST1" 37
  61 "arm_upper_R_TWIST" 36
  62 "arm_upper_R_TWIST1" 36
  63 "leg_upper_L" 0
  64 "leg_lower_L" 63
  65 "ankle_L" 64
  66 "ball_L" 65
  67 "leg_upper_L_TWIST" 63
  68 "leg_upper_L_TWIST1" 63
  69 "leg_upper_R" 0
  70 "leg_lower_R" 69
  71 "ankle_R" 70
  72 "ball_R" 71
  73 "leg_upper_R_TWIST" 69
  74 "leg_upper_R_TWIST1" 69
  75 "ValveBiped.weapon_bone" 38
  76 "lh_ik_driver" 10
  77 "lean_root" -1
  78 "lfoot_lock" 66
  79 "rfoot_lock" 72
  80 "primary_jiggle_jnt" 3
end

When I export with 3DSMax I get it:

nodes
  0 "pelvis"  -1
  1 "spine_0"   0
  2 "spine_1"   1
  3 "spine_2"   2
  4 "spine_3"   3
  5 "neck_0"   4
  6 "head_0"   5
  7 "clavicle_L"   4
  8 "arm_upper_L"   7
  9 "arm_lower_L"   8
10 "hand_L"   9
11 "finger_middle_meta_L"  10
12 "finger_middle_0_L"  11
13 "finger_middle_1_L"  12
14 "finger_middle_2_L"  13
15 "finger_pinky_meta_L"  10
16 "finger_pinky_0_L"  15
17 "finger_pinky_1_L"  16
18 "finger_pinky_2_L"  17
19 "finger_index_meta_L"  10
20 "finger_index_0_L"  19
21 "finger_index_1_L"  20
22 "finger_index_2_L"  21
23 "finger_thumb_0_L"  10
24 "finger_thumb_1_L"  23
25 "finger_thumb_2_L"  24
26 "finger_ring_meta_L"  10
27 "finger_ring_0_L"  26
28 "finger_ring_1_L"  27
29 "finger_ring_2_L"  28
30 "weapon_hand_L"  10
31 "lh_ik_driver"  10
32 "arm_lower_L_TWIST"   9
33 "arm_lower_L_TWIST1"   9
34 "arm_upper_L_TWIST"   8
35 "arm_upper_L_TWIST1"   8
36 "clavicle_R"   4
37 "arm_upper_R"  36
38 "arm_lower_R"  37
39 "hand_R"  38
40 "finger_middle_meta_R"  39
41 "finger_middle_0_R"  40
42 "finger_middle_1_R"  41
43 "finger_middle_2_R"  42
44 "finger_pinky_meta_R"  39
45 "finger_pinky_0_R"  44
46 "finger_pinky_1_R"  45
47 "finger_pinky_2_R"  46
48 "finger_index_meta_R"  39
49 "finger_index_0_R"  48
50 "finger_index_1_R"  49
51 "finger_index_2_R"  50
52 "finger_thumb_0_R"  39
53 "finger_thumb_1_R"  52
54 "finger_thumb_2_R"  53
55 "finger_ring_meta_R"  39
56 "finger_ring_0_R"  55
57 "finger_ring_1_R"  56
58 "finger_ring_2_R"  57
59 "weapon_hand_R"  39
60 "ValveBiped.weapon_bone"  39
61 "arm_lower_R_TWIST"  38
62 "arm_lower_R_TWIST1"  38
63 "arm_upper_R_TWIST"  37
64 "arm_upper_R_TWIST1"  37
65 "primary_jiggle_jnt"   3
66 "leg_upper_L"   0
67 "leg_lower_L"  66
68 "ankle_L"  67
69 "ball_L"  68
70 "lfoot_lock"  69
71 "leg_upper_L_TWIST"  66
72 "leg_upper_L_TWIST1"  66
73 "leg_upper_R"   0
74 "leg_lower_R"  73
75 "ankle_R"  74
76 "ball_R"  75
77 "rfoot_lock"  76
78 "leg_upper_R_TWIST"  73
79 "leg_upper_R_TWIST1"  73
80 "lean_root"  -1
81 "smdimport"  -1
end


When it's happens and the bones don't have the same numbers, the crash appears.


The question is; Is possible do anything with the exporter to export the skeleton like the imported one? I tested it on Milkshape and it's nice, so it's possible. I have tried with the 3 exporters on 3DSMax and all have the same problem. If you can help me with that would be nice, because if you use 3DSMax you're F#$@ed.

Thanks!

When I imported skeletons from CS:GO I always made sure to export the new skins with the exact same settings as in the decompiled .qc, as in you literally copy-paste whatever was in that .qc. The reason for that is because when Wall Worm exports this model, just a few slight changes might be made during export which ended up in some crashes even on the old model rig. I'm not sure why that was, and what 3DS Max does exactly to cause these changes, but by copying the exact same .qc values from the decompiled one and simply adjusting the new paths for your custom model made it work for me. I expect nothing less from the new one, UNLESS the new skeleton has NEW COMMANDS. With this update, it's very well possible, and that means someone has to find out how a decompiler can decompile those.

Also, I think you should remove '81 "smdimport"  -1' as it originally didn't belong to the model (judging from the 2 .qc's.)

Editing the SMD is probably not the solution. That means you should not edit the SMD to remove the "smdimport" bone. The reason is that it is probably the only bone that has a mesh assigned to it--so if you try to compile that SMD as a reference with the smdimport bone entry removed, it will not work.

If you want to remove the smdimport bone, use the QC command to $collapsebone "smdimport". If re-exporting the whole model via WWMT, you can assign an advanced bone setting to that node in Max.

Beyond that, I don't know what to tell you. The compilers use the names of the bones and the hierarchy defined in the SMD, not the node IDs in the SMD, when matching different bones from different SMDs. So there is absolutely nothing invalid about the two SMD files listed. Both will work. Why one crashes and not the other is just as likely a result of some bad information in the decompiled SMD or your Max settings.

I do not and never will spend much time trying to figure out crashes from decompiled models. It's too much effort and time on my part to support something I do not do. If someone wants to pay me a week's wage to investigate, sure.

My only other idea is that the original SMD had bone weights that exceed what Source wants. Wall Worm does not strip bone weights even if they exceed the Max bone per vert  allowed in Source. So if your imported model included higher bone per vert weighting and the updates to Source don't like that, it's an issue that needs to be addressed in the model. Again, this isn't a Wall Worm issue, but a model issue. This can be checked in the Skin modifier.

The problem is that only happens on this F#$@ing skeleton. It's happened on the old csgo skeleton too, but I just fix it importing the original skeleton and export and all fine, but on this one I can't do nothing, I always export a "wrong" skeleton, I know that it's not a WW problem, if I extract to .FBX or other format I get the wrong skeleton too. It's 3DSMax thing, because on Milkshape for example I tested it and the exporter do a good work and don't change the order of bones, but I don't know rig on Milkshape so shit.

Not is the number of the bones, it's the order of them, I just guess that on some times the motor don't read well the skeleton and the server crash. I'm 100% sure of this, I did many tests.

So " '81 "smdimport"  -1' " don't care, it's because I used the old cannonfodders exporter to do the example.

My principal question was if is possible do a "good" export. But if We assume that it's 3DSMax thing...I don't know what to do.

Thanks for answers.

Well, you can try using the WW SMD exporter. Of course, you'll need to use 3ds Max 2014+ to get correct skin weights for that. I don't support Max 2012 anymore. Max 2015 is currently the version I recommend most. The skin functions in Max were changed and improved in Max 2014; previous versions of Max are not compatible with WW SMD and skin.

In terms of this issue: I cannot imagine how the order of the SMD nodes can break a model if the hierarchy in the SMD is correct. The only real rule is that any node's parent is defined further up the node (if it has one). From my review, the Cannonfodder SMD you posted is 100% valid. So if it really is the order of the SMD nodes that breaks this, then the bug is a Valve bug or whichever plugin provider is making the function that breaks. Most likely, there is some bad logic in the game plugin or the game engine. In which case, they need to fix the bug.

I don't know how Cannonfodder chooses to order the nodes, but I know that the WW SMD exporter orders the nodes in a correct order based on node hierarchy. Once the hierarchy is a true parent-child order, it's valid SMD.

I know It's happens only on Zombie Reloaded servers, I guess for too many model change on the round, and Valve don't care about the mods and when they do the models right, so we're on the shit if we hope a fix, its happens from like one year ago (Hallowen update).

I'll think about get some new 3DSMax version, I use 2012. But I'm not sure, because if it happens only with this skeleton... If you have a momment, Can you do last thing for me? Always If you use 3DSMax 2014/15 can you just Import the .smd and export, and see if it happens? I will appreciate it and I'm saving time, It's jus a momment.

https://drive.google.com/file/d/0BxAWIML840OFeEQxWHgzR3pMaE0/view?usp=sharing

Thanks again.

The attachment has an SMD that I re-exported from Max 2015.

I noticed nothing abnormal in the model or the exported SMD.

WW's hierarchy in the SMD doesn't match your original decompiled SMD, but really that shouldn't matter. All I can say is the SMD looks valid that is exported.

Hi, It's me again,

After a few weeks looking for "What" make the possible new "slerpbone crash" on servers, We haven't found anything. This happens completely random (As always) and I think now more than ever that it's a problem with the extracted skeleton of 3DSMax, as I said in above posts. I think that I do the models 99% as the original one (Same .QC, same .smd's), the 1% is the different order of the bones.

I tried many things, download new software (Milkshape, GMAx...) with support with .smd and an exporter that doesn't change the order of the bones, in order to find a solution exporting the model from 3DSMax rigged and convert it with 'good' skeleton, but it's impossible, the skeletons are incompatible, I tried too edit manually the .smd, but nothing.

I know that it's a 3DSMax thing, he export the skeleton and reorders as he thinks correct. I know that it's Valve problem, they don't care about this "crash" from years.

Simply say my theory is that right now We can't do CSGO playermodels with 3DSMax. Because the motor fails when the skeleton order change on custom playermodels. I have hours of tests on servers with bots, and ppl testing my models on public servers and getting crashes, and when they remove the model, 0 problems. And well, I have the proof  of the "old slerpbone problem", I fixed it extracting a good skeleton with good bone order.

I don't know if one day this will be fixed, I only hope so.

I feel your pain. I wish I could tell you that I can provide a fast solution for your specific problem. But the fact is that the exporter works according to the specifications of Source. This may be symptomatic of Max exports, but it's a Source engine or a modification bug. That is because the bone hierarchy order is based on parent/child relationships. I can't speak for how Wunderboy or Cannonfodder chose the order logic, but I see it's slightly different than WW SMD; and WW SMD is based on absolutely correct parent/child ordering rules. Parent nodes must be defined before child nodes. That's it.

I am already hyper-extended when it comes to my time. I just can't realistically look at this problem at this moment.

Even though you say that you are 99% sure it's the bone order, there are potentially other issues that can come into play. Other issues could be 1) Bone-per-Vert count (which would take a lot of time to analyze an SMD and make sure that a Max SMD VS other is different); you may want to make 100% certain that the skin modifier has a maximum of 3 bones affecting any vert in the Skin as WW does not truncate this. 2) Another likely suspect is simply the fact that the WW (and Cannonfodder SMD) include a bone node that relates to the Mesh node(s) whereas some SMD exporters might exclude that; this can potentially increase the entity count in a level which can potentially crash Source (if the number of entities exceeds the allowed limit). In that case, using the right QC commands to remove the mesh node could help (as I think I hinted above).

Etc, etc.

I wish I could give you a better answer, but I just don't have the time at this moment to track down the cause of this. Having done so much programming and troubleshooting for so many years, I'm more inclined to suspect the suspects above than the actual bone order in the SMD (because the MDL hierarchy, for all I know, is agnostic to bone node IDs from SMD/DMX files--and must be considering I've seen Valve's own player models with different hierarchies in their own SMD files for the same models).