There's only one other suggestion I can make without actually looking at the model myself and that is, when you exported the mesh, was the basis shape in Blender selected and were all the shapes zeroed?

By doulbling, I mean, do you have the head objects multiple build statements like

$model "blah" "head.dmx" {
blah...
blah...
}

and/or a

$body "head" "head.dmx"

and/or a

$bodygroup "head" {
studio head.dmx
studio blah...
studio blah...
blank
}

What are you expecting to see in SFM, or what is it you think is wrong in SFM? Do they not fall back into place it you move the playhead in SFM, or distort out of control? (screen shot of that would help)

And are you saying that, (as an example) initially the bones were pointed downward, you rotated them in edit mode in blender 90 degrees, exported and recompiled the model. On load in SFM the bones are still pointed downward and on decompile of that SFM model and re import into Blender the bones are pointed downward again?

Also, do you have any animations attached to the model in Blender (or not using a new ref animation based on the new positions as a sequence) in the build QC?

are you defining the jiggles in the QC properly? And do you have the same model in a folder with a higher priority that is loading instead of the one your think you/re loading? Try changing the $modelname statement to a different name on your next compile to see if you have multiples.

Are you doubling the mesh anywhere in the head when you compile>? Are you exporting SMD or DMX files and is the face solid and doesn't have any non manifold edges or vertexes?

Submitted a feature request to Zeq to add an option to add (something) to to a material name if we strip the path from a material name on decompile.
(The condition also exists in DMX imports from the sourcesdk_content Reference models so an option in BleST would be nice as well. Like a 4 character random _rdm1rdm2rdm3 (rdm=Random) extension if a material already exists. This would definitely make any dupe material imported unique while retaining original material names if they don't already exist and would be easy to find if created.)

This isn't a Blender or Add-on problem, it a user's preference problem and only exists on models that are decompiled (or brought in from other sources). But it could be handled on decompile as well.

Zeq, you already give us the option to add a prefix to mesh names (model Name), could you add an option to add either a prefix or suffix to materials if we strip the path? This would get us back to Class uniqueness again.

I would think it would be a heck of a lot easier to identify and rename or copy to make a new material with a name like
hw2013_volatile_voodoo_1_blue_color.001 (39Characters)
than models\workshop\player\items\all_class\hw2013_volatile_voodoo\hw2013_volatile_voodoo_1_blue_color (97 Characters)
as we did in the past.

It doesn't have to be .001, it just has to be something to make the material name unique, if one already exists. hw2013_volatile_voodoo_1_blue_color_dup would do it or hw2013_volatile_voodoo_1_blue_color_a

I just figured out how this was handled in the past.
When models were imported, the materials were imported with their path as part of the material name. This made them unique to a model type (like class) and it was before path names were over 100 characters long or 70 levels deep. The Valve engine relies on the path to separate same named materials.
Zeq gives us the option to strip paths from materials when decompiling and It is easier to work with the short name of a material rather than the 150 character long one. But this now causes the conflict between same named materials. We need something to make them unique and break that conflict.

Zappy lähetti viestin:

It's not a Blender Source Tools bug nor a Blender bug. That's completely intentional.

Think of it this way: If you import the Scout's body and then import the Scout's legs body-group, would you want the latter to use "scout_red.001" instead of "scout_red" when the body already uses that material?
No, chances are, you probably want to use the same material on both things. That's what StudioMDL does, too.

So how should it tell that two same-named eye materials should be different when two same-named body materials shouldn't?

Pte Jack lähetti viestin:

- All Objects except materials get appended names (.001, .002 etc) -

You can't(/aren't supposed to) have two objects with the same name, and importing multiple meshes into the same object is bad too, so adding ".001" is necessary to avoid conflicts here.

But again, for materials, you probably/usually want to use the same material on both things, so it just doesn't make a new material like it makes new objects.

Sorry for re quoting Zappy, but, this does not make sense to me. especially in the case of the sniper/scout instance where the sniper (eyeball_l / eyeball_r) might be brown and the scout's blue. When I import both are going to be the same and it will be based on the first model imported when the material is created. AFAIC model materials should be as unique as the rest of the model to as you put it, avoid conflicts.

It's not often that I import multiple models into a scene and I just went back to see if this was happening in 2.xx and it is. In fact, duplicating objects doesn't create new materials either, so I guess it's just something I hadn't noticed before. So sorry for rabbit holing here, but if possible, would it be possible to add a switch as Zeq suggested to create new materials on import for materials that already exist?

Think of it this way, I want to create a city, and I want to 4 different houses (bungalow, Ranch, 2 story and apartment building) but they all have the same material names, (wall, window, roof and door) that have different textures. What skin are they going to wear on import?

What if I duplicated or imported 100, I'm going to have to "fix" the number of models that aren't going to wear the correct textures. Now what if I only wanted to change textures on 30 of them (broken windows, different roof colours, different siding styles, etc). (I guess that situation would be a 2 way street discussion, but I think I would favor having individual materials for individual models because If they import textured, the shader nodes are gong to be already established and the materials unique.)

Anyway, just my feelings on this and again, I apologize for rabbit holing a situation that didn't really exist.