I've been able to consistently reproduce this bug.
If I make a new session and go to import a Source mesh, the default armature mode is "Append to Target".

If I import a DMX, the next time I go to import a Source mesh, it's set to "Make New Armature".
If I change it back to "Append to Target", import a DMX, and go to import another mesh, it's at "Append to Target" again, and will stay there until I change it myself or make a new session or something, haven't tested that thoroughly (except making a new session).
This is regardless of whether the DMX has multiple parts/objects or only one.

But on the other hand, if the first import is an SMD, the next import will default to "Append to Target", as expected. If one imports a DMX after an SMD, it also defaults to "Append to Target".


Observed in the 64-bit Steam version of Blender 2.74, using version 2.5.2 of the Blender Source Tools on a 64-bit Windows 7.

Początkowo opublikowane przez Artfunkel:

Could you possibly stick the common directory into the QC as $cdmaterials instead?

I agree.

Plus, if you (ZeqMacaw) want to give people what's used to compile the models, you shouldn't include it, since with DMXes, one can set a material directory root (like $CDMaterials, except not used in texture groups), such as models/player/scout/, and then the materials will be named scout_blue for example, which StudioMDL will interpret as models/player/scout/scout_blue even though the material name is only scout_blue. At least I'm fairly certain that's what's going on. Why would people give the full material path as the material name in a modelling tool when also using $CDMaterials and a material root thing, anyway?

If you need me to confirm that material root thing does this, I can try, but I won't do it if you don't ask me to.

Początkowo opublikowane przez ZeqMacaw:

I made the change in Crowbar 0.24 to write the full path if that is what was found in the MDL file because that's the data that was used to make the MDL.

Oh, so that's actually completely intentional. I think it's a stupid change, since $CDMaterials...

I assume it takes Blender long to import these mega-material-filled meshes because it needs a little time to set up each and every material, and with thousands of materials...

I've had this happen with a Team Fortress 2 cosmetic or two before (but not many), however I think it's more a fault with the decompiler than the Blender Source Tools (although I admit I didn't check the affected cosmetic meshes in Notepad++, so it could be either).

Początkowo opublikowane przez Akuba:

Are you sure it has to be zero?

No, because if the dimensions were 0x0x0, that would mean every single thing would be at the exact same point, basically invisible. Dimensions/Size has nothing to do with being able to export or not.

Try clicking "Check for updates" in the "Source Engine Export" tab.

Maybe Internet Explorer corrupts the Zip archive or something. Try using another browser, unless you already were using another browser. But if it keeps being annoying... The Steam version of Blender has the Blender Source Tools pre-installed, plus it also auto-updates.

Maybe "idle.smd" doesn't have that bone at the right spot. Try changing $sequence idle "idle.smd" to $Sequence idle "neighbor_hater.smd"

By the way, $StaticProp removes ALL bones, and replaces them ALL with a static_prop at 0 0 0 with a rotation of 0 0 0, so that also removes Bone.Noz_01, Bone.Noz_02 and Bone.Wig (and all other bones).

You probably very well know what I mean by that. But in case not...


When importing SMDs/DMXes, there could be a checkbox for "Import normals" or so, which would default to on.

For DMX, either do as it does right now (import the normals and turn on auto-smoothing on the model) if on, or do nothing about normals (and don't turn auto-smooth on) if off.

For SMD, normals (and the auto-smooth thing) should be ignored if "Import normals" is off and/or "Preserve SMD polygons" is off, but if "Import normals" is on, and "Preserve SMD polygons" is on, then... import the normals.


I was very surprised to import a decompiled SMD with "Preserve SMD polygons" on, and find that the normals weren't imported. After all, you've said the reason normals aren't imported on SMDs is because "Remove doubles" messes it up... but "Preserve SMD polygons" skips that.

If you wouldn't like to clutter up the interface with that checkbox, it'd also be fine if normals are just imported to SMDs if "Preserve SMD polygons" is on, with no changes to DMX importing, and with SMD normals still ignored if "Preserve SMD polygons" is off.