Your head object is to big, too many vertices. The head is too complex for studioMDL to compile. Mesh objects should not exceed 9-to 11 thousand verts.

Also, because you're using DMX exports, more than one object can contain flexes, as long as the shapekeys are not blended across objects. Each object has to have its own shapes, the names can not be the same across objects.

The best way to fix this is to confine all the verts you're using in flexes into one object then split the rest into another 1 or 2 objects.

As per the BleST discussion I started in the BleST Bug Reports on Material uniqueness:
https://steamhost.cn/steamcommunity_com/groups/BlenderSourceTools/discussions/0/3104641620181885419/

Can you add an option to the Decompile screen that will give an option to append something (don't care what as long as it is something short and simple like dupe_ or _dupe) as either a prefix or suffix to a material name if we strip the path from material names?

Edit: In fact thinking about this, a 3 character random on the end might be better (maybe??) The problem is still going to exist if importing multiples of the same decompile, but it would be limited to to that model.

Ahhhh... ikRules.... This might lead me down the path of fixing a different problem (not with Crowbar, but with anims in Blender and bringing them back into SFM)!!! Thanks Zeq.

Thanks Zeq. An oldie, but a goodie and I think you're right.

As Zeq states it's not Crowbar that does the compiling, it's only a messenger to StudioMDL,but if the model has Facial flexes (aka shapekeys) make sure the Basis key is selected and all the other shapes have been zeroed when you do your export.

This type of issue usually point to the fact that one of the shapekeys (other than basis or the root shapekey) is active or one or more shapekey are not at the default 0 position and the face is being exported with that key being considered the rest position of the face.

Another situation maybe
If the model uses bones for the face and you're exporting DMX files, make sure that none of the bone names are the same as mesh object names. (this looks like more the first situation though).

However, you DON'T want to include the standard Female animation models to give her animations!!!!! Yeeeeewwwwww!!!!

https://i.imgur.com/GC2VsUk.gif

But here she is in all her ragdoll glory https://i.imgur.com/ZVKdQCa.gifv

The model (from the blend file) works beautifully, check your qc and make sure your compiling the right exports. The one you gave me, is compiling SMDs not DMXs and also, make sure to suppress the collections before export.

Well, one way to find out if it is Crowbar that is missing something and that is to compile the QC directly from Blender or by dragging and dropping it on to Studiomdl.exe directly.

If the you think the pelvis bone should be in the log and it isn't, then you know it's not a Crowbar problem.

If it is, then I would be copying both logs and sending them and creating a bug report to Zeq.

I hate collision models, but that said, is there actually a collision block for the pelvis itself?

https://i.imgur.com/ok5E4yV.png

Also, I notice in the QC you have an added $jointrotdamping "ValveBiped.Bip01_Pelvis" 0, I don't see this in a qc for a TF2 character.

Also each bone in the TF qc has its own $jointmassbias and $jointrotdamping variable. I don't see that in your qc (and personally I don't know if these get their from the default defined value at the start of the collision definitions. $damping 0 and $rotdamping 12)

Last thing I find different between a QC that works a ragdoll is I don't see a ragdoll animation defined here either.

(like

$sequence ragdoll "../parts/dmx/sniper_ragdoll.dmx" FPS 30 activity ACT_DIERAGDOLL 1

)

Drag and drop the 7z onto the 7zip.exe file and see if that opens it. Personally, I don't use 7zip, I use WinRar.